Subject: Re: [CCAMP] POLL CLOSED - WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

From: tom petch <[email-masked]>
Date: Wed, 2 Feb 2022 11:44:10 +0000

There are good reasons why there is a limit of five authors on the front page of an RFC so when I see in excess of twice that number, I know what to expect:-(

IANA Considerations must be as per YANG Guidelines; no IANA Considerations, no YANG modules.

Security Considerations must be as per YANG Guidelines.

Line length is limited in RFC; this limit is exceeded in the YANG modules

YANG import must be a Normative Reference in the I-D.

TLP is out of date in the YANG module

YANG references must also be I-D references e,g GSMA NS Template (and they have to be accessible)

No RF8174 boiler plate; are those lower case 'must' really lower case?

Abbreviations need expanding on first use in both text and YANG module

The way my mind works is that if these straightforward non-technical  matters are not right then is there any point in looking at the technical ones? YMMV!

Tom Petch

________________________________________
From: CCAMP <[email-masked]> on behalf of Daniele Ceccarelli <daniele.ceccarelli=[email-masked]>
Sent: 28 January 2022 13:50
To: Aihua Guo; Fatai Zhang
Cc: CCAMP
Subject: Re: [CCAMP] POLL CLOSED - WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Aihua,

That’s an excellent work, it will make the interim much more profitable.
Thanks a lot.
It would be great to have a similar list/presentation from the part of the WG that believes that we should speak about OTN slicing but only applicability of OTN to network slicing.

Thanks,
Daniele

From: CCAMP <[email-masked]> On Behalf Of Aihua Guo
Sent: den 27 januari 2022 19:14
To: Fatai Zhang <zhangfatai=[email-masked]>
Cc: CCAMP <[email-masked]>
Subject: Re: [CCAMP] POLL CLOSED - WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi Fatai, Daniele, WG,

Thank you for concluding the adoption call. draft-ietf-ccamp-yang-otn-slicing-00 has been published to the WG.

In today's meeting, we have created a collection of comments received from the mailing list, and plan to provide further responses for the interim based on the replies already made on the mailing list. The list is tracked as issue #25<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-487ca34dd2925741&q=1&e=558326bf-5aa5-4c1a-bc50-0e4d1cac4cb3&u=https%3A%2F%2Fgithub.com%2Faguoietf%2Fietf-ccamp-yang-otn-slicing%2Fissues%2F25> on GitHub and also copied below for your reference:

  1.  Harmonizing with [draft-ietf-teas-ietf-network-slice-nbi-yang]
  2.  It would be helpful for the draft to reflect the fact that OTN-SC is just a “NS Realizer” for OTN networks.
  3.  Harmonizing with [draft-ietf-teas-applicability-actn-slicing]
  4.  Reduced frontpage author (#23<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-4792b329c1f7937d&q=1&e=558326bf-5aa5-4c1a-bc50-0e4d1cac4cb3&u=https%3A%2F%2Fgithub.com%2Faguoietf%2Fietf-ccamp-yang-otn-slicing%2Fissues%2F23>)
  5.  Clarify relationship between an OTN slice and L1VPN
  6.  Clarify relationship between an OTN slice and Abstract (TE) Topology
  7.  Is there a need for OTN slicing? Some thought that slicing should stop at IP layer
  8.  Is "OTN slicing" a conflated term, and should we call it "OTN resource partitioning" or "OTN virtual network"?
  9.  Update the description and Fig. 2 for the 3 identified options. Explicit verbiage showing the options would be good for the reader.
  10. It would be helpful to show maybe in a section that how this additional OTN-SC the value and gains it provides that is not already provided by ACTN framework RFC 8453.
  11. It may be a good idea to add verbiage in the draft as to the OTN slice provisioning gap that exists for network slicing compared to ACTN provisioning of underlay VN Type 1 and Type 2 OTN resources.
  12. Minor changes to the text following section 1.3.2 of RFC 5921 (MPLS --> MPLS(-TP))
Thanks,
Aihua

On Wed, Jan 26, 2022 at 9:45 AM Fatai Zhang <zhangfatai=[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

The WG poll is closed with the result of the draft being adopted based on the WG consensus.

We as the chairs made the decision to adopt the draft because there is lots of interest in this topic and the open comments have been clarified to some extent, and we’re arranging an interim just on this draft and the WG will decide if and how to update the draft according to mailing list discussion and interim discussions.

Authors, please republish draft-zheng-ccamp-yang-otn-slicing-03  as draft-ietf-ccamp-yang-otn-slicing-00 with only the date and file name changed..

Thanks,

Fatai & Daniele

发件人: CCAMP [mailto:[email-masked]<mailto:[email-masked]>] 代表 Fatai Zhang
发送时间: 2022年1月12日 10:24
收件人: CCAMP <[email-masked]<mailto:[email-masked]>>
主题: [CCAMP] WG adoption poll on draft-zheng-ccamp-yang-otn-slicing-03

Hi all,

All the IPR declarations regarding draft-zheng-ccamp-yang-otn-slicing-03 have been collected, this starts the polling for WG adoption.

The poll will last 2 weeks and will end on Wednesday January 26th.

Please send email to the list indicating "yes/support" or "no/do not support" and a motivation for your reply, mandatory for the "not support" and nice to have for the "support".

Thanks,

Fatai & Daniele

_______________________________________________
CCAMP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ccamp

---

From: Aihua Guo <[email-masked]>
Date: Wed, 2 Feb 2022 15:57:40 -0500

Hi Tom,

Noted with thanks to your very helpful comments! We will update the draft
and address your comments in the upcoming revision.

Thank you,
Aihua

On Wed, Feb 2, 2022 at 6:44 AM tom petch <[email-masked]> wrote:

> There are good reasons why there is a limit of five authors on the front
> page of an RFC so when I see in excess of twice that number, I know what to
> expect:-(
>
> The way my mind works is that if these straightforward non-technical
> matters are not right then is there any point in looking at the technical
> ones? YMMV!
>
> Tom Petch
>
> From: CCAMP <[email-masked]> on behalf of Daniele Ceccarelli
> <daniele.ceccarelli=[email-masked]>
> It would be great to have a similar list/presentation from the part of the
> WG that believes that we should speak about OTN slicing but only
> applicability of OTN to network slicing.
>
> Thanks,
> Daniele
>
> Thank you for concluding the adoption call.
> draft-ietf-ccamp-yang-otn-slicing-00 has been published to the WG.
>
> In today's meeting, we have created a collection of comments received from
> the mailing list, and plan to provide further responses for the interim
> based on the replies already made on the mailing list. The list is tracked
> as issue #25<
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-487ca34dd2925741&q=1&e=558326bf-5aa5-4c1a-bc50-0e4d1cac4cb3&u=https%3A%2F%2Fgithub.com%2Faguoietf%2Fietf-ccamp-yang-otn-slicing%2Fissues%2F25>
> on GitHub and also copied below for your reference:
>
>   4.  Reduced frontpage author (#23<
> https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-4792b329c1f7937d&q=1&e=558326bf-5aa5-4c1a-bc50-0e4d1cac4cb3&u=https%3A%2F%2Fgithub.com%2Faguoietf%2Fietf-ccamp-yang-otn-slicing%2Fissues%2F23
> >)
>   8.  Is "OTN slicing" a conflated term, and should we call it "OTN
> resource partitioning" or "OTN virtual network"?
>   9.  Update the description and Fig. 2 for the 3 identified options.
> Explicit verbiage showing the options would be good for the reader.
>   10. It would be helpful to show maybe in a section that how this
> additional OTN-SC the value and gains it provides that is not already
> provided by ACTN framework RFC 8453.
>   11. It may be a good idea to add verbiage in the draft as to the OTN
> slice provisioning gap that exists for network slicing compared to ACTN
> provisioning of underlay VN Type 1 and Type 2 OTN resources.
> On Wed, Jan 26, 2022 at 9:45 AM Fatai Zhang <zhangfatai=
> [email-masked]<mailto:[email-masked]>> wrote:
> Hi all,
>
> We as the chairs made the decision to adopt the draft because there is
> lots of interest in this topic and the open comments have been clarified to
> some extent, and we’re arranging an interim just on this draft and the WG
> will decide if and how to update the draft according to mailing list
> discussion and interim discussions.
>
>
> Authors, please republish draft-zheng-ccamp-yang-otn-slicing-03  as
> draft-ietf-ccamp-yang-otn-slicing-00 with only the date and file name
> changed..
>
>
>
> Thanks,
>
> Fatai & Daniele
>
>
> All the IPR declarations regarding draft-zheng-ccamp-yang-otn-slicing-03
> have been collected, this starts the polling for WG adoption.
>
> Please send email to the list indicating "yes/support" or "no/do not
> support" and a motivation for your reply, mandatory for the "not support"
> and nice to have for the "support".
>
>
> Thanks,
>
> Fatai & Daniele
>
>
>