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

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.


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