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. >>> --> >>> >>> >>> 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: >>> --> >>> >>> >>> 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. >>> --> >>> >>> >>> 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. >>> --> >>> >>> >>> 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)". >>> --> >>> >>> >>> 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]). >>> --> >>> >>> >>> 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) >>> --> >>> >>> >>> 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 >>> --> >>> >>> >>> 9) <!-- [rfced] Please review the "Inclusive Language" portion of the >>> online Style Guide >>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>> 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. >>> --> >>> >>> >>> 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-4Q9l2USxI >>> 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
