Re: [tcpm] [Last-Call] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07

Robert Raszuk <> Mon, 04 July 2022 19:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5810BC14F726 for <>; Mon, 4 Jul 2022 12:39:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Status: No, score=-7.105 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KUrviLHU1zFL for <>; Mon, 4 Jul 2022 12:39:29 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (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 E0515C14F74B for <>; Mon, 4 Jul 2022 12:39:29 -0700 (PDT)
Received: by with SMTP id i18so17196465lfu.8 for <>; Mon, 04 Jul 2022 12:39:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dcFFydKq3fhaLaCymAeb/rHSUBPfFUTDssVqJ8AIX5k=; b=VBLt1to5nF6H7E/Y9eMcS10ubc1lSSEx011HgaSqlWNsVeS/bcCHelnKPHMD4XKPhc xvNJVT+sTuDLGPs3aWmLnS/klZKNLeAKPXXOtxAy8sRmZXcoKN0vV8ujH27d5kd1UIfo FW9dkvmcycmh+bJyGgLJEeyHGs3Pi6eUOptdaEWpXB2oxoTtA+/KTKma1VthdRDw2/JQ 5niTW4SfS5zs3PakgGI4FRkK0/PQBB4fk8vttEo6/9aT/YbeeJEIMIGVrvawZv1JDJ8o XIQG3ic51RW90r/mJSP7z76YDT4KhYrnpsZCiBRtfyRbf8EfhM3kka1MSm6pAXFTlLuK dwWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dcFFydKq3fhaLaCymAeb/rHSUBPfFUTDssVqJ8AIX5k=; b=FaDXmsd68NipQqfLpEO1QvjJ6r8h623ZYeebEc0IybNAdvtBGBJUkO7D0YpVn5jjlO JriQh8wP6B7f7eOsSqx65+rvkf4mKc4QjWpfpr1Qbr1JYzgJwVCZ+b54ARZfgnn3IAlj REbCVHKOuk+UyHDnVhUQsiDn4+StG5BCmQAkVHFsfNPxHyDQ84M9SBHlU6UF+B6m0ajZ zhWnF+8mOA0/miZD/6vK6t8TazTXRot5jycWkSgNf2u+TtUlFeDdyas/jCu0w4V9mpmY dMucYfbsAUb/bKlKTqGOWKD5orLUAUCJLGlu5zelCXGJ0r75aQcMIgTTARrMFic1sW8O t8Bg==
X-Gm-Message-State: AJIora9MjT+AudCZX6SXY6fpCc5s1UVju/f7/7MBdKNy6wlUdPfA64wo QkwwrjRh/boBI2qSAxC7QWIIAWL+eEDijN15i4S/Hg==
X-Google-Smtp-Source: AGRyM1tj1u0h+dGAV7nEfLDtMAqHFoGhVwOrqpWafmbgi+tfOaRhlsgBwnKDJ+1qtBACWiX60RARjN0AthdE4W5NK9Y=
X-Received: by 2002:a05:6512:41a:b0:47f:a121:610a with SMTP id u26-20020a056512041a00b0047fa121610amr20787798lfk.433.1656963567650; Mon, 04 Jul 2022 12:39:27 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 04 Jul 2022 21:39:26 +0200
Message-ID: <>
To: "" <>
Cc: "Scharf, Michael" <>, Gyan Mishra <>, Last Call <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000db223505e2ffe4dd"
Archived-At: <>
Subject: Re: [tcpm] [Last-Call] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07
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: Mon, 04 Jul 2022 19:39:34 -0000


I think the crux is here:

> remotely managed.

For me YANG is about visibility (or nowadays observability) (like was/is
SNMP MIB) and not about remote management. I would never set any TCP
parameters remotely as it does not make sense. That's role of client app
via socket API.

So lot's of TCP parameters makes sense to me to observe state of TCP
session irrespective on what is the client above it from remote controller.
Especially that telemetry may use YANG format for packing this info.

Then what is missing - everything which I could see by using local OS hooks
into kernel. That is all TCP parameters as well as connection state.


On Mon, Jul 4, 2022 at 9:30 PM <>

> > On Jul 4, 2022, at 12:15 PM, Robert Raszuk <> wrote:
> >
> > Hi,
> >
> > > Any application can decide to configure TCP parameters as far as
> possible in the given operation
> > > system, e.g., via the sockets API. That is orthogonal to the internals
> of the TCP implementation and the TCP protocol.
> >
> > While clients running on top of TCP can configure its parameters I would
> at least expect to be able to report such values (local and remote) when
> using the TCP YANG model. For example I can not find the Urgent Flag in the
> current YANG model.
> That’s because URG is not a property of the TCP connection; it’s a
> property of a segment, not the connection. The same is true for PSH.
> > Same for elementary window size of any given connection, same for
> connection duration, .
> There is no such thing as “elementary window size”. There are a variety of
> window parameters, i.e., send window, congestion window, receive window.
> Only the send and receive windows are application / OS set.
> If there’s a list of desired parameters, it would be useful to start by
> stating them in terms of the TCP specs and explaining why they need to be
> remotely managed.
> Joe