Re: [Gen-art] Gen-ART review for draft-ietf-ippm-checksum-trailer-03

[Romascanu, Dan (Dan)]

Hi Al,

Thanks for the explanation, this helped me a lot.


1.   It may be useful to insert a paragraph that provides this explanation

2.   Makes sense - no change needed.

Regards,

Dan


From: MORTON, ALFRED C (AL) [mailto:acmor...@att.com]
Sent: Friday, October 23, 2015 1:32 AM
To: Romascanu, Dan (Dan); General Area Review Team
Cc: draft-ietf-ippm-checksum-trailer@tools.ietf.org
Subject: RE: Gen-ART review for draft-ietf-ippm-checksum-trailer-03

Hi Dan,
I'll wade-in as Document Shepherd and begin to answer your questions,
Al

1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

[ACM]
Yes, the mix is possible, because the receiver stack performs normally
and evaluates checksums. Inserting the time stamp at a lower layer and
keeping the checksum accurate by providing the checksum-complement octets at the
same lower layer is a sender-only process.

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.

[ACM]
In OWAMP and TWAMP, there are three Modes of operation for the Core protocol
(without optional extensions):
Unauthenticated (completely in the clear)
Authenticated
Encrypted

Authenticated mode does not calculate the HMAC over the timestamps and packet 
padding
fields in the Test Session packets, where checksum complement is used.
So, after lower layer placement of the timestamp and checksum-complement,
the HMAC is still valid.

Encrypted Mode requires the Timestamps of test packets to be encrypted,
so timestamps cannot be inserted at lower layers before transmission,
(unless you are also re-encrypting, then the checksum complement has little 
value,
as Tal points out).

Section 3.4 explains this, and provides limited *WAMP background
on the modes.

Hope this helps,
Al



From: Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
Sent: Thursday, October 22, 2015 11:55 AM
To: General Area Review Team
Cc: 
draft-ietf-ippm-checksum-trailer@tools.ietf.org
Subject: Gen-ART review for draft-ietf-ippm-checksum-trailer-03


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-ippm-checksum-trailer-03

Reviewer: Dan Romascanu

Review Date: 10/22/15

IETF LC End Date: N/A

IESG Telechat date: N/A



Summary:



This document is ready for publication. I have a couple of minor issues that 
need clarification and can be solved easily by minor editing.



Major issues:



Minor issues:



1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.



Nits/editorial comments:



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

Re: [Gen-art] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10

[Huangyihong (Rachel)]

Hi Vijay,

Sorry for omitting this one.

It is absolute:
A leecher is a peer that is downloading chunks from other peers, but it does 
not have the complete content. And of course, it is uploading while 
downloading. 
A seeder has complete copies of the content. So it is only uploading.
A leecher can become a seeder once it finishes downloading. But a peer can't be 
both a leecher and seeder at the same time.

BR,
Rachel


> -Original Message-
> From: Vijay K. Gurbani [mailto:v...@bell-labs.com]
> Sent: Friday, October 23, 2015 4:04 AM
> To: Huangyihong (Rachel); draft-ietf-ppsp-base-tracker-proto...@tools.ietf.org
> Cc: General Area Review Team;
> draft-ietf-ppsp-base-tracker-protocol.cha...@ietf.org;
> draft-ietf-ppsp-base-tracker-protocol...@ietf.org
> Subject: Re: Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10
> 
> Rachel: Thank you for attending to all my comments.
> 
> I did not see the resolution to this one, though:
> 
> > - S1.1: The taxonomy of a peer into a leecher or a seeder appears to be
> >absolute.  In real swarms (BitTorrent), a peer trades chunks with
> >other peers, so it is a leecher but also a provider for certain
> >chunks.  This eventuality is not considered here.
> 
> Any thoughts on how to proceed?
> 
> Other than that, I am fine with the resolution to the remaining ones.
> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review for draft-ietf-ippm-checksum-trailer-03

[MORTON, ALFRED C (AL)]

Hi Dan,
I'll wade-in as Document Shepherd and begin to answer your questions,
Al

1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

[ACM]
Yes, the mix is possible, because the receiver stack performs normally
and evaluates checksums. Inserting the time stamp at a lower layer and
keeping the checksum accurate by providing the checksum-complement octets at the
same lower layer is a sender-only process.

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.

[ACM]
In OWAMP and TWAMP, there are three Modes of operation for the Core protocol
(without optional extensions):
Unauthenticated (completely in the clear)
Authenticated
Encrypted

Authenticated mode does not calculate the HMAC over the timestamps and packet 
padding
fields in the Test Session packets, where checksum complement is used.
So, after lower layer placement of the timestamp and checksum-complement,
the HMAC is still valid.

Encrypted Mode requires the Timestamps of test packets to be encrypted,
so timestamps cannot be inserted at lower layers before transmission,
(unless you are also re-encrypting, then the checksum complement has little 
value,
as Tal points out).

Section 3.4 explains this, and provides limited *WAMP background
on the modes.

Hope this helps,
Al



From: Romascanu, Dan (Dan) [mailto:droma...@avaya.com]
Sent: Thursday, October 22, 2015 11:55 AM
To: General Area Review Team
Cc: draft-ietf-ippm-checksum-trailer@tools.ietf.org
Subject: Gen-ART review for draft-ietf-ippm-checksum-trailer-03


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-ippm-checksum-trailer-03

Reviewer: Dan Romascanu

Review Date: 10/22/15

IETF LC End Date: N/A

IESG Telechat date: N/A



Summary:



This document is ready for publication. I have a couple of minor issues that 
need clarification and can be solved easily by minor editing.



Major issues:



Minor issues:



1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.



Nits/editorial comments:



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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-netconf-call-home-11.txt

[Suresh Krishnan]

Hi Kent,

On 10/22/2015 06:03 PM, Kent Watsen wrote:
> [+barry]
>
> I apologize to reply to myself, but I would be remiss to not mention that 
> Barry Leiba had a related COMMENT on the "must immediately start” text.   His 
> suggestion is to remove the words “MUST immediately” (i.e. Just have 
> “start”).  As he writes: "What *else* might the client [server] do, which 
> merits a MUST here?”
>
> While I personally do think that it is “MUST immediately”, I think that the 
> wording is still be accurate without it...and thus simply removing these two 
> words provides an alternate way to resolve Suresh’s comment.  Thoughts?

That works for me as well. Go for it.

Cheers
Suresh


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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-netconf-call-home-11.txt

[Kent Watsen]

[+barry]

I apologize to reply to myself, but I would be remiss to not mention that Barry 
Leiba had a related COMMENT on the "must immediately start” text.   His 
suggestion is to remove the words “MUST immediately” (i.e. Just have “start”).  
As he writes: "What *else* might the client [server] do, which merits a MUST 
here?”

While I personally do think that it is “MUST immediately”, I think that the 
wording is still be accurate without it...and thus simply removing these two 
words provides an alternate way to resolve Suresh’s comment.  Thoughts?

Thanks,
Kent





On 10/22/15, 5:35 PM, "Kent Watsen"  wrote:

>
>Hi Jari, Suresh,
>
>Thank you for your suggestion.  How about this, after each of the four uses of 
>“must immediately start” (in C3, C8, S3, and S6), we add the sentence:
>
>It is unnecessary for the  [client/server] to wait
>for the remote peer to initiate the  first.
>
>Would this be helpful?
>
>Thanks,
>Kent
>
>
>
>
>
>On 10/22/15, 9:05 AM, "Jari Arkko"  wrote:
>
>>Thanks for the explanation, Kent, and for the review, Suresh. Can the 
>>explanation be added to the document for other people who might have the same 
>>question.
>>
>>Jari
>>
>>On 21 Oct 2015, at 19:37, Kent Watsen  wrote:
>>
>>> 
>>> Hi Suresh,
>>> 
>>> Thank you for your review.
>>> 
>>> To answer your question, the server can start the SSH server protocol 
>>> immediately.  It does not have the wait for the client for anything.  At 
>>> least, this is how my code works  :)
>>> 
>>> Thanks again,
>>> Kent
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 10/21/15, 12:10 AM, "Suresh Krishnan"  
>>> wrote:
>>> 
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 
 
 Please wait for direction from your document shepherd or AD before
 posting a new version of the draft.
 
 Document: draft-ietf-netconf-call-home-11.txt
 Reviewer: Suresh Krishnan
 Review Date: 2015/10/20
 IESG Telechat date: 2015/10/22
 
 Summary: The draft is ready for publication as a Proposed Standard but I do
 have a comment that you may wish to address.
 
 Minor
 =
 
 * Section 3.1 S3: The server cannot immediately start the SSH server 
 protocol
 without waiting for SSH connection initiation from the SSH client, right? 
 If
 yes, shouldn't there be an additional condition here?
 
 Thanks
 Suresh
 
 
>>> ___
>>> Gen-art mailing list
>>> Gen-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/gen-art
>>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-netconf-call-home-11.txt

[Kent Watsen]

Hi Jari, Suresh,

Thank you for your suggestion.  How about this, after each of the four uses of 
“must immediately start” (in C3, C8, S3, and S6), we add the sentence:

It is unnecessary for the  [client/server] to wait
for the remote peer to initiate the  first.

Would this be helpful?

Thanks,
Kent





On 10/22/15, 9:05 AM, "Jari Arkko"  wrote:

>Thanks for the explanation, Kent, and for the review, Suresh. Can the 
>explanation be added to the document for other people who might have the same 
>question.
>
>Jari
>
>On 21 Oct 2015, at 19:37, Kent Watsen  wrote:
>
>> 
>> Hi Suresh,
>> 
>> Thank you for your review.
>> 
>> To answer your question, the server can start the SSH server protocol 
>> immediately.  It does not have the wait for the client for anything.  At 
>> least, this is how my code works  :)
>> 
>> Thanks again,
>> Kent
>> 
>> 
>> 
>> 
>> 
>> 
>> On 10/21/15, 12:10 AM, "Suresh Krishnan"  
>> wrote:
>> 
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>> 
>>> 
>>> Please wait for direction from your document shepherd or AD before
>>> posting a new version of the draft.
>>> 
>>> Document: draft-ietf-netconf-call-home-11.txt
>>> Reviewer: Suresh Krishnan
>>> Review Date: 2015/10/20
>>> IESG Telechat date: 2015/10/22
>>> 
>>> Summary: The draft is ready for publication as a Proposed Standard but I do
>>> have a comment that you may wish to address.
>>> 
>>> Minor
>>> =
>>> 
>>> * Section 3.1 S3: The server cannot immediately start the SSH server 
>>> protocol
>>> without waiting for SSH connection initiation from the SSH client, right? If
>>> yes, shouldn't there be an additional condition here?
>>> 
>>> Thanks
>>> Suresh
>>> 
>>> 
>> ___
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] A *new* batch of IETF LC reviews - 2015-10-22

[A. Jean Mahoney]

Hi all,

The following reviewers have assignments:

Reviewer  LC end   Draft
-
Robert Sparks 2015-10-30   draft-ietf-isis-route-preference-02

Roni Even 2015-11-02   draft-ietf-sidr-rfc6485bis-04

Suresh Krishnan   2015-11-02   draft-ietf-pcp-third-party-id-option-04


I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The /updated/ template is included below.

Thanks,

Jean

---

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

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

Re: [Gen-art] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10

[Vijay K. Gurbani]

Rachel: Thank you for attending to all my comments.

I did not see the resolution to this one, though:


- S1.1: The taxonomy of a peer into a leecher or a seeder appears to be
   absolute.  In real swarms (BitTorrent), a peer trades chunks with
   other peers, so it is a leecher but also a provider for certain
   chunks.  This eventuality is not considered here.


Any thoughts on how to proceed?

Other than that, I am fine with the resolution to the remaining ones.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

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

Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02

[Alia Atlas]

Thanks - LGTM.

Alia

On Thu, Oct 22, 2015 at 3:56 PM, Fred Baker (fred)  wrote:

>
> On Oct 22, 2015, at 1:48 PM, Pete Resnick 
> wrote:
>
> You missed the Zhang reference in 2.2.5. Otherwise fine.
>
>
>
>
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02

[Pete Resnick]

You missed the Zhang reference in 2.2.5. Otherwise fine.

pr

On 22 Oct 2015, at 11:45, Fred Baker (fred) wrote:


See attached. Sorry for the oversight.

On Oct 22, 2015, at 12:09 PM, Pete Resnick 
 wrote:


All of the changes you made look fine.

You changed the reference to Brisoce, but didn't change McKenny, 
Shreedar, or Zhang. I still think you should.


You missed the nit in section 4, paragraph 2 (s/a mark/mark).

There's still no explanation of why this is likely to be a useful 
document in the future (which may be more for the shepherd writeup 
than for the document itself, and given that the IESG is already 
doing their work, may be moot).


pr

On 22 Oct 2015, at 10:47, Fred Baker (fred) wrote:

Thanks Pete. I had updated the draft on October 12 in response to 
working group comments, so the diff I'm sending is against -02 (which 
you reviewed) and includes those changes. I have attached a -04 
version, which I plan to post when the repository opens. If you have 
other comments or are not satisfied with the changes, it still has 
room to change.


On Oct 6, 2015, at 6:06 PM, Pete Resnick presn...@qti.qualcomm.com 
 wrote:


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 
 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq 
.


Document: draft-ietf-aqm-fq-implementation-02
Reviewer: Pete Resnick
Review Date: 2015-10-6
IETF LC End Date: 2015-10-15
IESG Telechat date: 2015-10-22

Summary:

This document is in fine shape and is generally ready for publication 
(caveat some minor things below); no major issues at all. One overall 
question though:


Neither the document nor the shepherd writeup explain why this 
document will be useful for future work. It may very well be (I'm no 
expert in the area), but it's at least not obvious to me that it is. 
You've already pulled the lever to start an IETF-wide Last Call, but 
before it goes to the IESG for them to work on, perhaps it would be 
good to say why the WG thinks this is useful as a permanent 
publication in the RFC series as against just a working reference 
document for the WG. Is some future WG likely to want to refer to 
this document when doing queue management work?


Presuming it is desirable to publish, here are the remainder of my 
comments. Some of them are right on the line between "minor issue" 
and "editorial" (they're editorial, but did cause some confusion for 
me), so I just grouped them all together here.


Minor issues and nits/editorial comments:

In 2.1.3, calling out any author by name is a bit weird in an IETF 
document, but in this case the reference is to RFC 7141, an IETF BCP. 
While I know Bob's a smart guy and I'm sure he contributed 
substantially to that document, I don't think calling out a just one 
author of an IETF consensus document is appropriate. (I think it's 
stylistically a little weird to use author names in general in IETF 
documents, but at least in two of the other cases, it's a single 
author of a non-IETF document; calling out Shreedhar and not Varghese 
is still weird to me, though I understand it is common practice in 
academic literature. If it were me, I'd reference the title, not the 
author. That said, you're going to have to fight it out with the RFC 
Editor regarding whether those URLs are "stable references".)


