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

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

Hi Megan,

Thanks - and thanks for accommodating the address fix.

Cheers, Frank

> -----Original Message-----
> From: Megan Ferguson <[e-mail]>
> Sent: Thursday, 20 October 2022 16:47
> To: Shwetha Bhandari <[e-mail]>
> Cc: Frank Brockners (fbrockne) <[e-mail]>; Tal Mizrahi
> <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; ippm-
> [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
> 
> Greetings Shwetha, Frank, and Haoyu,
> 
> Thank you for your replies.  We have recorded your approvals at the AUTH48
> status page (see http://www.rfc-editor.org/auth48/rfc9326).  Note that we will
> assume your assent to further changes submitted by your coauthors unless we
> hear otherwise at that time.
> 
> Frank - we have incorporated your changes to Section 3.1.1 and your address in
> the files below.  Please review carefully as we do not make updates once the
> document is published.
> 
>   The files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9326.txt
>    https://www.rfc-editor.org/authors/rfc9326.pdf
>    https://www.rfc-editor.org/authors/rfc9326.html
>    https://www.rfc-editor.org/authors/rfc9326.xml
> 
>   The relevant diff files have been posted here (please refresh):
>    https://www.rfc-editor.org/authors/rfc9326-diff.html (comprehensive diff)
>    https://www.rfc-editor.org/authors/rfc9326-rfcdiff.html (comprehensive
> rfcdiff)
>    https://www.rfc-editor.org/authors/rfc9326-auth48diff.html (AUTH48
> changes)
>    https://www.rfc-editor.org/authors/rfc9326-lastdiff.html (last version to this)
>    https://www.rfc-editor.org/authors/rfc9326-lastrfcdiff.html (last version to
> this rfcdiff)
> 
> Thank you.
> 
> RFC Editor/mf
> 
> > On Oct 19, 2022, at 1:50 AM, Shwetha Bhandari
> <[e-mail]> wrote:
> >
> > 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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0
> B
> > > > ekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSzVSajYg$ .  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!JQjsM3
> SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4l
> qIM01ApgRiBtzlQSoZAVCw$ > 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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3M
> GF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSLKB4m5w$ ).
> > > >
> > > > 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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRp
> oXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlT28ms5Ig$ ).
> > > >
> > > > *  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!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0
> BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSD9_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!JQjsM3SadJmgep6J
> > > >
> wmJachqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRi
> Btzl
> > > > QTca5KWw$
> > > > Ae6P8O4Zc
> > > >
> > > >      *  The archive itself:
> > > >
> > > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/brow
> > > >
> se/auth48archive/__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFL
> > > > k3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlTpvcPzsQ$
> > > >
> > > >      *  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!JQjsM3SadJmgep6JwmJach
> qnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlQIER
> GS_w$
> > > >    https://urldefense.com/v3/__https://www.rfc-
> editor.org/authors/rfc9326.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJac
> hqnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSQ-
> 9fyuQ$
> > > >    https://urldefense.com/v3/__https://www.rfc-
> editor.org/authors/rfc9326.pdf__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJach
> qnO73MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSQU
> Cmxjw$
> > > >
> > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
> > > >
> 9326.txt__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0Bek
> > > > RpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSLru3XRA$
> > > >
> > > > Diff file of the text:
> > > >    https://urldefense.com/v3/__https://www.rfc-
> editor.org/authors/rfc9326-
> diff.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0Be
> kRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlTcua81cQ$
> > > >
> > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
> > > > 9326-
> rfcdiff.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFL
> > > >
> k3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlSk46TSGQ$
> > > > (side by
> > > > side)
> > > >
> > > > Diff of the XML:
> > > >
> > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
> > > > 9326-
> xmldiff1.html__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJF
> > > >
> Lk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlRJGz09Dg$
> > > >
> > > > 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/rfc
> > > >
> 9326.original.v2v3.xml__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO7
> > > >
> 3MJFLk3MGF0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlRpoSl4tA$
> > > >
> > > > XMLv3 file that is a best effort to capture v3-related format
> > > > updates
> > > > only:
> > > >
> > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc
> > > >
> 9326.form.xml__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3M
> G
> > > > F0BekRpoXZWLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlTa6L4g2Q$
> > > >
> > > >
> > > > Tracking progress
> > > > -----------------
> > > >
> > > > The details of the AUTH48 status of your document are here:
> > > >
> > > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9
> > > >
> 326__;!!MZ3Fw45to5uY!JQjsM3SadJmgep6JwmJachqnO73MJFLk3MGF0BekRpo
> XZ
> > > > WLepXWBrWvaaTKusmLBIh4lqIM01ApgRiBtzlQCiK2dKg$
> > > >
> > > > 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
> > > >
> > > >