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

mohamed.boucadair@orange.com Tue, 08 February 2022 08:39 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 A0F7C3A0CAC for <tcpm@ietfa.amsl.com>; Tue, 8 Feb 2022 00:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 Yd7ou0adOMnI for <tcpm@ietfa.amsl.com>; Tue, 8 Feb 2022 00:39:26 -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 92EFC3A0CB0 for <tcpm@ietf.org>; Tue, 8 Feb 2022 00:39:26 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) (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 opfedar20.francetelecom.fr (ESMTP service) with ESMTPS id 4JtGdn0Jpvz8svW; Tue, 8 Feb 2022 09:39:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1644309565; bh=HWW0WSL1Dua/F5rORfRblPFvqoBkPpUF2FH3AhnLFoU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=OwbLb3OjVfMp9lDGc+ebCUgE1sddZBUHMpX15JbAxIuuR0U/+RSuOYgdNAqecZOOj XJjHlS6nECUboieklLPDt+IlVZ4v1S/IcRvvyFaXg7gZlaf1CSn44BGcCZKHdGTTsd wWW3Pq45APj2DswCQ8x+e/QoCH7EQ19jjbeoogeS04qMCbuSylfvbfxPVyuzQkUZEa 0NpeUBCO7HXEyZxqEs9Mv3x6QI3m2xpxmwHPnPx8UHgFh8KGiukWmHVsPz4Yr+JugE K4+0A9awffVv9+h8Znyc8lMT92rr0rGymG8inKo11QoPa0MIllWag+nCptrg/6snaQ RqL60X06SBYrQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar02.francetelecom.fr (ESMTP service) with ESMTPS id 4JtGdm6bsHzCqkP; Tue, 8 Feb 2022 09:39: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/uF0AgEvBUuCABenxUIAYa72QgBqz19CABXaAYA==
Content-Class:
Date: Tue, 8 Feb 2022 08:39:23 +0000
Message-ID: <18668_1644309564_62022C3C_18668_151_1_787AE7BB302AE849A7480A190F8B93303548DD57@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> <3337_1641201204_61D2BE34_3337_132_1_787AE7BB302AE849A7480A190F8B93303546BDC5@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <706848a62fd74d18a34566046369d049@hs-esslingen.de> <bdc3831619dd442dbc5e2914fff7a2b5@hs-esslingen.de>
In-Reply-To: <bdc3831619dd442dbc5e2914fff7a2b5@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-02-08T08:34:21Z; 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=918be82b-2241-4d63-9cc9-9ad158f11070; 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/Uk70daQeFiKWGKtxG4c2SxeaeeY>
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: Tue, 08 Feb 2022 08:39:32 -0000

Hi Michael, 

Thank you. 

There is one minor comment about the ipv6 addresses in the examples: they should be derived from the prefix in RFC 3849. This should be fixed in draft-ietf-tcpm-ao-test-vectors (the same applies for 10.11.12.13, etcs that are not from the blocks defined in 5737). 

Other than that, this looks good to me. Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Envoyé : vendredi 4 février 2022 22:12
> À : 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
> 
> For what it is worth, -06 with the mentioned changes has been published.
> 
> The diff can be found at: https://www.ietf.org/rfcdiff?url2=draft-ietf-
> tcpm-yang-tcp-06.txt
> 
> I hope that this update fixes all issues.
> 
> Michael
> 
> > -----Original Message-----
> > From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Scharf, Michael
> > Sent: Tuesday, January 18, 2022 10:32 PM
> > To: mohamed.boucadair@orange.com
> > Cc: tcpm@ietf.org
> > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt
> >
> > Hi Med,
> >
> > Thanks a lot for this further review with good catches.
> >
> > We have addressed all comments in the current working copy for -06,
> > except for the disclaimer text regarding line wrap in B.1. This
> > disclaimer is currently automatically introduced by the build tools no
> matter whether it is needed.
> > That detail can be sorted out later by the RFC editor.
> >
> > Details can be found at the repository with the working copy:
> > https://github.com/mjethanandani/ietf-tcp
> >
> > Our suggestion is to change the TCP-AO example so that it illustrates
> > the use of send-id and recv-id with parameters documented in
> > draft-ietf-tcpm-ao- test-vectors.
> >
> > As the WGLC is ongoing, we would wait for further comments before
> > finalizing -06.
> >
> > Thanks
> >
> > Michael (as author)
> >
> >
> > > -----Original Message-----
> > > From: mohamed.boucadair@orange.com
> > > <mohamed.boucadair@orange.com>
> > > Sent: Monday, January 3, 2022 10:13 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,
> > >
> > > 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.
> >
> > _______________________________________________
> > 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.