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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 Jan 2018 19:28:53 +0000

Hi Lada,

Apologies for the delay. We somewhat got hung up on 4 and 6. See inline.

On 12/6/17, 6:26 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>Reviewer: Ladislav Lhotka
>Review result: Ready with Issues
>
>The data model defined in this document is a massive piece of work: it
>consists of 11 YANG modules and defines around 1200 schema nodes. The
>"ietf-ospf@2017-10-30" module is compatible with the NMDA architecture.
>
>**** Comments
>
>1. Unless there is a really compelling reason not to do so, the
>   "ietf-ospf" should declare YANG version 1.1. For one,
>   "ietf-routing" that is being augmented by "ietf-ospf" already
>   declares this version. Some of my suggestions below also assume
>   version 1.1.

We will add this. 

>
>2. The "ietf-ospf" can work only with the new NMDA-compatible
>   revisions of some modules, such as "ietf-interfaces" and
>   "ietf-routing". I understand it is not desirable to import such
>   modules by revision, but at least it should be mentioned in a
>   description attached to every such import.

We will add comments to the description.
>
>3. Maybe the draft could mention that implementations should supply a
>   default routing domain as a system-controlled resource.

Isn’t this more of an RFC8022BIS statement? I guess we could state this as
an assumption. 
>
>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?

>
>5. Some enumerations, such as "packet-type" and "if-state-type"
>   define enum identifiers with uppercase letters and/or underscores,
>   for example "Database-Description" or "LONG_WAIT". RFC6087bis
>   recommends that only lowercase letters, numbers and dashes. I think
>   this convention should be observed despite the fact that the
>   current names are traditionally used in OSPF specs. The
>   "ietf-routing" module also defines "router-id" even though the
>   documents use "Router ID".

I agree - we will follow the RFC 6087BIS guidelines.

>
>6. The types of LSA headers are modelled as integers. While OSPF gurus
>   probably know these numbers by heart, it is not very
>   reader-frienly. So at least some references to documents defining
>   these numbers should be provided, but my suggestion is to consider
>   implementing them with identities. It seems it might also be useful
>   to define some "abstract" identities for these types. For example,
>   if "opaque-lsa" is defined, then the definition of container
>   "opaque" could simply use
>
>     when "derived-from(../../header/type, 'ospf:opaque-lsa')";
>
>   instead of
>
>      when "../../header/type = 9 or "
>              + "../../header/type = 10 or "
>              + "../../header/type = 11";

I guess I don’t see the identities as always being better. We will
consider this one. 

>
>7. The title of sec. 2.9 should be "OSPF Notifications" rather than
>   "OSPF notification".

Sure. 

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 8 Jan 2018 19:34:23 +0000

Hi Martin, 

We will incorporate these comments as well. I agree we could take another
pass at the descriptions.

Thanks,
Acee 

On 12/6/17, 7:26 AM, "Ladislav Lhotka" <[email-masked]> wrote:

>On Wed, 2017-12-06 at 12:46 +0100, Martin Bjorklund wrote:
>> Ladislav Lhotka <[email-masked]> wrote:
>> 11 YANG modules?  Isn't there just one?
>
>Yes, but I meant the complete data model including the existing modules
>that
>must be implemented along with "ietf-ospf", such as "ietf-interface",
>"ietf-
>routing" and "ietf-keychain". I think it is a higher league of data
>modelling
>compared to a stand-alone module - kudos to the authors.
>
>> 
>> 
>> 
>> I would like to add two quick comments to Lada's review.
>> 
>> o  Remove all "revision" statements except the one that says "initial
>>    revision".   The idea is to have one revision statement per
>>    published version (i.e., RFC).
>
>Right, the revisions make the module excessively long.
>
>> 
>> 
>> o  Many of the nodes have quite rudimentary descriptions, and the
>>    "reference" statement is rarely used.  For example:
>> 
>>          leaf lsa-id {
>>            type yang:dotted-quad;
>>            mandatory true;
>>            description "LSA ID.";
>>          }
>> 
>>    It seems as the description is put there just to keep the tools
>>    quiet.  I know that it is painful to write good descriptions, but
>>    it does help the consumer of the data model.
>
>Agreed.
>
>Thanks, Lada
>
>> 
>> 
>> /martin
>> 
>> 
>> > _______________________________________________
>> > yang-doctors mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/yang-doctors
>> > 
>-- 
>Ladislav Lhotka
>Head, CZ.NIC Labs
>PGP Key ID: 0xB8F92B08A9F76C67

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Jan 2018 08:51:35 +0100

Hi Acee,

please see inline.

> > Review result: Ready with Issues

...

> Isn’t this more of an RFC8022BIS statement? I guess we could state this as

Probably, but it is not a YANG issue, so I'd leave it to you routing folks to
decide.

> 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 for the
"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. 

> I guess I don’t see the identities as always being better. We will

In what situations could the numbers be better?

...

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Jan 2018 09:06:48 +0100 (CET)

Hi,

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

So the equality test of the identityref is correct.

However, I agree that in most cases 'derived-from-or-self' should be
used, in order to handle derived identities.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Jan 2018 16:08:56 +0100

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

Also, potentially there can be a collision in prefixes and then this also breaks
down.

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. 

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Jan 2018 16:23:03 +0100

On Tue, 2018-01-09 at 16:08 +0100, Ladislav Lhotka wrote:
> > > Probably, but it is not a YANG issue, so I'd leave it to you routing folks
> > 
> > to
> > 
> > > decide.
> > > 
> > > >  
> > > > 
> > > That's one reason: derived identities should often also satisfy the
> > 
> > constraint.
> > 
> > > 
> > > rely on plain string comparison that depends od the actual prefix used for
> > 
> > the
> > 
> > > "rt:type" value. For one, according to RFC 7951 the JSON encoding of this
> > 
> > value
> > 
> This is weird, to say the least. The leafref instance may have an identity 

Sorry, I meant "identityref" here --------^

Lada

> value

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Jan 2018 16:23:11 +0100 (CET)

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

> Also, potentially there can be a collision in prefixes and then this also breaks

No, two modules cannot be imported with the same prefix.

> 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
different prefix in some other module.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Jan 2018 17:08:21 +0100

> be used in the XPath expression.

In the XPath expression above, do you mean the "rt" prefix of "rt:type"? 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.

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

> writing the XPath expression.  The same identityref value might use a

No, it is not. The prefixes appear in instance data.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jan 2018 10:34:28 +0100 (CET)

Hi,

I think we can agree that the model in this I-D should use
derived-from-or-self() instead of string comparison, and conclude this
discussion here.  I suggest that if we need to further discuss the
representation of identityrefs, then we start a new thred on the
NETMOD ML.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jan 2018 10:35:50 +0100 (CET)

Hi,

Replying to this only on yang-doctors, since this is mostly a
discussion about the interpretation of RFC 7950.

> > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <[email-masked]> wrote:

[...]

> > > > > rely on plain string comparison that depends od the actual prefix used
> > > > 
> 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,
>    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.
> > 
> > 
> 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.
> > 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jan 2018 11:17:48 +0100

On Wed, 2018-01-10 at 10:35 +0100, Martin Bjorklund wrote:
> > > > needn't be imported in the module that contains the XPath expression. So
> I
> > > > don't

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?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jan 2018 12:58:41 +0100 (CET)

> datastore is either of the two '...:ospfv3' identities.

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:

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jan 2018 17:06:24 +0100

On Wed, 2018-01-10 at 12:58 +0100, Martin Bjorklund 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.
> > > > > > > > 
> > > > > > > > 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
> > > > > > >    "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
> > > > > > 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 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
> > value of the leafref node instance ("../type" here), and clearly it is what
> 
> sec.
> > 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"
> > expression in your module "a", if the value-space value of 'type' instance
> 
> in a

