Subject: [Teas] I-D Action: draft-ietf-teas-yang-path-computation-11.txt

From: [email-masked]
Date: Mon, 16 Nov 2020 06:58:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Traffic Engineering Architecture and Signaling WG of the IETF.

        Title           : Yang model for requesting Path Computation
        Authors         : Italo Busi
                          Sergio Belotti
                          Victor Lopez
                          Anurag Sharma
                          Yan Shi
	Filename        : draft-ietf-teas-yang-path-computation-11.txt
	Pages           : 93
	Date            : 2020-11-16

Abstract:
   There are scenarios, typically in a hierarchical SDN context, where
   the topology information provided by a TE network provider may not
   be sufficient for its client to perform end-to-end path computation.
   In these cases the client would need to request the provider to
   calculate some (partial) feasible paths.

   This document defines a YANG data model for an RPC to request path
   computation. This model complements the solution, defined in
   RFCXXXX, to configure a TE Tunnel path in "compute-only" mode.

   [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of
   draft-ietf-teas-yang-te once it has been published.

   Moreover this document describes some use cases where a path
   computation request, via YANG-based protocols (e.g., NETCONF or
   RESTCONF), can be needed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-path-computation/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-yang-path-computation-11
https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-yang-path-computation-11

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: tom petch <[email-masked]>
Date: Thu, 19 Nov 2020 12:12:14 +0000

Some mostly editorial comments

Capitalisation; confuses me
I would use a general principle that capitals are used for technical
terms, something special, and not elsewhere.  Thus I prefer Optical
Domain Controller,  Cloud Network Orchestrator, YANG(!)
but domain, optical domain, child, parent, coordinator, packet, optical,
multi-domain
but above all, consistency in the use

Expand on first use
SDN, ABNO, ACTN, CMI, MPI, OTN, ODU, PCE, WSON, LSP,  PNC, SVEC, SRLG

XXXX  is standing in for two distinct I-D; the common convention is to
use XXXX for this document, rather than 'this document' and then YYYY,
ZZZZ etc for others - here, I would use YYYY for teas-te.

k-shortest could do with a reference

/data-store/datastore/

/multi domain/multi-domain/

/setup/set up/ when this is a verb, set-up is the noun

I think that  there is only the one path delete RPC but I see several
different phrases that seem to refer to it - consistency is good (and
capitalisation is good!)

Abstract

YANG-based protocols
I know of none such:-)  perhaps YANG-supporting or some such

s.1
YANG, NETCONF, RESTCONF need references  and I would mention at this
point that this is RPC-based

s.2.1
/depend from/depend on/
/even this is/ even if this is/

s.2.4
/path computation to/path computation from/

s.3.2
/computation by its own/computation on its own/
/to compute unfeasible path/to compute an unfeasible path/
/and accurate the TE//and accurate TE/

s.3.2.2
/is not good and need/is not good and it needs/
/to get a suboptimal path that/     unsure perhaps /that/than/?

s.3.3
/major issues in case the time /major issues when the time /

compute-only mode in the config data-store
which datastore?  elsewhere you name the datastore

/can request to setup /can request the set-up of/
/computation requests /computation request/
/path that have been /path that has been /

s.4
  /not-synchronized /unsynchronized

s.5.1
/The YANG model permits to synchronize/The YANG model permits the
synchronization of/

including raw YANG seems odd - might be better in English with a line or
two of explanation for each
identity - I see this approach in yang-te-types

s.5.2
/It also allows to request in the input/It also allows the request in
the input/

s.5.3
'is indented to be used'
perhaps 'intended'- this occurs in several places

/ primary paths, or/ primary path, or/

Since the IETF has expunged pagination, then it would be good to keep
sections to a page or less, where this is technically feasible -  I know, diagrams make this difficult!.

Tom Petch