Re: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-yang-tcp-07: (with COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Mahesh,

Yes, the YANG that you have below looks semantically right to me.  Is some tooling complaining about it?

Regards,
Rob


From: Mahesh Jethanandani <[e-mail]>
Sent: 07 September 2022 22:48
To: Rob Wilton (rwilton) <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-yang-tcp-07: (with COMMENT)

Hi Rob,

A question. See inline.


On Jun 30, 2022, at 6:29 AM, Robert Wilton via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Robert Wilton has entered the following ballot position for
draft-ietf-tcpm-yang-tcp-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thanks for another YANG module!

I have some non-blocking comments, I suspect that many of these have already
been raised/discussed so really just want to check that they had been
proactively considered.

1)
     TCP connection list: Access to status information for all TCP
     connections.  Note, the connection table is modeled as a list that
     is read-writeable, even though a connection cannot be created by
     adding entries to the table.  Similarly, deletion of connections
     from this list is implementation-specific.

I think that it would be helpful to further describe and perhaps constrain the
behaviour here:
- I would suggest clarifying that the list is read/writable to allow
configuration to be associated with existing connections, or connections that
may be subsequently made. - It would be helpful to understand what happens if
the configuration for a connection changes for an existing connection.  Does
it force the connection to be closed and reopened?  Or does it depend on the
configuration change? - I don't think that deleting the configuration
properties should cause a connection to be closed (although it might cause the
connection to flap, as per my comment above.)  E.g., for BGP, isn't it the BGP
neighbour configuration that should control whether a connection logically
exists?

2) With the ambiguity regarding YANG IP address and zones, can I clarify that
in all cases, the intention is that zoned ip-addresses are allowed where the
inet:ip-address type is used?

3) leaf enable-ao {
I presume that there was a conscious decision not to use a presence container
here (and hence avoid the need for the must statements)?

4) leaf enable-md5 {
I presume that implementations won't need to add extra MD5 specific parameters?
I.e., it doesn't make sense for this to be a presence container?

5) Connection is closed. Connections in this state
                   may not appear in this list.";

In the operational state tree then what does the tcp/connections list
represent?  Does it contain all connections that either exist or have some
configuration associated with them?

6) I think that leaf "state" (describing the connection state) should be marked
as "config false".  A client should not be able to configure the current
protocol "state".

7)      leaf address {
          type union {
            type string;
            type inet:ip-address;
          }

Given the described behaviour, then I think that you should probably:
(i) List the inet:ip-address type first.
(ii) Add a length "0" restriction to the string type.

I am trying to model (ii) but do not know how. If we are trying to model ‘’h, a zero length octet-string, what would the restriction look like?

leaf address {
  type union {
    type string {
      length 0;
    }
    type inet:ip-address;
  }
}



8)              For an application willing to accept both IPv4 and
                IPv6 datagrams, the value of this object must be
                ''h (a zero-length octet-string), with the value
                of the corresponding 'type' object being
                unknown (0).

What does the h mean?  I've got a nagging feeling that this is a known
convention ...  I presumed that the WG considered and dismissed the option of
having two separate listeners listed, one for v4 and one for v6 rather than the
union with the string type?

9)
list tcp-listeners {
        key "type address port";
This allows multiple listeners for the same port.  I just wanted to check that
is allowed/expected?

10) container statistics

These counters are global level, so there are not many of them.  Some of these
counters are 32 bits, I presume that there is no reasonable risk that they
would overflow over a reasonable time frame?

Nits:

included in TCP MIB => included in the TCP MIB
TCP-AO TCP-AO [RFC5925] => Duplicate TCP-AO.

Thanks,
Rob




Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>