Document: draft-ietf-roll-building-routing-reqs-05 Reviewer: Robert Sparks Review Date: 13Mar09 IETF LC End Date: 5Mar09 IESG Telechat date: (if known) Summary: Assuming this draft is intended to inform the protocol development work the ROLL group is rechartering to take on, it has some significant issues you should consider addressing before publishing. This is my primary concern and suggestion: There is a lot of interesting background information in the draft, but its presented such that it is very (almost completely) unclear what is background and what the requirements for the protocol to be developed really are. Restructuring this into an informative "Motivations and Background" section (or separate draft) and a much more concise "Requirements for a Protocol" section would result in a much more useful tool for the next step of work. While evaluating that suggestion, please consider: The document has a very inconsistent use of 2119 language (MUST,etc.), including instances of lower-case versions of the words where the context implies it is trying to place a requirement on the protocol, and use of the upper-case versions where it is placing requirements on aspects of the application other than the protocol being discussed. There are a few design decisions being stated as requirements (example: requiring that devices MUST have a minimal link on time when the requirement is that the protocol not make battery saving behavior impossible. Second example: text around network-wide and application keys affecting packet encryption). The document uses the termsĀ "Zero-Configuration" and "Plug-and-Play for a generic requirement against manual configuration when adding elements. Those terms have meaning beyond what the document intends. The document requires that the protocol be allowed to run with "security". The protocol being considered involves devices connected to the Internet as a whole, and these words should be more carefully considered - the real requirement (at least one that I can infer from the text) is that the protocol support diagnostic configurations. There are several sections of text that should acknowledge they are very US-centric or be adjusted to be less so. Many of the requirements that will affect the protocol design are very unclear - for example, are the requirements in section 5.3.1 currently say that devices SHOULD re-establish communication to lots of things, while I suspect it's trying to say that if the device is going to re- establish communication it SHOULD be able to do so within this timeperiod.