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

[Martin Duke <[e-mail]>]

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://www.rfc-editor.org/authors/rfc9378-auth48diff.html.]
>
> 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://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)
>
> 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://www.rfc-editor.org/auth48/rfc9378
>
> 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://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
>
>
>
>