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

On Mon, Apr 9, 2018 at 3:45 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > Hi, > > > > All of these suggested solutions seem OK if one were looking for the most > > disruptive > > way to solve the problem. Tossing iana-if-types and starting over

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

Andy Bierman writes: > Hi, > > All of these suggested solutions seem OK if one were looking for the most > disruptive > way to solve the problem. Tossing iana-if-types and starting over would > achieve that result. I think nobody is suggesting to dump iana-if-types, just

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

On Fri, Apr 6, 2018 at 9:24 AM, Mahesh Jethanandani wrote: > Chassis based systems have line cards that support particular interface > types. What happens to the output when a line card is plugged in or out of > the system? In other words, is this a static or a dynamic

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

Chassis based systems have line cards that support particular interface types. What happens to the output when a line card is plugged in or out of the system? In other words, is this a static or a dynamic list? > On Apr 6, 2018, at 9:03 AM, Andy Bierman wrote: > > Hi, > >

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

Hi, All of these suggested solutions seem OK if one were looking for the most disruptive way to solve the problem. Tossing iana-if-types and starting over would achieve that result. First, this is a server capabilities problem, so it is related to the implementation, not the schema. Second,

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

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

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

On Fri, 2018-04-06 at 14:29 +0200, Juergen Schoenwaelder wrote: > On Fri, Apr 06, 2018 at 02:01:30PM +0200, 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

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

Juergen Schoenwaelder wrote: > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder writes: > > > > > If we would have a mechanism to deviate an identityref to a subset of > > >

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

On Fri, Apr 06, 2018 at 02:01:30PM +0200, 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 writes: > > > > > > > If we

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

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 writes: > > > > > If we would have a mechanism to deviate an identityref to a subset of > > >

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

Juergen, I was not suggesting to have a feature for all identities but I would assume that there are several identities that logically belong to each other so these could be grouped. If this would still lead to a lot of features I do not see how a deviation can help out here to reduce the

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

On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder 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

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

Juergen Schoenwaelder 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

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

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'. /js On Fri, Apr 06, 2018 at 08:12:03AM +, Bogaert, Bart (Nokia -

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

Alex, Not sure if this only has to do with "practical limitations providing a CLI interface"... In a machine-to-machine interface this is less of a problem but in a human-to-machine interface it seems a bit impractical to me to find a solution for a problem to scroll through a list of 100+

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

Ladislav Lhotka wrote: > Hi, > > I have argued several times in the past that the IANA interface list (and, for > that matter, the iana-if-type module) is a useless pile of rubbish because > > - for some interface classes (Ethernet, tunnels) it is way too coarse-grained > > - on

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

Hi, I have argued several times in the past that the IANA interface list (and, for that matter, the iana-if-type module) is a useless pile of rubbish because - for some interface classes (Ethernet, tunnels) it is way too coarse-grained - on the other hand, it contains a lot of stuff that nobody

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

I haven't seen any previous discussions on the topic, but we have a similar problem. Note this is not really to do with YANG itself, so much as the practical limitations of the software package that provides our CLI interface. In NETCONF, the existence of extra unused identities doesn't pose

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

Hi, We were wondering if it would make sense to introduce features in the IANA if types YANG model to enable grouping of related interface types. This would allow implementations to include only the types it really requires (by supporting the related features but not the others) and (in case