Did anyone do a Telechat review of this document? It is now at version -07.
Russ
At 01:38 PM 3/13/2009, Robert Sparks wrote:
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.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
