On Fri, 2018-04-06 at 14:29 +0200, Juergen Schoenwaelder wrote:
> 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.

OK, but then I certainly wouldn't call it a deviation.

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

Come on, the cyberspace is full of such code. We should do our best to enable
schemas that are as strict as possible.

In XML, it should have been clear to everybody that hardwired namespace prefixes
are broken, and yet they were used so often that eventually the prefix-URL
duality was identified as a flaw of XML itself.

Lada 

> regardless whether we restrict the identities somewhere or not. I do
> not buy the security point.
> 
> /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