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

[Roman Danyliw <[e-mail]>]

Hi Frank!

Thanks for this follow-up explanation and the revised text in -12.  I've cleared my ballot.

Roman

> -----Original Message-----
> From: Frank Brockners (fbrockne) <[e-mail]>
> Sent: Thursday, May 4, 2023 4:24 PM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-sfc-ioam-nsh-11: (with
> DISCUSS and COMMENT)
> 
> 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