Thank you for addressing my comments. trimmed, responses where needed
in line.
Yours,
Joel
On 9/24/2022 10:01 PM, Shwetha Bhandari wrote:
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
<nore...@ietf.org> 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
Minor issues:
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?
<jmh>Yes, renaming the section to "deployment and implementation
considerations" would resolve this concern. </jmh>
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.
<jmh>I marked this as minor, so if you really can't say anything else, I
guess I can live with it. But it seems more than a little odd to have a
requirement in a draft with no way to meet it.</jmh>
Nits/editorial comments:
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.
<jmh>Okay.</jmh>
Thanks,
Shwetha
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
