Re: [auth48] AUTH48: RFC-to-be 9452 <draft-ietf-sfc-ioam-nsh-13> for your review

[Sarah Tarrant <[e-mail]>]

Hello Frank,

My apologies—you are absolutely correct! We’ll be working on your edits today.

Thank you,
RFC Editor/st

> On Aug 9, 2023, at 8:17 AM, Frank Brockners (fbrockne) <[e-mail]> wrote:
> 
> Hi Sarah,
> 
> I replied earlier today (see attached). Did you receive my reply?
> 
> Cheers, Frank
> 
> 
>> -----Original Message-----
>> From: Sarah Tarrant <[e-mail]>
>> Sent: Wednesday, 9 August 2023 15:05
>> To: RFC Editor <[e-mail]>
>> Cc: Frank Brockners (fbrockne) <[e-mail]>;
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: AUTH48: RFC-to-be 9452 <draft-ietf-sfc-ioam-nsh-13> for your
>> review
>> 
>> Greetings,
>> 
>> Just a friendly weekly reminder that this document awaits your attention.
>> 
>> Please see the document-specific questions and AUTH48 announcement in
>> this thread and let us know if we can be of assistance as you begin the
>> AUTH48 review process.
>> 
>> Please note that the AUTH48 status page of this document is viewable at:
>> http://www.rfc-editor.org/auth48/rfc9452
>> 
>> AUTH48 FAQs are available at https://www.rfc-editor.org/faq/#auth48.
>> 
>> We look forward to hearing from you at your earliest convenience.
>> 
>> Thank you.
>> RFC Editor/st
>> 
>>> On Jul 31, 2023, at 9:58 PM, [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 ("In-situ" to "In Situ"):
>>> 
>>> Original:
>>> Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data
>>> 
>>> Current:
>>> Network Service Header (NSH) Encapsulation for In Situ OAM (IOAM) Data
>>> -->
>>> 
>>> 
>>> 2) <!-- [rfced] We are having trouble understanding "by means of
>>> configuration."  Does the suggested text convey the intended meaning?
>>> Also, does "encapsulating/decapsulating" mean "encapsulating and
>>> decapsulating" or "encapsulating or decapsulating"?
>>> 
>>> Original:
>>>  In an administrative domain where IOAM is used,
>>>  insertion of the IOAM header in NSH is enabled at the NSH tunnel
>>>  endpoints, which also serve as IOAM encapsulating/decapsulating nodes
>>>  by means of configuration.
>>> 
>>> Perhaps:
>>>  In an administrative domain where IOAM is used,
>>>  insertion of the IOAM header in NSH is enabled at the NSH tunnel
>>>  endpoints, which are also configured to serve as IOAM encapsulating and
>>>  decapsulating nodes.
>>> -->
>>> 
>>> 
>>> 3) <!-- [rfced] This text appears in and points to Section 3.  May we
>>> delete "Section 3"?  Please review.
>>> 
>>> Original:
>>>  The operator MUST ensure that SFC-aware
>>>  nodes along the Service Function Path support IOAM, otherwise packets
>>>  might be dropped (see Section 3 further below, as well as [RFC8300]
>>>  Section 2.2).
>>> 
>>> Perhaps:
>>>  The operator MUST ensure that SFC-aware
>>>  nodes along the Service Function Path support IOAM; otherwise, packets
>>>  might be dropped (see more below, as well as Section 2.2 of [RFC8300]).
>>> -->
>>> 
>>> 
>>> 4) <!-- [rfced] Would it be helpful to expand MD for the reader?  Perhaps it
>> could be added to list of abbreviations introduced in Section 2?
>>> 
>>> -->
>>> 
>>> 
>>> 5) <!-- [rfced] For readability, we have updated the text as follows.  Please
>> let us know if any corrections are needed.
>>> 
>>> Original:
>>>  Per Section 2.2 of [RFC8300], packets with Next Protocol values not
>>>  supported SHOULD be silently dropped by default.
>>> 
>>> Current:
>>>  Per Section 2.2 of [RFC8300], packets with unsupported Next Protocol
>> values
>>>  SHOULD be silently dropped by default.
>>> -->
>>> 
>>> 
>>> 6) <!-- [rfced] For readability, may we update the text as follows?
>>> 
>>> Original:
>>>  IOAM is considered a "per domain" feature, where the operator decides
>>>  on leveraging and configuring IOAM according to the operator's needs.
>>> 
>>> Suggested:
>>>  IOAM is considered a "per domain" feature, where the operator decides
>>>  how to leverage and configure IOAM according to the operator's needs.
>>> -->
>>> 
>>> 
>>> 7) <!-- [rfced] For clarity, may we update the text as follows?  Please let us
>> know if any corrections are needed.
>>> 
>>> Original:
>>>  Hardware and software friendly implementation: Hardware forwarders
>>>  benefit from an encapsulation that minimizes iterative look-ups of
>>>  fields within the packet: Any operation which looks up the value of a
>>>  field within the packet, based on which another lookup is performed,
>>>  consumes additional gates and time in an implementation - both of
>>>  which are desired to be kept to a minimum.
>>> 
>>> Current:
>>>  Hardware- and software-friendly implementation: Hardware forwarders
>>>  benefit from an encapsulation that minimizes iterative lookups of
>>>  fields within the packet. Any operation that looks up the value of a
>>>  field within the packet, based on which another lookup is performed,
>>>  consumes additional gates and time in an implementation, both of
>>>  which should be kept to a minimum.
>>> -->
>>> 
>>> 
>>> 8) <!-- [rfced] Terminology
>>> 
>>> a) We note that Figure 1 contains “IOAM Option and Optional Data
>>> Space”, while the text defines “IOAM Option and Data Space”. Please
>>> review and let us know if these should be consistent.
>>> 
>>> 
>>> b) These terms may be used inconsistently.  Please review and let us
>>> know if the forms on the right (on the right of the arrow) should be
>>> used consistently, or if any other updates are needed.
>>> 
>>> IOAM-Data-fields & IOAM data fields -> IOAM-Data-Fields
>>> IOAM-Option-Types -> IOAM Option-Type
>>> -->
>>> 
>>> 
>>> 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.
>>> 
>>> Note that our script did not flag any words in particular, but this
>>> should still be reviewed as a best practice.
>>> -->
>>> 
>>> 
>>> Thank you.
>>> 
>>> RFC Editor
>>> 
>>> 
>>> On Jul 31, 2023, at 7:53 PM, [e-mail] wrote:
>>> 
>>> *****IMPORTANT*****
>>> 
>>> Updated 2023/07/31
>>> 
>>> 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/rfc9452.xml
>>>  https://www.rfc-editor.org/authors/rfc9452.html
>>>  https://www.rfc-editor.org/authors/rfc9452.pdf
>>>  https://www.rfc-editor.org/authors/rfc9452.txt
>>> 
>>> Diff file of the text:
>>>  https://www.rfc-editor.org/authors/rfc9452-diff.html
>>>  https://www.rfc-editor.org/authors/rfc9452-rfcdiff.html (side by
>>> side)
>>> 
>>> Diff of the XML:
>>>  https://www.rfc-editor.org/authors/rfc9452-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/rfc9452.original.v2v3.xml
>>> 
>>> XMLv3 file that is a best effort to capture v3-related format updates
>>> only:
>>>  https://www.rfc-editor.org/authors/rfc9452.form.xml
>>> 
>>> 
>>> Tracking progress
>>> -----------------
>>> 
>>> The details of the AUTH48 status of your document are here:
>>>  https://www.rfc-editor.org/auth48/rfc9452
>>> 
>>> Please let us know if you have any questions.
>>> 
>>> Thank you for your cooperation,
>>> 
>>> RFC Editor
>>> 
>>> --------------------------------------
>>> RFC9452 (draft-ietf-sfc-ioam-nsh-13)
>>> 
>>> Title            : Network Service Header (NSH) Encapsulation for In-situ OAM
>> (IOAM) Data
>>> Author(s)        : F. Brockners, Ed., S. Bhandari, Ed.
>>> WG Chair(s)      : Joel M. Halpern, Jim Guichard
>>> 
>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
>>> 
>>> 
> 
> <Mail Attachment.eml>