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
