Hi,
Thank you for your review. Comments inline.
"Roni Even" <ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com> wrote:
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-netmod-interfaces-cfg-10
Reviewer: Roni Even
Review Date:2013-4-28
IETF LC End Date: 2013-5-3
IESG Telechat date: 2013-5-16
Summary: This draft is almost ready for publication as Standard track RFC.
Major issues:
Minor issues:
1. I had some problem understanding the "location" leaf. Section 3.2
has it as a string and says that "The device uses the location string to
identify the physical or logical entity that the configuration applies to".
I am not sure how you identify physical location having no definition of the
mapping.
The sentence just before the quoted one above says:
"The format of this string is device- and type-dependent."
and then the text says:
"How a client can learn which types and locations are present on a
certain device is outside the scope of this document."
So the exact procedure is currently left to the vendors, but may be
standardized in a future document (if possible...)
I saw the examples in Appendix E and it looked more to me as
logical mapping but not physical since it attaches a name to something in
the device but I am not clear how you know what it is physically in the
device. If the name 0-n or n/m are real physical entities, I think that it
should be specified some place.
Nits/editorial comments:
1. In the introduction section maybe add to the first sentence a
reference to RFC6244 with some text.
Ok, this probably makes sense. I will check w/ the WG and other
documents.
2. In section 2 are the" must" and "should" used as described in
RFC2119, if yes need capital letters
Seciton 2 is more of a background, non-normative section. It lists
some of the design objectives.
3. In section 3.1 "It is optional in the data model, but if the type
represents a physical interface, it is mandatory", suggest having RFC2119
language "It is OPTIONAL in the data model, but if the type represents a
physical interface, it is MUST be specified"
I think the first one should not be OPTIONAL, but the second one is
correct. So I suggest this:
It is defined as being optional in the data model, but if the type
represents a physical interface, it MUST be specified.
/martin