Re: [sfc] Jim Guichard's Discuss on draft-ietf-sfc-ioam-nsh-11: (with DISCUSS and COMMENT)

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

Hi Jim,

Thanks a lot for your review. We've just posted an updated revision (12):
https://www.ietf.org/archive/id/draft-ietf-sfc-ioam-nsh-12.txt

Please see inline below:

> -----Original Message-----
> From: Jim Guichard via Datatracker <[e-mail]>
> Sent: Friday, 28 April 2023 21:32
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Jim Guichard's Discuss on draft-ietf-sfc-ioam-nsh-11: (with DISCUSS
> and COMMENT)
> 
> Jim Guichard has entered the following ballot position for
> draft-ietf-sfc-ioam-nsh-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-ioam-nsh/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> - Section 3:
>    The IOAM-Data-Fields MUST follow the definitions corresponding to
>    IOAM-Option-Types (e.g., see Section 5 of [RFC9197] and Section 3.2
>    of [I-D.ietf-ippm-ioam-direct-export])
> 
> The above reference to RFC9197 is incorrect although a simple fix. The
> IOAM-Option-Types are defined in Section 4 of that document not Section
> 5.
> Adding a DISCUSS as this reference is important enough to not just be a
> comment. Note that the same incorrect reference is used later on in Section
> 3
> and must be corrected also.

...FB: Corrected in  draft-ietf-sfc-ioam-nsh-12

> 
> - Section 3:
>    The operator MUST ensure that all nodes along the service path support
> IOAM.
>     Otherwise packets with IOAM are likely to be dropped per [RFC8300].
> 
> This text needs clarification as RFC8300 says nothing about IOAM
> specifically
> and dropping of OAM packets is discussed in that RFC here ->
> https://www.rfc-
> editor.org/rfc/rfc8300#:~:text=O%20bit%3A%20%20Setting,disabled%20by
> %20default.
> The authors should clarify exactly what they mean by the above text and
> clarify
> what specifically in RFC8300 would cause packets to be dropped if a node
> does
> not support IOAM.

...FB: This sentence has been updated to refer to section 3 of the document as well as RFC 8300, section 2.2:

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).

> 
> - IANA Considerations:
> The text says "IANA is requested to allocate protocol numbers for the
> following
> "NSH Next Protocol" related to IOAM" but there is no reference to the
> correct
> registry. NSH Next Protocol allocations can be found here:
> https://www.iana.org/assignments/nsh/nsh.xhtml#next-protocol and they
> are part
> of the Network Service Header (NSH) Parameters registry. Please provide an
> accurate reference to the Network Service Header (NSH) Parameters
> registry for
> IANA.

...FB: Thanks! The IANA request now reads:

   IANA is requested to allocate a code point for IOAM in the "NSH Next
   Protocol" registry (https://www.iana.org/assignments/nsh/
   nsh.xhtml#next-protocol):

> 
> - Section 5: Another incorrect reference needs to be corrected. "For
> additional
> IOAM related security considerations, see Section 10 in [RFC9197].". It is
> actually section 9 of that RFC so please correct the reference.

...FB: Corrected in version 12.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> General comment. There are several typos or grammatical errors in the
> document.
> Suggest running an error checker against the document.
> 
> Section 1: "In-situ OAM (IOAM)" in the first sentence does not need to be
> expanded as the authors already did so in the abstract.

...FB: Fixed.

> 
> Section 1: "Service Function Chaining (SFC) [RFC7665]" should read "Service
> Function Chaining (SFC) Architecture [RFC7665]".

...FB: Fixed.

> 
> Section 3: 6th sentence use of "service path" should probably be changed
> to the
> correct terminology used by the SFC architecture which is Service Function
> Path
> (SFP). Further, the next sentence should be folded into the 6th sentence as
> a
> single sentence to make it more readable.

...FB: Fixed.

> 
> Section 3: "See [I-D.ietf-ippm-ioam-deployment] for a discussion of
> deployment
> related aspects of IOAM-Data-fields.". This reference should be changed to
> [RFC9378].
> 
> Section 3: "[I-D.ietf-ippm-ioam-flags]". This reference should be changed to
> [RFC9322].
> 
> Several outdated references need to be updated:
> 
>   == Outdated reference: A later version (-03) exists of
>      draft-ietf-sfc-oam-packet-01
> 
>   == Outdated reference: draft-ietf-ippm-ioam-deployment has been
> published
>      as RFC 9378
> 
>   == Outdated reference: draft-ietf-ippm-ioam-direct-export has been
>      published as RFC 9326
> 
>   == Outdated reference: draft-ietf-ippm-ioam-flags has been published as
> RFC
>      9322
> 
> 

...FB: All the references were updated.

Thanks again for the review.

Cheers, Frank