Subject: [netmod] is identity derivation reflexive?

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Dec 2012 11:06:54 +0100

Hi,

Jernej sent me a bug report for RFC 6110 which surprised me: So far, I have assumed that identity derivation is a reflexive relation, so that, using for example the "my-crypto" module in RFC 6020, Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto" leaf.

Is it correct?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Dec 2012 11:13:19 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> Jernej sent me a bug report for RFC 6110 which surprised me: So far, I
> have assumed that identity derivation is a reflexive relation, so
> that, using for example the "my-crypto" module in RFC 6020,
> Sec. 9.10.5, "crypto:crypto-alg" is a valid value of the "crypto"
> leaf.
> 
> Is it correct?

No.  Section 9.10.2 says:

   Valid values for an identityref are any identities derived from the
   identityref's base identity.

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 06 Dec 2012 12:14:55 +0100

>     identityref's base identity.

Is it transitive? Can one assume that Z is derived from X, if Y is 
derived from X and Z is derived from Y? Can an identity which is used as 
an argument to another identities' base-stmt ever appear as a value of a 
data node at all?

Jernej

>
> /martin
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Dec 2012 12:23:19 +0100 (CET)

Jernej Tuljak <[email-masked]> wrote:
> derived from X and Z is derived from Y?

Yes (it seems this could be made more clear in the text).

> Can an identity which is used
> as an argument to another identities' base-stmt ever appear as a value
> of a data node at all?

Sure:

  identity a;

  identity b {
    base a;
  }

  identity c {
    base b;
  }

  leaf foo {
    type identityref {
      base a;
    }
    default b;  // valid
  }

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Dec 2012 12:32:45 +0100

>> as an argument to another identities' base-stmt ever appear as a value

OK, so what are the permitted values of the following type in this case?

type identityref {
 base b;
}

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 06 Dec 2012 15:42:58 +0100

> OK, so what are the permitted values of the following type in this case?

"c" only I guess. Since that is the only identity derived from "b" which 
is your identityref's base. For Martin's example both "b" and "c" are 
valid (due to transitivity). A bit strange that such values are allowed 
only indirectly. Changing the module this way:

identity x;

identity a {base x;}
identity b {base a;}
identity c {base b;}

leaf foo {
   type identityref {
     base x;
   }
   default b;
}

would allow "a" too.

I agree that all of this needs clarifications in the RFC. I tested it 
during inter-op and I remember that at least one server allowed the 
referenced base identity to be a valid value for an identityref leaf.

Jernej

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Dec 2012 07:48:39 -0800

On Thu, Dec 6, 2012 at 6:42 AM, Jernej Tuljak <[email-masked]>wrote:

> is your identityref's base. For Martin's example both "b" and "c" are valid
> (due to transitivity). A bit strange that such values are allowed only
> indirectly. Changing the module this way:
>
> identity x;
>
> identity a {base x;}
> identity b {base a;}
> identity c {base b;}
>
> leaf foo {
>   type identityref {
>     base x;
>   }
>   default b;
> }
>
> would allow "a" too.
>
The identityref does not distinguish between abstract and concrete
identities.

                                         snacks
                                       /            \
                                 chips          candy
                                 /     \             |
                             corn   potato   chocolate

The YANG designer picks the base for an identityref leaf
and the intent is that only down-stream identities can be used as values.

A base(chips) leaf can have corn or potato as values.

   leaf chip-type {
     type identityref { base chips; }
   }

But I think the RFC says that chips and snacks would also be valid.
Operationally, this is not correct since these values provide no semantics
to the 'chip-type' leaf.

Jernej
>>  /martin

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Dec 2012 17:05:50 +0100

On Dec 6, 2012, at 3:42 PM, Jernej Tuljak <[email-masked]> wrote:

> "c" only I guess. Since that is the only identity derived from "b" which is your identityref's base. For Martin's example both "b" and "c" are valid (due to transitivity). A bit strange that such values are allowed only indirectly. Changing the module this way:
> 
> identity x;
> 
> identity a {base x;}
> identity b {base a;}
> identity c {base b;}
> 
> leaf foo {
>  type identityref {
>    base x;
>  }
>  default b;
> }
> 
> would allow "a" too.
> 
> I agree that all of this needs clarifications in the RFC. I tested it during inter-op and I remember that at least one server allowed the referenced base identity to be a valid value for an identityref leaf.

