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

[Sarah Tarrant <[e-mail]>]

All,

Daniel's approval has been noted on the AUTH48 status page:
https://www.rfc-editor.org/auth48/rfc9378

We have now received all necessary approvals and consider AUTH48 complete. Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time.

RFC Editor/st

> On Apr 20, 2023, at 11:43 AM, Bernier, Daniel <[e-mail]> wrote:
> 
> Sorry
> 
> I approve the changes
> 
> On Apr 20, 2023 5:55 p.m., Sarah Tarrant <[e-mail]> wrote:
> 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
> >>>> 
> >>>> 
> >>>> 
> >>> 
> > 
> 
> ------------------------------------------------------------------------------
> External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints