Re: [sfc] John Scudder's No Objection on draft-ietf-sfc-ioam-nsh-11: (with COMMENT)

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

Hi John,

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: John Scudder via Datatracker <[e-mail]>
> Sent: Monday, 1 May 2023 16:38
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: John Scudder's No Objection on draft-ietf-sfc-ioam-nsh-11: (with
> COMMENT)
> 
> John Scudder has entered the following ballot position for
> draft-ietf-sfc-ioam-nsh-11: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # John Scudder, RTG AD, comments for draft-ietf-sfc-ioam-nsh-11
> CC @jgscudder
> 
> Thanks for this document. I have a few brief comments.
> 
> ## COMMENTS
> 
> ### Section 1, implementation
> 
> "An implementation of IOAM which leverages NSH to carry the IOAM data
> is
> available from the FD.io open source software project [FD.io]."
> 
> - Is it appropriate to include this here? If you wanted to flag this for
> reviewers' and WG's information, maybe following the practice
> recommended in
> RFC 7942 would be better? That document makes the case (Section 2) for
> not
> leaving it in the RFC:
> 
>    Since this information is necessarily time dependent, it is
>    inappropriate for inclusion in a published RFC.
> 
> - The contradiction with the shepherd writeup is a little concerning:
> "Although
> no implementations have been reported..." The shepherd writeup was last
> updated
> in July of 2022 but the draft text appears to have been present since the 01
> version published March 11, 2019.

...FB: Mirja had a similar comment. We've removed the reference to the open source implementation.
Just for the sake of completeness, the implementation in FD.io was done in 2019 - see e.g. https://docs.fd.io/vpp/19.04/clicmd_src_plugins_nsh_nsh-md2-ioam.html

> 
> ### Section 3, header length
> 
> Perhaps in "IOAM HDR Len: 8 bit Length field contains the length of the
> IOAM
> header in 4-octet units", mention that the length covers the type and length
> fields? I think this is already implicit in what you've written, but better
> explicit than implicit.

...FB: Thanks. Now it is explicit:

      IOAM HDR Len:  8-bit field that contains the length of the IOAM
         header in multiples of 4-octets, including the "IOAM-Type" and
         "IOAM HDR Len" fields.

> 
> ### Section 5, "several operators"
> 
> I support Roman Danyliw's DISCUSS.

...FB: Fixed. We're back to a single operator :-)


Thanks again for your review.

Cheers, Frank
> 
> ## Notes
> 
> This review is in the ["IETF Comments" Markdown format][ICMF], You can
> use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
> 
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
> 
>