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-v6ops-ipv6-deployment-07

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Ready with Nits

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-v6ops-ipv6-deployment-07
Reviewer: Robert Sparks
Review Date: 2022-09-24
IETF LC End Date: 2022-09-26
IESG Telechat date: Not scheduled for a telechat

Summary: Mostly ready for publication as an Informational RFC, but with nits to
address before publication.

I appreciate that this document represents a significant amount of discussion,
and agree that obsoleting RFC6036 is the right thing to do.

However, it is unclear who this document is for. It doesn't feel like it's for
people working on standardization or regulation, nor does it feel like a
roadmap into other work or sources of information. Parts of it _begin_ to feel
like it's intended to help people who are managing networks going through
transition, but the language in those sections is not addressed to them. Is it
primarily a guide to the narrative IPv6 evangelists could use when approaching
other audiences?

I don't object to publishing this in its current form (but suggest addressing
the below nits), but I really wonder if it would be more useful to reconsider
the audience(s) and goals and write more explicitly to them.

It's hard to tell what in this document is repetition of results from other
sources, and what is new synthesis and analysis.

There is language that should be adjusted to reflect being published in
archival series. Example: "This document intends to"

I recognize that this is a matter of style, but I find the use of phrases like
"it may be interesting to", "it is worth mentioning", and similar to be
distracting. Please consider removing the phrases - the point of the sentences
will become stronger.

There are a few sentences that could be adjusted to make them easier for
non-native english speakers to translate. Places like "Their actions cannot be
objected, ". It would be good to scrub these before they get to the rfc-editor.

The document is acronym-heavy, and some acronyms are used so few times that
expanding them on _every_ use is better than just on first use. Example: FBB.

It is uncomfortable to see "It is important to say that IPv6 is not more or
less secure than IPv4". First - are you telling the readers that it is
important for them to say this? Or stating that it's important for this
document to say it? Second, the rest of the document doesn't support the
statement. Instead, it almost directly contradicts it, by pointing to the
relative maturity of implementations, the larger potential attack surface, etc.
Why is this sentence (at the beginning of 5.4.1) in the document? Could the
statement simply be removed?

Has potential selection bias been considered in the analysis of the survey in
appendix A? Perhaps it would be more accurate to title section 3.2 "IPv6 among
Internet Service Providers in Europe"?

At "theoretical ratio", I suggest instead of using that phrase, you explain why
you needed to say it. I suggest something like: "This is not a claim that each
person uses this many addresses", or simply talking about the ratio without
this disclaimer - the readers will already be familiar with the characteristics
of per-capita metrics.

In 3.3, last sentence of the first paragraph - it's not clear that you actually
state otherwise in the text that follows. If you do, stating otherwise needs to
be done more clearly. If you don't, you don't need this sentence.

Micro-nit in figure 3: Wolrdwide -> Worldwide


___
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-6man-rfc6874bis-02

[Brian E Carpenter]

Roni,

Assuming "easy" means "ready", thank you!

Regards
   Brian Carpenter

On 24-Sep-22 19:31, Roni Even via Datatracker wrote:

Reviewer: Roni Even
Review result: Ready

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-6man-rfc6874bis-??
Reviewer: Roni Even
Review Date: 2022-09-24
IETF LC End Date: 2022-09-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is easy for publication as a standard track rfc

Major issues:

Minor issues:

Nits/editorial comments:





___
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-dots-telemetry-use-cases-11

[H Y]

Hi Peter,

Thank you for your very careful review.

We modified the draft to address the comments, and you can see the diff here.
https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-use-cases-12

Please see inline.

2022年9月21日(水) 14:54 Peter Yee via Datatracker :

