Re: [CCAMP] 答复: Webex meeting changed: Optical impairments draft

Dieter Beller <Dieter.Beller@nokia.com> Tue, 10 November 2020 11:34 UTC

Return-Path: <dieter.beller@nokia.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 253693A1146; Tue, 10 Nov 2020 03:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.801
X-Spam-Level:
X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 B_Ifl39IDCn1; Tue, 10 Nov 2020 03:34:48 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2120.outbound.protection.outlook.com [40.107.21.120]) (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 C9D733A0D64; Tue, 10 Nov 2020 03:34:17 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Axj3l8YGaAOT2nwLvrjA3c7enQamiborYs4RfTH1OxGc7MpgrPNqLMGqUk1cBaj6RSYXPXChoTLfSro6R+W0bvyG5U/gyYOpHc/gCIPM3GFr+OB1qj29JY0a7jAwGvRTjQ/Vij3pB6tik9n6f3imt5y+fs/g9dI0lH+2kmh9r18Ah+F1KP9/YC2WZUlOgzwJfux9AEhCpIEY5+YDluyfZAo+XvtCUoG8AKIn7kUYoV0IIyMW2KK/sbsCURipIrxaMWXUx3Yo//vMDftllDpmfyMg2DMp/q2hWE8oWI4vWebvraej8OrCQtKWHLu3rNIZwHbI7H1PhLkPAtVdt8MjpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ihcSYI795tetjcKFfhiWcVPlifKeJlM53BOt+WQqftE=; b=FkZNFA0xFr+Z/rpKWAxxjvUsMbDdaEabBFUzSGZ9hZUcPcLpNK0JpSJHvF60MDUiFqHGXEQ0nnoa5V3i+IfKICq7z2+2GFUnP754siVFGaqG/uyzXP8F0HrnSlixn32YK5Ru5ITWDM6EKT3Sw7meMT9E+lIBl/6yyKWcR6Eg3q80+mQErybpcHlNCYYpFjPNkXDfbKA769/I1LU/hTRvHKRrDcpSQk7hUV4gjrE23FrD8iuiZnPGsY6KxUthQPZAgLlabYUZBQ/J/3touiR4mAaHhMlJVOCZx/UsmM7i8Ij/VabiWt57EbAfruBDxYZlQLM0mGSB6tWJcsjlPW+EWw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ihcSYI795tetjcKFfhiWcVPlifKeJlM53BOt+WQqftE=; b=WS6JXWeY7Mm8onQ2318BkVYxP5qfnu4hIUYUhdQiL9SYbxzqOKLa+Qkgps7Vn1ZrF3uz0rTbZLTuoj8k7fOFpjxYu7oJazEZDuAxTz/9s9YcXWY9+WLsdr5wYiwTP0Pb3cTdYVH7tnWLS1YxXghEYiexVqGagzSYXp2oSz7t4j0=
Authentication-Results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=nokia.com;
Received: from AM7PR07MB6788.eurprd07.prod.outlook.com (2603:10a6:20b:1be::14) by AM6PR07MB4040.eurprd07.prod.outlook.com (2603:10a6:209:33::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.13; Tue, 10 Nov 2020 11:34:14 +0000
Received: from AM7PR07MB6788.eurprd07.prod.outlook.com ([fe80::9444:9b92:5e0f:4971]) by AM7PR07MB6788.eurprd07.prod.outlook.com ([fe80::9444:9b92:5e0f:4971%7]) with mapi id 15.20.3564.021; Tue, 10 Nov 2020 11:34:14 +0000
To: Gert Grammel <ggrammel@juniper.net>, Fatai Zhang <zhangfatai@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Italo Busi <Italo.Busi@huawei.com>, "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
References: <8F544027-DF1B-41B0-8C27-75093878FA33@juniper.net>
From: Dieter Beller <Dieter.Beller@nokia.com>
Organization: Nokia
Message-ID: <5e306712-9544-b6e9-d4c6-a7ac6424bb7e@nokia.com>
Date: Tue, 10 Nov 2020 12:34:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.1
In-Reply-To: <8F544027-DF1B-41B0-8C27-75093878FA33@juniper.net>
Content-Type: multipart/alternative; boundary="------------58E4ADA09379623E1AF67227"
Content-Language: en-US
X-Originating-IP: [88.152.185.31]
X-ClientProxiedBy: PR0P264CA0147.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::15) To AM7PR07MB6788.eurprd07.prod.outlook.com (2603:10a6:20b:1be::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.18.11] (88.152.185.31) by PR0P264CA0147.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1b::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21 via Frontend Transport; Tue, 10 Nov 2020 11:34:13 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 928b4168-aa23-47b4-d706-08d8856c8cdd
X-MS-TrafficTypeDiagnostic: AM6PR07MB4040:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM6PR07MB40405998EE9ABCFB27230538E2E90@AM6PR07MB4040.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: tC0gkvWepJtjUYzo+/KMuSyVROH60DtTFJm/ejVnHVVu6UlPaYX3Abszan0jXE5z9p1bNMOuTVvJIKbrQt4W9qn68uQ12QnvmUQtmKAVeOwXqj9gyF/pftX4iyv1klgM/hIQsms5ekQPz5zKjS7x4Q8BnYsbl772zfG8nlEWBr7vJ8OCUPDcQo7Le7indulU5yGwPRv+vSCeIEHuTuRT6Ro3foX3Tu3Jl8o6yCgCIlp9PSZeCL43JMQBowmqUOP94vRTOc62XHLJJaRdWczroUO7c8zMjUZOXWmgGu/4Lyu64fDsqmNDC5VuHu+3Qti7LQK7lTAWr9peMqKf1imOcVFBDj0oQKas4tCeruGa3R70YZHJCrbAFEsOXaGoaNmtTpMXXfDtucE/R6h056U3rOLnoI993kEhx4zFqhjn2DEzkcuW8hMkKQD6Oo+Qk+jUt1fNOSCOEnTonajCjpE3lg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6788.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(136003)(346002)(396003)(376002)(39860400002)(36756003)(110136005)(5660300002)(31696002)(4326008)(30864003)(53546011)(2906002)(316002)(16576012)(166002)(83380400001)(33964004)(956004)(8936002)(6486002)(66556008)(478600001)(16526019)(31686004)(2616005)(186003)(966005)(86362001)(66476007)(107886003)(66946007)(26005)(36916002)(224303003)(43740500002)(579004)(559001); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: RGLciy6ncRIF6Pt3TQLD/jxa8S6Flgtti4rYvb8N87B2EqOATsPXIjxSBI4ylvXWnmfUAnMMRWw/uBb9yEvlmN57CX3Y8dmU5GJDa84mIwgzysc/DJ3cJkh+ye2XLvIY9XFkPf/PQL7gJulSaL06XnMmbrMu0gMh++Okn0vnxeTPlY7AsEZ5kmir4+IngnHqeFov+MFPIzTMC3sSVp9zo1rg3rbwdv6NSu9MwnmdDYA9zOrjE1jFB61byS3baRltHmoWt9Xa8JGIwp1OqzuHslXRVYFT9fYAXDKnyAeK/X94ExFXUYF2BC/7REWUUHEDpZGcfGE6MUnTXomkIZbj/P3tVKfMkUm36ea7VqX3dS3V990C8UIDGWlsPV7Oy4iPVQmDVy6moAAbVOhIkj9aevqvkPcgyDm3s3498PmN4KGL0vH+IRSHAePzwxa9LInKtDYbBYOr35tsnBxyqhlrBwV3/PgjGFZeH13YS4Azx7IfhV1879hqX+t7Do9XM3reEP8OUrEOk0VCKT+32Ehws7o05QPnTFK6YmmYNPnwOozzNQwYKloDGHEIEnkIyNEWWNPZxKGgZ0lRrrzfOKawlyBxVEdADyXjxk8WqwpY3fEL+zT8bijxFvpYRtcpALX+7gs0kkinS8TGaYijZj+X/znEyQ610q83jsWEODJVMEWme74TKvCTGR4ExLujS8Zq4rKZWHjE2ZLFzSzSj7ZXACrkTOCf6vsrLCqeI3vZp7+Cyhj2S3RjCt66wtzK3BNNd850eZ7go7OKdXGoSioFzU/x0kvQclj1dR+rfmwH4Mn/VwfV6swKhKDV4vPnrSH0/JY0qHHrrTw653h9gtGWwsaG9wMBSU1Ch5Kc38TGy8R8P8tB2Y1GVdkeJ4Jp0rgD382zKr0O0MqzDAfMCns30Q==
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 928b4168-aa23-47b4-d706-08d8856c8cdd
X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6788.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2020 11:34:14.1316 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: l4B0RQpp6I01an6vSrfMK6nRb1kXXnAxIgPble5j0jkNdjWkQPwriuA498/elYVnkHiuKntO4mD49HWwY9J7gg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4040
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/xSk5f3c8WUfEbO2_K-as3bLYpZY>
Subject: Re: [CCAMP] =?utf-8?b?562U5aSNOiAgV2ViZXggbWVldGluZyBjaGFuZ2VkOiBP?= =?utf-8?q?ptical_impairments_draft?=
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: Tue, 10 Nov 2020 11:34:54 -0000

Hi Gert, all,

there has been consensus to support the 3 options as currently defined 
in the YANG model (see 
https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang).

Stating that the organizational-mode option is under discussion is 
passing a wrong message to the CCAMP WG!

The situation is the following: there is rough consensus that the 
organizational-mode option is valuable and there is only one single 
person continuously disagreeing because of another
preference.


Thanks,
Sergio and Dieter


On 10.11.2020 11:09, Gert Grammel wrote:
>
> Hi Fatai,
>
> The group managed to find agreement on the Application code and the 
> explicit mode whereas Organizational codes are under discussion. In 
> essence, the question is whether non-standard organizations can define 
> their own codes along the same lines as ITU-T did (case-A) or if 
> additional parameters need to be made explicit (case-B).
>
> Regards
>
> Gert
>
> *From: *Fatai Zhang <zhangfatai@huawei.com>
> *Date: *Friday, November 6, 2020 at 08:01
> *To: *Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>om>, Italo Busi 
> <Italo.Busi@huawei.com>om>, Gert Grammel <ggrammel@juniper.net>et>, 
> "ccamp-chairs@ietf.org" <ccamp-chairs@ietf.org>rg>, CCAMP <ccamp@ietf.org>
> *Cc: *Dieter Beller <Dieter.Beller@nokia.com>
> *Subject: *答复: [CCAMP] Webex meeting changed: Optical impairments draft
>
> *[External Email. Be cautious of content]*
>
> Hi all,
>
> I think there are too many options (three!) , which introduces too 
> much flexibility and complexity to this document and the real world.
>
> If “only application codes” can work, why the others are necessary?
>
> I think we can try if we could keep only one option and remove the 
> other options to keep it simple , because we could treat e.g., 
> “organization mode” as proprietary implementation since it is really 
> proprietary  among some organization.
>
> Thanks
>
> Fatai
>
> *发件人:*Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> *发送时间:* 2020年11月2日 23:51
> *收件人:* Italo Busi <Italo.Busi@huawei.com>om>; 'Gert Grammel' 
> <ggrammel@juniper.net>et>; ccamp-chairs@ietf.org; ccamp@ietf.org
> *抄送:* Dieter Beller <Dieter.Beller@nokia.com>
> *主题:* RE: [CCAMP] Webex meeting changed: Optical impairments draft
>
> Hi,
>
> Sorry to jump in but I’m having hard times to understand what the 
> issue is. What is wrong with the actual modes? I asked if it was 
> possible to merge 2 of them and go down to 2 but it was proven not 
> possible.
>
> Moreover this is no longer just author’s agreement since the draft is 
> a WG document.
>
> What italo says below is correct. We decided that all the modes are 
> optional, hence the model needs to be self-consistent and all 
> permutations should be allowed.
>
>
> But once again, it’s not clear to me what the issue is, could you 
> please elaborate it a bit?
>
> Cheers,
>
> Daniele
>
> *From:* Italo Busi <Italo.Busi@huawei.com <mailto:Italo.Busi@huawei.com>>
> *Sent:* den 2 november 2020 12:42
> *To:* 'Gert Grammel' <ggrammel@juniper.net 
> <mailto:ggrammel@juniper.net>>; ccamp-chairs@ietf.org 
> <mailto:ccamp-chairs@ietf.org>; ccamp@ietf.org <mailto:ccamp@ietf.org>
> *Cc:* Dieter Beller <Dieter.Beller@nokia.com 
> <mailto:Dieter.Beller@nokia.com>>
> *Subject:* RE: [CCAMP] Webex meeting changed: Optical impairments draft
>
> Hi Gert,
>
> Just an high level comment: the initial agreement between the 
> co-authors was that to define three modes (application code, 
> organization mode and explicit mode) all as being optional.
>
> Therefore, IMHO, the YANG model for each mode should be 
> self-consistent to give implementers the freedom to implement either:
>
>   * Only application codes
>   * Only organization modes
>   * Only explicit modes
>   * Both application codes and organization modes
>   * Both application codes and explicit modes
>   * Both organizational modes and explicit modes
>   * All options (application code, organizational mode and explicit mode)
>
> Please find some detailed comments of mine in line below.
>
> My 2 cents
>
> Italo
>
> *From:* Gert Grammel [mailto:ggrammel@juniper.net 
> <mailto:ggrammel@juniper.net>]
> *Sent:* domenica 1 novembre 2020 12:02
> *To:* ccamp-chairs@ietf.org <mailto:ccamp-chairs@ietf.org>; 
> ccamp@ietf.org <mailto:ccamp@ietf.org>
> *Cc:* Dieter Beller <Dieter.Beller@nokia.com 
> <mailto:Dieter.Beller@nokia.com>>; Italo Busi <Italo.Busi@huawei.com 
> <mailto:Italo.Busi@huawei.com>>
> *Subject:* Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
> It would be good to tune the heat of the down by a few centigrade. Why 
> spending time writing definitions, getting agreement  and rewriting 
> again in less than 24h?  The core of the discussion is where to hang 
> parameters in a YANG-tree in a consistent manner. How exciting is this?
>
> The minimum we should strive for in IETF is to come up with a 
> consistent model. To do so, it is good engineering practice to first 
> agree on the problem. That said, I am happy that apparently the Case-A 
> and Case-B description laid out in my previous mail turned out not to 
> be contentious.
>
> About the issue of “organizational mode”:
>
>  1. Case-A: AFAIK the most common and Transponder Model today is
>     OpenConfig, which uses a single identifier for the
>     operational-mode. The use is simple because it can be used as a
>     matching criteria to make sure the two transponders at each end
>     interoperate (given the OLS is within spec).
>  2. Case-B: proposes a series of additional criteria that must be met
>     by adding explicit parameters such as frequency range, power-range
>     etc. So the simple matching rule is no more sufficient and
>     additional parameters must be checked to assess compatibility.
>
> I think it is a fair ask to hear from the CCAMP-WG if we are happy to 
> ditch the OpenConfig way and  implement Case-B.
>
> //
>
> /[[Italo Busi] ] I am not an expert of OpenConfig but Dieter has 
> already confirmed that the latest definition in github 
> (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=44077b9a-1b9c42d9-44073b01-861fcb972bfc-e503d80e6efd81dd&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1dV-vxg_$>) 
> is aligned with existing implementations (I assume, based on his 
> working experience, he was also considering OpenConfig implementations)./
>
> //
>
> /Anyhow, OpenConfig experts can provide their comments on this 
> definition, if they think it is not correct./
>
> About the issue of “where to put the explicit parameters”:
>
>  1. Case-A: puts all explicit parameters in the explicit mode and
>     provides a leafref to Organizational modes. Explicit min/max
>     parameters can be liked to an Organizational mode by referencing
>     the organizational mode from the explicit mode. Organizational
>     modes continue to be used just like Application codes as a
>     matching condition.
>
> *//*
>
> /[[Italo Busi] ] The references between the explicit mode and the 
> application code/organization modes have been added as informative to 
> represent the fact that an explicit mode can support zero, one or more 
> application codes and/or zero, one or more organization modes. It was 
> not intended to provide additional information wrt the application 
> code or organization mode definitions and I think it should not be 
> used in that way to avoid creating inconsistencies (see comment below)./
>
>  2. Case-B: puts a subset of the parameters also defined in the
>     explicit mode into the Organizational mode. By doing so we now
>     have duplicated parameters in operational and explicit mode.
>
> Structurally this creates a conflict, because it is not clear which 
> definition takes precedence in a matching condition. It is this 
> structural issue we need to address to move forward.
>
> /[[Italo Busi] ] I think you have spotted a potential technical issue 
> with the current definition of the leafref between an explicit mode 
> and an application code or organization mode but this is independent 
> from the fact that explitic parameters are defined or not for the 
> application mode./
>
> /This inconsistency could apply also to parameters that are implicitly 
> defined by the organization mode (or even by an application code). For 
> example, the YANG model allows an explicit mode which supports one 
> type of FEC to claim support of an application code or of an 
> organization model which (implicitly) requires a different type of FEC./
>
> /If the client requests the interface to operate according to a given 
> application code or organization mode, I think that the expectation is 
> that the FEC defined for that application code or organization mode is 
> being used./
>
> //
>
> /I think to resolve this issue we should either clarify the rules an 
> implementation MUST follow to avoid reporting inconsistent information 
> or some precedence rules (considering both implicit and explicit 
> parameters) or remove the leafref./
>
> About the parameter set of the “Organizational mode”:
>
>  1. Case-A: allows to use any set of explicit parameters to add more
>     information to organizational modes as a reference
>
> //
>
> /[[Italo Busi] ] The YANG model for application codes and organization 
> modes should be self-consistent to supports implementations that do 
> not implement the explicit-mode. Moreover, using the leafref to 
> provide more information would be a potential source of inconsistency 
> (see comment above)/
>
>  2. Base-B: allows a small subset of parameters to be used to further
>     define the organizational mode. This set is fixed as described in
>     case-B.
>
> As the selection criteria for the set of parameters has not been 
> disclosed, it is difficult to understand whether the list remains such 
> short or is growing much longer over time. It would be good to get the 
> sense of the WG on that aspect too.
>
> /[[Italo Busi] ] According to the latest definition in github 
> (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=c4b9f9f1-9b22c0b2-c4b9b96a-861fcb972bfc-7ad4277e89b62b88&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1TYJhR0h$>) 
> the current list is complete./
>
> //
>
> /Those who have implemented organization modes (including OpenConfig 
> experts) can provide their comment if they think this list is not 
> complete./
>
> //
>
> Cheers
>
> Gert
>
> *From: *CCAMP <ccamp-bounces@ietf.org <mailto:ccamp-bounces@ietf.org>> 
> on behalf of Dieter Beller <Dieter.Beller@nokia.com 
> <mailto:Dieter.Beller@nokia.com>>
> *Organization: *Nokia
> *Date: *Saturday, October 31, 2020 at 10:28
> *To: *Italo Busi <Italo.Busi@huawei.com 
> <mailto:Italo.Busi@huawei.com>>, "ccamp-chairs@ietf.org 
> <mailto:ccamp-chairs@ietf.org>" <ccamp-chairs@ietf.org 
> <mailto:ccamp-chairs@ietf.org>>, CCAMP <ccamp@ietf.org 
> <mailto:ccamp@ietf.org>>
> *Subject: *Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
> *[External Email. Be cautious of content]*
>
> Thanks, Italo, for your contribution to the technical discussion!
>
> I would like to emphasize that the text on GitHub ( see 
> https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150 
> <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=2c758499-73eebdda-2c75c402-861fcb972bfc-3975d7433728ea76&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1W1fns7e$>) 
> tries
> to provide the technical justification for the modeling approach taken 
> for the organizational mode option - here is the text, which was 
> referenced in Italo's mail:
>
> *Organizational Mode:*
> Organizations like operator groups, industry fora, or equipment 
> vendors can define organizational modes, which will allow these 
> organizations to make use of advanced transceiver capabilities going 
> beyond existing standardized application codes. Such an organizational 
> mode is identified by the organization-identifier attribute defining 
> the scope and an operational-mode that is meaningful within the scope 
> of the organization. Hence, the two attributes must always be 
> considered together. Two transceivers are inter-operable, if they have 
> at least one (organization-identifier, operational-mode) pair in 
> common and if the supported carrier frequency and power attributes 
> have a matching range. This is a necessary condition for path 
> computation in the context of organizational modes. An operational 
> mode is a transceiver preset (a configuration with well-defined 
> parameter values) subsuming several transceiver properties including:
> • FEC type
> • Modulation scheme
> • Encoding (mapping of bit patterns to symbols in the constellation 
> diagram)
> • Baud rate (symbol rate)
> • Carrier bandwidth (typically measured in GHz)
>
> The major reason for these transceiver presets is the fact that the 
> attribute values typically cannot be configured independently and are 
> therefore advertised as supported operational mode capabilities.
> It is the responsibility of the organization to assign operational 
> modes and to ensure that operational modes are unique and not 
> ambiguous within the scope of the organization.
> In addition to the transceiver properties subsumed by the operational 
> mode, optical power and carrier frequency related properties are 
> modeled separately, i.e., outside of the operational mode. This 
> modeling approach allows transponders using different transceiver 
> variants (e.g. optical modules) with slightly different power and/or 
> frequency range properties to interoperate without defining separate 
> operational modes. Different optical modules (pluggables) from 
> different suppliers typically have slightly different input and output 
> power ranges or may have slightly different carrier frequency tuning 
> ranges.
> The received channel power and the received total power are two 
> parameters that can be measured by the receiver and can be provided by 
> the transceiver in order to allow a controller to determine the 
> expected performance of the end-to-end service taking into account the 
> optical impairments along the path.
>
>
> Moreover, implementations exist that are based on the same modeling 
> approach and hence it is *already field proven!*
>
>
> Thanks,
> Dieter
>
> On 30.10.2020 17:14, Italo Busi wrote:
>
>     Hi Gert,
>
>     Let me try to look at this issue from a different perspective.
>
>     I think the objective of our work is to define a YANG model for
>     the optical specification methodologies which are used in the
>     field to represent the capabilities of the transponders.
>
>     I do not think that it is in the scope of our work to discuss the
>     optical specification methodologies other than understanding how
>     they could be used for path computation (ensuring interoperability
>     between the sender and receiver) and modelled using YANG.
>
>     As far as I have understood from past discussion, we have agreed
>     to support three optical specification methodologies which are
>     used by existing optical interfaces implementations and we have
>     named them as application code (ITU-T G.698.2), organizational
>     mode and explicit mode.
>
>     After some rounds of discussions and questions for clarification,
>     the latest proposed text to describe the behavior of the
>     organization mode has been prepared on github:
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29#issuecomment-719503150
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=fe2bb22f-a1b08b6c-fe2bf2b4-861fcb972bfc-7c29789e806b744e&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29*23issuecomment-719503150__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1RUYzMO4$>
>
>     I think this updated description has improved the clarity of how
>     the operational mode are implemented and, in particular that:
>
>     "Two transceivers are inter-operable, if they have at least one
>     (organization-identifier, operational-mode) pair in common and if
>     the supported carrier frequency and power attributes have a
>     matching range."
>
>     As a consequence, I think that the YANG model defined in "Case A"
>     below does not work (since it does not provide enough information
>     to check that " the supported carrier frequency and power
>     attributes have a matching range ") while the one defined in "Case
>     B" works properly.
>
>     This text describing the operational mode behavior has been
>     provided by people who have implemented it.
>
>     Therefore, I think we can update the draft with the changes
>     discussed in the last few weeks incorporating the definitions
>     capturing our current understanding of how these optical
>     specification methodologies (application code, organizational mode
>     and explicit mode) behave and the YANG model aligned with our
>     current understanding (i.e., based on "Case B" below).
>
>     Since we are not yet in WG LC stage, we still have plenty of time
>     to update both the description and the YANG model based on the
>     feedbacks we receive from data plane experts.
>
>     My 2 cents
>
>     Italo (as co-author of the draft)
>
>     -----Original Message-----
>
>     From: Gert Grammel [mailto:ggrammel@juniper.net
>     <mailto:ggrammel@juniper.net>]
>
>     Sent: giovedì 29 ottobre 2020 17:34
>
>     To: ccamp-chairs@ietf.org <mailto:ccamp-chairs@ietf.org>;
>     ccamp@ietf.org <mailto:ccamp@ietf.org>
>
>     Subject: Re: [CCAMP] Webex meeting changed: Optical impairments draft
>
>     We discussed today a difference in the interpretation of the model
>     related to
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=30d0fc94-6f4bc5d7-30d0bc0f-861fcb972bfc-5d5353826774237a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*2F29__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1eeOzXrI$>
>     and its interpretation. The different interpretation lead to
>     different computation requirements.
>
>     The design team appreciates feedback which of both Cases is
>     preferred and what consideration led to the preference
>
>     Case A:
>
>     ======
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues#issuecomment-677768528
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=af80a102-f01b9841-af80e199-861fcb972bfc-509d8509e721d1cb&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fissues*23issuecomment-677768528__;JSUlJSUlJQ!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1fp5UCUX$>
>     from August 20 documented the structure of the model:
>
>     +--ro supported-modes* [mode-id]
>
>           +--ro mode-id
>
>           +--ro (mode)?
>
>           |  +--:(G.698.2)
>
>           |  |  +--ro standard-mode?                standard-mode
>
>           |  +--:(organizational-mode)
>
>           |  |  +--ro operational-mode?             operational-mode
>
>           |  |  +--ro organization-identifier?      vendor-identifier
>
>     ➢|  +--:(explicit-mode)
>
>     ➢|    +--ro supported-standard-mode*? leafref
>
>           |     +--ro modulation-types                   identityref
>
>           |     ......
>
>     This snippet would allow to use standard mode or operational mode
>     as a simple matching criteria for compatibility i.e. two
>     transponders with Operational-mode=X and suitable line parameters
>     would interoperate.
>
>     In case of “explicit” mode, the set of parameters provided, can
>     support one or more application code/organizational mode, that
>     means this set of parameters if applied to configure the
>     transceiver, is aligned with one or more application
>     code/organizational mode.
>
>     (Note that there are no additional parameters associated to the
>     organizational mode in this case)
>
>     Case B:
>
>     ======
>
>     https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/blob/master/ietf-optical-impairment-topology.tree
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=dacf1e95-855427d6-dacf5e0e-861fcb972bfc-13a67d7f67153c4a&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Fgithub.com*2Fietf-ccamp-wg*2Fdraft-ietf-ccamp-optical-impairment-topology-yang*2Fblob*2Fmaster*2Fietf-optical-impairment-topology.tree__;JSUlJSUlJSU!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1ToD0jv4$>
>     contains additional parameters to the Operational Mode that are
>     also replicated in the explicit mode. Those parameters are related
>     to the min/max ranges which are allowed.
>
>       +--ro supported-mode* [mode-id]
>
>                     +--ro mode-id                      string
>
>                     +--ro (mode)
>
>                        +--:(G.698.2)
>
>                        |  +--ro standard-mode?         standard-mode
>
>                        +--:(organizational-mode)
>
>                        |  +--ro organizational-mode
>
>                        |     +--ro operational-mode?
>
>                        |     |       operational-mode
>
>                        |     +--ro organization-identifier?
>
>                        |     |       organization-identifier
>
>                        |     +--ro min-central-frequency?
>
>                        |     |       frequency-thz
>
>                        |     +--ro max-central-frequency?
>
>                        |     |       frequency-thz
>
>                        |     +--ro minimum-channel-spacing?
>
>                        |     |       frequency-ghz
>
>                        |     +--ro tx-channel-power-min?      dbm-t
>
>                        |     +--ro tx-channel-power-max?      dbm-t
>
>                        |     +--ro rx-channel-power-min?      dbm-t
>
>                        |     +--ro rx-channel-power-max?      dbm-t
>
>                        |     +--ro rx-total-power-max?        dbm-t
>
>                        +--:(explicit-mode)
>
>                           +--ro explicit-mode
>
>                              +--ro supported-modes
>
>                              |  +--ro supported-application-codes*
>
>                              |  |       -> ../../mode-id
>
>                              |  +--ro supported-organizational-modes*
>
>                              |          -> ../../mode-id
>
>                              +--ro line-coding-bitrate?
>
>                              |       identityref
>
>                          <snip>
>
>                              +--ro min-central-frequency?
>
>                              |       frequency-thz
>
>                              +--ro max-central-frequency?
>
>                              |       frequency-thz
>
>                              +--ro minimum-channel-spacing?
>
>                              |       frequency-ghz
>
>                              +--ro tx-channel-power-min?
>
>                              |       dbm-t
>
>                              +--ro tx-channel-power-max?
>
>                              |       dbm-t
>
>                              +--ro rx-channel-power-min?
>
>                              |       dbm-t
>
>                              +--ro rx-channel-power-max?
>
>                              |       dbm-t
>
>                              +--ro rx-total-power-max?
>
>                                      dbm-t
>
>     In this case, interoperability can only be provided if the
>     organizational code on each side match AND all other explicit
>     parameters defined in the organizational-code have a matching range.
>
>     (Note that min/max parameters are associated to the organizational
>     mode AND to the explicit mode in this case)
>
>     Juniper Business Use Only
>
>     _______________________________________________
>
>     CCAMP mailing list
>
>     CCAMP@ietf.org <mailto:CCAMP@ietf.org>
>
>     https://www.ietf.org/mailman/listinfo/ccamp
>     <https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=e2f70c1c-bd6c355f-e2f74c87-861fcb972bfc-c52544a2ca4d215d&q=1&e=acdb6ee5-5f1d-46c2-9f88-0c7a7270ed91&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fccamp__*3B*21*21NEt6yMaO-gk*21Qf7o1-a2YfLkPqzntQzH4eVYGLpUDj-1ysELXfiLRhkWu-G-RrJBibxJipiVa6Bx*24__;JSUlJSUlJSUlJSUlJSUl!!NEt6yMaO-gk!VUTkZYjr1SzBsWUrTlUxd7xhsWsLrdP8W5TjoHhNmVPjChpludoTcqiy1bI5nQgy$>
>