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 +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > 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+ completions if an > operator would ask for the possible completion in case he does not know what > to provide as input. There are ways to limit this output but it can be > solved on a modelling level as well. As I indicated identities can be > conditional to a feature and if implementations choose not to implement a set > of interface-type related features the list becomes (a whole lot) shorter "by > itself". Now iana-if-type is just a collection of all interface types that > have been defined once without any kind of "structure". > > Regards, Bart > > -----Original Message----- > From: Ladislav Lhotka [mailto:lho...@nic.cz] > Sent: Friday, April 6, 2018 9:55 AM > To: Alex Campbell <alex.campb...@aviatnet.com>; Bogaert, Bart (Nokia - > BE/Antwerp) <bart.boga...@nokia.com>; netmod@ietf.org > Subject: 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 will ever use > > - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for > Ethernet is outright stupid > > - YANG identities allow for encoding important relationships in interface > types,in the flat list all this information is lost > > - as you say, implementing the iana-if-type module means that all interface > types listed therein become valid. > > So yes, I do believe that it would be useful if authoritative expert groups > develop a better structure of interface type identities. > > Lada > > On Thu, 2018-04-05 at 23:59 +0000, Alex Campbell wrote: > > 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 any > > problem. > > > > From: netmod <netmod-boun...@ietf.org> on behalf of Bogaert, Bart > > (Nokia - > > BE/Antwerp) <bart.boga...@nokia.com> > > Sent: Thursday, 5 April 2018 8:21 p.m. > > To: netmod@ietf.org > > Subject: [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 of a CLI > > interface) would reduce the possible completions if an operator would > > ask for the possible values of the type of an interface. > > Has this ever been considered/discussed? > > > > Best regards, > > Bart > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