>
> Reviewer: Peter Yee
> Review result: Ready with Nits
>
> 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-dots-telemetry-use-cases-11
> Reviewer: Peter Yee
> Review Date: 2022-09-20
> IETF LC End Date: 2022-09-20
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This document gives use cases showing how RFC 9244 can be employed 
> for
> to convey DOTS telemetry. It seems perfectly fine as an informational adjunct
> to RFC 9244, giving more involved examples.
>
> Major issues: None.
>
> Minor issues: None.
>
> Nits/editorial comments:
>
> Page 3, section 3, 1st paragraph: insert “the” before “DOTS telemetry
> specifications” and change “specifications” to “specification”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 4, section 3.1.1, 1st paragraph, 1st sentence: delete “such”. Change “is”
> to “are”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 4, section 3.1.1, 1st paragraph, 2nd sentence: change “recent” to
> “recently”. Change “Tps” to “Tbps”, unless you believe that 1 transaction per
> second is a lot of traffic. One tablespoon might be. ;-)
[Yuhei]
Thanks. I addressed this comment.

>
> Page 7, 1st paragraph, 2nd sentence: change “identifies” to “identify”. Change
> “of” to “about”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 7, 1st paragraph, 3rd sentence: delete the first two commas (bracketing
> “then”).
[Yuhei]
Thanks. I addressed this comment.

>
> Page 7, section 3.1.2, 1st paragraph, 2nd sentence: change “under attack time”
> to “at the time of an attack”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 9, 1st paragraph, 2nd sentence: change “of” to “on”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 9, 1st paragraph, 4th sentence: delete “each”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 9, 1st paragraph, 5th sentence: change “atribute” to “attribute”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 10, section 3.1.3, 1st paragraph, 1st sentence: delete “an”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 12, 1st paragraph, 2nd sentence: change “of” to “about”. Delete “a” after
> “using”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 12, 1st paragraph, 3rd sentence: delete “On the other hands,” and
> capitalize the ‘t’ in “the”. Insert “the” before “volume”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 12, section 3.1.4, 1st paragraph, 1st sentence: delete the comma after
> “Short”. Change “internet” to “Internet”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 12, section 3.1.4, 1st paragraph, 2nd sentence: considering inserting
> “salient” before “feature”. Insert “it” before “start” and change “start” to
> “starts”. Change “go” to “goes” in both occurrences in the sentence. Insert
> “then” before “ back to maximum”.
[Yuhei]
Thanks. I addressed this comment, considering Genart and Artart last
call review comments.


OLD:
The feature of the attack is that start from zero and go to maximum
values in a very short time span, then go back to zero, and back to
maximum, repeating in continuous cycles at short intervals.

NEW:
These attacks start from zero and go to maximum values in a very short
time span, then go back to zero, and then back to maximum, repeating
in continuous cycles at short intervals.

>
> Page 12, section 3.1.4, 1st paragraph, 3rd sentence: delete “for them”. Insert
> “such” before “an attack”. Change “by” to “using a”. Change “it” to “this”.
[Yuhei]
Thanks. I addressed this comment, considering Genart and Artart last
call review comments.

OLD:
It is difficult for them to mitigate an attack by DMS by redirecting
attack flows because it may cause route flapping in the network.

NEW:
It is difficult for the transit providers to mitigate such an attack
with their DMSes using a redirecting attack flows because this may
cause route flapping in the network.

>
> Page 12, section 3.1.4, 2nd paragraph, 2nd sentence: insert “the” before
> “attack traffic”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 14, 1st paragraph, 3rd sentence: change “rate-limit” to “rate-limiting 
> of”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 14, 2nd paragraph: change “gatherd” to “gathered”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 15, section 3.1.5, 1st paragraph, 3rd sentence: change “suspecious” to
> “suspicious”.
[Yuhei]
Thanks. I addressed this comment.

>
> Page 15, section 3.1.5, 1st paragraph, 4th sentence: 

[Gen-art] Genart last call review of draft-ietf-6man-rfc6874bis-02

[Roni Even via Datatracker]

Reviewer: Roni Even
Review result: Ready

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-6man-rfc6874bis-??
Reviewer: Roni Even
Review Date: 2022-09-24
IETF LC End Date: 2022-09-26
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is easy for publication as a standard track rfc

Major issues:

Minor issues:

Nits/editorial comments:



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