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

From: "Roni Even" <[email-masked]>
Date: Sun, 28 Apr 2013 11:31:05 +0300

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. 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.
2.	In section 2 are the" must" and "should"  used as described in
RFC2119, if yes need capital letters
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"

---

From: "Roni Even" <[email-masked]>
Date: Sun, 28 Apr 2013 15:31:01 +0300

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:[email-masked]] 
Sent: 28 April, 2013 12:50 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10

Hi,

Thank you for your review.  Comments inline.

"Roni Even" <[email-masked]> wrote:
> Please resolve these comments along with any other Last Call comments 
> you may receive.
> 
> 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:
> 

Ok, this probably makes sense.  I will check w/ the WG and other documents.

> RFC2119, if yes need capital letters

Seciton 2 is more of a background, non-normative section.  It lists some of
the design objectives.

> 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

---

From: "Roni Even" <[email-masked]>
Date: Mon, 29 Apr 2013 12:41:37 +0300

Hi,
This new text is OK.
Thanks
Roni

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 29 April, 2013 11:26 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]

Hi,

"Roni Even" <[email-masked]> wrote:
> As for the comment on location I think I understand but what got me 
> thinking was the examples.
> In E.1
> 
> 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

> 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
> 
> 
> 
> 
> Cc: [email-masked]; 
> [email-masked]; [email-masked]
> > Please resolve these comments along with any other Last Call 
> > comments you may receive.
> > 
> > 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.
> 
> > 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:
> > 
> Seciton 2 is more of a background, non-normative section.  It lists 
> some of the design objectives.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 28 Apr 2013 11:50:10 +0200 (CEST)

Hi,

"Roni Even" <[email-masked]> wrote:
> mapping.

and then the text says:

> I saw the examples in Appendix E and it looked more to me as

Ok, this probably makes sense.  I will check w/ the WG and other
documents.

> 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:

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 29 Apr 2013 10:25:42 +0200 (CEST)

Hi,

> there and this is why I thought of it more as a logical device and not

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.

OLD:

NEW:

/martin