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

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Mon, 05 September 2022 08:51 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 5A4B0C152575; Mon, 5 Sep 2022 01:51:49 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 (1024-bit key) header.d=hs-esslingen.de
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 iVQnGxmwyCia; Mon, 5 Sep 2022 01:51:45 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD52C152574; Mon, 5 Sep 2022 01:51:44 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AE7D825A3F; Mon, 5 Sep 2022 10:51:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1662367901; bh=BJY2IsqBy2e5TPgHJce3qmAHd2pMIqT8Ra31AzoXuwA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bwM7wFG1DCEmD7HupKDaJZPUrc5bglxIcMAyQDoWwEp7PVKIuBONkzav9Ab6oh6nJ PWakxo3t2fiW68fsTwMd1knANoTzQWTEf+XBYGXONj65UQ+4sd2L9n8l/l1w63e+KV TVp/rEpWwOSMYEvhIjE/ZpWnhBRAzfG5zIQ6/DfE=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_nJd7hryyrO; Mon, 5 Sep 2022 10:51:40 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 5 Sep 2022 10:51:40 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 5 Sep 2022 10:51:40 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2375.031; Mon, 5 Sep 2022 10:51:40 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tcpm-yang-tcp@ietf.org" <draft-ietf-tcpm-yang-tcp@ietf.org>, "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "nsd.ietf@gmail.com" <nsd.ietf@gmail.com>
Thread-Topic: Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and COMMENT)
Thread-Index: AQHYiu4OHFB4M75MGE6fQ+kEmdbYV63KviNA
Date: Mon, 05 Sep 2022 08:51:40 +0000
Message-ID: <c8e569938400487c85c13849bc366ebf@hs-esslingen.de>
References: <165642080074.47890.4087202101509957926@ietfa.amsl.com>
In-Reply-To: <165642080074.47890.4087202101509957926@ietfa.amsl.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/k8Q56xDBruN-nvbM3m75kLCMA-c>
Subject: Re: [tcpm] Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-yang-tcp-07: (with DISCUSS and 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: Mon, 05 Sep 2022 08:51:49 -0000

Hi Zahed,

Thanks for these good comments and sorry that it took so long to prepare a reply.

The authors have published a version -08 that hopefully addresses all these issues. The full diff for -08 is available at:  https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-08

> -----Original Message-----
> From: Zaheduzzaman Sarker via Datatracker <noreply@ietf.org>
> Sent: Tuesday, June 28, 2022 2:53 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-tcpm-yang-tcp@ietf.org; tcpm-chairs@ietf.org; tcpm@ietf.org;
> nsd.ietf@gmail.com; nsd.ietf@gmail.com
> Subject: Zaheduzzaman Sarker's Discuss on draft-ietf-tcpm-yang-tcp-07:
> (with DISCUSS and COMMENT)
> 
> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-tcpm-yang-tcp-07: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for working on this useful specification.
> 
> I have noted the following which I think needs cross checking to make the
> meaning clear, it might be simple oversight or intentional. I would like to
> which one is correct.
> 
> - Section 4 :
>      - any reason why the leaf send_id and recv_id does not use normative
>      "MUST" in the description?

I don't think that this is a normative "MUST". In order to avoid any ambiguity, I have reworded this to:

  In a consistent configuration, the SendID matches the RecvID at the other endpoint.

Please let us know if this does not work for you.

>      - how should we interpret strongly " RECOMMENDED"? is this a MUST or
>      RECOMMENDED?

The use of TCP-AO is RECOMMENDED. The new wording in -08 is:

  As the TCP MD5 signature option is obsoleted by TCP-AO, it is	RECOMMENDED to use TCP-AO instead. 

Again, please let us know if this does not address your concern.

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> I have some minor observations, which we might want to address -
> 
> - Section 3.1 : It is not clear to me what is the difference between a "Global
> configuration" and "Policies". To me policies can include global configurations
> that will valid for all the TCP sessions. So, it is not clear is policy is a
> special case of global configuration or vise verse.  Also the term "Global"
> here seems ambiguous. I kind of read that as a global variable definition,
> still the text need to be clear about the scope of "Global" is self, global to
> what context?

Agreed, this terminology may not be perfect. In particular, the term "policy" can mean many things. The proposal is to avoid it with the following new terms:

*  System-wide configuration

*  Interface configuration

*  Connection parameters

*  Application preferences

I hope that this better captures the different cases.

> - What are we really following when we say "directly following from TCP
> standards."? a reference is needed here to understand what is meant here.

I have just removed these words as they are not really needed anyway.

Thanks

Michael