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.
When looking at E2.2 example
" 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