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

["Frank Brockners (fbrockne)" <[e-mail]>]

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://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-rfcdiff.html (comprehensive
> rfcdiff)  https://www.rfc-editor.org/authors/rfc9378-auth48diff.html (AUTH48
> changes only)
> 
> The AUTH48 status page is viewable at:
>  https://www.rfc-editor.org/auth48/rfc9378
> 
> 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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> >>>     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://www.rfc-editor.org/faq/).
> >>>
> >>> You and you coauthors are responsible for engaging other parties
> >>> (e.g., Contributors or Working Group) as necessary before providing your
> approval.
> >>>
> >>> Planning your review
> >>> ---------------------
> >>>
> >>> Please review the following aspects of your document:
> >>>
> >>> *  RFC Editor questions
> >>>
> >>>   Please review and resolve any questions raised by the RFC Editor
> >>>   that have been included in the XML file as comments marked as
> >>>   follows:
> >>>
> >>>   <!-- [rfced] ... -->
> >>>
> >>>   These questions will also be sent in a subsequent email.
> >>>
> >>> *  Changes submitted by coauthors
> >>>
> >>>   Please ensure that you review any changes submitted by your
> >>>   coauthors.  We assume that if you do not speak up that you
> >>>   agree to changes submitted by your coauthors.
> >>>
> >>> *  Content
> >>>
> >>>   Please review the full content of the document, as this cannot
> >>>   change once the RFC is published.  Please pay particular attention to:
> >>>   - IANA considerations updates (if applicable)
> >>>   - contact information
> >>>   - references
> >>>
> >>> *  Copyright notices and legends
> >>>
> >>>   Please review the copyright notice and legends as defined in
> >>>   RFC 5378 and the Trust Legal Provisions
> >>>   (TLP – https://trustee.ietf.org/license-info/).
> >>>
> >>> *  Semantic markup
> >>>
> >>>   Please review the markup in the XML file to ensure that elements of
> >>>   content are correctly tagged.  For example, ensure that <sourcecode>
> >>>   and <artwork> are set correctly.  See details at
> >>>   <https://authors.ietf.org/rfcxml-vocabulary>.
> >>>
> >>> *  Formatted output
> >>>
> >>>   Please review the PDF, HTML, and TXT files to ensure that the
> >>>   formatted output, as generated from the markup in the XML file, is
> >>>   reasonable.  Please note that the TXT will have formatting
> >>>   limitations compared to the PDF and HTML.
> >>>
> >>>
> >>> Submitting changes
> >>> ------------------
> >>>
> >>> To submit changes, please reply to this email using ‘REPLY ALL’ as
> >>> all the parties CCed on this message need to see your changes. The
> >>> parties
> >>> include:
> >>>
> >>>   *  your coauthors
> >>>
> >>>   *  [e-mail] (the RPC team)
> >>>
> >>>   *  other document participants, depending on the stream (e.g.,
> >>>      IETF Stream participants are your working group chairs, the
> >>>      responsible ADs, and the document shepherd).
> >>>
> >>>   *  [e-mail], which is a new archival mailing list
> >>>      to preserve AUTH48 conversations; it is not an active discussion
> >>>      list:
> >>>
> >>>     *  More info:
> >>>        https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-
> >>> 4Q9l2USxIAe6P8O4Zc
> >>>
> >>>     *  The archive itself:
> >>>        https://mailarchive.ietf.org/arch/browse/auth48archive/
> >>>
> >>>     *  Note: If only absolutely necessary, you may temporarily opt out
> >>>        of the archiving of messages (e.g., to discuss a sensitive matter).
> >>>        If needed, please add a note at the top of the message that you
> >>>        have dropped the address. When the discussion is concluded,
> >>>        [e-mail] will be re-added to the CC list and
> >>>        its addition will be noted at the top of the message.
> >>>
> >>> You may submit your changes in one of two ways:
> >>>
> >>> An update to the provided XML file
> >>> — OR —
> >>> An explicit list of changes in this format
> >>>
> >>> Section # (or indicate Global)
> >>>
> >>> OLD:
> >>> old text
> >>>
> >>> NEW:
> >>> new text
> >>>
> >>> You do not need to reply with both an updated XML file and an
> >>> explicit list of changes, as either form is sufficient.
> >>>
> >>> We will ask a stream manager to review and approve any changes that
> >>> seem beyond editorial in nature, e.g., addition of new text,
> >>> deletion of text, and technical changes.  Information about stream
> >>> managers can be found in the FAQ.  Editorial changes do not require
> approval from a stream manager.
> >>>
> >>>
> >>> Approving for publication
> >>> --------------------------
> >>>
> >>> To approve your RFC for publication, please reply to this email
> >>> stating that you approve this RFC for publication.  Please use
> >>> ‘REPLY ALL’, as all the parties CCed on this message need to see your
> approval.
> >>>
> >>>
> >>> Files
> >>> -----
> >>>
> >>> The files are available here:
> >>>   https://www.rfc-editor.org/authors/rfc9378.xml
> >>>   https://www.rfc-editor.org/authors/rfc9378.html
> >>>   https://www.rfc-editor.org/authors/rfc9378.pdf
> >>>   https://www.rfc-editor.org/authors/rfc9378.txt
> >>>
> >>> Diff file of the text:
> >>>   https://www.rfc-editor.org/authors/rfc9378-diff.html
> >>>   https://www.rfc-editor.org/authors/rfc9378-rfcdiff.html (side by
> >>> side)
> >>>
> >>> Diff of the XML:
> >>>   https://www.rfc-editor.org/authors/rfc9378-xmldiff1.html
> >>>
> >>> The following files are provided to facilitate creation of your own
> >>> diff files of the XML.
> >>>
> >>> Initial XMLv3 created using XMLv2 as input:
> >>>   https://www.rfc-editor.org/authors/rfc9378.original.v2v3.xml
> >>>
> >>> XMLv3 file that is a best effort to capture v3-related format
> >>> updates
> >>> only:
> >>>   https://www.rfc-editor.org/authors/rfc9378.form.xml
> >>>
> >>>
> >>> Tracking progress
> >>> -----------------
> >>>
> >>> The details of the AUTH48 status of your document are here:
> >>>   https://www.rfc-editor.org/auth48/rfc9378
> >>>
> >>> 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
> >>>
> >>
> >