It depends on what "current module" means. 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.

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

Lada

> > > > > > Also, potentially there can be a collision in prefixes and then this
> > > 
> > > also
> > > > > > breaks down.
> > > > > 
> > > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jan 2018 17:18:11 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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

Yes, as I wrote in my previous email, I agree, this would be better.
But that's for YANG 2.0, unfortunately.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 12 Jan 2018 11:13:28 +0100

> or "when" expression is defined.  There was a separate thread about

OK, then it really makes no sense to add the local prefix. 

> 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 

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Jan 2018 09:45:34 -0800

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Jan 2018 09:49:15 +0100

> This cannot be changed by an errata.

So what do you suggest? The last paragraph in sec. 9.10.3 is clearly wrong.

Note also that this paragraphs tries to define the string value of an
identityref node instance for any XPath expression, which needn't necessarily be
a simple EqualityExpr.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Jan 2018 09:59:41 +0100 (CET)

> So what do you suggest? The last paragraph in sec. 9.10.3 is clearly wrong.

I agree it is wrong, but only for identityref values that are defined
in a module that has not been imported.  I stronlgy agree w/ Andy that
this does NOT mean that we should change *working* and defined
behaviour in an errata.

The intention (for better or worse) was that the value would use the
prefix used in imports.  This means that if you want to do any kind of
comparision of the string value to some known identities, then you
must import that module so that there is a prefix defined.  This was
the intention.

>From this follows that (for all practical matters), the string value
of an identity defined in a module that is not imported doesn't really
matter.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Jan 2018 10:38:19 +0100

On Mon, 2018-01-15 at 09:59 +0100, Martin Bjorklund wrote:
> > > > >> > > > > > > > > > On 12/6/17, 6:26 AM, "Ladislav Lhotka" <lhotka@nic.
> cz>
> > > > wrote:
> > > > >> > > >
> > > > >> > > > [...]
> > > > >> > > >
> > > > >> > > > > > > > > > >   identities. This is known to be problematic,
> the
> > > > XPath
> > > > >> > > >
> > > > >> > > > functions
> > > > >> > > > > > > > > > >   derived-from() or derived-from-or-self() should
> be
> > > > used
> > > > >> > > >
> > > > >> > > > instead.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > That's one reason: derived identities should often
> also
> > > > satisfy
> > > > >> >
> > > > >> > the
> > > > >> > > > > > > > > constraint.
> > > > >> > > > > > > > >
> > > > >> > > > > > > > > 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
> > > > >> > > > > > > >    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
> > > > >> > > > > > > that is defined in a module that (has to be implemented
> by
> > > > the
> > > > >> >
> > > > >> > server
> > > > >> > > > but)
> > > > >> > > > > > > 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
> > > > >> > > > > it is irrelevant for the string comparison, what's important
> is
> > > > the
> > > > >> >
> > > > >> > *value*
> > > > >> > > > of
> > > > >> > > > > needn't be imported by ietf-routing, ietf-ospf or whatever.
> Sec.
> > > > 9.10.2:
> > > > >> > > > >
> > > > >> > > > 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 {
> > > > >> > > 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.
> > > > >> > > is legal), the module foo-ospf needn't be imported anywhere and
> still
> > > > the
> > > > >> >
> > > > >> > "type"
> > > > >> values altogether and use the same string as in JSON encoding (RFC
> 7951).
> > > > The

A more serious problem is that this text mixes up the prefix as defined in the
YANG module with the prefix that applies to instance values. A newcomer that
reads this text may wonder why an identity value is combined with a prefix of a
module in which the identity is NOT defined.

> must import that module so that there is a prefix defined.  This was

This is IMO not true. As I already wrote, for using a when expression like

   when "../type = 'ospf:ospfv3'"

