Re: [Gen-art] Gen-ART review of draft-ietf-aqm-eval-guidelines-11

[Ralph Droms (rdroms)]

> On May 18, 2016, at 9:29 PM 5/18/16, Jari Arkko  wrote:
> 
> Thanks for your review, Ralph!

You're welcome.  I'm glad to hear you found the review valuable.

Responses in line...

> 
> I do think some of the points you raised need to be addressed. Inline:
> 
>> 
>> #
>> 
>> I often react to the use of RFC 2119 language in an Informational document 
>> by asking is that language really necessary?  I'll ask the question here: in 
>> the context of this Informational document, which appears to be entirely 
>> advisory in providing guidelines, what does the use of RFC 2119 
>> "requirements language" add to the meaning of the document.
>> 
 Authors: Indeed, the use of RFC 2119 language is not mandatory for such 
 information document. However, using it enables us to introduce weight in 
 the different parameterizations of the tests. Even though, it is not 
 mandatory, we believe that it eases the reading of the document, for 
 someone familiar with the IETF wording.
> 
> I think that’s right.

OK.

>> #
>> 
>> Figure 1 is not clear to me.  Where are the physical links and interfaces?  
>> Are there multiple physical senders and receivers or are "senders A" 
>> instantiated on a single host (does it make a difference)?  Are there 
>> static-sized buffers for each interface or do all the buffers share one 
>> memory space?
>> 
 Authors: We acknowledge that Figure 1 is not very clear. We have 
 voluntarily omitted precisions on the amount of senders, receivers and 
 traffic classes since the instantiation on a specific testbed would remove 
 the generality of the figure and the described architecture. We believe 
 that the text helps in reading the figure. Also, the rationale of this 
 figure is to explain the notation more than going deeper in the topology 
 that is anyway very generic.
> 
> My opinion is that Figure 1 was very hard to read, even with reading the 
> text. I’d like to see some improvement in either the text or the figure.

I can understand that the figure might be an illustrative abstraction, but I 
still think it would be helpful to have more detail in the text and some 
restructuring of the figure.

>> #
>> 
>> In section 3.1, is there a need to say something about the relative 
>> capacities of the various links and the rates at which the various flows 
>> generate traffic?
>> 
 Authors: These capacities are described in a later section when needed, 
 and to remain high level and not focus on any applicability context 
 (wi-fi, rural satellite access, fibber access, etc.) they are not 
 specified for the whole document. The rates at which the flows generate 
 traffic is specified for each further described scenario.
> 
> OK

OK

>> #
>> 
>> I would have trouble following the guidelines set out in section 4.3.1.  I 
>> can understand the need for consideration of the tunable control parameters 
>> when comparing different AQM schemes.  However, I don't know what 
>> "comparable" means for control parameters that are likely quite different 
>> between AQM schemes.  I also think one would want to compare optimal control 
>> settings for the different schemes, to compare best-case performance.  Or, 
>> for AQM schemes whose performance is highly dependent on operational 
>> conditions, one might want to compare settings that are sub-optimal for any 
>> particular test condition but that give better performance over a wide range 
>> of conditions.
>> 
 Authors: The intent of the first recommendation is to make testers be 
 aware of which control points control which behavior and be conscious to 
 make apples to apples comparison.
>> To further precise this, we could change the text is section 4.3.1 as 
>> follows :
>> "1. Similar control parameters and implications: Testers should be aware of 
>> the control parameters of the different schemes that control similar 
>> behavior. Testers should also be aware of the input value ranges and 
>> corresponding implications. For example, consider two different schemes - 
>> (A) queue-length based AQM scheme, and (B) queueing-delay based scheme. A 
>> and B are likely to have different kinds of control inputs to control the 
>> target delay - target queue length in A vs. target queuing delay in B, for 
>> example. Setting parameter values such as 100MB for A vs. 10ms for B will 
>> have different implications depending on evaluation context.  Such 
>> context-dependent implications must be considered before drawing conclusions 
>> on performance comparisons. Also, it would be preferable if an AQM proposal 
>> listed such parameters and discussed how each relates to network 
>> characteristics such as capacity, average RTT etc.”
> 
> OK for me

I think the suggested text is OK, too.

>> #
>> 
>> Section 4.4 seems to give advice to the AQM designer rather than describe 
>> guidelines for characterization.  Section 4.4 should either be rewritten to 
>> give 

[Gen-art] Gen-ART review of draft-ietf-aqm-eval-guidelines-11

[Ralph Droms (rdroms)]

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-aqm-eval-guidelines-11
Reviewer: Ralph Droms
Review Date: 2016-04-28
IETF LC End Date: 2016-05-04
IESG Telechat date: 2016-05-19

Summary: This draft is on the right track but has open issues, described in the 
review.

In general, I think the document could be read, implemented and used to 
generate useful characterizations of AQM schemes.  However, the motivations for 
some of the measurements and scenarios seems weak to me, which might compromise 
the weight given to the conclusions drawn from the guidelines.

Major issues:

None.  However, the list of minor issues and nits, taken together, could be 
considered a major issue to be resolved before publication.

Minor issues:

I often react to the use of RFC 2119 language in an Informational document by 
asking is that language really necessary?  I'll ask the question here: in the 
context of this Informational document, which appears to be entirely advisory 
in providing guidelines, what does the use of RFC 2119 "requirements language" 
add to the meaning of the document.

Figure 1 is not clear to me.  Where are the physical links and interfaces?  Are 
there multiple physical senders and receivers or are "senders A" instantiated 
on a single host (does it make a difference)?  Are there static-sized buffers 
for each interface or do all the buffers share one memory space?

In section 3.1, is there a need to say something about the relative capacities 
of the various links and the rates at which the various flows generate traffic?

I would have trouble following the guidelines set out in section 4.3.1.  I can 
understand the need for consideration of the tunable control parameters when 
comparing different AQM schemes.  However, I don't know what "comparable" means 
for control parameters that are likely quite different between AQM schemes.  I 
also think one would want to compare optimal control settings for the different 
schemes, to compare best-case performance.  Or, for AQM schemes whose 
performance is highly dependent on operational conditions, one might want to 
compare settings that are sub-optimal for any particular test condition but 
that give better performance over a wide range of conditions.

Section 4.4 seems to give advice to the AQM designer rather than describe 
guidelines for characterization.  Section 4.4 should either be rewritten to 
give guidelines for structuring measurements to account for varying packet 
sizes or the section should be elided.

In section 4.5, what is the motivation for giving the advice about ECN to AQM 
designers?  I can understand that ECN will have affect the impact of AQM, but 
for this document I think the section should focus on measurement guidlines 
that account for that impact.

The specific topology in section 10 does not seem well-motivated to me.  Why is 
router R with no AQM included in the topology?  The choice of measurements is 
similarly not well-motivated.  Why would it not be of interest to run all the 
tests described earlier in the document?

Nits/editorial comments:

There are several instances of the word "advice" which should be replaced with 
"advise"; e.g., in section 2.3.

Last sentence of the abstract: I don't get the meaning of "precautionary 
characterizations of AQM schemes".  I recommend that the phrase be reworded

Section 1, first paragraph: The last sentence doesn't follow the rest of the 
paragraph and I recommend that it be elided.

Section 1, third paragraph: This text is redundant with the text in the 
Glossary section:

   When speaking of a specific queue in this
   document, "buffer occupancy" refers to the amount of data (measured
   in bytes or packets) that are in the queue, and the "maximum buffer
   size" refers to the maximum buffer occupancy.

Section 1, third paragraph:

OLD:

   In real
   implementations of switches, a global memory is often shared between
   the available devices, and thus, the maximum buffer size may vary
   over the time.

NEW:

   In switches and routers, a global memory space is often shared
   between the available interfaces, and thus, the maximum buffer size
   for any given interface may vary over the time.

Section 1, fifth paragraph, last sentence: Is this document just concerned with 
"deployability" or more generally with "applicability, performance and 
deployability"?

Section 1.1, first paragraph: Would it be helpful to qualify "goodput" as 
"goodput in individual flows", to contrast with "goodput at a router"?  If 
"goodput" is well-known in this community to be "flow goodput", no change is 
needed.

Section 1.1, second paragraph: What is "BDP", as in "BDP-sized buffer"?

Se

[Gen-art] Gem-Art review of draft-ietf-lager-specification-11

[Ralph Droms (rdroms)]

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-lager-specification-11
Reviewer: Ralph Droms
Review Date: 2016-04-19
IETF LC End Date: 2016-04-11
IESG Telechat date: (if known) 2016-04-21

Summary: This draft is ready for publication as a Standards Track RFC.

Major issues: None

Minor issues: None

Nits/editorial comments: While this document is long and detailed, I found it 
to be clear and well-written.  I can't say I fully understand all the details 
and nuances after my review, but I'm confident that an implementor could gain 
the necessary understanding from careful reading of the document.  I did find 
what I considered to be a couple of small typos, which I'm confident the RFC 
Editor will find and correct if necessary.






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

[Ralph Droms (rdroms)]

Confirming that rev -15 addresses my Gen-ART review comments...

- Ralph

> On Dec 16, 2015, at 11:19 AM 12/16/15, Ralph Droms (rdroms) 
>  wrote:
> 
> 
>> On Dec 16, 2015, at 10:47 AM 12/16/15, Alexey Melnikov 
>>  wrote:
>> 
>> Hi Ralph,
>> Thank you for your review. Sorry I missed it earlier.
> 
> You're welcome.  Looks like we have agreement on my editorial comments and 
> suggestions.  Will the edits you mention below appear in rev -15?
> 
> - Ralph
> 
>> 
>> On 09/12/2015 20:47, Ralph Droms (rdroms) wrote:
>>> Nits/editorial comments:
>>> 
>>> Nicely written, very clear document.
>> Thank you.
>>> idnits reports some lines too long and an unused reference.
>> I fixed the reference in my copy. I hope RFC Editor can help with lines 
>> which are too long.
>>> In the third paragraph of the Introduction, I suggest removing the 
>>> parentheses and editing the second sentence for clarity; specifically, what 
>>> is "SCRAM data"?
>> I meant SCRAM requests and responses.
>>> You could probably omit the parentheses in the second paragraph of Setion 
>>> 3, as well, I'm likely just arguing style.
>> Barry picked on this as well, so this was rewritten for clarity.
>>> The last sentence of the last paragraph of sectino 3 was unclear to me: 
>>> which messages are referred to?
>> Message is the same as 'decoded "data" attribute' in the previous sentence. 
>> I clarified that.
>>> I think, in the phrase "fail the authentication" in the fifth paragraph of 
>>> section 8, you are using "fail" as a transitive verb, as in "the client 
>>> considers the authentication of the message to have failed"
>> ... and does whatever is appropriate in this case. Which might be closing 
>> the connection, retrying or trying another (non SCRAM) mechanism.
>>> .  If I have that write, I suggest rewriting the containing sentence to 
>>> improve the clarity.
>> 
>> Best Regards,
>> Alexey
>> 
>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

> On Dec 7, 2015, at 1:31 PM 12/7/15, Stephane Bortzmeyer  
> wrote:
> 
> On Tue, Dec 01, 2015 at 01:55:46PM +0000,
> Ralph Droms (rdroms)  wrote
> a message of 128 lines which said:
> 
>> Would you consider adding a little text somewhere to make it clear
>> that the Appendix is intended as a guide to implementors?
> 
> Done,
> <https://github.com/bortzmeyer/my-IETF-work/commit/b768c43ab0624ec9cc8361d221a27058b64b19a2>
> 
>> My recommendation to improve the document would be the inclusion of
>> another appendix, describing the algorithm to use if zone cuts are
>> known.
> 
> It already exists, this is the second paragraph of section 2. (The
> ideal case.)

For the inexperienced implementor, a little more detail might be useful.

> But I do not find useful to add more text: for a real resolver, the
> algorithm in appendix A suffices (it works if the zone cuts are known,
> see step 1).
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

[Ralph Droms (rdroms)]

> On Dec 16, 2015, at 10:47 AM 12/16/15, Alexey Melnikov 
>  wrote:
> 
> Hi Ralph,
> Thank you for your review. Sorry I missed it earlier.

You're welcome.  Looks like we have agreement on my editorial comments and 
suggestions.  Will the edits you mention below appear in rev -15?

- Ralph

> 
> On 09/12/2015 20:47, Ralph Droms (rdroms) wrote:
>> Nits/editorial comments:
>> 
>> Nicely written, very clear document.
> Thank you.
>> idnits reports some lines too long and an unused reference.
> I fixed the reference in my copy. I hope RFC Editor can help with lines which 
> are too long.
>> In the third paragraph of the Introduction, I suggest removing the 
>> parentheses and editing the second sentence for clarity; specifically, what 
>> is "SCRAM data"?
> I meant SCRAM requests and responses.
>> You could probably omit the parentheses in the second paragraph of Setion 3, 
>> as well, I'm likely just arguing style.
> Barry picked on this as well, so this was rewritten for clarity.
>> The last sentence of the last paragraph of sectino 3 was unclear to me: 
>> which messages are referred to?
> Message is the same as 'decoded "data" attribute' in the previous sentence. I 
> clarified that.
>> I think, in the phrase "fail the authentication" in the fifth paragraph of 
>> section 8, you are using "fail" as a transitive verb, as in "the client 
>> considers the authentication of the message to have failed"
> ... and does whatever is appropriate in this case. Which might be closing the 
> connection, retrying or trying another (non SCRAM) mechanism.
>> .  If I have that write, I suggest rewriting the containing sentence to 
>> improve the clarity.
> 
> Best Regards,
> Alexey
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gem-Art review for draft-ietf-httpauth-scram-auth-14

[Ralph Droms (rdroms)]

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-httpauth-scram-auth-14
Reviewer: Ralph Droms
Review Date: 2015-13-9
IETF LC End Date: 2015-12-16
IESG Telechat date: (if known)

