Balázs, I am not sure I fully understand what you are looking for but it sounds to me like you are looking for an IANA maintained YANG module rather than a common YANG type (i.e., this may be considered out of scope for RFC 6991 bis).
By doing this, you will likely face the same problem the crypto types are facing; having a long list of protocol identities (crypto identities) does not express that only certain subsets are useful in certain contexts (a design time subset) and that implementations are supporting only certain subsets of the subset (an implementation time subset). I am sure we have a YANG next isssue for the later one, I am not sure we have one for the first. /js On Tue, Jul 23, 2019 at 04:10:05PM +0000, Balázs Lengyel wrote: > Hello Jurgen, > > I have seen multiple places where protocol identities are needed. > (Subscribed notifications, draft-mahesh-netconf-https-notif > <https://tools.ietf.org/id/draft-mahesh-netconf-https-notif-00.txt> , 3GPP > YAMs). Wouldnt it be a good idea to define these centrally e.g. in 6991bis? > > I know collecting a complete set of protocols would be a problem, but > defining at least the most important ones centrally, is better than every > module defining its own identities, enums, strings. > > If we provide these protocol identities, it would also be good to find a way > to specify, that a YANG module supports only a subset of them not the full > set going back to X.25 and pigeon based IP. > > Regards Balazs > > > > > > _______________________________________________ > netmod mailing list > [email protected] > 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
