Hi Peter, Thanks for your thorough review. See below.
On Sat, Jul 2, 2016 at 2:33 AM, Peter Yee <pe...@akayla.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 > comment. For background on Gen-ART, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> > > Document: draft-ietf-trill-channel-tunnel-09 > Reviewer: Peter Yee > Review Date: July 1, 2016 > IETF LC End Date: July 1, 2016 > IESG Telechat date: July 7, 2016 > > Summary: This draft is basically ready for publication as a Proposed > Standard, but has some nits that should be fixed before publication. [Ready > with nits] > > This draft extends TRILL RBridge Channels so that they can transmit > additional, tunneled message types. Security services for RBridge Channel > messages can be provisioned via RFC 5310 authentication and/or DTLS. The > draft is well-written and easy to understand in the larger TRILL context. > > Major issues: None > > Minor issues: None > > Nits: > > General: > > For cases of "[RFC5310] Based authentication" to "[RFC5310]-based > authentication". Watch for one instance of "RFC 5310 Based" as well. OK. (Nit-Nit: I think in the nit above, the first word should be Four.) > Specific: All of the following are OK unless noted otherwise right after that nit: > Page 3, Section 1, 1st paragraph, last sentence: delete the comma following > "link". > > Page 4, "HKDF" definition: Change "Hash based" to "HMAC-based". > > Page 4, "MTU" definition: add a period at the end of the definition for > consistency. > > Page 4, "Sz" definition: change "Campus wide" to "Campus-wide". > > Page 6, 1st full paragraph, 1st sentence: suggest changing "RBridge Channel > Extension Protocol" to "Extended RBridge Channel Protocol" as this is the > usage throughout the rest of the document. > > Page 8, Section 3.1, 3rd sentence: insert "tunneled" before "data". I hope > this will help clarity when referring back to Figure 2.4 which includes > "Tunneled Data". > > Page 8, Section 3.2, 1st sentence: append "(tunneled data)" after "payload". > This is done for the same reason, although I'm not recommending doing this > for all further occurrences of "payload" in other sections as I hope the > connection is made by that point. > > Page 12, 1st paragraph, 1st sentence: change "link local" to "link-local". > > Page 12, 1st paragraph, 2nd sentence: change "These constructed addresses" > to "A constructed address". Humm. I don't really like your suggested change. How about I change it to "Such a constructed address ..." > Page 14, Section 4, 2nd paragraph, 1st sentence: change "use" to "used". > > Page 14, Section 4, 3rd paragraph, 1st sentence: change "DTLS based" to > "DTLS-based". > > Page 14, Section 4, 4th paragraph, 2nd sentence: change "data accessible" to > "data-accessible". > > Page 15, 1st partial paragraph, last sentence: insert "the" before > "output-derived". > > Page 16, 1st bullet item: change "or" to "on". > > Page 17, 1st paragraph: delete the comma after "keying". > > Page 18, 2nd full paragraph, last sentence: change "secuirty" to "security". > > Page 20, Section 6.2, 1st paragraph: change "a" to "an". > > Page 21, Section 7, 3rd paragraph, 2nd sentence: delete "processing of". Or > change "processing" to "process". Instead, change the immediately following "decapsulating" to "decapsulated". Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
