A YANG Model for Transmission Control Protocol (TCP) Configuration and State
draft-ietf-tcpm-yang-tcp-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2022-09-19
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-09-16
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-09-16
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-09-16
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-09-12
|
09 | (System) | RFC Editor state changed to MISSREF |
2022-09-12
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-09-12
|
09 | (System) | Announcement was received by RFC Editor |
2022-09-12
|
09 | (System) | IANA Action state changed to In Progress |
2022-09-12
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-09-12
|
09 | Cindy Morgan | IESG has approved the document |
2022-09-12
|
09 | Cindy Morgan | Closed "Approve" ballot |
2022-09-12
|
09 | Cindy Morgan | Ballot approval text was generated |
2022-09-12
|
09 | (System) | Removed all action holders (IESG state changed) |
2022-09-12
|
09 | Martin Duke | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-09-12
|
09 | Roman Danyliw | [Ballot comment] Thank you to Hilarie Orman for the SECDIR review. Thank you for addressing my DISCUSS and COMMENTs point. |
2022-09-12
|
09 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2022-09-11
|
09 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-09.txt |
2022-09-11
|
09 | Mahesh Jethanandani | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2022-09-11
|
09 | Mahesh Jethanandani | Uploaded new revision |
2022-09-09
|
08 | Paul Wouters | [Ballot comment] old DISCUSSes: [ballot text incomplete as cloudflare triggers a weird refusal if I include a certain sentence, see Cloudflare Ray ID: 722aa6477e01a1db] Thanks … [Ballot comment] old DISCUSSes: [ballot text incomplete as cloudflare triggers a weird refusal if I include a certain sentence, see Cloudflare Ray ID: 722aa6477e01a1db] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be caused by a limited understanding of the underlying yang model inclusions. 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. #D1 To me, it seems very counter-intuitive that '' means (0.0.0.0 or ::). For LISTEN, I find it concerning because it means that '' as a default means to listen to any IP, rather than the more secure default of '' meaning 'none'. Is it possible to have some kind of "None" default? (or is that achieved by omission of this option? #D2 Is it intended that this cannot be specified using names #C1 It is unclear to me if '0.0.0.0' denotes the type inet:ip-address or the type string with text value "0.0.0.0". I also worry that if this is represented in C with a struct with union, that than it is unclear what a zero'ed out struct is set to? The string or the v4 ANY or the v6 ANY ? (I personally like enums to start from value 1 for that reason) #C2 How is this option set when fully disabled (eg not listening on anything, only willing to make an outgoing TCP connection). Is it by being omitted? NITS: listner -> listener for TCP connection that -> for a TCP connection that |
2022-09-09
|
08 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss |
2022-09-05
|
08 | Zaheduzzaman Sarker | [Ballot comment] Thanks for addressing my discuss points. Thanks for the effort on this specification. |
2022-09-05
|
08 | Zaheduzzaman Sarker | [Ballot Position Update] Position for Zaheduzzaman Sarker has been changed to No Objection from Discuss |
2022-08-31
|
08 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-08-31
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-08-31
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-08-31
|
08 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-08.txt |
2022-08-31
|
08 | Mahesh Jethanandani | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2022-08-31
|
08 | Mahesh Jethanandani | Uploaded new revision |
2022-07-23
|
07 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. Submission of review completed at an earlier date. |
2022-07-17
|
07 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. |
2022-07-03
|
07 | Gyan Mishra | Request for Telechat review by OPSDIR Completed: Not Ready. Reviewer: Gyan Mishra. Sent review to list. |
2022-06-30
|
07 | (System) | Changed action holders to Martin Duke, Mahesh Jethanandani, Michael Scharf, Vishal Murgai (IESG state changed) |
2022-06-30
|
07 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2022-06-30
|
07 | Robert Wilton | [Ballot comment] Hi, Thanks for another YANG module! I have some non-blocking comments, I suspect that many of these have already been raised/discussed so really … [Ballot comment] Hi, Thanks for another YANG module! I have some non-blocking comments, I suspect that many of these have already been raised/discussed so really just want to check that they had been proactively considered. 1) TCP connection list: Access to status information for all TCP connections. Note, the connection table is modeled as a list that is read-writeable, even though a connection cannot be created by adding entries to the table. Similarly, deletion of connections from this list is implementation-specific. I think that it would be helpful to further describe and perhaps constrain the behaviour here: - I would suggest clarifying that the list is read/writable to allow configuration to be associated with existing connections, or connections that may be subsequently made. - It would be helpful to understand what happens if the configuration for a connection changes for an existing connection. Does it force the connection to be closed and reopened? Or does it depend on the configuration change? - I don't think that deleting the configuration properties should cause a connection to be closed (although it might cause the connection to flap, as per my comment above.) E.g., for BGP, isn't it the BGP neighbour configuration that should control whether a connection logically exists? 2) With the ambiguity regarding YANG IP address and zones, can I clarify that in all cases, the intention is that zoned ip-addresses are allowed where the inet:ip-address type is used? 3) leaf enable-ao { I presume that there was a conscious decision not to use a presence container here (and hence avoid the need for the must statements)? 4) leaf enable-md5 { I presume that implementations won't need to add extra MD5 specific parameters? I.e., it doesn't make sense for this to be a presence container? 5) Connection is closed. Connections in this state may not appear in this list."; In the operational state tree then what does the tcp/connections list represent? Does it contain all connections that either exist or have some configuration associated with them? 6) I think that leaf "state" (describing the connection state) should be marked as "config false". A client should not be able to configure the current protocol "state". 7) leaf address { type union { type string; type inet:ip-address; } Given the described behaviour, then I think that you should probably: (i) List the inet:ip-address type first. (ii) Add a length "0" restriction to the string type. 8) For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). What does the h mean? I've got a nagging feeling that this is a known convention ... I presumed that the WG considered and dismissed the option of having two separate listeners listed, one for v4 and one for v6 rather than the union with the string type? 9) list tcp-listeners { key "type address port"; This allows multiple listeners for the same port. I just wanted to check that is allowed/expected? 10) container statistics These counters are global level, so there are not many of them. Some of these counters are 32 bits, I presume that there is no reasonable risk that they would overflow over a reasonable time frame? Nits: included in TCP MIB => included in the TCP MIB TCP-AO TCP-AO [RFC5925] => Duplicate TCP-AO. Thanks, Rob |
2022-06-30
|
07 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-06-30
|
07 | Murray Kucherawy | [Ballot comment] Just some editing suggestions: In Section 1: ... This is conscious decision as these parameters hardly matter in a state-of-the-art TCP … [Ballot comment] Just some editing suggestions: In Section 1: ... This is conscious decision as these parameters hardly matter in a state-of-the-art TCP implementation. It would also be possible also to translate a MIB into a YANG module, ... Need "a" before "conscious", and drop one instance of "also". Section 2.1 should probably indicate that there are lots of places where "I-D.ietf-tcpm-rfc793bis" in the YANG module will need to be replaced by its final RFC number. Section 5.2: OLD: This document registers a YANG module in the "YANG Module Names" registry YANG - A Data Modeling Language [RFC6020]. Following the format in YANG - A Data Modeling Language [RFC6020], the following registration is requested: NEW: The following entry is requested to be added to the "YANG Module Names" registry created by [RFC6020]: |
2022-06-30
|
07 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2022-06-29
|
07 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2022-06-29
|
07 | John Scudder | [Ballot comment] Thanks for this document. I have two minor comments. 1. In §1, * TCP-AO and TCP MD5 configuration for Layer 3 VPNs … [Ballot comment] Thanks for this document. I have two minor comments. 1. In §1, * TCP-AO and TCP MD5 configuration for Layer 3 VPNs is modeled in A Layer 3 VPN Network YANG Model [RFC9182]. This model assumes that TCP-AO specific parameters are preconfigured in addition to the keychain parameters. When you say "this model" are you referring to RFC 9182, or the present document? You could clarify by saying "that model" if you're talking about 9182 (which I think is the case?), or "the present document" if you mean your own spec. 2. In §6, perhaps consider using a different term for an on-path attacker other than "MITM", which conventionally (to my knowledge) expands to "man in the middle". (Or I think you could just drop "e.g. MITM", which doesn't seem to add much.) |
2022-06-29
|
07 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2022-06-29
|
07 | Roman Danyliw | [Ballot discuss] ** B.2. Thanks for providing an example of a TCP-AO configuration. Unfortunately, this isn’t a valid example example and it seems to be … [Ballot discuss] ** B.2. Thanks for providing an example of a TCP-AO configuration. Unfortunately, this isn’t a valid example example and it seems to be making citations that don’t match. Specifically: -- “hmac-sha-256” The algorithms usable by TCP-AO come from https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-3. Only SHA1 and AES128 are registered. As far as I tell, the only work to add SHA256 is in an unadopted and expired draft (https://datatracker.ietf.org/doc/draft-nayak-tcp-sha2/). As aside, I think the algorithm name would have been SHA-256 or SHA256 (no HMAC). -- Per the link to RFC9235: The following example demonstrates how to model a TCP-AO [RFC5925] configuration for the example in TCP-AO Test Vectors [RFC9235]. The IP addresses and other parameters are taken from the test vectors. RFC9235 doesn’t use SHA256; and uses KeyID 61 and 84. Different KeyIDs are used in this example. Which parameters are being used from the test-vector? |
2022-06-29
|
07 | Roman Danyliw | [Ballot comment] Thank you to Hilarie Orman for the SECDIR review. I concur with the SECDIR observation that “there are no statistics kept for authentication … [Ballot comment] Thank you to Hilarie Orman for the SECDIR review. I concur with the SECDIR observation that “there are no statistics kept for authentication failures. If a shared key falls out of synch, the statistics might help detect that.” I appreciate the response (https://mailarchive.ietf.org/arch/msg/secdir/BnjVJ7_IgN7mSNaGi3H2ujVYvn0/) which recommends that this should be generically modeled. I disagree that this should be deferred. There is a very specific TCP-level primitive being described here and it makes sense to me to provide a corresponding logging primitive. |
2022-06-29
|
07 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2022-06-28
|
07 | Paul Wouters | [Ballot discuss] [ballot text incomplete as cloudflare triggers a weird refusal if I include a certain sentence, see Cloudflare Ray ID: 722aa6477e01a1db] Thanks for the … [Ballot discuss] [ballot text incomplete as cloudflare triggers a weird refusal if I include a certain sentence, see Cloudflare Ray ID: 722aa6477e01a1db] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be caused by a limited understanding of the underlying yang model inclusions. 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. #D1 To me, it seems very counter-intuitive that '' means (0.0.0.0 or ::). For LISTEN, I find it concerning because it means that '' as a default means to listen to any IP, rather than the more secure default of '' meaning 'none'. Is it possible to have some kind of "None" default? (or is that achieved by omission of this option? #D2 Is it intended that this cannot be specified using names |
2022-06-28
|
07 | Paul Wouters | Ballot discuss text updated for Paul Wouters |
2022-06-28
|
07 | Paul Wouters | [Ballot discuss] [ballot text incomplete at cloudflare triggers a weird refusal if I include a certain sentence, see Cloudflare Ray ID: 722aa6477e01a1db] Thanks for the … [Ballot discuss] [ballot text incomplete at cloudflare triggers a weird refusal if I include a certain sentence, see Cloudflare Ray ID: 722aa6477e01a1db] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be caused by a limited understanding of the underlying yang model inclusions. 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. #D1 To me, it seems very counter-intuitive that '' means (0.0.0.0 or ::). For LISTEN, I find it concerning because it means that '' as a default means to listen to any IP, rather than the more secure default of '' meaning 'none'. Is it possible to have some kind of "None" default? (or is that achieved by omission of this option? #D2 Is it intended that this cannot be specified using names |
2022-06-28
|
07 | Paul Wouters | Ballot discuss text updated for Paul Wouters |
2022-06-28
|
07 | Paul Wouters | [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be … [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be caused by a limited understanding of the underlying yang model inclusions. 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. #D1 To me, it seems very counter-intuitive that '' means (0.0.0.0 or ::). For LISTEN, I find it concerning because it means that '' as a default means to listen to any IP, rather than the more secure default of '' meaning 'none'. Is it possible to have some kind of "None" default? (or is that achieved by omission of this option? #D2 Is it intended that this cannot be specified using names |
2022-06-28
|
07 | Paul Wouters | Ballot discuss text updated for Paul Wouters |
2022-06-28
|
07 | Paul Wouters | [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be … [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be caused by a limited understanding of the underlying yang model inclusions. 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. #D1 To me, it seems very counter-intuitive that '' means (0.0.0.0 or ::). For LISTEN, I find it concerning because it means that '' as a default means to listen to any IP, rather than the more secure default of '' meaning 'none'. Is it possible to have some kind of "None" default? (or is that achieved by omission of this option? #D2 |
2022-06-28
|
07 | Paul Wouters | Ballot discuss text updated for Paul Wouters |
2022-06-28
|
07 | Paul Wouters | [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be … [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be caused by a limited understanding of the underlying yang model inclusions. 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. #D1 To me, it seems very counter-intuitive that '' means (0.0.0.0 or ::). For LISTEN, I find it concerning because it means that '' as a default means to listen to any IP, rather than the more secure default of '' meaning 'none'. Is it possible to have some kind of "None" default? (or is that achieved by omission of this option? |
2022-06-28
|
07 | Paul Wouters | Ballot discuss text updated for Paul Wouters |
2022-06-28
|
07 | Paul Wouters | [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be … [Ballot discuss] Thanks for the -07 changes in response to the various area reviews! I still have two small discuss questions left which might be caused by a limited understanding of the underlying yang model inclusions. 1. For an application willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding 'type' object being unknown (0). 2. For an application willing to accept only IPv4 or IPv6 datagrams, the value of this object must be '0.0.0.0' or '::' respectively, with 'type' representing the appropriate address type. |
2022-06-28
|
07 | Paul Wouters | Ballot discuss text updated for Paul Wouters |
2022-06-28
|
07 | Paul Wouters | [Ballot comment] #C1 It is unclear to me if '0.0.0.0' denotes the type inet:ip-address or the type string with text value "0.0.0.0". I also worry … [Ballot comment] #C1 It is unclear to me if '0.0.0.0' denotes the type inet:ip-address or the type string with text value "0.0.0.0". I also worry that if this is represented in C with a struct with union, that than it is unclear what a zero'ed out struct is set to? The string or the v4 ANY or the v6 ANY ? (I personally like enums to start from value 1 for that reason) #C2 How is this option set when fully disabled (eg not listening on anything, only willing to make an outgoing TCP connection). Is it by being omitted? NITS: listner -> listener for TCP connection that -> for a TCP connection that |
2022-06-28
|
07 | Paul Wouters | Ballot comment text updated for Paul Wouters |
2022-06-28
|
07 | Paul Wouters | [Ballot discuss] test |
2022-06-28
|
07 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2022-06-28
|
07 | Alvaro Retana | [Ballot comment] I'm happy to see the changes from the -06 version. Thanks to Jeff Haas for his review! [One more comment from Jeff, which … [Ballot comment] I'm happy to see the changes from the -06 version. Thanks to Jeff Haas for his review! [One more comment from Jeff, which I'm transcribing here as it wasn't wart of an archived discussion.] It occurs to me that as the keychain extensions are defined it might be desirable to protect them via if-feature. Basically, what happens if tcp-ao or tcp-md5 aren't supported by the implementation? |
2022-06-28
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2022-06-28
|
07 | Zaheduzzaman Sarker | [Ballot discuss] Thanks for working on this useful specification. I have noted the following which I think needs cross checking to make the meaning clear, … [Ballot discuss] Thanks for working on this useful specification. I have noted the following which I think needs cross checking to make the meaning clear, it might be simple oversight or intentional. I would like to which one is correct. - Section 4 : - any reason why the leaf send_id and recv_id does not use normative "MUST" in the description? - how should we interpret strongly " RECOMMENDED"? is this a MUST or RECOMMENDED? |
2022-06-28
|
07 | Zaheduzzaman Sarker | [Ballot comment] I have some minor observations, which we might want to address - - Section 3.1 : It is not clear to me what … [Ballot comment] I have some minor observations, which we might want to address - - Section 3.1 : It is not clear to me what is the difference between a "Global configuration" and "Policies". To me policies can include global configurations that will valid for all the TCP sessions. So, it is not clear is policy is a special case of global configuration or vise verse. Also the term "Global" here seems ambiguous. I kind of read that as a global variable definition, still the text need to be clear about the scope of "Global" is self, global to what context? - What are we really following when we say "directly following from TCP standards."? a reference is needed here to understand what is meant here. |
2022-06-28
|
07 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Discuss, has been recorded for Zaheduzzaman Sarker |
2022-06-27
|
07 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2022-06-27
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Gyan Mishra |
2022-06-27
|
07 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Gyan Mishra |
2022-06-26
|
07 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-tcpm-yang-tcp-07 CC @evyncke Thank you for the work put into this document. Please find below some … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-tcpm-yang-tcp-07 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Yoshifumi Nishidar for the shepherd's detailed write-up including the WG consensus even if it lacks the justification of the intended status and uses an unusual template. I hope that this helps to improve the document, Regards, -éric ## COMMENTS ### Section 1 ``` As such, TCP is implemented on network elements that can be configured via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. ``` AFAIK, NETCONF & RESTCONF can also be used to monitor/collect statistics. So "configured" seems rather limited. ### Section 1 YANG usefulness I wonder whether the paragraph containing: `Moreover, many existing TCP/IP stacks do not use YANG data models.` really brings any value to this document. ### Section 1, orthogonal or not ? ``` This specification is orthogonal to the Management Information Base (MIB) for the Transmission Control Protocol (TCP) [RFC4022]. The basic statistics defined in this document follow the model of the TCP MIB. ``` Is the model is based on the MIB, can it really be orthogonal to it ? ## NITS ### listner ? Is there a typo in "listner" ? ### Section 3.1 Perhaps a rendering issue, but "TCP-AO TCP-AO" is probably wrong ;-) ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments |
2022-06-26
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2022-06-24
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Hilarie Orman |
2022-06-24
|
07 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Hilarie Orman |
2022-06-23
|
07 | Martin Duke | Telechat date has been changed to 2022-06-30 from 2022-07-14 |
2022-06-23
|
07 | Martin Duke | Placed on agenda for telechat - 2022-07-14 |
2022-06-23
|
07 | Martin Duke | Ballot has been issued |
2022-06-23
|
07 | Martin Duke | [Ballot Position Update] New position, Yes, has been recorded for Martin Duke |
2022-06-23
|
07 | Martin Duke | Created "Approve" ballot |
2022-06-23
|
07 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-06-23
|
07 | Martin Duke | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2022-06-16
|
07 | Martin Duke | Changed action holders to Mahesh Jethanandani, Michael Scharf, Vishal Murgai |
2022-06-16
|
07 | Martin Duke | The document has been updated, but there has been no dialogue with last call reviewers and not all relevant conversations have been vetted by the … The document has been updated, but there has been no dialogue with last call reviewers and not all relevant conversations have been vetted by the WG. I am holding this until those actions are complete. |
2022-06-16
|
07 | (System) | Removed all action holders (IESG state changed) |
2022-06-16
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-06-16
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2022-06-16
|
07 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-07.txt |
2022-06-16
|
07 | Mahesh Jethanandani | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2022-06-16
|
07 | Mahesh Jethanandani | Uploaded new revision |
2022-05-31
|
06 | Martin Duke | Changed action holders to Mahesh Jethanandani, Michael Scharf, Vishal Murgai |
2022-05-04
|
06 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-05-04
|
06 | Martin Duke | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup::Revised I-D Needed |
2022-03-06
|
06 | Ebben Aries | Request for Early review by YANGDOCTORS Completed: On the Right Track. Reviewer: Ebben Aries. Sent review to list. |
2022-03-03
|
06 | Gyan Mishra | Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Gyan Mishra. Sent review to list. |
2022-03-03
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. Submission of review completed at an earlier date. |
2022-03-02
|
06 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Hilarie Orman. |
2022-03-02
|
06 | Martin Duke | Ballot writeup was changed |
2022-03-02
|
06 | (System) | Changed action holders to Martin Duke, Mahesh Jethanandani, Michael Scharf, Vishal Murgai (IESG state changed) |
2022-03-02
|
06 | Martin Duke | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup |
2022-03-02
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-02-28
|
06 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Reviews assigned |
2022-02-28
|
06 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2022-02-28
|
06 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
2022-02-28
|
06 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2022-02-28
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tcpm-yang-tcp-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-tcpm-yang-tcp-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a new namespace will be registered as follows: ID: yang:ietf-tcp URI: urn:ietf:params:xml:ns:yang:ietf-tcp Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the YANG Module Names registry on the YANG Parameters registry page located at: https://www.iana.org/assignments/yang-parameters/ a new YANG module will be registered as follows: Name: ietf-tcp File: [ TBD-at-Registration ] Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-tcp Prefix: tcp Module: Reference: [ RFC-to-be ] While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Lead IANA Services Specialist |
2022-02-28
|
06 | Gorry Fairhurst | Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Gorry Fairhurst. Sent review to list. |
2022-02-28
|
06 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Gorry Fairhurst |
2022-02-28
|
06 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Gorry Fairhurst |
2022-02-25
|
06 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list. |
2022-02-17
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2022-02-17
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2022-02-17
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2022-02-17
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2022-02-17
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Gyan Mishra |
2022-02-17
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Gyan Mishra |
2022-02-16
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2022-02-16
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2022-03-02): From: The IESG To: IETF-Announce CC: draft-ietf-tcpm-yang-tcp@ietf.org, martin.h.duke@gmail.com, nsd.ietf@gmail.com, tcpm-chairs@ietf.org, tcpm@ietf.org … The following Last Call announcement was sent out (ends 2022-03-02): From: The IESG To: IETF-Announce CC: draft-ietf-tcpm-yang-tcp@ietf.org, martin.h.duke@gmail.com, nsd.ietf@gmail.com, tcpm-chairs@ietf.org, tcpm@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard 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' 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 last-call@ietf.org mailing lists by 2022-03-02. Exceptionally, comments may be sent to iesg@ietf.org 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. |
2022-02-16
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2022-02-16
|
06 | Martin Duke | Last call was requested |
2022-02-16
|
06 | Martin Duke | Last call announcement was generated |
2022-02-16
|
06 | Martin Duke | Ballot approval text was generated |
2022-02-16
|
06 | Martin Duke | Ballot writeup was generated |
2022-02-16
|
06 | Martin Duke | IESG state changed to Last Call Requested from AD Evaluation |
2022-02-15
|
06 | (System) | Changed action holders to Martin Duke (IESG state changed) |
2022-02-15
|
06 | Martin Duke | IESG state changed to AD Evaluation from Publication Requested |
2022-02-08
|
06 | Jenny Bui | Changed consensus to Yes from Unknown |
2022-02-08
|
06 | Jenny Bui | Intended Status changed to Proposed Standard from None |
2022-02-08
|
06 | Yoshifumi Nishida | 1. Summary The document shepherd is Yoshifumi Nishida The responsible Area Director is Martin Duke This document specifies a YANG Model that can be used … 1. Summary The document shepherd is Yoshifumi Nishida The responsible Area Director is Martin Duke This document specifies a YANG Model that can be used to configure TCP on YANG supported network elements. This is a model with narrow scope which includes fundamental TCP functions, basic statistics for TCP and configuration parameters for TCP-AO and TCP MD5. One expected use case for the model is BGP YANG Model. 2. Review and Consensus The draft has been reviewed and discussed by various participants in the WG for long time. When the draft was presented for the first time, some concerns had been raised in the WG that there are other TCP related YANG models which might create conflicts or overwrap. In order to address it, the focus of the draft has been limited to a small sets of parameters when it was adopted. The draft has been updated to address several comments since then, however, there was no controversial point that required long arguments. In addition, some prototypes implementations efforts have been made to check the feasibility of the model. I believe there is a solid consensus in the WG for publication. 3. Intellectual Property Each author has confirmed that their direct, personal knowledge of any IPR related to this document has already been disclosed. None of the authors is aware of any IPR related to this document. 4. Other Points This draft contains a YANG model. We have requested a YANG doctors review request after the WGLC. |
2022-02-08
|
06 | Yoshifumi Nishida | Responsible AD changed to Martin Duke |
2022-02-08
|
06 | Yoshifumi Nishida | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2022-02-08
|
06 | Yoshifumi Nishida | IESG state changed to Publication Requested from I-D Exists |
2022-02-08
|
06 | Yoshifumi Nishida | IESG process started in state Publication Requested |
2022-02-07
|
06 | Yoshifumi Nishida | 1. Summary The document shepherd is Yoshifumi Nishida The responsible Area Director is Martin Duke This document specifies a YANG Model that can be used … 1. Summary The document shepherd is Yoshifumi Nishida The responsible Area Director is Martin Duke This document specifies a YANG Model that can be used to configure TCP on YANG supported network elements. This is a model with narrow scope which includes fundamental TCP functions, basic statistics for TCP and configuration parameters for TCP-AO and TCP MD5. One expected use case for the model is BGP YANG Model. 2. Review and Consensus The draft has been reviewed and discussed by various participants in the WG for long time. When the draft was presented for the first time, some concerns had been raised in the WG that there are other TCP related YANG models which might create conflicts or overwrap. In order to address it, the focus of the draft has been limited to a small sets of parameters when it was adopted. The draft has been updated to address several comments since then, however, there was no controversial point that required long arguments. In addition, some prototypes implementations efforts have been made to check the feasibility of the model. I believe there is a solid consensus in the WG for publication. 3. Intellectual Property Each author has confirmed that their direct, personal knowledge of any IPR related to this document has already been disclosed. None of the authors is aware of any IPR related to this document. 4. Other Points This draft contains a YANG model. We have requested a YANG doctors review request after the WGLC. |
2022-02-06
|
06 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Ebben Aries |
2022-02-06
|
06 | Mehmet Ersue | Request for Early review by YANGDOCTORS is assigned to Ebben Aries |
2022-02-06
|
06 | Yoshifumi Nishida | Requested Early review by YANGDOCTORS |
2022-02-03
|
06 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-06.txt |
2022-02-03
|
06 | (System) | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2022-02-03
|
06 | Mahesh Jethanandani | Uploaded new revision |
2022-02-02
|
05 | Yoshifumi Nishida | Notification list changed to nsd.ietf@gmail.com because the document shepherd was set |
2022-02-02
|
05 | Yoshifumi Nishida | Document shepherd changed to Yoshifumi Nishida |
2021-12-29
|
05 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-05.txt |
2021-12-29
|
05 | (System) | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2021-12-29
|
05 | Mahesh Jethanandani | Uploaded new revision |
2021-11-02
|
04 | Michael Tüxen | Added to session: IETF-112: tcpm Thu-1200 |
2021-10-25
|
04 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-04.txt |
2021-10-25
|
04 | (System) | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2021-10-25
|
04 | Mahesh Jethanandani | Uploaded new revision |
2021-10-25
|
04 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Michael Scharf , Vishal Murgai |
2021-10-25
|
04 | Mahesh Jethanandani | Uploaded new revision |
2021-10-19
|
03 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-03.txt |
2021-10-19
|
03 | (System) | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2021-10-19
|
03 | Mahesh Jethanandani | Uploaded new revision |
2021-07-24
|
02 | Michael Tüxen | Added to session: IETF-111: tcpm Tue-1600 |
2021-07-06
|
02 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-02.txt |
2021-07-06
|
02 | (System) | New version approved |
2021-07-06
|
02 | (System) | Request for posting confirmation emailed to previous authors: Mahesh Jethanandani , Michael Scharf , Vishal Murgai |
2021-07-06
|
02 | Mahesh Jethanandani | Uploaded new revision |
2021-05-20
|
01 | (System) | Document has expired |
2021-03-06
|
01 | Yoshifumi Nishida | Added to session: IETF-110: tcpm Fri-1300 |
2021-01-03
|
01 | Yoshifumi Nishida | This document now replaces draft-scharf-tcpm-yang-tcp instead of None |
2020-11-16
|
01 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-01.txt |
2020-11-16
|
01 | (System) | New version accepted (logged-in submitter: Mahesh Jethanandani) |
2020-11-16
|
01 | Mahesh Jethanandani | Uploaded new revision |
2020-11-13
|
00 | Michael Tüxen | Added to session: IETF-109: tcpm Tue-1200 |
2020-10-30
|
00 | Mahesh Jethanandani | New version available: draft-ietf-tcpm-yang-tcp-00.txt |
2020-10-30
|
00 | (System) | WG -00 approved |
2020-10-29
|
00 | Mahesh Jethanandani | Set submitter to "Mahesh Jethanandani ", replaces to (none) and sent approval email to group chairs: tcpm-chairs@ietf.org |
2020-10-29
|
00 | Mahesh Jethanandani | Uploaded new revision |