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