Summary: This draft is ready for publication as an Experimental RFC.

Major issues: None.

Minor issues: None.

Nits/editorial comments:

Nicely written, very clear document.

idnits reports some lines too long and an unused reference.

In the third paragraph of the Introduction, I suggest removing the parentheses 
and editing the second sentence for clarity; specifically, what is "SCRAM data"?

You could probably omit the parentheses in the second paragraph of Setion 3, as 
well, I'm likely just arguing style.

The last sentence of the last paragraph of sectino 3 was unclear to me: which 
messages are referred to?

I think, in the phrase "fail the authentication" in the fifth paragraph of 
section 8, you are using "fail" as a transitive verb, as in "the client 
considers the authentication of the message to have failed".  If I have that 
write, I suggest rewriting the containing sentence to improve the clarity.






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

> On Nov 26, 2015, at 7:41 AM 11/26/15, Stephane Bortzmeyer  
> wrote:
> 
> On Fri, Nov 20, 2015 at 04:22:21PM +0000,
> Ralph Droms (rdroms)  wrote
> a message of 97 lines which said:
> 
>> I am the assigned Gen-ART reviewer for
>> draft-ietf-dnsop-qname-minimisation-07.txt.
> 
> Hello. Glad to have reviewers.

This document is well-written and easy to read.  It's a pleasure to do the 
review.

