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

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

Hi Sarah,

Thanks for implementing all the changes we discussed. The document looks ready for publishing to me.

Cheers, Frank

> -----Original Message-----
> From: Sarah Tarrant <[e-mail]>
> Sent: Thursday, 10 August 2023 19:43
> To: Frank Brockners (fbrockne) <[e-mail]>
> Cc: RFC Editor <[e-mail]>;
> [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
> 
> Hello Frank,
> 
> Thank you for your reply and guidance. We have updated the document
> accordingly.
> 
> The files have been posted here (please refresh):
> https://www.rfc-editor.org/authors/rfc9452.xml
> https://www.rfc-editor.org/authors/rfc9452.txt
> https://www.rfc-editor.org/authors/rfc9452.html
> https://www.rfc-editor.org/authors/rfc9452.pdf
> 
> The relevant diff files have been posted here:
> https://www.rfc-editor.org/authors/rfc9452-diff.html (comprehensive diff)
> https://www.rfc-editor.org/authors/rfc9452-rfcdiff.html (comprehensive
> rfcdiff) https://www.rfc-editor.org/authors/rfc9452-auth48diff.html
> (AUTH48 changes only)
> 
> Please review the document carefully as documents do not change once
> published as RFCs.
> 
> We will await any further changes you may have and approvals from each
> author prior to moving forward in the publication process.
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9452
> 
> 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-4Q9l2US
> >>> xI
> >>> 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>