Re: [CCAMP] POLLING on draft-ietf-ccamp-optical-impairment-topology-yang-05

julien.meuric@orange.com Mon, 23 November 2020 17:19 UTC

Return-Path: <julien.meuric@orange.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 219E43A02BC for <ccamp@ietfa.amsl.com>; Mon, 23 Nov 2020 09:19:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.219
X-Spam-Level:
X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 kCvoEbyZuRDc for <ccamp@ietfa.amsl.com>; Mon, 23 Nov 2020 09:19:07 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AAC3A0147 for <ccamp@ietf.org>; Mon, 23 Nov 2020 09:19:07 -0800 (PST)
Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4Cfv5P3lrhz10GT for <ccamp@ietf.org>; Mon, 23 Nov 2020 18:19:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1606151945; bh=mpc5V+vztVj7QBktFfPEA9DAusX3jduPbLfeZ/4ui5g=; h=Subject:To:From:Message-ID:Date:MIME-Version:Content-Type; b=lbbURvlisZUxUVRWYZ0ELMmqsA9k/CvJEZI2NX5zGgTLDKvBlbkxqWR1f3Nu3i8Tl aaLSJcDmW+qyx9Lo5BHVfKLYOW39h51n4/LkFNElhJvIbzLRnRKDlExHxZvZUIGMWE wZKTeUq2oN2nzpkJUxQ532JZy67lK9iVlh0otoONwrifspfj1oVkQ+f6CzsQeTEAKH JOL7USSS++85drQxq7a+x7GFD9KOI6L9h+bm8nYztCdcTeHirb0856He1nWW7fnPa8 zhwmdEtjoKZKagmLZaKulz4mVsa+/GwBU0tiDVYaX96IE8yNbjr/b90EKgq00DC4rr MgkC63RPcaYqw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4Cfv5P2qTMzDq7g for <ccamp@ietf.org>; Mon, 23 Nov 2020 18:19:05 +0100 (CET)
Received: from [10.192.150.201] (10.114.13.245) by exchange-eme6.itn.ftgroup (10.114.13.98) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 23 Nov 2020 18:19:05 +0100
To: ccamp@ietf.org
References: <HE1PR07MB4156F0B898311EE616B1424BF0FF0@HE1PR07MB4156.eurprd07.prod.outlook.com>
From: julien.meuric@orange.com
Organization: Orange
Message-ID: <b5f610e9-3d48-b336-cbdc-48c608b5f277@orange.com>
Date: Mon, 23 Nov 2020 18:18:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <HE1PR07MB4156F0B898311EE616B1424BF0FF0@HE1PR07MB4156.eurprd07.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms060505010402070607070907"
X-Originating-IP: [10.114.13.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/noSHHYzmoxV_lv5k5KnfMv9Nc8g>
Subject: Re: [CCAMP] POLLING on draft-ietf-ccamp-optical-impairment-topology-yang-05
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: Mon, 23 Nov 2020 17:19:09 -0000

Ciao Daniele, hi all,

I believe the way the draft is progressing is fine, which puts me on
option 1. If some holes are identified, I think option 2 is the typical
way to take care of them and I would be ready to support it.
Option 3 feels orthogonal: if it's progressed in parallel, the solution
from the I-D will be able to make use of the results, but I don't want
to bind the specification only to the output of that action.
I don't think what is proposed by the 1st sentence of option 4 is
necessary, and I don't understand how the 2nd sentence sustains the 1st
one...

Cheers,

Julien


On 20/11/2020 16:08, Daniele Ceccarelli wrote:
>
> Hi WG,
>
>  
>
> This is a polling to follow up on the discussion we had during the
> IETF session.
>
> *The polling will be closed on Friday 27^th November.*
>
>  
>
> Please indicate which option (more than one allowed) do you support.
> You can motivate why an option and why not another or share if you are
> aware of existing implementations.
>
>  
>
>   * Option 1: The draft is good as is today.
>   * Option 2: We need to add text specifying the use cases that we
>     want to cover. More precisely identify the cases that are outside
>     the scope of the solution proposed.
>   * Option 3: Contribute to ITU-T to have all the cases covered by
>     application codes.
>   * Option 4: Remove explicit parameters in the organizational-mode
>     because they are considered implicit parameters in the mode. This
>     allows to cover cases where the same mode is used for transceivers
>     that extend (but not limit) the operation range of a mode.
>
>  
>
> Thanks,
>
> Daniele, Fatai.
>
>
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp