Skip to main content

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/