I like it. Deb
On Wed, Aug 20, 2025 at 2:34 PM Sandy Ginoza <sgin...@staff.rfc-editor.org> wrote: > Hi Valery and Deb, > > We updated the text to use “in general”. It doesn’t hurt to emphasize the > point, but we also note the bullet just prior to this paragraph also > indicates that the properties are interpreted in a broad sense. > > Current: > > * The properties of sequence numbers are interpreted in a broad > sense, which includes the case when sequence numbers are absent. > > Given this updated definition, Transform Type 5 in the "Transform > Type Values" registry [IKEV2-IANA] has been renamed from "Extended > Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that > it defines the properties of the sequence numbers in general. > > > The current files are available here: > https://www.rfc-editor.org/authors/rfc9827.xml > https://www.rfc-editor.org/authors/rfc9827.txt > https://www.rfc-editor.org/authors/rfc9827.pdf > https://www.rfc-editor.org/authors/rfc9827.html > > Diffs of the most recent update only: > https://www.rfc-editor.org/authors/rfc9827-lastdiff.html > https://www.rfc-editor.org/authors/rfc9827-lastrfcdiff.html (side by > side) > > AUTH48 diffs: > https://www.rfc-editor.org/authors/rfc9827-auth48diff.html > https://www.rfc-editor.org/authors/rfc9827-auth48rfcdiff.html (side by > side) > > Comprehensive diffs: > https://www.rfc-editor.org/authors/rfc9827-diff.html > https://www.rfc-editor.org/authors/rfc9827-rfcdiff.html (side by side) > > > Please review and let us know if any further updates are needed or if you > approve the RFC for publication. > > Thank you, > > Sandy Ginoza > RFC Production Center > > > > > On Aug 18, 2025, at 3:49 AM, Valery Smyslov <s...@elvis.ru> wrote: > > > > Hi Deb, > > > > thank you for the help. Unless Sandy proposes something better, > > I think that changing to "in general" is acceptable. I'd rather keep > > these trailing words to remind that "properties" are interpreted > > rather broadly (e.g., they include the case when there is no sequence > numbers at all). > > > > Regards, > > Valery. > > > > From: Deb Cooley <debcool...@gmail.com> > > Sent: 18 августа 2025 г. 13:05 > > To: Valery Smyslov <s...@elvis.ru> > > Cc: Sandy Ginoza <sgin...@staff.rfc-editor.org>; RFC Editor < > rfc-edi...@rfc-editor.org>; ipsecme-...@ietf.org; ipsecme-cha...@ietf.org; > Tero Kivinen <kivi...@iki.fi>; auth48archive <auth48archive@rfc-editor.org > > > > Subject: [***SPAM***] [***SPAM***] Re: [***SPAM***] [***SPAM***] Re: > AUTH48: RFC-to-be 9827 <draft-ietf-ipsecme-ikev2-rename-esn-05> for your > review > > > > I agree it isn't ideal. I think we could just remove 'in a broad > sense'. Or change the last phrase to 'in general'. > > > > Deb > > > > On Mon, Aug 18, 2025 at 1:59 AM Valery Smyslov <s...@elvis.ru> wrote: > >> Hi Sandy, > >> > >> after re-reading the latest changes I realized that in the text I > proposed (Section 3): > >> > >> Given this updated definition, Transform Type 5 in the "Transform > >> Type Values" registry [IKEV2-IANA] has been renamed from "Extended > >> Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense that > >> it defines the properties of the sequence numbers in a broad sense. > >> > >> the word "sense" is used twice in a single sentence. In my native > language > >> (Russian) this is considered as a bad style and authors are > >> advised to avoid it whenever possible. I'm not so sure about English, > >> but if the rules are similar, then perhaps the text should be > re-phrased. > >> > >> I rely on your opinion whether the current text is acceptable from > style point of view. > >> If it is problematic, then perhaps you can advise how to avoid the > double use of "sense" here. > >> > >> Thank you. > >> > >> Regards, > >> Valery. > >> > >> > Hi Valery and Deb*, > >> > > >> > *Deb, thank you for your review. We have noted your approval on the > AUTH48 > >> > page <https://www.rfc-editor.org/auth48/rfc9827>. > >> > > >> > Valery, we have updated the document as described — thank you for > catching > >> > the typo! As we believe the content is stable, we will ask IANA to > update their > >> > registry notes to match the edited text in this document. > >> > > >> > Note that we have not yet marked your approval. We will check in for > a final > >> > approval once draft-ietf-ipsecme-g-ikev2 is also in AUTH48 and we have > >> > updated the reference. > >> > > >> > The current files are available here: > >> > https://www.rfc-editor.org/authors/rfc9827.txt > >> > https://www.rfc-editor.org/authors/rfc9827.pdf > >> > https://www.rfc-editor.org/authors/rfc9827.html > >> > https://www.rfc-editor.org/authors/rfc9827.xml > >> > > >> > Diffs of most recent updates only: > >> > https://www.rfc-editor.org/authors/rfc9827-lastdiff.html > >> > https://www.rfc-editor.org/authors/rfc9827-lastrfcdiff.html (side > by side) > >> > > >> > AUTH48 diffs: > >> > https://www.rfc-editor.org/authors/rfc9827-auth48diff.html > >> > https://www.rfc-editor.org/authors/rfc9827-auth48rfcdiff.html > (side by side) > >> > > >> > Comprehensive diffs: > >> > https://www.rfc-editor.org/authors/rfc9827-diff.html > >> > https://www.rfc-editor.org/authors/rfc9827-rfcdiff.html (side by > side) > >> > > >> > > >> > Please let us know if you have any questions or if any further > updates are > >> > needed. > >> > > >> > Thank you, > >> > Sandy Ginoza > >> > RFC Production Center > >> > > >> > > >> > > >> > > On Aug 8, 2025, at 8:19 AM, Valery Smyslov <s...@elvis.ru> wrote: > >> > > > >> > > Hi Sandy, > >> > > > >> > > please, see inline. > >> > > > >> > >> -----Original Message----- > >> > >> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >> > >> Sent: Friday, August 8, 2025 5:23 PM > >> > >> To: Valery Smyslov <s...@elvis.ru>; Deb Cooley < > debcool...@gmail.com> > >> > >> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; ipsecme-...@ietf.org; > >> > >> ipsecme- cha...@ietf.org; Tero Kivinen <kivi...@iki.fi>; > >> > >> auth48archive <auth48archive@rfc- editor.org> > >> > >> Subject: [***SPAM***] [***SPAM***] [AD - Deb] Re: AUTH48: RFC-to-be > >> > >> 9827 <draft-ietf-ipsecme-ikev2-rename-esn-05> for your review > >> > >> > >> > >> Hi Valery and Deb*, > >> > >> > >> > >> *Deb, please review the change to the first bullet in Section 3 and > >> > >> let us know if you approve. This update can be viewed in the > AUTH48 diff > >> > files (see below). > >> > >> > >> > >> Valery, thank you for your review and for the explanations you > >> > >> provided. The current files are available here: > >> > >> https://www.rfc-editor.org/authors/rfc9827.xml > >> > >> https://www.rfc-editor.org/authors/rfc9827.txt > >> > >> https://www.rfc-editor.org/authors/rfc9827.pdf > >> > >> https://www.rfc-editor.org/authors/rfc9827.html > >> > >> > >> > >> AUTH48 diffs (diffs since the document entered AUTH48): > >> > >> https://www.rfc-editor.org/authors/rfc9827-auth48diff.html > >> > >> https://www.rfc-editor.org/authors/rfc9827-auth48rfcdiff.html > (side > >> > >> by side) > >> > >> > >> > >> Comprehensive diffs: > >> > >> https://www.rfc-editor.org/authors/rfc9827-diff.html > >> > >> https://www.rfc-editor.org/authors/rfc9827-rfcdiff.html (side by > >> > >> side) > >> > >> > >> > >> > >> > >> A few notes: > >> > >> > >> > >> a) During IETF, we believe you mentioned double-checking potential > >> > >> changes for the IANA registries set up by the docs in > >> > >> https://www.rfc- editor.org/cluster_info.php?cid=C532. We believe > >> > >> the IANA-related text in this document aligns with the IANA > registry, > >> > >> but please review and let us know if any updates are needed. > >> > > > >> > > Yes, I double-checked the IANA-related text in the draft and the > text in the > >> > registry and they match. > >> > > The only difference I found is the use of "the" articles in the > notes, which I > >> > mentioned in item 7. > >> > > > >> > >> b) We have added a note to the AUTH48 page that this document > should > >> > >> be published together with draft-ietf-ipsecme-g-ikev2. The > reference > >> > >> will be updated once that document enters AUTH48. > >> > > > >> > > Got it, thank you. > >> > > > >> > >> c) Regarding item 5 below, please note that we did not make any > >> > >> updates, as we don’t think the “implied meaning” is needed based on > >> > >> your explanation. However, please let us know if you prefer the > NEW text > >> > you provided: > >> > >> > >> > >>> NEW: > >> > >>> Given this updated definition, Transform Type 5 in the "Transform > >> > >>> Type Values" registry [IKEV2-IANA] has been renamed from "Extended > >> > >>> Sequence Numbers (ESN)" to "Sequence Numbers (SN)" with the > implied > >> > >>> meaning, that it defines the properties of the sequence numbers > in a > >> > broad sense. > >> > >>> > >> > >>> Is it better with regard to readability? > >> > > > >> > > I still think that clarification is helpful. Perhaps: > >> > > > >> > > NEW: > >> > > Given this updated definition, Transform Type 5 in the "Transform > >> > > Type Values" registry [IKEV2-IANA] has been renamed from "Extended > >> > > Sequence Numbers (ESN)" to "Sequence Numbers (SN)" in the sense, > >> > > that it defines the properties of the sequence numbers in a broad > sense. > >> > > > >> > > The purpose of this clarification is to draw readers' attention, > that > >> > > while the new name is very similar to the old one (only the word > >> > > "Extended" is removed), the meaning is completely different - > >> > > previously this transform simply defined whether Extended Sequence > >> > > Numbers are on or off, and now it defines a set of sequence numbers > >> > properties, that cannot be reduced to a binary switch. > >> > > > >> > >> d) Regarding the updates related to item 7, we will ask IANA to > >> > >> update their registry once AUTH48 completes and we are certain the > text > >> > are stable. > >> > > > >> > > Thank you. > >> > > > >> > >> Please review and let us know if any additional updates are needed. > >> > > > >> > > The text in the first bullet of Section 3 is good, but I wonder if > >> > > this is not a typo: > >> > > > >> > > "Sequence numbers" in this definition are not necessarily the > >> > > content of the Sequence Number field in the IPsec packets; they > >> > > may also be some logical entities (e.g., counters) that could > be > >> > > constructed take some information that is not transmitted on > the > >> > > ^^^^^ > >> > > wire into account. > >> > > > >> > > I apologize in advance if this is not a typo and is grammatically > >> > > correct, but should not it be "taking" instead of "take". > >> > > > >> > > Regards, > >> > > Valery. > >> > > > >> > >> Thank you, > >> > >> RFC Editor/sg > >> > >> > >> > >> > >> > >> > >> > >>> On Aug 6, 2025, at 7:49 AM, Valery Smyslov <s...@elvis.ru> wrote: > >> > >>> > >> > >>> Hi Sandy, > >> > >>> > >> > >>> one more issue I came across. The title currently contains > incorrect > >> > >>> transform > >> > >> type name: > >> > >>> > >> > >>> OLD: > >> > >>> Renaming the Extended Sequence Number (ESN) Transform Type in the > >> > >>> Internet Key Exchange Protocol Version 2 (IKEv2) > >> > >>> > >> > >>> NEW: > >> > >>> Renaming the Extended Sequence Numbers (ESN) Transform Type in the > >> > >>> Internet Key Exchange Protocol Version 2 (IKEv2) > >> > >>> > >> > >>> Regards, > >> > >>> Valery. > >> > >>> > >> > >>>> -----Original Message----- > >> > >>>> From: Valery Smyslov <s...@elvis.ru> > >> > >>>> Sent: Wednesday, July 30, 2025 6:13 PM > >> > >>>> To: 'Sandy Ginoza' <sgin...@staff.rfc-editor.org> > >> > >>>> Cc: 'RFC Editor' <rfc-edi...@rfc-editor.org>; > >> > >>>> 'ipsecme-...@ietf.org' <ipsecme- a...@ietf.org>; > >> > >>>> 'ipsecme-cha...@ietf.org' <ipsecme-cha...@ietf.org>; ' > kivi...@iki.fi' > >> > <kivi...@iki.fi>; 'debcool...@gmail.com' > >> > >>>> <debcool...@gmail.com>; 'auth48archive@rfc-editor.org' > >> > >>>> <auth48archive@rfc- editor.org> > >> > >>>> Subject: RE: [***SPAM***] [***SPAM***] Re: AUTH48: RFC-to-be 9827 > >> > >>>> <draft- > >> > >> ietf- > >> > >>>> ipsecme-ikev2-rename-esn-05> for your review > >> > >>>> > >> > >>>> Hi Sandy, > >> > >>>> > >> > >>>> please find my answers inline. > >> > >>>> > >> > >>>> With regard to the publication process. I understand, that this > >> > >>>> draft and > >> > >>>> draft-ietf-ipsecme-g-ikev2-22 are parts of the C532 cluster, but > >> > >>>> since there is no normative reference of > >> > >>>> draft-ietf-ipsecme-g-ikev2-22 from this draft, then this draft > can be > >> > published before draft-ietf-ipsecme-g-ikev2-22. > >> > >>>> On the other hand, there is an informative reference from this > >> > >>>> draft to draft-ietf-ipsecme-g-ikev2-22 and I believe that for > >> > >>>> readers it is better if the target of this reference is RFC > rather than I-D. > >> > >>>> And since draft-ietf-ipsecme-g-ikev2-22 is about to enter active > >> > >>>> editing state and hopefully be ready to be published soon, I > think > >> > >>>> that it makes sense to delay publication of this draft so that > both > >> > >>>> drafts are > >> > >> published at > >> > >>>> the same time, > >> > >>>> and each of them reference the other as an RFC (and not as an > I-D). > >> > >>>> > >> > >>>>> Hi Valery, > >> > >>>>> > >> > >>>>> We understand about the timing — thank you for letting us know. > >> > >>>>> > >> > >>>>> Hope your travels were smooth! Perhaps we’ll see you next week. > >> > >>>>> > >> > >>>>> RFC Editor/sg > >> > >>>>> > >> > >>>>>> On Jul 17, 2025, at 1:23 AM, Valery Smyslov <s...@elvis.ru> > wrote: > >> > >>>>>> > >> > >>>>>> Hi Sandy, > >> > >>>>>> > >> > >>>>>> sorry for radio silence. I did receive the AUTH48 message, but > it > >> > >>>>>> came in bad > >> > >>>>> time :-) > >> > >>>>>> I was busy with preparations to IETF 123, then was on the way > to > >> > >>>>>> Madrid and thus had no time to review. I'm afraid I won't be > able > >> > >>>>>> to do this during > >> > >> IETF > >> > >>>>> week as well, sorry. > >> > >>>>>> Apologize for the delay, I plan to review the AUTH48 changes > >> > >>>>>> after IETF 123 > >> > >>>>> ends. > >> > >>>>>> > >> > >>>>>> Regards, > >> > >>>>>> Valery. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>>> -----Original Message----- > >> > >>>>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >> > >>>>>>> Sent: 17 июля 2025 г. 1:09 > >> > >>>>>>> To: RFC Editor <rfc-edi...@rfc-editor.org> > >> > >>>>>>> Cc: s...@elvis.ru; ipsecme-...@ietf.org; > >> > >>>>>>> ipsecme-cha...@ietf.org; kivi...@iki.fi; debcool...@gmail.com > ; > >> > >>>>>>> auth48archive@rfc-editor.org > >> > >>>>>>> Subject: [***SPAM***] Re: AUTH48: RFC-to-be 9827 > >> > >>>>>>> <draft-ietf-ipsecme- > >> > >>>>>>> ikev2-rename-esn-05> for your review > >> > >>>>>>> > >> > >>>>>>> Hi Valery, > >> > >>>>>>> > >> > >>>>>>> We do not believe we have heard from you regarding the > questions > >> > below. > >> > >>>>>>> Please review and let us know how the items below may be > resolved. > >> > >>>>>>> > >> > >>>>>>> Thank you, > >> > >>>>>>> RFC Editor/sg > >> > >>>>>>> > >> > >>>>>>>> On Jul 11, 2025, at 4:46 PM, rfc-edi...@rfc-editor.org > wrote: > >> > >>>>>>>> > >> > >>>>>>>> Authors, > >> > >>>>>>>> > >> > >>>>>>>> While reviewing this document during AUTH48, please resolve > (as > >> > >>>>>>>> necessary) the following questions, which are also in the > XML file. > >> > >>>>>>>> > >> > >>>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that > >> > >>>>>>>> appear in the title) for use on > https://www.rfc-editor.org/search. > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> replay protection > >> > >>>> anti-replay > >> > >>>> IPsec > >> > >>>> ESP > >> > >>>> AH > >> > >>>> > >> > >>>>>>>> 2) <!-- [rfced] Is the second paragraph the current > definition? > >> > >>>>>>>> The first paragraph makes us think the definition is current. > >> > >>>>>>>> However, the third paragraph (indicating it needs > >> > >>>>>>>> clarification) makes us think it is the old definition. > Please > >> > >>>>>>>> consider adding text to indicate whether it is the old or new > >> > definition. > >> > >>>>>>>> > >> > >>>>>>>> Original: > >> > >>>>>>>> 3. Extending the Semantics of Transform Type 5 > >> > >>>>>>>> > >> > >>>>>>>> This document extends the semantics of transform type 5 in > >> > >>>>>>>> IKEv2 to the following definition. > >> > >>>>>>>> > >> > >>>>>>>> Transform type 5 defines the set of properties of sequence > >> > >>>>>>>> numbers of IPsec packets of a given SA when these packets > enter > >> > the network. > >> > >>>>>>>> > >> > >>>>>>>> This definition requires some clarifications. > >> > >>>>>>>> > >> > >>>>>>>> Perhaps: > >> > >>>>>>>> 3. Extending the Semantics of Transform Type 5 > >> > >>>>>>>> > >> > >>>>>>>> This document extends the semantics of Transform Type 5 in > >> > >>>>>>>> IKEv2 to be defined as follows: > >> > >>>>>>>> > >> > >>>>>>>> Transform Type 5 defines the set of properties of sequence > >> > numbers > >> > >>>>>>>> of IPsec packets of a given SA when these packets enter the > >> > network. > >> > >>>>>>>> > >> > >>>>>>>> The updated definition is clarified as follows: > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> The second paragraph is the current (new) definition. > >> > >>>> Thus, the proposed text is clearer and I'm fine with it. > >> > >>>> > >> > >>>>>>>> 3) <!-- [rfced] We are having trouble parsing this sentence. > >> > >>>>>>>> Please provide an update if our suggested text is incorrect. > >> > >>>>>>>> > >> > >>>>>>>> Original: > >> > >>>>>>>> * By "sequence numbers" here we assume logical entities > (like > >> > >>>>>>>> counters) that can be used for replay protection on > receiving > >> > >>>>>>>> sides. In particular, these entities are not necessarily > the > >> > >>>>>>>> content of the Sequence Number field in the IPsec packets, > but > >> > may > >> > >>>>>>>> be constructed using some information, that is not > necessaryly > >> > >>>>>>>> transmitted. > >> > >>>>>>>> > >> > >>>>>>>> Perhaps: > >> > >>>>>>>> * The use of "sequence numbers" implies that logical > entities (like > >> > >>>>>>>> counters) can be used for replay protection on receiving > >> > >>>>>>>> sides. In particular, these entities are not necessarily > the > >> > >>>>>>>> content of the Sequence Number field in the IPsec packets, > as they > >> > >>>>>>>> may be constructed using some information that is not > >> > transmitted. > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> I would propose the following text: > >> > >>>> > >> > >>>> NEW: > >> > >>>> * "Sequence numbers" in this definition are not necessary the > >> > >>>> content of the Sequence Number field in the IPsec packets, > >> > >>>> but may also be some logical entities (e.g., counters) that > might > >> > >>>> be constructed taking in account some information that is not > >> > >>>> transmitted on > >> > >> the > >> > >>>> wire. > >> > >>>> > >> > >>>> Feel free to propose better text if this is still not clear or > grammatically > >> > incorrect. > >> > >>>> The point is that while we have "Sequence Number" field in the > >> > >>>> IPsec packets, the "sequence numbers" we are talking about are > not > >> > >>>> necessary the content of this field, but may be constructed using > >> > additional sources. > >> > >>>> > >> > >>>>>>>> 4) <!-- [rfced] We have updated this sentence as described > below. > >> > >>>>>>>> Please let us know if any corrections are needed. > >> > >>>>>>>> > >> > >>>>>>>> Original: > >> > >>>>>>>> * The properties are interpreted as a characteristic of > IPsec SA > >> > >>>>>>>> packets, and not as a result of a sender actions. > >> > >>>>>>>> > >> > >>>>>>>> Current: > >> > >>>>>>>> * The properties are interpreted as characteristics of > IPsec SA > >> > >>>>>>>> packets rather than the results of sender actions. > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> This change is OK. > >> > >>>> > >> > >>>>>>>> 5) <!-- [rfced] For readability, we have updated the sentence > >> > >>>>>>>> as shown below. Please let us know if any corrections are > >> > >>>>>>>> needed. In addition, please consider whether the abbreviated > >> > >>>>>>>> form of "SN" should be plural (i.e., Sequence Numbers (SNs) - > >> > >>>>>>>> we recognize that ESN was singular even though "Numbers" was > >> > plural). > >> > >>>>>>>> > >> > >>>>>>>> Original: > >> > >>>>>>>> Given this definition, transform type 5 in the IANA > registries > >> > >>>>>>>> for > >> > >>>>>>>> IKEv2 [IKEV2-IANA] is renamed from "Extended Sequence Numbers > >> > >>>> (ESN)" > >> > >>>>>>>> to "Sequence Numbers (SN)" with the meaning, that it defines > >> > >>>>>>>> the properties the sequence numbers would have. > >> > >>>>>>>> > >> > >>>>>>>> Current: > >> > >>>>>>>> Given this updated definition, Transform Type 5 in the > >> > >>>>>>>> "Transform Type Values" registry [IKEV2-IANA] has been > renamed > >> > >>>>>>>> from "Extended > >> > >>>> Sequence > >> > >>>>>>>> Numbers (ESN)" to "Sequence Numbers (SN)". > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> I still believe that the clarification is helpful. In other > words, > >> > >>>> the name of this Transform Type is too short to be absolutely > clear. > >> > >>>> Before IETF LC the proposed new name for this transform type was > >> > >>>> "Sequence Numbers Properties (SNP)", which would be clearer, but > >> > >>>> apparently was grammatically incorrect. Another proposed name was > >> > >>>> "Properties of Sequence Numbers (PSN)", but eventually it was > >> > >>>> decided to use simple "Sequence Numbers (SN)" with a > clarification > >> > >>>> what this name means. I also don't think that abbreviation in > >> > >>>> plural form (SNs) is justified, since this would break the rule > >> > >>>> that all abbreviation is always in all-capital letters. > >> > >>>> > >> > >>>> Thus, my preference is: > >> > >>>> > >> > >>>> NEW: > >> > >>>> Given this updated definition, Transform Type 5 in the "Transform > >> > >>>> Type Values" registry [IKEV2-IANA] has been renamed from > "Extended > >> > >>>> Sequence Numbers (ESN)" to "Sequence Numbers (SN)" with the > implied > >> > >>>> meaning, that it defines the properties of the sequence numbers > in a > >> > broad sense. > >> > >>>> > >> > >>>> Is it better with regard to readability? > >> > >>>> > >> > >>>>>>>> 6) <!-- [rfced] "their monotonic increase" is not easily > >> > >>>>>>>> parsed. May we update as follows for readability? > >> > >>>>>>>> Note that this text appears in the definitions for values 0 > and 1. > >> > >>>>>>>> > >> > >>>>>>>> Original: > >> > >>>>>>>> They can also be used with protocols that rely > >> > >>>>>>>> on sequence numbers uniqueness (like [RFC8750]) or their > >> > monotonic > >> > >>>>>>>> increase (like [RFC9347]). > >> > >>>>>>>> > >> > >>>>>>>> Perhaps: > >> > >>>>>>>> They can also be used with protocols that rely > >> > >>>>>>>> on sequence numbers uniqueness (e.g., [RFC8750]) or > >> > monotonically > >> > >>>>>>>> increasing sequence numbers (e.g., [RFC9347]). > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> This change is good. > >> > >>>> > >> > >>>>>>>> 7) <!-- [rfced] Note that we have updated the IANA > >> > >>>>>>>> Considerations to reduce redundancy throughout. Please > review > >> > >>>>>>>> carefully and let us know if any updates are needed. > >> > >>>>>>>> > >> > >>>>>>>> You can review the changes by looking through a diff of the > >> > >>>>>>>> IANA Considerations section: > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827-diff.html > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827-rfcdiff.html > >> > >>>>>>>> (side-by-side view) > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> These changes are generally OK. I noticed that the text of the > >> > >>>> notes in this section to be added to IANA registries now > mismatches > >> > >>>> the notes that are actually added as a result of IANA actions > made > >> > >>>> when this I-D was sent to the RFC Editor (with regard of the > >> > >>>> articles). I think that this can be sorted out with IANA. > >> > >>>> > >> > >>>>>>>> 8) <!-- [rfced] Throughout the text, the following > terminology > >> > >>>>>>>> appears to be used inconsistently. We updated to use the form > >> > >>>>>>>> on the left to align with RFC 7296. Please let us know any > >> > objections. > >> > >>>>>>>> > >> > >>>>>>>> Transform Type vs transform type Transform ID vs transform ID > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> I'm OK with this change, thank you. > >> > >>>> > >> > >>>>>>>> 9) <!-- [rfced] Please review the "Inclusive Language" > portion > >> > >>>>>>>> of the online Style Guide > >> > >>>>>>>> < > https://www.rfc-editor.org/styleguide/part2/#inclusive_languag > >> > >>>>>>>> e> and let us know if any changes are needed. Updates of > this > >> > >>>>>>>> nature typically result in more precise language, which is > >> > >>>>>>>> helpful for readers. > >> > >>>>>>>> > >> > >>>>>>>> Note that our script did not flag any words in particular, > but > >> > >>>>>>>> this should still be reviewed as a best practice. > >> > >>>>>>>> --> > >> > >>>> > >> > >>>> I re-read the draft and I believe that it satisfies the > "Inclusive Language" > >> > >>>> requirements. > >> > >>>> > >> > >>>> One more points I found. > >> > >>>> > >> > >>>> 10) [EESP] should reference draft-ietf-ipsecme-eesp instead of > >> > >>>> draft-klassert- ipsecme-eesp (it was adopted as WG document a > while > >> > >>>> ago). > >> > >>>> > >> > >>>> Regards, > >> > >>>> Valery. > >> > >>>> > >> > >>>>>>>> Thank you. > >> > >>>>>>>> > >> > >>>>>>>> RFC Editor > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> On Jul 11, 2025, at 4:43 PM, rfc-edi...@rfc-editor.org > wrote: > >> > >>>>>>>> > >> > >>>>>>>> *****IMPORTANT***** > >> > >>>>>>>> > >> > >>>>>>>> Updated 2025/07/11 > >> > >>>>>>>> > >> > >>>>>>>> RFC Author(s): > >> > >>>>>>>> -------------- > >> > >>>>>>>> > >> > >>>>>>>> Instructions for Completing AUTH48 > >> > >>>>>>>> > >> > >>>>>>>> Your document has now entered AUTH48. Once it has been > >> > >>>>>>>> reviewed > >> > >> and > >> > >>>>>>>> approved by you and all coauthors, it will be published as > an RFC. > >> > >>>>>>>> If an author is no longer available, there are several > remedies > >> > >>>>>>>> available as listed in the FAQ ( > https://www.rfc-editor.org/faq/). > >> > >>>>>>>> > >> > >>>>>>>> You and you coauthors are responsible for engaging other > >> > >>>>>>>> parties (e.g., Contributors or Working Group) as necessary > >> > >>>>>>>> before providing your approval. > >> > >>>>>>>> > >> > >>>>>>>> Planning your review > >> > >>>>>>>> --------------------- > >> > >>>>>>>> > >> > >>>>>>>> Please review the following aspects of your document: > >> > >>>>>>>> > >> > >>>>>>>> * RFC Editor questions > >> > >>>>>>>> > >> > >>>>>>>> Please review and resolve any questions raised by the RFC > >> > >>>>>>>> Editor that have been included in the XML file as comments > >> > >>>>>>>> marked as > >> > >>>>>>>> follows: > >> > >>>>>>>> > >> > >>>>>>>> <!-- [rfced] ... --> > >> > >>>>>>>> > >> > >>>>>>>> These questions will also be sent in a subsequent email. > >> > >>>>>>>> > >> > >>>>>>>> * Changes submitted by coauthors > >> > >>>>>>>> > >> > >>>>>>>> Please ensure that you review any changes submitted by your > >> > >>>>>>>> coauthors. We assume that if you do not speak up that you > >> > >>>>>>>> agree to changes submitted by your coauthors. > >> > >>>>>>>> > >> > >>>>>>>> * Content > >> > >>>>>>>> > >> > >>>>>>>> Please review the full content of the document, as this > cannot > >> > >>>>>>>> change once the RFC is published. Please pay particular > attention > >> > to: > >> > >>>>>>>> - IANA considerations updates (if applicable) > >> > >>>>>>>> - contact information > >> > >>>>>>>> - references > >> > >>>>>>>> > >> > >>>>>>>> * Copyright notices and legends > >> > >>>>>>>> > >> > >>>>>>>> Please review the copyright notice and legends as defined in > >> > >>>>>>>> RFC 5378 and the Trust Legal Provisions (TLP – > >> > >>>>>>>> https://trustee.ietf.org/license-info). > >> > >>>>>>>> > >> > >>>>>>>> * Semantic markup > >> > >>>>>>>> > >> > >>>>>>>> Please review the markup in the XML file to ensure that > >> > >>>>>>>> elements of content are correctly tagged. For example, > ensure > >> > >>>>>>>> that <sourcecode> and <artwork> are set correctly. See > details > >> > >>>>>>>> at <https://authors.ietf.org/rfcxml-vocabulary>. > >> > >>>>>>>> > >> > >>>>>>>> * Formatted output > >> > >>>>>>>> > >> > >>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the > >> > >>>>>>>> formatted output, as generated from the markup in the XML > file, > >> > >>>>>>>> is reasonable. Please note that the TXT will have formatting > >> > >>>>>>>> limitations compared to the PDF and HTML. > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> Submitting changes > >> > >>>>>>>> ------------------ > >> > >>>>>>>> > >> > >>>>>>>> To submit changes, please reply to this email using ‘REPLY > ALL’ > >> > >>>>>>>> as all the parties CCed on this message need to see your > >> > >>>>>>>> changes. The parties > >> > >>>>>>>> include: > >> > >>>>>>>> > >> > >>>>>>>> * your coauthors > >> > >>>>>>>> > >> > >>>>>>>> * rfc-edi...@rfc-editor.org (the RPC team) > >> > >>>>>>>> > >> > >>>>>>>> * other document participants, depending on the stream > (e.g., > >> > >>>>>>>> IETF Stream participants are your working group chairs, the > >> > >>>>>>>> responsible ADs, and the document shepherd). > >> > >>>>>>>> > >> > >>>>>>>> * auth48archive@rfc-editor.org, which is a new archival > mailing list > >> > >>>>>>>> to preserve AUTH48 conversations; it is not an active > discussion > >> > >>>>>>>> list: > >> > >>>>>>>> > >> > >>>>>>>> * More info: > >> > >>>>>>>> > >> > >>>>>>>> > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q > >> > >>>>>>>> 9l2USxI > >> > >>>>>>>> Ae6P8O4Zc > >> > >>>>>>>> > >> > >>>>>>>> * The archive itself: > >> > >>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >> > >>>>>>>> > >> > >>>>>>>> * Note: If only absolutely necessary, you may temporarily > opt out > >> > >>>>>>>> of the archiving of messages (e.g., to discuss a > sensitive matter). > >> > >>>>>>>> If needed, please add a note at the top of the message > that you > >> > >>>>>>>> have dropped the address. When the discussion is > concluded, > >> > >>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC > list and > >> > >>>>>>>> its addition will be noted at the top of the message. > >> > >>>>>>>> > >> > >>>>>>>> You may submit your changes in one of two ways: > >> > >>>>>>>> > >> > >>>>>>>> An update to the provided XML file — OR — An explicit list of > >> > >>>>>>>> changes in this format > >> > >>>>>>>> > >> > >>>>>>>> Section # (or indicate Global) > >> > >>>>>>>> > >> > >>>>>>>> OLD: > >> > >>>>>>>> old text > >> > >>>>>>>> > >> > >>>>>>>> NEW: > >> > >>>>>>>> new text > >> > >>>>>>>> > >> > >>>>>>>> You do not need to reply with both an updated XML file and an > >> > >>>>>>>> explicit list of changes, as either form is sufficient. > >> > >>>>>>>> > >> > >>>>>>>> We will ask a stream manager to review and approve any > changes > >> > >>>>>>>> that seem beyond editorial in nature, e.g., addition of new > >> > >>>>>>>> text, deletion of text, and technical changes. Information > >> > >>>>>>>> about stream managers can be found in the FAQ. Editorial > >> > >>>>>>>> changes do not require approval from a > >> > >>>>>>> stream manager. > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> Approving for publication > >> > >>>>>>>> -------------------------- > >> > >>>>>>>> > >> > >>>>>>>> To approve your RFC for publication, please reply to this > email > >> > >>>>>>>> stating that you approve this RFC for publication. Please > use > >> > >>>>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to > see your > >> > approval. > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> Files > >> > >>>>>>>> ----- > >> > >>>>>>>> > >> > >>>>>>>> The files are available here: > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827.xml > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827.html > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827.pdf > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827.txt > >> > >>>>>>>> > >> > >>>>>>>> Diff file of the text: > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827-diff.html > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827-rfcdiff.html > (side > >> > >>>>>>>> by > >> > >>>>>>>> side) > >> > >>>>>>>> > >> > >>>>>>>> Diff of the XML: > >> > >>>>>>>> https://www.rfc-editor.org/authors/rfc9827-xmldiff1.html > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> Tracking progress > >> > >>>>>>>> ----------------- > >> > >>>>>>>> > >> > >>>>>>>> The details of the AUTH48 status of your document are here: > >> > >>>>>>>> https://www.rfc-editor.org/auth48/rfc9827 > >> > >>>>>>>> > >> > >>>>>>>> Please let us know if you have any questions. > >> > >>>>>>>> > >> > >>>>>>>> Thank you for your cooperation, > >> > >>>>>>>> > >> > >>>>>>>> RFC Editor > >> > >>>>>>>> > >> > >>>>>>>> -------------------------------------- > >> > >>>>>>>> RFC 9827 (draft-ietf-ipsecme-ikev2-rename-esn-05) > >> > >>>>>>>> > >> > >>>>>>>> Title : Renaming Extended Sequence Number (ESN) > Transform > >> > >>>> Type > >> > >>>>> in > >> > >>>>>>> the Internet Key Exchange Protocol Version 2 (IKEv2) > >> > >>>>>>>> Author(s) : V. Smyslov > >> > >>>>>>>> WG Chair(s) : Yoav Nir, Tero Kivinen > >> > >>>>>>>> > >> > >>>>>>>> Area Director(s) : Deb Cooley, Paul Wouters > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>> > >> > >>> > >> > > > >> > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