I checked the corresponding sections in RFC 6020 and found no text from which one could conclude that identity derivation is transitive. Section 9.10.2 only says:

"Valid values for an identityref are any identities derived from the identityref's base identity."

In my opinion, the identity derivation should in fact be a partial ordering, i.e. reflexive, transitive and antisymmetric. Antisymmetricity is stated in 6020 (no circular derivations) but the other two properties are not mentioned.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Dec 2012 08:17:24 -0800

On Thu, Dec 6, 2012 at 8:05 AM, Ladislav Lhotka <[email-masked]> wrote:

> I checked the corresponding sections in RFC 6020 and found no text from
> which one could conclude that identity derivation is transitive. Section
> 9.10.2 only says:
>

you are right -- I checked my code and it would allow 'chips' (the base)
as a value, but not 'snacks'.  But YANG has no way to say that the base
identity
is not intended to be a valid value.

>
> In my opinion, the identity derivation should in fact be a partial
> ordering, i.e. reflexive, transitive and antisymmetric. Antisymmetricity is
> stated in 6020 (no circular derivations) but the other two properties are
> not mentioned.
>
> Lada
>
>
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Dec 2012 17:17:27 +0100

On Dec 6, 2012, at 4:48 PM, Andy Bierman <[email-masked]> wrote:
> 
> The identityref does not distinguish between abstract and concrete identities.

6020 makes no distinction between abstract and concrete identities.

I can have an identity like

identity beer;

and I hope everybody agrees it is perfectly concrete.

However, the lack of reflexivity means that I cannot refer to such identities created "from scratch" via identityrefs.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Dec 2012 17:35:26 +0100

On Dec 6, 2012, at 5:17 PM, Andy Bierman <[email-masked]> wrote:

> as a value, but not 'snacks'.  But YANG has no way to say that the base identity

Well, in your example the identityref has base "chips", so it cannot reach beyond this base to "snack". The more interesting question is this:

   leaf snack-type {
     type identityref { base snacks; }
   }

Are the allowed values:

1. chips, candy (current 6020 wording)

2. snacks, chips, candy (reflexivity)

3. chips, candy, corn, potato, chocolate (transitivity)

4. snacks, chips, candy, corn, potato, chocolate (reflexivity & transitivity)

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Dec 2012 08:39:42 -0800

> and I hope everybody agrees it is perfectly concrete.
And the same applies to each new base that is derived from this one, etc.
These non-root base identities are more interesting.

I checked RFC 6020, sec. 10, and there is no mention of adding a base
to an identity statement, which means it is not allowed.

IMO this should be legal (create rev B after A is published):

Rev A:

    identity beer;

    leaf beer-type { type identityref { base beer; } }

Rev B:

    identity beverage;

    identity beer { base beverage; }

    identity wine { base beverage; }

    leaf beer-type { type identityref { base beer; } }

    leaf beverage-type { type identityref {base beverage; } }

This implies that we cannot really define abstract vs. concrete, because it
can
change depending on the data model.  It doesn't seem likely that the base
can ever provide any semantics (beer-type = beer, beverage-type = beverage).

However, the lack of reflexivity means that I cannot refer to such
> identities created "from scratch" via identityrefs.
>
>
Not sure what you mean since identityrefs can only refer to identity
statements,
not other identityref leafs.  Can you give a YANG example?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Dec 2012 08:42:11 -0800

....

>
> Well, in your example the identityref has base "chips", so it cannot reach
> beyond this base to "snack". The more interesting question is this:
>
>    leaf snack-type {
(4)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Dec 2012 17:43:08 +0100

On Dec 6, 2012, at 5:39 PM, Andy Bierman <[email-masked]> wrote:

> Not sure what you mean since identityrefs can only refer to identity statements,

identity beer;

leaf pint {
    type identityref {
        base beer;
    }
}

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 6 Dec 2012 17:44:11 +0100

> 4. snacks, chips, candy, corn, potato, chocolate (reflexivity & transitivity)

Right, that was my original idea, too, but Martin said no.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Dec 2012 21:30:06 +0100 (CET)

> Right, that was my original idea, too, but Martin said no.

Right, it should be (3).

In order to support (4) we would also need a 'abstract' keyword, to
indicate that the base class cannot be used as a proper value.  This
just adds complexity for very little gain.  With the current design,
you have to create identities for all values you want to support, not
a big deal.

Is there any real use case that cannot be handled today?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 6 Dec 2012 13:01:08 -0800

> > Right, that was my original idea, too, but Martin said no.

Right, it should be (3) but the RFC text seems to say that it is (4).

> a big deal

We don't need a new keyword.
I can't think of a use-case to use the base itself, as determined
by the identityref leaf.

   snack-type = snacks
   chip-type = chips
   candy-type = candy

You can't tell from the identity-stmt that a base is also a concrete
identity,
but you can tell from the leaf's type-stmt. Meaningless assignments like
above
should produce an invalid-value error.

.
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 Dec 2012 23:09:19 +0100 (CET)

> Right, it should be (3) but the RFC text seems to say that it is (4).

I think it might say (1) as Lada suggests.  But the intention was
always to say (3).

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 6 Dec 2012 23:24:15 +0100

> I think it might say (1) as Lada suggests.  But the intention was

This matches my recollection. 

In any case, I think this needs to be clarified since the current text
apparently leads to different interpretations. Someone wants to open
an errata?

/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: Fri, 7 Dec 2012 10:52:10 +0100

On Dec 6, 2012, at 10:01 PM, Andy Bierman <[email-masked]> wrote:

> --14dae9cfcc30eab59204d035658c
> Content-Type: text/plain; charset=UTF-8
> 

But one can easily argue that chips and candy are also "abstract" identities so that only leaf identities are supposed to be assigned to leafrefs.

Lada

> --14dae9cfcc30eab59204d035658c
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <br><br><div class=3D"gmail_quote">On Thu, Dec 6, 2012 at 12:30 PM, Martin =
> Bjorklund <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D=
> "_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
> _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
> 1ex">
> Ladislav Lhotka &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
> wrote:<br>
> &gt;<br>
> &gt; On Dec 6, 2012, at 5:42 PM, Andy Bierman &lt;<a href=3D"mailto:andy@yu=
> maworks.com">[email-masked]</a>&gt; wrote:<br>
> &gt;<br>
> &gt; &gt; ....<br>
> &gt; &gt;<br>
> &gt; &gt; Well, in your example the identityref has base &quot;chips&quot;,=
> so it cannot reach<br>
> &gt; &gt; beyond this base to &quot;snack&quot;. The more interesting quest=
> ion is this:<br>
> &gt; &gt;<br>
> &gt; &gt; =C2=A0 =C2=A0leaf snack-type {<br>
> &gt; &gt; =C2=A0 =C2=A0 =C2=A0type identityref { base snacks; }<br>
> &gt; &gt; =C2=A0 =C2=A0}<br>
> &gt; &gt;<br>
> &gt; &gt; Are the allowed values:<br>
> &gt; &gt;<br>
> &gt; &gt; 1. chips, candy (current 6020 wording)<br>
> &gt; &gt;<br>
> &gt; &gt; 2. snacks, chips, candy (reflexivity)<br>
> &gt; &gt;<br>
> &gt; &gt; 3. chips, candy, corn, potato, chocolate (transitivity)<br>
> &gt; &gt;<br>
> &gt; &gt; 4. snacks, chips, candy, corn, potato, chocolate (reflexivity &am=
> p; transitivity)<br>
> &gt; &gt;<br>
> &gt; &gt;<br>
> &gt; &gt; (4)<br>
> &gt;<br>
> &gt; Right, that was my original idea, too, but Martin said no.<br></blockq=
> uote><div>=C2=A0</div><div><br></div><div>Right, it should be (3) but the R=
> FC text seems to say that it is (4).</div><div><br></div><div><br></div><bl=
> ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
> ccc solid;padding-left:1ex">
> 
> In order to support (4) we would also need a &#39;abstract&#39; keyword, to=
> <br>
> indicate that the base class cannot be used as a proper value. =C2=A0This<b=
> r>
> just adds complexity for very little gain. =C2=A0With the current design,<b=
> r>
> you have to create identities for all values you want to support, not<br>
> a big deal</blockquote><div><br></div><div>We don&#39;t need a new keyword.=
> </div><div>I can&#39;t think of a use-case to use the base itself, as deter=
> mined</div><div>by the identityref leaf.</div><div><br></div><div>=C2=A0 =
> =C2=A0snack-type =3D snacks</div>
> <div>=C2=A0 =C2=A0chip-type =3D chips</div><div>=C2=A0 =C2=A0candy-type =3D=
> candy</div><div><br></div><div>You can&#39;t tell from the identity-stmt t=
> hat a base is also a concrete identity,</div><div>but you can tell from the=
> leaf&#39;s type-stmt. Meaningless assignments like above</div>
> <div>should produce an invalid-value error.</div><div><br></div><blockquote=
> class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
> d;padding-left:1ex">.<br>
> <br>
> Is there any real use case that cannot be handled today?<br>
> <span class=3D"HOEnZb"><font color=3D"#888888"><br>
> <br>
> /martin<br>
> <br>
> <br>
> </font></span></blockquote></div><br><div>Andy</div><div><br></div>
> 
> --14dae9cfcc30eab59204d035658c--

---

From: Jernej Tuljak <[email-masked]>
Date: Fri, 07 Dec 2012 11:24:59 +0100

> But one can easily argue that chips and candy are also "abstract" identities so that only leaf identities are supposed to be assigned to leafrefs.

Yes. That is why I asked

There's a fifth option:

5. corn, potato, chocolate (transitivity with abstract identities)

Imagine a leaf-list indentityref with option (3) which is what Martin 
and Juergen say was the WG intention.

leaf-list foo {
type indentityref {base snacks;}
}

Since "chips" implies both "corn" and "potato", what does the following 
mean in a config:

<foo>chips</foo>
<foo>corn</foo>

Technically speaking, one could argue that this breaks the unique 
constraint for leaf-list values ("corn" is duplicated), since the values 
have a special meaning.

Anyways, I also understood the RFC as (1). There's nothing in there 
about transitivity. If this was not the intention, it should be fixed.

Jernej

---

From: Xiang Li <[email-masked]>
Date: Fri, 07 Dec 2012 09:22:14 -0600

> 5. corn, potato, chocolate (transitivity with abstract identities)

I don't see this can count as another option. I think it's really the 
same as 3).

