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.