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
> 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
> much worse and could also be a security issue if implementors aren't careful
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.
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