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@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
