Subject: [netmod] Another question about identityref with multiple base statements

From: Italo Busi <[email-masked]>
Date: Wed, 23 Sep 2020 09:00:49 +0000

I have also another question about identityref with multiple base statements.

Let’s consider the following definitions:

identity base-1 {

  description

    "Base identity #1.";

}

identity base-2 {

  description

    "Base identity #2.";

}

identity a {

  base base-1;

  description

    "Identity A.";

}

identity a-1 {

  base base-2;

  base a;

  description

    "Identity A-1.";

}

identity b {

  base base-1;

  description

    "Identity B.";

}

identity b-1 {

  base base-2;

  base b;

  description

    "Identity B-1.";

}

And the following identityrefs:

leaf reference-1 {
  type identityref {
    base base-1;
  }
  description
    "Reference to an identity #1.";
}

leaf reference-2 {
  type identityref {
    base base-2;
  }
  description
    "Reference to an identity #2.";
}

In this case, my understanding is that all the possible pairs (a, a-1), (a, b-1), (a-1, a-1), (a-1, b-1), (b, a-1), (b, b-1), (b-1, a-1) and (b-1, b-1) would be valid values for reference-1 and reference-2.

Is my understanding correct?

Is there a way to restrict the possible values for reference-1 and reference-2 to a limited subset like (a, a-1) or (b, b-1)?

For example, would this code be valid?

leaf reference-2 {
  type identityref {
    base base-2;
  }
  must 'derived-from(../reference-2, ../reference-1)';
  description
    "Reference to an identity #2.";
}

If not, is there any other option to restrict the possible values for reference-1 and reference-2?

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer

____________________________________________________________________

Huawei Technologies Italia S.r.l.
Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090 Segrate (MI)
Tel: +39 345 4721946 - Mobile: [email-masked]<mailto:[email-masked]>

__________________________________________________________________________________
Huawei Technologies Italia S.r.l. is a company registered in Italy at the Company Registration Office of Milan, with registered number 04501190963 and equity capital €3,000,000 fully paid up, whose registered office is in Milan, Via Lorenteggio 240, Tower A, 20147 Milan, Italy. Huawei Technologies Italia S.r.l. is 100% owned by Huawei Technologies Cooperatief U.A.
CONAI Reg. No. cc 12639454 - A.E.E. Registry No. IT10010000006521 - Batteries and Accumulators Registry No. IT12050P00002839.
________________________________________________________________________________________________________________________
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! Thank you.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs you that the personal data contained in this email will be collected and treated for the acquisition of information preliminary to the conclusion of contracts, for the definition of the contractual relationship, as well as for the fulfillment of legal requirements related to civil, tax and accounting law or any other legal obligation to which Huawei may be subject. Personal data will not be subject to disclosure and spread unless otherwise required by law. Huawei will take appropriate security measures to protect personal data against loss, misuse disclosure or destruction of the information. Personal Data held may be transferred to countries outside the European Union, however Huawei Italia has put in place appropriate safeguards for the transfer of personal data to third countries by adopting the standard data protection clauses of the EU Commission. Personal Data are kept for a period necessary for the fulfillment of contract obligations unless otherwise required by law. You can exercise your rights under Art. 15 and following of the GDPR (i.e. right of access, rectification, erasure, restriction, portability, object) by contacting Huawei at this email address: [email-masked]<mailto:[email-masked]> or through the following channel: www.huawei.com/en/personal-data-request<http://www.huawei.com/en/personal-data-request>. You have also the right to lodge a complaint with the competent supervisory authorities. If you need any further information or have any queries on how Huawei process your personal data, please send an email to our Data Protection Officer at [email-masked]<mailto:[email-masked]>.The Data Controller is Huawei Technologies Italia S.r.l. with registered office in Milan, Via Lorenteggio 240 Tower A, 20147.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 23 Sep 2020 19:47:40 +0000

Italo,

Your question is difficult to parse because:

  1) the example is long without an easy way to understand it.  For instance:

	   Identities:
	     +-- base-1
	     |  +-- a
	     |  +-- a1
	     +-- base-2
	        +-- b
	        +-- b1

  2) the derived identities names aren’t logical.  For instance, this would’ve been easier to parse:

	   Identities:
	     +-- base-1
	     |  +-- a1
	     |  +-- a2
	     +-- base-2
	        +-- b1
	        +-- b2

And the following even easier:

	   Identities:
	     +-- a
	     |  +-- a1
	     |  +-- a2
	     +-- b
	        +-- b1
	        +-- b2

That said, see below:

> On Sep 23, 2020, at 5:00 AM, Italo Busi <[email-masked]> wrote:
> 

Reference-1 can be any of: "base-1", “a”, and “”a1”
Reference-2 can be any of: “base-2", “b”, and “”b1”
 
A total of 9 combinations.  You only list 8 and none of them include “base-1” or “base-2”, so no, it doesn’t look correct.

> If not, is there any other option to restrict the possible values for reference-1 and reference-2?

“must” expressions can be used.  For instance, the ssh-client-server draft includes the line:

	must 'public-key-format = "ct:ssh-public-key-format”'
	
	note: "public-key-format” is an identity.

I don’t know about your particular goal, but “must” expressions are incredibly powerful and likely can achieve what is needed.

K.  // contributor

