Re: [auth48] [AD] AUTH48: RFC-to-be 9333 <draft-ietf-lwig-minimal-esp-12> for your review

[Rebecca VanRheenen <[e-mail]>]

Hi Erik,

This is a friendly reminder that we need your approval before we move this document forward in the publication process. :

> *Erik, as AD, please review and approve the sentence added to the end of the Acknowledgments section (we ask for AD approval for all added text). This change is best viewed in one of the following diff files:
> 
> https://www.rfc-editor.org/authors/rfc9333-auth48diff.html (shows all changes made during AUTH48)
> https://www.rfc-editor.org/authors/rfc9333-alt-diff.html (shows all changes)

Thank you,
RFC Editor/rv



> On Nov 14, 2022, at 10:24 AM, Rebecca VanRheenen <[e-mail]> wrote:
> 
> Hi Daniel,
> 
> Thank you for confirming! We have noted your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9333).
> 
> We can move this document forward once we receive approval from Erik.
> 
> Thank you,
> RFC Editor
> 
> 
> 
>> On Nov 11, 2022, at 5:02 PM, Daniel Migault <[e-mail]> wrote:
>> 
>> Hi,
>> 
>> Looks fine to me. Thank you everyone for the follow-up.
>> 
>> Yours,
>> Daniel
>> 
>> ________________________________________
>> From: Rebecca VanRheenen <[e-mail]>
>> Sent: Friday, November 11, 2022 4:09 PM
>> To: Tobias Guggemos; Daniel Migault; [e-mail]; [e-mail]; [e-mail]
>> Cc: RFC Editor; [e-mail]; [e-mail]
>> Subject: [AD] Re: AUTH48: RFC-to-be 9333 <draft-ietf-lwig-minimal-esp-12> for your review
>> 
>> Hi Tobias, Daniel, and AD*,
>> 
>> Tobias, we have noted your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9333).
>> 
>> Daniel, please let us know if you also approve the document in its current form.
>> 
>> *Erik, as AD, please review and approve the sentence added to the end of the Acknowledgments section (we ask for AD approval for all added text). This change is best viewed in one of the following diff file:
>> 
>> https://www.rfc-editor.org/authors/rfc9333-auth48diff.html (shows all changes made during AUTH48)
>> https://www.rfc-editor.org/authors/rfc9333-alt-diff.html (shows all changes)
>> 
>> Thank you,
>> RFC Editor/rv
>> 
>> 
>> 
>>> On Nov 9, 2022, at 6:43 AM, Tobias Guggemos <[e-mail]> wrote:
>>> 
>>> Hey Rebecca, hey Daniel,
>>> For me, everything is fine!
>>> Thanks a lot!
>>> Tobias
>>> 
>>> -----Ursprüngliche Nachricht-----
>>> Von: Daniel Migault <[e-mail]>
>>> Gesendet: Dienstag, 8. November 2022 19:52
>>> An: Rebecca VanRheenen <[e-mail]>; [e-mail]
>>> Cc: RFC Editor <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>> Betreff: Re: AUTH48: RFC-to-be 9333 <draft-ietf-lwig-minimal-esp-12> for your review
>>> 
>>> Hi,
>>> 
>>> Please see my comments/responses in line.
>>> 
>>> Yours,
>>> Daniel
>>> ________________________________________
>>> From: Rebecca VanRheenen <[e-mail]>
>>> Sent: Tuesday, November 8, 2022 1:35 PM
>>> To: Daniel Migault; [e-mail]
>>> Cc: RFC Editor; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: AUTH48: RFC-to-be 9333 <draft-ietf-lwig-minimal-esp-12> for your review
>>> 
>>> Hi Daniel,
>>> 
>>> Thank you for responding to all of our questions. We have updated the document accordingly (see list of files below). We also have two followup questions:
>>> 
>>> 
>>>> 14) <!-- [rfced] Will readers know what "It" refers to here?
>>>> 
>>>> Original:
>>>> It could accept any SN as long as it is higher than the
>>>> previously received SN.
>>>> 
>>>> <mglt>
>>>> I think so, though this may be replaced by
>>>> 
>>>> NEW:
>>>> It could accept any SN as long as that received SN is higher than the
>>>> previously received SN.
>>>> 
>>>> </mglt>
>>>> -->
>>> 
>>> To clarify, we were wondering if the "It" at the beginning of the sentence will be clear to readers. We ask because the previous sentence does not appear to contain a clear antecedent for this pronoun. Would the following be an improvement? We will go with your choice here (i.e., retain original or update).
>>> 
>>> Perhaps:
>>> Receiving peers could accept any SN as long as it is higher than the
>>> previously received SN.
>>> 
>>> <mglt>
>>> ah Ok! ;-). The proposed change works for me.
>>> </mglt>
>>> 
>>> 
>>>> 23) <!-- [rfced] Some author comments are present in the XML. Please
>>>> confirm that no updates related to these comments are outstanding.
>>>> Note that the comments will be deleted prior to publication.
>>>> -->
>>>> 
>>>> <mglt>
>>>> Most of the comments are addressed by this email. There are additional comments but it remains unclear to me if these a text changed by the rfc editor or comments we left in the xml. That said, I have not seen anything that shocked me.
>>>> </mglt>
>>> 
>>> Apologies for any confusion! To clarify, below is a list of comments left in the xml file by the authors. May we delete these? Or do they still need to be addressed?
>>> 
>>> <mglt>
>>> sure!
>>> </mglt>
>>> 
>>> <!-- This document describes a minimal IP Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options to remain compatible with ESP as described in RFC 4303. ->
>>> 
>>> <!-- what is the spi / definition ->
>>> 
>>> <!-- Alternate designs that take less resources than fully random SPI's are likely using a limited list of possible SPIs.  This limit should take into account the number of inbound SAs - possibly per IP addresses - as well as the requirement for rekeying which would briefly require 2 inbound SPIs to co-exist as the new SA is setup before the old SA is torn down.-->
>>> 
>>> <!-- Note that standard receivers are generally configured with incrementing counters and, if not appropriately configured, the use of a significantly larger SN than the previous packet can result in that packet falling outside of the peer's receiver window which could cause that packet to be discarded. </t>
>>> 
>>> As a result, using time based SN should only be used when it is known that the remote peer supports this or when it is known that anti-replay windows are disabled.</t> ->
>>> 
>>> <!--
>>> Constrained devices running specific applications that would leak too much information by not generating and sending dummy packets could implement this functionality instead at the application layer.
>>> ->
>>> 
>>> __________________
>>> 
>>> Updated XML file:
>>> https://www.rfc-editor.org/authors/rfc9333.xml
>>> 
>>> Updated output files:
>>> https://www.rfc-editor.org/authors/rfc9333.txt
>>> https://www.rfc-editor.org/authors/rfc9333.pdf
>>> https://www.rfc-editor.org/authors/rfc9333.html
>>> 
>>> Diff file showing all changes made during AUTH48:
>>> https://www.rfc-editor.org/authors/rfc9333-auth48diff.html
>>> 
>>> Diff files showing all changes:
>>> https://www.rfc-editor.org/authors/rfc9333-diff.html
>>> https://www.rfc-editor.org/authors/rfc9333-rfcdiff.html (side-by-side diff)
>>> https://www.rfc-editor.org/authors/rfc9333-alt-diff.html (diff to see changes in moved/deleted text)
>>> 
>>> Note that it may be necessary for you to refresh your browser to view the most recent version.
>>> 
>>> Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. Contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9333
>>> 
>>> Thank you,
>>> 
>>> RFC Editor/rv
>>> 
>>> 
>>> 
>>> 
>>>> On Nov 4, 2022, at 1:24 PM, Daniel Migault <daniel.migault=[e-mail]> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Thank you for teh careful review and please find below my comments/repsonse.
>>>> 
>>>> Yours,
>>>> Daniel
>>>> 
>>>> ________________________________________
>>>> From: [e-mail] <[e-mail]>
>>>> Sent: Friday, November 4, 2022 2:47 PM
>>>> To: Daniel Migault; [e-mail]
>>>> Cc: [e-mail]; [e-mail];
>>>> [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]
>>>> Subject: Re: AUTH48: RFC-to-be 9333 <draft-ietf-lwig-minimal-esp-12>
>>>> for your review
>>>> 
>>>> 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] Are the bits needed in the titles of Sections 3, 4, and 6?
>>>> 
>>>> Current:
>>>> 3.  Security Parameter Index (SPI) (32 Bits)
>>>>  3.1.  Considerations over SPI Generation
>>>> 4.  Sequence Number (SN) (32 Bits)
>>>> 5.  Padding
>>>> 6.  Next Header (8 Bits) and Dummy Packets
>>>> 7.  ICV
>>>> 
>>>> Perhaps:
>>>> 3.  Security Parameters Index (SPI)
>>>>  3.1.  Considerations over SPI Generation
>>>> 4.  Sequence Number (SN)
>>>> 5.  Padding
>>>> 6.  Next Header and Dummy Packets
>>>> 7.  ICV
>>>> 
>>>> <mglt>
>>>> The bit length does not need to be present in the title. However this is a convention we have taken to specify the size in the title for fixed size fields. We can remove the length of the title and make sure the size is mentioned early in the section. This is the case here with the first sentence being:  "[RFC4303] defines the SPI as a mandatory 32-bit field."
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 3) <!-- [rfced] Please review "with [EHC-DIET-ESP] or [EHC-IKEv2]".
>>>> Should this text be updated in one of the following ways for clarity?
>>>> 
>>>> Current:
>>>> With the adoption of IPsec by Internet of Things (IoT)
>>>> devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
>>>> with [EHC-DIET-ESP] or [EHC-IKEv2], these ESP implementations MUST
>>>> remain interoperable with standard ESP implementations.
>>>> 
>>>> Perhaps:
>>>> With the adoption of IPsec by Internet of Things (IoT)
>>>> devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
>>>> [EHC-DIET-ESP] [EHC-IKEv2], these ESP implementations MUST
>>>> remain interoperable with standard ESP implementations.
>>>> 
>>>> <mglt>
>>>> The alternative above seems good to me.
>>>> 
>>>> NEW:
>>>> With the adoption of IPsec by Internet of Things (IoT)
>>>> devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
>>>> [EHC-DIET-ESP] [EHC-IKEv2], these ESP implementations MUST
>>>> remain interoperable with standard ESP implementations.
>>>> 
>>>> </mglt>
>>>> 
>>>> Or:
>>>> With the adoption of IPsec by Internet of Things (IoT)
>>>> devices with minimal IKEv2 [RFC7815] and ESP Header Compression (EHC)
>>>> with Diet-ESP [EHC-DIET-ESP] or Internet Key Exchange version 2 (IKEv2)
>>>> [EHC-IKEv2], these ESP implementations MUST
>>>> remain interoperable with standard ESP implementations.
>>>> -->
>>>> 
>>>> 
>>>> 4) <!-- [rfced] How may we clarify "also require to use the" here?
>>>> 
>>>> Original:
>>>> Nodes supporting multicast communications also require to use the IP
>>>> addresses and thus SA lookup need to be performed using the longest
>>>> match.
>>>> 
>>>> Perhaps:
>>>> Nodes supporting multicast communications are also required to use IP
>>>> addresses; thus, SA lookup needs to be performed using the longest
>>>> match.
>>>> 
>>>> Or:
>>>> Nodes supporting multicast communications also require the use of IP
>>>> addresses; thus, SA lookup needs to be performed using the longest
>>>> match.
>>>> <mglt>
>>>> This seems good to me:
>>>> 
>>>> NEW:
>>>> Nodes supporting multicast communications also require the use of IP
>>>> addresses; thus, SA lookup needs to be performed using the longest
>>>> match.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 5) <!-- [rfced] We are having trouble understanding how the text after
>>>> the dash relates to the rest of the sentence. Please clarify.
>>>> 
>>>> Original:
>>>> In addition, some of these constrained
>>>> devices are also likely to have a limited number of SAs - likely to
>>>> be indexed over 3 bytes only for example.
>>>> 
>>>> Perhaps:
>>>> In addition, some of these constrained
>>>> devices are likely to have a limited number of SAs; for example, they are likely to
>>>> only be indexed over 3 bytes.
>>>> 
>>>> <mglt>
>>>> 
>>>> The proposed text seems fine to us.
>>>> 
>>>> What we meant is that constrained devices - like a sensor - will use a very small number of SAs compared to a security gateway. As a result, thet sapce to index such SA can be significantly smaller. While the full range of indexes is 4 bytes, we can reasonably believe that sensor can deal with 3 bytes without any issue - or even less.
>>>> 
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 6) <!-- [rfced] What does "It" refer to in the second sentence below?
>>>> Should this read "they" or perhaps the two sentences could be combined?
>>>> 
>>>> Original:
>>>> Some specific values or
>>>> subset of SPI values could reveal the models or manufacturer of the
>>>> node implementing ESP.  It could also reveal some state such as "not
>>>> yet rekeyed" or "rekeyed 10 times".
>>>> 
>>>> Perhaps:
>>>> Some specific values or
>>>> subsets of SPI values could reveal the model or manufacturer of the
>>>> node implementing ESP or reveal a state such as "not
>>>> yet rekeyed" or "rekeyed 10 times".
>>>> 
>>>> <mglt>
>>>> This is what we meant.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 7) <!-- [rfced] Please review "a very limited". Is a word missing here?
>>>> 
>>>> Original:
>>>> If a constrained host uses a
>>>> very limited or even just one application, the SPI itself could
>>>> indicate what kind of traffic (eg the kind of application typically
>>>> running) is transmitted.
>>>> 
>>>> <mglt>
>>>> We meant a very limited number of applications  - eventually a single one. I propose the following wording.
>>>> 
>>>> OLD:
>>>> If a constrained host uses a
>>>> very limited or even just one application, the SPI itself could
>>>> indicate what kind of traffic (eg the kind of application typically
>>>> running) is transmitted.
>>>> 
>>>> NEW:
>>>> If a constrained host uses a
>>>> very limited number of applications, eventually a single one, the SPI itself could
>>>> indicate what kind of traffic (eg the kind of application typically
>>>> running) is transmitted.
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 8) <!-- [rfced] Is "correlated by" correct, or should this read
>>>> "correlated with"? Also, are both instances of "further" needed here?
>>>> 
>>>> Original:
>>>> This could be further correlated by
>>>> encrypted data size to further leak information to an observer on the
>>>> network.
>>>> 
>>>> Perhaps:
>>>> This could also be correlated with
>>>> encrypted data size to further leak information to an observer on the
>>>> network.
>>>> 
>>>> <mglt>
>>>> I suspect that correlated is used with 'with' and not 'by'. I am fine with the proposed wording.
>>>> </mglt>
>>>> 
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 9) <!-- [rfced] FYI - We updated "its" to "their" as the antecedent
>>>> seems to be the plural "sensors". Also, we updated "may not" to "do not".
>>>> 
>>>> Original:
>>>> Typically temperature sensors, wind sensors, used
>>>> outdoors may not leak privacy sensitive information and most of its
>>>> traffic is expected to be outbound traffic.
>>>> 
>>>> Updated:
>>>> Typically, temperature and wind sensors that
>>>> are used outdoors do not leak privacy-sensitive information, and
>>>> most of their traffic is expected to be outbound traffic.
>>>> 
>>>> <mglt>
>>>> I am fine with the wording.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 10) <!-- [rfced] We had trouble parsing this sentence. Please let us
>>>> know how we may update for clarity.
>>>> 
>>>> Original:
>>>> The RECOMMENDED way for multipurpose ESP implementation is to
>>>> increment a counter for each packet sent.
>>>> 
>>>> Perhaps:
>>>> It is RECOMMENDED that multipurpose ESP implementations increment a
>>>> counter for each packet sent.
>>>> 
>>>> <mglt>
>>>> This works for me.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 11) <!-- [rfced] Please clarify "requires to store any information" here.
>>>> 
>>>> Original:
>>>> This requires to store any information in a stable storage - such as
>>>> flash memory - that can be restored across sleeps.
>>>> 
>>>> Perhaps:
>>>> This requires devices to store any information in stable storage
>>>> that can be restored across sleeps (e.g., flash memory).
>>>> 
>>>> Or:
>>>> This requires any information to be stored in stable storage that
>>>> can be restored across sleeps (e.g., flash memory).
>>>> 
>>>> <mglt>
>>>> I think that both formulation work.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 12) <!-- [rfced] Is "property" the correct word choice here? Or would
>>>> "ability" or something else be better?
>>>> 
>>>> Original:
>>>> The size of the window should depend on the
>>>> property of the network to deliver packets out of order.
>>>> 
>>>> <mglt>
>>>> I am wondering is characteristic is not more appropriated.
>>>> 
>>>> NEW:
>>>> 
>>>> The size of the window should depend on the network characteristic to
>>>> deliver packets out of order.
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 13) <!-- [rfced] Will "is too much in the past" be clear to readers?
>>>> 
>>>> Original:
>>>> Typically, when the
>>>> sending peer is using SN based on time, anti-replay may be
>>>> implemented by discarding any packets that present a SN whose value
>>>> is too much in the past.
>>>> 
>>>> <mglt>
>>>> This seems to me clear.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 14) <!-- [rfced] Will readers know what "It" refers to here?
>>>> 
>>>> Original:
>>>> It could accept any SN as long as it is higher than the
>>>> previously received SN.
>>>> 
>>>> <mglt>
>>>> I think so, though this may be replaced by
>>>> 
>>>> NEW:
>>>> It could accept any SN as long as that received SN is higher than the
>>>> previously received SN.
>>>> 
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 15) <!-- [rfced] Please confirm that the pointer to "Section 10" is
>>>> correct here. We ask because we do not see "rekey" in Section 10.
>>>> 
>>>> Original:
>>>> Even for constrained devices, it is RECOMMENDED
>>>> to implement some rekey mechanisms (see Section 10).
>>>> 
>>>> <mglt>
>>>> This is correct - we use key management in section 10 which includes rekey.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 16) <!-- [rfced] Should "Data Payload" read "Payload Data" here to
>>>> match the field name in Figure 1?
>>>> 
>>>> Original:
>>>> This would typically be the case when the Data Payload is of fixed size.
>>>> 
>>>> <mglt>
>>>> Correct:
>>>> 
>>>> NEW:
>>>> This would typically be the case when the Payload Data is of fixed size.
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 17) <!-- [rfced] Please review "some application use". Should this
>>>> read "some applications"? Or is another meaning intended?
>>>> 
>>>> Original:
>>>> In addition, some
>>>> application use - such as health applications - could leak important
>>>> privacy oriented information.
>>>> 
>>>> Perhaps:
>>>> In addition, some
>>>> applications (such as health applications) could leak important
>>>> privacy oriented information.
>>>> 
>>>> 
>>>> <mglt>
>>>> The is correct.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 18) <!-- [rfced] Please review "authenticated encryption (AEAD)".
>>>> Should the complete expansion, i.e., "Authenticated Encryption with
>>>> Associated Data (AEAD)", be used?
>>>> 
>>>> Original:
>>>> ESP can be used to authenticate only
>>>> (ENCR_NULL) or to encrypt the communication.  In the latter case,
>>>> authenticated encryption (AEAD) is
>>>> RECOMMENDED [RFC8221].
>>>> 
>>>> Perhaps:
>>>> ESP can be used to authenticate only
>>>> (ENCR_NULL) or to encrypt the communication.  In the latter case,
>>>> Authenticated Encryption with Associated Data (AEAD) is
>>>> RECOMMENDED [RFC8221].
>>>> 
>>>> <mglt>
>>>> Seems better to me.
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 19) <!-- [rfced] Will it be clear to readers how the text after the
>>>> dash relates to the rest of the sentence? Also, is a unit of measure needed with "2"
>>>> (maybe "bits")?
>>>> 
>>>> Original:
>>>> 4.  Avoid Padding by sending payload data which are aligned to
>>>>     the cipher block length - 2 for the ESP trailer.
>>>> 
>>>> <mglt>
>>>> 
>>>> Adding the unit will be clearer. I propose the following text:
>>>> 
>>>> NEW:
>>>> 4.  Avoid Padding by sending payload data which are aligned to
>>>>     the cipher block length - 2 bytes for the ESP trailer.
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 20) <!-- [rfced] FYI, we have used the <sup> element for superscript
>>>> in this document. You can see how it looks in the last paragraph of Section 4.
>>>> 
>>>> Note: In the HTML and PDF, it appears as superscript.  In the text
>>>> output, <sup> generates a^b.  -->
>>>> 
>>>> 
>>>> 21) <!-- [rfced] Terminology
>>>> 
>>>> a) "Next Header" is capitalized in the document except in two
>>>> instances of "no next header". Should this read either "no Next Header"
>>>> or "No Next Header" or "no Next Header"? Or is the current okay as is?
>>>> 
>>>> <mglt>
>>>> RFC4303 mentions "no next header" so we believe that the current wording is ok.
>>>> </mglt>
>>>> 
>>>> b) FYI - We updated "Security Parameter Index" to read "Security
>>>> Parameters Index" per RFC 4303.
>>>> 
>>>> <mglt>
>>>> Thank you. That is what should have been written.
>>>> </mglt>
>>>> 
>>>> 
>>>> c) We note inconsistencies in the terms below throughout the text.
>>>> Should these be uniform? If so, please let us know which form is preferred.
>>>> 
>>>> minimal IKEv2 vs. Minimal IKEv2
>>>> 
>>>> minimal ESP vs. Minimal ESP
>>>> 
>>>> rekey mechanism vs. rekeying mechanism
>>>> 
>>>> <mglt>
>>>> 
>>>> It seems to me more consistent with RFC7815 to have:
>>>> 
>>>> minimal IKEv2 (from RFC7815)
>>>> minimal ESP (to mimic RFC7815)
>>>> rekeying mechanism may also be more consistent by I do not have a strong preference.
>>>> 
>>>> </mglt>
>>>> -->
>>>> 
>>>> 
>>>> 22) <!-- [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.
>>>> 
>>>> For example, please consider whether the following should be updated:
>>>> 
>>>> dummy
>>>> 
>>>> <mglt>
>>>> This is really taking the wording of 4303. I think that is better to keep it as it is. However if that needs to be changed, we shoudl mentioned this new designation is refered as "dummy" in RFC4303.
>>>> </mglt>
>>>> 
>>>> -->
>>>> 
>>>> 
>>>> 23) <!-- [rfced] Some author comments are present in the XML. Please
>>>> confirm that no updates related to these comments are outstanding.
>>>> Note that the comments will be deleted prior to publication.
>>>> -->
>>>> 
>>>> <mglt>
>>>> Most of the comments are addressed by this email. There are additional comments but it remains unclear to me if these a text changed by the rfc editor or comments we left in the xml. That said, I have not seen anything that shocked me.
>>>> </mglt>
>>>> Thank you.
>>>> 
>>>> RFC Editor/st/rv
>>>> 
>>>> 
>>>> 
>>>> On Nov 4, 2022, at 11:43 AM, [e-mail] wrote:
>>>> 
>>>> *****IMPORTANT*****
>>>> 
>>>> Updated 2022/11/04
>>>> 
>>>> 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
>>>> 
>>>> *  [e-mail] (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).
>>>> 
>>>> *  [e-mail], 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,
>>>>    [e-mail] 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/rfc9333.xml
>>>> https://www.rfc-editor.org/authors/rfc9333.html
>>>> https://www.rfc-editor.org/authors/rfc9333.pdf
>>>> https://www.rfc-editor.org/authors/rfc9333.txt
>>>> 
>>>> Diff file of the text:
>>>> https://www.rfc-editor.org/authors/rfc9333-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9333-rfcdiff.html (side by
>>>> side)
>>>> 
>>>> Alt-diff of the text (allows you to more easily view changes where
>>>> text has been deleted or moved):
>>>> https://www.rfc-editor.org/authors/rfc9333-alt-diff.html
>>>> 
>>>> Diff of the XML:
>>>> https://www.rfc-editor.org/authors/rfc9333-xmldiff1.html
>>>> 
>>>> The following files are provided to facilitate creation of your own
>>>> diff files of the XML.
>>>> 
>>>> Initial XMLv3 created using XMLv2 as input:
>>>> https://www.rfc-editor.org/authors/rfc9333.original.v2v3.xml
>>>> 
>>>> XMLv3 file that is a best effort to capture v3-related format updates
>>>> only:
>>>> https://www.rfc-editor.org/authors/rfc9333.form.xml
>>>> 
>>>> 
>>>> Tracking progress
>>>> -----------------
>>>> 
>>>> The details of the AUTH48 status of your document are here:
>>>> https://www.rfc-editor.org/auth48/rfc9333
>>>> 
>>>> Please let us know if you have any questions.
>>>> 
>>>> Thank you for your cooperation,
>>>> 
>>>> RFC Editor
>>>> 
>>>> --------------------------------------
>>>> RFC9333 (draft-ietf-lwig-minimal-esp-12)
>>>> 
>>>> Title            : Minimal IP Encapsulating Security Payload (ESP)
>>>> Author(s)        : D. Migault, T. Guggemos
>>>> WG Chair(s)      : Zhen Cao, Mohit Sethi
>>>> 
>>>> Area Director(s) : Erik Kline, Éric Vyncke
>>>> 
>>> 
>> 
>