Subject: [Teas] some shepherd comments on draft-ietf-teas-yang-te-topo

From: Lou Berger <[email-masked]>
Date: Mon, 9 Oct 2017 18:40:44 -0400

Authors,

Great (and important) work! I think the early sections are very
informative and readable. 

My one substantive comment is that I think it would be helpful to future
model developers to provide an overview of how you see this work will be
extended to support technology specific extensions, e.g., new control
technologies, new/tech link config parameters/statistics, technology
specific (or not) switching constraints, etc.    I don' want this to
delay the work, but I also don't want to find out in 6 months that the
model isn't sufficiently extendable. What do you think?

** Editorial comments:

- TE should be spelled out in the title and first use in the abstract
and introduction

- This should be moved to section 1.1:

  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

- reverences to 6020 should be replaced 7950

- Section 1.1
  It's unclear to me how you selected this particular terms and I
suspect we're going to see many comments on the need to expand this
list.  Perhaps just state that reader is assumed to be familiar with the
terminology and concepts in TE rfcs, e.g., perhaps just add something like:

   The reader is assumed to be familiar with general body of work
captured in
    currently available TE related RFCs.  RFC7926 serves as a good
starting point
    for those who may be less familiar with Traffic Engineering related
RFCs.

- It would be good to add references the first time you refer to a
well-known concept, e.g.,
Multi-layer TE [RFC5512], SRLGs, ODUk, etc..

- Section 1.2 should be replaced by a reference to
draft-ietf-netmod-yang-tree-diagrams

- s/decorate/annotate and s/decorating/annotating

- I'm not sure how useful the 30 odd pages of tree diagrams in section 6
are in this document.  Perhaps move to an appendix?  I'm really not sure...

- Please replace the reference to   draft-clemm-netconf-yang-push with
draft-ietf-netconf-yang-push

- please make [YANG-SCHEDULE] and informative reference

That's it,
Lou

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 12 Oct 2017 15:22:21 +0000

Hi Lou,

Thanks for reviewing the draft and providing the valuable comments. Authors are working on a draft update and should post it soon.

Regards,
- Xufeng

> -----Original Message-----
> From: Lou Berger [mailto:[email-masked]]
> Sent: Monday, October 9, 2017 6:41 PM
> To: [email-masked]
> Cc: TEAS WG <[email-masked]>
> Subject: some shepherd comments on draft-ietf-teas-yang-te-topo
> 
> Authors,
> 
> Great (and important) work! I think the early sections are very informative and
> readable.
> 
> My one substantive comment is that I think it would be helpful to future model
> developers to provide an overview of how you see this work will be extended to
> support technology specific extensions, e.g., new control technologies,
> new/tech link config parameters/statistics, technology specific (or not)
> switching constraints, etc.    I don' want this to delay the work, but I also don't
> want to find out in 6 months that the model isn't sufficiently extendable. What
> do you think?
> 
> ** Editorial comments:
> 
> - TE should be spelled out in the title and first use in the abstract and
> introduction
> 
>   It's unclear to me how you selected this particular terms and I suspect we're
> going to see many comments on the need to expand this list.  Perhaps just state
> that reader is assumed to be familiar with the terminology and concepts in TE
> rfcs, e.g., perhaps just add something like:
> 
>    The reader is assumed to be familiar with general body of work captured in
>     currently available TE related RFCs.  RFC7926 serves as a good starting point
>     for those who may be less familiar with Traffic Engineering related RFCs.
> 
> - It would be good to add references the first time you refer to a well-known
> concept, e.g., Multi-layer TE [RFC5512], SRLGs, ODUk, etc..
> 
> - Section 1.2 should be replaced by a reference to draft-ietf-netmod-yang-tree-
> diagrams
> 
> - I'm not sure how useful the 30 odd pages of tree diagrams in section 6 are in
> this document.  Perhaps move to an appendix?  I'm really not sure...
> 
> - Please replace the reference to   draft-clemm-netconf-yang-push with draft-
> ietf-netconf-yang-push
>