Re: [CCAMP] POLLING on draft-ietf-ccamp-optical-impairment-topology-yang-05 Tue, 24 November 2020 08:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 674B83A19EC for <>; Tue, 24 Nov 2020 00:25:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.217
X-Spam-Status: No, score=-0.217 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i9z9EFsNy-VP for <>; Tue, 24 Nov 2020 00:25:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 55FFF3A19EA for <>; Tue, 24 Nov 2020 00:25:02 -0800 (PST)
Received: from (unknown [xx.xx.xx.67]) by (ESMTP service) with ESMTP id 4CgHBh6B9mz5wR8; Tue, 24 Nov 2020 09:25:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1606206300; bh=uOceQXnTYwoGSpxDyVqQcjFLFWLCd6GuvM1EgHLVQbA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=bnHW7FGufy3g6DGGuiRTBdgZGSiIKJ15n2+b4hntujKRt9D/xnU9csr3lQv77cfhY PCd16xSqP98WWGUpi24G/pALc3TGDSDAVZYv/GVbvYQw4Q78aTq8/I1HKfGLmNcqbO bvjweRltonvdP1BXz+o+hLELzO0+gpz6kw2RJydYA7bJFCIfrJRoSjwaHoCaMLX4Mi CKRDENUN0UetYdu4ayS+H05tlBqwyGUhbCaHlSG4QnlS7fy3VhfkNAdcq6KrkcR1QT AC0L7uUxpAad9XzJYgx2/ZIwsdXTGan2i9MSi1XO09C4sOKcmALT6WR4byc5rpOoWO xF5uCZ1gVxR0w==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by (ESMTP service) with ESMTP id 4CgHBh5BFqzDq7J; Tue, 24 Nov 2020 09:25:00 +0100 (CET)
From: <>
To: Daniele Ceccarelli <>, CCAMP <>
Thread-Topic: POLLING on draft-ietf-ccamp-optical-impairment-topology-yang-05
Thread-Index: Ada/R30fB1cf88FbSyOfxOZXNxaE3QC852AQ
Date: Tue, 24 Nov 2020 08:24:58 +0000
Message-ID: <BDD0E12FDA19534DA7B322C56B753E6D47F67BD8@OPEXCAUBM42.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C4_01D6C243.AC6FBE10"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [CCAMP] POLLING on draft-ietf-ccamp-optical-impairment-topology-yang-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 08:25:05 -0000

Dear Daniele, WG,


I am for option 1 or 2: for me the draft (model) is good as it is  but some
explanations (in the text) on the way it can be used could help
implementers. So far I have not identified cases that could not be covered.

I am not in favor to wait for option 3 to have our draft. Transponders not
covered by ITU are already deployed and implementers need a model that can
cover these cases already now. 

I am not in favor of option 4 : the first sentence is not reflecting what we
discussed in our meeting (not true in my understanding) and I do not
understand how removing parameters can help in any way to support modes with
extended range .








Esther Le Rouzic 
Chargée d'études en réseaux optiques 


+33 6 10 05 40 85





De : CCAMP [] De la part de Daniele Ceccarelli
Envoyé : vendredi 20 novembre 2020 16:09
À : CCAMP <>
Objet : [CCAMP] POLLING on


Hi WG,


This is a polling to follow up on the discussion we had during the IETF

The polling will be closed on Friday 27th 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. 



Daniele, Fatai.