Re: [Gen-art] Gen-ART LC review of draft-ietf-trill-channel-tunnel-09

[Donald Eastlake <[e-mail]>]

Hi Peter,

Thanks for your thorough review. See below.

On Sat, Jul 2, 2016 at 2:33 AM, Peter Yee <[e-mail]> 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   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]