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

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 4 Feb 2022 21:11:37 +0000

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 <[email-masked]> On Behalf Of Scharf, Michael
> Sent: Tuesday, January 18, 2022 10:32 PM
> To: [email-masked]
> Cc: [email-masked]
> 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: [email-masked]
> > <[email-masked]>
> > Sent: Monday, January 3, 2022 10:13 AM
> > To: Scharf, Michael <[email-masked]>
> > Cc: [email-masked]
> > 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 <[email-masked]>
> > > Envoyé : jeudi 30 décembre 2021 15:19
> > > À : BOUCADAIR Mohamed INNOV/NET
> > <[email-masked]>
> > > Cc : [email-masked]
> > > 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: [email-masked]
> > > > <[email-masked]>
> > > > Sent: Friday, November 12, 2021 11:17 AM
> > > > To: Scharf, Michael <[email-masked]>
> > > > Cc: [email-masked]
> > > > 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 <[email-masked]> De la part de
> > > > > [email-masked] Envoyé : lundi 25 octobre 2021 20:22 À :
> > > > > [email-masked] Cc : [email-masked] 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
> > > > > [email-masked]
> > > > > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: <[email-masked]>
Date: Tue, 8 Feb 2022 08:39:23 +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

> Envoyé : vendredi 4 février 2022 22:12
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : [email-masked]
> > 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.
> > 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.
> >
> > >  "Identifies the address that is used locally by an endpoint to bind
> > > the connection.";
> > >
> > > OLD:
> > >  "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
> > > - As you are referring to RFC 8792, you need to add the 8792 header
> > > to adhere with the following (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.
> > >
> > > > De : Scharf, Michael <[email-masked]> Envoyé :
> > > > jeudi 30 décembre 2021 15:19 À : BOUCADAIR Mohamed INNOV/NET
> > > > 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
> > > > (BGP, LDP, ...). At least I am not aware of widespread use of BGP
> > > > over MPTCP.
> > > >
> > > > > > A New Internet-Draft is available from the on-line
> > > > > > Internet-Drafts directories.
> > > > > 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.
> > > > >
> > > > > 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.
> > >
> > >
> > >
> > > 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.
> > >
> > > 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.

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 8 Feb 2022 07:16:31 -0800

Hi, Med,

I disagree. The addresses in test vectors are not examples for documentation, but rather an actual configuration intended for testing purposes.

I found only one other RFC that provides test vectors based on packet fields that include IP addresses: RFC 5769, but it (IMO) incorrectly uses the documentation addresses you suggest (I expect to submit an errata on that shortly - let me know if you know of others).

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Feb 8, 2022, at 12:39 AM, [email-masked] wrote:
> 
> Hi Michael, 
> 
> Thank you. 
>

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 9 Feb 2022 10:42:26 +0000

Hi all,

My proposal would be to await the IESG evaluation of draft-ietf-tcpm-ao-test-vectors. This detail is mentioned in my shepherd write-up as a heads-up.

If the addresses in draft-ietf-tcpm-ao-test-vectors have to be modified, the example in draft-ietf-tcpm-yang-tcp will change as well.

Best regards

Michael

From: [email-masked] <[email-masked]>
Sent: Tuesday, February 8, 2022 4:17 PM
To: [email-masked]
Cc: Scharf, Michael <[email-masked]>; [email-masked]
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt

Hi, Med,

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>

On Feb 8, 2022, at 12:39 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Michael,

Thank you.

Cheers,
Med

-----Message d'origine-----
De : Scharf, Michael <[email-masked]<mailto:[email-masked]>>
Envoyé : vendredi 4 février 2022 22:12
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt

The diff can be found at: https://www.ietf.org/rfcdiff?url2=draft-ietf-
tcpm-yang-tcp-06.txt

Michael

-----Original Message-----
From: tcpm <[email-masked]<mailto:[email-masked]>> On Behalf Of Scharf, Michael
Sent: Tuesday, January 18, 2022 10:32 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt

Hi Med,

Thanks

Michael (as author)

-----Original Message-----
From: [email-masked]<mailto:[email-masked]>
<[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 3, 2022 10:13 AM
To: Scharf, Michael <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-04.txt

Hi Michael,

(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.

OLD:

OLD:

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

NEW:
     name:         ietf-tcp

======
...
  Text content that has been folded as specified by this strategy
MUST

7.1.1.  Header

  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.

- B.2:

<!--

Cheers,
Med

-----Message d'origine-----
De : Scharf, Michael <[email-masked]<mailto:[email-masked]>> Envoyé :
jeudi 30 décembre 2021 15:19 À : BOUCADAIR Mohamed INNOV/NET
<[email-masked]<mailto:[email-masked]>>

Cc : [email-masked]<mailto:[email-masked]>
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.

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: [email-masked]<mailto:[email-masked]>
<[email-masked]<mailto:[email-masked]>>
Sent: Friday, November 12, 2021 11:17 AM
To: Scharf, Michael <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
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:

Cheers,
Med

-----Message d'origine-----
De : tcpm <[email-masked]<mailto:[email-masked]>> De la part de
[email-masked]<mailto:[email-masked]> Envoyé : lundi 25 octobre 2021 20:22
À :

[email-masked]<mailto:[email-masked]> Cc : [email-masked]<mailto:[email-masked]> Objet : [tcpm] I-D
Action:

       Title           : YANG Model for Transmission Control
Protocol

(TCP) Configuration
       Authors         : Michael Scharf
                         Mahesh Jethanandani
                         Vishal Murgai

Abstract:
  This document specifies a minimal YANG model for TCP on
devices
that

  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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp
-04

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

_____

_____

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm