Re: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-yang-tcp-07: (with COMMENT)
Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 07 September 2022 21:48 UTC
Return-Path: <mjethanandani@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A40AC14CE44; Wed, 7 Sep 2022 14:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwcjzMzQ8z2V; Wed, 7 Sep 2022 14:48:10 -0700 (PDT)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 8FDABC14F726; Wed, 7 Sep 2022 14:48:10 -0700 (PDT)
Received: by mail-pg1-x530.google.com with SMTP id t70so9019503pgc.5; Wed, 07 Sep 2022 14:48:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 smtpclient.apple ([70.234.233.187]) by smtp.gmail.com with ESMTPSA id n12-20020a170902e54c00b001749381ed8csm780789plf.254.2022.09.07.14.48.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Sep 2022 14:48:09 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <8B635F11-6A25-4FC5-82BA-F4012F234C16@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2E59983E-CBFC-4610-88DA-B5FC2F6AD14E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Wed, 07 Sep 2022 14:48:08 -0700
In-Reply-To: <165659575476.26185.3417581885981216323@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tcpm-yang-tcp@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, nsd.ietf@gmail.com
To: Robert Wilton <rwilton@cisco.com>
References: <165659575476.26185.3417581885981216323@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/wL7_PitXz_OUWjMh35ODndTX4ZM>
Subject: Re: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-yang-tcp-07: (with COMMENT)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=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 <noreply@ietf.org> 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 mjethanandani@gmail.com
- [tcpm] Robert Wilton's No Objection on draft-ietf… Robert Wilton via Datatracker
- Re: [tcpm] Robert Wilton's No Objection on draft-… Scharf, Michael
- Re: [tcpm] Robert Wilton's No Objection on draft-… Mahesh Jethanandani
- Re: [tcpm] Robert Wilton's No Objection on draft-… Rob Wilton (rwilton)
- Re: [tcpm] Robert Wilton's No Objection on draft-… Mahesh Jethanandani