In 2.2, second sentence: The algorithm isn't empty or not empty, the 
queue is empty or not empty. This had me really confused for a bit. 
Please fix the sentence.


In 2.2.1ff: Instead of "a method, called 'enqueue'", say "an enqueue 
method". Personally, I'd prefer "function" or "operation" instead of 
"method" throughout, but that's your choice really. (Using "a method, 
called 'enqueue'" implies an actual implementation in a particular 
kind of programming language.) Whichever terminology you choose, pick 
one and stick to it throughout the document. Right now you switch. 
(Obviously the same comment for "a method, called 'dequeue'".)


In 2.2.2 and 2.2.3, each in the 3rd paragraph, the verb "removes" 
does not have a subject. I think you need to say "the dequeue 
function" somewhere in each sentence.


In 2.2.2, your reference to using a hash as a classifier threw me. I 
figured out what you meant, but it was an unfamiliar concept to me. 
But I'm also not sure why it's useful to call out a particular kind 
of classifier in the first place. I'd think it would be better to 
just describe generally how a classifier can be used to put data into 
different queues. (And shouldn't this be part of the enqueue 
paragraph? Are classifiers used to dequeu

Re: [Gen-art] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02

[Pete Resnick]

All of the changes you made look fine.

You changed the reference to Brisoce, but didn't change McKenny, 
Shreedar, or Zhang. I still think you should.


You missed the nit in section 4, paragraph 2 (s/a mark/mark).

There's still no explanation of why this is likely to be a useful 
document in the future (which may be more for the shepherd writeup than 
for the document itself, and given that the IESG is already doing their 
work, may be moot).


pr


On 22 Oct 2015, at 10:47, Fred Baker (fred) wrote:

Thanks Pete. I had updated the draft on October 12 in response to 
working group comments, so the diff I'm sending is against -02 (which 
you reviewed) and includes those changes. I have attached a -04 
version, which I plan to post when the repository opens. If you have 
other comments or are not satisfied with the changes, it still has 
room to change.


On Oct 6, 2015, at 6:06 PM, Pete Resnick  
wrote:


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-aqm-fq-implementation-02
Reviewer: Pete Resnick
Review Date: 2015-10-6
IETF LC End Date: 2015-10-15
IESG Telechat date: 2015-10-22

Summary:

This document is in fine shape and is generally ready for publication 
(caveat some minor things below); no major issues at all. One overall 
question though:


Neither the document nor the shepherd writeup explain why this 
document will be useful for future work. It may very well be (I'm no 
expert in the area), but it's at least not obvious to me that it is. 
You've already pulled the lever to start an IETF-wide Last Call, but 
before it goes to the IESG for them to work on, perhaps it would be 
good to say why the WG thinks this is useful as a permanent 
publication in the RFC series as against just a working reference 
document for the WG. Is some future WG likely to want to refer to 
this document when doing queue management work?


Presuming it is desirable to publish, here are the remainder of my 
comments. Some of them are right on the line between "minor issue" 
and "editorial" (they're editorial, but did cause some confusion for 
me), so I just grouped them all together here.


Minor issues and nits/editorial comments:

In 2.1.3, calling out any author by name is a bit weird in an IETF 
document, but in this case the reference is to RFC 7141, an IETF BCP. 
While I know Bob's a smart guy and I'm sure he contributed 
substantially to that document, I don't think calling out a just one 
author of an IETF consensus document is appropriate. (I think it's 
stylistically a little weird to use author names in general in IETF 
documents, but at least in two of the other cases, it's a single 
author of a non-IETF document; calling out Shreedhar and not Varghese 
is still weird to me, though I understand it is common practice in 
academic literature. If it were me, I'd reference the title, not the 
author. That said, you're going to have to fight it out with the RFC 
Editor regarding whether those URLs are "stable references".)


In 2.2, second sentence: The algorithm isn't empty or not empty, the 
queue is empty or not empty. This had me really confused for a bit. 
Please fix the sentence.


In 2.2.1ff: Instead of "a method, called 'enqueue'", say "an enqueue 
method". Personally, I'd prefer "function" or "operation" instead of 
"method" throughout, but that's your choice really. (Using "a method, 
called 'enqueue'" implies an actual implementation in a particular 
kind of programming language.) Whichever terminology you choose, pick 
one and stick to it throughout the document. Right now you switch. 
(Obviously the same comment for "a method, called 'dequeue'".)


In 2.2.2 and 2.2.3, each in the 3rd paragraph, the verb "removes" 
does not have a subject. I think you need to say "the dequeue 
function" somewhere in each sentence.


In 2.2.2, your reference to using a hash as a classifier threw me. I 
figured out what you meant, but it was an unfamiliar concept to me. 
But I'm also not sure why it's useful to call out a particular kind 
of classifier in the first place. I'd think it would be better to 
just describe generally how a classifier can be used to put data into 
different queues. (And shouldn't this be part of the enqueue 
paragraph? Are classifiers used to dequeue?)


In 2.2.4, last paragraph: WRR is not defined. Did you mean DRR?

In 4, paragraph 2, s/a mark/mark

I hope that's helpful.

pr



--
Pete Resnick 
Qualcomm Technologies, Inc. - +1 (858)651-4478___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review for draft-ietf-ippm-checksum-trailer-03

[Romascanu, Dan (Dan)]

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-ippm-checksum-trailer-03

Reviewer: Dan Romascanu

Review Date: 10/22/15

IETF LC End Date: N/A

IESG Telechat date: N/A



Summary:



This document is ready for publication. I have a couple of minor issues that 
need clarification and can be solved easily by minor editing.



Major issues:



Minor issues:



1.   It is not clear to me how backwards compatibility is ensured. How do 
implementations make distinction between OWAMP or TWAMP packets that use 
timestamp update and Checksum Complement rather than timestamp update and UDP 
checksum update? Is a mix of senders/receivers (for OWAMP) or 
senders/reflectors (for TWAMP) that some support and some do not support 
Checksum Complement possible?

2.   The last paragraph in section 4 reads: 'The concept described in this 
document is intended to be used only in unauthenticated or in authenticated 
mode.' This seems either a mistake, or I did not understand what it means and 
some clarification is needed.



Nits/editorial comments:



___
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

[Shah, Himanshu]

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

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

[Shah, Himanshu]

Still no luck. No message content.

Andy Malis – is it possible for you to send Ralph’s email?

Thanks,
Himanshu

From: Ralph Droms (rdroms) [mailto:rdr...@cisco.com]
Sent: Thursday, October 22, 2015 11:27 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


___
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)]

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
> 
> .
> 
> 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 
> 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.
> 
> [Himanshu>] I would prefer taking the text out if its mention in 
> "Introduction" section is not desirable.
> Wildcard MAC withdr

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
> 
> .
> 
> 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 
> 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.
> 
> [Himanshu>] I would prefer taking the text out if its mention in 
> "Introduction" section is not desirable.
> Wildcard MAC withdraw is a very

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

[Shah, Himanshu]

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


___
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-trill-rfc7180bis-06

[Donald Eastlake]

Hi Jari,

On Thu, Oct 22, 2015 at 8:51 AM, Jari Arkko  wrote:
> Meral, many thanks for the review. Donald, many thanks for the changes.
>
> I have balloted no-obj.
>
> On re: conflicts, I understood the sentence as a usual if-all-else-fails 
> clause of specifying which document has precedence in case some conflicts are 
> discovered later. I think that’s fine. Is this your understanding too, Donald?

Yes, I would say that sentence is really just a back-stop as you describe.

