RFC Errata


Errata Search
 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (2)

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 2948
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sean Turner
Date Reported: 2011-08-28
Verifier Name: Stephen Farrell
Date Verified: 2011-11-13

Section 12.2 says: 

URI:  urn:ietf:params:xml:ns:keyprov:dskpp

It should say:

URI:  urn:ietf:params:xml:schema:keyprov:dskpp

Notes:

Section 12.2 is the registration for the schema not the namespace, which is in Section 12.1. The URI for the schema ought to point to :schema: and not :ns:. It's in the IANA registry it just needs to be updated here.

Errata ID: 2999
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gareth Richards
Date Reported: 2011-10-17
Verifier Name: Sean Turner
Date Verified: 2011-11-13

Section 4.2.4 says: 

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), AD          --->


   When this message is sent:
      The DSKPP Client will send this message immediately following a
      <KeyProvServerHello> message whose status was set to "Continue".

It should say:

           DSKPP Client                         DSKPP Server
           ------------                         ------------
           E(K,R_C), [AD]          --->

   When this message is sent:
      The DSKPP Client will send this message immediately following a
      <KeyProvServerHello> message whose status was set to "Continue".
      The AD element MUST be sent unless it was already sent in the
      KeyProvClientHello message.

Notes:

The AD is carried in the <KeyProvClientHello> if sent as a result of a trigger and so is optional in the <ekyProvClientNonce>.

Status: Reported (1)

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 5314
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Walter Summonte
Date Reported: 2018-03-29

Section 3.4.1.1. says: 

checksum of 0x356, resulting in a Checksum TLV of "334D5"

It should say:

checksum of 0xEA4C, resulting in a Checksum TLV of "304EA4C"

Notes:

The ALG_ISO3309_CRC16 should be based on polynomial : x^16+x^12+x^5+1

width=16 poly=0x1021 init=0x0000 refin=false refout=false xorout=0xffff

It should it be zero left padded

Status: Held for Document Update (2)

RFC 6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)", December 2010

Source of RFC: keyprov (sec)

Errata ID: 2697
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2011-01-31
Held for Document Update by: Tim Polk

Section 3.4.1.1 says: 

   Assume that the raw Client ID value or the value entered by the use
   is: myclient!ID

It should say:

   Assume that the raw Client ID value or the value entered by the use
   is: myclient!D

Notes:

Erroneously entered an extra character "I" into Client ID value.

Errata ID: 2725
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2011-02-18
Held for Document Update by: Tim Polk

Section 7.2.2 says: 

   To handle content negotiation, HTTP requests MAY include an HTTP
   Accept header field.  This header field SHOULD should be identified
   using the MIME type specified in Section 7.2.1.  The Accept header
   MAY include additional content types defined by future versions of
   this protocol.

It should say:

   To handle content negotiation, HTTP requests MAY include an HTTP
   Accept header field.  This header field SHOULD be identified
   using the MIME type specified in Section 7.2.1.  The Accept header
   MAY include additional content types defined by future versions of
   this protocol.

Notes:

Double "should"

Report New Errata



Advanced Search