Early Review of draft-ietf-trill-channel-tunnel-07

Request Review of draft-ietf-trill-channel-tunnel
Requested rev. no specific revision (document currently at 11)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2016-07-21
Requested 2015-09-02
Authors Donald Eastlake, Mohammed Umair, Yizhou Li
Draft last updated 2015-09-17
Completed reviews Genart Last Call review of -09 by Peter Yee (diff)
Genart Last Call review of -09 by Peter Yee (diff)
Genart Last Call review of -10 by Peter Yee (diff)
Secdir Early review of -07 by Yaron Sheffer (diff)
Secdir Last Call review of -09 by Yaron Sheffer (diff)
Opsdir Early review of -07 by Ron Bonica (diff)
Rtgdir Early review of -07 by Jonathan Hardwick (diff)
Assignment Reviewer Ron Bonica 
State Completed
Review review-ietf-trill-channel-tunnel-07-opsdir-early-bonica-2015-09-17
Reviewed rev. 07 (document currently at 11)
Review result Has Issues
Review completed: 2015-09-17



I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the 
IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: Almost ready for publication

Major issues:

- Figure 2.4 is confusing. In the RBridge Channel Header, you rename the Channel Protocol to " Tunnel Protocol =TBD". A better way to get the idea across would be to omit the RBridge Channel Header from Figure 2.4. (It is already in 2.3). Alternatively, it text between 2.3 and 2.4, say that IANA has allocated Channel Protocol (TBD) to represent Tunnel Protocol.

- Section 3.2.1 is confusing. It says " A typical reason for sending an RBridge Channel message inside a Channel Tunnel message is to provide security services, such as authentication or encryption." Figure 3.1 shows what the Tunneled RBridge Channel Message Structure would look like in this case. Are there other motivations? When sent for another reason, might the packet look different?

- This draft was a three-pass read. I think that the problem is that you don't explain the motivation for the new protocol machinery. You let the reader learn the protocol machinery and then go back to infer the motivation

Minor issues:


- The nit check complains about downrefs

Ron Bonica