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/