> Tel: +39 345 4721946 - Mobile: [email-masked] <mailto:[email-masked]>
>  
> PRIVACY NOTICE: Pursuant to Art. 13 of the General Data Protection Regulation 2016/679 (GDPR), Huawei Technologies Italia S.r.l. informs you that the personal data contained in this email will be collected and treated for the acquisition of information preliminary to the conclusion of contracts, for the definition of the contractual relationship, as well as for the fulfillment of legal requirements related to civil, tax and accounting law or any other legal obligation to which Huawei may be subject. Personal data will not be subject to disclosure and spread unless otherwise required by law. Huawei will take appropriate security measures to protect personal data against loss, misuse disclosure or destruction of the information. Personal Data held may be transferred to countries outside the European Union, however Huawei Italia has put in place appropriate safeguards for the transfer of personal data to third countries by adopting the standard data protection clauses of the EU Commission. Personal Data are kept for a period necessary for the fulfillment of contract obligations unless otherwise required by law. You can exercise your rights under Art. 15 and following of the GDPR (i.e. right of access, rectification, erasure, restriction, portability, object) by contacting Huawei at this email address: [email-masked] <mailto:[email-masked]> or through the following channel: www.huawei.com/en/personal-data-request <http://www.huawei.com/en/personal-data-request>. You have also the right to lodge a complaint with the competent supervisory authorities. If you need any further information or have any queries on how Huawei process your personal data, please send an email to our Data Protection Officer at [email-masked] <mailto:[email-masked]>.The Data Controller is Huawei Technologies Italia S.r.l. with registered office in Milan, Via Lorenteggio 240 Tower A, 20147.
>  
>  
> _______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Italo Busi <[email-masked]>
Date: Wed, 30 Sep 2020 10:48:27 +0000

Hi Kent,

Thanks a lot for your reply and for you suggestion on how to improve the example

Let me try to clarify the goal I am trying to achieve, updating the example as per your suggestion:

Identities:
  +-- a
  |  +-- a1
  |  +-- a2
  +-- b
     +-- b1
     +-- b2

The YANG code using the identityref statements would become:

leaf reference-1 {
  type identityref {
    base a;
  }
  description
    "Reference to an identity of type A.";
}

leaf reference-2 {
  type identityref {
    base b;
  }
  description
    "Reference to an identity of type B.";
}

My understanding is that:
reference-1 can be any of: “a1”, and “”a2” (but not “a”)
reference-2 can be any of: “b1”, and “”b2” (but not “b”)

At least, according to my understanding of section 7.18.2 of RFC7950 saying that an identity is “irreflexive, which means that an identity is not derived from itself”.

Am I missing anything here?

If not the number of allowed combinations would be four: (a1, b1), (a1, b2), (a2, b1) and (a2, b2).

Coming back to my goal, I would like to encode in YANG a condition that limits the number of possible combinations to just (a1, b1) and (a2, b2).

My doubt is about how to define a must statement that will enforce this rule while allowing other modules to define new identities that could be used for reference-1  and reference-2. For example, another module can define the a3 and b3 identities and impose the condition that only the (a3, b3) combination is allowed.

My initial thinking was to leverage the multiple bases feature and re-define the identities as follow:

Identities:
  +-- a
  |  +-- a1
  |  |  +-- b1
  |  +-- a2
  |     +-- b2
  +-- b
     +-- b1
     +-- b2

Updating, for example, the YANG code as:

identity b1 {
  base b;
  base a1;
  description
    "Identity B1.";
}

In this case, the must expression could be:

leaf reference-2 {
  type identityref {
    base b;
  }
  must 'derived-from(../reference-2, ../reference-1)';
  description
"Reference to an identity of type B.";
}

IMHO, this code would work but my doubt is about the definition of the derived-from function in RFC7950:

boolean derived-from(node-set nodes, string identity)

Could the second argument be an XPath to a node of type identityref or should it be a string containing the identity value?

In the former case, my goal has been achieved, while in the latter case it would not work since the must statement would need to be updated any time a new identity of base a or base b is defined …

What do you think?

Thanks, Italo

From: Kent Watsen [mailto:[email-masked]]
Sent: mercoledì 23 settembre 2020 21:48
To: Italo Busi <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] Another question about identityref with multiple base statements

Italo,

             Identities:
               +-- base-1
               |  +-- a
               |  +-- a1
               +-- base-2
                  +-- b
                  +-- b1

             Identities:
               +-- base-1
               |  +-- a1
               |  +-- a2
               +-- base-2
                  +-- b1
                  +-- b2

             Identities:
               +-- a
               |  +-- a1
               |  +-- a2
               +-- b
                  +-- b1
                  +-- b2

That said, see below:

On Sep 23, 2020, at 5:00 AM, Italo Busi <[email-masked]<mailto:[email-masked]>> wrote:

identity base-1 {
  description
    "Base identity #1.";
}

identity base-2 {
  description
    "Base identity #2.";
}

identity a {
  base base-1;
  description
    "Identity A.";
}

identity a-1 {
  base base-2;
  base a;
  description
    "Identity A-1.";
}

identity b {
  base base-1;
  description
    "Identity B.";
}

identity b-1 {
  base base-2;
  base b;
  description
    "Identity B-1.";
}

leaf reference-1 {
  type identityref {
    base base-1;
  }
  description

leaf reference-2 {
  type identityref {
    base base-2;
  }
  description

leaf reference-2 {
  type identityref {
    base base-2;
  }

K.  // contributor

Thanks, Italo

Italo Busi

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