Yoav Nir writes: > I don’t see anything wrong with the suggestion (it’s just adding “to indicate > NONE” in the last > sentence). However:
I think it is pointless change, and there is no need to give name for the number we use when we do not have protocol identifier, when it is used in exactly one place. All the text about the IKEv2 Security Protocol Identifiers is wrong. There is no reference to the IANA registry in the Protocol ID fields in the Notify or Delete payloads. Only section 3.3.1 Proposal Substructure refers to the that IANA registry. The sections 3.10 Notify Payload and 3.11 Delete Payload enumerate all possible numbers for Protocol IDs in place, and those registries do not have IANA registry associated with them. Note, that we had discussion about the Protocol ID field of the Notify payload during the RFC5996 update. I.e. the RFC4306 said that the protocol ID for notifications concerning IKE SA was set to 1, and zero was used if the notification didn't concern any SA. It also had text saying rest of the values are left for IANA to allocate. In the RFC5996 update, text about IANA was removed, as was the text about notifications concerning IKE SA, i.e., the only valid values (0, 2, 3) were enumerated in place. I.e., it is not the same IANA registry that is used for the Propsal substructure anymore. Section 7.8 of the RFC4718 explains some of the resons behind the change. > * A value marked “Reserved” in IANA just means that IANA should not assign > it. It does not mean > that it cannot appear in the protocol. > * Using a zero in a field to indicate no value is common, and IANA > registries are inconsistent > about whether such zero values are named or just reserved. > * Unless we want to change the IANA registry, there is no reason to > uppercase ‘none’ > * I don’t think we need to update the IANA registry. As this IANA registry is not used here, there is no need to change it. If we ever want to add new protocol ID to Notify or Delete payloads, we most likely need to crete new IANA registry for them. > “Hold for document update”? I think "rejected" would be better. > On 30 Jan 2018, at 23:50, RFC Errata System <rfc-edi...@rfc-editor.org> > wrote: > > The following errata report has been submitted for RFC7296, > "Internet Key Exchange Protocol Version 2 (IKEv2)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5247 > > -------------------------------------- > Type: Editorial > Reported by: Andrew Cagney <andrew.cag...@gmail.com> > > Section: 3.10. > > Original Text > ------------- > o Protocol ID (1 octet) - If this notification concerns an existing > SA whose SPI is given in the SPI field, this field indicates the > type of that SA. For notifications concerning Child SAs, this > field MUST contain either (2) to indicate AH or (3) to indicate > ESP. Of the notifications defined in this document, the SPI is > included only with INVALID_SELECTORS, REKEY_SA, and > CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be > sent as zero and MUST be ignored on receipt. > > Corrected Text > -------------- > o Protocol ID (1 octet) - If this notification concerns an existing > SA whose SPI is given in the SPI field, this field indicates the > type of that SA. For notifications concerning Child SAs, this > field MUST contain either (2) to indicate AH or (3) to indicate > ESP. Of the notifications defined in this document, the SPI is > included only with INVALID_SELECTORS, REKEY_SA, and > CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be > sent as zero to indicate NONE and MUST be ignored on receipt. > > Notes > ----- > If I assume that the 'Protocol ID' field in the notification payload is > specified by: > > Internet Key Exchange Version 2 (IKEv2) Parameters > IKEv2 Security Protocol Identifiers > > then a notification is using the 'Reserved' value 0. Since the value is > being used, > I think it would be better to give it a name. Other uses of 'Protocol > ID' don't need > updating as they all explicitly list allowed values, and in no case is 0 > allowed. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) > -------------------------------------- > Title : Internet Key Exchange Protocol Version 2 (IKEv2) > Publication Date : October 2014 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. > Kivinen > Category : INTERNET STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