> 
>> Has the working group considered publishing this document as
>> "Informational" rather than "Experimental"?  If the document is
>> published as "Experimental", is the intention to publish a
>> subsequent proposed standard or BCP?
> 
> [See Tim's answer.]

OK.

> 
>> I found the descriptions in the document understandable, but not
>> quite detailed enough to build an interoperable implementation.
> 
> There is something very important about qname minimisation: it is a
> local technique, not a protocol. It works with unmodified authoritative
> name servers. So "interoperability" is not a concern because it does
> not change the DNS protocol. Consequence: each resolver MAY implement
> it slightly differently (see appendix B).

OK, I understand this is a local technique and does not represent a change to 
the DNS protocols.  Even so, in my opinion there are some details that are not 
provided in the document (see below).

>> Is Appendix A intended as the specification for the QNAME
>> minimization techniques described in this document?
> 
> No. That's why it's in an appendix. Most resolvers already can find
> the zone cuts (they need it to do DNSSEC), this appendix is to give
> ideas to developers of the other resolvers.

Would you consider adding a little text somewhere to make it clear that the 
Appendix is intended as a guide to implementors?

>> The appendix is titled "An algorithm to find the zone cut" and the
>> introductory text indicates the algorithm is intended for locating
>> the zone cut.  However, as I read the algorithm, it finds and
>> traverses all zone cuts until the original QNAME can be resolved.
> 
> The title may be misleading. What about "An algorithm to perform QNAME
> minimisation in presence of zone cuts?"

Perhaps "unknown zone cuts"?  Otherwise, that title sounds good.

My recommendation to improve the document would be the inclusion of another 
appendix, describing the algorithm to use if zone cuts are known.  In my 
opinion, what's missing from the document for an inexperienced implementor is a 
summary of how to build the resolver you refer to in section 2: "The minimising 
resolver works perfectly when it knows the zone cut"

>> In section 2, is the phrase "closest known parent of the original
>> QNAME" something that most DNS developers would understand?
> 
> Well, "parent" could be misleading because it is rather "ancestor"
> (the example in the draft show a grand-parent).
> 
>> Would the phrase "closest enclosing NS RRset" from Appendix A be
>> more precise?
> 
> "Known" is very important here. What about "closest known enclosing NS
> RRset"?

OK, that text would be good.

>> I wasn't sure at first whether "(section 6)" in the 4th paragraph of
>> section 2 referred to section 6 of RFC 2181 or section 6 of this
>> document.
> 
> OK, fixed in my local copy.

Great.

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

I am the assigned Gen-ART reviewer for 
draft-ietf-dnsop-qname-minimisation-07.txt.

For background on Gen-ART, please see the FAQ at 
.

Please resolve these comments along with any other Last Call comments you may 
receive.


Document: draft-ietf-dnsop-qname-minimisation-07
Reviewer: Ralph Droms
Review Date: 2015-11-20
IETF LC End Date: 2015-11-23
IESG Telechat date: unknown

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

The document is well-written and easy to understand.  Thank you.

Has the working group considered publishing this document as "Informational" 
rather than "Experimental"?  If the document is published as "Experimental", is 
the intention to publish a subsequent proposed standard or BCP?

In my opinion, the document needs a little more work if it is to be published 
as "Experimental", especially if the intention is to publish a proposed 
standard based on the results of experiments with the techniques described in 
this document.  I found the descriptions in the document understandable, but 
not quite detailed enough to build an interoperable implementation.

Is Appendix A intended as the specification for the QNAME minimization 
techniques described in this document?  The appendix is titled "An algorithm to 
find the zone cut" and the introductory text indicates the algorithm is 
intended for locating the zone cut.  However, as I read the algorithm, it finds 
and traverses all zone cuts until the original QNAME can be resolved.

If Appendix A is not the specification for the QNAME minimization techniques, 
then I don't know exactly what specific behavior or algorithm is referred to by 
"minimising resolver" in this sentence from section 2:  "The minimising 
resolver works perfectly when it knows the zone cut [...]".

My suggestion would be to include another algorithm description, similar to 
that in Appendix A, but that describes how to use knowledge of zone cuts.

Editorial
-

In section 2, is the phrase "closest known parent of the original QNAME" 
something that most DNS developers would understand?  Would the phrase "closest 
enclosing NS RRset" from Appendix A be more precise?

I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 2 
referred to section 6 of RFC 2181 or section 6 of this document.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gem-Art Last Call review of draft-ietf-dnsop-qname-minimisation-07

[Ralph Droms (rdroms)]

I am the assigned Gen-ART reviewer for 
draft-ietf-dnsop-qname-minimisation-07.txt.

For background on Gen-ART, please see the FAQ at 
.

Please resolve these comments along with any other Last Call comments you may 
receive.


Document: draft-ietf-dnsop-qname-minimisation-07
Reviewer: Ralph Droms
Review Date: 2015-11-20
IETF LC End Date: 2015-11-23
IESG Telechat date: unknown

Summary:

This draft is on the right track but has open issues, described in the review.

Major issues:

The document is well-written and easy to understand.  Thank you.

Has the working group considered publishing this document as "Informational" 
rather than "Experimental"?  If the document is published as "Experimental", is 
the intention to publish a subsequent proposed standard or BCP?

In my opinion, the document needs a little more work if it is to be published 
as "Experimental", especially if the intention is to publish a proposed 
standard based on the results of experiments with the techniques described in 
this document.  I found the descriptions in the document understandable, but 
not quite detailed enough to build an interoperable implementation.

Is Appendix A intended as the specification for the QNAME minimization 
techniques described in this document?  The appendix is titled "An algorithm to 
find the zone cut" and the introductory text indicates the algorithm is 
intended for locating the zone cut.  However, as I read the algorithm, it finds 
and traverses all zone cuts until the original QNAME can be resolved.

If Appendix A is not the specification for the QNAME minimization techniques, 
then I don't know exactly what specific behavior or algorithm is referred to by 
"minimising resolver" in this sentence from section 2:  "The minimising 
resolver works perfectly when it knows the zone cut [...]".

My suggestion would be to include another algorithm description, similar to 
that in Appendix A, but that describes how to use knowledge of zone cuts.

Editorial
-

In section 2, is the phrase "closest known parent of the original QNAME" 
something that most DNS developers would understand?  Would the phrase "closest 
enclosing NS RRset" from Appendix A be more precise?

I wasn't sure at first whether "(section 6)" in the 4th paragraph of section 2 
referred to section 6 of RFC 2181 or section 6 of this document.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Himanshu - I've been tied up in meetings most of the day today and am about to 
go into more meetings that will last until the end of the day.

I reviewed your revised draft briefly and it mostly looks OK.  I have one 
substantive comment, which is about an issue I didn't notice until now:

How is the Mac Withdraw sub-TLV registry from which the "Sequence Number" code 
point is taken differentiated from the LDP Parameters sub-TLV registry from 
which the "MAC List" and "MAC Flush Parameter" code points are taken?  In other 
words, how does the receciver know to interpret the code point on the Sequence 
Number TLV as a code point in the Mac Withdraw sub-TLV registry while the code 
points on the MAC List TLV and the MAC Flush Paramter TLV are interpreted as 
code points in the LDP Paramteres sub-TLV?  Shouldn't all the code points on 
the TLVs in this message come from a single registry?

I also have an editorial comment from my earlier review: the ifrst paragraph of 
section 3 is mostly redundant with section 4.1 and that text in section 3 
should be merged into the text in section 4.1

- Ralph

> On Oct 26, 2015, at 2:09 PM 10/26/15, Shah, Himanshu  wrote:
> 
> Thanks Andy.
> He did re-send the email without MIME and I was able to read and reply.
>  
> Thanks,
> Himanshu
>  
> From: Andrew G. Malis [mailto:agma...@gmail.com] 
> Sent: Monday, October 26, 2015 2:08 PM
> To: Shah, Himanshu
> Cc: Ralph Droms (rdroms); A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>  
> Himanshu,
>  
> Ralph said:
>  
> Himanshu - I've received your revised draft.  I've been stuck in a variety of 
> meetings Monday and haven't had time to review it.  I should be able to look 
> at it before the end of the day.
> 
> - Ralph
>  
> On Mon, Oct 26, 2015 at 1:04 PM, Shah, Himanshu  wrote:
> Can you send the email without MIME signature?
>  
> Thanks,
> Himanshu
>  
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
> Sent: Monday, October 26, 2015 1:02 PM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

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

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Himanshu - I've received your revised draft.  I've been stuck in a variety of 
meetings Monday and haven't had time to review it.  I should be able to look at 
it before the end of the day.

- Ralph

> On Oct 24, 2015, at 5:56 PM 10/24/15, Shah, Himanshu  wrote:
> 
> Now with the draft..
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu 
> Sent: Saturday, October 24, 2015 5:52 PM
> To: 'Ralph Droms (rdroms)'
> Cc: 'A. Jean Mahoney'; 'General Area Review Team'; 
> 'draft-ietf-pals-mpls-tp-mac-wd@ietf.org'; 'The IESG'
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> One more update that was discussed in previous emails but not included in 
> your last email -
> 
> Original text: 
>  Only half of the sequence number space is used.  Modular arithmetic
>  is used to detect wrapping of sequence number.  When sequence number
>  wraps, all MAC addresses are flushed and the sequence number is
>  reset.  The 16-bit sequence number handling is described in
>  [RFC4385]. This document uses 32-bits sequence numbers and hence
>  sequence number in half the number space (i.e. 31-bits or ~2billion)
>  is considered in the valid receive range.
> 
> [Ralph]
> This paragraph is not at all clear to me. Reading section 4 of RFC 4385 
> helped but left me unsure about how my understanding of how to extend the 
> sequence number mechanism to 32 bits corresponds to the expectations of this 
> document.
> 
> 
> [Himanshu>] 
> 
> New text:
> 
>   The lack of reliable transport protocol for the in-band OAM
>   necessitates a presence of sequencing and acknowledgement
>   scheme so that the receiver can recognize newer message from
>   retransmitted older messages. The [RFC4385] describes the details
>   of sequence number handling which includes overflow detection for
>   sequence number field of size 16-bits. This document leverages
>   the same scheme with the two exemptions
>   - sequence number field is of size 32-bits
>   - overflow detection is simplified such that sequence
> number exceed 2,147,483,647 (0x7FFF) is considered
>  overflow and reset to 1.
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 4:00 PM
> To: 'Ralph Droms (rdroms)'
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> I am updating the drafts to address your comments where relevant.
> 
> Since there is too many indentations below, I am bringing you latest comments 
> here, and respond.
> 
> ---
> [ralph] What I think would improve this specification is clarification that 
> trims redundant specification details from draft-ietf-pals-mpls-tp-mac-wd and 
> cites, concisely and exactly, the other documents from which the 
> specifications are copied.
> 
> [Himanshu] Trimming where relevant.
> ---
> 
> [ralph] It wasn't obvious to me what is intended as a protocol specification 
> and what is intended as a description of the protocol.  I see that RFC 4762 
> includes text that describes how to process an empty MAC List TLV, so perhaps 
> removal of the text altogether would be best.
> 
> [Himanshu] removed the reference to empty MAC List TLV
> 
> 
> [ralph]
>> The PW OAM message header is exactly the same as what is defined in 
>> [RFC6478].
>> 
> Is this statement really true?  The MAC Address Withdraw header seems to 
> replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
> flag.  The statement might be misleading to an implementor.
> 
> [Himanshu] replaced with following text:
> "The MAC withdraw PW OAM message follows the same guidelines used in  
> [RFC6478], whereby first 4-bytes of OAM message header is followed by  
> message specific field and a set of TLVs relevant for the message"
> 
> -
> [ralph]
> I think it would be helpful to state explicitly that the Sequence Number TLV 
> MUST be the first TLV in the message.
> 
> [Himanshu] added.
> 
> [Ralph] I apologize if I appear to be finicky, again, but the sentence I 
> quoted simply wasn't clear to me.  Common sense interpretation of 
> specifications is, of course, expected, but in my experience a simple 
> sentence like:
> 
> A MAC Address Withdraw OAM message with the A-bit set is sent by a receiver 
> to acknowledge receipt and processing of a MAC Address Withdraw OAM message
> 
> [Himanshu]  Modified description of A-

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Himanshu - I've received your revised draft.  I've been stuck in a variety of 
meetings Monday and haven't had time to review it.  I should be able to look at 
it before the end of the day.

- Ralph

> On Oct 24, 2015, at 5:56 PM 10/24/15, Shah, Himanshu  wrote:
> 
> Now with the draft..
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 5:52 PM
> To: 'Ralph Droms (rdroms)'
> Cc: 'A. Jean Mahoney'; 'General Area Review Team'; 
> 'draft-ietf-pals-mpls-tp-mac-wd@ietf.org'; 'The IESG'
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> One more update that was discussed in previous emails but not included in 
> your last email -
> 
> Original text:
>  Only half of the sequence number space is used.  Modular arithmetic
>  is used to detect wrapping of sequence number.  When sequence number
>  wraps, all MAC addresses are flushed and the sequence number is
>  reset.  The 16-bit sequence number handling is described in
>  [RFC4385]. This document uses 32-bits sequence numbers and hence
>  sequence number in half the number space (i.e. 31-bits or ~2billion)
>  is considered in the valid receive range.
> 
> [Ralph]
> This paragraph is not at all clear to me. Reading section 4 of RFC 4385 
> helped but left me unsure about how my understanding of how to extend the 
> sequence number mechanism to 32 bits corresponds to the expectations of this 
> document.
> 
> 
> [Himanshu>]
> 
> New text:
> 
>   The lack of reliable transport protocol for the in-band OAM
>   necessitates a presence of sequencing and acknowledgement
>   scheme so that the receiver can recognize newer message from
>   retransmitted older messages. The [RFC4385] describes the details
>   of sequence number handling which includes overflow detection for
>   sequence number field of size 16-bits. This document leverages
>   the same scheme with the two exemptions
>   - sequence number field is of size 32-bits
>   - overflow detection is simplified such that sequence
> number exceed 2,147,483,647 (0x7FFF) is considered
>  overflow and reset to 1.
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Shah, Himanshu
> Sent: Saturday, October 24, 2015 4:00 PM
> To: 'Ralph Droms (rdroms)'
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: RE: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> I am updating the drafts to address your comments where relevant.
> 
> Since there is too many indentations below, I am bringing you latest comments 
> here, and respond.
> 
> ---
> [ralph] What I think would improve this specification is clarification that 
> trims redundant specification details from draft-ietf-pals-mpls-tp-mac-wd and 
> cites, concisely and exactly, the other documents from which the 
> specifications are copied.
> 
> [Himanshu] Trimming where relevant.
> ---
> 
> [ralph] It wasn't obvious to me what is intended as a protocol specification 
> and what is intended as a description of the protocol.  I see that RFC 4762 
> includes text that describes how to process an empty MAC List TLV, so perhaps 
> removal of the text altogether would be best.
> 
> [Himanshu] removed the reference to empty MAC List TLV
> 
> 
> [ralph]
>> The PW OAM message header is exactly the same as what is defined in
>> [RFC6478].
>> 
> Is this statement really true?  The MAC Address Withdraw header seems to 
> replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
> flag.  The statement might be misleading to an implementor.
> 
> [Himanshu] replaced with following text:
> "The MAC withdraw PW OAM message follows the same guidelines used in  
> [RFC6478], whereby first 4-bytes of OAM message header is followed by  
> message specific field and a set of TLVs relevant for the message"
> 
> -
> [ralph]
> I think it would be helpful to state explicitly that the Sequence Number TLV 
> MUST be the first TLV in the message.
> 
> [Himanshu] added.
> 
> [Ralph] I apologize if I appear to be finicky, again, but the sentence I 
> quoted simply wasn't clear to me.  Common sense interpretation of 
> specifications is, of course, expected, but in my experience a simple 
> sentence like:
> 
> A MAC Address Withdraw OAM message with the A-bit set is sent by a receiver 
> to acknowledge receipt and processing of a MAC Address Withdraw OAM message
> 
> [Himanshu]  Modified description of A-bit as

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Himanshu - I have one clarification to my review: I should have written "Is 
there a reason this document does not use RFC 2119 terminology throughout?"

...and even that is likely an unfair assessment, as RFC 2119 language more or 
less everywhere needed for clarity.

My apologies for the inaccuracy.

- Ralph

> On Oct 22, 2015, at 11:31 AM 10/22/15, Shah, Himanshu  wrote:
> 
> Aahh! Finally got it with content!!..
> 
> Let me go through your email..
> 
> Thanks,
> Himanshu
> 
> 
> -----Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com] 
> Sent: Thursday, October 22, 2015 11:29 AM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> (originally sent 10/16; second try)
> 
> Hi, Himanshu - responses in line...
> 
>> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu  wrote:
>> 
>> Hi Ralph -
>> Thanks for your thorough review.
>> 
>> Let me first address your major concern.
>> 
>> As you point out, this draft builds on existing standards.
>> We (authors and WG) had to carefully balance between the right amount 
>> of information and wanting to describe details of methods described in other 
>> RFCs.
>> 
>> This is frustrating to implementer (including myself) having to go 
>> back and forth between the documents. So I share that concern.
>> 
>> But we would like to refrain from indulging in beefing up the doc and 
>> risk deviating from other base standards. However, for certain, if 
>> there is any conflict or lack of clarity, we would prefer to rectify.
> 
> I agree that, in general, duplicating specifications from other documents 
> increases the possibility that the respective documents unintentionally 
> conflict with each other or are not updated in parallel.
>> 
>> To that end, I would rather prefer, trimming by removing 
>> conflicting/confusing text.
> 
> I wasn't clear in my review - I think making the references to other 
> documents concise and clear, along with trimming unnecessary text from 
> draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.
> 
>> For example, sequence number processing - I rather would ask reader to 
>> get all details from relevant RFC, and point to only delta (which is 
>> to apply same logic that is used for 16-bit sequence number field to 
>> 32-bit field sequence number field that is used in this document).
> 
> This example is sort of an interesting one to consider, as I was thinking 
> more of the examples in which the format and semantics of the MAC TLVs are 
> exactly the same as in the cited defining documents.
> 
>> 
>> More comments in line.. and I look forward to your further guidance so 
>> we can wrap this up in time.
>> 
>> As a data point, there are two implementations of this draft deployed 
>> in a Telco network in Asia.
> 
> Noted.
> 
>> 
>> 
>> Thanks,
>> Himanshu
>> 
>> 
>> -Original Message-
>> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
>> Sent: Wednesday, October 14, 2015 4:02 PM
>> To: A. Jean Mahoney; General Area Review Team; 
>> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
>> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
>> 
>> 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
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Document: draft-ietf-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
>> Static Pseudowire"
>> Reviewer: Ralph Droms
>> Review Date: 2015-10-14
>> IETF LC End Date: 2015-10-19
>> IESG Telechat date: (if known) N/A
>> 
>> Summary:
>> 
>> This draft is on the right track but has open issues, described in the 
>> review.
>> 
>> 
>> Major issues:
>> 
>> While this document is describing a straightforward adaptation of previously 
>> defined standards to statically provisioned PWs, in my opinion an 
>> implementor would not necessarily be able to construct a fully interoperable 
>> implementation from this document.  There are several sections of the 
>> document that are not clear in their description of how to use mechanisms 
>> from referenced documents in this st

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

