Re: [auth48] AUTH48: RFC-to-be 9378 <draft-ietf-ippm-ioam-deployment-05> for your review

[Sarah Tarrant <[e-mail]>]

Hi Daniel,

This is a friendly reminder that we await your review and approval prior to moving this document forward in the publication process.

The files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc9378.txt
 https://www.rfc-editor.org/authors/rfc9378.pdf
 https://www.rfc-editor.org/authors/rfc9378.html
 https://www.rfc-editor.org/authors/rfc9378.xml

The relevant diff files have been posted here (please refresh):
 https://www.rfc-editor.org/authors/rfc9378-diff.html (comprehensive diff)
 https://www.rfc-editor.org/authors/rfc9378-auth48diff.html (AUTH48 changes only)
 https://www.rfc-editor.org/authors/rfc9378-lastdiff.html (last to current version only)

The AUTH48 status page for this document is available here:
 https://www.rfc-editor.org/auth48/rfc9378

Thank you,
RFC Editor/st

> On Apr 13, 2023, at 11:19 AM, Sarah Tarrant <[e-mail]> wrote:
> 
> Hi Frank and Shwetha,
> 
> We have updated your statuses to “Approved” at https://www.rfc-editor.org/auth48/rfc9378. We will await approval from Daniel prior to moving this document forward in the publication process.
> 
> Thank you.
> 
> RFC Editor/st
> 
>> On Apr 13, 2023, at 1:53 AM, Shwetha Bhandari <[e-mail]> wrote:
>> 
>> Hi Sarah,
>> 
>> Thank for the edits, it looks good to me. I approve the changes as a co-author too.
>> 
>> Thanks
>> Shwetha
>> 
>> On Thu, 13 Apr 2023, 8:17 am Frank Brockners (fbrockne), <[e-mail]> wrote:
>> Hi Sarah,
>> 
>> Thanks for the changes. The document LGTM - I approve the doc as one of the authors.
>> 
>> Cheers, Frank
>> 
>>> -----Original Message-----
>>> From: Sarah Tarrant <[e-mail]>
>>> Sent: Wednesday, 12 April 2023 19:38
>>> To: Martin Duke <[e-mail]>
>>> Cc: Frank Brockners (fbrockne) <[e-mail]>; Tal Mizrahi
>>> <[e-mail]>; [e-mail];
>>> [e-mail]; [e-mail]; ippm-
>>> [e-mail]; [e-mail]; [e-mail]; auth48archive@rfc-
>>> editor.org
>>> Subject: Re: [AD] AUTH48: RFC-to-be 9378 <draft-ietf-ippm-ioam-deployment-
>>> 05> for your review
>>> 
>>> Hi Martin,
>>> 
>>> We have updated your status to “Approved” at https://urldefense.com/v3/__https://www.rfc-__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ic04jIKHQ$ 
>>> editor.org/auth48/rfc9378.
>>> 
>>> We will await approvals from the three remaining authors prior to moving this
>>> document forward in the publication process.
>>> 
>>> Thank you.
>>> 
>>> RFC Editor/st
>>> 
>>>> On Apr 12, 2023, at 10:56 AM, Martin Duke <[e-mail]>
>>> wrote:
>>>> 
>>>> Revised Sec 3 LGTM
>>>> 
>>>> On Wed, Apr 12, 2023 at 8:51 AM Sarah Tarrant <[e-mail]> wrote:
>>>> Hi Frank and *Martin,
>>>> 
>>>> [*Martin - just a reminder that we are requesting your review/approval
>>>> of the text added to Section 3 as highlighted in the following diff:
>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-auth48diff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie42ABwRw$ .]
>>>> 
>>>> Thank you for your reply and guidance. We have updated accordingly.
>>>> 
>>>> Please review the files carefully as we do not make changes after publication.
>>>> 
>>>> The files have been posted here (please refresh):
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.txt__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6if4NY2luQ$ 
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.pdf__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6icJu4AWbQ$ 
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6id1Xfzapg$ 
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.xml__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie_OoT5uQ$ 
>>>> 
>>>> The relevant diff files have been posted here (please refresh):
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-diff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6idAknQYQw$  (comprehensive diff)
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-auth48diff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie42ABwRw$  (AUTH48
>>> changes only)
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-lastdiff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6icDlde-ow$  (last to
>>>> current version only)
>>>> 
>>>> Please contact us with any further updates/questions/comments you may
>>> have.
>>>> 
>>>> We will await approvals from each of the parties listed on the AUTH48 status
>>> page prior to moving forward to publication.
>>>> 
>>>> The AUTH48 status page for this document is available here:
>>>>  https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9378__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ieZ3UiMwA$ 
>>>> 
>>>> Thank you.
>>>> 
>>>> RFC Editor/st
>>>> 
>>>>> On Apr 12, 2023, at 3:44 AM, Frank Brockners (fbrockne)
>>> <[e-mail]> wrote:
>>>>> 
>>>>> Hi Sarah,
>>>>> 
>>>>> Thanks for the updates. Please see inline.. ("..FB")
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Sarah Tarrant <[e-mail]>
>>>>>> Sent: Friday, 7 April 2023 17:00
>>>>>> To: Tal Mizrahi <[e-mail]>; Frank Brockners
>>>>>> (fbrockne) <[e-mail]>; [e-mail]
>>>>>> Cc: [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>> [e-mail]; [e-mail]
>>>>>> Subject: Re: [AD] AUTH48: RFC-to-be 9378
>>>>>> <draft-ietf-ippm-ioam-deployment-
>>>>>> 05> for your review
>>>>>> 
>>>>>> Hi Frank and Tal (and *Martin),
>>>>>> 
>>>>>> [*Martin - please review and approve the changes highlighted at the
>>>>>> beginning of Section 3 in the AUTH48 diff file below.]
>>>>>> 
>>>>>> Thank you for your replies and guidance.  We have marked Tal as
>>>>>> “approved" at the AUTH48 status page (see below).  We will assume
>>>>>> Tal’s assent to any further changes provided by the coauthors unless we
>>> hear otherwise at that time.
>>>>>> 
>>>>>> Please review the following further questions that arose while we
>>>>>> implemented the requested updates.  We will await your responses to
>>>>>> these questions prior to moving the document forward in the publication
>>> process.
>>>>>> 
>>>>>> 1) Regarding question 5, please let us know if any further updates
>>>>>> were necessary regarding point b or if you would like to keep the text as is.
>>>>> 
>>>>> ...FB: See below for a minor suggestion.
>>>>> 
>>>>>> 
>>>>>>>>> 5) <!-- [rfced] We had two questions related to the first two subpoints
>>>>>>>>>  in the list in Section 4:
>>>>>>>>> 
>>>>>>>>> a) To make the two nested points parallel, should the second
>>>>>>>>> point be rewritten
>>>>>>>>> ("Operations/Troubleshooting: Understand" updated to "With
>>>>>>>>> regard to operations and troubleshooting, understand...")?  Or
>>>>>>>>> should the first nested point have a similar introduction to the second?
>>>>>>>>> Please let us know if our suggestion below is a viable solution
>>>>>>>>> or if there is another way to rephrase.
>>>>>>>>> 
>>>>>>>>> b) Also, please clarify the two instances of "Understand".  Who
>>>>>>>>> is understanding the different paths?  Or is there another way
>>>>>>>>> to clarify
>>>>>> "Understand"?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>>   Potential uses of IOAM per-hop tracing include:
>>>>>>>>> 
>>>>>>>>>   -  Understand the different paths different packets traverse
>>>>>>>>>      between an IOAM encapsulating and an IOAM decapsulating node in
>>>>>>>>>      a network that uses load balancing such as Equal Cost Multi-
>>>>>>>>>      Path (ECMP).  This information could be used to tune the
>>>>>>>>>      algorithm for ECMP for optimized network resource usage.
>>>>>>>>> 
>>>>>>>>>   -  Operations/Troubleshooting: Understand which path a particular
>>>>>>>>>      packet or set of packets take as well as what amount of jitter
>>>>>>>>>      and delay different IOAM nodes in the path contribute to the
>>>>>>>>>      overall delay and jitter between the IOAM encapsulating node
>>>>>>>>>      and the IOAM decapsulating node.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>>   Potential uses of IOAM per-hop tracing include:
>>>>>>>>> 
>>>>>>>>>   -  Understanding the different paths different packets traverse
>>>>>>>>>      between an IOAM encapsulating and an IOAM decapsulating node in
>>>>>>>>>      a network that uses load-balancing such as Equal Cost Multi-
>>>>>>>>>      Path (ECMP).  This information could be used to tune the
>>>>>>>>>      algorithm for ECMP for optimized network resource usage.
>>>>>>>>> 
>>>>>>>>>   -  With regard to operations and troubleshooting, understanding
>>> which
>>>>>>>>>      path a particular packet or set of packets take as well as what
>>>>>>>>>    amount of jitter and delay different IOAM nodes in the path
>>>>>>>>>    contribute to the overall delay and jitter between the IOAM
>>>>>>>>>    encapsulating node and the IOAM decapsulating node.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: I like your proposal.
>>>>> 
>>>>> ...FB: IMHO it would be good to mention "IOAM encapsulating node" in the
>>> sentence below, rather than just "IOAM encapsulating". But this is just my
>>> "feeling" as a non-native English speaker.
>>>>> 
>>>>> CURRENT:
>>>>>     *  Understanding the different paths that different packets
>>>>>        traverse between an IOAM encapsulating and an IOAM
>>>>>        decapsulating node in a network that uses load balancing, such
>>>>>        as Equal Cost Multi-Path (ECMP).  This information could be
>>>>>        used to tune the algorithm for ECMP for optimized network
>>>>>        resource usage.
>>>>> 
>>>>> NEW:
>>>>>     *  Understanding the different paths that different packets
>>>>>        traverse between an IOAM encapsulating node and an IOAM
>>>>>        decapsulating node in a network that uses load balancing, such
>>>>>        as Equal Cost Multi-Path (ECMP).  This information could be
>>>>>        used to tune the algorithm for ECMP for optimized network
>>>>>        resource usage.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 2) Regarding question 6, where Frank wrote:
>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>> *  Generic data, that is format-free information, where the syntax and
>>>>>>>>    semantics of the information are defined by the operator in a specific
>>>>>>>>    deployment.
>>>>>> 
>>>>>> please note that we further updated to use “Generic data, which is
>>>>>> format-free information, where…” as we assume the intention is to
>>>>>> give further information on the generic data (not to contrast it with generic
>>> data that is not format-free).
>>>>>> Please let us know any objections.
>>>>> 
>>>>> ...FB: ACK. The change to "which" makes sense.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 3) When making terminology updates, we wanted to clarify the following:
>>>>>> 
>>>>>> a) Please confirm that the “Perhaps” text below is an *example* of
>>>>>> a desired update (similar text occurs elsewhere).
>>>>>> 
>>>>>> Original:
>>>>>> The incremental IOAM-Trace-Option-Type eliminates the need for the
>>>>>> IOAM transit nodes to read the full array in the Trace-Option-Type
>>>>>> and allows packets to grow to the size of the MTU of the IOAM domain.
>>>>>> 
>>>>>> Current:
>>>>>> The incremental IOAM Trace
>>>>>> Option-Type eliminates the need for the IOAM transit nodes to read
>>>>>> the full array in the Trace Option-Type and allows packets to grow
>>>>>> to the size of the MTU of the IOAM-Domain.
>>>>>> 
>>>>>> Perhaps:
>>>>>> The IOAM Incremental Trace
>>>>>> Option-Type eliminates the need for the IOAM transit nodes to read
>>>>>> the full array in the Trace Option-Type and allows packets to grow
>>>>>> to the size of the MTU of the IOAM-Domain.
>>>>> 
>>>>> ...FB: Agreed. Your suggestion is more accurate.
>>>>> 
>>>>>> 
>>>>>> b) We were uncertain about the updates to “Active flag” per the
>>>>>> author
>>>>>> response:
>>>>>> 
>>>>>>> Original:
>>>>>>> IOAM active mode flag
>>>>>>> Active flag
>>>>>>> 
>>>>>>> Perhaps:
>>>>>>> Active flag (per RFC 9322)
>>>>>> 
>>>>>> ...FB: Agreed.
>>>>>> 
>>>>>>> 
>>>>>>> See also IOAM Active Mode.
>>>>>> 
>>>>>> 
>>>>>> Should the title of Section 7.6 be updated as follows?
>>>>>> 
>>>>>> Current:
>>>>>> IOAM Active Mode
>>>>>> 
>>>>>> Perhaps:
>>>>>> Active Flag
>>>>> 
>>>>> ...FB: Agreed. Keeping things consistent with RFC 9322 is appreciated.
>>>>> 
>>>>> ...FB: In order to keep things consistent in the document, IMHO it
>>>>> would make sense to also change4
>>>>> 
>>>>> CURRENT:
>>>>> 
>>>>> 7.5.  IOAM Loopback
>>>>> 
>>>>> NEW:
>>>>> 
>>>>> 7.5.  Loopback flag
>>>>> 
>>>>>> 
>>>>>> See also:
>>>>>> 
>>>>>> Current:
>>>>>> Example use cases for IOAM Active Mode include:
>>>>>> 
>>>>>> Perhaps:
>>>>>> Example use cases for the Active flag include:
>>>>> 
>>>>> ...FB: Agreed.
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> We have updated the document with all the other changes as
>>>>>> requested.  Please review these updates carefully as we do not make
>>>>>> changes once the document is published as an RFC.  We will
>>>>>> approvals from each coauthor prior to moving the document forward in the
>>> publication process.
>>>>> 
>>>>> 
>>>>> ...FB: When reading through the document, I found another minor
>>> inconsistency in language in section 10 ("Direct Exporting mode" vs. "Direct
>>> Exporting"). IMHO it would be good to avoid "mode" here as well and just refer
>>> to "Direct Exporting"
>>>>> 
>>>>> CURRENT:
>>>>> 
>>>>>  IOAM data can be subject to eavesdropping.  Although the
>>>>>  confidentiality of the user data is not at risk in this context, the
>>>>>  IOAM data elements can be used for network reconnaissance, allowing
>>>>>  attackers to collect information about network paths, performance,
>>>>>  queue states, buffer occupancy, and other information.  Recon is an
>>>>>  improbable security threat in an IOAM deployment that is within a
>>>>>  confined physical domain.  However, in deployments that are not
>>>>>  confined to a single LAN but span multiple interconnected sites (for
>>>>>  example, using an overlay network), the inter-site links are expected
>>>>>  to be secured (e.g., by IPsec) in order to avoid external
>>>>>  eavesdropping and introduction of malicious or false data.  Another
>>>>>  possible mitigation approach is to use the "Direct Exporting" mode
>>>>>  [RFC9326].  In this case, the IOAM-related trace information would
>>>>>  not be available in the customer data packets but would trigger the
>>>>>  exporting of (secured) packet-related IOAM information at every node.
>>>>>  IOAM data export and securing IOAM data export is outside the scope
>>>>>  of this document.
>>>>> 
>>>>> [...]
>>>>> 
>>>>>  Notably, IOAM is expected to be deployed in limited network domains
>>>>>  [RFC8799], thus, confining the potential attack vectors within the
>>>>>  limited domain.  Indeed, in order to limit the scope of threats
>>>>>  within the current network domain, the network operator is expected
>>>>>  to enforce policies that prevent IOAM traffic from leaking outside
>>>>>  the IOAM-Domain and prevent an attacker from introducing malicious or
>>>>>  false IOAM data to be processed and used within the IOAM-Domain.
>>>>>  IOAM data leakage could lead to privacy issues.  Consider an IOAM
>>>>>  encapsulating node that is a home gateway in an operator's network.
>>>>>  A home gateway is often identified with an individual.  Revealing
>>>>>  IOAM data, such as "IOAM node identifier" or geolocation information
>>>>>  outside of the limited domain, could be harmful for that user.  Note
>>>>>  that the Direct Exporting mode [RFC9326] can mitigate the potential
>>>>>  threat of IOAM data leaking through data packets.
>>>>> 
>>>>> NEW:
>>>>>  IOAM data can be subject to eavesdropping.  Although the
>>>>>  confidentiality of the user data is not at risk in this context, the
>>>>>  IOAM data elements can be used for network reconnaissance, allowing
>>>>>  attackers to collect information about network paths, performance,
>>>>>  queue states, buffer occupancy, and other information.  Recon is an
>>>>>  improbable security threat in an IOAM deployment that is within a
>>>>>  confined physical domain.  However, in deployments that are not
>>>>>  confined to a single LAN but span multiple interconnected sites (for
>>>>>  example, using an overlay network), the inter-site links are expected
>>>>>  to be secured (e.g., by IPsec) in order to avoid external
>>>>>  eavesdropping and introduction of malicious or false data.  Another
>>>>>  possible mitigation approach is to use "Direct Exporting"
>>>>>  [RFC9326].  In this case, the IOAM-related trace information would
>>>>>  not be available in the customer data packets but would trigger the
>>>>>  exporting of (secured) packet-related IOAM information at every node.
>>>>>  IOAM data export and securing IOAM data export is outside the scope
>>>>>  of this document.
>>>>> 
>>>>> [...]
>>>>> 
>>>>>  Notably, IOAM is expected to be deployed in limited network domains
>>>>>  [RFC8799], thus, confining the potential attack vectors within the
>>>>>  limited domain.  Indeed, in order to limit the scope of threats
>>>>>  within the current network domain, the network operator is expected
>>>>>  to enforce policies that prevent IOAM traffic from leaking outside
>>>>>  the IOAM-Domain and prevent an attacker from introducing malicious or
>>>>>  false IOAM data to be processed and used within the IOAM-Domain.
>>>>>  IOAM data leakage could lead to privacy issues.  Consider an IOAM
>>>>>  encapsulating node that is a home gateway in an operator's network.
>>>>>  A home gateway is often identified with an individual.  Revealing
>>>>>  IOAM data, such as "IOAM node identifier" or geolocation information
>>>>>  outside of the limited domain, could be harmful for that user.  Note
>>>>>  that Direct Exporting [RFC9326] can mitigate the potential
>>>>>  threat of IOAM data leaking through data packets.
>>>>> 
>>>>> Cheers, Frank
>>>>> 
>>>>> 
>>>>>> 
>>>>>> The files have been posted here (please refresh):
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.txt__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6if4NY2luQ$ 
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.pdf__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6icJu4AWbQ$ 
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6id1Xfzapg$ 
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.xml__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie_OoT5uQ$ 
>>>>>> 
>>>>>> The relevant diff files have been posted here (please refresh):
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-diff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6idAknQYQw$  (comprehensive
>>>>>> diff) https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-rfcdiff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ic-AN-pqw$ 
>>>>>> (comprehensive
>>>>>> rfcdiff)
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-auth48diff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie42ABwRw$  (AUTH48
>>>>>> changes only)
>>>>>> 
>>>>>> The AUTH48 status page is viewable at:
>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9378__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ieZ3UiMwA$ 
>>>>>> 
>>>>>> Thank you.
>>>>>> 
>>>>>> RFC Editor/st
>>>>>>> On Apr 5, 2023, at 9:02 AM, Tal Mizrahi <[e-mail]>
>>> wrote:
>>>>>>> 
>>>>>>> Dear RFC Editorial Team,
>>>>>>> 
>>>>>>> I agree with Frank's comments.
>>>>>>> I approve.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Tal.
>>>>>>> 
>>>>>>> On Tue, Apr 4, 2023 at 9:26 PM Frank Brockners (fbrockne)
>>>>>>> <[e-mail]> wrote:
>>>>>>>> 
>>>>>>>> Dear Sarah, RFC-Editor team,
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: [e-mail] <[e-mail]>
>>>>>>>>> Sent: Monday, 27 March 2023 23:14
>>>>>>>>> To: Frank Brockners (fbrockne) <[e-mail]>;
>>>>>>>>> [e-mail]; [e-mail];
>>>>>>>>> [e-mail]
>>>>>>>>> Cc: [e-mail]; [e-mail];
>>>>>>>>> [e-mail]; [e-mail]; [e-mail];
>>>>>>>>> [e-mail]
>>>>>>>>> Subject: Re: AUTH48: RFC-to-be 9378
>>>>>>>>> <draft-ietf-ippm-ioam-deployment-05>
>>>>>>>>> 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 note that the title of the document has
>>>>>>>>> been updated as follows to more similarly match related recently
>>> published RFCs.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> In-situ OAM Deployment
>>>>>>>>> 
>>>>>>>>> Current:
>>>>>>>>> In Situ Operations, Administration, and Maintenance (IOAM)
>>>>>>>>> Deployment
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: ACK.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 2) <!-- [rfced] We suggest updating the following text for the ease of
>>>>>>>>>   the reader.  Please let us know any objections.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> IOAM mechanisms can be
>>>>>>>>> leveraged where mechanisms using e.g., ICMP do not apply or do
>>>>>>>>> not  offer the desired results, such as proving that a certain
>>>>>>>>> traffic  flow takes a pre-defined path, SLA verification for the
>>>>>>>>> live data  traffic, detailed statistics on traffic distribution
>>>>>>>>> paths in  networks that distribute traffic across multiple
>>>>>>>>> paths, or scenarios  in which probe traffic is potentially
>>>>>>>>> handled differently from  regular data traffic by the network devices.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> IOAM mechanisms can be
>>>>>>>>> leveraged where mechanisms using, e.g., ICMP do not apply or do
>>>>>>>>> not  offer the desired results. These results could include:
>>>>>>>>> 
>>>>>>>>>     * proving that a certain traffic flow takes a predefined
>>>>>>>>> path,
>>>>>>>>> 
>>>>>>>>>     * verifying the Service Level Agreement (SLA) for the live data
>>>>>>>>>       traffic,
>>>>>>>>> 
>>>>>>>>>     * providing detailed statistics on traffic distribution paths in
>>>>>>>>>       networks that distribute traffic across multiple paths,
>>>>>>>>> or
>>>>>>>>> 
>>>>>>>>>     * providing scenarios in which probe traffic is potentially
>>>>>>>>>       handled differently from regular data traffic by the network
>>>>>>>>>       devices.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: Making this long winded sentence more readable is very
>>>>>>>> worthwhile. In
>>>>>> your proposal, the term "result" could be misunderstood though.
>>>>>>>> How about the following:
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>> IOAM mechanisms can be leveraged in situations where mechanisms
>>>>>>>> using, e.g., ICMP does not apply or does not offer the desired
>>>>>>>> results. These situations could include:
>>>>>>>> 
>>>>>>>>      * proving that a certain traffic flow takes a predefined
>>>>>>>> path,
>>>>>>>> 
>>>>>>>>     * verifying the Service Level Agreement (SLA) for the live data
>>>>>>>>        traffic,
>>>>>>>> 
>>>>>>>>     * providing detailed statistics on traffic distribution paths in
>>>>>>>>       networks that distribute traffic across multiple paths, or
>>>>>>>> 
>>>>>>>>      * providing scenarios in which probe traffic is potentially
>>>>>>>>        handled differently from regular data traffic by the network
>>>>>>>>        devices.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 3) <!--[rfced] We note a lot of similarities in the text of
>>>>>>>>> Section
>>>>>>>>> 3 with the text that appears in Section 4.2 of RFC 9197.
>>>>>>>>> However, there is no citation to that document in Section 3.
>>>>>>>>> Please review and let us know if a citation should be added, any
>>>>>>>>> text should be updated, or if the reader should simply be
>>>>>>>>> pointed to Section 4.2 of RFC 9197 for certain info.-->
>>>>>>>> 
>>>>>>>> ...FB: Good point. Given that (a) the deployment document is a
>>>>>>>> bit more
>>>>>> recent than RFC 9197, (b) a partial repeat of definitions helps the
>>>>>> reader and (c) the IESG had comments and text suggestions on the
>>>>>> section which led to revised text, IMHO it would be better to keep the
>>> section in place rather than remove it.
>>>>>> That said, what would make sense is to add a paragraph up front
>>>>>> which states the reference to RFC 9197.  E.g.
>>>>>>>> 
>>>>>>>> OLD:
>>>>>>>> 
>>>>>>>> 3.  IOAM Deployment: Domains And Nodes
>>>>>>>> 
>>>>>>>> IOAM is focused on "limited domains" as defined in [RFC8799].
>>>>>>>> IOAM  is not targeted for a deployment on the global Internet. ...
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>> 3.  IOAM Deployment: Domains And Nodes
>>>>>>>> 
>>>>>>>> RFC 9197 defines the scope of IOAM as well as the different
>>>>>>>> types of IOAM nodes. For improved readability, this section
>>>>>>>> provides a brief overview of where IOAM applies,  along with
>>>>>>>> explaining the main roles of nodes that employ IOAM.
>>>>>>>> Please refer to RFC 9197 for further details.
>>>>>>>> 
>>>>>>>> IOAM is focused on "limited domains" as defined in [RFC8799].
>>>>>>>> IOAM  is not targeted for a deployment on the global Internet. ...
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 4) <!-- [rfced] Does this instance of "/" indicate "and" or "or"?
>>>>>>>>> Please let us know how we may update for clarity.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> For example, an IOAM-domain can include an enterprise campus
>>>>>>>>> using  physical connections between devices or an overlay
>>>>>>>>> network using  virtual connections / tunnels for connectivity between
>>> said devices.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> a)
>>>>>>>>> For example, an IOAM-Domain can include an enterprise campus
>>>>>>>>> using  physical connections between devices or an overlay
>>>>>>>>> network using  virtual connections and tunnels for connectivity between
>>> said devices.
>>>>>>>>> 
>>>>>>>>> b)
>>>>>>>>> For example, an IOAM-Domain can include an enterprise campus
>>>>>>>>> using  physical connections between devices or an overlay
>>>>>>>>> network using  virtual connections or tunnels for connectivity between
>>> said devices.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: It is option b). I.e.,
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>>  For example, an IOAM-Domain can include an enterprise campus using
>>>>>>>>  physical connections between devices or an overlay network using
>>>>>>>>  virtual connections or tunnels for connectivity between said devices.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 5) <!-- [rfced] We had two questions related to the first two subpoints
>>>>>>>>>   in the list in Section 4:
>>>>>>>>> 
>>>>>>>>> a) To make the two nested points parallel, should the second
>>>>>>>>> point be rewritten
>>>>>>>>> ("Operations/Troubleshooting: Understand" updated to "With
>>>>>>>>> regard to operations and troubleshooting, understand...")?  Or
>>>>>>>>> should the first nested point have a similar introduction to the second?
>>>>>>>>> Please let us know if our suggestion below is a viable solution
>>>>>>>>> or if there is another way to rephrase.
>>>>>>>>> 
>>>>>>>>> b) Also, please clarify the two instances of "Understand".  Who
>>>>>>>>> is understanding the different paths?  Or is there another way
>>>>>>>>> to clarify
>>>>>> "Understand"?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>>    Potential uses of IOAM per-hop tracing include:
>>>>>>>>> 
>>>>>>>>>    -  Understand the different paths different packets traverse
>>>>>>>>>       between an IOAM encapsulating and an IOAM decapsulating node
>>> in
>>>>>>>>>       a network that uses load balancing such as Equal Cost Multi-
>>>>>>>>>       Path (ECMP).  This information could be used to tune the
>>>>>>>>>       algorithm for ECMP for optimized network resource usage.
>>>>>>>>> 
>>>>>>>>>    -  Operations/Troubleshooting: Understand which path a particular
>>>>>>>>>       packet or set of packets take as well as what amount of jitter
>>>>>>>>>       and delay different IOAM nodes in the path contribute to the
>>>>>>>>>       overall delay and jitter between the IOAM encapsulating node
>>>>>>>>>       and the IOAM decapsulating node.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>>    Potential uses of IOAM per-hop tracing include:
>>>>>>>>> 
>>>>>>>>>    -  Understanding the different paths different packets traverse
>>>>>>>>>       between an IOAM encapsulating and an IOAM decapsulating node
>>> in
>>>>>>>>>       a network that uses load-balancing such as Equal Cost Multi-
>>>>>>>>>       Path (ECMP).  This information could be used to tune the
>>>>>>>>>       algorithm for ECMP for optimized network resource usage.
>>>>>>>>> 
>>>>>>>>>    -  With regard to operations and troubleshooting, understanding
>>> which
>>>>>>>>>       path a particular packet or set of packets take as well as what
>>>>>>>>>     amount of jitter and delay different IOAM nodes in the path
>>>>>>>>>     contribute to the overall delay and jitter between the IOAM
>>>>>>>>>     encapsulating node and the IOAM decapsulating node.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: I like your proposal.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 6) <!-- [rfced] To make this list parallel, may we update "Generic data:
>>>>>>>>>   Format-free information where..." to "Generic data, such as
>>>>>>>>>   format-free information, where..."? Or would you like the list to
>>>>>>>>>   be more of a definition list where each point has a term and then
>>>>>>>>>   a definition list?  Please let us know how we may update.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> *  Generic data: Format-free information where syntax and semantic of
>>>>>>>>>    the information is defined by the operator in a specific
>>>>>>>>>    deployment.  For a specific IOAM-Namespace, all IOAM nodes should
>>>>>>>>>    interpret the generic data the same way.  Examples for generic
>>>>>>>>>    IOAM data include geolocation information (location of the node at
>>>>>>>>>    the time the packet was processed), buffer queue fill level or
>>>>>>>>>    cache fill level at the time the packet was processed, or even a
>>>>>>>>>    battery charge level.
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> *  Generic data, such as format-free information, where the syntax and
>>>>>>>>>    semantics of the information are defined by the operator in a specific
>>>>>>>>>    deployment.  For a specific IOAM-Namespace, all IOAM nodes should
>>>>>>>>>    interpret the generic data the same way.  Examples for generic
>>>>>>>>>    IOAM data include geolocation information (location of the node at
>>>>>>>>>    the time the packet was processed), bufferqueue fill level or
>>>>>>>>>    cache fill level at the time the packet was processed, or even a
>>>>>>>>>    battery charge level.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: Generic data _is_ format-free in case of IOAM. "such as"
>>>>>>>> could be read
>>>>>> as "format-free" information is only an example.  How about:
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>>  *  Generic data, that is format-free information, where the syntax and
>>>>>>>>     semantics of the information are defined by the operator in a specific
>>>>>>>>     deployment.  For a specific IOAM-Namespace, all IOAM nodes should
>>>>>>>>     interpret the generic data the same way.  Examples for generic
>>>>>>>>     IOAM data include geolocation information (location of the node at
>>>>>>>>     the time the packet was processed), bufferqueue fill level or
>>>>>>>>     cache fill level at the time the packet was processed, or even a
>>>>>>>>     battery charge level.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 7) <!--[rfced] The following text seems to be taken from RFC 9197.  May
>>>>>>>>>   we update the capping scheme to match?  Note that we will update
>>>>>>>>>   s/consist/consists regardless (which seems to be an error in
>>>>>>>>>   RFC 9197).
>>>>>>>>> 
>>>>>>>>> RFC 9197:
>>>>>>>>> The IOAM Proof of Transit Option-Type consist of a fixed-size
>>>>>>>>> "IOAM Proof of Transit Option header" and "IOAM Proof of Transit
>>>>>>>>> Option data
>>>>>>>>> fields":
>>>>>>>>> 
>>>>>>>>> This document:
>>>>>>>>> The IOAM Proof of Transit Option-Type consist of a fixed size
>>>>>>>>> "IOAM proof of transit option header" and "IOAM proof of transit
>>>>>>>>> option data
>>>>>> fields".
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> The IOAM Proof of Transit Option-Type consists of a fixed-size
>>>>>>>>> "IOAM Proof of Transit Option header" and "IOAM Proof of Transit
>>>>>>>>> Option data
>>>>>> fields."
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: Your suggestion makes sense.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 8) <!--[rfced] We had a question about the citation in this text:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> ... IOAM loopback mode.  For a definition of IOAM Namespaces and
>>>>>>>>> IOAM layering, please refer to [RFC9197].  IOAM loopback mode is
>>>>>>>>> defined in [RFC9322].
>>>>>>>>> 
>>>>>>>>> We note that RFC 9322 never actually uses the term "mode".
>>>>>>>>> Please review and let us know if any updates to the following text are
>>> necessary.
>>>>>>>>> 
>>>>>>>> ...FB: Rather than talk about "IOAM loopback mode" we should
>>>>>>>> simply say
>>>>>> "IOAM loopback".
>>>>>>>> How about...
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>> 7.  IOAM Deployment Considerations
>>>>>>>> 
>>>>>>>> This section describes several concepts of IOAM, and provides
>>>>>>>> considerations that need to be taken to account when implementing
>>>>>>>> IOAM in a network domain.  This includes concepts like IOAM
>>>>>>>> Namespaces, IOAM Layering, traffic-sets that IOAM is applied to
>>>>>>>> and  IOAM Loopback.  For a definition of IOAM Namespaces and IOAM
>>>>>>>> layering, please refer to [RFC9197].  IOAM Loopback is defined
>>>>>>>> in [RFC9322].
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -->
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 9) <!-- [rfced] We had the following queries related to terminology use
>>>>>>>>>   throughout the document:
>>>>>>>>> 
>>>>>>>>> a) The following terminology appears to be used inconsistently.
>>>>>>>>> May we update as suggested below for consistency with past RFCs?
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Direct export
>>>>>>>>> Direct Export
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> Direct Export (based on RFC 9326)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Incremental Trace-Option-Type
>>>>>>>>> incremental Trace Option-Type
>>>>>>>>> Incremental Trace-Option
>>>>>>>>> Incremental Trace Option-Type
>>>>>>>>> "Incremental" Trace-Option-Type
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> Incremental Trace Option-Type (based on RFC 9197)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> IOAM Layering
>>>>>>>>> IOAM layering
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> IOAM Layering (based on RFC 9197)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> IOAM Loopback
>>>>>>>>> IOAM loopback
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> ? - RFC 9322 uses IOAM Loopback only once, then we see "IOAM
>>>>>>>>> looped-
>>>>>> back"
>>>>>>>> 
>>>>>>>> ...FB: See above. Let's standardize on "IOAM Loopback".
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> IOAM active mode flag
>>>>>>>>> Active flag
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> Active flag (per RFC 9322)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> See also IOAM Active Mode.
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> loopback flag
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> Loopback flag (per RFC 9322)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> IOAM-Namespace
>>>>>>>>> IOAM Namespace
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> IOAM-Namespace (based on RFCs 9197 and 9322)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> IOAM-Option-Type
>>>>>>>>> IOAM Option-Type
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> IOAM Option-Type (based on RFC 9197 and 9326)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> IOAM-Trace-Option-Type
>>>>>>>>> IOAM Trace Option Type
>>>>>>>>> IOAM Trace Option-Type
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> IOAM Trace Option-Type (based on RFC 9197)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Pre-allocated Trace-Option-Type
>>>>>>>>> pre-allocated Option-Type
>>>>>>>>> Pre-allocated Trace-Option
>>>>>>>>> "Pre-allocated" Trace-Option-Type
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> Pre-allocated Trace Option-Type (based on RFC 9197)
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Original:
>>>>>>>>> Trace-Option-Type
>>>>>>>>> Trace Option-Type
>>>>>>>>> trace Option-Type
>>>>>>>>> 
>>>>>>>>> Perhaps:
>>>>>>>>> Trace Option-Type (based on RFC 9197)
>>>>>>>>> 
>>>>>>>>> Relating to the two entries above, see also:
>>>>>>>>> The Option-Types of incremental tracing and pre-allocated
>>>>>>>>> tracing are  defined in [RFC9197].
>>>>>>>> 
>>>>>>>> ...FB: Agreed.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> b) We have updated "Edge to Edge" and "Edge-to-edge" to "Edge-to-
>>> Edge"
>>>>>>>>> per RFC 9197. May we update all subsequent instances to "E2E"
>>>>>>>>> when not in quotes?
>>>>>>>> 
>>>>>>>> ...FB: Makes sense.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> c) FYI, we have updated to use the following forms (see
>>>>>>>>> capitalization/hyphenation/etc.) of various terms for
>>>>>>>>> consistency with recent RFCs on the topic. Please let us know of any
>>> objections.
>>>>>>>>> 
>>>>>>>>> Hop-by-Hop (per RFC 9326)
>>>>>>>>> IOAM-Domain (per feedback on RFC-to-be 9359)  Proof of Transit
>>>>>>>>> (per feedback on RFC-to-be 9359)  IOAM encapsulating node, IOAM
>>>>>>>>> decapsulating node, IOAM transit node
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: ACK.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 10) <!-- [rfced] Please review the "Inclusive Language" portion of the
>>>>>>>>>   online Style Guide
>>>>>>>>>   <https://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie1C5gmvA$ >
>>>>>>>>>   and let us know if any changes are needed.  Note that our script
>>>>>>>>>   did not flag any words in particular, but this should still be
>>>>>>>>>   reviewed as a best practice.
>>>>>>>>> -->
>>>>>>>> 
>>>>>>>> ...FB: Thanks for the note. I'm also not aware of any challenges
>>>>>>>> wrt/ non-
>>>>>> inclusive language with the current text.
>>>>>>>> I don't see a need for further changes.
>>>>>>>> 
>>>>>>>> THANKS A LOT for your suggestions, review and help.
>>>>>>>> 
>>>>>>>> Cheers, Frank
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Thank you.
>>>>>>>>> 
>>>>>>>>> RFC Editor/st/mf
>>>>>>>>> 
>>>>>>>>> *****IMPORTANT*****
>>>>>>>>> 
>>>>>>>>> Updated 2023/03/27
>>>>>>>>> 
>>>>>>>>> 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6idBXRC0kQ$ ).
>>>>>>>>> 
>>>>>>>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license-info/__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6icRrn8x_A$ ).
>>>>>>>>> 
>>>>>>>>> *  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://urldefense.com/v3/__https://authors.ietf.org/rfcxml-vocabulary__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6id2N5D7og$ >.
>>>>>>>>> 
>>>>>>>>> *  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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie64C1PHQ$ 
>>>>>>>>> 4Q9l2USxIAe6P8O4Zc
>>>>>>>>> 
>>>>>>>>>   *  The archive itself:
>>>>>>>>>      https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ic0QJDdXg$ 
>>>>>>>>> 
>>>>>>>>>   *  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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.xml__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ie_OoT5uQ$ 
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6id1Xfzapg$ 
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.pdf__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6icJu4AWbQ$ 
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.txt__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6if4NY2luQ$ 
>>>>>>>>> 
>>>>>>>>> Diff file of the text:
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-diff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6idAknQYQw$ 
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-rfcdiff.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ic-AN-pqw$  (side
>>>>>>>>> by
>>>>>>>>> side)
>>>>>>>>> 
>>>>>>>>> Diff of the XML:
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378-xmldiff1.html__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6icRlFRZQw$ 
>>>>>>>>> 
>>>>>>>>> The following files are provided to facilitate creation of your
>>>>>>>>> own diff files of the XML.
>>>>>>>>> 
>>>>>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.original.v2v3.xml__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ieJ7525GQ$ 
>>>>>>>>> 
>>>>>>>>> XMLv3 file that is a best effort to capture v3-related format
>>>>>>>>> updates
>>>>>>>>> only:
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9378.form.xml__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6idnP0nFVA$ 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Tracking progress
>>>>>>>>> -----------------
>>>>>>>>> 
>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9378__;!!MZ3Fw45to5uY!Niwb5rCDDNfXQuFUzPalS0gFsNgF3_4LZ3s3LLw_xzfBsriDBl8vlmJ8zxQfiHOE-oE6EWuL-hN-hjOe6ieZ3UiMwA$ 
>>>>>>>>> 
>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>> 
>>>>>>>>> Thank you for your cooperation,
>>>>>>>>> 
>>>>>>>>> RFC Editor
>>>>>>>>> 
>>>>>>>>> --------------------------------------
>>>>>>>>> RFC9378 (draft-ietf-ippm-ioam-deployment-05)
>>>>>>>>> 
>>>>>>>>> Title            : In-situ OAM Deployment
>>>>>>>>> Author(s)        : F. Brockners, Ed., S. Bhandari, Ed., D. Bernier, T. Mizrahi,
>>> Ed.
>>>>>>>>> WG Chair(s)      : Marcus Ihlar, Tommy Pauly
>>>>>>>>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>>> 
>>>> 
>>>> 
>>> 
>