On Apr 30, 2013, at 12:20 PM, Martin Bjorklund <mbj@xxxxxxxxxx> 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