RFC Errata
Found 4 records.
Status: Verified (2)
RFC 6407, "The Group Domain of Interpretation", October 2011
Source of RFC: msec (sec)
Errata ID: 3598
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Claude Briere de L'Isle
Date Reported: 2013-04-20
Verifier Name: Sean Turner
Date Verified: 2013-05-02
Section 5.5.1 says:
DST ID Prot (1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) [PROT-REG]. A value of zero means that the DST ID Prot field MUST be ignored.
It should say:
To be removed, this field does not exist
Notes:
M. Brian Weiss confirmed to me that "The description of "DST ID Prot (1 octet) on Page 32 is incorrect, no such field is meant to be in Figure 8. This is definitely errata. The bullet describing "DST ID Prot (1 octet)" should be removed"
Errata ID: 3599
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Claude Briere de L'Isle
Date Reported: 2013-04-20
Verifier Name: Sean Turner
Date Verified: 2013-05-02
Section 5.5.1 says:
o DST ID Port (2 octets) -- Value specifying a port associated with the source ID. A value of zero means that the DST ID Port field MUST be ignored.
It should say:
o DST ID Port (2 octets) -- Value specifying a port associated with the destination ID. A value of zero means that the DST ID Port field MUST be ignored.
Notes:
Brian Weiss wrote "You are correct, this should be "destination ID"".
Status: Held for Document Update (2)
RFC 6407, "The Group Domain of Interpretation", October 2011
Source of RFC: msec (sec)
Errata ID: 3600
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Claude Briere de L'Isle
Date Reported: 2013-04-20
Held for Document Update by: Sean Turner
Section 7.4 says:
The concepts "forward access control" and "backward access control" have also been described as "perfect forward security" and "perfect backward security", respectively, in the literature [RFC2627].
It should say:
The concepts "forward access control" and "backward access control" have also been described as "perfect forward security" and "perfect backward security", respectively, in the literature (<http://tools.ietf.org/id/draft-balenson-groupkeymgmt-oft-00.txt>).
Notes:
There is no occurrence of these terms in RFC 2627. Brian Weiss wrote : "You are correct. I see that this wording was carried from early versions of an Internet-draft that became RFC 3547, the predecessor of RFC6407. A more accurate reference for these terms would be <http://tools.ietf.org/id/draft-balenson-groupkeymgmt-oft-00.txt>
Errata ID: 3861
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Prashant Gupta
Date Reported: 2014-01-07
Held for Document Update by: Sean Turner
Date Held: 2014-01-20
Section 1 says:
Secure group and multicast applications require a method by which each group member shares common security policy and keying material. This document describes the Group Domain of Interpretation (GDOI), which is an Internet Security Association and Key Management Protocol (ISAMKP) [RFC2408] Domain of Interpretation (DOI), a group key management system.
It should say:
Secure group and multicast applications require a method by which each group member shares common security policy and keying material. This document describes the Group Domain of Interpretation (GDOI), which is an Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408] Domain of Interpretation (DOI), a group key management system.
Notes:
ISAMKP -> ISAKMP