The archived message in the gen-art list is available here: 
http://www.ietf.org/mail-archive/web/gen-art/current/msg12413.html

> On Oct 22, 2015, at 11:22 AM 10/22/15, Shah, Himanshu  wrote:
> 
> Can not see your message content.
> PLEASE send without MIME…
> 
> Thanks,
> Himanshu
> 
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Thursday, October 22, 2015 11:20 AM
> To: Shah, Himanshu
> Cc: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org; The IESG
> Subject: Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

(originally sent 10/16; second try)

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu  wrote:
> 
> Hi Ralph -
> Thanks for your thorough review.
> 
> Let me first address your major concern.
> 
> As you point out, this draft builds on existing standards.
> We (authors and WG) had to carefully balance between the right amount of 
> information
> and wanting to describe details of methods described in other RFCs.
> 
> This is frustrating to implementer (including myself) having to go back and 
> forth
> between the documents. So I share that concern.
> 
> But we would like to refrain from indulging in beefing up the doc and risk 
> deviating
> from other base standards. However, for certain, if there is any conflict or 
> lack of
> clarity, we would prefer to rectify.

I agree that, in general, duplicating specifications from other documents 
increases the possibility that the respective documents unintentionally 
conflict with each other or are not updated in parallel.
> 
> To that end, I would rather prefer, trimming by removing 
> conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents 
concise and clear, along with trimming unnecessary text from 
draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> For example, sequence number processing - I rather would ask reader to get 
> all details
> from relevant RFC, and point to only delta (which is to apply same logic that 
> is used
> for 16-bit sequence number field to 32-bit field sequence number field that 
> is used in
> this document).

