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

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

Hi Roman,

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: Roman Danyliw via Datatracker <[e-mail]>
> Sent: Monday, 1 May 2023 16:36
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Roman Danyliw's Discuss on draft-ietf-sfc-ioam-nsh-11: (with
> DISCUSS and COMMENT)
> 
> Roman Danyliw 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:
> ----------------------------------------------------------------------
> 
> (revised ballot)
> 
> ** Section 5.
>    IOAM is considered a "per domain" feature, where one or several
>    operators decide on leveraging and configuring IOAM according to
>    their needs.
> 
> This seems like an an expansion of the applicability statement of IOAM.  I
> don’t see reference to multiple operators in Section 3 of RFC9197.  Please
> explicitly cite the RFC9197 applicability statement to be clear that scope is
> not being expanded and and consider if discussion of multiple operators is
> needed.
> 
...FB: This is a good catch. The new rev -12 now refers to a single operator only.

IOAM is considered a "per domain" feature, where the operator decides
   on leveraging and configuring IOAM according to the operator's needs.


> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Jim Guichard's DISCUSS position on clarifying Section 3's text:
> "[t]he operator MUST ensure that all nodes along the service path support
> IOAM.
>  Otherwise   packets with IOAM are likely to be dropped per [RFC8300]."
> 
> ** Section 5. Wrong reference. (Same observation as Jim)
> 
>    For additional IOAM
>    related security considerations, see Section 10 in [RFC9197].
> 
> s/see Section 10/see Section 9/.
> 
> 

...FB: Thanks. The reference were corrected.

Thanks again for your review.

Cheers, Frank