Re: [yang-doctors] Yangdoctors last call review of draft-ietf-ospf-yang-09

[Ladislav Lhotka <[e-mail]>]

On Mon, 2018-01-15 at 08:24 -0800, Andy Bierman wrote:
> > ....
> 
>  
> > > So what do you suggest? The last paragraph in sec. 9.10.3 is clearly
> > wrong.
> > 
> > I agree it is wrong, but only for identityref values that are defined
> > in a module that has not been imported.  I stronlgy agree w/ Andy that
> > this does NOT mean that we should change *working* and defined
> > behaviour in an errata.
> 
> 
> I think there is other text in the RFC that says a prefix is resolved in the
> local module.
> This is the only design that makes any sense, and the only design that could
> ever work.
> The module author has no control over prefix usage and imports in other
> modules.
> 
> 
> > The intention (for better or worse) was that the value would use the
> > prefix used in imports.  This means that if you want to do any kind of
> > comparision of the string value to some known identities, then you
> > must import that module so that there is a prefix defined.  This was
> > the intention.
> > 
> > From this follows that (for all practical matters), the string value
> > of an identity defined in a module that is not imported doesn't really
> > matter.
> > 
> > > Note also that this paragraphs tries to define the string value of an
> > > identityref node instance for any XPath expression, which needn't
> > necessarily be
> > > a simple EqualityExpr.
> > 
> 
> 
> The derived-from and derived-from-or-self functions are flawed
> because they use prefixes instead of module names and a missing
> prefix means the current module instead of the local module.
> I don't see how using derived-from-or-self(type, "foo") is any better
> than type="foo".  The latter is being used a lot and the XPath functions
> are not being used (by our customers).

Although I tend to agree that using module name as a parameter would be better
(it was I believe the original proposal), it is IMO not as flawed as the string
equality test because the semantics of the latter is defined by the XPath 1.0
spec. In contrast, the derived-from(-or-self) functions are defined in YANG, so
it is possible to specify additional semantics for its parameters.

I don't see any compelling reason why your customers couldn't use the functions.
The problem of sec. 9.10.3 is that it gives an excuse for using the plain string
test.

Lada

> 
> Seems new XPath functions are needed, like
>    derived-from2(type, "iana-if-type", "ethernetCsmacd")
> 
> 
>  
> > 
> > /martin
> > 
> 
> Andy
>  
> > 
> > >
> > > Lada
> > >
> > > >
> > > >
> > > > > Lada
> > > >
> > > >
> > > > Andy
> > > >
> > > > > >
> > > > > >
> > > > > > /martin
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >>
> > > > > >> Lada
> > > > > >>
> > > > > >> >
> > > > > >> >
> > > > > >> > /martin
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > >
> > > > > >> > > Lada
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > >
> > > > > >> > > > and
> > > > > >> > > >
> > > > > >> > > >   module b {
> > > > > >> > > >     ...
> > > > > >> > > >     import ietf-ospf {
> > > > > >> > > >       prefix y;
> > > > > >> > > >     }
> > > > > >> > > >     ...
> > > > > >> > > >     leaf bar {
> > > > > >> > > >       when "../type = 'y:ospfv3'";
> > > > > >> > > >       ...
> > > > > >> > > >     }
> > > > > >> > > >   }
> > > > > >> > > >
> > > > > >> > > > You may not like it, but these two modules are both correct
> > > > > according
> > > > > >> > > > to the rules defined in RFC 7950.  The string value of the
> > "type"
> > > > > leaf
> > > > > >> > > > *when evaluating the when expression* is different in the
> > different
> > > > > >> > > > modules.  See the last paragraph of section 9.10.3 in RFC
> > 7950.
> > > > > >> > > >
> > > > > >> > > > > > > Also, potentially there can be a collision in prefixes
> > and
> > > > > then this
> > > > > >> > > >
> > > > > >> > > > also
> > > > > >> > > > > > > breaks down.
> > > > > >> > > > > >
> > > > > >> > > > > >
> > > > > >> > > > > > No, two modules cannot be imported with the same prefix.
> > > > > >> > > > >
> > > > > >> > > > > I have to disagree. An identity derived from the
> > > > > >> > > > > "ietf-routing:control-protocol-type" base identity can be
> > defined
> > > > > >> > > > > in a module that is not imported anywhere. If a server
> > declares
> > > > > such
> > > > > >> > > > > a module as implemented, then "rt:type" may have this value
> > per
> > > > > >> > > > > sec. 9.10.2.
> > > > > >> > > > >
> > > > > >> > > > > And, consequently, there may be two different modules with
> > > > > >> > > > > conflicting prefixes defining identities that are derived
> > from
> > > > > >> > > > > "ietf-routing:control-protocol-type".
> > > > > >> > > >
> > > > > >> > > > Sure, but this is not the point.
> > > > > >> > > >
> > > > > >> > > > > > > A moral of the namespace/prefix story in XML was that
> > relying
> > > > > of
> > > > > >> > > > > > > namespace prefixes having a particular value is a
> > really bad
> > > > > >> > > > > > > idea. I know that the cited paragraph was intended to
> > make
> > > > > such
> > > > > >> > > > > > > XPath string comparisons more deterministic, but it is
> > also
> > > > > >> > > > > > > problematic and should be avoided if possible.
> > > > > >> > > > > >
> > > > > >> > > > > > Note that this prefix is under the control of the module
> > > > > designer
> > > > > >> > > > > > writing the XPath expression.  The same identityref value
> > might
> > > > > use a
> > > > > >> > > > >
> > > > > >> > > > > No, it is not. The prefixes appear in instance data.
> > > > > >> > > >
> > > > > >> > > > The prefix *in the when expression* is under the control of
> > the
> > > > > module
> > > > > >> > > > designer, as explained above.
> > > > > >> > > >
> > > > > >> > > > You are correct that the prefix in an XML encoding is not
> > under
> > > > > >> > > > control of the module designer, but noone has claimed that.
> > > > > >> > > >
> > > > > >> > > > I agree that it is unfortunate that context-specific prefixes
> > are
> > > > > used
> > > > > >> > > > for the identityref values.  It would have been better if we
> > used a
> > > > > >> > > > context free representation, e.g. "<module-
> > name>:<identity>".  But
> > > > > >> > > > that's another discussion.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > /martin
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > > Ladislav Lhotka
> > > > > >> > > Head, CZ.NIC Labs
> > > > > >> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > >> > >
> > > > > >> --
> > > > > >> Ladislav Lhotka
> > > > > >> Head, CZ.NIC Labs
> > > > > >> PGP Key ID: 0xB8F92B08A9F76C67
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> yang-doctors mailing list
> > > > > >> [e-mail]
> > > > > >> https://www.ietf.org/mailman/listinfo/yang-doctors
> > > > > >>
> > > > >
> > > > > --
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > >
> > > > > _______________________________________________
> > > > > yang-doctors mailing list
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/yang-doctors
> > > >
> > > >
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67