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 <j.schoenwael...@jacobs-university.de> 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. > > > > > - 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.
Putting today's limits of YANG syntax aside for the moment, I still believe implementations need to publish the identities they support without requiring matching features or module definition. > > 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. If an implementation does not check input, then the code is broken, regardless whether we restrict the identities somewhere or not. I do not buy the security point. /js -- 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
