Re: [Gen-art] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

[Shwetha Bhandari]

Hi Martin,

This is to confirm that -09 version of the draft has been published a few
days ago that addresses all the comments per the discussion in this thread.

Thanks
Shwetha

On Sun, Sep 25, 2022, 9:56 AM Joel Halpern  wrote:

> 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?
>
> Yes, renaming the section to "deployment and implementation
> considerations" would resolve this concern. 
>
>
>
>>
>> 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.
>
> 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.
>
>
> 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.
>
> Okay.
>
>
>
> Thanks,
> Shwetha
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

[Joel Halpern]

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 
 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


.

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?
Yes, renaming the section to "deployment and implementation 
considerations" would resolve this concern. 



    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.
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.


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.

Okay.



Thanks,
Shwetha___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

[Shwetha Bhandari]

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
>
> 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
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-ippm-ioam-ipv6-options-08

[Joel Halpern via Datatracker]

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

.

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.

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.

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?

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??)

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?

 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".

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.

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.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art