Hi Valery, Thank you for your review - we have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9827>. As requested, we will coordinate publication with draft-ietf-ipsecme-g-ikev2, which should be entering AUTH48 shortly.
Thank you, Sandy Ginoza RFC Production Center > On Aug 21, 2025, at 12:42 AM, Valery Smyslov <[email protected]> wrote: > > Hi Sandy, > > I approve the publication. > > Thank you and Deb for the help and the patience. > > Regards, > Valery. > >> 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 <[email protected]> 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 <[email protected]> >>> Sent: 18 августа 2025 г. 13:05 >>> To: Valery Smyslov <[email protected]> >>> Cc: Sandy Ginoza <[email protected]>; RFC Editor <rfc-editor@rfc- >> editor.org>; [email protected]; [email protected]; Tero Kivinen >> <[email protected]>; auth48archive <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>> Hi Sandy, >>>>>> >>>>>> please, see inline. >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sandy Ginoza <[email protected]> >>>>>>> Sent: Friday, August 8, 2025 5:23 PM >>>>>>> To: Valery Smyslov <[email protected]>; Deb Cooley >> <[email protected]> >>>>>>> Cc: RFC Editor <[email protected]>; [email protected]; >>>>>>> ipsecme- [email protected]; Tero Kivinen <[email protected]>; >>>>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>>>> Sent: Wednesday, July 30, 2025 6:13 PM >>>>>>>>> To: 'Sandy Ginoza' <[email protected]> >>>>>>>>> Cc: 'RFC Editor' <[email protected]>; >>>>>>>>> '[email protected]' <ipsecme- [email protected]>; >>>>>>>>> '[email protected]' <[email protected]>; '[email protected]' >>>>> <[email protected]>; '[email protected]' >>>>>>>>> <[email protected]>; '[email protected]' >>>>>>>>> <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 <[email protected]> >> 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 <[email protected]> >>>>>>>>>>>> Sent: 17 июля 2025 г. 1:09 >>>>>>>>>>>> To: RFC Editor <[email protected]> >>>>>>>>>>>> Cc: [email protected]; [email protected]; >>>>>>>>>>>> [email protected]; [email protected]; [email protected]; >>>>>>>>>>>> [email protected] >>>>>>>>>>>> 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, [email protected] 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, [email protected] 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 >>>>>>>>>>>>> >>>>>>>>>>>>> * [email protected] (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). >>>>>>>>>>>>> >>>>>>>>>>>>> * [email protected], 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, >>>>>>>>>>>>> [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
