Thanks your review, Dan. Thank you authors for addressing the concerns (in a new version, once it appears :-)
Jari On Feb 19, 2014, at 10:33 PM, Andrew G. Malis <[email protected]> wrote: > Samer, > > Thanks for responding to Dan. > > The timing for a new revision is up to Stewart - don't take any action > until you hear from him. > > Cheers, > Andy > > On Wed, Feb 19, 2014 at 1:30 PM, Samer Salam (ssalam) <[email protected]> > wrote: >> Hi Dan, >> >> Thank you for your review. Please find responses inlineĊ >> >> Hi Andy, >> >> Please let us know when we can go ahead an update the draft to address the >> review comments. >> >> >> Regards, >> Samer >> >> On 2014-02-19 6:31 AM, "Andrew G. Malis" <[email protected]> wrote: >> >>> Dan, >>> >>> Thanks for the review (twice!). >>> >>> Authors, >>> >>> Could you please respond to Dan's review and comments? >>> >>> Thanks, >>> Andy >>> >>> >>> On Wed, Feb 19, 2014 at 3:23 AM, Romascanu, Dan (Dan) >>> <[email protected]> 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-pwe3-iccp-13.txt >>>> >>>> Reviewer: Dan Romascanu >>>> >>>> Review Date: 2/19/14 >>>> >>>> IETF LC End Date: 2/11/14 >>>> >>>> IESG Telechat date: 2/20/14 >>>> >>>> >>>> >>>> Summary: >>>> >>>> >>>> >>>> Ready with issues. I did not see any answer from the editors or >>>> shepherd to >>>> the issues raised in the IETFLC Gen-ART review and there was no >>>> revision of >>>> the document since then. Although none of the issues raised seems to be >>>> blocking, I believed that they should be considered and answered as >>>> part of >>>> the IETF Last Call Comments. >>>> >>>> >>>> >>>> This is a complex but well written document. It is ready, a number of >>>> minor >>>> issues need clarification and possibly editing. Some nits also may be >>>> considered to fix >>>> >>>> >>>> >>>> Major issues: >>>> >>>> >>>> >>>> None >>>> >>>> >>>> >>>> Minor issues: >>>> >>>> >>>> >>>> 1. The document (and the name of the protocol defined here) uses >>>> the >>>> notion of 'chassis'. However there is no definition or reference to a >>>> definition that would clarify what a 'chassis' is. >> >> Good point, will add a definition to that effect. >> >>>> >>>> 2. In section 7.2.2.1 - I am not a fan of transferring >>>> information in >>>> text format like in the Disconnect Cause String - no interoperability >>>> results if there no agreement on a finite set of causes. Anyway - should >>>> this not be UTF-8 format? >> >> This is meant to relay information to a human user, and not intended to be >> used to take any automated actions. Will clarify that it is UTF-8. >> >>>> >>>> 3. Similar question in Section 7.2.4 - why is Aggregator Name a >>>> text? >>>> Why not using AggregatorID as per IEEE 802.1AX? >> >> The AggregatorID is already part of the TLV. The name is to enhance human >> usability, same reason as above. >> >>>> >>>> 4. In Section 7.2.5 - if Port Speed corresponds to the ifHighSpeed >>>> object in the IF-MIB, should not also Port (interface) name correspond >>>> to >>>> ifName truncated to 20 characters whenever possible? >>>> >> >> Agreed, will update accordingly. >> >>>> >>>> >>>> >>>> >>>> Nits/editorial comments: >>>> >>>> >>>> >>>> 1. Some acronyms need expansion at the first occurrence - e.g. >>>> POP, CO >> >> Will update the draft accordingly. >> >>>> >>>> 2. In section 3.3/i: PE nodes MAY be collocated or remote - this >>>> MAY >>>> needs not be capitalized. >> >> Will fix. >> >>>> >>>> 3. The first two lines in the diagram in page 16 are mis-aligned >> >> Will fix. >> >>>> >>>> 4. The diagrams in 7.1.1., 7.1.5 end at 16-bit boundary with the >>>> last field defined for optional sub-TLVs. Is this intentional? Do they >>>> suggest that the number of octets is always 4*n + 2? What happens else? >> >> No that was not intentional. Will add text to clarify that there are no >> such assumptions. >> >>>> >>>> 5. In section 7.3.1:' -ii. PW ID TLV or generalized PW ID TLV' I >>>> think >>>> what is meant is actually ' -ii. One of PW ID TLV or generalized PW ID >>>> TLV' >> >> Will update. >> >>>> >>>> >>>> >>>> >> > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