This example is sort of an interesting one to consider, as I was thinking more 
of the examples in which the format and semantics of the MAC TLVs are exactly 
the same as in the cited defining documents.

> 
> More comments in line.. and I look forward to your further guidance so we can 
> wrap this
> up in time.
> 
> As a data point, there are two implementations of this draft deployed in a 
> Telco network
> in Asia.

Noted.

> 
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Wednesday, October 14, 2015 4:02 PM
> To: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> 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
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
> Static Pseudowire"
> Reviewer: Ralph Droms
> Review Date: 2015-10-14
> IETF LC End Date: 2015-10-19
> IESG Telechat date: (if known) N/A
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> 
> Major issues:
> 
> While this document is describing a straightforward adaptation of previously 
> defined standards to statically provisioned PWs, in my opinion an implementor 
> would not necessarily be able to construct a fully interoperable 
> implementation from this document.  There are several sections of the 
> document that are not clear in their description of how to use mechanisms 
> from referenced documents in this standard.
> 
> If it appears that some of my comments are overly finicky, I'll agree that 
> the correct implementation could probably be deduced from the text in most 
> cases.  That is, I didn't find many outright errors or inconsistencies.  Many 
> of my comments took a lot of paging back and forth, reading of referenced 
> documents and head-scratching, which, in my experience, can lead to 
> implementations that don't interoperate.
> 
> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within 
draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and 
cited documents.  What I think would improve this specification is 
clarification that trims redundant specification details from 
draft-ietf-pals-mpls-tp-mac-wd and cites, concisely and exactly, the other 
documents from which the specifications are copied.

> 
> Section 1:
> 
> When the number of MAC addresses to be
> removed is large, the empty MAC List TLV may be used.  The empty MAC
> List TLV signifies wildcard MAC Address withdrawl.
> 
> This text seems to be the only reference 

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

(originally sent 10/16)

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu  wrote:
> 
> Hi Ralph -
> Thanks for your thorough review.
> 
> Let me first address your major concern.
> 
> As you point out, this draft builds on existing standards.
> We (authors and WG) had to carefully balance between the right amount of 
> information
> and wanting to describe details of methods described in other RFCs.
> 
> This is frustrating to implementer (including myself) having to go back and 
> forth
> between the documents. So I share that concern.
> 
> But we would like to refrain from indulging in beefing up the doc and risk 
> deviating
> from other base standards. However, for certain, if there is any conflict or 
> lack of
> clarity, we would prefer to rectify.

I agree that, in general, duplicating specifications from other documents 
increases the possibility that the respective documents unintentionally 
conflict with each other or are not updated in parallel.
> 
> To that end, I would rather prefer, trimming by removing 
> conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents 
concise and clear, along with trimming unnecessary text from 
draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> For example, sequence number processing - I rather would ask reader to get 
> all details
> from relevant RFC, and point to only delta (which is to apply same logic that 
> is used
> for 16-bit sequence number field to 32-bit field sequence number field that 
> is used in
> this document).

This example is sort of an interesting one to consider, as I was thinking more 
of the examples in which the format and semantics of the MAC TLVs are exactly 
the same as in the cited defining documents.

> 
> More comments in line.. and I look forward to your further guidance so we can 
> wrap this
> up in time.
> 
> As a data point, there are two implementations of this draft deployed in a 
> Telco network
> in Asia.

Noted.

> 
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Wednesday, October 14, 2015 4:02 PM
> To: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> 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
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
> Static Pseudowire"
> Reviewer: Ralph Droms
> Review Date: 2015-10-14
> IETF LC End Date: 2015-10-19
> IESG Telechat date: (if known) N/A
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> 
> Major issues:
> 
> While this document is describing a straightforward adaptation of previously 
> defined standards to statically provisioned PWs, in my opinion an implementor 
> would not necessarily be able to construct a fully interoperable 
> implementation from this document.  There are several sections of the 
> document that are not clear in their description of how to use mechanisms 
> from referenced documents in this standard.
> 
> If it appears that some of my comments are overly finicky, I'll agree that 
> the correct implementation could probably be deduced from the text in most 
> cases.  That is, I didn't find many outright errors or inconsistencies.  Many 
> of my comments took a lot of paging back and forth, reading of referenced 
> documents and head-scratching, which, in my experience, can lead to 
> implementations that don't interoperate.
> 
> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within 
draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and 
cited documents.  What I think would improve this specification is 
clarification that trims redundant specification details from 
draft-ietf-pals-mpls-tp-mac-wd and cites, concisely and exactly, the other 
documents from which the specifications are copied.

> 
> Section 1:
> 
> When the number of MAC addresses to be
> removed is large, the empty MAC List TLV may be used.  The empty MAC
> List TLV signifies wildcard MAC Address withdrawl.
> 
> This text seems to be the only reference to the process

Re: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

Hi, Himanshu - responses in line...

> On Oct 15, 2015, at 7:44 PM 10/15/15, Shah, Himanshu  wrote:
> 
> Hi Ralph -
> Thanks for your thorough review.
> 
> Let me first address your major concern.
> 
> As you point out, this draft builds on existing standards.
> We (authors and WG) had to carefully balance between the right amount of 
> information
> and wanting to describe details of methods described in other RFCs.
> 
> This is frustrating to implementer (including myself) having to go back and 
> forth
> between the documents. So I share that concern.
> 
> But we would like to refrain from indulging in beefing up the doc and risk 
> deviating
> from other base standards. However, for certain, if there is any conflict or 
> lack of
> clarity, we would prefer to rectify.

I agree that, in general, duplicating specifications from other documents 
increases the possibility that the respective documents unintentionally 
conflict with each other or are not updated in parallel.
> 
> To that end, I would rather prefer, trimming by removing 
> conflicting/confusing text.

I wasn't clear in my review - I think making the references to other documents 
concise and clear, along with trimming unnecessary text from 
draft-ietf-pals-mpls-tp-mac-wd, will result in the best document.

> For example, sequence number processing - I rather would ask reader to get 
> all details
> from relevant RFC, and point to only delta (which is to apply same logic that 
> is used
> for 16-bit sequence number field to 32-bit field sequence number field that 
> is used in
> this document).

This example is sort of an interesting one to consider, as I was thinking more 
of the examples in which the format and semantics of the MAC TLVs are exactly 
the same as in the cited defining documents.

> 
> More comments in line.. and I look forward to your further guidance so we can 
> wrap this
> up in time.
> 
> As a data point, there are two implementations of this draft deployed in a 
> Telco network
> in Asia.

Noted.

> 
> 
> Thanks,
> Himanshu
> 
> 
> -Original Message-
> From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
> Sent: Wednesday, October 14, 2015 4:02 PM
> To: A. Jean Mahoney; General Area Review Team; 
> draft-ietf-pals-mpls-tp-mac-wd@ietf.org
> Subject: [Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd
> 
> 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
> 
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
> Static Pseudowire"
> Reviewer: Ralph Droms
> Review Date: 2015-10-14
> IETF LC End Date: 2015-10-19
> IESG Telechat date: (if known) N/A
> 
> Summary:
> 
> This draft is on the right track but has open issues, described in the review.
> 
> 
> Major issues:
> 
> While this document is describing a straightforward adaptation of previously 
> defined standards to statically provisioned PWs, in my opinion an implementor 
> would not necessarily be able to construct a fully interoperable 
> implementation from this document.  There are several sections of the 
> document that are not clear in their description of how to use mechanisms 
> from referenced documents in this standard.
> 
> If it appears that some of my comments are overly finicky, I'll agree that 
> the correct implementation could probably be deduced from the text in most 
> cases.  That is, I didn't find many outright errors or inconsistencies.  Many 
> of my comments took a lot of paging back and forth, reading of referenced 
> documents and head-scratching, which, in my experience, can lead to 
> implementations that don't interoperate.
> 
> [Himanshu>] Please see above for the justification of this approach.

Again, I wasn't clear in my review - my paging back and forth was both within 
draft-ietf-pals-mpls-tp-mac-wd and between draft-ietf-pals-mpls-tp-mac-wd and 
cited documents.  What I think would improve this specification is 
clarification that trims redundant specification details from 
draft-ietf-pals-mpls-tp-mac-wd and cites, concisely and exactly, the other 
documents from which the specifications are copied.

> 
> Section 1:
> 
>  When the number of MAC addresses to be
>  removed is large, the empty MAC List TLV may be used.  The empty MAC
>  List TLV signifies wildcard MAC Address withdrawl.
> 
> This text seems to be the only reference to the processing of an empty MAC 
>

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
Static Pseudowire"
Reviewer: Ralph Droms
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.


Major issues:

While this document is describing a straightforward adaptation of previously 
defined standards to statically provisioned PWs, in my opinion an implementor 
would not necessarily be able to construct a fully interoperable implementation 
from this document.  There are several sections of the document that are not 
clear in their description of how to use mechanisms from referenced documents 
in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the 
correct implementation could probably be deduced from the text in most cases.  
That is, I didn't find many outright errors or inconsistencies.  Many of my 
comments took a lot of paging back and forth, reading of referenced documents 
and head-scratching, which, in my experience, can lead to implementations that 
don't interoperate.

Section 1:

   When the number of MAC addresses to be
   removed is large, the empty MAC List TLV may be used.  The empty MAC
   List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List 
TLV.  Specification of how the protocol works doesn't belong in the 
Introduction, and "wildcard MAC Address withdrawal" could certainly use some 
more explanation.

Section 3:

   The PW OAM message header is exactly the same as what is
   defined in [RFC6478].

Is this statement really true?  The MAC Address Withdraw header seems to 
replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
flag.  The statement might be misleading to an implementor.

   a MAC address withdraw OAM message MUST contain a
   "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are 
the TLVs required to appear in any particular order?

   A single bit (called A-bit) is set to indicate if a MAC withdraw
   message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK 
contain a "Sequence Number" TLV?

   Only half of the sequence number space is used.  Modular arithmetic
   is used to detect wrapping of sequence number.  When sequence number
   wraps, all MAC addresses are flushed and the sequence number is
   reset.  The 16-bit sequence number handling is described in
   [RFC4385]. This document uses 32-bits sequence numbers and hence
   sequence number in half the number space (i.e. 31-bits or ~2billion)
   is considered in the valid receive range.

This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped 
but left me unsure about how my understanding of how to extend the sequence 
number mechanism to 32 bits corresponds to the expectations of this document.

Section 4.1:

   Each PW is associated with a counter to keep track of the sequence
   number of the transmitted MAC withdrawal messages.  Whenever a node
   sends a new set of MAC TLVs, it increments the transmitted sequence
   number counter, and include the new sequence number in the message.
   The transmit sequence number is initialized to 1 at the onset.

I'm pretty sure this is supposed to mean that the sequence number in the first 
message is 1.  The text could be interpreted to mean that the counter is 
initialized to 1 and then incremented to 2 when sending the first message.

   The retransmission MUST be
   ceased anytime when ACK is received or after three retries.  This
   avoids unended retransmissions in the absence of acknowledgements.
   Since retransmission time interval and the maximum number of retries
   is local configuration of the sender node, it is up to the
   implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the 
default 3?

   The 'R' reset bit is set in the first MAC withdraw
   to notify the remote peer to reset the send and receive sequence
   numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
   messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better 
to say "The R-bit is set in a message when one peer needs to force the remote 
peer to reset its send and receive sequence numbers"?  Does the device sending 
the message with the R-bit use a sequence number of 1 in that message, and 

[Gen-art] Review: draft-ietf-pals-mpls-tp-mac-wd

[Ralph Droms (rdroms)]

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-pals-mpls-tp-mac-wd-02, "MAC Address Withdrawal over 
Static Pseudowire"
Reviewer: Ralph Droms
Review Date: 2015-10-14
IETF LC End Date: 2015-10-19
IESG Telechat date: (if known) N/A

Summary:

This draft is on the right track but has open issues, described in the review.


Major issues:

While this document is describing a straightforward adaptation of previously 
defined standards to statically provisioned PWs, in my opinion an implementor 
would not necessarily be able to construct a fully interoperable implementation 
from this document.  There are several sections of the document that are not 
clear in their description of how to use mechanisms from referenced documents 
in this standard.

If it appears that some of my comments are overly finicky, I'll agree that the 
correct implementation could probably be deduced from the text in most cases.  
That is, I didn't find many outright errors or inconsistencies.  Many of my 
comments took a lot of paging back and forth, reading of referenced documents 
and head-scratching, which, in my experience, can lead to implementations that 
don't interoperate.

Section 1:

  When the number of MAC addresses to be
  removed is large, the empty MAC List TLV may be used.  The empty MAC
  List TLV signifies wildcard MAC Address withdrawl.

This text seems to be the only reference to the processing of an empty MAC List 
TLV.  Specification of how the protocol works doesn't belong in the 
Introduction, and "wildcard MAC Address withdrawal" could certainly use some 
more explanation.

Section 3:

  The PW OAM message header is exactly the same as what is
  defined in [RFC6478].

Is this statement really true?  The MAC Address Withdraw header seems to 
replace the "Refresh Timer" field with a "Reserved" field, and adds a new "R" 
flag.  The statement might be misleading to an implementor.

  a MAC address withdraw OAM message MUST contain a
  "Sequence Number TLV" otherwise the entire message is dropped.

Is the "Sequence Number TLV" required to be the first TLV in the message?  Are 
the TLVs required to appear in any particular order?

  A single bit (called A-bit) is set to indicate if a MAC withdraw
  message is for ACK.  Also, ACK does not include MAC TLV(s).

Does this mean that the message is an ACK if the A-bit is set?  Can an ACK 
contain a "Sequence Number" TLV?

  Only half of the sequence number space is used.  Modular arithmetic
  is used to detect wrapping of sequence number.  When sequence number
  wraps, all MAC addresses are flushed and the sequence number is
  reset.  The 16-bit sequence number handling is described in
  [RFC4385]. This document uses 32-bits sequence numbers and hence
  sequence number in half the number space (i.e. 31-bits or ~2billion)
  is considered in the valid receive range.

This paragraph is not at all clear to me. Reading section 4 of RFC 4385 helped 
but left me unsure about how my understanding of how to extend the sequence 
number mechanism to 32 bits corresponds to the expectations of this document.

Section 4.1:

  Each PW is associated with a counter to keep track of the sequence
  number of the transmitted MAC withdrawal messages.  Whenever a node
  sends a new set of MAC TLVs, it increments the transmitted sequence
  number counter, and include the new sequence number in the message.
  The transmit sequence number is initialized to 1 at the onset.

I'm pretty sure this is supposed to mean that the sequence number in the first 
message is 1.  The text could be interpreted to mean that the counter is 
initialized to 1 and then incremented to 2 when sending the first message.

  The retransmission MUST be
  ceased anytime when ACK is received or after three retries.  This
  avoids unended retransmissions in the absence of acknowledgements.
  Since retransmission time interval and the maximum number of retries
  is local configuration of the sender node, it is up to the
  implementers to pick a discipline.

Is the maximum number of retransmissions 3 or is it locally configured?  Is the 
default 3?

  The 'R' reset bit is set in the first MAC withdraw
  to notify the remote peer to reset the send and receive sequence
  numbers.  The 'R' bit must be cleared in subsequent MAC withdraw
  messages after the acknowledgement is received

"First" as in "first message after reset or restart or ???  Would it be better 
to say "The R-bit is set in a message when one peer needs to force the remote 
peer to reset its send and receive sequence numbers"?  Does the device sending 
the message with the R-bit use a sequence number of 1 in that message, and 
expect the next message from t

Re: [Gen-art] Gen-ART review of draft-ietf-dhc-dhcpv6-solmaxrt-update-03

[Ralph Droms (rdroms)]

Dan - thanks for your review.  Responses in line; edits will appear in the -04 
rev.

- Ralph

On Aug 25, 2013, at 7:29 AM 8/25/13, "Romascanu, Dan (Dan)" 
 wrote:

> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
> Document: draft-ietf-dhc-dhcpv6-solmaxrt-update-03
> Reviewer: Dan Romascanu
> Review Date: 8/25/13
> IETF LC End Date: 9/3/13
> IESG Telechat date: (if known)
> 
> Summary: Ready with minor issues
> 
> Major issues: None
> 
> Minor issues:
> 
> 1. My understanding is that although the default values of SOL_MAX_RT and 
> INF_MAX_RT were the same in RFC 3315, and now they are change to similar 
> values, there is no mandatory behavior defined for servers to set them at the 
> same values using the new override options. If this is the case then the 
> Abstract should say 
> 
> OLD: 
> 
> ... override the client's default value for SOL_MAX_RT
>   and INF_MAX_RT with a new value.
> 
> NEW: 
> 
> ... override the client's default value for SOL_MAX_RT
>   and INF_MAX_RT with new values.
> 
> If I am wrong, and the values of the two parameters are always identical at 
> defalult or after changes, then something needs to be said on this respect in 
> Section 8 (DHCPv6 Server Behavior)

Good catch; left over text from adding INF_MAX_RT after the draft was initially 
written.  I will use your suggested text.

> 
> 2. This is not a document problem but a WG management issue. I could not find 
> anything in the dhc WG charter that corresponds to this document, so I cannot 
> say whether this document meets the conditions of the 'contract with the 
> IESG'. Actually the charter seems not to have been updated for five years, if 
> not more. I guess that with Ralph as an author all is OK, but an update of 
> the charter seems to be needed. 

In my opinion, this work falls under this WG work item:

  1. Develop extensions to the DHCPv6 infrastructure as required to meet
 new applications and deployments of DHCP.

Admittedly, there is no explicit entry in the list of current topics that 
covers this document.

I know either Bernie, Tomek or Ted has pointed out that the dhc WG is 
rechartering.

> 
> 
> Nits/editorial comments:
> 
> Section 7: 
> 
> OLD:
> 
>   a DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
>   values that are less than 60 or more than 86400.
> 
> 
> New:
> 
>   A DHCPv6 client MUST silently ignore any SOL_MAX_RT or INF_MAX_RT
>   values that are less than 60 or more than 86400.

Fixed.

- Ralph


> 
> 
> Regards,
> 
> Dan
> 

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

[Gen-art] RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

[Ralph Droms \(rdroms\)]

Comment about DHCPv6 question in line...

- Ralph


-Original Message-
From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley 
(townsley); Bob Hinden; Brian Haberman; Thomas Narten; Erik Nordmark; William 
Allen Simpson; ipv6@ietf.org; ietf@ietf.org
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt
 

 > 4.2 router advertisement
 > 
 >   - "Note: If neither M nor O flags are set this indicates that no
 > information is available via DHCPv6."
 > 
 > This means that the responding router always knows if DHCPv6 is
 > definitely available or definitely not available.  Is there any
 > possibility that the responding router might not know?  

=> I don't think so. It should always know.

It's a network config and admin issue.  The router doesn't "learn" or "know" if 
DHCPv6 is available; rather, the router is explicitly configured by the network 
admin to advertise the availability of DHCPv6 to hosts.  Presumably, the 
netowkr admin knows whether DHCPv6 is available and configures the router 
appropriately.

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