Re: [sfc] Adoption call for draft-boucadair-sfc-oam-packet-03.txt

Hi Carlos,

Thank you much for this feedback. I updated the text to reflect your input as you can see at: https://tinyurl.com/sfc-oam-packet-latest

Please see also inline for more context.

If any further changes are needed, please let me know. Thanks.

Cheers,
Med

De : sfc <sfc-bounces@ietf.org> De la part de Carlos Pignataro (cpignata)
Envoyé : jeudi 24 mars 2022 19:20
À : Joel M. Halpern <jmh@joelhalpern.com>
Cc : sfc@ietf.org
Objet : Re: [sfc] Adoption call for draft-boucadair-sfc-oam-packet-03.txt

Hi, Joel, WG,

I support this adoption call.

I feel the approach of a surgical, self-contained approach to clarifying the O-bit behavior is most effective, and support this approach.

I believe that the content is clear, deliberate, unambiguous, and useful. More than a great start.

Many thanks Med for taking on this work an producing this I-D.

A couple of questions / comments for consideration:

  *   Is the document about "OAM Behavior” in NSH, “O-bit” in the NSH header (as S2.2 of RFC 8300), or both? The title should reflect that. The abstract says it’s about the NSH header and definition of OAM Packet.
[Med] Agree. Went for “OAM Packet and Behavior in the Network Service Header (NSH)”

  *   S2 terminology: The OAM control element “generates” OAM packets. What about an element that can “process” OAM packets?
[Med] That element can set the bit if a response is triggered as part of that processing. Otherwise, the element follows: “The O bit MUST NOT be modified along the SFP”. Do you have in mind something more to say there? Thanks.

  *   S2 terminology: OAM Data: it says refers to an “OAM command” but that terminology does not exist in RFC 7276.
[Med] Yes. This term is a generalization of methods such as those defined in 7276 as per this text: “refers to an OAM command (e.g., Connectivity Verification and Continuity Checks [RFC7276]),”. I changed that term to “OAM request” to be close to what we can kind find in 7276. Hope that is better.

  *   S3, last paragraph, or Security Considerations — might be useful to also cite / reference RFC 8924.
[Med] Agree.

Thanks again,

Carlos.

On Mar 7, 2022, at 9:52 AM, Joel M. Halpern <jmh@joelhalpern.com<mailto:jmh@joelhalpern.com>> wrote:

This starts the SFC adoption call for

https://datatracker.ietf.org/doc/html/draft-boucadair-sfc-oam-packet-03

Please respond indicating support or opposition to this adoption call. With explanation of why you support or oppose this.

We will run this call through the end of the IETF meeting, i.e. Through March 25-2022.

Also, authors (and contributors if any) please confirm to the list that all known IPR has been disclosed.

Thank you,
Joel

_______________________________________________
sfc mailing list
sfc@ietf.org<mailto:sfc@ietf.org>
https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.