ietf
[Top] [All Lists]

Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10

2013-04-29 09:09:33
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