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

[[e-mail]]

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 <[e-mail]> De la part de Scharf, Michael
> Envoyé : vendredi 22 octobre 2021 18:45
> À : t petch <[e-mail]>; Yoshifumi Nishida <[e-mail]>;
> [e-mail] Extensions <[e-mail]>
> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-yang-tcp-03.txt
> 
> > > 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
> >
> > 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.
> 
> 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
> 
> > Tom Petch
> >
> > > --
> > > Yoshi
> > >
> > > On Tue, Oct 19, 2021 at 9:01 AM <[e-mail]> wrote:
> > >
> > >>
> > >> 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/
> > >>
> > >>
> > >> _______________________________________________
> > >> I-D-Announce mailing list
> > >> [e-mail]
> > >> 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
> > >>
> > >
> > >
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> 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.