> Since "chips" implies both "corn" and "potato", what does the 
> following mean in a config:
>
> <foo>chips</foo>
> <foo>corn</foo>
>
> constraint for leaf-list values ("corn" is duplicated), since the 
> values have a special meaning.
>

For me,  since RFC6020 says:

"  Valid values for an identityref are any identities derived from the 
identityref's base identity."

I think it's natural for me to consider "corn,  potato,   chocolate" 
(the descendants of snacks) are also derived from the the identityref's 
base identity "Snacks".

If RFC6020 says the following instead:

"  Valid values for an identityref are any identities  *directly* 
derived from the identityref's base identity."

Then 1) will be my understanding. But since the word "directly" is not 
there in RFC6020, I think that the current wording is Ok. Of course it 
can be made clearer but IMO it's not a real problem.

--Xiang

---

From: Andy Bierman <[email-masked]>
Date: Fri, 7 Dec 2012 07:39:33 -0800

Hi,

On Fri, Dec 7, 2012 at 2:24 AM, Jernej Tuljak <[email-masked]>wrote:

>>>>>> Well, in your example the identityref has base "chips", so it cannot
>>>>>>
>>>>> reach
>>>>
>>>>>> 4. snacks, chips, candy, corn, potato, chocolate (reflexivity &
>>>>>>
>>>>> transitivity)
>>>>
>>>>>
>>>>>> (4)
>>>>>>
>> But one can easily argue that chips and candy are also "abstract"
>> identities so that only leaf identities are supposed to be assigned to
>> leafrefs.
>>
>
> Yes. That is why I asked
>
> Imagine a leaf-list indentityref with option (3) which is what Martin and
> Juergen say was the WG intention.

