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

[Mahesh Jethanandani <[e-mail]>]

Hi Rob,

No nothing in particular. I was only wondering how it will be rendered, since it is a zero length string. I guess much as what the description says - ‘’h.

> On Sep 8, 2022, at 12:47 AM, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> 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/ <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/ <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]>

Mahesh Jethanandani
[e-mail]