Re: [auth48] [ADs] AUTH48: RFC-to-be 9359 <draft-ietf-ippm-ioam-conf-state-10> for your review

[Greg Mirsky <[e-mail]>]

Hi Xiao Min,
thank you for your kind consideration of my answers.

Dear RFC Editor,
it seems like Xiao Min and I have agreed on our responses to your
questions. Please advise of any further steps we need to make.

Regards,
Greg

On Thu, Mar 9, 2023 at 5:31 PM <[e-mail]> wrote:

> Thank you for the reply, Greg.
>
> Please see inline...
> Original
> *From: *GregMirsky <[e-mail]>
> *To: *[e-mail] <[e-mail]>;
> *Cc: *[e-mail] <[e-mail]>;[e-mail] <
> [e-mail]>;[e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>;肖敏10093570;
> *Date: *2023年03月10日 06:21
> *Subject: **Re: [ADs] AUTH48: RFC-to-be 9359
> <draft-ietf-ippm-ioam-conf-state-10> for your review*
> Dear RFC Editor,
> thank you for your thoughtful questions. Please find my answers in-line
> below under the GIM>> tag. I have two alternative proposals. Please let me
> know if you have any questions.
>
> Regards,
> Greg
>
> On Tue, Mar 7, 2023 at 7:13 PM <[e-mail]> wrote:
>
>> Dear RFC Editor,
>>
>>
>> Many thanks for your effort.
>>
>> Please see inline...
>> Original
>> *From: *[e-mail] <[e-mail]>
>> *To: *肖敏10093570;[e-mail] <[e-mail]>;
>> [e-mail] <[e-mail]>;
>> *Cc: *[e-mail] <[e-mail]>;
>> [e-mail] <[e-mail]>;[e-mail] <
>> [e-mail]>;[e-mail] <
>> [e-mail]>;[e-mail] <
>> [e-mail]>;[e-mail] <
>> [e-mail]>;
>> *Date: *2023年03月07日 11:50
>> *Subject: **Re: [ADs] AUTH48: RFC-to-be 9359
>> <draft-ietf-ippm-ioam-conf-state-10> for your review*
>> Authors and *ADs,
>>
>> [*ADs - please see question 9 below.]
>>
>>
>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions,
>>  which are also in the XML file.
>>
>>
>> 1) <!-- [rfced] We had the following questions regarding the document's title.
>>
>> a) Please note that the title of the document has been
>>      updated as follows to more similarly match related recently
>>      published RFCs.
>>
>> Original:
>> Echo Request/Reply for Enabled In-situ OAM Capabilities
>>
>> Current:
>> Echo Request/Reply for Enabled In Situ OAM (IOAM) Capabilities
>>
>> [XM]>>> This change looks good to me.
>>
> GIM>> I agree with the proposed update of the title.
>
>>
>> b) Please review the short title of the document as "Ping" is only mentioned
>>
>> briefly in this document.
>>
>> Original:
>> Ping Enabled IOAM Capabilities
>>
>> [XM]>>> "Ping" is used widely, so I lean to remain it as is.
>>
> GIM>> "Ping" is synonymous with Echo Request/Reply and traditionally used
> as a shorter version. I think that is quite fitting for the short title.
>
>> -->
>>
>>
>>
>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the
>> title) for use on https://www.rfc-editor.org/search.
>>
>> [XM]>>> IPv6, MPLS, SFC, BIER.
>>
> GIM>> I agree with Xiao Min's proposal.
>
>> -->
>>
>>
>> 3) <!-- [rfced] FYI, to avoid run-on sentence structure, we updated this
>> following paragraph (adding "and" in "... NETCONF Client, and each IOAM
>> ...." and adding "so" in "... NETCONF Server, so complexity can be
>> ...."). Please let us know any objections.
>>
>> Original:
>>    *  When NETCONF/YANG is used in this scenario, each IOAM
>>       encapsulating node (including the host when it takes the role of
>>       an IOAM encapsulating node) needs to implement a NETCONF Client,
>>       each IOAM transit and IOAM decapsulating node (including the host
>>       when it takes the role of an IOAM decapsulating node) needs to
>>       implement a NETCONF Server, the complexity can be an issue.
>>       Furthermore, each IOAM encapsulating node needs to establish a
>>       NETCONF Connection with each IOAM transit and IOAM decapsulating
>>       node, so scalability can be an issue.
>>
>> Current:
>>    *  When NETCONF/YANG is used in this scenario, each IOAM
>>       encapsulating node (including the host when it takes the role of
>>       an IOAM encapsulating node) needs to implement a NETCONF Client,
>>
>>       and each IOAM transit and IOAM decapsulating node (including the host
>>       when it takes the role of an IOAM decapsulating node) needs to
>>       implement a NETCONF Server, so complexity can be an issue.
>>       Furthermore, each IOAM encapsulating node needs to establish a
>>       NETCONF Connection with each IOAM transit and IOAM decapsulating
>>       node, so scalability can be an issue.
>>
>> [XM]>>> No objection.
>>
> GIM>> I agree with the proposed update; thank you.
>
>> -->
>>
>>
>> 4) <!--[rfced] This text may need some clarification.  If the "perhaps"
>>      text does not convey the intended meaning, please rephrase.
>>
>> Original:
>>    SoP (Size of POT) field has two bits, which means the size of "PktID"
>>    and "Cumulative" data that are specified in Section 4.5 of [RFC9197].
>>
>> Perhaps:
>>    The SoP (Size of POT) field has two bits, which means the size of
>>    "PktID" and "Cumulative" data are those that are specified in
>>    Section 4.5 of [RFC9197].
>>
>> [XM]>>> How about:
>>
>>    The SoP (Size of POT) field has two bits, which means the size of
>>    "PktID" and "Cumulative" data, the two data are specified in
>>    Section 4.5 of [RFC9197].
>>
> GIM>> I would propose another editorial update:
> OLD TEXT:
>    SoP (Size of POT) field has two bits, which means the size of "PktID"
>    and "Cumulative" data that are specified in Section 4.5 of [RFC9197].
> NEW TEXT:
>    SoP (Size of POT) field has two bits that indicate the size of "PktID"
>    and "Cumulative" data, which are specified in Section 4.5 of [RFC9197].
>
> WDYT?
>
> [XM-2]>>> The new text proposed by Greg looks good to me.
>
>> -->
>>
>>
>> 5) <!-- [rfced] FYI - we have updated this text to use a list format for
>>      the ease of the reader.  Please let us know any objections.
>>
>> Original:
>>    Once the IOAM encapsulating node is triggered to discover the enabled
>>    IOAM capabilities of each IOAM transit and IOAM decapsulating node,
>>    the IOAM encapsulating node will send echo requests that include the
>>    IOAM Capabilities Query Container.  First, with TTL equal to 1 to
>>    reach the closest node, which may be an IOAM transit node or not.
>>    Then with TTL equal to 2 to reach the second-nearest node, which also
>>    may be an IOAM transit node or not.  And further, increasing by 1 the
>>    TTL every time the IOAM encapsulating node sends a new echo request,
>>    until the IOAM encapsulating node receives an echo reply sent by the
>>    IOAM decapsulating node, which contains the IOAM Capabilities
>>    Response Container including the IOAM Edge-to-Edge Capabilities
>>    Object or the IOAM End-of-Domain Object.
>>
>> Current:
>>    Once the IOAM encapsulating node is triggered to discover the enabled
>>    IOAM capabilities of each IOAM transit and IOAM decapsulating node,
>>    the IOAM encapsulating node will send echo requests that include the
>>    IOAM Capabilities Query Container as follows:
>>
>>    *  First, with TTL equal to 1 to reach the closest node (which may or
>>       may not be an IOAM transit node).
>>
>>    *  Then, with TTL equal to 2 to reach the second-nearest node (which
>>       also may or may not be an IOAM transit node).
>>
>>    *  Then, further increasing by 1 the TTL every time the IOAM
>>       encapsulating node sends a new echo request, until the IOAM
>>       encapsulating node receives an echo reply sent by the IOAM
>>       decapsulating node (which contains the IOAM Capabilities Response
>>       Container including the IOAM Edge-to-Edge Capabilities Object or
>>       the IOAM End-of-Domain Object).
>>
>> [XM]>>> No objection. And I suggest to separate "Alternatively, if the
>> IOAM encapsulating node...without TTL expiration." from the following
>> paragraph, into a new paragraph.
>>
> GIM>> I agree with the proposed update. And I support the update proposed
> by Xuiao Min.
>
>> -->
>>
>>
>> 6) <!--[rfced] We do not see "RFC Required" mentioned at
>> https://www.iana.org/assignments/ioam-capabilities/ioam-capabilities.xhtml
>> .
>>
>> Please let us know if the registry needs an update of if the following text in this
>>
>> document needs an update.
>>
>> Original:
>>    New registries in this group can be created via RFC Required process
>>    as per [RFC8126].
>> [XM]>>> Please remove this sentence.
>>
> GIM>> I agree with Xiao Min's resolution.
>
>> -->
>>
>>
>>
>> 7) <!-- [rfced] FYI, to make the hierarchy of phrases ("whether ...", "whether
>> ....", and "once ...") more clear, we updated the example in the sentence
>> to the following. Please let us know any objections.
>>
>> Original:
>>    An implementation can also check whether the fields in received echo
>>    requests and replies strictly conform to the specifications, e.g.,
>>    whether the list of IOAM Namespace-IDs includes duplicate entries,
>>    whether the received Namespace-ID is an operator-assigned or IANA-
>>    assigned one, once a check fails, an exception event indicating the
>>    checked field should be reported to the management.
>>
>> Current:
>>    An implementation can also check whether the fields in received echo
>>    requests and replies strictly conform to the specifications, e.g.,
>>    whether the list of IOAM Namespace-IDs includes duplicate entries
>>    and whether the received Namespace-ID is an operator-assigned or IANA-
>>    assigned one, once a check fails, an exception event indicating the
>>    checked field should be reported to the management.
>>
>> [XM]>>> No objection.
>>
> GIM>> I agree with the proposed update.
>
>> -->
>>
>>
>> 8) <!-- [rfced] For the reference entry for [I-D.ietf-bier-ping], the
>>      first author's name appears differently in various locations. How
>>      may we update for accuracy and consistency?
>>
>> "N. Kumar" in original
>> "N.K. Nainar" in current (xi:include)
>> "N. Nainar" in past RFCs
>>
>> [XM]>>> I believe the current one is up-to-date.
>>
> GIM>> I've checked published RFCs, e.g., RFC 8029. It appears that N.
> Kumar is the right form.
>
> [XM-2]>>> I checked the latest one RFC 9214, where "N. Nainar" is used.
> Considering his full name "Nagendra Kumar Nainar", I believe "N.K. Nainar"
> is up-to-date. Anyway, either one works for me. :)
>
>> -->
>>
>>
>> 9) <!-- [rfced] *ADs - please review and approve the changes to Sections
>>      1, 2.2, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.2.4, 3.2.5, and 3.2.6 that
>>      were submitted by the authors while this document was in our
>>      queue. They are as follows:
>>
>>
>> Section 1:
>>
>> a)
>> Original:
>>       Furthermore, each IOAM encapsulating node needs to establish
>>       NETCONF Connection with each IOAM transit and IOAM decapsulating
>>       node, the scalability can be an issue.
>>
>> Updated:
>>       Furthermore, each IOAM encapsulating node needs to establish a
>>       NETCONF Connection with each IOAM transit and IOAM decapsulating
>>       node, so scalability can be an issue.
>>
>> b)
>> Original:
>>    Fate sharing is a common requirement for all kinds of active OAM
>>    packets, echo request is among them, in this document that means echo
>>    request is required to traverse a path of IOAM data packet.  This
>>    requirement can be achieved by, e.g., applying same explicit path or
>>    ECMP processing to both echo request and IOAM data packet.  Specific
>>
>>    to apply same ECMP processing to both echo request and IOAM data
>>    packet, one possible way is to populate the same value(s) of ECMP
>>    affecting field(s) in the echo request.
>>
>> Updated:
>>    Fate sharing is a common requirement for all kinds of active OAM
>>    packets including echo request.  In this document that means echo
>>    request is required to traverse the path of an IOAM data packet.
>>    This requirement can be achieved by, e.g., applying the same explicit
>>    path or ECMP processing to both echo request and IOAM data packets.
>>    Specifically, the same ECMP processing can be applied to both echo
>>    request and IOAM data packets, by populating the same value(s) in
>>    ECMP affecting field(s) of the packets.
>>
>> ......
>>
>> Section 2.2:
>>
>> Added to Abbreviations List:
>>    SoP: Size of POT
>>    TSF: TimeStamp Format
>> ......
>>
>> Section 3.2:
>>
>> Original:
>>    A list of IOAM capabilities objects (one
>>    or more objects) which contains the enabled IOAM capabilities MUST be
>>    included in this container of echo reply except the sender encounters
>>    an error (e.g., no matched Namespace-ID).
>>
>> Updated:
>>    A list of IOAM capabilities objects (one
>>    or more objects) which contains the enabled IOAM capabilities MUST be
>>    included in this container of echo reply unless the sender encounters
>>    an error (e.g., no matched Namespace-ID).
>>
>> ......
>>
>> Sections 3.2.1, 3.2.2, 3.2.3, 3.2.4, and 3.2.5:
>>
>> Original:
>>    Reserved field is reserved for future use and MUST be set to zero,
>>    and MUST be ignored when non-zero.
>>
>> Updated:
>>    Reserved field MUST be zeroed on transmission and ignored on receipt.
>>
>> ......
>>
>> Section 3.2.6:
>>
>> a)
>> Original (in table):
>>    Must Be Zero
>>
>> Updated:
>>    Reserved
>>
>> b)
>> Original:
>>    When the IOAM
>>    edge-to-edge function is enabled at the IOAM decapsulating node, it's
>>    RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities Object
>>    but not the IOAM End-of-Domain Object.
>>
>> Updated:
>>    When the IOAM
>>    edge-to-edge function is enabled at the IOAM decapsulating node,
>>    including only the IOAM Edge-to-Edge Capabilities Object but not the
>>    IOAM End-of-Domain Object is RECOMMENDED.
>>
>> c)
>> Added paragraph at end of section:
>>    Reserved field MUST be zeroed on transmission and ignored on receipt.
>>
>> ......
>>
>> Acknowledgements:
>>    Added "Donald Eastlake")
>>
>> Original:
>>    The authors would like to acknowledge Tianran Zhou, Dhruv Dhody,
>>    Frank Brockners, Cheng Li, Gyan Mishra, Marcus Ihlar, Martin Duke,
>>    Chris Lonvick, Eric Vyncke, Alvaro Retana, Paul Wouters, Roman
>>    Danyliw, Lars Eggert, Warren Kumari, John Scudder, Robert Wilton,
>>    Erik Kline, Zaheduzzaman Sarker and Murray Kucherawy for their
>>    careful review and helpful comments.
>>
>> Updated:
>>    The authors would like to acknowledge Tianran Zhou, Dhruv Dhody,
>>    Frank Brockners, Cheng Li, Gyan Mishra, Marcus Ihlar, Martin Duke,
>>    Chris Lonvick, Eric Vyncke, Alvaro Retana, Paul Wouters, Roman
>>    Danyliw, Lars Eggert, Warren Kumari, John Scudder, Robert Wilton,
>>    Erik Kline, Zaheduzzaman Sarker, Murray Kucherawy, and Donald Eastlake
>>    for their careful review and helpful comments.
>> -->
>>
>>
>> 10) <!--[rfced] Terminology: we had the following questions related to the use of terminology
>>
>> throughout the document.
>>
>> a) IOAM domain: we see "IOAM-Domain" in RFC 9197.  Please let us know if this term should be
>>
>> updated in this document.
>>
>> [XM]>>> Yes, this term should be updated in this document.
>>
> GIM>> Thank you for pointing this out. You're correct, should use
> IOM-Domain.
>
>>
>> b) Please review the use of both "Object Header" and "object header" in the body of Section 3.2.
>>
>>
>> Should the capping scheme be made uniform there?  Note also that we see "Object" capped in the first sentence of all of the 3.2.* subsections.  Please confirm that this should not be made "object" or updated to the full name (e.g., in Section 3.2.6: "When the IOAM End-of-Domain Object is present...").
>>
>> [XM]>>> Please do s/Object Header/object header in the body of Section
>> 3.2. Please do s/Object/the-full-name in the first sentence of all of the
>> 3.2.* subsections.
>>
> GIM>> It seems to me that in
>    Similar to the container, each object has an object header that is
>    used to identify the type and length of the object payload.
>
> "object header" refers to the field by its shortened name. If that is
> right, I think that capitalization is needed. WDYT?
>
> [XM-2]>>> Make sense to me. To RFC Editor, Please do s/object
> header/Object Header in the body of Section 3.2. Please do
> s/Object/the-full-name in the first sentence of all of the 3.2.*
> subsections.
>
>
> Cheers,
>
> Xiao Min
>
>>
>> c) Should IOAM be added here?
>>
>> Original:
>>    ...the End-of-Domain Object MUST be present in the IOAM Capabilities
>>    Response Container sent by an IOAM decapsulating node.
>>
>> Perhaps:
>>
>>    ...the IOAM End-of-Domain Object MUST be present in the IOAM Capabilities
>>    Response Container sent by an IOAM decapsulating node.-->
>> [XM]>>> Yes, IOAM should be added here.
>>
> GIM>> I agree as well.
>
>>
>> Best Regards,
>>
>> Xiao Min
>>
>>
>> Thank you.
>>
>> RFC Editor/st/mf
>>
>> *****IMPORTANT*****
>>
>> Updated 2023/03/06
>>
>> RFC Author(s):
>> --------------
>>
>> Instructions for Completing AUTH48
>>
>> Your document has now entered AUTH48.  Once it has been reviewed and
>> approved by you and all coauthors, it will be published as an RFC.
>> If an author is no longer available, there are several remedies
>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>
>> You and you coauthors are responsible for engaging other parties
>> (e.g., Contributors or Working Group) as necessary before providing
>> your approval.
>>
>> Planning your review
>> ---------------------
>>
>> Please review the following aspects of your document:
>>
>> *  RFC Editor questions
>>
>>    Please review and resolve any questions raised by the RFC Editor
>>    that have been included in the XML file as comments marked as
>>    follows:
>>
>>    <!-- [rfced] ... -->
>>
>>    These questions will also be sent in a subsequent email.
>>
>> *  Changes submitted by coauthors
>>
>>    Please ensure that you review any changes submitted by your
>>    coauthors.  We assume that if you do not speak up that you
>>    agree to changes submitted by your coauthors.
>>
>> *  Content
>>
>>    Please review the full content of the document, as this cannot
>>    change once the RFC is published.  Please pay particular attention to:
>>    - IANA considerations updates (if applicable)
>>    - contact information
>>    - references
>>
>> *  Copyright notices and legends
>>
>>    Please review the copyright notice and legends as defined in
>>    RFC 5378 and the Trust Legal Provisions
>>    (TLP – https://trustee.ietf.org/license-info/).
>>
>> *  Semantic markup
>>
>>    Please review the markup in the XML file to ensure that elements of
>>    content are correctly tagged.  For example, ensure that <sourcecode>
>>    and <artwork> are set correctly.  See details at
>>    <https://authors.ietf.org/rfcxml-vocabulary>.
>>
>> *  Formatted output
>>
>>    Please review the PDF, HTML, and TXT files to ensure that the
>>    formatted output, as generated from the markup in the XML file, is
>>    reasonable.  Please note that the TXT will have formatting
>>    limitations compared to the PDF and HTML.
>>
>>
>> Submitting changes
>> ------------------
>>
>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>> the parties CCed on this message need to see your changes. The parties
>> include:
>>
>>    *  your coauthors
>>
>>    *  [e-mail] (the RPC team)
>>
>>    *  other document participants, depending on the stream (e.g.,
>>       IETF Stream participants are your working group chairs, the
>>       responsible ADs, and the document shepherd).
>>
>>    *  [e-mail], which is a new archival mailing list
>>
>>       to preserve AUTH48 conversations; it is not an active discussion
>>       list:
>>
>>      *  More info:
>>
>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>>
>>      *  The archive itself:
>>         https://mailarchive.ietf.org/arch/browse/auth48archive/
>>
>>      *  Note: If only absolutely necessary, you may temporarily opt out
>>
>>         of the archiving of messages (e.g., to discuss a sensitive matter).
>>         If needed, please add a note at the top of the message that you
>>         have dropped the address. When the discussion is concluded,
>>         [e-mail] will be re-added to the CC list and
>>
>>         its addition will be noted at the top of the message.
>>
>> You may submit your changes in one of two ways:
>>
>> An update to the provided XML file
>>  — OR —
>> An explicit list of changes in this format
>>
>> Section # (or indicate Global)
>>
>> OLD:
>> old text
>>
>> NEW:
>> new text
>>
>> You do not need to reply with both an updated XML file and an explicit
>> list of changes, as either form is sufficient.
>>
>> We will ask a stream manager to review and approve any changes that seem
>> beyond editorial in nature, e.g., addition of new text, deletion of text,
>>
>> and technical changes.  Information about stream managers can be found in
>>
>> the FAQ.  Editorial changes do not require approval from a stream manager.
>>
>>
>> Approving for publication
>> --------------------------
>>
>> To approve your RFC for publication, please reply to this email stating
>> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
>> as all the parties CCed on this message need to see your approval.
>>
>>
>> Files
>> -----
>>
>> The files are available here:
>>    https://www.rfc-editor.org/authors/rfc9359.xml
>>    https://www.rfc-editor.org/authors/rfc9359.html
>>    https://www.rfc-editor.org/authors/rfc9359.pdf
>>    https://www.rfc-editor.org/authors/rfc9359.txt
>>
>> Diff file of the text:
>>    https://www.rfc-editor.org/authors/rfc9359-diff.html
>>    https://www.rfc-editor.org/authors/rfc9359-rfcdiff.html (side by side)
>>
>> Diff of the XML:
>>    https://www.rfc-editor.org/authors/rfc9359-xmldiff1.html
>>
>> The following files are provided to facilitate creation of your own
>> diff files of the XML.
>>
>> Initial XMLv3 created using XMLv2 as input:
>>    https://www.rfc-editor.org/authors/rfc9359.original.v2v3.xml
>>
>> XMLv3 file that is a best effort to capture v3-related format updates
>> only:
>>    https://www.rfc-editor.org/authors/rfc9359.form.xml
>>
>>
>> Tracking progress
>> -----------------
>>
>> The details of the AUTH48 status of your document are here:
>>    https://www.rfc-editor.org/auth48/rfc9359
>>
>> Please let us know if you have any questions.
>>
>> Thank you for your cooperation,
>>
>> RFC Editor
>>
>> --------------------------------------
>> RFC9359 (draft-ietf-ippm-ioam-conf-state-10)
>>
>> Title            : Echo Request/Reply for Enabled In-situ OAM Capabilities
>> Author(s)        : X. Min, G. Mirsky, L. Bo
>> WG Chair(s)      : Marcus Ihlar, Tommy Pauly
>> Area Director(s) : Martin Duke, Zaheduzzaman Sarker
>>
>>
>>
>>
>