Re: [Pce] I-D Action: draft-ietf-pce-pcep-yang-16.txt

[tom petch <[e-mail]>]

From: Pce <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: 22 February 2021 14:27

<tp>
I notice a number of glitches in this I-D, several about terminology, others about arithmetic.  I post the ones I have seen so far because my cache is full, but I expect that there will be more!

s.3 lacks
**PLSPID
** Association
** OF  RFC5441
**SRP RFC8231
all of which I think are needed along with the relevant RFC as references

RFC5540 is consistent in its terminology as it should be, but this I-D does not follow that terminology and is not consistent.  I refer to such as 
Keepalive
OpenWait
KeepWait
DeadTimer
SyncTimer
back-off
Where these appear in text in the I-D then I think that they should appear exactly as in the RFC.  YANG leaf names is trickier.  YANG does not do camelcase so I think that hyphenated is best e,g,
open-wait, keep-wait; keep-alive I am unsure about and note that the I-D has both with and without a hyphen which needs fixing

grouping pce-scope lacks the bit name as in the RFC, L, R, S, Rd, etc

leaf intra-area-pref {
does not say which is the higher pref and again lacks the names in the RFC

there are several 'domain' which is why the YANG convention is to make a list name plural with the leaf therein as singular lest you get a path with the same element repeated several times!

container capability
the reference should be to the IANA registry not the RFCs; in two leaf

NAI needs expanding in the text, SID too

container neigh
neigh is the sound that a horse makes but ....

list domain perhaps better as list domains as above

admin-status oper-status
did NMDA make this approach redundant?

There is an awful lot of 'when pcc or pcc-and-pce.
It would be lovely if the pcc-and-pce case could be represented with two values so that it becomes just when pcc; ditto pce

          leaf enabled {
            type boolean;
            description
              "Enabled or Disabled";
which is true?  I know, obvious, but I like stating the obvious

      leaf open-wait-timer {
the RFC says this is fixed not configurable.  If there is a reason to ignore the RFC then that needs to be spelt out IMO
      leaf keep-wait-timer {
ditto

      leaf dead-timer {
the RFC recommends a multiplier  not a value which I think better lest an operator increase the wait, forget to increase dead and so kills sessions

      leaf allow-negotiation {
default?

            Zero means that the PCEP
           entity will allow no Keepalive transmission at
           all.";
This seems like a bad idea.  If the peer is not allowed to send Keepalive then I would expect them to be greeted with an error message

            Zero means that
           the PCEP entity will allow not running a Dead
           timer.";
Likewise, if the peer wants to run a Deadtimer how can you stop them?

      leaf min-dead-timer {
and again.  I think that the underlying concepts need more consideration.  I see nothing like this in the RFC.

      leaf max-unknown-reqs {
I think that the RFC fixes this as five.

/"The PCEP association type";/"The PCEP Association Type";/
and the reference should be to IANA not RFC

/"PCEP Association Global Source.";/"PCEP Global Association Source.";/
as per RFC; this also occurs lower down

            leaf srp-id {
RFC8231 says 0 and ffffffff reserved, YANG does not.

/"The Path-key should be retreived";/"The Path-key should be retrieved";/

              case auth-tls {
                if-feature "tls";
                choice role {
                  description
                    "The role of the local entity";
                  case server {

what happens when entity is pcc and pce? the PCC client must be the TLS client but I do not know how this is handled.

.... appear transiently in this yang module. The
caps for YANG

              leaf dead-timer {
as above I like counts not times

              leaf overload-time {
in several places, does the time duration  have any meaning when there is no time of day to go with it to say when it started?

                      "The PST authorized";
I am unclear why this is 'authorized; who has said so?

  notification pcep-session-local-overload {
as above does this need a data and time?

/"Trigger the resyncrinization at the PCE";/"Trigger the resynchronization at the PCE";

       leaf avg-rsp-time {
I would find 
       leaf rsp-time-avg
clearer for this and the other two times

counters
do they need a discontinuity date and time?

       leaf num-keepalive-sent {
elsewhere keep-alive is hyphenated in YANG leaf names

5.2
/capcabilities/capabilities


There are parts of PCE I have not looked at previously and so plan to look at the RFC which is likely to generate further comments.

Tom Petch



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.

        Title           : A YANG Data Model for Path Computation Element Communications Protocol (PCEP)
        Authors         : Dhruv Dhody
                          Jonathan Hardwick
                          Vishnu Pavan Beeram
                          Jeff Tantsura
        Filename        : draft-ietf-pce-pcep-yang-16.txt
        Pages           : 112
        Date            : 2021-02-22

Abstract:
   This document defines a YANG data model for the management of Path
   Computation Element communications Protocol (PCEP) for communications
   between a Path Computation Client (PCC) and a Path Computation
   Element (PCE), or between two PCEs.  The data model includes
   configuration and state data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-16
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-yang-16


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/


_______________________________________________
Pce mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pce