Re: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt

mohamed.boucadair@orange.com Mon, 03 January 2022 09:13 UTC

Return-Path: <mohamed.boucadair@orange.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 64DBE3A0D26 for <tcpm@ietfa.amsl.com>; Mon, 3 Jan 2022 01:13:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NmBFebJugtk for <tcpm@ietfa.amsl.com>; Mon, 3 Jan 2022 01:13:29 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (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 BDB123A0D24 for <tcpm@ietf.org>; Mon, 3 Jan 2022 01:13:28 -0800 (PST)
Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4JS95c3Vs7z8vGV; Mon, 3 Jan 2022 10:13:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1641201204; bh=U4bURJj0G9IEKTMZdIi/uaIJqNAaWxPuAIG8DTQaWMg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=SyUyyVf5l53/2/YinU1HMtD5bOGzguSoUn/ItQdchyjPbzU9dEmTb3hYORULDuA+Z c6TS5HJwwc+hSq1kXoHmwXyVSypVLKw9kr42RQRGUEcdpNLnYFIcQBm6uaKC0b8flp 0IjglA57vOK5iNoeRJ9lyb0uAe8SComiooc+An3WO6UlrXanJEGqGD/T1geSdHaCAl urPrHjfaU+wfonxKhjCiHuhR6mt/nE/TPwzlN8G0OmI7M5Urzpa9whfgOz4DmwrgIu c/hNXsUY4OJfI4La7WsS+JQahkr3lLHTx1ry9QdXoeqwUHtxJhlIJkoyrFueYz/oGa o3plC38Z+4a8g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar07.francetelecom.fr (ESMTP service) with ESMTPS id 4JS95c2dByz5vNB; Mon, 3 Jan 2022 10:13:24 +0100 (CET)
From: mohamed.boucadair@orange.com
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt
Thread-Index: AQHXyc25qfTSowdLSEa6dKhesfqRYKv/uF0AgEvBUuCABenxUA==
Content-Class:
Date: Mon, 03 Jan 2022 09:13:23 +0000
Message-ID: <3337_1641201204_61D2BE34_3337_132_1_787AE7BB302AE849A7480A190F8B93303546BDC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <163518613944.7645.2494692847367626249@ietfa.amsl.com> <18622_1636712195_618E3F03_18622_35_1_787AE7BB302AE849A7480A190F8B933035450859@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <bde902389b8a4c76aae776ea2d68d9ce@hs-esslingen.de>
In-Reply-To: <bde902389b8a4c76aae776ea2d68d9ce@hs-esslingen.de>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-01-03T08:26:45Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=49c250bb-949e-4569-b0b4-01c9d91c8976; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/vhe6-Bi58ZcgwvTYekmqGh7wTnY>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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, 03 Jan 2022 09:13:33 -0000

Hi Michael, 

The changes look good. Thank you. 

Please find below some comments on the new version: 
- Section 4

(1)
OLD: 
       reference
         "RFC XXXX, YANG Model for Transmission Control Protocol (TCP)
                    Configuration.";

NEW:
       reference
         "RFC XXXX: A YANG Model for Transmission Control Protocol (TCP)
                    Configuration";

(2)

Add "when set to true" in the description of almost all the Boolean nodes. 

(3)

I still don't think "forms the connection identifier" is accurate. The connection is identified by the 4-uple (which is captured in the key statement). You may consider simply: s/forms the connection identifier/of the connection. Another better approach would be, e.g.: 

OLD: 
 "Local address that forms the connection identifier.";
NEW:
 "Identifies the address that is used locally by an endpoint to bind the connection.";

OLD: 
 "Remote address that forms the connection identifier.";
NEW:
 "Identifies the address that is used by the peer endpoint to bind the connection.";

etc. 

- Make this change in 5.2: s/registrations are requested/registration is requested
- Update 5.2 to make it explicit that the module is not maintained by IANA: 

OLD:
      name:         ietf-tcp
      namespace:    urn:ietf:params:xml:ns:yang:ietf-tcp
      prefix:       tcp
      reference:    RFC XXXX

NEW:
      name:         ietf-tcp
      namespace:    urn:ietf:params:xml:ns:yang:ietf-tcp
      prefix:       tcp
      maintained by IANA: N
      reference:    RFC XXXX 

- I think you can remove the note in B.1
- remove "\" right after "</description>" in B.2
- As you are referring to RFC 8792, you need to add the 8792 header to adhere with the following (B.2):

======
...
   Text content that has been folded as specified by this strategy MUST
   adhere to the following structure.

7.1.1.  Header

   The header is two lines long.

   The first line is the following 36-character string; this string MAY
   be surrounded by any number of printable characters.  This first line
   cannot itself be folded.

   NOTE: '\' line wrapping per RFC 8792

   The second line is an empty line, containing only the end-of-line
   character sequence.  This line provides visual separation for
   readability.
=====

- B.2:

<!--
This example sets TCP-AO configuration parameters as
demonstrated by examples in draft-touch-tcpm-ao-test-vectors.
-->

Not sure why this I-D is cited here given the example does not echo an example from that I-D (e.g., same local/remote port, local address, etc.). Also, I was expecting to see an example that illustrates the use of send-id and recv-id.

If the citation is maintained, please make this change: 

s/demonstrated by examples in draft-touch-tcpm-ao-test-vectors/demonstrated by examples in I-D.ietf-tcpm-ao-test-vectors

Cheers,
Med

> -----Message d'origine-----
> De : Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Envoyé : jeudi 30 décembre 2021 15:19
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
> Cc : tcpm@ietf.org
> Objet : RE: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt
> 
> Hi Med,
> 
> Thanks a lot for the detailed review. I went through all your comments.
> Most were straightforward to address.
> 
> Our suggestion is to clearly state that MPTCP is outside the scope of this
> model. MPTCP may need a different YANG model. Yet, the most obvious use
> case of the YANG model are TCP-based control plane protocols on routers
> (BGP, LDP, ...). At least I am not aware of widespread use of BGP over
> MPTCP.
> 
> Can you please have a look at -05 and let me know if -05 works for you?
> 
> The full diff is available at: https://www.ietf.org/rfcdiff?url2=draft-
> ietf-tcpm-yang-tcp-05
> 
> Thanks
> 
> Michael
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com
> > <mohamed.boucadair@orange.com>
> > Sent: Friday, November 12, 2021 11:17 AM
> > To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> > Cc: tcpm@ietf.org
> > Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt
> >
> > Hi Michael,
> >
> > FWIW, please find below some comments to the latest version of the
> draft:
> >
> > * pdf: https://raw.githubusercontent.com/boucadair/IETF-Drafts-
> > Reviews/master/draft-ietf-tcpm-yang-tcp-04-rev%20Med.pdf
> > * doc: https://github.com/boucadair/IETF-Drafts-
> > Reviews/raw/master/draft-ietf-tcpm-yang-tcp-04-rev%20Med.doc
> >
> > I think that the document is almost stable. Thank you.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : tcpm <tcpm-bounces@ietf.org> De la part de
> > > internet-drafts@ietf.org Envoyé : lundi 25 octobre 2021 20:22 À :
> > > i-d-announce@ietf.org Cc : tcpm@ietf.org Objet : [tcpm] I-D Action:
> > > draft-ietf-tcpm-yang-tcp-04.txt
> > >
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > > This draft is a work item of the TCP Maintenance and Minor
> > > Extensions WG of the IETF.
> > >
> > >         Title           : YANG Model for Transmission Control Protocol
> > > (TCP) Configuration
> > >         Authors         : Michael Scharf
> > >                           Mahesh Jethanandani
> > >                           Vishal Murgai
> > > 	Filename        : draft-ietf-tcpm-yang-tcp-04.txt
> > > 	Pages           : 23
> > > 	Date            : 2021-10-25
> > >
> > > Abstract:
> > >    This document specifies a minimal YANG model for TCP on devices
> that
> > >    are configured by network management protocols.  The YANG model
> > >    defines a container for all TCP connections and groupings of
> > >    authentication parameters that can be imported and used in TCP
> > >    implementations or by other models that need to configure TCP
> > >    parameters.  The model also includes basic TCP statistics.  The
> model
> > >    is NMDA (RFC 8342) compliant.
> > >
> > >
> > > The IETF datatracker status page for this draft is:
> > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/
> > >
> > > There is also an htmlized version available at:
> > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-04
> > >
> > > A diff from the previous version is available at:
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-04
> > >
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tcpm
> >
> > __________________________________________________________
> > __________________________________________________________
> > _____
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> > exploites ou copies sans autorisation. Si vous avez recu ce message
> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> > que les pieces jointes. Les messages electroniques etant susceptibles
> > d'alteration, Orange decline toute responsabilite si ce message a ete
> > altere, deforme ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or
> > privileged information that may be protected by law; they should not
> > be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> > been modified, changed or falsified.
> > Thank you.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.