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

[Martin Bjorklund <[e-mail]>]

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.

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


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