Thank you for the detailed review and sorry for a very late response. I am creating a revision of the draft based on this feedback.
Responses and clarifications inline @SB
On Wed, Jun 29, 2022 at 1:39 AM Joel Halpern via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!MZ3Fw45to5uY!NoSxZQbYffG7SJV0yDCTEy7dKRhLkASqrXTvmSZYhuyCrik6ftQvulTvbfT6xyFBWdoxk_7S4nD87nOYMkJnckbF$ >.
Document: draft-ietf-ippm-ioam-ipv6-options-08
Reviewer: Joel Halpern
Review Date: 2022-06-28
IETF LC End Date: 2022-07-01
IESG Telechat date: Not scheduled for a telechat
Summary: If the issues identified below are addressed, this document will be
ready for publication as a Proposed Standard RFC.
Major issues:
Why is the domain boundary expectation in section 4 only a SHOULD? Either
there is no need to restrict it, or it is important and it is a MUST? This
comes up again in section 5.1 item C4.
[SB] Agreed. Will change to MUST in the revision.
Minor issues:
The document uses the term IOAM extensively. It expands the term as
"In-situ Operations, Administration, and Maintenance". While a good start,
it would be very helpful if the document either defined IOAM or cited a
definition. The expansion does not explain what the difference is between
IOAM and other forms of OAM, nor indicate what sorts of packets IOAM
applies to.
[SB] Will refer to RFC 9197 for the definition of IOAM.
Section 5.1 (Considerations for IOAM deployment in IPv6 networks)
requirement C1 seems to be an implementation requirement not a deployment
requirement. The text even ends with "Implementations of IOAM SHOULD..."
Why is this in a deployment considerations section?
[SB] This was an important consideration for implementation and deployment that came
up during the workgroup discussions. Would renaming the sesion to deployment and implementation
considerations work?
Requirement C3 in section 5.1 is very oddly worded. It seems to say "X
should not happen" but does not tell the implementor or deployer how to
avoid having X occur. I would recommend rewording. (At a guess, something
about how entities sending errors outside of an IOAM domain should remove
any IOAM data??)
[SB] Added text to this effect.
Requirement C5 in 5.1 says that leaks need to be easily identified and
attributed. That's nice. It doesn't seem to say HOW that is to be done.
So how does an implementor or deployer comply with the requirement?
[SB] This is not addressed in the current draft. A future draft could add
IOAM field to indicate the AS that added the IOAM data.
Could the description clause of the two IANA entries please use "IOAM
destination option" and "IOAM hop-by-hop option" rather than describing
them both just as "IOAM".
[SB] done.
Nits/editorial comments:
Given the problems of acronym overload and the sparse need for it, I would
recommend not using the acronym ION (IOAM Overlay Network), and simply
spelling that out in the few places it is needed.
[SB] done
It would be helpful if section 5.3 (IOAM domains bounded by network
devices) restated that such ingress edge devices will encapsulate the user
packet, and put the IOAM option in the resulting encapsulating header. And
decapsulate at the egress.
[SB] The deployment options elaborates this option, it is difficult to summarize that and add it as part of the requirement.
I would prefer to keep this context in the deployment options section.
Thanks,
Shwetha
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
