Re: [Teas] I-D Action: draft-ietf-teas-yang-rsvp-16.txt etc

[t petch <[e-mail]>]

Some final comments (pro tem.).

'epoch' has a reference of RFC5063; yes that RFC uses the term but
RFC2961 defines it and seems to me the better reference

' purged if no states associated with it."; '
not quite English - not sure what it is trying to say

              + "/rsvp:sessions/rsvp:session-ip/destination";
                    + "/rsvp:neighbors/rsvp:neighbor/address";
both would be better with another ' rsvp: '

        "WG Web:   <http://tools.ietf.org/wg/teas/>
should be https: (I have seen an AD raise a DISCUSS on this:-)

        leaf interface-based {
          type empty;
Why not boolean (or a presence container)?

        leaf hello-interval {
RFC3209 uses hello_interval but I think that you are right to change it

          units "milliseconds";
          default "9000";
RFC3209 says
"  A node periodically generates a Hello message containing a HELLO
    REQUEST object for each neighbor who's status is being tracked.  The
    periodicity is governed by the hello_interval.  This value MAY be
    configured on a per neighbor basis.  The default value is 5 ms."
Is that the same concept? If so, the values are rather different.

          reference
            "RFC3209: RSVP-TE: Extensions to RSVP for LSP Tunnels.
             RFC5495: Description of the Resource Reservation Protocol -
I am unclear what RFC5495 adds; AFAICT all the information needed is in
RFC3209

        leaf hello-misses {
          type uint32 {
            range "1..10";
Why a 'uint32' for a range 1..10?

          reference
            "RFC3209: RSVP-TE: Extensions to RSVP for LSP Tunnels.
             RFC5495: Description of the Resource Reservation Protocol -
ditto

        leaf refresh-misses {
          type uint32;
          default "9";
Where does that value come from?  RFC2205 or RFC2961 would appear to say
three.

        leaf checksum_enabled {
YANG style is usually
        leaf checksum-enabled {

        leaf patherr-state-removal {
          type empty;
As before, why empty?

The referenced RFC3473 has state-removed rather than state-removal which 
I would find clearer.

/rfc4558/RFC4558/
I note that while this RFC is referenced in the body of the text as
relating to rsvp-extended, it does not appear in the YANG module.  The
RFC seems not to change anything by way of retries or timers so I am not
clear why it is applicable.

Overall, it is timers, timeouts and retries I struggle with since I find
it difficult, impossible even, to relate the YANG definitions to those
in the RFC.  I think that all the RSVP RFC should be Normative not
Informative References.

Tom Petch


----- Original Message -----
From: "t petch" <[e-mail]>
To: "Tarek Saad" <tsaad=[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Tuesday, August 10, 2021 9:16 AM
Subject: Re: [Teas] I-D Action: draft-ietf-teas-yang-rsvp-16.txt refresh
reduction