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

[Ladislav Lhotka <[e-mail]>]

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.

Lada

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