Re: [CCAMP] Question about identities with multiple bases

Italo Busi <Italo.Busi@huawei.com> Fri, 05 June 2020 17:13 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38A73A0891; Fri, 5 Jun 2020 10:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogx78CU3ctKM; Fri, 5 Jun 2020 10:13:54 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62BB73A0884; Fri, 5 Jun 2020 10:13:54 -0700 (PDT)
Received: from lhreml730-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1E809B6FCFC542668FE7; Fri, 5 Jun 2020 18:13:53 +0100 (IST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 18:13:52 +0100
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 5 Jun 2020 19:13:52 +0200
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.1913.007; Fri, 5 Jun 2020 19:13:52 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: tom petch <ietfc@btconnect.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: "draft-ietf-ccamp-l1csm-yang@ietf.org" <draft-ietf-ccamp-l1csm-yang@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, "draft-ietf-ccamp-layer1-types@ietf.org" <draft-ietf-ccamp-layer1-types@ietf.org>
Thread-Topic: [CCAMP] Question about identities with multiple bases
Thread-Index: AQHWOyoiQkytytjGRQiDq8TRiq1jdKjKIX9Q
Date: Fri, 05 Jun 2020 17:13:52 +0000
Message-ID: <491dc6da5a8e4d9baf86330f97238a47@huawei.com>
References: <DBAPR07MB701667D98E6A9B2B6769FDF4A0860@DBAPR07MB7016.eurprd07.prod.outlook.com>
In-Reply-To: <DBAPR07MB701667D98E6A9B2B6769FDF4A0860@DBAPR07MB7016.eurprd07.prod.outlook.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.201.119.2]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/VqagzlksJfcX0pYLHavx5v7gkLE>
Subject: Re: [CCAMP] Question about identities with multiple bases
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp/>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2020 17:13:57 -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:ietfc@btconnect.com]
> Sent: venerdì 5 giugno 2020 13:12
> To: Italo Busi <Italo.Busi@huawei.com>; Rob Wilton (rwilton)
> <rwilton@cisco.com>
> Cc: draft-ietf-ccamp-l1csm-yang@ietf.org; ccamp@ietf.org; draft-ietf-ccamp-
> layer1-types@ietf.org
> Subject: Re: [CCAMP] Question about identities with multiple bases
> 
> From: CCAMP <ccamp-bounces@ietf.org> on behalf of Italo Busi
> <Italo.Busi@huawei.com>
> 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
> 
> [cid:image001.jpg@01D5AC11.9575BB40]
> ________________________________________________________________
> ____
> 
> Huawei Technologies Italia S.r.l.
> Address: Centro Direzionale Milano 2, Palazzo Verrocchio, 20090 Segrate (MI)
> Tel: +39 345 4721946 - Mobile:
> Italo.busi@huawei.com<mailto:Italo.busi@huawei.com>
> 
> ________________________________________________________________
> __________________
> 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: dataprotection@huawei.com<mailto:dataprotection@huawei.com>
> 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
> dpo@huawei.com<mailto:dpo@huawei.com>.The Data Controller is Huawei
> Technologies Italia S.r.l. with registered office in Milan, Via Lorenteggio 240
> Tower A, 20147.
> 
> 
>