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

From: [email-masked]
Date: Tue, 19 Oct 2021 09:01:10 -0700

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-03.txt
	Pages           : 22
	Date            : 2021-10-19

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-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-yang-tcp-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 22 Oct 2021 01:12:23 -0700

Hello folks,
The chairs are thinking that the draft is getting close to WGLC.
We'll discuss it at the next meeting, but please share if you have any
comments or concerns on proceeding this draft to WGLC.

We appreciate your feedback
--
Yoshi

On Tue, Oct 19, 2021 at 9:01 AM <[email-masked]> wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: t petch <[email-masked]>
Date: Fri, 22 Oct 2021 09:51:49 +0100

> We appreciate your feedback

While this I-D has been slowly maturing, a rival model of more limited 
scope has made it through the IESG.  I commented on the different 
approaches and got some changes to bring the rival model in line with 
this one but not all.  I think that the authors of this I-D should 
review the relevant parts of opsawg-l3sm-l3nm in its final version and 
decide what to do with the differences.  Probably nothing but perhaps 
recognise and note that there are differences, if only implicitly, by 
stressing the approach taken here.

More parochially, is it time for this I-D to build on 793bis and not 793?

The web reference is insecure and ood.

The title in the reference clause is not that of the I-D.

The IANA COnsiderations do not follow the template of RFC6020.

Tom Petch

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

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 22 Oct 2021 16:45:13 +0000

> stressing the approach taken here.

To those who do not follow OPSAWG, please be aware of this thread there ...

https://mailarchive.ietf.org/arch/msg/opsawg/40yHqHdFSGiqo2iOl_lG5UB6MVg/

... as well as the acknowledgement in draft-ietf-opsawg-l3sm-l3nm-18 "Thanks to Michael Scharf for the discussion on TCP-AO."

The key difference is that draft-ietf-opsawg-l3sm-l3nm-18 does not specify any way to set the SendID and RecvID of TCP-AO, even though this is one of the configuration parameters that matters for TCP-AO. The authors of draft-ietf-opsawg-l3sm-l3nm prefer that approach.

We have discussed this difference on the OPSAWG list, and as result I have added in -03 of the TCPM draft the following sentence to stress that: "The model defined in this document includes the required parameters for TCP-AO configuration, such as the values of SendID and RecvID."

We could add a reference to draft-ietf-opsawg-l3sm-l3nm as well. I haven't though about that when finalizing -03, but it is reasonable suggestion. Thanks.

Note, however, that I disagree with the term "rival model".

First, draft-ietf-opsawg-l3sm-l3nm only overlaps with draft-ietf-tcpm-yang-tcp regarding the TCP-AO / MD5 configuration, not with any of the other parts of the model (which basically provide an equivalent to the widely implemented TCP-MIB). So, there is only a small overlap, and we have tried our best to align the two drafts.

Second, draft-ietf-opsawg-l3sm-l3nm overlaps with *many* other YANG models in the IEZF, as it picks a subset of the protocol configuration parameters for many IETF protocol as far as they matter for a VPN site. The fact that there is overlap is nothing specific to this TCPM document.

However, a TCP YANG model is not only needed for a L3VPN site, but e.g. for the native PE or ASBR router configuration, too. This is where draft-ietf-tcpm-yang-tcp would be used.

> More parochially, is it time for this I-D to build on 793bis and not 793?

