ietf
[Top] [All Lists]

Re: [netmod] Last Call: <draft-ietf-netmod-interfaces-cfg-10.txt> (A YANG Data Model for Interface Management) to Proposed Standard

2013-04-30 10:04:33

On Apr 30, 2013, at 12:20 PM, Martin Bjorklund <mbj(_at_)tail-f(_dot_)com> 
wrote:


5) is there a reason why "description" value MAY match IF-MIB ifAlias 
***and MAY restrict the values***? 
Is there a particular use case for this lack of standardization of 
restrictions across data models? 
The persistence is a pretty important restriction related to the 
functionality of ifAlias, and the dynamism of ifIndex. 
If NETCONF is used to set the value, ignoring IF-MIB restrictions, what 
happens to IF-MIB ifAlias as a persistent "handle" to the interface? 

The only reason the "description" leaf is mapped to ifAlias is b/c
this is what many implementations do.  So we wanted to point out the

I think it is a dubious practice.

differences in the value space for these objects so that implementers
are aware of this.

And of course it is not possible to actually set *ifAlias* and ignore
its syntax constraints.  However, you can use non 7-bit ascii in
"description", and in this case the "description" value cannot be used
unmodified as ifAlias.

If I correctly understand IF-MIB, a natural mapping would be

       +----------------------------------+------------------------+
       | YANG data node                   | IF-MIB object          |
       +----------------------------------+------------------------+
       | name                             | ifAlias                |
       | local-name                       | ifName                 |
       +----------------------------------+------------------------+

with "local-name" being a new config=false leaf. The "location" leaf then could 
be removed.
The lack of correspondence between "name" and "ifName" is somewhat confusing, 
so perhaps an alternative could be to follow suit of IF-MIB and use "alias" (== 
ifAlias) as the key of interface list, and "name" (== ifName) as the 
config=false local name. 

Lada


--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C