leaf-list foo {
> type indentityref {base snacks;}

But 'chips' is only a base if there are more identities defined off of it
that are supported
by the server -- 'beer and chips' can be considered a valid snack, so
even non-terminal identities may be valid values, depending on the leaf
semantics.

Leafref is not an issue -- any identityref value accepted by the server is
valid to point at
with a leafref.

The issue is that the client doesn't know from reading the YANG module(s)
what
the server will accept for a given identityref leaf.

I also raised the issue of adding a base-stmt to an identity in a later
release.
This should be allowed and does not seem to break any existing
functionality.
(e.g., add 'beverages' after 'beer' was the root)

> Since "chips" implies both "corn" and "potato", what does the following
The leaf-list needs to define the semantics I guess.
I agree the current RFC does not specify the server behavior here.
Does it accept 'chips' and ignore it? Send an invalid-value error?
Should it be up to each implementation? I hope not.

> Anyways, I also understood the RFC as (1). There's nothing in there about
> transitivity. If this was not the intention, it should be fixed.
>
> Jernej
>
>

Andy

>>> "_blank">[email-masked]</a>&**gt;</span> wrote:<br><blockquote
>>> class=3D"gmail=
>>> Ladislav Lhotka &lt;<a href=3D"mailto:[email-masked]">[email-masked]<[email-masked]></a>&gt;
>>> =
>>> wrote:<br>
>>> &gt;<br>
>>> maworks.com">andy@yumaworks.**com <[email-masked]></a>&gt;
>>> wrote:<br>
>>> &gt;<br>
>>> &gt; &gt; ....<br>
>>> &gt; &gt;<br>
>>> uote><div>=C2=A0</div><div><**br></div><div>Right, it should be (3) but
>>> the R=
>>> FC text seems to say that it is (4).</div><div><br></div><div>**
>>> <br></div><bl=
>>> a big deal</blockquote><div><br></**div><div>We don&#39;t need a new
>>> keyword.=
>>> mined</div><div>by the identityref leaf.</div><div><br></div><**div>=C2=A0
>>> =
>>> candy</div><div><br></div><**div>You can&#39;t tell from the
>>> identity-stmt t=
>>> <div>should produce an invalid-value error.</div><div><br></div><**
>>> blockquote=
>>> </font></span></blockquote></**div><br><div>Andy</div><div><**br></div>
>>>
>>> --**14dae9cfcc30eab59204d035658c--
>>>
>> --
>> ______________________________**_________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/netmod<https://www.ietf.org/mailman/listinfo/netmod>
>>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 7 Dec 2012 17:10:06 +0100

On Dec 7, 2012, at 4:22 PM, Xiang Li <[email-masked]> wrote:

> I don't see this can count as another option. I think it's really the same as 3).

It's not the same because two values from (3) are not valid here.

> 
>> Imagine a leaf-list indentityref with option (3) which is what Martin and Juergen say was the WG intention.
>> 
>> leaf-list foo {
>> Since "chips" implies both "corn" and "potato", what does the following mean in a config:
>> 
>> <foo>chips</foo>
>> <foo>corn</foo>
>> 
>> Technically speaking, one could argue that this breaks the unique constraint for leaf-list values ("corn" is duplicated), since the values have a special meaning.
>> 
>> Anyways, I also understood the RFC as (1). There's nothing in there about transitivity. If this was not the intention, it should be fixed.
> 
> "  Valid values for an identityref are any identities derived from the identityref's base identity."
> 
> I think it's natural for me to consider "corn,  potato,   chocolate" (the descendants of snacks) are also derived from the the identityref's base identity "Snacks".

Apparently, different things are natural for different people, so the spec has to be more precise. There is no definition of what "deriving an identity" means, except in sec. 7.16.1:

'The "base" statement, which is optional, takes as an argument a string that is the name of an existing identity, from which the new identity is derived.'

This means the relation "derived from" is established only between an identity and its base identity, if there is any.

Lada

> "  Valid values for an identityref are any identities  *directly* derived from the identityref's base identity."
> 
> Then 1) will be my understanding. But since the word "directly" is not there in RFC6020, I think that the current wording is Ok. Of course it can be made clearer but IMO it's not a real problem.
> 
> 
> --Xiang
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 09 Dec 2012 08:19:08 +0100

> apparently leads to different interpretations. Someone wants to open

How about this?

Section 7.16.2 says:

An identity MUST NOT reference itself, neither directly nor indirectly through a chain of other identities.

It should say:

The derivation of identities has the following properties:

o It is irreflexive, which means that no identity is derived from itself.

o It is transitive, which means that if identity B is derived from A and C is derived
  from B, then C is also derived from A.

Lada