Hi, Thank you for your review. Comments inline. "Roni Even" <ron.even.tlv@xxxxxxxxx> 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