Re: [Teas] teas-yang-te was Re: TEAS WG Document Status Reports yang-te

[t petch <[e-mail]>]

Another set of quirks, mostly, but not all, admin.

Abbreviations are used in the YANG module but only one is expanded.  I
think you should expand, on first use,
BRPC    GCO     APS     LoP
  SD         SF         SRLG   MS   WTR
Also it would help a reader to include them all in s.1.1

References, always a good idea, but need to be  in I-D references;  I
cannot see
RFC5440  RFC5441 RFC5520 RFC5557
RFC8306  RFC8685

    identity tunnel-admin-auto {
'state datastore'
is this operational?


    grouping path-preference {
    leaf preference {  type uint8 {  range "1..255";   }
        default 1;
in -22, default was was 1 for  grouping p2p-path-properties {
          100 for grouping tunnel-p2p-config {
I realise that the groupings have changed - is the change of default
intentional?

    grouping protection-restoration-properties-state {
  'The freeze command command'

          enum protecting {
'e.g.'
is that really i.e.?

      leaf protection-group-ingress-node-id {
/extenal/external/

      leaf protection-group-egress-node-id {
/extenal/external/

      container restoration {
        leaf hold-off-time {
            "The time between the declaration of an SF or SD condition
             and the initialization of the protection switching
             algorithm.";
sounds like protection not restoration

What triggers the start of the hold-off-time?


      leaf bidirectional {
        type boolean;
I always like my booleans to indicate which is true which false i.e.
start the description with 'When true ...' (or not as the case may be)

    grouping tunnel-protection-actions {
               By default, if neither ingress nor egress node-id
should the YANG be in line with this description e.g. with a choice?
What happens in both ingress and egress are specified as the YANG
allows?

    grouping named-admin-groups-properties {
      leaf bit-position {  type uint32;
        description  "Bit position representing the administrative
group.";
        reference "RFC3209 and RFC7308";
admin group does not appear in RFC3209 - RFC7308 is extended i.e. in
excess of 32 bit which is not what the YANG specifies

    rpc tunnels-actions {
          choice filter-type {
            mandatory true;  description "Filter choice";
            case all-tunnels {
              leaf all { type empty;
                mandatory true;
I am unclear what the YANG is doing but I do find choice mandatory
  complex

       rpc link-state-update {
likewise

Tom Petch

> ----- Original Message -----
> From: "tom petch" <[e-mail]>
> Sent: Thursday, April 30, 2020 10:14 AM
>
>> From: Teas <[e-mail]> on behalf of tom petch
> <[e-mail]>
>> Sent: 27 April 2020 17:29
>> Subject: Re: [Teas] TEAS WG Document Status Reports  yang-te
>>
>> <tp>
>> this I-D is BIGG so I expect that I will be noticing things for months
> to come so here are some more
>>
>> Editors/Authors are listed in four places, top, bottom and both YANG
> modules and the lists differ
>>
>> IANA Considerations has no Registrant Contact for the uri
>>
>> tree diagram lacks reference to RFC8340
>>
>> downstream-info
>> when origin-type != egress
>> Applicable to ingress LSP only
>> is a mismatch - when will allow transit
>>
>> enum link-down
>> "Link-up flooding trigger"
>> mismatch
>>
>> advertized-level-areas
>> " List of areas .. is advertised in"
>> mismatch, I think the list name is wrong
>> (stupid autocorrect:-)
>>
>> tom petch
>>
>> From: Teas <[e-mail]> on behalf of Tarek Saad
> <tsaad=[e-mail]>
>> Sent: 21 April 2020 22:39
>>
>> Below is status reports for the below documents.
>>
>> Regards,
>> Tarek (for the document co-authors)
>>
>>
>> 1. draft-ietf-teas-yang-te-23
>> Current Status:
>>
>>    *   Version -21 was reviewed by YANG Dr. and received comments
>>
>>    *   Authors addressed all comments in version -23 (already
> uploaded).
>>    *   Team meeting regularly to address open issues - tracked on
> https://github.com/tsaad-dev/te/issues
>>    *   Will publish new version -24 before asking for WGLC
>> Open Issues:
>>    *   None.
>> Next Steps:.
>>
>>    *   Authors will followup with YANG Dr. to make sure no further
> comments
>>    *   Will request a Working Group Last Call after completing the
> above
>>
>> <tp>
>> I think that there is quite a bit wrong with this I-D from an
> administrative viewpoint some of which may be more debatable than
> others.
>>
>> It is VERRY  BIGGG which makes it hard to digest which for me is not
> helped by having 52 pages of uninterrupted tree diagram at the start (or
> is that intended to discourage anyone from going further?).  I see other
> authors taking two variations.  One is to put the entire module tree
> diagram at the end as an appendix.  The other is to include bite size
> chunks with sections of text.  You sort of do that s.3 but for me there
> is too little tree diagram in those sections.  Look for example at
> draft-ietf-opsawg-l3sm-l3nm which is only 122 pages but which I think
> gets a better balance in its section 6 of interspersing text with tree
> diagram and making it possible to follow.
>>
>> Less debatably,
>> - the prefix in the YANG does not match prefix in IANA Considerations.
>> - the Security Considerations are out of date..
>> - the device module would be better In a separate section
>> - s.4 lists [4872] twice
>>
>> Tom Petch
>>
>>
>> 2. draft-ietf-teas-yang-rsvp-11
>> Current Status:
>>
>>    *   Version -10 was reviewed by YANG Dr. and received comments
>>
>>    *   Authors published version -12 which addressed all outstanding
> comments
>>    *   Authors followed up with YANG Dr. reviewer on closing comments
>> Open Issues:
>>
>>    *   None
>> Next Steps:
>>
>>    *   Proceed to WGLC
>>
>>
>> 3. draft-ietf-teas-yang-rsvp-te-07
>> Current Status:
>>
>>    *   Version -07 was reviewed by YANG Dr. and received comments
>> Open Issues:
>>
>>    *   Authors working on addressing YANG Dr. comments
>> Next Steps:
>>
>>    *   Folllow-up with YANG Dr. reviewer to close on comments
>>    *   Proceed to WGLC after addressing
>>
>> 4. draft-ietf-teas-yang-te-mpls
>> Current Status:
>>
>>    *   Authors discussing augmentation of this module for MPLS-TP
>>    *   A new module and model is expected
>> Open Issues:
>>
>>    *   Close on MPLS-TP modeling
>> Next Steps:
>>
>>    *   Publish a new revision
>>    *   Ask for YANG Dr. review
>>
>>
>>
>> _______________________________________________
>> Teas mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/teas
>> .
>>
>>