Valery Smyslov writes: > Some candidates: > > Sequence Number Properties (SNP) > Sequence Number Interpretation (SNI) (can be mixed up with SNI in TLS) > Sequence Number Features (SNF) > > Thoughts? Other proposals?
All of those works for me, just pick whatever you like. SNP sounds fine... > > I also noticed another point buried deep in the document: ARP > > value 2 MUST NOT be used with IIV (RFC 8750) for ESP, also on on > > simple ESP SA with G-IKEv2. > > > > When you create new document. Make it explicit. > > I don't think this should ever be mentioned in the document. As I > said, the document must not change the current semantics for the > transform type and for the two existing values. Thus, all the > restrictions for the use of this transform in the existing documents > will persist. And the document will add a note in the IANA page > notifying about the previous name of this transform, so that we > avoid updating all existing documents that reference it. If we keep the number 2 allocation in the g-ikev2, then I do not think we need to mention anything in this another draft about IIV etc, but if we mention that also in this draft, then I do think we need to specify meaning for this new value. I think proper thing would be to do renaming in this new draft, but do not fill in the value 2 in this draft, only rename registry and existing values. Then in the g-ikev2 add new value 2 to this renamed registry and then you can say that this value 2 is for g-ikev2 use... If someone really wants to use it in some other places they can write short rfc explaining full meaning of it (and no, I do not want to delay this document if someone wants to specify more meanings for sequence number properties values, they can make new draft and it still fits in "ESP enhancements" charter topic). -- kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
