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