Russ Housley writes: > I do not think that RFC 9370 changes are the same as the ones we are discussing here. > > The point has been raised to the Area Directors at this point. I > will accept whatever they consider best. I agree with you as a WG chair, and there were others in similar situation, and I think it is best to create another (very short) document that will do this change, and nothing else, and make it so it will catch up g-ikev2 before publication... > > Russ > > > > On Nov 29, 2024, at 2:08 PM, Valery Smyslov <smyslov.ietf@xxxxxxxxx> wrote: > > > > Hi Russ, > > > >> Valery: > >> > >> I react to one response now. I'll look at the rest later. > >> > >>>> IKEv2 implementers that have no need for group security associations > >>>> are not likely to read this document. For this reason, I think it is > >>>> unwise to include the updates to RFC 7296 here that: > >>>> > >>>> (1) Rename transform type 5 from "Extended Sequence Numbers (ESN)" to > >>>> "Anti-Replay Protection (ARP)"; and > >>>> > >>>> (2) Rename IKEv2 authentication method 0 from "Reserved" to "NONE". > >>> > >>> These actions don't change bits on the wire and the semantics of the > >>> currently defined values - implementers who only read RFC 7296 and > >> implement IKEv2 accordingly will get compliant implementations. > >> > >> You are missing my point. Some yet-to-be written RFC will use the new > >> terminology. That will confuse an implementer. It is a very small part of this > >> document, and I think it belongs in a more mainstream location for the IPsec > >> implementer. > > > > I believe I see your point. > > > > We have already passed this way with RFC 9370, which renamed some IKEv2 registries. > > One may argue that RFC 9370 is more kind of mainstream document, than this draft, > > but it is still not for every implementer (some may ignore PQ stuff). > > > > Thus, I don't believe this is a real problem, especially if IANA registry page will > > contain notes describing the fact of renaming, the old names and the document > > that caused it (as it was done with RFC 9370). > > > > If you think that I'm still missing your point, then may I ask you to exemplify > > the prospected scenario when a careful implementer would be confused. > > > > Regards, > > Valery. > > > >> Russ > >> > >> _______________________________________________ > >> IPsec mailing list -- ipsec@xxxxxxxx > >> To unsubscribe send an email to ipsec-leave@xxxxxxxx > > > > _______________________________________________ > IPsec mailing list -- ipsec@xxxxxxxx > To unsubscribe send an email to ipsec-leave@xxxxxxxx -- kivinen@xxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