it is not necessary to import the "ietf-ospf" module and thus have the "ospf"
prefix defined. If you think it is necessary, then point me to the relevant
text.

Lada

> > > > >> > > > to the rules defined in RFC 7950.  The string value of the
> "type"
> > > > leaf
> > > > >> > > > > > > Also, potentially there can be a collision in prefixes
> and
> > > > then this
> > > > >> > > >
> > > > >> > > > also
> > > > >> > > > > > > breaks down.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > in a module that is not imported anywhere. If a server
> declares
> > > > such
> > > > >> > > > > > > A moral of the namespace/prefix story in XML was that
> relying
> > > > of
> > > > >> > > > > > > idea. I know that the cited paragraph was intended to
> make
> > > > such
> > > > >> > > > > > writing the XPath expression.  The same identityref value
> might
> > > > use a
> > > > >> > > > >
> > > > >> > > > I agree that it is unfortunate that context-specific prefixes
> are
> > > > used

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Jan 2018 10:53:06 +0100

> prefix defined. If you think it is necessary, then point me to the relevant

Prefixes assigned to modules using the prefix statement are not
guaranteed to be globally unique. It is possible to have multiple
modules defining the prefix 'ospf', e.g.:

 module ietf-ospf {
   prefix ospf;
 }

 module acme-ospf {
   prefix ospf;
 }

Note that this is not a problem since YANG allows to redefine the
prefix in an import statement in case a prefix clash occurs. Hence,
the 'ospf' prefix in the when statement has to refer to the prefix
that is used in the module where the when statement is defined. And
because of that it is necessary to import a module that defines the
prefix 'ospf'. Any other interpretation would be ambiguous I think.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Jan 2018 11:10:13 +0100

> that is used in the module where the when statement is defined. And