Thanks,
Donald
=
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e...@gmail.com

> Jari
>
> On 21 Oct 2015, at 17:20, Meral Shirazipour  
> wrote:
>
>> Hi Donald,
>>  Thank you for considering the changes. Please see in-line for a few more 
>> comments.
>>
>> Best,
>> Meral
>>
>>> -Original Message-
>>> From: Donald Eastlake [mailto:d3e...@gmail.com]
>>> Sent: Wednesday, October 21, 2015 7:54 AM
>>> To: Meral Shirazipour
>>> Cc: draft-ietf-trill-rfc7180bis@tools.ietf.org; gen-art@ietf.org
>>> Subject: Re: Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06
>>>
>>> Hi Meral,
>>>
>>> On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
>>>  wrote:
 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.


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


 Document: draft-ietf-trill-rfc7180bis-06
 Reviewer: Meral Shirazipour (was originally assigned to another
 gen-art) Review Date: 2015-10-19 IETF LC End Date:  2015-10-19 IESG
 Telechat date: 2015-10-22



 Summary:

 This draft is ready to be published as Standards Track RFC but I have
 some comments .
>>>
>>> Thanks. See below.
>>>
 Major issues:


 Minor issues:

 -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325.
 The update is about conflict resolution between sections of the RFC.

 Shouldn't this bis highlight those conflicts if any?
>>>
>>> I do not believe there are any real conflicts. RFC 6325 has some
>>> general/introductory sections and some detailed technical sections.
>>> The general sections, particularly Section 2, are written with a pedagogical
>>> goal of giving the reader the best general understanding and such general
>>> sections are not necessarily precise and do not, in general, include every
>>> corner case. During the development of RFC 6325, some reader focused on
>>> such general descriptions and claimed that the "conflicted" with the 
>>> precise,
>>> detailed technical sections.
>>> Thus Section 1.2 was added to RFC6325 to resolve this and make it clear that
>>> the later detailed sections should be followed in case of any such apparent
>>> "conflict".
>>>
>>> I don't really remember exactly what motivated making the material about
>>> precedence of sections in RFC 6325 more complete in RFC 7180 but it was
>>> probably based on some comment.
>>>
>>> The only change from Section 1.1 of RFC 7180 to this Section 1.1 draft-ietf-
>>> trill-rfc7180bis is updating of some other RFC numbers in this section.
>>>
>>
>> [MSh] Would it be possible to add a few sentences to clarify that? or maybe 
>> remove the word "conflict" ?
>>
>>
 -[Page 14], Section 3.4. Should this section have a MUST sentence just
 before the last sentence?

 "All RBridges in a campus MUST determine distribution trees in the
 same way "
>>>
>>> I don't think so. The mandatory implementation of the distribution tree
>>> computation provisions is elsewhere. The sentence you refer to is just
>>> discussion of the consequences of failure to follow that.
>>>
 -[Page 10], Section 2.4.2.1 , gives an example, then the first bullet
 after the figure explains the problem with that scenario and says
 "MUST NOT be locally distributed in native form ".

 Is it possible to clarify what should be done instead?
>>>
>>> This section is about tunneling the frame to a neighbor that is offering the
>>> OOMF service. It could be re-worded a little to use "instead" rather than
>>> "before". The change would be
>>>
>>> OLD
>>>  The multi-destination frame MUST NOT be locally distributed in
>>>  native form at RB2 before tunneling to a neighbor because this
>>>  would cause the frame to be delivered twice.
>>>
>>> NEW
>>>  The multi-destination frame MUST NOT be locally distributed in
>>>  native form at RB2 because this
>>>  would cause the frame to be delivered twice. Instead it is tunneling 
>>> to a
>>> neighbor as provided in this section.
>>>
>>
>> [MSh] NEW looks good to me. Thanks.
>>
 -[Page 11], last line, "forwards the packet on that tree."

 Just checking if that is supposed to say "packet" or if it should say
 "frame" or "TRILL Data packet"?
>>>
>>> It would be more 

Re: [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02

[Jari Arkko]

> Yes, the tools servers don't currently follow replaces the same way the 
> datatracker does.
> Henrik is aware of it, and is working to make them say the same thing.

Cool, thanks!

Jari



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 LC review: draft-ietf-pals-redundancy-spe-02

[Robert Sparks]

On 10/22/15 5:15 AM, Jari Arkko wrote:


But in this case I noticed that 
http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows 
1 IPR whereas 
https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02 does 
not. But https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 
does. What gives? Robert, do you know if the tools version does not 
track through replaced-by? Getting such information properly displayed 
in all cases might be important, as many people use the tools server 
to view drafts.


Yes, the tools servers don't currently follow replaces the same way the 
datatracker does.

Henrik is aware of it, and is working to make them say the same thing.

RjS

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

Re: [Gen-art] [Gen-Art] Review: draft-ietf-ace-usecases-07

[Jari Arkko]

Thanks for this, Joel. I agree with your suggestion.

Jari

On 16 Oct 2015, at 06:55, Joel M. Halpern  wrote:

> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ace-usecases-07
>ACE use cases
> Reviewer: Joel M. Halpern
> Review Date: 15-Oct-2015
> IETF LC End Date: 22-Oct-2015
> IESG Telechat date: 22-Oct-2015
> 
> Summary: This document is ready to be published as an Informational RFC.
> 
> Major issues: N/A
> 
> Minor issues:
>I believe ACE should be spelled out in the title.
> 
>I am mildly concerned that some of the requirements may be undecidable or 
> unmeetable, such as a requirement for easily sanitizing a log to leave needed 
> historical information while removing personal information (U2.12).  I 
> understand the motivation for this.  But I think the document might be helped 
> by a warning about their being conflicting goals within or among some 
> requirements.
> 
> Nits/editorial comments: N/A
> 
> ___
> 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] Gen-ART Telechat Call review of draft-ietf-6man-predictable-fragment-id-10

[Jari Arkko]

Thanks again Meral for the review.

Jari

On 17 Oct 2015, at 03:38, Meral Shirazipour  
wrote:

> Hi,
>  Thank you.
> 
> Best,
> Meral
> 
>> -Original Message-
>> From: Fernando Gont [mailto:fg...@si6networks.com]
>> Sent: Friday, October 16, 2015 3:20 PM
>> To: Meral Shirazipour; draft-ietf-6man-predictable-fragment-
>> id@tools.ietf.org; gen-art@ietf.org
>> Subject: Re: Gen-ART Telechat Call review of draft-ietf-6man-predictable-
>> fragment-id-10
>> 
>> Hi, Meral,
>> 
>> Thanks so much for your feedback! Please find my comments in-line...
>> 
>> On 10/16/2015 07:07 PM, Meral Shirazipour wrote:
>> []
>>> 
>>> Summary: This draft is ready to be published as Informational RFC.
>>> 
>> []>
>>> 
>>> Nits/editorial comments:
>>> 
>>> [Page 7], "that needs to fragmented"--->"that needs to be fragmented"
>> 
>> Will fix this.
>> 
>> Thanks!
>> 
>> Cheers,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fg...@si6networks.com
>> PGP Fingerprint:  31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
> 
> ___
> 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] Gen-ART Last Call review of draft-ietf-aqm-ecn-benefits-06 (resend)

[Jari Arkko]

Thanks for your review!

On 06 Oct 2015, at 18:00, Paul Kyzivat  wrote:

