Subject: [CCAMP] Fw: New Version Notification for draft-zheng-ccamp-client-signal-yang-07.txt

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Wed, 27 Mar 2019 17:29:31 +0000

Hi, WG, 

This work is updated according to the discussion in the working group. The usage of terminology 'transport' is replaced by 'transport network'. Some clean-up have been done as well in this version. We tried our best to solve the comments in https://mailarchive.ietf.org/arch/msg/ccamp/GQ4oxkx1QvWFRNyJTlu6L8UjpE4. Thanks again to Mr. Petch for the careful review. 

It is proposed to proceed this version for WG adoption, thank you. 

Best wishes,
Haomian

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2019年3月28日 1:24
收件人: Xufeng Liu <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical Technology Research Dept) <[email-masked]>; Italo Busi <[email-masked]>; Yunbin Xu <[email-masked]>; Francesco Lazzeri <[email-masked]>; Anton Snitser <[email-masked]>; Giuseppe Fioccola <[email-masked]>; Aihuaguo (Aihua Guo, CRC) <[email-masked]>; Italo Busi <[email-masked]>; Yang Zhao <[email-masked]>
主题: New Version Notification for draft-zheng-ccamp-client-signal-yang-07.txt

A new version of I-D, draft-zheng-ccamp-client-signal-yang-07.txt
has been successfully submitted by Haomian Zheng and posted to the IETF repository.

Name:		draft-zheng-ccamp-client-signal-yang
Revision:	07
Title:		A YANG Data Model for Transport Network Client Signals
Document date:	2019-03-27
Group:		Individual Submission
Pages:		50
URL:            https://www.ietf.org/internet-drafts/draft-zheng-ccamp-client-signal-yang-07.txt
Status:         https://datatracker.ietf.org/doc/draft-zheng-ccamp-client-signal-yang/
Htmlized:       https://tools.ietf.org/html/draft-zheng-ccamp-client-signal-yang-07
Htmlized:       https://datatracker.ietf.org/doc/html/draft-zheng-ccamp-client-signal-yang
Diff:           https://www.ietf.org/rfcdiff?url2=draft-zheng-ccamp-client-signal-yang-07

Abstract:
   A transport network is a server-layer network to provide connectivity
   services to its client.  The topology and tunnel information in the
   transport layer has already been defined by generic Traffic-
   engineered models and technology-specific models (e.g., OTN, WSON).
   However, how the client signals are accessing to the network has not
   been described.  These information is necessary to both client and
   provider.

   This draft describes how the client signals are carried over
   transport network and defines YANG data models which are required
   during configuration procedure.  More specifically, several client
   signal (of transport network) models including ETH, STM-n, FC and so
   on, are defined in this draft.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: tom petch <[email-masked]>
Date: Fri, 29 Mar 2019 17:22:21 +0000

Zheng

I note that in the YANG module, you reference IEEE 802.1Q but in the
list of references you have IEEE 802.1q.  In the IEEE, case matters so
one is right and one is wrong (but I have not checked to see which is
which).

MEF 10 is a bit limp for a reference; I think you need to expand MEF and
give a URL for the document even if RFC6004 is just as limp.

Security Considerations is still not the current text (which references
TLS 1.3 and HTTPS); RFC8407 tells you where to find it

Line lengths are ok but the splits are a bit clunky - there is pyang
option to format for a chosen line length, I am unsure if that is what
you are using.

More technically, I wonder about the choice of prefix; they customarily
go from more important to less which ethtsvc does not do for me; thus
the prefix for optical transport networks YANG modules start otn...
which seems just right.  If this is also to do with transport networks,
and client service, then should they start with tn... or cs..?

Think of what other modules are likely to be sitting alongside this one,
and how the prefixes will look alongside each other; I do like my labels
to collate so that like sits along like once sorted.

I see no rush to change this - it can all wait until after adoption if
that suits you better; the point about prefix would benefit from a wider
input from others who know what is, or is about to be, out there.

Tom Petch

