Thanks for your quick response.
See below at <de>.
On Wed, Dec 14, 2022 at 4:49 AM <xiao.min2@xxxxxxxxxx> 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
OriginalFrom: DonaldEastlake <d3e3e3@xxxxxxxxx>To: <rtg-ads@xxxxxxxx> <rtg-ads@xxxxxxxx>;Cc: rtg-dir@xxxxxxxx <rtg-dir@xxxxxxxx>;draft-ietf-ippm-ioam-conf-state.all@xxxxxxxx <draft-ietf-ippm-ioam-conf-state.all@xxxxxxxx>;ippm@xxxxxxxx <ippm@xxxxxxxx>;Last Call <last-call@xxxxxxxx>;Date: 2022年12月14日 02:50Subject: [ippm] RtgDir Last Call review: draft-ietf-ippm-ioam-conf-state-10 (really, this time)_______________________________________________
ippm mailing list
ippm@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ippmHello,
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 butthe 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 the0x0000 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 thisassumption 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 theabbreviation 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 "
<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@xxxxxxxxx
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@xxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
