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

From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)" <[email-masked]>
Date: Fri, 8 Mar 2019 05:49:58 +0000

Dear Ccampers, 

We have updated this work. Compared with -03, there are the following changes: 

- Integrating this work with two more experts (Thanks Francesco and Anton!)
- Indicating necessity of the models, and specify their relationship with existing models, in section 3; 
- Update the modules, ietf-trans-client-service, ietf-eth-tran-service and ietf-eth-tran-types with new attributes, e.g., end-point and PW segment; 
- For the resilience information and pm-config, there is still pending work to be done, place holders have been put for future work. 

The authors believe this work is stable in working scope and functionality, and request for a WG adoption. Please feel free to review and leave your comments to us. Thank you. 

BTW, please forget about -04 of this work as the model inside was not correct (my apologize...). 

Best wishes,
Haomian (On behalf of all the authors & contributors)

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2019年3月8日 13:02
收件人: Xufeng Liu <[email-masked]>; Zhenghaomian (Zhenghaomian, Optical Technology Research Dept) <[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-05.txt

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

Name:		draft-zheng-ccamp-client-signal-yang
Revision:	05
Title:		A YANG Data Model for Transport Network Client Signals
Document date:	2019-03-08
Group:		Individual Submission
Pages:		46
URL:            https://www.ietf.org/internet-drafts/draft-zheng-ccamp-client-signal-yang-05.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-05
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-05

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: Sat, 9 Mar 2019 12:51:05 +0000

----- Original Message -----
From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)"
<[email-masked]>
Sent: Friday, March 08, 2019 5:49 AM

> - Update the modules, ietf-trans-client-service, ietf-eth-tran-service
and ietf-eth-tran-types with new attributes, e.g., end-point and PW
segment;
> - For the resilience information and pm-config, there is still pending
work to be done, place holders have been put for future work.
>
> The authors believe this work is stable in working scope and
functionality, and request for a WG adoption. Please feel free to review
and leave your comments to us. Thank you.

Since you ask...

The YANG needs some more work, mostly of an administrative kind.

Abstract/Introduction should say whether or not NMDA is supported.

good practice is to have a section in the body of the I-D which lists
the prefixes used in a module and where they can be found e.g.
   +---------+------------------------------+-----------------+
   | Prefix  | YANG module                  | Reference       |
   +---------+------------------------------+-----------------+
   | l1csm   | ietf-l1cms                   | [RFC XXXX]      |
   | yang    | ietf-yang-types              | [RFC6991]       |
   +---------+------------------------------+-----------------+

good practice is to have a section just before each YANG module listing
the documents that it imports from and references
e.g.
   This module imports typedefs and modules from [RFC6991], [RFC8343]
   and [RFC7224], and it references [TR102311], [EN302217-1],
   [EN301129], and [G.826].

YANG modules must have a copyright statement

YANG modules must say where they come from e.g.
  reference "RFC XXXX: A YANG Data Model for Transport Network Client
Signals";

References in a YANG module must appear in the references of the I-D
e.g.
802.1ad
MEF 10
RFC 2697
RFC 2698
RFC 4115

YANG import statements need a reference e.g.
     import ietf-routing-types {
       prefix "rt-types";
       reference "RFC 8294 - Common YANG Data Types for the
                  Routing Area";     }

'Security Considerations' are not the current text

Some line lengths are too long for an RFC

IANA Considerations !

All of which makes the I-D easier to follow, easier to assess for
adoption (or not:-)

Tom Petch

> 收件人: Xufeng Liu <[email-masked]>; Zhenghaomian
(Zhenghaomian, Optical Technology Research Dept)
<[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-05.txt
> URL:
https://www.ietf.org/internet-drafts/draft-zheng-ccamp-client-signal-yan
g-05.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-05
> 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
5
> 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: tom petch <[email-masked]>
Date: Sat, 23 Mar 2019 13:06:25 +0000

I see
draft-zheng-ccamp-client-signal-yang-06
and it is moving forward.

You need YANG version statement in every module.  It defaults to 1 and
in that version, you cannot have a reference in an import which is why I
suspect you have made
    //reference "RFC 6991 - Common YANG Data Types";
into a comment; add version 1.1 and the statement will be valid as
   reference "RFC 6991 - Common YANG Data Types";

   reference "RFC XXXX - This Document.";
will not look so good when the YANG module is extracted from the RFC. I
suggest
   reference "RFC XXXX - A YANG Data Model for Transport Network Client
Signals";
with a note to the RFC Editor somewhere at the start asking them to
replace XXXX with the number assigned to the RFC; you will see such a
request in almost all YANG I-D.  Just the one request is fine for all
the XXXX

But
   reference "RFC XXXX - Traffic Engineering Common YANG Types";
may confuse the RFC Editor.  I suggest
   reference "RFC YYYY - Traffic Engineering Common YANG Types";
with a note up from asking the RFC Editor to replace YYYY with the
number assigned to
   [I-D.ietf-teas-yang-te-types]
and if you need to reference further I-D, then RFC ZZZZ etc

Security Considerations are still not the current text.

You have 'weather' where I think 'whether' is intended

There are several lines too long to fit in an RFC

IANA Considerations should reference RFC6020 and not RFC 7950

NMDA needs a mention, support or lack thereof.

  grouping  client-svc-instance_config {
is a mix of hyphen and underscore; YANG allows this but discourages it.
All hyphen is preferred.

/      "Configuraiton parameters for client services.";
 /     "Configuration parameters for client services."; /

Tom Petch

----- Original Message -----
From: "tom petch" <[email-masked]>
To: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)"
<[email-masked]>; <[email-masked]>
Sent: Saturday, March 09, 2019 12:51 PM
> > We have updated this work. Compared with -03, there are the
following
> changes:
> > BTW, please forget about -04 of this work as the model inside was
not
> correct (my apologize...).
> >
> > Best wishes,