Good catch, I have suggested the same recently in other context ( https://mailarchive.ietf.org/arch/msg/tcpm/WF6OApDuj_nSlY_S-J-G1bgxWp0/ ). 

IMHO we should start referencing 793bis in all documents last called in TCPM after 793bis. I should have done that myself... Mea culpa...

Note, however, that so far there is no clear consensus in TCPM on when to use 793bis as new normative reference for TCP, mostly since 793bis is still in IESG evaluation. 

> The web reference is insecure and ood.

Good catch. Thanks.

> The title in the reference clause is not that of the I-D.

Yep, albeit that text will have to be fixed by the RFC Editor anyway.

> The IANA COnsiderations do not follow the template of RFC6020.

Mahesh may be in a better position to comment on that. 

Thanks for the comments!

Michael

> >> This draft is a work item of the TCP Maintenance and Minor Extensions
> WG
> >> of the IETF.
> >>

---

From: <[email-masked]>
Date: Mon, 25 Oct 2021 08:52:01 +0000

Hi all,

Like Michael, I disagree with the "rival model" mentioned in Tom's initial message. 

The L3NM is a network model that touches a large set of technologies (routing, qos, security, ...). We had to find a balance between usability/usefulness vs. exhaustiveness and navigate in an area where it is easy to create a large document cluster that will take years before being published as an RFC. We also need to ack current implementations (some pointers are provided in the thread mentioned by Michael), hence this note in the opsawg I-D:

      This version of the L3NM assumes that TCP-AO specific parameters
      are preconfigured as part of the key-chain that is referenced in
      the L3NM.  No assumption is made about how such a key-chain is
      pre-configured.  However, the structure of the key-chain should
      cover data nodes beyond those in [RFC8177], mainly SendID and
      RecvID (Section 3.1 of [RFC5925]).

draft-ietf-tcpm-yang-tcp can be updated to indicate that it can be used (especially, the ao grouping) as part of the preconfiguration mentioned in this note. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : tcpm <[email-masked]> De la part de Scharf, Michael
> Envoyé : vendredi 22 octobre 2021 18:45
> À : t petch <[email-masked]>; Yoshifumi Nishida <[email-masked]>;
> [email-masked] Extensions <[email-masked]>
> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-03.txt
> 
> > > Hello folks,
> > > We'll discuss it at the next meeting, but please share if you have
> > > any comments or concerns on proceeding this draft to WGLC.
> > >
> ... as well as the acknowledgement in draft-ietf-opsawg-l3sm-l3nm-18
> "Thanks to Michael Scharf for the discussion on TCP-AO."
> 
> The key difference is that draft-ietf-opsawg-l3sm-l3nm-18 does not specify
> any way to set the SendID and RecvID of TCP-AO, even though this is one of
> the configuration parameters that matters for TCP-AO. The authors of
> draft-ietf-opsawg-l3sm-l3nm prefer that approach.
> 
> We have discussed this difference on the OPSAWG list, and as result I have
> added in -03 of the TCPM draft the following sentence to stress that: "The
> model defined in this document includes the required parameters for TCP-AO
> configuration, such as the values of SendID and RecvID."
> 
> We could add a reference to draft-ietf-opsawg-l3sm-l3nm as well. I haven't
> though about that when finalizing -03, but it is reasonable suggestion.
> Thanks.
> 
> First, draft-ietf-opsawg-l3sm-l3nm only overlaps with draft-ietf-tcpm-
> yang-tcp regarding the TCP-AO / MD5 configuration, not with any of the
> other parts of the model (which basically provide an equivalent to the
> widely implemented TCP-MIB). So, there is only a small overlap, and we
> have tried our best to align the two drafts.
> 
> Second, draft-ietf-opsawg-l3sm-l3nm overlaps with *many* other YANG models
> in the IEZF, as it picks a subset of the protocol configuration parameters
> for many IETF protocol as far as they matter for a VPN site. The fact that
> there is overlap is nothing specific to this TCPM document.
> 
> However, a TCP YANG model is not only needed for a L3VPN site, but e.g.
> for the native PE or ASBR router configuration, too. This is where draft-
> ietf-tcpm-yang-tcp would be used.
> 
> Good catch, I have suggested the same recently in other context (
> https://mailarchive.ietf.org/arch/msg/tcpm/WF6OApDuj_nSlY_S-J-G1bgxWp0/ ).
> 
> IMHO we should start referencing 793bis in all documents last called in
> TCPM after 793bis. I should have done that myself... Mea culpa...
> 
> Note, however, that so far there is no clear consensus in TCPM on when to
> use 793bis as new normative reference for TCP, mostly since 793bis is
> still in IESG evaluation.
> 
> > >>          Title           : YANG Model for Transmission Control
> Protocol
> > >> (TCP) Configuration
> > >>          Authors         : Michael Scharf
> > >>                            Mahesh Jethanandani
> > >>                            Vishal Murgai
> > >> Internet-Draft directories: http://www.ietf.org/shadow.html or
> > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >>
> > >
> > >
> > >

_________________________________________________________________________________________________________________________

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: t petch <[email-masked]>
Date: Mon, 25 Oct 2021 10:46:03 +0100

>>> We appreciate your feedback

Further to my comments on http and 793bis,

all YANG import need a Normative Reference

I would like a more comprehensive comparison with RFC4022 - other I-D 
have provided a table showing the objects or groups thereof which carry 
across and those that do not.

You mention other models which model TCP - for me the most comprehensive 
would be in I2NSF

0..255 could be 0..max

MD5 needs calling out as no longer strong enough both in the YANG module 
and in Security Considerations, perhaps making AO the default, perhaps 
making MD5 deprecated.  The Security AD will do this if noone else does 
but why make work for him?  opsawg-l3sm-l3nm and dhcpv6-yang went this 
way recently

the statistics with their protocol detail need references even if every 
one is 793bis

YANG 'action' could probably do with a NACM default deny-all

5.1 This document registers two URIs...
Really?

Examples should use documentation IP addresses

An IPv6 example might create a good impression

The convention for line wrap would be better for a reference to RFC8792

Tom Petch

> .