Thanks for your quick response.

See below at <de>.

On Wed, Dec 14, 2022 at 4:49 AM <xiao.min2@zte.com.cn> wrote:

> Hi Donald,
>
> Thank you for the review and thoughtful comments.
>
> I'll attempt to address your comments, although the relevant document is
> already in RFC Editor's Queue.
>

<de> You're welcome. For some reason I was asked to review your draft after
it was in the RFC Editor's Queue so I'm not sure what will happen to
comment resolutions.

Please see inline my responses...
>
>
> Best Regards,
>
> Xiao Min
> Original
> *From: *DonaldEastlake <d3e3e3@gmail.com>
> *To: *<rtg-ads@ietf.org> <rtg-ads@ietf.org>;
> *Cc: *rtg-dir@ietf.org <rtg-dir@ietf.org>;
> draft-ietf-ippm-ioam-conf-state.all@ietf.org <
> draft-ietf-ippm-ioam-conf-state.all@ietf.org>;ippm@ietf.org <ippm@ietf.org
> >;Last Call <last-call@ietf.org>;
> *Date: *2022年12月14日 02:50
> *Subject: **[ippm] RtgDir Last Call review:
> draft-ietf-ippm-ioam-conf-state-10 (really, this time)*
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> Document: draft-ietf-ippm-ioam-conf-state-10
> Reviewer: Donald Eastlake 3rd
> Review Date: 13 December 2022
> IETF LC End Date:
> Intended Status: Standards Track
>
>
> Summary:
>
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
>
> Comments:
>
> This document is reasonably well written but has some minor issues and
> occasionally scattered grammatical slips.
>
>
> Major Issues:
>
> No major issues found.
>
>
> Minor Issues:
>
> Section 3.1: Concerning the list of IOAM Namespace-IDs, it states that
> Namespace-ID 0x000 MUST be first, any other occurrences of 0x000 MUST
> be disregarded. This naturally leads me to the following:
>    If there are multiple occurrences of other Namespace-IDs, are all but
>
> the first ignored?
>
> [XM]>>> As stated in section 6, duplicate IOAM Namespace-IDs is an error.
>    Is there any ordering requirement on any Namespace-IDs after the
>
> 0x0000 and, if so, how are out-of-order Namespace IDs handled?
>
> [XM]>>> No.
>
<de> OK. If it is convenient to modify the document, I think it would be
good to mention earlier in the document, where Namespace-IDs are first
mentioned, that duplicates are an error and that, except for the
requirement that 0x0000 be first, the Namespace-IDs can be in any order.


> Section 4: There is some unstated assumption here that IOAM capability
> information is wanted for a specific known unicast path. I think this
>
> assumption should be made explicit.
>
> [XM]>>> For IPv6, IOAM Capabilities Query would be sent to the known IOAM
> transit/decap nodes. For MPLS, IOAM Capabilities Query would be sent to the
> egress node and intercepted by the transit node through TTL expiration.
>
<de> I was primarily wondering about multicast.


> SoP / TSF:
> - Either these need to be spelled out in the registry names for the
> registries being created in Section 5 or each registry with such an
> abbreviation in its registry name needs a note that includes the
>
> abbreviation expansion.
>
> [XM]>>> In section 5.1, it says "SoP: size of POT"; In section 5.2, it
> says "TSF: timestamp format". Do you see a need for some new text?
>
<de> I think that text just in this draft is not sufficient. Someone
looking at the Registries on the IANA web pages needs a bit more
explanation. Of course, I suppose the RFC this draft is published as will
be listed as a Reference from the IANA Registries which helps a lot. And
maybe IANA will spontaneously put a little of this text into a Note at the
beginning of each registry...

> - Suggest adding these to Section 2.2 Abbreviations.
>
> [XM]>>> OK.
>
> Section 6, Page 16:
> - There are two paragraphs in Section 6 where the first talks about
> IOAM Capability information being carried across the network and the
> second talks about collected IOAM Capability information. The first
> paragraph reasonably gives example security methods for data in
> transit. The second paragraph, however, does not mention or give an
> example of how to protect collected information, which is presumably
> data at rest. As it is, the paragraphs are mostly redundant except for
> the first sentence of the 2nd paragraph. Suggest changing the 2nd
> paragraph by replacing the existing material after the first sentence
> with something like "Care should therefore be taken to limit access to
> such collected IOAM Capabilities information."
> - In the next to the last paragraph of Section 6, we first learn that
> duplicate IAOM Namespace-IDs is an error. This should be mentioned
> earlier where Namespace-IDs in messages is first discussed. This
> paragraph also lists "whether the received Namespace-ID is an
> operator-assigned or IANA-assigned one" as if that was an error
> condition, which I don't understand.
> [XM]>>> At this point, I prefer not to change section 6 in any way. As to
> the text "whether the received Namespace-ID is an operator-assigned or
> IANA-assigned one", it's from RFC 9197 which says "
>
> The Namespace-ID value is divided into two subranges:
> <https://www.rfc-editor.org/rfc/rfc9197#section-4.3-2>
>
>    -
>
>    an operator-assigned range from 0x0001 to 0x7FFF and
>    <https://www.rfc-editor.org/rfc/rfc9197#section-4.3-3.1>
>    -
>
>    an IANA-assigned range from 0x8000 to 0xFFFF.
>
> <de> Yes, I understand there are two ranges of IDs but they are mentioned
here in the Security Considerations section in a paragraph about checking
that "the fields in received echo requests and replies strictly conform to
the specifications". I wasn't sure what being operator-assigned or
IANA-assigned had to do with strictly conforming to the specifications.

<de> Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com


> Nits:
>
> Section 1, page 3:
> OLD
>    Furthermore, each IOAM encapsulating node needs to establish
>    NETCONF Connection with each IOAM transit and IOAM decapsulating
>    node, the scalability can be an issue.
> NEW
>    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.
>
> Section 1, Page 4/5:
> OLD
>    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.
> NEW
>    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 3.2, Page 7:
> "reply except the" -> "reply unless the"
>
> Section 3.2.6, Page 13:
> OLD
>    it's
>    RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities Object
>    but not the IOAM End-of-Domain Object.
> NEW
>    including only the IOAM Edge-to-Edge Capabilities Object
>    but not the IOAM End-of-Domain Object is RECOMMENDED.
>
> Multiple sections: It is just a tiny bit confusing that many fields
> that are to be sent as zero and ignored on receipt are labeled with
> the ordinary capitalized word "Reserved". Suggest that you consider
> using "MBZ" or "RES" or even "RESERVED" so you don't end up
> duplicating the word when you say "Reserved field is reserved ..."
> In Section 3.2.6, however, there is a "Must Be Zero" field and,
> although all the fields are explained in other cases, there is no
> explanation below for that field.
>
>
> [XM]>>> Thank you for catching the Nits. Will work with RFC Editor to
> address them.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
>
>