I re-assigned that document to Francis for the telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-090924.html
But, I've not yet seen a review. Mary. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Russ Housley Sent: Tuesday, September 22, 2009 10:46 AM To: [email protected] Subject: Re: [Gen-art] Genart LC review : draft-ietf-roll-building-routing-reqs-05 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 >[email protected] >https://www.ietf.org/mailman/listinfo/gen-art > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
