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.

> 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.

Lada  

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to