Re: [auth48] AUTH48: RFC-to-be 9326 <draft-ietf-ippm-ioam-direct-export-11> for your review

[Shwetha Bhandari <[e-mail]>]

Hello RFC Editor Team,

I approve the document too. I do not have further comments.

Thanks,
Shwetha

On Wed, Oct 12, 2022 at 1:00 AM Frank Brockners (fbrockne) <
[e-mail]> wrote:

> Hi RFC Editor Team, Tal,
>
> Thanks a lot for the edits. I also approve the doc, subject to a few
> changes - see inline on top of Tal's changes - and below (address change).
>
> Tal - note there is one delta between our comments - see inline.
>
> In addition, the editorial changes that were done to my address render it
> wrong.
>
> OLD:
>    Frank Brockners
>    Cisco Systems, Inc.
>    3rd Floor
>    Hansaallee 249
>    40549 Duesseldorf
>    Germany
>    Email: [e-mail]
>
> NEW
>    Frank Brockners
>    Cisco Systems, Inc.
>    Hansaallee 249
>    40549 Duesseldorf
>    Germany
>    Email: [e-mail]
>
> If you really want to mention the floor (I suggest to drop it), then it
> needs to go below the "Hansaallee 249":
>    Frank Brockners
>    Cisco Systems, Inc.
>    Hansaallee 249
>    3rd Floor
>    40549 Duesseldorf
>    Germany
>    Email: [e-mail]
>
> Thanks again, Frank
>
> > -----Original Message-----
> > From: Tal Mizrahi <[e-mail]>
> > Sent: Saturday, 8 October 2022 13:59
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]; Frank Brockners
> > (fbrockne) <[e-mail]>; [e-mail]; ippm-
> > [e-mail]; [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: AUTH48: RFC-to-be 9326
> <draft-ietf-ippm-ioam-direct-export-11>
> > for your review
> >
> > Dear RFC Editor Team,
> >
> > Thanks for your work on this document.
> > I approve the document, subject to the comments below.
> > Please see my responses and comments inline, marked [TM].
> >
> > Thanks,
> > Tal.
> >
> > On Sat, Oct 8, 2022 at 3:04 AM <[e-mail]> wrote:
> > >
> > > 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:
> > >
> > > a) Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
> > > Style Guide").
> > >
> > > b) The hyphen in "In-situ" has been removed to be consistent with
> > > recently published IOAM documents. Please review.
> > >
> > > Original:
> > > In-situ OAM Direct Exporting
> > >
> > > Current:
> > > In Situ Operations, Administration, and Maintenance (IOAM) Direct
> > > Exporting
> > > -->
> >
> > [TM] Looks good.
> >
> > >
> > >
> > > 2) <!-- [rfced] We had the following questions related to similar text
> in
> > >      both the Abstract and Introduction:
> > >
> > > Original (Abstract):
> > > This document introduces a new IOAM option type (denoted
> > > IOAM-Option-Type) called the Direct Export (DEX) Option-Type, which is
> > > used as a trigger for IOAM data to be directly exported or locally
> > > aggregated without being pushed into in-flight data packets.
> > >
> > > Original (Introduction):
> > > This document defines a new IOAM-Option-Type called the Direct Export
> > > (DEX) Option-Type.  This Option-Type is used as a trigger for IOAM
> > > nodes to locally aggregate and process IOAM data, and/or to export it
> > > to a receiving entity (or entities).
> > >
> > >
> > > a) We have updated mentions in the text above to use "IOAM Direct
> > > Export (DEX) Option-Type" to exactly match its use at
> > >
> https://urldefense.com/v3/__https://www.iana.org/assignments/ioam/ioam.xhtml__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSzVSajYg$
> .  Please let us know
> > > any objections and/or if similar changes should be made elsewhere in
> the
> > document (specifically the IANA Considerations section?).
> >
> > [TM] Looks good, and in my opinion there is no need for further changes.
> >
> > >
> > > b) There is some difference in the description of how the DEX
> > > Option-Type is used in the Intro and Abstract.  Please let us know
> > > if/how these instances should be made consistent.
> >
> > [TM] I would be fine with the current text. In my opinion there is no
> need for the
> > abstract and introduction to be identical.
> >
> > >
> > > -->
> > >
> > >
> > > 3) <!-- [rfced] FYI: We changed "Direct EXporting" to "Direct
> Exporting" for
> > consistency throughout the document. Please let us know of any
> objections.
> > >
> > > Original:
> > > DEX: Direct EXporting
> > >
> > > Current:
> > > DEX: Direct Exporting
> > > -->
> >
> > [TM] Looks good.
> >
> > >
> > >
> > > 4) <!-- [rfced] FYI: We rearranged parts of this sentence and added
> more
> > >      context (specifically to the content in parenthesis) for ease of
> the
> > >      reader. Please let us know of any objections.
> > >
> > > Original:
> > > An IOAM encapsulating node configured to incorporate the DEX
> > > Option-Type encapsulates (possibly a subset of) the packets it
> > > forwards with the DEX Option-Type, and MAY export and/or collect the
> > > requested IOAM data immediately.
> > >
> > > Current:
> > > An IOAM encapsulating node configured to incorporate the DEX
> > > Option-Type encapsulates the packets (and possibly a subset of the
> > > packets) it forwards with the DEX Option-Type and MAY export and/or
> > > collect the requested IOAM data immediately.
> >
> > [TM] I suggest the following change:
> > OLD:
> > and possibly a subset
> > NEW:
> > or possibly a subset
> >
> >
> >
> > > -->
> > >
> > >
> > > 5) <!-- [rfced] Will readers know what "it" is referring to in this
> > >      sentence?
> > >
> > > Original:
> > > Therefore, an IOAM encapsulating node that supports the DEX
> > > Option-Type MUST support the ability to incorporate the DEX
> > > Option-Type selectively into a subset of the packets that are
> > > forwarded by it.
> > >
> > > Perhaps:
> > > Therefore, an IOAM encapsulating node that supports the DEX
> > > Option-Type MUST support the ability to incorporate the DEX
> > > Option-Type selectively into a subset of the packets that are
> > > forwarded by the DEX Option-Type.
> > > -->
> > >
> >
> > [TM] Looks good.
>
> [FB] IMHO the new proposal is confusing to say the least. The new text
> could be read as if the DEX Option-Type would forward packets. Whereas it
> is the IOAM encapsulating node that forwards the packets.
>
> Suggestion:
>
> ORIGINAL:
> Therefore, an IOAM encapsulating node that supports the DEX
> Option-Type MUST support the ability to incorporate the DEX
> Option-Type selectively into a subset of the packets that are
> forwarded by it.
>
> NEW:
> Therefore, an IOAM encapsulating node that supports the DEX
> Option-Type MUST support the ability to incorporate the DEX
> Option-Type selectively into a subset of the packets that are
> forwarded by the IOAM encapsulating node.
>
> >
> > >
> > > 6) <!-- [rfced] We suggest rephrasing and condensing this sentence, as
> it may
> > be difficult to parse for some readers due to the number of adverbs.
> Would the
> > suggested text change the original meaning of the sentence?
> > >
> > > Original:
> > > As mentioned above, the data can be locally collected, and optionally
> > > can be aggregated and exported to a receiving entity, either
> > > proactively or on-demand.
> > >
> > > Perhaps:
> > > As mentioned above, the data can be locally collected, aggregated, and
> > > exported to a receiving entity proactively or on-demand.
> > > -->
> >
> > [TM] Yes, except that I suggest replacing "and" with "and/or".
> >
> > >
> > >
> > > 7) <!-- [rfced] FYI: In Section 3.2, we updated the terms "Optional
> > >      fields", "Flow ID", and "Sequence Number" to fall under a nested
> > >      definition list. Please confirm that this accurately describes
> > >      the figure and let us know if there are any objections.
> > > -->
> >
> > [TM] Looks good.
> >
> > >
> > >
> > > 8) <!--[rfced] FYI - I-D.ietf-ippm-ioam-flags is in AUTH48 state. We
> have
> > >      updated the reference in this document to point to the RFC-to-be
> info
> > >      assuming that document will be published before this one.  Please
> > >      advise on how you would like to proceed in the event that
> > >      I-D.ietf-ippm-ioam-flags does not complete AUTH48 prior to this
> > >      doc (i.e., revert the reference to the I-D format or hold on
> > >      publication of this document?).-->
> > >
> >
> > [TM] There is no reason why the flags document should be delayed.
> > Let's proceed with the reference to the RFC number.
> >
> > >
> > > 9) <!-- [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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlQSoZAVCw$
> >
> > and let us know if any changes are needed.
> > > -->
> >
> > [TM] In my opinion there is no need for any changes in this context.
> >
> > >
> > >
> > > Thank you.
> > >
> > > RFC Editor/mc/mf
> > >
> > > *****IMPORTANT*****
> > >
> > > Updated 2022/10/07
> > >
> > > 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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSLKB4m5w$
> ).
> > >
> > > 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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlT28ms5Ig$
> ).
> > >
> > > *  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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSD9_fUnA$
> >.
> > >
> > > *  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-4Q9l2USxI__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlQTca5KWw$
> > > Ae6P8O4Zc
> > >
> > >      *  The archive itself:
> > >
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlTpvcPzsQ$
> > >
> > >      *  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/rfc9326.xml__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlQIERGS_w$
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9326.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSQ-9fyuQ$
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9326.pdf__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSQUCmxjw$
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9326.txt__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSLru3XRA$
> > >
> > > Diff file of the text:
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9326-diff.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlTcua81cQ$
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9326-rfcdiff.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSk46TSGQ$
> (side by
> > > side)
> > >
> > > Diff of the XML:
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9326-xmldiff1.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlRJGz09Dg$
> > >
> > > 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/rfc9326.original.v2v3.xml__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlRpoSl4tA$
> > >
> > > XMLv3 file that is a best effort to capture v3-related format updates
> > > only:
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9326.form.xml__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlTa6L4g2Q$
> > >
> > >
> > > Tracking progress
> > > -----------------
> > >
> > > The details of the AUTH48 status of your document are here:
> > >
> https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9326__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlQCiK2dKg$
> > >
> > > Please let us know if you have any questions.
> > >
> > > Thank you for your cooperation,
> > >
> > > RFC Editor
> > >
> > > --------------------------------------
> > > RFC9326 (draft-ietf-ippm-ioam-direct-export-11)
> > >
> > > Title            : In-situ OAM Direct Exporting
> > > Author(s)        : H. Song, B. Gafni, F. Brockners, S. Bhandari, T.
> Mizrahi
> > > WG Chair(s)      : Marcus Ihlar, Tommy Pauly
> > > Area Director(s) : Martin Duke, Zaheduzzaman Sarker
> > >
> > >
>