A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network
draft-ietf-roll-p2p-measurement-10

This is a nice, clear document, which was easy to review.  I have just two very minor points, of the extreme-NON-blocking variety:

-- Section 1 --
   Note that it is important that the routing constraints
   are not overly strict; otherwise the P2P-RPL route discovery may fail
   even though a route, much better than the one currently being used,
   exists.

The commas setting off that last phrase make it non-restrictive (it could be removed without changing the meaning of the sentence), and that's not what you want.  So (adding a change to subjunctive mood along the way)...

NEW1
   Note that it is important that the routing constraints
   not be overly strict; otherwise, the P2P-RPL route discovery may fail
   even though a route much better than the one currently being used
   exists.

...or...

NEW2
   Note that it is important that the routing constraints
   not be overly strict; otherwise, the P2P-RPL route discovery may fail
   even though a route exists that is much better than the one currently
   being used.

-- Section 6.1 --
   The remaining fields inside a Measurement Reply may have
   any value and MUST be ignored on reception at the Start Point.  The
   received Measurement Request MAY trivially be converted into a
   Measurement Reply by setting the Type (T) flag to zero.

It's really a small point, but this doesn't feel like the right use of 2119 "MAY", because it simply follows from the rest of the paragraph, and the protocol only cares about what the Measurement Reply looks like, not how you went about creating it.  I suggest this slight change:

NEW
   The remaining fields inside a Measurement Reply may have
   any value and MUST be ignored on reception at the Start Point; the
   received Measurement Request can, therefore, trivially be converted
   into a Measurement Reply by setting the Type (T) flag to zero.
END

I support the publication of this document modulo the changes resulting from Sean's points.

3.1, Accumulate Route:

      Route accumulation is allowed (i.e., this flag MAY be set to one)
      inside a Measurement Request only if it travels along a Hop-by-hop
      Route represented by a local RPLInstanceID (i.e., H = 1,
      RPLInstanceID has a local value).

I think you buried the lede here. I suggest instead:

      Route accumulation MUST NOT be used (i.e., this flag set to one)
      inside a Measurement Request unless it travels along a Hop-by-hop
      Route represented by a local RPLInstanceID (i.e., H = 1,
      RPLInstanceID has a local value).

That MAY could cause a reader to miss the important point that this is a requirement, even though this is followed with "In other cases, this flag MUST be set to zero".

Very well-written and easy to understand document.  Thank you.

I have only a few minor comments for your consideration.

1. In this text:

   Such a route could be a Source
   Route [I-D.ietf-roll-p2p-rpl] or a Hop-by-hop Route
   [I-D.ietf-roll-p2p-rpl] established using RPL [RFC6550] or P2P-RPL
   [I-D.ietf-roll-p2p-rpl]

I found the first two citations of [I-D.ietf-roll-p2p-rpl] a little
confusing.  The use of terminology from [I-D.ietf-roll-p2p-rpl] was
already mentioned; no need to cite the sources of those terms here.

2. Are there any restrictions on the addresses (link-local, global
scope, etc.) in the address list, used either for source-routing or
accumulating a route?

4. Are there rules about what address a node should insert in the
address list - for example, link-local if possible, MUST match End
Point address prefix as specified by Compr?

5. Is the RPLInstanceID value 0b10000000 now reserved in some way?
Section 4.4 call for the RPLInstanceID to be set to 0b10000000, but I
don't see any requirement to check that value in a received MO.

  The Gen-ART Review by Pete McCann on 5-Feb-2013 raises one concern
  about clarity.  In Section 5, it says:
  >
  > An Intermediate Point MUST discard the packet with no further
  > processing if the received MO is not a Measurement Request (i.e.,
  > T = 0).
  >
  The Intermediate Points are the routers on the route that are being
  measured, excluding the Start Point and the End Point.  Section 6.1
  identifies situations where the Measurement Reply _may_ travel back
  to the Start Point using the reverse of the measured route. So, it is
  possible that the Measurement Reply travels along the reverse of the
  measured path and, in this case, the Measurement Reply does pass
  through all the Intermediate Points. However, the End Point may decide
  to send the Measurement Reply along a different path than the measured
  one. In that case, the Measurement Reply may not pass through the
  Intermediate Points.

  It would be helpful to share this information with the reader in
  Section 5, instead of waiting for Section 6.1.

Thank you for addressing my concerns.

Thanks for addressing my discuss. On the basis that this is an
experimental-track specification and you're depending on the
security from 6550, your changes are enough to clear my
discuss. I'd be really interested in knowing how this goes, 
when people implement/deploy, given that you need all 
routers to share the same key.

Two other comments, 

- its not clear to me if there are cases where a router will 
pass on a "secure MO" without changing the message,
 but where the router doesn't have the key required. It'd 
be good to say if a router needs to drop the message in 
that case or not.

- I'm also unclear about that the starting point has to 
do if a "secure MO" it sent out gets dropped and the 
starting point never hears anything back.

Both of the above may be clear in the document already
(apologies if so) but I didn't immediately see what's 
supposed to happen.