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. Document reviewed:  draft-ietf-roll-routing-dispatch-01 Status: Ready with issues Disclaimer: I am not a IPv6 expert specially as it relates to 6Lo and while reading the document gave me some idea of what was being suggested, some subtleties were probably lost on me.  Summary: This document defines introduces a new 6LoWPAN dispatch type for use in 6LoWPAN topologies. Using this dispatch type, the specification defines a method to compress RPL Options information and Routing Header type 3. Management considerations: The draft clearly outlines management considerations (the first time I have seen one :-)). It states clearly that the solution cannot be deployed in a non-homogenous environment, where there is a mixture of routers that have the compressed and uncompressed headers.  Most operators are going to find this difficult to deploy, unless it is a green field opportunity. Have the authors considered giving implementors an option of detecting the new header format and letting them decide if they want to provide a solution where these routers can exist in a non-homogenous manner? Fault management: The draft talks about what happens when a intermediate router is not able to recognize the new routing header 6LoRH and drops the packet. What is the implication? Does it retry with an alternate path? Do the end points fall back to using the LOWPAN_IPHC? I understand that the draft considers this an administrative error, but unless there is a deterministic way of determining fault (see next section), I can imagine the operators having a very hard time determining why things are not working as expected. Fault determination: The document states that if a mismatch is detected, that it is expected the device raises a management alert. But it does not describe what that management alert should be. In the interest of providing consistency, the draft should talk about the alert, what it should be, and how it will be reported. For example, the node that will detect the mismatch is going to be the receiver. Therefore the receiver should report what it was expecting, e.g. compressed header, but it got uncompressed header, or something similar. It will allow an operator to detect not only where the fault is, but what it is. The document states that it does not require “extraneous code” to exchange and handle error messages for mismatch situations, but does it mean there is error handling code for other situations. Also how are operators are expected to detect a mismatch? Configuration management: The draft needs to talk about how individual devices will be configured and monitored for this proposal. Verifying correct operation: How is it determined that the device is operating correctly when configured? A run of idnits revealed one issue that might need to be addressed:     Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:   ----------------------------------------------------------------------------   == It seems as if not all pages are separated by form feeds - found 33 form      feeds but 37 pages  Checking references for intended status: Proposed Standard   ----------------------------------------------------------------------------      (See RFCs 3967 and 4897 for information about using normative references      to lower-maturity documents in RFCs)   == Missing Reference: 'RFCthis' is mentioned on line 1170, but not defined   == Outdated reference: A later version (-05) exists of      draft-ietf-6lo-paging-dispatch-04   -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802154'   == Outdated reference: A later version (-09) exists of      draft-ietf-roll-useofrplinfo-08 Thanks. Mahesh Jethanandani mjethanandani at gmail.com