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

[Shwetha Bhandari <[e-mail]>]

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