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_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.
> > >>> -->
>
> 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-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
