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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
