Subject: [Idr] Fwd: Last Call: <draft-ietf-tcpm-yang-tcp-06.txt> (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard

From: Alvaro Retana <[email-masked]>
Date: Tue, 22 Feb 2022 12:42:58 -0800

FYI..

On February 16, 2022 at 5:44:30 PM, The IESG ([email-masked])
wrote:

The IESG has received a request from the TCP Maintenance and Minor
Extensions
WG (tcpm) to consider the following document: - 'A YANG Model for
Transmission Control Protocol (TCP) Configuration'
<draft-ietf-tcpm-yang-tcp-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2022-03-02. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

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 compliant with Network Management Datastore Architecture (NMDA)
(RFC 8342).

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Feb 2022 16:20:13 -0500

Alvaro,

Thanks for bringing this to our attention.  

I don't think there's any implications on the BGP YANG module we care about from this document.  Mahesh is an author on both, so I suspect review has been done.

I'm a little surprised at the lack of certain counters in this TCP YANG module.  I'll take a look at the IETF archives (I've not followed this work) and reply to the appropriate thread, if necessary

-- Jeff

> On Feb 22, 2022, at 3:42 PM, Alvaro Retana <[email-masked]> wrote:
> 
> FYI..
> 
> 
> On February 16, 2022 at 5:44:30 PM, The IESG ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> 
>> The IESG has received a request from the TCP Maintenance and Minor Extensions 
>> [email-masked] <mailto:[email-masked]> mailing lists by 2022-03-02. Exceptionally, comments may 
>> be sent to [email-masked] <mailto:[email-masked]> instead. In either case, please retain the beginning 
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/ <https://datatracker.ietf.org/doc/draft-ietf-tcpm-yang-tcp/> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce> 
> Idr mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/idr <https://www.ietf.org/mailman/listinfo/idr>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 22 Feb 2022 13:24:46 -0800

Hi Jeff,

> On Feb 22, 2022, at 1:20 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Alvaro,
> 

The only known implication is the use of TCP-AO or MD5 in securing a BGP session.

Thanks.

>> On Feb 22, 2022, at 3:42 PM, Alvaro Retana <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> FYI..
>> 
>> 

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Feb 2022 16:41:13 -0500

Mahesh,

> On Feb 22, 2022, at 4:24 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi Jeff,
> 
>> On Feb 22, 2022, at 1:20 PM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Alvaro,
>> 

... of which the TCP module says "yes, you're using it" and "here are the IDs in each direction.

Digging further, I'm unclear on a bit of the module inter-work.  Using the example fo the bgp yang module which references a key chain (leaf ao-keychain), and a keychain from RFC 8177, what module is expected to configure the send-id/receive-id for a session?  RFC 8177 only casually mentions tcp-ao and notes that a keychain may be used by a KDF in TCP-AO.

I think I spoke too quickly.  How is an implementation expected to set MKT IDs as a client?  How is rollover of MKT handled in the model?  Is the responsibility up to RFC 8177 or extensions?

What is likely needed is (no surprise, Mahesh), some example that demonstrates interwork across the modules.

And yes, if the TCP YANG authors say "it's not in our stuff, it belongs in the client", the BGP module can be the example case.  That said, I suspect the real desire is that the keychain infrastructure handle this.  Is there any followup work for 8177 in progress?

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 22 Feb 2022 15:01:47 -0800

Hi Jeff,

> Digging further, I'm unclear on a bit of the module inter-work.  Using the example fo the bgp yang module which references a key chain (leaf ao-keychain), and a keychain from RFC 8177, what module…

The client is expected to configure the send/receive ids. In the case of BGP YANG module, it will be BGP that will have to configure. I can expand the example that we currently have in the draft to include configuration of send/receive id. And yes, the model references a keychain from the keychain module, leaving it to that module to define the keychain. 

> I think I spoke too quickly.  How is an implementation expected to set MKT IDs as a client?  How is rollover of MKT handled in the model?  Is the responsibility up to RFC 8177 or extensions?

That is outside the scope of the BGP YANG model.

> And yes, if the TCP YANG authors say "it's not in our stuff, it belongs in the client", the BGP module can be the example case.  That said, I suspect the real desire is that the keychain infrastruc…

In essence, yes this belongs in the keychain infrastructure area. I am not aware of any followup work to 8177. Since this is not a problem limited to BGP, I believe it should be solved generically even as we are ones to highlight it.

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 25 Feb 2022 16:42:43 -0500

Brief note for the list archive:

On Tue, Feb 22, 2022 at 04:41:13PM -0500, Jeffrey Haas wrote:
> Digging further, I'm unclear on a bit of the module inter-work.  Using the
> example fo the bgp yang module which references a key chain (leaf
> ao-keychain), and a keychain from RFC 8177, what module is expected to
> configure the send-id/receive-id for a session?  RFC 8177 only casually
> mentions tcp-ao and notes that a keychain may be used by a KDF in TCP-AO.

Discussing this off-line, I think we've convinced Mahesh these and other
things are open issues to resolve.  That work will likely revert to the tcpm
list.

-- Jeff