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

[tom petch <[e-mail]>]

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" <[e-mail]>
To: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)"
<[e-mail]>; <[e-mail]>
Sent: Saturday, March 09, 2019 12:51 PM
> ----- Original Message -----
> From: "Zhenghaomian (Zhenghaomian, Optical Technology Research Dept)"
> <[e-mail]>
> Sent: Friday, March 08, 2019 5:49 AM
>
> > 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.
>
> 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
>
> > 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)
> >
> > -----邮件原件-----
> > 发件人: [e-mail] [mailto:[e-mail]]
> > 发送时间: 2019年3月8日 13:02
> > 收件人: Xufeng Liu <[e-mail]>; Zhenghaomian
> (Zhenghaomian, Optical Technology Research Dept)
> <[e-mail]>; Yunbin Xu <[e-mail]>; Francesco
> Lazzeri <[e-mail]>; Anton Snitser
> <[e-mail]>; Giuseppe Fioccola
> <[e-mail]>; Aihuaguo (Aihua Guo, CRC)
> <[e-mail]>; Italo Busi <[e-mail]>; Yang Zhao
> <[e-mail]>
> > 主题: 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-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
> >
> > 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
> >
> > _______________________________________________
> > CCAMP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ccamp
> >
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>