Re: [tcpm] Paul Wouters's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and COMMENT)

["Scharf, Michael" <[e-mail]>]

Hi Paul,

Sorry, apparently I have not received an e-mail regarding this DISCUSS.

I have copied the text from datatracker and replied inline.

The complete diff for version -08 can be found at:  https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-08

> Discuss (2022-06-28 for -07)
> [ballot text incomplete as cloudflare triggers a weird refusal if I include a certain sentence, see Cloudflare Ray ID: 722aa6477e01a1db]
>
> Thanks for the -07 changes in response to the various area reviews!
> 
> I still have two small discuss questions left which might be caused by a limited
> understanding of the underlying yang model inclusions.
>
>
>              1. 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).
>
>              2. For an application willing to accept only IPv4 or
>                 IPv6 datagrams, the value of this object must be
>                 '0.0.0.0' or '::' respectively, with
>                 'type' representing the appropriate address type.
>
> #D1
>
> To me, it seems very counter-intuitive that '' means (0.0.0.0 or ::). For
> LISTEN, I find it concerning because it means that '' as a default means to
> listen to any IP, rather than the more secure default of '' meaning 'none'.

This syntax is identical to the TCP MIB. We have not created this definition on our own. At least to me it is not obvious why this specific detail of the TCP MIB would be broken. Also, I don't understand why "none" would be required at all in this context (see below).

> Is it possible to have some kind of "None" default? (or is that achieved by
> omission of this option?

As far as I understand, this entry is about the list "tcp-listeners".

By definition, a TCP endpoint in state "listen" is willing to accept (some) TCP connections. This is the connection acceptor, i.e., typically the server side of an application. An application that is not willing to accept any connections (e.g., a client) is not in "listen" state and therefore not included in this list "tcp-listeners". 

As this list "tcp-listener" only includes endpoints that indeed listen on at least one IP address, I am not aware of a case in which a value "none" would be used.

In -08, we have slightly changed this description to address some other comments and to avoid "MIB speak", but we have not added a way to encode "none".

Please get back to us if we should have missed something.

> #D2
>
> Is it intended that this cannot be specified using names

Again, I assume that this refers to the list "tcp-listeners".

This is a read-only list, i.e., a TCP listener will never be created by configuring the YANG model. Instead, an application will use the usual ways to create a TCP endpoint (e.g., the socket API, which may understand names depending on the used socket calls).

Once a TCP listener exists, the TCP stack must know the port number internally, and it internally operates using the port number. So, the port number can always be listed.

It may be possible to list names for port numbers if the mapping is known, but it is not exactly clear if all TCP stacks are able to do so.

The TCP MIB just uses the port number in the corresponding list. As a result, in version -08 we just kept this as in the TCP MIB.

If there is really a strong reason to model more than the TCP MIB, please let us know.

> Comment (2022-06-28 for -07)
> #C1
>
> It is unclear to me if '0.0.0.0' denotes the type inet:ip-address or
> the type string with text value "0.0.0.0". I also worry that if this is
> represented in C with a struct with union, that than it is unclear what
> a zero'ed out struct is set to? The string or the v4 ANY or the v6 ANY ?
> (I personally like enums to start from value 1 for that reason)
>
> #C2
> 
> How is this option set when fully disabled (eg not listening on anything, only
> willing to make an outgoing TCP connection). Is it by being omitted?

Yes. A connection initiator (i.e., a client making only outgoing connections) is not a tcp listener and thus just omitted. See also the previous comments.
 
> NITS:
>
> listner -> listener
>
> for TCP connection that -> for a TCP connection that

Thanks, this has been fixed in -08.

Michael