[CCAMP]Re: WG adoption call on draft-tan-ccamp-fgotn-yang-06

Italo Busi <Italo.Busi@huawei.com> Wed, 30 September 2026 07:19 UTC

Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id 4FCBF42 for <ccamp@ietf.org>; Wed, 30 Sep 2026 07:19:50 +0000 (UTC)
Authentication-Results: mx.ietf.org; dkim=pass header.d=huawei.com header.s=dkim header.b=aNtJDq0t; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (mx.ietf.org: domain of Italo.Busi@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=Italo.Busi@huawei.com
dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=BJotJeEuEeiFbMKXSk3uBRpUj0YO6hBDBRIa8jDmwsI=; b=aNtJDq0tJnn5sGYBUxaqQrfo1YKip7jhqPd29hJxHxOpaHyBrUBNVIa8Ym7KO+CvLYE08xDGh n1Dg9rCLokFWv+PWd0ppr6u8gKjrYwFh27vPiNgSJ05GLHSd9pL+LYKgC4dODzV5lN03G6MP7fI jWyai4lA8mOX8oNIoSunKUQ=
Received: from mail.maildlp.com (unknown [172.18.224.150]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4hvmcg1WcGzHnGjM; Wed, 30 Sep 2026 15:18:59 +0800 (CST)
Received: from dubpeml100004.china.huawei.com (unknown [7.214.146.78]) by mail.maildlp.com (Postfix) with ESMTPS id 33AC440570; Wed, 30 Sep 2026 15:19:41 +0800 (CST)
Received: from dubpeml500004.china.huawei.com (7.214.147.1) by dubpeml100004.china.huawei.com (7.214.146.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.46; Wed, 30 Sep 2026 08:19:40 +0100
Received: from dubpeml500004.china.huawei.com ([7.214.147.1]) by dubpeml500004.china.huawei.com ([7.214.147.1]) with mapi id 15.02.2562.046; Wed, 30 Sep 2026 08:19:40 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Thread-Topic: [CCAMP]Re: WG adoption call on draft-tan-ccamp-fgotn-yang-06
Thread-Index: AQKxqX7Tiwo8Mv0l/JAWp55cZp5vzbScZkLwgEBcDCCAYUKWkA==
Date: Wed, 30 Sep 2026 07:19:40 +0000
Message-ID: <1361c23a14ea48ffb20470353c125058@huawei.com>
References: <CY8PR11MB73404CC005FB9D0A861A6D44D4E32@CY8PR11MB7340.namprd11.prod.outlook.com> <04fc01dcffe0$19efdee0$4dcf9ca0$@olddog.co.uk> <eaedc5bf2f4744d49f39f678c6fad585@huawei.com>
In-Reply-To: <eaedc5bf2f4744d49f39f678c6fad585@huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.154.213]
Content-Type: multipart/alternative; boundary="_000_1361c23a14ea48ffb20470353c125058huaweicom_"
MIME-Version: 1.0
X-Spamd-Bar: ---------
Message-ID-Hash: S47KTIAQKSHVAZN44JC2E2CDDI6OPIJL
X-Message-ID-Hash: S47KTIAQKSHVAZN44JC2E2CDDI6OPIJL
X-MailFrom: Italo.Busi@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-ccamp.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: 'CCAMP' <ccamp@ietf.org>
X-Mailman-Version: 3.3.10
Precedence: list
Subject: [CCAMP]Re: WG adoption call on draft-tan-ccamp-fgotn-yang-06
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/ajPne_AZZHgAHMjf7zZdt0Bddng>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ccamp>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Owner: <mailto:ccamp-owner@ietf.org>
List-Post: <mailto:ccamp@ietf.org>
List-Subscribe: <mailto:ccamp-join@ietf.org>
List-Unsubscribe: <mailto:ccamp-leave@ietf.org>

Hi Adrian,

We have just uploaded draft-ietf-ccamp-fgotn-yang-02 with the changes proposed to address your comments as discussed below

We are planning to expand the Manageability, Security, and IANA considerations in the future updates of the document

Yanxia and Italo (on behalf of co-authors/contributions)

From: Italo Busi <Italo.Busi@huawei.com>
Sent: giovedì 30 luglio 2026 12:19
To: adrian@olddog.co.uk
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: RE: [CCAMP]Re: WG adoption call on draft-tan-ccamp-fgotn-yang-06

Hi Adrian,

Thanks for your review and support of the draft

We have discussed your comments yesterday: please find our initial feedbacks in line below marked as [Authors]

Regarding the term "OTN network" we had a similar discussion with Dhruv on other drafts so it would be good to get into a common approach for all the OTN-related drafts/RFCs

See: https://mailarchive.ietf.org/arch/msg/ccamp/yIz26ZDNZN_Jg-ou9mcq26pNXYw/

FYI - we have created an open issue in github to track your comments while preparing for the next draft update:

Adrian WG adoption comments · Issue #48 · ietf-ccamp-wg/draft-ietf-ccamp-fgotn-yang<https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-fgotn-yang/issues/48>

Thanks, Italo (on behalf of co-authors/contributions)

From: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Sent: venerdì 19 giugno 2026 13:38
To: 'Daniele Ceccarelli (dceccare)' <dceccare=40cisco.com@dmarc.ietf.org<mailto:dceccare=40cisco.com@dmarc.ietf.org>>; 'CCAMP' <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP]Re: WG adoption call on draft-tan-ccamp-fgotn-yang-06

Hi chairs,

Thanks for this adoption poll.

Yes, the WG should have a document on this topic. And, yes, this draft is a good starting point. Please adopt it.

Cheers,
Adrian

===

Attention that is needed (*after* adoption).

Some problems with line lengths in Figure 3. This is easily fixed.

[Authors] We will fix the line lengths of Figure 3 in the next draft update

---

Obviously, the empty sections (11, 12, 13) need work.

[Authors] We are tracking these as open issues in github with the target to complete these sections before WG LC

---

The Abstract could us a short sentence to say what fine grain optical transport networks are.

[Authors] We would propose the following NEW abstract:

   Fine grain Optical Transport Network (fgOTN) is a data plane
   technology, specified in ITU-T Recommendation G.709/Y.1331 (2020)
   Amd. 3, which complements existing OTN by providing bandwidth
   efficient support for sub-1Gbit/s services.

   This document defines YANG data models to describe the topology and
   tunnel information of an fgOTN network.

[/Authors]

---

In 1.1, can you add references for fgTS and fgODUflex?

[Authors] We would propose the following change:

OLD

   Some of the key terms used in this document are listed as follow.

NEW

   The following terms are defined in [ITU-T_G.709] and in
   [ITU-T_G.709.20] and are not redefined here:

[/Authors]

---

Section 1.4 enthusiastically repeats section 1.2.

[Authors] We have already fixed it in draft-ietf-ccamp-fgotn-yang-01

---

Section 1.6 overlaps with section 1.3

[Authors] We have already fixed it in draft-ietf-ccamp-fgotn-yang-01

---

Watch out for "OTN network". The N in OTN already means network.

[Authors]

There has been a similar comment from Dhruv on the OTN Tunnel model: https://mailarchive.ietf.org/arch/msg/ccamp/yIz26ZDNZN_Jg-ou9mcq26pNXYw/

While you are correct regarding the literal acronym, 'OTN' in this document is treated as a proper noun, in line with standard practice in ITU-T (e.g., ITU-T G.709) and other IETF documents (e.g., RFC 7138)

Therefore we would propose to keep the terms "OTN network" and, for consistency, also the term "fgOTN network"

[/Authors]

---

I'm pretty sure that the pattern in ts-list is wrong, but my brain is sitting outside sipping mojitos at the moment, and won't help me sort it out.

[Authors]

The current regular expression pattern does not fully align with the node description because it fails to 1) enforce the 1-4095 range: The current pattern accepts values up to 9999, making out-of-range inputs syntactically valid and 2) enforce sorting rules: It cannot programmatically verify that the values are disjoint and listed in strictly ascending order

