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

[Martin Bjorklund <[e-mail]>]

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'";
      ...
    }
  }

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