Subject: Re: [CCAMP] Question about identities with multiple bases

From: tom petch <[email-masked]>
Date: Fri, 5 Jun 2020 11:12:00 +0000

From: CCAMP <[email-masked]> on behalf of Italo Busi <[email-masked]>
Sent: 19 May 2020 17:49

Hi Rob,

We have discussed an open issue with the ietf-l1csm which is impacting the ietf-layer1-types YANG model, for which we are addressing CCAMP WG LC comments

See slides 3 and 4 of the attached presentation made during the CCAMP WG virtual meeting last week

Since we have not much experience with identities having multiple bases, we would like to get a feedbacks from you about whether the proposed solution would work
<tp>
Italo

I have not seen a response to your question.  I had a look and it seems ok but like you I do not see much of this construct in IETF modules.

So while it may be ok, that does make me wonder; is this approach too complicated?  If you and I are uncertain about it, then what about future users - will they be comfortable with it?  I had to look up which Boolean operator applied with multiple bases!

Separately, having persuaded my obstructionist ESP to let me send an e-mail, I see a number of quirks in the English of layer1-types.  Are you interested in hearing about them? (assuming that my ESP lets me:-)

Tom Petch

You can check initial changes to ETH-1GbE, FICON-4G and STM-1 identities in github:

https://github.com/haomianzheng/IETF-ACTN-YANG-Model/pull/65

Let me report here the key ones:

  identity ETH-1Gb {
    base client-signal;
    description
      "Client signal type of 1GbE";
    reference "RFC7139/ITU-T G.709";
  }

  identity FICON-4G {
    base client-signal;
    description
      "Client signal type of Fibre Connection 4G";
    reference "RFC4328/RFC7139";
  }

  identity ETH-1000X {
    base "coding-func";
    base Ethernet;
    description
      "1000BASE-X PCS clause 36 coding function.";
    reference "MEF63: Subscriber Layer 1 Service Attributes";
  }

  identity STM-1 {
    base client-signal;
    base "coding-func";
    base SDH;
    description
      "STM-1 client signal;
       STM-1 G.707 (N=1) coding function.";
    reference
      "RFC7139/ITU-T G.709
       MEF63: Subscriber Layer 1 Service Attributes";
  }

              leaf client-signal {
                type identityref {
                  base "l1-types:client-signal";
                }
                mandatory true;
                description
                  "The client signal being used at the UNI";
              }

Then ETH-1GbE, FICON-4G and STM-1 would be valid configuration for the client-signa leaf, while ETH-1000X will not be valid

    leaf coding {
      type identityref {
        base "l1-types:coding-func";
      }
      must 'derived-from(../coding, ../protocol)';
      mandatory true;
      description "The coding function being used at the UNI.";
    }

Then:
- ETH-1000X would be valid configuration of the coding leaf, if Ethernet is configured, otherwise it is invalid;
- STM-1 would be valid configuration of the coding leaf, if SDH is configure as protocol, otherwise it is invalid;
- ETH-1GbE and FICON-4G would never be valid configuration of the coding leaf

Before applying these changes to a lot of identities, it would be good to check that our understanding is correct

What do you think?

Thanks in advance

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: Italo Busi <[email-masked]>
Date: Fri, 5 Jun 2020 17:13:52 +0000

Hi Tom,

Thanks for raising this point

If the proposal works as I guess, I think the solution would be much simpler than:
- avoiding to define two set of identities with different bases but with a lot of overlaps;
- defining the consistency between different leaves of type identityrefs in the text rather than in YANG. 

However, some text to clarify how this would work needs to be added to the draft.

Is there any opinion/feedback from YANG experts?

If none, do you know who we can ask for help?

Any suggestion to improve the English text in the draft is more than welcome.

Thanks, Italo

> -----Original Message-----
> From: tom petch [mailto:[email-masked]]
> Sent: venerdì 5 giugno 2020 13:12
> To: Italo Busi <[email-masked]>; Rob Wilton (rwilton)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-ccamp-
> [email-masked]
> Subject: Re: [CCAMP] Question about identities with multiple bases
> 
> We have discussed an open issue with the ietf-l1csm which is impacting the
> ietf-layer1-types YANG model, for which we are addressing CCAMP WG LC
> comments
> 
> Since we have not much experience with identities having multiple bases, we
> would like to get a feedbacks from you about whether the proposed solution
> would work <tp> Italo
> 
> I have not seen a response to your question.  I had a look and it seems ok but
> like you I do not see much of this construct in IETF modules.
> 
> So while it may be ok, that does make me wonder; is this approach too
> complicated?  If you and I are uncertain about it, then what about future users
> - will they be comfortable with it?  I had to look up which Boolean operator
> applied with multiple bases!
> 
> Separately, having persuaded my obstructionist ESP to let me send an e-mail, I
> see a number of quirks in the English of layer1-types.  Are you interested in
> hearing about them? (assuming that my ESP lets me:-)
> 
> Tom Petch
> 
> 
> 
> Then ETH-1GbE, FICON-4G and STM-1 would be valid configuration for the
> client-signa leaf, while ETH-1000X will not be valid
> 
>     leaf coding {
>       type identityref {
> 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: tom petch <[email-masked]>
Date: Mon, 8 Jun 2020 10:22:14 +0000

From: Italo Busi <[email-masked]>
Sent: 05 June 2020 18:13
Hi Tom,

The problem is that I can look at the YANG and say yes, it looks valid but I have no idea what you are trying to do:-)  I am reverse engineering the YANG to make a guess and that is no validation.  So, what is the requirement?

I am acquainted with MEF 63 but your terminology is not quite the same and I am unclear if that is because the concepts you are describing are the same or not.

If the requirements are clear, then yes, I know where I would go to ask how to do it in YANG,

Tom Petch

Thanks, Italo

> ____
> __________________

---

From: tom petch <[email-masked]>
Date: Mon, 8 Jun 2020 11:02:21 +0000

From: CCAMP <[email-masked]> on behalf of tom petch <[email-masked]>
Sent: 08 June 2020 11:22
To: Italo Busi; Rob Wilton (rwilton)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] Question about identities with multiple bases

<tp>
An independent issue.

The YANG has references to RFC4230 RFC4328 they need to be added to the I-D References

ITU-T are not unique without a date;  the I-D References gets this right but the YANG module generally does not as with G.709 G.sup43 G.7044 which mostly lack dates

I would not update the I-D just to fix these.

Tom Petch

Tom Petch

Thanks, Italo

> the right to lodge a complaint with the competent supervisory authorities.. If

_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp