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

[tom petch <[e-mail]>]

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

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, November 16, 2020 2:58 PM
Subject: I-D Action: draft-ietf-teas-yang-path-computation-11.txt


>
> 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/
>