Re: [netmod] An abundant amount of IANA if types...

[Robert Wilton <[e-mail]>]

At the moment, I would say that the vast majority of the definitions in 
IANA.yang are just noise because they refer to definitions that are 
obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, 
and that 10% includes technologies such as frame relay, serial, atm, 
that very much seem to be on their way out.

Using hierarchical identities and interface properties seems like a 
reasonable solution to me (e.g. as described in 
draft-wilton-netmod-interface-properties-00).  E.g. so rather than 
having configuration with a direct when statement on a specific list of 
interface types, instead the when statement can depend on the 
appropriate interface properties.

I also like Lada's suggestion of trying to spread out the IANA 
definitions to the modules that are defining the technology.  So, if a 
device implements support for PPP configuration/operational state then 
it would also naturally define any PPP related interface identities at 
the same time.

If a vendor wants to define their own flavour of Ethernet interface then 
they can do so in their vendor specific module without requiring all 
tooling to become aware of it, and allowing the existing Ethernet 
configuration to work as normal.



On 06/04/2018 13:01, Ladislav Lhotka wrote:
> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
>>> Juergen Schoenwaelder <[e-mail]> writes:
>>>
>>>> If we would have a mechanism to deviate an identityref to a subset of
>>>> identity values supported by an implementation, we would have solved a
>>>> more generic problem. Yes, the IANA list could be 'nicer' but it will
>>>> never be 'nice'.
>>> Three mechanisms can be used for this:
>>>
>>> - splitting the identities into separate modules
>> Whatever module organization you come up with, it won't work for all
>> implementations.
Yes, getting the root of this structure right is perhaps somewhat 
tricky, but I don't think that it needs to be all encompassing, or perfect.

>>> - using features
>> Making every identity a feature will turn the feature system upside
>> down. This is similar to making every leaf a feature.
>>
>>> - using deviations (even though vendors frown on them)
>> If my implementation only supports A and B and C, then a deviation may
>> state exactly that and the problem is solved. Hoping that my specific
> In fact, deviations cannot delete identity values because they aren't schema
> nodes, so they are of no use.
>
>> combination of A and B and C matches a set of modules or some set of
>> features is in my view an illusion.
> An implementation that supports, say, a given type of tunnel interface will
> implement the module that covers this tunnel type. If the identity for this
> tunnel interface type is defined in the same module, then all is good. I don't
> get why this should be an illusion. On the contrary, I think it is the cleanest
> available solution to this conformance specification problem.
>
>> Vendors not shipping proper deviations are essentially telling their
>> customers that they have not yet understood model driven management.
>> We need to change the mindset here instead of polluting our data
>> models with hundreds or thousands of fine grained 'features'.
> I agree that zillions of features aren't nice but it seems to be the only
> solution that we currently have for modules of the iana-if-type style.
>
> Having an bulky set of identity values, most of which are of no interest, is IMO
> much worse and could also be a security issue if implementors aren't careful
> enough.
I'm not sure there is a security concern here, but a long list where 
most of the values are cruft doesn't really seem to help anyone.  It 
also makes it harder to know which is the right type to use.  E.g. will 
everyone know that they should use "ethernetCsmacd" rather than 
"gigabitEthernet" for an optical GE interface that doesn't actually use 
CSMA/CD ...

Thanks,
Rob


>
> Lada
>
>> /js
>>