Subject: [Gen-art] Genart LC review : draft-ietf-roll-building-routing-reqs-05

From: Robert Sparks <[email-masked]>
Date: Fri, 13 Mar 2009 12:38:41 -0500

Apologies that this is late.

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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 "no  
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.