[netmod] interface-cfg issues

[Martin Bjorklund <[e-mail]>]

Hi,

The Routing Directorate review of
draft-ietf-netmod-interfaces-cfg-10.txt
brought up a couple of issues that I think the WG needs to dicsuss.

(The original mail is not in the list archive, but my reply is found
here: 
http://www.ietf.org/mail-archive/web/netmod/current/msg08031.html)


1)  The name "location"

> > >> 3. Interfaces Data Model
> > >> …
> > >>            +--rw location?                   string
> > >> ...
> > >> 3.1. The interface List
> > >> …
> > >>   The "location" leaf is a string.  It is optional in the data model,
> > >>   but if the type represents a physical interface, it is mandatory.
> > >>   The format of this string is device- and type-dependent.  The device
> > >>   uses the location string to identify the physical or logical entity
> > >>   that the configuration applies to.  For example, if a device has a
> > >>   single array of 8 ethernet ports, the location can be one of the
> > >>   strings "1" to "8".  As another example, if a device has N cards of M
> > >>   ports, the location can be on the form "n/m", such as "1/0".
> > >> 
> > >> I think that "location" is a poorly chosen label, a misnomer. This
> > >> seems to be
> > >> closer to an identifier than a locator. For example, some devices
> > >> number slots
> > >> left to right, and some number slots right to left :-)
> > > 
> > > Correct, and we do not try to get into this at all.  Some
> > > devices has 2 ports called A and B, and some have chassis of cards
> > > with rows of ports...
> > > 
> > >> This does not answer
> > >> "where" something is; I do not mean geo-location, but I strongly
> > >> suggest
> > >> getting more precision on how this leaf is called. For example,
> > >> interface
> > >> numbering, instance id, type identifier, etc.
> > > 
> > > The intention is really to be "where" the port is.  It is not intended
> > > to be a virtual id.  If the operator plugs in a cable in a certain
> > > port, he has to know how to configure this port so there must be
> > > something in the config that connects to the physical port.  We use
> > > the name "location" for this purpose.
> > 
> > Thanks for the explanation. While I appreciate (and I agree) that you
> > do not get into interpreting or parsing the syntax of the field, I
> > still think it is not a "location".
> > 
> > I believe there is still an underlying assumption that the language is
> > defined for the physical world. If you have an Ethernet1/0, versus an
> > Ethernet1/2, that identifies (not locates) which interface. Yes, you
> > can use that to physically find them. But what if you have a
> > "loopback123" vs "loopback112358 or a "Serial1/4:5.123"? I do not
> > think we can "locate" the loopback, or the subinterface.
> > 
> > If the operator creates a "loopback", "Tunnel", or virtual interface,
> > he or she does not need to physically locate it.
> > 
> > I believe that labeling the leaf as "location" can be harmful as it
> > implies a specific meaning and shows assumptions.
> 
> Ok I think I understand your concern.  Personally, I think "location"
> works also in this case, but we should pick a name that is as useful
> as possible.  Let me bring this issue back to the WG.


Any comments on this?


2)  phys-address

>>         leaf phys-address {
>>           type yang:phys-address;
>>           config false;
>>           description
>>             "The interface's address at its protocol sub-layer.  For
>>             example, for an 802.x interface, this object normally
>>             contains a MAC address.  The interface's media-specific
>>             modules must define the bit and byte ordering and the
>>             format of the value of this object.  For interfaces that do
>>             not have such an address (e.g., a serial line), this node
>>             is not present.";
>>           reference
>>             "RFC 2863: The Interfaces Group MIB - ifPhysAddress";
>>         }
>> 
>> Just by reading the description of this leaf, shouldn't this be
>> part of an augmentation type-specific module? For example, for an
>> Ethernet interface module, instead of the main YANG interface
>> management top-level. Meaning: this specific leaf, by definition,
>> cannot be generically specified to what it means for each type of
>> interfaces. All the others can… if this cannot be specified outside
>> a media-specific module, why define it here?

So the proposal from him is to remove this leaf.  I think it could
stay, but we would probably not have added it if it wasn't part of
ifTable...  Comments?


/martin