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

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

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://www.iana.org/assignments/ioam/ioam.xhtml.  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://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> 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://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-4Q9l2USxI
> > Ae6P8O4Zc
> >
> >      *  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/rfc9326.xml
> >    https://www.rfc-editor.org/authors/rfc9326.html
> >    https://www.rfc-editor.org/authors/rfc9326.pdf
> >    https://www.rfc-editor.org/authors/rfc9326.txt
> >
> > Diff file of the text:
> >    https://www.rfc-editor.org/authors/rfc9326-diff.html
> >    https://www.rfc-editor.org/authors/rfc9326-rfcdiff.html (side by
> > side)
> >
> > Diff of the XML:
> >    https://www.rfc-editor.org/authors/rfc9326-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/rfc9326.original.v2v3.xml
> >
> > XMLv3 file that is a best effort to capture v3-related format updates
> > only:
> >    https://www.rfc-editor.org/authors/rfc9326.form.xml
> >
> >
> > Tracking progress
> > -----------------
> >
> > The details of the AUTH48 status of your document are here:
> >    https://www.rfc-editor.org/auth48/rfc9326
> >
> > 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
> >
> >