Thanks for the review, Paul. I expect to see a document change to address the issues.
Jari On 01 Nov 2016, at 15:44, Carlos Pignataro (cpignata) <cpign...@cisco.com> wrote: > Thanks for the review, Paul! > > Authors, > > Please find some comments inline. > > Carlos, as shepherd. > >> On Oct 31, 2016, at 10:20 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Document: draft-ietf-l2tpext-keyed-ipv6-tunnel-07 >> Reviewer: Paul Kyzivat >> Review Date: 2016-10-26 >> IETF LC End Date: 2016-10-28 >> IESG Telechat date: 2016-11-03 >> >> Summary: >> >> This draft is on the right track but has open issues, described in the >> review. >> >> (Note: The draft is unchanged since Last Call, as is this review.) >> >> Issues: >> >> Major: 0 >> Minor: 3 >> Nits: 0 >> >> (1) MINOR: General comment >> >> As best I can understand, this draft provides a new alternative approach >> tunneling Ethernet over IPv6, that differs from L2TPv3 over IP in two key >> ways: >> >> - it uniquely associates a tunnel with an IPv6 address, simplifying routing >> of arriving packets >> >> - it does not use the L2TPv3 control plane, instead relying upon coordinated >> consistent configuration of the two ends of the tunnel. >> >> As best I can tell, these two choices are independent of one another. >> >> IMO this draft would be improved with a substantial discussion of why this >> new approach to tunneling, using these two features, is being offered as an >> alternative. This is mentioned very slightly in Section 1, but seems >> incomplete. What are the cons as well as the pros, and under what >> circumstances will the pros outweigh the cons? >> > > I agree with this. Some text explaining when you would prefer this approach, > and when not, would help. > >> (2) MINOR: Section 3: >> >> There is no explanation of why 64-bit cookies are chosen and required. Is >> this because there is no mechanism for negotiation, so a fixed size is >> needed to define the packet format? Since coordinated configuration of the >> two ends is required wouldn't it be possible to allow the consistent >> configuration of the cookie size? Better explanation would be helpful. >> > > This is related to Mirja’s comment as well, and some clarity will improve the > doc. > >> (3) MINOR: Section 5: >> >> The 2nd paragraph uses "recommended" (non-normative) while the subsequent >> paragraphs used "RECOMMENDED" (normative). Is this intentional? > > Thanks, > > — Carlos. > _______________________________________________ > 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
