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

Mahesh Jethanandani <> Wed, 07 September 2022 21:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A40AC14CE44; Wed, 7 Sep 2022 14:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vwcjzMzQ8z2V; Wed, 7 Sep 2022 14:48:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 8FDABC14F726; Wed, 7 Sep 2022 14:48:10 -0700 (PDT)
Received: by with SMTP id t70so9019503pgc.5; Wed, 07 Sep 2022 14:48:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date; bh=MF2WzsKL+tmSlFtaVLDDg1AlPFzfzLmZ42biNJ+e0/o=; b=Wr0EgZuQM1nV+eGIpp0AwbUFaT3gAS49YC6UjSQCFhGu9f5gHNH+mMTTg+5i9CErbe UYiYm2oc+uP9OqZXMx4CerMYy0Qk8nhoLlZIaqIdet990zB3j7q6/QFDSWY/ad1nLs4n DrVtkf5cR/ZjpSbCfRSHYyQ6FJk0w/c9cvjIntBSQqyqnGZwdMcTexcxOloHhEs9FEwG qAxZcReVwpdyDVNsmkzZoEuV8ZSErpfDaJpVdYWBOBqBhiQ6XFIAtI+7v0JMMLyAbe5C 0jPQgsj0DgrmwB53f5L5wT+h55K4hhcUvT1QZ2l0jR2KQIC8KfQG040vzeDJkhAyWd9s p9kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=MF2WzsKL+tmSlFtaVLDDg1AlPFzfzLmZ42biNJ+e0/o=; b=tIvg5njRE0hoP7t6pjD5bbPx3abPG4Wt4v+O5ByGcO6a7e+9WSvb9T2Q/AvfkpeTsE N2mNtaH4MdCXlpnpswEjt1KE/sfgJo7FrubphHULRKcYCucWOUFLw0GMv84y0QEGtOgI GVpf09kKFhZnrURtphVnasu9s0KDdJJ0lDFYscnLTZdR25Puy1wUrNXOpxQeMBxdUGD9 uXOsnfRgN1b8+pXKaqxulTeDSKM+FG1TxuoKSfCCfdUQd0B9BTSEUj4Hs8DCnwdNECzs d6dz6MDVGeDgf6FNeHXik++5qcZGdJx01jiXWghWhzxRBVg77hAfXFMnrQeu4cJHASrn 4YOw==
X-Gm-Message-State: ACgBeo2qQD1PO+RyT/6yh5OBSiUoioORF8QLdSbgarUzaSBO2OBz2n5y CuG9KTPVwQPF7Awe4O8S4Fr+RbyATOk=
X-Google-Smtp-Source: AA6agR6Ag+uBu0c/rudB4jbQhgArjgHY4Kc4LcsFe7pw/fizcFbmTsROWDFG/FXqI2Mg192sXc21TA==
X-Received: by 2002:a05:6a00:1350:b0:53a:c314:73d9 with SMTP id k16-20020a056a00135000b0053ac31473d9mr5847938pfu.45.1662587289469; Wed, 07 Sep 2022 14:48:09 -0700 (PDT)
Received: from ([]) by with ESMTPSA id n12-20020a170902e54c00b001749381ed8csm780789plf.254.2022. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Sep 2022 14:48:09 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E59983E-CBFC-4610-88DA-B5FC2F6AD14E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 07 Sep 2022 14:48:08 -0700
In-Reply-To: <>
Cc: The IESG <>,,,,
To: Robert Wilton <>
References: <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-yang-tcp-07: (with COMMENT)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Sep 2022 21:48:14 -0000

Hi Rob,

A question. See inline.

> On Jun 30, 2022, at 6:29 AM, Robert Wilton via Datatracker <> 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 
> for more information about how to handle DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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