Hi,
This new text is OK.
Thanks
Roni
-----Original Message-----
From: Martin Bjorklund [mailto:mbj(_at_)tail-f(_dot_)com]
Sent: 29 April, 2013 11:26 AM
To: ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com
Cc: draft-ietf-netmod-interfaces-cfg(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org;
gen-art(_at_)ietf(_dot_)org
Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
Hi,
"Roni Even" <ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com> 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(_at_)tail-f(_dot_)com]
Sent: 28 April, 2013 12:50 PM
To: ron(_dot_)even(_dot_)tlv(_at_)gmail(_dot_)com
Cc:
draft-ietf-netmod-interfaces-cfg(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org; gen-art(_at_)ietf(_dot_)org
Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10
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