A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network
RFC 6998
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Adrian Farrel; former steering group member) Yes
(Barry Leiba; former steering group member) No Objection
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
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
I support the publication of this document modulo the changes resulting from Sean's points.
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
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".
(Ralph Droms; former steering group member) No Objection
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.
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
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.
(Sean Turner; former steering group member) (was Discuss) No Objection
Thank you for addressing my concerns.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
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.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection