Early Review of draft-ietf-trill-channel-tunnel-07
review-ietf-trill-channel-tunnel-07-opsdir-early-bonica-2015-09-17-00

Folks,

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:

Nits:

- The nit check complains about downrefs

Ron Bonica