In my example, the prefix is used inside an XPath string, and XPath 1.0 doesn't
allow for adding any structure or semantics to the string type. So even if RFC
7950 stated that such an import was necessary (which it doesn't), it would be an
improper use of XPath.

YANG can define the string value of a node instance in the conceptual data tree
but a literal XPath string is just that.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Jan 2018 11:20:09 +0100

> > prefix 'ospf'. Any other interpretation would be ambiguous I think.

Fine, so this construction should be avoided since it is ambiguous.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Jan 2018 11:28:48 +0100

> Fine, so this construction should be avoided since it is ambiguous.

Yes, so I think the erratum should say just this. New modules should by all
means use the XPath functions.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Jan 2018 08:24:36 -0800

> ....

> this does NOT mean that we should change *working* and defined

I think there is other text in the RFC that says a prefix is resolved in
the local module.
This is the only design that makes any sense, and the only design that
could ever work.
The module author has no control over prefix usage and imports in other
modules.

> > identityref node instance for any XPath expression, which needn't

The derived-from and derived-from-or-self functions are flawed
because they use prefixes instead of module names and a missing
prefix means the current module instead of the local module.
I don't see how using derived-from-or-self(type, "foo") is any better
than type="foo".  The latter is being used a lot and the XPath functions
are not being used (by our customers).

Seems new XPath functions are needed, like
   derived-from2(type, "iana-if-type", "ethernetCsmacd")

Andy

> > > > >> > > > > > > Also, potentially there can be a collision in
> prefixes and
> > > > then this
> > > > >> > > >
> > > > >> > > > also
> > > > >> > > > > > > breaks down.
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > writing the XPath expression.  The same identityref
> value might
> > > > use a
> > > > >> > > > >
> > > > >> > > > The prefix *in the when expression* is under the control of
> the
> > > > module
> > > > >> > > > I agree that it is unfortunate that context-specific
> prefixes are
> > > > used

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Jan 2018 18:14:27 +0100

On Mon, 2018-01-15 at 08:24 -0800, Andy Bierman wrote:
> I think there is other text in the RFC that says a prefix is resolved in the
> local module.
> This is the only design that makes any sense, and the only design that could
> ever work.

Although I tend to agree that using module name as a parameter would be better
(it was I believe the original proposal), it is IMO not as flawed as the string
equality test because the semantics of the latter is defined by the XPath 1.0
spec. In contrast, the derived-from(-or-self) functions are defined in YANG, so
it is possible to specify additional semantics for its parameters.

I don't see any compelling reason why your customers couldn't use the functions.
The problem of sec. 9.10.3 is that it gives an excuse for using the plain string
test.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 15 Jan 2018 09:31:39 -0800

On Mon, Jan 15, 2018 at 9:14 AM, Ladislav Lhotka <[email-masked]> wrote:

> could

This sort of distinction is not relevant to engineers writing YANG modules.

> The problem of sec. 9.10.3 is that it gives an excuse for using the plain
The <node> = <value> construct is quite familiar and intuitive to people.
A good API avoids confusion instead of promoting it.
The XPath function should have used a module-name parameter
or made the module name a mandatory prefix in the identity string.

The best-case for API stability is where the canonical representation is
also
the only representation. The worst-case (current prefix) is where the
representation
has a different interpretation everywhere it is used. Context-free value
comparison is
kind of useful.

Lada

Andy

> > > > > > >> > > > You may not like it, but these two modules are both
> correct
> > > > > > according
> > > > > > >> > > > *when evaluating the when expression* is different in
> the
> > > different
> > > > > > >> > > > modules.  See the last paragraph of section 9.10.3 in
> RFC
> > > 7950.
> > > > > > >> > > >
> prefixes
> > > > > > >> > > > > "ietf-routing:control-protocol-type" base identity
> can be
> > > defined
> > > > > > >> > > > > a module as implemented, then "rt:type" may have this
> value
> > > per
> > > > > > >> > > > > sec. 9.10.2.
> > > > > > >> > > > >
> > > > > > >> > > > > conflicting prefixes defining identities that are
> derived
> > > from
> > > > > > >> > > > > > > XPath string comparisons more deterministic, but
> it is
> > > also
> > > > > > >> > > > > > Note that this prefix is under the control of the
> module
> > > > > > designer
> > > > > > >> > > > You are correct that the prefix in an XML encoding is
> not
> > > under
> prefixes
> > > > > > >> > > > for the identityref values.  It would have been better
> if we
> > > used a

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 22 Jan 2018 18:42:07 +0000

Hi Martin, Lada, 

In experimenting with this, I get YANGLINT validation errors. I’m not sure what I’m missing but the first argument to derived-from()/derive-from-or-self() is the schema node and the second is the identity – correct?
For example, the following YANG leaf:

identity ospf-protocol {
    base "rt:routing-protocol";
    description "Any version the OSPF protocol";
  }

  identity ospfv2 {
    base "ospf-protocol";
    description "OSPFv2";
  }

  identity ospfv3 {
    base "ospf-protocol";
    description "OSPFv3";
  }

leaf routing-protocol-name {
      type leafref {
        path "/rt:routing/rt:control-plane-protocols/"
           + "rt:control-plane-protocol/rt:name";
      }
      must "derived-from( "
	+ "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol[rt:name=current()]/"
        + "rt:type, ospf:ospf-protocol)";
      description
       "OSPF routing protocol instance name.";
    }

Gives me: 

warn: Schema node "ietf-ospf:ospf-protocol" not found (derived-from( /ietf-routing:routing/ietf-routing:control-plane-protocols/ietf-routing:control-plane-protocol[ietf-routing:name=current()]/ietf-routing:type, ietf-ospf:ospf-protocol) with context node "/ietf-ospf:if-state-change/routing-protocol-name".

Thanks
Acee 

On 1/10/18, 4:36 AM, "Martin Bjorklund" <[email-masked]> wrote:

    Hi,

    /martin

    Ladislav Lhotka <[email-masked]> wrote:
    > > breaks