I'm fine with Section 3, bullet #1, with Valery's suggested change take/taking.
Thanks, Deb On Fri, Aug 8, 2025 at 11: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_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, [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-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, > > >>>>>> [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]