----- Original Message -----
From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)"
<[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 27, 2019 5:29 PM
>
> This work is updated according to the discussion in the working group.
The usage of terminology 'transport' is replaced by 'transport network'.
Some clean-up have been done as well in this version. We tried our best
to solve the comments in
https://mailarchive.ietf.org/arch/msg/ccamp/GQ4oxkx1QvWFRNyJTlu6L8UjpE4.
Thanks again to Mr. Petch for the careful review.
> 收件人: Xufeng Liu <[email-masked]>; Zhenghaomian
(Zhenghaomian, Optical Technology Research Dept)
<[email-masked]>; Italo Busi <[email-masked]>; Yunbin Xu
<[email-masked]>; Francesco Lazzeri <[email-masked]>;
Anton Snitser <[email-masked]>; Giuseppe Fioccola
<[email-masked]>; Aihuaguo (Aihua Guo, CRC)
<[email-masked]>; Italo Busi <[email-masked]>; Yang Zhao
<[email-masked]>
> 主题: New Version Notification for
draft-zheng-ccamp-client-signal-yang-07.txt
> URL:
https://www.ietf.org/internet-drafts/draft-zheng-ccamp-client-signal-yan
g-07.txt
> Status:
https://datatracker.ietf.org/doc/draft-zheng-ccamp-client-signal-yang/
> Htmlized:
https://tools.ietf.org/html/draft-zheng-ccamp-client-signal-yang-07
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-zheng-ccamp-client-signal-ya
ng
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-zheng-ccamp-client-signal-yang-0
7
> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Sun, 31 Mar 2019 02:18:13 +0000

Thank you Tom for the review again. We have left a comment in 'open issues' to check with RFC8407. 

Will also try the best to address the reference/format issue in the next update, I agree with you, it may be better to do after WG adoption. 

Best wishes,
Haomian

-----邮件原件-----
发件人: tom petch [mailto:[email-masked]] 
发送时间: 2019年3月30日 1:22
收件人: Zhenghaomian (Zhenghaomian, Optical Technology Research Dept) <[email-masked]>; [email-masked]
抄送: [email-masked]
主题: Re: [CCAMP] Fw: New Version Notification for draft-zheng-ccamp-client-signal-yang-07.txt

Zheng

I note that in the YANG module, you reference IEEE 802.1Q but in the list of references you have IEEE 802.1q.  In the IEEE, case matters so one is right and one is wrong (but I have not checked to see which is which).

MEF 10 is a bit limp for a reference; I think you need to expand MEF and give a URL for the document even if RFC6004 is just as limp.

Security Considerations is still not the current text (which references TLS 1.3 and HTTPS); RFC8407 tells you where to find it

Line lengths are ok but the splits are a bit clunky - there is pyang option to format for a chosen line length, I am unsure if that is what you are using.

More technically, I wonder about the choice of prefix; they customarily go from more important to less which ethtsvc does not do for me; thus the prefix for optical transport networks YANG modules start otn...
which seems just right.  If this is also to do with transport networks, and client service, then should they start with tn... or cs..?

Think of what other modules are likely to be sitting alongside this one, and how the prefixes will look alongside each other; I do like my labels to collate so that like sits along like once sorted.

I see no rush to change this - it can all wait until after adoption if that suits you better; the point about prefix would benefit from a wider input from others who know what is, or is about to be, out there.

Tom Petch

----- Original Message -----
The usage of terminology 'transport' is replaced by 'transport network'.
Some clean-up have been done as well in this version. We tried our best to solve the comments in https://mailarchive.ietf.org/arch/msg/ccamp/GQ4oxkx1QvWFRNyJTlu6L8UjpE4.
Thanks again to Mr. Petch for the careful review.
> 收件人: Xufeng Liu <[email-masked]>; Zhenghaomian
(Zhenghaomian, Optical Technology Research Dept) <[email-masked]>; Italo Busi <[email-masked]>; Yunbin Xu <[email-masked]>; Francesco Lazzeri <[email-masked]>; Anton Snitser <[email-masked]>; Giuseppe Fioccola <[email-masked]>; Aihuaguo (Aihua Guo, CRC) <[email-masked]>; Italo Busi <[email-masked]>; Yang Zhao <[email-masked]>
> Title: A YANG Data Model for Transport Network Client Signals Document 
> date: 2019-03-27
> Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at tools.ietf.org.