While the regular expression can be updated to strictly enforce the numeric range, standard YANG syntactic constraints cannot evaluate relative mathematical logic like disjointness or ascending order. Enforcing these sequential rules relies entirely on compliance with the text in the description statement

Since updating the regex pattern to restrict the range makes the expression significantly more complex and less readable and considering that 1) the backend application must already parse the string to validate the sorting and disjointness constraints and 2) that the maximum value of 4095 is defined for consistency with the length of the TPN field in RFC7139, although the actual maximum value depends on the type of the server layer OPU and TSG, we would prefer to rely on the description statement to govern the numeric range as well. This keeps the YANG model clean and maintainable while centralizing all numerical logic within the backend implementation

[/Authors]

---

I think that the "augments" relationship defines the need for a normative reference. Further, this is a transitive relationship.
So, because the model in this draft augments ietf-otn-topology, I-D.ietf-ccamp-otn-topo-yang is a normative relationship.
And, because ietf-otn-topology augments, ietf-te-topology, RFC8795 should be a normative reference.
And, because ietf-te-topology augments ietf-network and ietf-network-topology, RFC8345 should be a normative reference.

[Authors] We will fix the normative references in the next draft update



From: Daniele Ceccarelli (dceccare) <dceccare=40cisco.com@dmarc.ietf.org<mailto:dceccare=40cisco.com@dmarc.ietf.org>>
Sent: 18 June 2026 16:08
To: CCAMP <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [CCAMP]WG adoption call on draft-tan-ccamp-fgotn-yang-06


Hi working group,



The IPR polling related to draft-tan-ccamp-fgotn-yang-06<https://datatracker.ietf.org/doc/draft-tan-ccamp-fgotn-yang/> has been completed.

This starts a working group adoption call on draft-tan-ccamp-fgotn-yang-06. The polling will last 2 weeks till Friday July 3rd.





Thanks,

Daniele, Fatai, Luis