> 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 
> .
> 
> Summary: This draft is ready for publication as an Informational RFC.
> 
> This is a well written document. I know nothing about the subject area but 
> was able to follow the document and understand the points it is making.
> 
> Major Issues: NONE
> 
> Minor Issues: NONE
> 
> Nits: NONE that I noticed.
> 
> ___
> 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] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02

[Jari Arkko]

Thanks for the review, Pete. Authors, did you have any responses to the points 
that Pete is making?

FWIW, I think that the algorithm/queue empty and WRR issues need a fix, and I 
also agree with Pete on RFC/author name reference issue,

Jari



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 Review of draft-ietf-lisp-impact-04

[Jari Arkko]

Thanks for the edits & review.

Jari

On 17 Oct 2015, at 20:50, Luigi Iannone  wrote:

> Hi Russ,
> 
> thanks for the review.
> Inline you can find our propose changes in order to fix the issues.
> 
> Let us know if such proposed changes are sufficient.
> 
> ciao
> 
> Luigi
> 
> 
> 
>> On 14 Oct 2015, at 18:50, Russ Housley  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-lisp-impact-04
>> Reviewer: Russ Housley
>> Review Date: 2015-10-14
>> IETF LC End Date: 2015-10-19
>> IESG Telechat date: unknown
>> 
>> Summary:  Almost Ready.
>> 
>> 
>> Major Concerns:
>> 
>> Section 3 says: "[KIF13] and [CDLC] explore different EDI prefix space
>> sizes, and still show results that are consistent and equivalent to the
>> above assumptions."  It seems like it would be valuable to include a
>> sentence or two about the way that EDI space is obtained.
> 
> 
> What if we modify the paragraph as follows:
> 
>   [KIF13] and [CDLC] explore different EID prefix space sizes, and
>   still show results that are consistent and equivalent to the above
>   assumptions. In particular, [KIF13] looks at what happens using all
>   possible /24 and /27 as fixed-size prefixes, while [CDLC] filters out
>   all de-aggregation from the BGP routing infrastructure (hence including
>   PA addresses).
> 
> 
>> 
>> 
>> Minor Concerns:
>> 
>> I found the Introduction and LISP in a nutshell sections a bit too
>> much like marketing material.  I think the document would be better
>> if the tone was more like an engineering analysis.
>> 
>> Perhaps this paragraph can be moved to the top:
>> 
>> An introduction to LISP can be found in [RFC7215].  The LISP
>> specifications are given in [RFC6830], [RFC6833],
>> [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834].
>> 
> 
> We think that the solution would be:
> 
> 1. Move the last paragraph as actually the first (as you suggest)
> 
> 2. Re-word the second-last paragraph
> 
> OLD Version:
> 
>   The correspondence between EIDs and RLOCs is given by the mappings.
>   When an ITR needs to find ETR RLOCs that serve an EID, it queries a
>   mapping system.  With the LISP Canonical Address Format (LCAF)
>   [I-D.ietf-lisp-lcaf], LISP is not restricted to the Internet Protocol
>   for the EID addresses.  With LCAF, any address type can be used as
>   EID (the address is only the key for the mapping lookup).  LISP can
>   transport, for example, Ethernet frames over the Internet.
> 
> NEW Version:
> 
>   The correspondence between EIDs and RLOCs is given by the mappings.
>   When an ITR needs to find ETR RLOCs that serve an EID, it queries a
>   mapping system.  The LISP Canonical Address Format (LCAF)
>   [I-D.ietf-lisp-lcaf] allows LISP to use addresses other than the 
> Internet Protocol.
>   Such address are used as lookup key in the mapping system.
>   In this way it is possible, for example, to LISP-encapsulate Ethernet 
> frames.
> 
> 
>> Section 5 has very little content on "business models".  There is some,
>> but not much.  It seems odd that it appears in the section heading.
> 
> That is correct. There is very little about business.
> We can simplify the title to: "Impact of LISP on network operations”
> 
> 
>> 
>> 
>> Other Comments:
>> 
>> Please spell out "DPI" and "DFZ" on first use.
> 
> Consider it done.
> 
>> 
>> Section 4 says: "Without LISP, operators are forced to centralize
>> service anchors in custom built boxes."  This seems a bit too strong.
>> Perhaps: "Without LISP, operators centralize service anchors.”
> 
> Much more straightforward. Thanks.
> 
> 
>> 
>> Section 4.1: s/(non-LISP)routing/(non-LISP) routing/
> 
> Thanks for the catch.
> 
> ciao
> 
> Luigi
> 
> 



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 Telechat review of draft-ietf-ippm-type-p-monitor-02.txt

[Jari Arkko]

Thanks for the review and responses.

Jari

On 22 Oct 2015, at 05:03, Suresh Krishnan  wrote:

> Hi Greg,
>   Thanks for addressing my comments quickly. Your proposed changes sound
> good to me.
> 
> Cheers
> Suresh
> 
> On 10/21/2015 04:38 PM, Gregory Mirsky wrote:
>> Hi Suresh,
>> thank you for the most careful review and very helpful comments. Please find 
>> my answers in-line and tagged by GIM>>.
>> 
>>  Regards,
>>  Greg
>> 
>> -Original Message-
>> From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com]
>> Sent: Tuesday, October 20, 2015 8:13 PM
>> To: draft-ietf-ippm-type-p-monitor@ietf.org; General Area Review Team
>> Subject: Gen-ART Telechat review of draft-ietf-ippm-type-p-monitor-02.txt
>> 
>> I am the assigned Gen-ART reviewer for this draft. For background on 
>> Gen-ART, please see the FAQ at 
>> 
>> 
>> Please wait for direction from your document shepherd or AD before posting a 
>> new version of the draft.
>> 
>> Document: draft-ietf-ippm-type-p-monitor-02.txt
>> Reviewer: Suresh Krishnan
>> Review Date: 2015/10/20
>> IESG Telechat date: 2015/10/22
>> 
>> Summary: The draft is almost ready for publication as a Proposed Standard 
>> but I do have some comments that you may wish to address.
>> 
>> Minor
>> =
>> 
>> * MBZ is not expanded. I understand this should expand to "Must Be Zero" and 
>> it MUST be set to zero by senders and MUST be ignored by receivers. It makes 
>> sense to add this to the terminology section or before first use.
>> GIM>> MBZ is used only in figures that reflect updates to formats defined in 
>> RFC 5357. None of fields defined in RFC 5357 referenced in this proposal and 
>> their identification in the figures is the same as in RFC 5357. I think it 
>> may be confusing to those familiar with RFC 5357 to see "Must Be Zero" 
>> instead of MBZ in figures.
>> 
>> * Please cite as references RFC2474 for the DSCP field and RFC3168 for ECN.
>> GIM>> Thank you, will add references and send diff for review.
>> 
>> * Section 2.2.1:
>> 
>> "the first six bits of the Differentiated Service field"
>> 
>> Not sure if this "first" qualification is required as RFC2474 defines the 
>> DSCP field to be *exactly* 6 bits long. I have a similar issue with the word 
>> "following" in the definition of the ECN field as they are two separate 
>> fields.
>> GIM>> Al suggested re-wording that, in my view, makes it clear and 
>> unambiguous:
>>o  the six (least-significant) bits of the Differentiated Service
>>   field MUST be copied from received Session-Sender test packet into
>>   Sender DSCP (S-DSCP) field;
>> 
>> * Section 2.2.2: Figure 4 seems to be incomplete and it has no mention of 
>> either DSCP or ECN. Is this correct? Probably would also explain where the 
>> 28 byte padding requirement comes from.
>> GIM>> Figure 4 reflects impact of DSCP and ECM Monitoring on test packet 
>> transmitted by a Session-Sender that supports RFC 6038. RFC 6038 states that 
>> in order to support Symmetrical Size and/or Reflects Octets modes 
>> Session-Sender must append at least 27 octet-long Packet Padding. Because 
>> the DSCP and ECM Monitoring extension requires Session-Reflector to copy 
>> additional octet, the minimal size of Packet Padding to support RFC 6038 
>> must be 28 octets.
>> 
>> Editorial
>> =
>> 
>> * Section 2.2.1
>> 
>> s/MUST extracts/MUST extract/
>> GIM>> Done.
>> 
>> Thanks
>> Suresh
>> 
>> 
> 
> 
> ___
> 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] Gen-ART Telechat review of draft-ietf-netconf-call-home-11.txt

