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

[Andy Bierman <[e-mail]>]

On Mon, Jan 15, 2018 at 9:14 AM, Ladislav Lhotka <[e-mail]> wrote:

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

This sort of distinction is not relevant to engineers writing YANG modules.


> 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.
>
>
The <node> = <value> construct is quite familiar and intuitive to people.
A good API avoids confusion instead of promoting it.
The XPath function should have used a module-name parameter
or made the module name a mandatory prefix in the identity string.

The best-case for API stability is where the canonical representation is
also
the only representation. The worst-case (current prefix) is where the
representation
has a different interpretation everywhere it is used. Context-free value
comparison is
kind of useful.


Lada
>

Andy


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