Hi Tero, > > 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...
Noted, thanks. > > > 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. Yes, that was my intention too. Because we usually allocate new values in documents that define protocols, otherwise it looks strange - to allocate a value for the yet-to-be-defined protocol. Just in case. > 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). I think that this value can re-used later in document like draft-pan-ipsecme-anti-replay-notification. Regards, Valery. > -- > kivi...@iki.fi _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
