Last Call Review of draft-ietf-opsawg-automated-network-configuration-
review-ietf-opsawg-automated-network-configuration-genart-lc-gurbani-2012-08-15-00
Request | Review of | draft-ietf-opsawg-automated-network-configuration |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2012-08-15 | |
Requested | 2012-07-26 | |
Authors | Tina Tsou (Ting ZOU) , Jürgen Schönwälder , Yang Shi , Tom Taylor , GuoLiang Yang | |
I-D last updated | 2012-08-15 | |
Completed reviews |
Genart Last Call review of -??
by Vijay K. Gurbani
Secdir Last Call review of -?? by Rob Austein |
|
Assignment | Reviewer | Vijay K. Gurbani |
State | Completed | |
Request | Last Call review on draft-ietf-opsawg-automated-network-configuration by General Area Review Team (Gen-ART) Assigned | |
Result | Ready w/issues | |
Completed | 2012-08-15 |
review-ietf-opsawg-automated-network-configuration-genart-lc-gurbani-2012-08-15-00
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-opsawg-automated-network-configuration-04 Reviewer: Vijay K. Gurbani Review Date: Aug-13-2012 IETF LC End Date: Aug-15-2012 IESG Telechat date: Aug-16-2012 This draft is on the right track but has open issues, described in the review. Major: 0 Minor: 5 Nits: 4 Minor: 1/ S1, paragraph 2: The use of the phrase "...how to implement things properly," is too colloquial for a standards document (even though the draft is targeted as an Informational). I would suggest to rewrite the phrase with more information on what these "things" are. 2/ S1, similar comment for issue (b), it is too colloquial. I would suggest rewording to something like the following: "network equipment vendors introducing who would like to ensure a smooth delivery of many devices with new features" 3/ S1, paragraph 4 --- I suspect that simply expanding eNodeB to "Evolved Node B" and referencing the appropriate standard body's document describing the role of eNodeB should suffice. 4/ S3, second paragraph: "let us agree" is, again, more colloquial than standards-oriented prose. Maybe a good thing to do would be to define "configuration data", "configuration server", "joining device" and others in a terminology section (either as a subsection in S3 or as a section of its own). You already have a good collection of such terminology definitions at the beginning of S3. 5/ S5.4, page 12, while discussing lack of URNs for SAN to carry a MAC: one way to carry a MAC in SAN is to use the otherName field as discussed in rfc5280. S4.2.1.6. I suspect that you have evaluated this option but decided against it. If so, it will be good to list it as an indication of the reasons why you do not think this option will work. Nits: 1/ S1, s/nodes, in a Wi-Fi rather/nodes in a Wi-Fi rather/ 2/ S3, in "Pre-configuration": I suspect that the "certificate" mentioned there pertains to an X.509 certificate. If so, please make it apparent. 3/ S5.1: s/non-IETF protocols only./non-IETF protocols./ 4/ S5.4: s/identity built in/identity/ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg at {bell-labs.com,acm.org} / vijay.gurbani at alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/