[Jari Arkko]

Thanks for the explanation, Kent, and for the review, Suresh. Can the 
explanation be added to the document for other people who might have the same 
question.

Jari

On 21 Oct 2015, at 19:37, Kent Watsen  wrote:

> 
> Hi Suresh,
> 
> Thank you for your review.
> 
> To answer your question, the server can start the SSH server protocol 
> immediately.  It does not have the wait for the client for anything.  At 
> least, this is how my code works  :)
> 
> Thanks again,
> Kent
> 
> 
> 
> 
> 
> 
> On 10/21/15, 12:10 AM, "Suresh Krishnan"  wrote:
> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> 
>> 
>> Please wait for direction from your document shepherd or AD before
>> posting a new version of the draft.
>> 
>> Document: draft-ietf-netconf-call-home-11.txt
>> Reviewer: Suresh Krishnan
>> Review Date: 2015/10/20
>> IESG Telechat date: 2015/10/22
>> 
>> Summary: The draft is ready for publication as a Proposed Standard but I do
>> have a comment that you may wish to address.
>> 
>> Minor
>> =
>> 
>> * Section 3.1 S3: The server cannot immediately start the SSH server protocol
>> without waiting for SSH connection initiation from the SSH client, right? If
>> yes, shouldn't there be an additional condition here?
>> 
>> Thanks
>> Suresh
>> 
>> 
> ___
> 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] Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06

[Jari Arkko]

Meral, many thanks for the review. Donald, many thanks for the changes.

I have balloted no-obj.

On re: conflicts, I understood the sentence as a usual if-all-else-fails clause 
of specifying which document has precedence in case some conflicts are 
discovered later. I think that’s fine. Is this your understanding too, Donald?

Jari

On 21 Oct 2015, at 17:20, Meral Shirazipour  
wrote:

> Hi Donald,
>  Thank you for considering the changes. Please see in-line for a few more 
> comments.
> 
> Best,
> Meral
> 
>> -Original Message-
>> From: Donald Eastlake [mailto:d3e...@gmail.com]
>> Sent: Wednesday, October 21, 2015 7:54 AM
>> To: Meral Shirazipour
>> Cc: draft-ietf-trill-rfc7180bis@tools.ietf.org; gen-art@ietf.org
>> Subject: Re: Gen-ART Last Call review of draft-ietf-trill-rfc7180bis-06
>> 
>> Hi Meral,
>> 
>> On Mon, Oct 19, 2015 at 8:02 PM, Meral Shirazipour
>>  wrote:
>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>> Gen-ART, please see the FAQ at
>>> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>>> 
>>> 
>>> Please resolve these comments along with any other Last Call comments
>>> you may receive.
>>> 
>>> 
>>> Document: draft-ietf-trill-rfc7180bis-06
>>> Reviewer: Meral Shirazipour (was originally assigned to another
>>> gen-art) Review Date: 2015-10-19 IETF LC End Date:  2015-10-19 IESG
>>> Telechat date: 2015-10-22
>>> 
>>> 
>>> 
>>> Summary:
>>> 
>>> This draft is ready to be published as Standards Track RFC but I have
>>> some comments .
>> 
>> Thanks. See below.
>> 
>>> Major issues:
>>> 
>>> 
>>> Minor issues:
>>> 
>>> -[Page 5], Section 1.1: this section updates section 1.2 of RFC6325.
>>> The update is about conflict resolution between sections of the RFC.
>>> 
>>> Shouldn't this bis highlight those conflicts if any?
>> 
>> I do not believe there are any real conflicts. RFC 6325 has some
>> general/introductory sections and some detailed technical sections.
>> The general sections, particularly Section 2, are written with a pedagogical
>> goal of giving the reader the best general understanding and such general
>> sections are not necessarily precise and do not, in general, include every
>> corner case. During the development of RFC 6325, some reader focused on
>> such general descriptions and claimed that the "conflicted" with the precise,
>> detailed technical sections.
>> Thus Section 1.2 was added to RFC6325 to resolve this and make it clear that
>> the later detailed sections should be followed in case of any such apparent
>> "conflict".
>> 
>> I don't really remember exactly what motivated making the material about
>> precedence of sections in RFC 6325 more complete in RFC 7180 but it was
>> probably based on some comment.
>> 
>> The only change from Section 1.1 of RFC 7180 to this Section 1.1 draft-ietf-
>> trill-rfc7180bis is updating of some other RFC numbers in this section.
>> 
> 
> [MSh] Would it be possible to add a few sentences to clarify that? or maybe 
> remove the word "conflict" ?
> 
> 
>>> -[Page 14], Section 3.4. Should this section have a MUST sentence just
>>> before the last sentence?
>>> 
>>> "All RBridges in a campus MUST determine distribution trees in the
>>> same way "
>> 
>> I don't think so. The mandatory implementation of the distribution tree
>> computation provisions is elsewhere. The sentence you refer to is just
>> discussion of the consequences of failure to follow that.
>> 
>>> -[Page 10], Section 2.4.2.1 , gives an example, then the first bullet
>>> after the figure explains the problem with that scenario and says
>>> "MUST NOT be locally distributed in native form ".
>>> 
>>> Is it possible to clarify what should be done instead?
>> 
>> This section is about tunneling the frame to a neighbor that is offering the
>> OOMF service. It could be re-worded a little to use "instead" rather than
>> "before". The change would be
>> 
>> OLD
>>  The multi-destination frame MUST NOT be locally distributed in
>>  native form at RB2 before tunneling to a neighbor because this
>>  would cause the frame to be delivered twice.
>> 
>> NEW
>>  The multi-destination frame MUST NOT be locally distributed in
>>  native form at RB2 because this
>>  would cause the frame to be delivered twice. Instead it is tunneling to 
>> a
>> neighbor as provided in this section.
>> 
> 
> [MSh] NEW looks good to me. Thanks.
> 
>>> -[Page 11], last line, "forwards the packet on that tree."
>>> 
>>> Just checking if that is supposed to say "packet" or if it should say
>>> "frame" or "TRILL Data packet"?
>> 
>> It would be more consistent to say TRILL Data packet.
>> 
>>> Naming ("frame" or "TRILL Data packet") are used throughout,  but it
>>> would help to mention the convention at the beginning of the draft.
>> 
>> I believe the intent to is use "frame" for native frames to/from end stations
>> and "TRILL Data packet" or "packet" for TRILL encapsulated packets between
>> TRILL switches. This convention could be ment

Re: [Gen-art] Gen-ART Telechat Call review of draft-ietf-pcp-port-set-11

[Jari Arkko]

Thanks again, Meral.

Jari

On 16 Oct 2015, at 00:27, Meral Shirazipour  
wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at < 
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please wait for direction from your document shepherd or AD before posting a 
> new version of the draft.
> 
> Document: draft-ietf-pcp-port-set-11
> Reviewer: Meral Shirazipour
> Review Date: 2015-10-15
> IETF LC End Date: 2015-10-14
> IESG Telechat date: 2015-10-22
> 
> Summary: This draft is ready to be published as Standards Track RFC.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> -Comments from LC review [1] were resolved.
> 
> -AD to decide if additional text is required regarding 'Minor issues' comment 
> and the follow up discussion on the list.
> 
> [1] http://www.ietf.org/mail-archive/web/gen-art/current/msg12363.html
> 
> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson
> Research
> www.ericsson.com
> ___
> 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] Gen-art LC review: draft-ietf-pals-redundancy-spe-02

[Jari Arkko]

Robert, Jimmy,

Thanks for the review & discussion.

From my perspective some of the things that Robert raises are very valid
questions. The particular item that I’m perhaps most interested in is the
text in Section 3.2, which seems like explaining what happens in an example,
but it also uses normative language and keywords to say what various entities
should do. Yet, the example is just one example. Is there a need to lift the
keyword statements out of this paragraph and generalise them to make
sure that the specification is about the general case and not about the
example? Alternatively, maybe I misunderstood the purpose of the keyword
statements.

(I also agree with Robert that the document is fairly hard to read. This isn’t
the first document in the IETF to be like that, and I didn’t feel that this
issue is discuss-worthy.)

Jari



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 LC review: draft-ietf-pals-redundancy-spe-02

[Andrew G. Malis]

Jari,

(I removed some of the the cc:s for this reply).

Thanks, that’s exactly the case, the IPR was announced in November 2012,
prior to the PWE3 WG adoption poll.

I think you just uncovered a tools page bug. Looking at the datatracker,
the replaced-by information is correct through the draft’s lifetime, and
the IPR follows all the way through. However, the tools page only shows the
IPR for draft-dong, and not the subsequent drafts. I seem to recall this
having worked properly in the past, perhaps it’s an unintended side-effect
of the recent datatracker upgrades?

Cheers,
Andy

On Thu, Oct 22, 2015 at 6:15 AM, Jari Arkko  wrote:

> Robert:
>
> Many thanks for your detailed review. I will send some technical comments
> on this
> topic but wanted to answer you and Andrew on the IPR issue separately:
>
> Robert wrote:
>
> > That happens sometimes, but it's much better to have a real indication
> > that the group considered the disclosure and explicitly decided not to
> > change directions.
>
> Andrew wrote:
>
> > The IPR declaration is against the original individual draft,
> draft-dong-pwe3-redundancy-spe. The IPR declaration was from a company that
> was not represented as an author on the draft, and offered free licencing
> with reciprocity.
>
> OK. Interesting background information.
>
> > At the time, no concerns were raised by either the authors or from
> anyone in the WG in response to the declaration. This, IMHO, is normal
> operating procedure when IPR declarations are made, especially by
> non-author entities and early in the process. The usual concern is when
> declarations come in late in the process, especially from an author
> company. Neither was the case here, it was still an individual draft. And
> of course, the declaration was clear for all to see during both WG adoption
> and WG LC polls.
>
> I think this is the key. The standing practice at the IETF is that IPR
> gets declared, timely, and the information is used by the participants when
> they decide things like whether they support document adoption (among many
> other factors). I find that there is often no explicit discussion but those
> that care take the information into account, in careful and competent
> manner and through consultation with their colleagues back home etc.
>
> So, it appears that the right thing happened here, and your answer above
> is the right one for Robert’s question.
>
> However, I have one question, as I started digging… First, this is one of
> those many cases where an individual draft has an IPR declaration and the
> later adoption into a WG draft doesn’t lead to a new declaration. Our tools
> usually track this correctly, as long as the replaced-by information is
> correctly updated. (WG chairs: please check that this happens when you
> adopt documents.)
>
> But in this case I noticed that
> http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows 1
> IPR whereas https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02
> does not. But
> https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 does. What
> gives? Robert, do you know if the tools version does not track through
> replaced-by? Getting such information properly displayed in all cases might
> be important, as many people use the tools server to view drafts.
>
> In any case, my question is, I think, not relevant to the question of
> whether the group properly considered *this* case, because at the time that
> the document was adopted, it was an individual draft and therefore likely
> correctly displayed in all tools. The date of IPR declaration was Nov 2012,
> and the first WG document on this (in PWE3) appeared in December 2012.
>
> Jari
>
> >
> > Thanks,
> > Andy
> >
> >
> > On Fri, Oct 16, 2015 at 11:30 PM, Robert Sparks 
> wrote:
> > 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-redundancy-spe-02
> > Reviewer: Robert Sparks
> > Review Date: 16 Oct 2015
> > IETF LC End Date: 19 Oct 2015
> > IESG Telechat date: 22 Oct 2015
> >
> > Summary: Almost ready for publication as PS but with issues that need to
> be discussed/addressed
> >
> > This document is hard to read. It is more acronym-laden than it
> > needs to be.
> >
> > -
> > There is a process issue that the IESG should pay attention to.
> > The shepherd writeup says this:
> >
> >   "There is one IPR declaration (1911) raised in November 2012 against
> >an early version of the draft.  There was no discussion in the WG
> >related to this."
> >
> > -
> >
> > The last sentence of the 2nd paragraph (declaring multi-homing on both
> > sides of an S-PE out of scope) should be moved earlier in the document.
> 

Re: [Gen-art] Gen-art LC review: draft-ietf-pals-redundancy-spe-02

[Jari Arkko]

Robert:

Many thanks for your detailed review. I will send some technical comments on 
this
topic but wanted to answer you and Andrew on the IPR issue separately:

Robert wrote:

> That happens sometimes, but it's much better to have a real indication
> that the group considered the disclosure and explicitly decided not to
> change directions.

Andrew wrote:

> The IPR declaration is against the original individual draft, 
> draft-dong-pwe3-redundancy-spe. The IPR declaration was from a company that 
> was not represented as an author on the draft, and offered free licencing 
> with reciprocity.

OK. Interesting background information.

> At the time, no concerns were raised by either the authors or from anyone in 
> the WG in response to the declaration. This, IMHO, is normal operating 
> procedure when IPR declarations are made, especially by non-author entities 
> and early in the process. The usual concern is when declarations come in late 
> in the process, especially from an author company. Neither was the case here, 
> it was still an individual draft. And of course, the declaration was clear 
> for all to see during both WG adoption and WG LC polls.

I think this is the key. The standing practice at the IETF is that IPR gets 
declared, timely, and the information is used by the participants when they 
decide things like whether they support document adoption (among many other 
factors). I find that there is often no explicit discussion but those that care 
take the information into account, in careful and competent manner and through 
consultation with their colleagues back home etc.

So, it appears that the right thing happened here, and your answer above is the 
right one for Robert’s question.

However, I have one question, as I started digging… First, this is one of those 
many cases where an individual draft has an IPR declaration and the later 
adoption into a WG draft doesn’t lead to a new declaration. Our tools usually 
track this correctly, as long as the replaced-by information is correctly 
updated. (WG chairs: please check that this happens when you adopt documents.)

But in this case I noticed that 
http://datatracker.ietf.org/doc/draft-ietf-pals-redundancy-spe/ shows 1 IPR 
whereas https://tools.ietf.org/html/draft-ietf-pals-redundancy-spe-02 does not. 
But https://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-04 does. What 
gives? Robert, do you know if the tools version does not track through 
replaced-by? Getting such information properly displayed in all cases might be 
important, as many people use the tools server to view drafts.

In any case, my question is, I think, not relevant to the question of whether 
the group properly considered *this* case, because at the time that the 
document was adopted, it was an individual draft and therefore likely correctly 
displayed in all tools. The date of IPR declaration was Nov 2012, and the first 
WG document on this (in PWE3) appeared in December 2012.

Jari

> 
> Thanks,
> Andy
> 
> 
> On Fri, Oct 16, 2015 at 11:30 PM, Robert Sparks  wrote:
> 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-redundancy-spe-02
> Reviewer: Robert Sparks
> Review Date: 16 Oct 2015
> IETF LC End Date: 19 Oct 2015
> IESG Telechat date: 22 Oct 2015
> 
> Summary: Almost ready for publication as PS but with issues that need to be 
> discussed/addressed
> 
> This document is hard to read. It is more acronym-laden than it
> needs to be.
> 
> -
> There is a process issue that the IESG should pay attention to.
> The shepherd writeup says this:
> 
>   "There is one IPR declaration (1911) raised in November 2012 against
>an early version of the draft.  There was no discussion in the WG
>related to this."
> 
> -
> 
> The last sentence of the 2nd paragraph (declaring multi-homing on both
> sides of an S-PE out of scope) should be moved earlier in the document.
> The introduction and perhaps even the abstract can be clearer about
> what _is_ in scope.
> 
> It needs to be clearer where the normative description of behavior is.
> I think you're intending it to be the first part of section 3. I have
> not worked through the references enough to ensure that it is complete.
> 
> The third paragraph starts off "In general, ...". Are there any
> specific cases where the requirements that follow do not hold? If so,
> there needs to be more description. If not, please delete "In general,".
> 
> Are sections 3.1 and 3.2 supposed to be only examples? Would the
> specification of the protocol be complete if they were deleted? If not,
> something needs to be moved up into the main part of section 3.
> For instance, is the SHOULD at t

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

[Jari Arkko]

Ralph, many thanks for your in-depth review! And thanks for being on the 
Gen-ART team. And than you Himanshu for suggesting ways to deal with the issues.

I agree with Ralph that there are points where this document could be clearer. 
The one case that I felt personally strongly about was the part about what 
number the sequence numbers must start from. The text makes the reader wonder 
if one should read it literally, or if the starting number is handled 
differently. It would be better to be explicit.

I have balloted no-obj for this document, but would very much like to see the 
discussion with Ralph continue and some changes based on the comments adopted.

Jari



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 LC/Telechat review of draft-ietf-pals-ms-pw-protection-03

[Jari Arkko]

Thanks for your review, Peter.

Jari



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 Telechat Call review of draft-ietf-homenet-dncp-11

[Jari Arkko]

Thanks again, Meral.

jari

On 17 Oct 2015, at 00:10, Meral Shirazipour  
wrote:

> 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 wait for direction from your document shepherd or AD before posting a 
> new version of the draft.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-homenet-dncp-11
> Reviewer: Meral Shirazipour
> Review Date: 2015-10-16
> IETF LC End Date: 2015-07-29
> IESG Telechat date: 2015-10-22
> 
> Summary: This draft is ready to be published as Standards Track RFC.
> *Note: this draft was extensively discussed on the list 
> https://mailarchive.ietf.org/arch/search/?q=draft-ietf-homenet-dncp  since 
> the last call review.
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> Best Regards,
> Meral
> ---
> Meral Shirazipour
> Ericsson
> Research
> www.ericsson.com
> ___
> 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] review: draft-housley-sow-author-statistics-00

[Jari Arkko]

Thanks for your review, Joel. And thanks Russ for the added text.

jari

On 27 Aug 2015, at 22:53, Joel M. Halpern  wrote:

> 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-housley-sow-author-statistics-00
> Statement of Work for Extensions to the IETF Datatracker for
>  Author Statistics
> Reviewer: Joel M. Halpern
> Review Date: 27-August-2015
> IETF LC End Date: 23-September-2015
> IESG Telechat date: N/A
> 
> Summary: This document is ready for publication as an Informational RFC
> 
> Major issues: N/A
> 
> Minor issues:
>   There are a few references in this document to the format evolution.  It 
> seems that either this document should provide for additional work as those 
> changes occur, or should indicate that such further work will be dealt with 
> separately at the appropriate time.
> 
> Nits/editorial comments:
>   I wonder if this document could or should identify additional metadata 
> items that the new formats could provide to make these statistics more 
> reliable.
> 
> ___
> 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] Gen-ART review of draft-ietf-ppsp-base-tracker-protocol-10

[Huangyihong (Rachel)]

Hi Vijay,

Thank you for the review. Please see our replies inline starting with [Rachel]. 

BR,
Rachel

> 
> Document: draft-ietf-ppsp-base-tracker-protocol-10
> Reviewer: Vijay K. Gurbani
> Review Date: Oct-15-2015
> IETF LC End Date: Not known
> IESG Telechat date: Oct-15-2015
> 
> This document is ready as a Proposed Standard, however, it does have some
> minor comments and nits that I detail below.
> 
> Major: 0
> Minor: 3
> Nits:  9
> 
> Minor:
> - Generally speaking, I think one more round of edits for grammar and
>clarity may not be a bad thing.

[Rachel]: Will do.

> 
> - S2, "The PPSP Tracker Protocol architecture is intended to be
>compatible with the web infrastructure."  What is the "web
>infrastructure"?  How is it defined?  What does it mean to be
>compatible with it?  Perhaps you meant that the PPSP TP is a request-
>response protocol, which characterizes many "web protocols"?

[Rachel]: Right. Will fix it.

> 
> - S3.2.5, Table 4: "available_bandwidth  | Upstream Bandwidth
>available" is this provisioned upload bandwidth or instantaneous
>upload bandwidth?

[Rachel]: It's available instantaneous upload bandwidth. Will add some 
clarifications.

> 
> Nits:
> 
> - General comment: too much use of gratuitous capitalization (Request
>message, Tracker, Peer etc.)

[Rachel]: Will fix it in the next version.

> 
> - S1.1, CHUNK is better defined as "An uniformly sized atomic subset of
>   the resource that constitutes the basic unit of data organized in P2P
>   ..."

[Rachel]: As for the terminologies. I think it's better to reference RFC6972. 
So maybe just delete those already defined in [RFC6972] and keep those new ones.

> 
> - S1.1, For uniformity when defining terms, you may want to think of
>   starting the definition of live streaming as "LIVE STREAMING: Refers to
>   ..."

[Rachel]: Ok.

> 
> - S1.1: The taxonomy of a peer into a leecher or a seeder appears to be
>absolute.  In real swarms (BitTorrent), a peer trades chunks with
>other peers, so it is a leecher but also a provider for certain
>chunks.  This eventuality is not considered here.
> 
> - S1.2.1, what is the implication of the prefix "[Peer Protocol]" in the
>numbered steps shown?  Is it a reference (using syntax like we use for
>references), or is it implying that the protocol used by a peer in
>these steps is the peer protocol?  If so, why not put the RFC/I-D
>number of the peer protocol there?

[Rachel]: Sorry, it should be [RFC7574].

> 
> - S1.2.2, s/Once CONNECTed/Once connected/
> 
> - S2.2, what is an "action signal"?  Perhaps easier to simply say that
>"This Request message is used when ..."  Same with "information
>signal".
> 
> - S2.3.1, s/register on a tracker/register with a tracker/

[Rachel]: Accepted. Will fix them in the next version.

> 
> - S3.1, "turning the definitions for JSON objects extensible."  I cannot
>quite parse that.  Sorry.

[Rachel]: This sentence should be deleted.

> 
> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art