Hi, "Roni Even" <ron.even.tlv@xxxxxxxxx> wrote: > Martin, > Thanks for the response. I am OK with your responses to the nits. > > As for the comment on location I think I understand but what got me thinking > was the examples. > In E.1 > > "An operator can configure a new interface by sending an <edit-config> > containing: > > <interface nc:operation="create"> > <name>fastethernet-1/0</name> > </interface> > > When the server processes this request, it will set the leaf "type" > to "ethernetCsmacd" and "location" to "1/0". Thus, if the client > performs a <get-config> right after the <edit-config> above, it will > get: > > <interface> > <name>fastethernet-1/0</name> > <type>ethernetCsmacd</type> > <location>1/0</location> > </interface>" > > I can see how the linkage between the location and name is done. I am not > sure how the operator knows from the response what is the physical location > without knowing the device type and manufacturer but at least the linkage is > there and this is why I thought of it more as a logical device and not > physical one. Ok. Since this is an example of a configuration of a physical interface, it is assumed that the operator somehow knows which physical port is being reconfigured -- somehow the operator must be able to know what the port where the new cable was inserted is called in the config. But it makes sense to be more clear about this. How about this change: OLD: The implementation restricts the names of the interfaces to one of "fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an interface is a string on the form "N/M". The implementation auto-initializes the values for "type" and "location" based on the interface name. NEW: The implementation restricts the names of the interfaces to one of "fastethernet-N/M" or "gigabitethernet-N/M". The "location" of an interface is a string on the form "N/M". It is assumed that the operator is aware of this naming scheme. The implementation auto-initializes the values for "type" and "location" based on the interface name. > When looking at E2.2 example (ditto for this example.) /martin > " An operator can configure a new interface by sending an <edit-config> > containing: > > <interface nc:operation="create"> > <name>acme-interface</name> > <type>ethernetCsmacd</type> > <location>1/0</location> > </interface>" > > Here the operator need to know the device to configure a specific interface > and know how many interface exist and how they are named. So you assume that > for this case this is known to the configuration. > > Roni > > > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@xxxxxxxxxx] > Sent: 28 April, 2013 12:50 PM > To: ron.even.tlv@xxxxxxxxx > Cc: draft-ietf-netmod-interfaces-cfg.all@xxxxxxxxxxxxxx; ietf@xxxxxxxx; > gen-art@xxxxxxxx > Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10 > > 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 >