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

[Andy Bierman <[e-mail]>]

On Fri, Jan 12, 2018 at 2:13 AM, Ladislav Lhotka <[e-mail]> wrote:

> Martin Bjorklund <[e-mail]> writes:
>
> > Ladislav Lhotka <[e-mail]> wrote:
> >> On Wed, 2018-01-10 at 12:58 +0100, Martin Bjorklund wrote:
> >> > Ladislav Lhotka <[e-mail]> wrote:
> >> > > On Wed, 2018-01-10 at 10:35 +0100, Martin Bjorklund wrote:
> >> > > > Hi,
> >> > > >
> >> > > > Replying to this only on yang-doctors, since this is mostly a
> >> > > > discussion about the interpretation of RFC 7950.
> >> > > >
> >> > > >
> >> > > > Ladislav Lhotka <[e-mail]> wrote:
> >> > > > > On Tue, 2018-01-09 at 16:23 +0100, Martin Bjorklund wrote:
> >> > > > > > Ladislav Lhotka <[e-mail]> wrote:
> >> > > > > > > On Tue, 2018-01-09 at 09:06 +0100, Martin Bjorklund wrote:
> >> > > > > > > > Ladislav Lhotka <[e-mail]> wrote:
> >> > > > > > > > > On Mon, 2018-01-08 at 19:28 +0000, Acee Lindem (acee)
> wrote:
> >> > > > > > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <[e-mail]>
> wrote:
> >> > > >
> >> > > > [...]
> >> > > >
> >> > > > > > > > > > > 4. In "when" expressions, the module uses literal
> strings
> >> >
> >> > for
> >> > > > > > > > > > >   identities. This is known to be problematic, the
> XPath
> >> > > >
> >> > > > functions
> >> > > > > > > > > > >   derived-from() or derived-from-or-self() should
> be used
> >> > > >
> >> > > > instead.
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > Why is this problematic? Is it because the types can
> be
> >> >
> >> > extended?
> >> > > > > > > > >
> >> > > > > > > > > That's one reason: derived identities should often also
> satisfy
> >> >
> >> > the
> >> > > > > > > > > constraint.
> >> > > > > > > > >
> >> > > > > > > > > But the more serious problem is that things like
> >> > > > > > > > >
> >> > > > > > > > >     when "../../../../../../../rt:type = 'ospf:ospfv3'"
> >> > > > > > > > >
> >> > > > > > > > > rely on plain string comparison that depends od the
> actual
> >> >
> >> > prefix
> >> > > > used
> >> > > > > > > >
> >> > > > > > > > > "rt:type" value. For one, according to RFC 7951 the JSON
> >> >
> >> > encoding of
> >> > > > > > > > > this value
> >> > > > > > > > > would be "ietf-ospf:ospfv3" so the above expression is
> always
> >> > > >
> >> > > > false.
> >> > > > > > > >
> >> > > > > > > > This is not correct; the when expression is not evaluated
> on the
> >> >
> >> > JSON
> >> > > > > > > > encoding.  See the last paragraph of section 9.10.3 in
> RFC 7950:
> >> > > > > > > >
> >> > > > > > > >    The string value of a node of type "identityref" in a
> "must" or
> >> > > > > > > >    "when" XPath expression is the referred identity's
> qualified
> >> >
> >> > name
> >> > > > > > > >    with the prefix present.  If the referred identity is
> defined
> >> >
> >> > in an
> >> > > > > > > >    imported module, the prefix in the string value is the
> prefix
> >> > > >
> >> > > > defined
> >> > > > > > > >    in the corresponding "import" statement.  Otherwise,
> the prefix
> >> >
> >> > in
> >> > > > > > > >    the string value is the prefix for the current module.
> >> > > > > > >
> >> > > > > > > This is weird, to say the least. The leafref instance may
> have an
> >> > > >
> >> > > > identity
> >> > > > > > > value
> >> > > > > > > that is defined in a module that (has to be implemented by
> the
> >> >
> >> > server
> >> > > > but)
> >> > > > > > > needn't be imported in the module that contains the XPath
> >> >
> >> > expression. So
> >> > > > I
> >> > > > > > > don't
> >> > > > > > > know what 'corresponding "import" statement' this paragraph
> is
> >> >
> >> > talking
> >> > > > > > > about.
> >> > > > > >
> >> > > > > > It has to import the module in order to give a prefix, which
> then can
> >> > > > > > be used in the XPath expression.
> >> > > > >
> >> > > > > In the XPath expression above, do you mean the "rt" prefix of
> >> > > > > "rt:type"?
> >> > > >
> >> > > > No, I meant the "ospf" prefix for the module "ietf-ospf".
> >> > > >
> >> > > > > If so,
> >> > > > > it is irrelevant for the string comparison, what's important is
> the
> >> >
> >> > *value*
> >> > > > of
> >> > > > > the "rt:type" instance, which can be an identity defined in a
> module
> >> >
> >> > that
> >> > > > > needn't be imported by ietf-routing, ietf-ospf or whatever.
> Sec. 9.10.2:
> >> > > > >
> >> > > > >    On a particular server, the valid values are further
> restricted
> >> > > > >    to the set of identities defined in the modules implemented
> by
> >> > > > >    the server.
> >> > > >
> >> > > > Because of the way the representation of identities work in
> must/when
> >> > > > expressions, you *must* import the module where the identity is
> >> > > > define, if you want to use the identity for equality comparision
> like
> >> > > > in the example.
> >> > > >
> >> > > > You may have:
> >> > > >
> >> > > >   module a {
> >> > > >     ...
> >> > > >     import ietf-ospf {
> >> > > >       prefix x;
> >> > > >     }
> >> > > >     ...
> >> > > >     leaf foo {
> >> > > >       when "../type = 'x:ospfv3'";
> >> > > >       ...
> >> > > >     }
> >> > > >   }
> >> > >
> >> > > The problem here is not with the literal 'x:ospf' but rather with
> the string
> >> > > value of the leafref node instance ("../type" here), and clearly it
> is what
> >> >
> >> > sec.
> >> > > 9.10.3 talks about ("string value of a [leafref] node").
> >> > >
> >> > > I can define a module like
> >> > >
> >> > > module foo-ospf {
> >> > >   namespace "http://example.com/foo-ospf";
> >> > >   prefix ospf;
> >> > >   import ietf-routing {
> >> > >     prefix rt;
> >> > >   }
> >> > >   identity ospfv3 {
> >> > >     base "rt:routing-protocol";
> >> > >   }
> >> > >   ...
> >> > > }
> >> > >
> >> > > Now, if the server advertizes both ietf-ospf and foo-ospf as
> implemented
> >> >
> >> > (which
> >> > > is legal), the module foo-ospf needn't be imported anywhere and
> still the
> >> >
> >> > "type"
> >> > > leaf instance can have both values "ietf-ospf:ospfv3" and
> "foo-ospf:ospfv3",
> >> > > provided that it is defined as
> >> > >
> >> > > leaf type {
> >> > >   type identityref {
> >> > >     base rt:routing-protocol;
> >> > >   }
> >> > > }
> >> > >
> >> > > And I wonder what the last paragraph in sec. 9.10.3 means in this
> situation,
> >> > > i.e. what string value of "type" is used in the evaluation of the
> XPath
> >> > > expression in your module "a", if the value-space value of 'type'
> instance
> >> >
> >> > in a
> >> > > datastore is either of the two '...:ospfv3' identities.
> >> > >
> >> > > Do you see what I mean?
> >> >
> >> > Do you mean that the problem is that the spec does not define what the
> >> > string value is if the module where the identity is defined is not
> >> > imported?
> >> >
> >> > I agree that this is an issue.
> >> >
> >> > BUT, actually, if you look the text in the spec:
> >> >
> >> >    The string value of a node of type "identityref" in a "must" or
> >> >    "when" XPath expression is the referred identity's qualified name
> >> >    with the prefix present.  If the referred identity is defined in an
> >> >    imported module, the prefix in the string value is the prefix
> defined
> >> >    in the corresponding "import" statement.  Otherwise, the prefix in
> >> >    the string value is the prefix for the current module.
> >> >
> >> > If you blindly follow this, the last sentence would have to apply, and
> >> > the string would be "a:ospfv3", which clearly is broken.
> >>
> >> It depends on what "current module" means.
> >
> > "current module" and "local module" means the module where the "must"
> > or "when" expression is defined.  There was a separate thread about
> > this as well.
>
> OK, then it really makes no sense to add the local prefix.
>
> >
> >> It could also be interpreted as the
> >> module in which the identity is defined, but then we can get the
> collision of
> >> prefixes as in my example.
> >>
> >> >
> >> > For all practical purposes, I think the string value can be "" if the
> >> > identity is defined in a module that is not imported, and is not
> >> > defined in the current module.
> >>
> >> I think a better solution would be to avoid prefixes in lexical-space
> identity
> >> values altogether and use the same string as in JSON encoding (RFC
> 7951). The
> >> XPath expression from your example would become
> >>
> >>     "../type = 'ietf-ospf:ospfv3'"
> >>
> >> Everything would then be straightforward and non-ambiguous.
> >
> > Yes, as I wrote in my previous email, I agree, this would be better.
> > But that's for YANG 2.0, unfortunately.
>
> Maybe not. If we agree that the last paragraph in 9.10.3 is wrong ang
> needs an erratum, then I think instead of saying that the XPath string
> value is the empty string as you suggested (which is weird and
> non-intuitive), this paragraph can say that the value (only for XPath!)
> is as in RFC 7951.
>
> In fact, after re-reading sec. 9.10, I believe it is even not required
> to import the module in order to be able to use the prefix in a string
> literal, as "x" in
>
>     "../type = 'x:ospfv3'"
>
> because it is just an XPath 1.0 string with no additional semantics, so
> module authors can equally well write
>
>     "../type = 'ietf-ospf:ospfv3'"
>
> without importing "ietf-ospf".
>
> Of course, we could also replace the paragraph with a statement that the
> result of using bare identityref string values in XPath is undefined and
> thus force everybody to use the XPath functions.
>
>

I do not agree with this interpretation.
The term "prefix" is used 10 times in that section.
It is clear that the WG meant "prefix" not "module name".
This cannot be changed by an errata.



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