An Abstract Application Layer Interface to Transport Services
draft-ietf-taps-interface-26
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-11-01
|
26 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2024-04-25
|
26 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2024-04-25
|
26 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2024-04-25
|
26 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Sean Turner was marked no-response |
2024-04-19
|
26 | (System) | RFC Editor state changed to EDIT |
2024-04-19
|
26 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2024-04-19
|
26 | (System) | Announcement was received by RFC Editor |
2024-04-18
|
26 | (System) | IANA Action state changed to In Progress |
2024-04-18
|
26 | (System) | Removed all action holders (IESG state changed) |
2024-04-18
|
26 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2024-04-18
|
26 | Cindy Morgan | IESG has approved the document |
2024-04-18
|
26 | Cindy Morgan | Closed "Approve" ballot |
2024-04-18
|
26 | Cindy Morgan | Ballot approval text was generated |
2024-04-18
|
26 | Zaheduzzaman Sarker | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2024-04-18
|
26 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from Waiting for AD Go-Ahead |
2024-04-18
|
26 | Murray Kucherawy | [Ballot comment] Thanks to Robert Sparks for his dual ARTART reviews. Kudos to the document shepherd who took the time to give a comprehensive explanation … [Ballot comment] Thanks to Robert Sparks for his dual ARTART reviews. Kudos to the document shepherd who took the time to give a comprehensive explanation as to why there are eight authors, saving us the investigation and debate. In Section 5, in the second bullet, the two SHOULDs seem redundant to each other to me. Various other SHOULDs in the document (Sections 6, 8, and 9 mainly) left me wondering "Why?". I think you might be using at least some of them to mean "this is really good advice", while BCP 14 is meant more to constrain implementations for interoperability reasons. You might consider adding some text to them that explains why they're short of a MUST, or just make them fully OPTIONAL. I note Roman's most recent comments and was tempted to DISCUSS this, so please do give it a second look. |
2024-04-18
|
26 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2024-04-18
|
26 | Murray Kucherawy | [Ballot comment] Thanks to Robert Sparks for his dual ARTART reviews. Kudos to the document shepherd who took the time to give a comprehensive explanation … [Ballot comment] Thanks to Robert Sparks for his dual ARTART reviews. Kudos to the document shepherd who took the time to give a comprehensive explanation as to why there are eight authors, saving us the investigation and debate. In Section 5, in the second bullet, the two SHOULDs seem redundant to each other to me. Various other SHOULDs in the document (Sections 6, 8, and 9 mainly) left me wondering "Why?". I think you might be using at least some of them to mean "this is really good advice", while BCP 14 is meant more to constrain implementations for interoperability reasons. You might consider adding some text to them that explains why they're short of a MUST, or just make them fully OPTIONAL. |
2024-04-18
|
26 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record |
2024-04-18
|
26 | Roman Danyliw | [Ballot comment] Thank you to Sean Turner for the SECDIR review. Thank you for the iteration on my DISCUSS and ABSTAIN positions and the significant … [Ballot comment] Thank you to Sean Turner for the SECDIR review. Thank you for the iteration on my DISCUSS and ABSTAIN positions and the significant effort to refine the document in response. Questions remain for me on how conformance to this abstract API would be assessed based on the flexibility afforded by language such as "Implementations SHOULD expose an equivalent ...". I welcome the field experience to inform future RFCs who choose to define such APIs. |
2024-04-18
|
26 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Abstain |
2024-04-15
|
26 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2024-04-10
|
26 | Gunter Van de Velde | [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde |
2024-03-29
|
26 | Orie Steele | [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele |
2024-03-20
|
26 | Cindy Morgan | Telechat date has been changed to 2024-04-18 from 2023-09-07 |
2024-03-16
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2024-03-16
|
26 | Brian Trammell | New version available: draft-ietf-taps-interface-26.txt |
2024-03-16
|
26 | Tommy Pauly | New version approved |
2024-03-16
|
26 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2024-03-16
|
26 | Brian Trammell | Uploaded new revision |
2024-03-01
|
25 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2024-02-29
|
25 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2024-02-29
|
25 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-taps-interface-25, which is currently in Last Call (we've also previously reviewed -20 and … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: IANA has completed its review of draft-ietf-taps-interface-25, which is currently in Last Call (we've also previously reviewed -20 and -22), and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Sr. Specialist |
2024-02-22
|
25 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2024-02-16
|
25 | Cindy Morgan | The following Last Call announcement was sent out (ends 2024-03-01): From: The IESG To: IETF-Announce CC: anna.brunstrom@kau.se, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, zahed.sarker.ietf@gmail.com … The following Last Call announcement was sent out (ends 2024-03-01): From: The IESG To: IETF-Announce CC: anna.brunstrom@kau.se, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org, zahed.sarker.ietf@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (An Abstract Application Layer Interface to Transport Services) to Proposed Standard The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'An Abstract Application Layer Interface to Transport Services' 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 2024-03-01. 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 describes an abstract application programming interface, API, to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services architecture by providing asynchronous, atomic transmission of messages. It is intended to replace the BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple network paths and potential transport protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ This draft is going for a 2nd IETF last call due to the changes resulted during the IESG evaluation. A diff towards the -20 version of this document should show the changes since the previous IETF last call. No IPR declarations have been submitted directly on this I-D. |
2024-02-16
|
25 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2024-02-16
|
25 | Zaheduzzaman Sarker | Last call was requested |
2024-02-16
|
25 | Zaheduzzaman Sarker | IESG state changed to Last Call Requested from IESG Evaluation::AD Followup |
2024-02-16
|
25 | Zaheduzzaman Sarker | Last call announcement was changed |
2024-02-16
|
25 | Zaheduzzaman Sarker | Last call announcement was generated |
2024-01-29
|
25 | Brian Trammell | New version available: draft-ietf-taps-interface-25.txt |
2024-01-29
|
25 | Tommy Pauly | New version approved |
2024-01-29
|
25 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2024-01-29
|
25 | Brian Trammell | Uploaded new revision |
2024-01-26
|
24 | Roman Danyliw | [Ballot comment] Thank you to Sean Turner for the SECDIR review. Thank you for the iteration on my DISCUSS position and the efforts to refine … [Ballot comment] Thank you to Sean Turner for the SECDIR review. Thank you for the iteration on my DISCUSS position and the efforts to refine the document in response. I want to acknowledge the significant effort required to produce https://github.com/ietf-tapswg/api-drafts/pull/1463. My recommendation would be to merge it as it improves -24. I am abstaining on this document because there is a degree of specificity in the abstract API in this document that I cannot reconcile with proposed standard status. I would expect to be able to do some basic, repeatable degree of conformance evaluation to understand if a concrete API meets what is described in this abstract API – put more simply, how would I know I have an “API to Transport Services”. Focusing just on the security aspects of the API, I struggled to envision how to do that. To summarize my DISCUSS feedback, it isn’t clear which classes of security parameters require concrete implementation from the abstract API. The subsequent PR improved the editorial presentation (much appreciated!), but the following text created further ambiguity: The set of security parameters defined here is not exhaustive, but illustrative. Implementations SHOULD expose an equivalent to the parameters listed below to allow for sufficient configuration of security parameters, but the details are expected to vary based on platform and implementation constraints. If this text and parameters are “illustrative”, they are examples. What conformance is required for the concrete security API if only examples are provided? How does one unambiguously agree on equivalence relative to examples? If “implementations SHOULD expose”, that means that they can choose not to and still be conformant which degenerates into very little normative guidance around the security aspects of the API. ==[ DISCUSS feedback on -24 ]== Thanks for the revised text in v-22, -23 and -24. I’m still do not understanding what exact Security Parameters that Section 6.3.1 is normatively specifying (and which of them are examples). My confusion is that Section 6.2 has a crisp list of parameters with an explicit names, type, and default value. The equivalent is not present for the security related parameters. Section 6.3 says “except as noted below, as with the rest of the Transport Services API, exact names of parameters and/or values of enumerations (e.g., ciphersuites) used in the security parameters are system and implementation specific, and ought to be chosen to follow the principle of least surprise for users of the platform / language environment in question.” How does one read “except when noted below”? Is this section saying the normative parameters are server-certificate, client-certificate, pinned-server-certificate, alpn, supported-group, ciphersuite, signature-algorithm, max-cached-sessions, cached-session-lifetime-seconds, pre-shared-key OR that “an API should define certificate bundles, certificate chains for pinned certificates, ALPN, session cache management parameters, supported groups/ciphersuite/ parameters, and PSK parameters but no further details are provided here beyond naming these categories of parameters”? I observe that the guidance in Section 4.1 suggests that parameter names are in CamelCase. That isn’t used here (e.g., “server-certificate” should be “ServerCertificate”). This might hint that there are not parameters here. However, the bulleted list in Section 6.3.1. is prefaced with “Security configuration parameters and sample usage follow:” seems to suggest that these are concrete parameters. ==[ DISCUSS ]== |
2024-01-26
|
24 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to Abstain from Discuss |
2024-01-08
|
24 | Roman Danyliw | [Ballot discuss] Thanks for the revised text in v-22, -23 and -24. I’m still do not understanding what exact Security Parameters that Section 6.3.1 is … [Ballot discuss] Thanks for the revised text in v-22, -23 and -24. I’m still do not understanding what exact Security Parameters that Section 6.3.1 is normatively specifying (and which of them are examples). My confusion is that Section 6.2 has a crisp list of parameters with an explicit names, type, and default value. The equivalent is not present for the security related parameters. Section 6.3 says “except as noted below, as with the rest of the Transport Services API, exact names of parameters and/or values of enumerations (e.g., ciphersuites) used in the security parameters are system and implementation specific, and ought to be chosen to follow the principle of least surprise for users of the platform / language environment in question.” How does one read “except when noted below”? Is this section saying the normative parameters are server-certificate, client-certificate, pinned-server-certificate, alpn, supported-group, ciphersuite, signature-algorithm, max-cached-sessions, cached-session-lifetime-seconds, pre-shared-key OR that “an API should define certificate bundles, certificate chains for pinned certificates, ALPN, session cache management parameters, supported groups/ciphersuite/ parameters, and PSK parameters but no further details are provided here beyond naming these categories of parameters”? I observe that the guidance in Section 4.1 suggests that parameter names are in CamelCase. That isn’t used here (e.g., “server-certificate” should be “ServerCertificate”). This might hint that there are not parameters here. However, the bulleted list in Section 6.3.1. is prefaced with “Security configuration parameters and sample usage follow:” seems to suggest that these are concrete parameters. |
2024-01-08
|
24 | Roman Danyliw | [Ballot comment] Thank you to Sean Turner for the SECDIR review. |
2024-01-08
|
24 | Roman Danyliw | Ballot comment and discuss text updated for Roman Danyliw |
2024-01-04
|
24 | Lars Eggert | [Ballot comment] I'm abstaining on this document, because I disagree that Proposed Standard is appropriate. This document (and its companion) outline an extremely intricate design … [Ballot comment] I'm abstaining on this document, because I disagree that Proposed Standard is appropriate. This document (and its companion) outline an extremely intricate design without going into the - in my opinion - necessary details to fully explain all aspects. I appreciate that the WG intends this to be an "abstract API" that therefore can be described at a higher level of abstraction, but that is IMO exactly why PS is not a suitable RFC status here - we won't be able to determine implementation conformance and hence interoperability to this spec. If the intend is to publish an API as a PS, it would IMO need to be described at a level where that is feasible. |
2024-01-04
|
24 | Lars Eggert | Ballot comment text updated for Lars Eggert |
2024-01-04
|
24 | Lars Eggert | [Ballot comment] I'm likely to abstain on this document, because I disagree that Proposed Standard is appropriate. This document (and its companion) outline an extremely … [Ballot comment] I'm likely to abstain on this document, because I disagree that Proposed Standard is appropriate. This document (and its companion) outline an extremely intricate design without going into the - in my opinion - necessary details to fully explain all aspects. I appreciate that the WG intends this to be an "abstract API" that therefore can be described at a higher level of abstraction, but that is IMO exactly why PS is not a suitable RFC status here - we won't be able to determine implementation conformance and hence interoperability to this spec. If the intend is to publish an API as a PS, it would IMO need to be described at a level where that is feasible. |
2024-01-04
|
24 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to Abstain from Discuss |
2023-12-29
|
24 | Paul Wouters | [Ballot comment] I updated my discuss items to non-blocking comments. I'm still a bit concerned that some security items are not fully addressed by the … [Ballot comment] I updated my discuss items to non-blocking comments. I'm still a bit concerned that some security items are not fully addressed by the API or its Security Considerations. Resolving my comments would make the document a bit more clear and useful I think. I'm not sure that the model really expands from netflows to IP flows (or TOR) in the future. I'm not sure the Security Considerations warn enough about re-using the same credentials with different protocols/auth mechanisms. (eg TLS and IKEv2, or TLS 1.2 and QUIC, or using RSA as RSA-PKCS1.5 as well as RSA-PSS) Unqualified Hostname vs FQDN seems a security risk punted mostly to the application. I don't understand this code: Connection := Preconnection.Initiate() Connection2 := Connection.Clone() Connection -> Ready<> Connection2 -> Ready<> //---- Ready event handler for any Connection C begin ---- C.Send(messageDataRequest) Where does "C" come from in "C.Send" ? The comment says "any Connection C"? I have a question on this code: Preconnections are reusable after being used to initiate a Connection, whether this Connection was closed or not. Hence, it would be correct to continue as follows after the above example: //.. carry out adjustments to the Preconnection, if desired Connection := Preconnection.Initiate() What would happen here? I can imagine a "compiler" turning this into a noop. I can also see it would kill the existing Connection state and start a new one. This could be to a different IP address (eg if the DNS name has A and AAAA). When starting a new one, what would happen to any Message or Event queues for Connection ? Preconnection.AddRemote(RemoteCandidates) Should this not technically be: Preconnection.AddRemote([]RemoteCandidates) as the array contains at least a host and a stun server candidate? Maybe this is just the difference between you using the variable you define that has been assigned, versus a more C like prototype format, eg: Preconnection := NewPreconnection([]LocalEndpoint, So I guess if your example here had set LocalEndpoint := [a,b] you would not have used [] in the call ? Section 6.1.4 Perhaps it would be useful to add a Local Endpoint with ephemeral port before the Local Endpoint with static port example, as the ephemeral port should be the far more common case. Right now the examples might give the wrong impression a local port MUST be specified. SecurityParameters.Set() seems to allow to set our identiy and our certificate, but not the remote peer's identity or certificate? For example, one might want to pin a remote certificate and not just rely on a WithHostname() identifier being present as subjectAltname on a certificate. The Connection state, which can be one of the following: Establishing, Established, Closing, or Closed. I think the text in Section 8 should more clearly show the property names if the goal is to have different implementations use the identical name. Eg in this case, why not write: The Connection state ("state"). The next two entries are similarly lacking a clear keyword to use: Whether the Connection can be used to send data. Whether the Connection can be used to receive data. eg. why not define words for these to implementations will use the same words, in this case perhaps ReadySend and ReadyRcv ? Writing that now, perhaps "state" should be "State" then ? Section 8.1.1: If this property is an Integer It is best to define the actual type in this document and not let implementations choose, if the goal is to try and harmonize implementations. I also see no non-integer value being given here ? |
2023-12-29
|
24 | Paul Wouters | [Ballot Position Update] Position for Paul Wouters has been changed to Yes from Discuss |
2023-12-22
|
24 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to Yes from Discuss |
2023-12-14
|
24 | Brian Trammell | New version available: draft-ietf-taps-interface-24.txt |
2023-12-14
|
24 | Tommy Pauly | New version approved |
2023-12-14
|
24 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2023-12-14
|
24 | Brian Trammell | Uploaded new revision |
2023-12-12
|
23 | Paul Wouters | [Ballot discuss] [updated for -24, although I feel most of my questions have not been discussed yet] - netflows vs IP flows? Is TAPS only … [Ballot discuss] [updated for -24, although I feel most of my questions have not been discussed yet] - netflows vs IP flows? Is TAPS only meant for flows or does it also support IP transport. I don't see an example that would embody "setup a connection to 192.0.1.1 port 80, but require IPsec. I guess it could be added, eg a WithVPN("IPsec") or something, but I'm not sure you can specify credentials without those being interpreted to be for the port 80 in this example ? Is this specifically out of scope, or just not (yet) specified? Related, lets say you want to only use a flow if it goes over TOR, I guess one could introduce a WithTOR() transport requirement. I'm a bit concerned that without an IANA registry for functions, this might cause conflicts in the future. - single credentials for multiple protocols? Does this document cause encouraging of re-using of key pairs for different protocols (eg TLS and IKEv2, or TLS 1.2 and QUIC). This might have security implications (eg using RSA as RSA-PKCS1.5 as well as RSA-PSS) - Hostname vs FQDN Can WithHostname be unqualified? (God I hope not!) If not, can the call WithHostname be renamed to WithFQDN ? If it can be unqualified, how does one deal with credentials and identifiers, eg with a 'search domain' containing multiple domains, RemoteSpecifier.WithHostname("mail") could end up on either mail.example.com or mail.example.net (or heaven forbid, the .mail TLD) It seems a little text is added that says "RECOMMENDED to not use unqualified", but that raises the question on why even support it? It's just too dangerous imho. - WithPort and WithService, but not WithProtocol How does one choose their syslog service transport protocol, since syslog over udp and tcp are valid and both have the same service name? Or does WithService accept values like "514/udp" ? - ALPN I don't see a WithALPN method for setting the ALPN. - Preconnection vs Listener |
2023-12-12
|
23 | Paul Wouters | [Ballot comment] It is not necessary for an application to handle all events; some events may have … [Ballot comment] It is not necessary for an application to handle all events; some events may have implementation-specific default handlers. The application should not assume that ignoring events (e.g., errors) is always safe. What is "ignoring events" vs "having a default handler for events" ? Wouldn't default handlers be handled outside the application, and thus not trigger an event towards the application? So that applications "ignoring events" would be unrelated to "implementation-specific default handlers"? Perhaps the last sentence should just start in a new paragraph to indicate these two things are separate unrelated notes? SecurityParameters.Set(identity, myIdentity) I assume myIdentity would be an array of Type and Value? Eg type=fqdn or type=RDN ? I don't understand this code: Connection := Preconnection.Initiate() Connection2 := Connection.Clone() Connection -> Ready<> Connection2 -> Ready<> //---- Ready event handler for any Connection C begin ---- C.Send(messageDataRequest) Where does "C" come from in "C.Send" ? The comment says "any Connection C"? I have a question on this code: Preconnections are reusable after being used to initiate a Connection, whether this Connection was closed or not. Hence, it would be correct to continue as follows after the above example: //.. carry out adjustments to the Preconnection, if desired Connection := Preconnection.Initiate() What would happen here? I can imagine a "compiler" turning this into a noop. I can also see it would kill the existing Connection state and start a new one. This could be to a different IP address (eg if the DNS name has A and AAAA). When starting a new one, what would happen to any Message or Event queues for Connection ? Preconnection.AddRemote(RemoteCandidates) Should this not technically be: Preconnection.AddRemote([]RemoteCandidates) as the array contains at least a host and a stun server candidate? Maybe this is just the difference between you using the variable you define that has been assigned, versus a more C like prototype format, eg: Preconnection := NewPreconnection([]LocalEndpoint, So I guess if your example here had set LocalEndpoint := [a,b] you would not have used [] in the call ? Section 6.1 An Endpoint object can be configured with the following identifiers: * Hostname (string): This starts with listing endpoint identifiers with types (eg string and 16-bit integers) but then stops specifying their types further down. I guess WithService(), WithIPAddress() and WithInterface take a (string) Section 6.1.4 Perhaps it would be useful to add a Local Endpoint with ephemeral port before the Local Endpoint with static port example, as the ephemeral port should be the far more common case. Right now the examples might give the wrong impression a local port MUST be specified. SecurityParameters.Set() seems to allow to set our identiy and our certificate, but not the remote peer's identity or certificate? For example, one might want to pin a remote certificate and not just rely on a WithHostname() identifier being present as subjectAltname on a certificate. If security is opportunistic, it will allow Connections without transport security, but will still attempt to use security if available. I assume what is meant is "but will still attempt to use unauthenticated security if available" ? The Connection state, which can be one of the following: Establishing, Established, Closing, or Closed. I think the text in Section 8 should more clearly show the property names if the goal is to have different implementations use the identical name. Eg in this case, why not write: The Connection state ("state"). The next two entries are similarly lacking a clear keyword to use: Whether the Connection can be used to send data. Whether the Connection can be used to receive data. eg. why not define words for these to implementations will use the same words, in this case perhaps ReadySend and ReadyRcv ? Writing that now, perhaps "state" should be "State" then ? Section 8.1.1: If this property is an Integer It is best to define the actual type in this document and not let implementations choose, if the goal is to try and harmonize implementations. I also see no non-integer value being given here ? |
2023-12-12
|
23 | Paul Wouters | Ballot comment and discuss text updated for Paul Wouters |
2023-11-14
|
23 | (System) | Changed action holders to Zaheduzzaman Sarker (IESG state changed) |
2023-11-14
|
23 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-11-14
|
23 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2023-11-14
|
23 | Brian Trammell | New version available: draft-ietf-taps-interface-23.txt |
2023-11-14
|
23 | Brian Trammell | New version approved |
2023-11-14
|
23 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2023-11-14
|
23 | Brian Trammell | Uploaded new revision |
2023-10-10
|
22 | Sean Turner | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Sean Turner. Sent review to list. |
2023-09-18
|
22 | Paul Wouters | [Ballot discuss] - netflows vs IP flows? Is TAPS only meant for flows or does it also support IP transport. I don't see an example … [Ballot discuss] - netflows vs IP flows? Is TAPS only meant for flows or does it also support IP transport. I don't see an example that would embody "setup a connection to 192.0.1.1 port 80, but require IPsec. I guess it could be added, eg a WithVPN("IPsec") or something, but I'm not sure you can specify credentials without those being interpreted to be for the port 80 in this example ? Is this specifically out of scope, or just not (yet) specified? Related, lets say you want to only use a flow if it goes over TOR, I guess one could introduce a WithTOR() transport requirement. I'm a bit concerned that without an IANA registry for functions, this might cause conflicts in the future. - single credentials for multiple protocols? Does this document cause encouraging of re-using of key pairs for different protocols (eg TLS and IKEv2, or TLS 1.2 and QUIC). This might have security implications (eg using RSA as RSA-PKCS1.5 as well as RSA-PSS) - identity and server-certificate forces same use over different protocols? The current API kind of forces re-use of credentials for different protocols, eg: SecurityParameters.Set(server-certificate, myCertificate) // Specifying a Remote Endpoint is optional when using Listen Preconnection := NewPreconnection(LocalSpecifier, TransportProperties, SecurityParameters) Let's say that a server only supports TLS 1.2 with RSA-PKCS-1.5 and TLS 1.3 with RSASSA-PSS. We shouldn't use 1 RSA key from 1 certificate for these two different RSA operations. Would this mean we could never tell the TAPS API "TLS 1.2 or 1.3 is fine". Maybe that is okay and we should pick an keypair that works the same in 1.2 and 1.3, but we don't know what the future will hold. If we could set multiple identities, TAPS could pick the appropriate one. eg: SecurityParameters.Set(identity, myIdentity) SecurityParameters.Set(server-certificate, []myCertificate) (and possibly multiple identities too?) - Hostname vs FQDN Can WithHostname be unqualified? (God I hope not!) If not, can the call WithHostname be renamed to WithFQDN ? If it can be unqualified, how does one deal with credentials and identifiers, eg with a 'search domain' containing multiple domains, RemoteSpecifier.WithHostname("mail") could end up on either mail.example.com or mail.example.net (or heaven forbid, the .mail TLD) - WithPort and WithService, but not WithProtocol How does one choose their syslog service transport protocol, since syslog over udp and tcp are valid and both have the same service name? Or does WithService accept values like "514/udp" ? - ALPN I don't see a WithALPN method for setting the ALPN. - Preconnection vs Listener The arch document talks about Preconnection, Connection and Listener but this document in Section 3 places Listener as a Preconnection. |
2023-09-18
|
22 | Paul Wouters | [Ballot comment] - Camelcase vs Dromedariescase Why is it RemoteSpecifier.WithHostname and not RemoteSpecifier.WithHostName, while it is RemoteSpecifier.WithIPAddress and not RemoteSpecifier.WithIPaddress ? … [Ballot comment] - Camelcase vs Dromedariescase Why is it RemoteSpecifier.WithHostname and not RemoteSpecifier.WithHostName, while it is RemoteSpecifier.WithIPAddress and not RemoteSpecifier.WithIPaddress ? String: Instances are represented in a way that is common to the programming language, e.g. UTF-8. Why doesn't it define this just like the other basic types? eg: "Instances are represented in UTF-8" Also, how would that work for things like DNS (Ulabel vs Alabel) IP Address: An IPv4 or IPv6 address. Maybe reference RFC5952 ? It is not necessary for an application to handle all events; some events may have implementation-specific default handlers. The application should not assume that ignoring events (e.g., errors) is always safe. What is "ignoring events" vs "having a default handler for events" ? Wouldn't default handlers be handled outside the application, and thus not trigger an event towards the application? So that applications "ignoring events" would be unrelated to "implementation-specific default handlers"? Perhaps the last sentence should just start in a new paragraph to indicate these two things are separate unrelated notes? SecurityParameters.Set(identity, myIdentity) I assume myIdentity would be an array of Type and Value? Eg type=fqdn or type=RDN ? I don't understand this code: Connection := Preconnection.Initiate() Connection2 := Connection.Clone() Connection -> Ready<> Connection2 -> Ready<> //---- Ready event handler for any Connection C begin ---- C.Send(messageDataRequest) Where does "C" come from in "C.Send" ? The comment says "any Connection C"? I have a question on this code: Preconnections are reusable after being used to initiate a Connection, whether this Connection was closed or not. Hence, it would be correct to continue as follows after the above example: //.. carry out adjustments to the Preconnection, if desired Connection := Preconnection.Initiate() What would happen here? I can imagine a "compiler" turning this into a noop. I can also see it would kill the existing Connection state and start a new one. This could be to a different IP address (eg if the DNS name has A and AAAA). When starting a new one, what would happen to any Message or Event queues for Connection ? What is "credentials" (especially because previously we have myCertificate, so it is unclear if this now contains myKey and if so, where in the previous example myKey was conveyed to TAPS. Preconnection.AddRemote(RemoteCandidates) Should this not technically be: Preconnection.AddRemote([]RemoteCandidates) as the array contains at least a host and a stun server candidate? Maybe this is just the difference between you using the variable you define that has been assigned, versus a more C like prototype format, eg: Preconnection := NewPreconnection([]LocalEndpoint, So I guess if your example here had set LocalEndpoint := [a,b] you would not have used [] in the call ? Section 4.1: For the purposes of this document, these names are alphanumeric strings Is there another purpose? If it is outside this document, why does this document care? Does it try to set a standard here to ensure interoperable names? Maybe just remove the "For the purposes of this document," ? Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace What if Vendor Foo has a non-standard tcp property MagicSmoke? Does it go under tcp.Foo.MagicSmoke or under Foo.tcp.MagicSmoke or something else? Section 6.1 An Endpoint object can be configured with the following identifiers: * Hostname (string): This starts with listing endpoint identifiers with types (eg string and 16-bit integers) but then stops specifying their types further down. I guess WithService(), WithIPAddress() and WithInterface take a (string) Section 6.1.4 Perhaps it would be useful to add a Local Endpoint with ephemeral port before the Local Endpoint with static port example, as the ephemeral port should be the far more common case. Right now the examples might give the wrong impression a local port MUST be specified. SecurityParameters.Set() seems to allow to set our identiy and our certificate, but not the remote peer's identity or certificate? For example, one might want to pin a remote certificate and not just rely on a WithHostname() identifier being present as subjectAltname on a certificate. If security is opportunistic, it will allow Connections without transport security, but will still attempt to use security if available. I assume what is meant is "but will still attempt to use unauthenticated security if available" ? The Connection state, which can be one of the following: Establishing, Established, Closing, or Closed. I think the text in Section 8 should more clearly show the property names if the goal is to have different implementations use the identical name. Eg in this case, why not write: The Connection state ("state"). The next two entries are similarly lacking a clear keyword to use: Whether the Connection can be used to send data. Whether the Connection can be used to receive data. eg. why not define words for these to implementations will use the same words, in this case perhaps ReadySend and ReadyRcv ? Writing that now, perhaps "state" should be "State" then ? Section 8.1.1: If this property is an Integer It is best to define the actual type in this document and not let implementations choose, if the goal is to try and harmonize implementations. I also see no non-integer value being given here ? A higher value reflects a higher priority. This is uncommon in IETF protocols. Normally priority is down with lower numbers being higher priority. Why reverse it here? NITS: Wouldn't the American spelling be "rendezvouzing" instead of "rendezvousing" :-) |
2023-09-18
|
22 | Paul Wouters | Ballot comment and discuss text updated for Paul Wouters |
2023-09-13
|
22 | Ines Robles | Assignment of request for Telechat review by IOTDIR to Lou Berger was marked no-response |
2023-09-07
|
22 | (System) | Changed action holders to Brian Trammell, Michael Welzl, Reese Enghardt, Gorry Fairhurst, Mirja Kühlewind, Colin Perkins, Philipp Tiesel, Tommy Pauly, Zaheduzzaman Sarker (IESG state changed) |
2023-09-07
|
22 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2023-09-07
|
22 | Paul Wouters | [Ballot discuss] [ this review is still incomplete, but I wanted to at least file what I have here ] - netflows vs IP flows? … [Ballot discuss] [ this review is still incomplete, but I wanted to at least file what I have here ] - netflows vs IP flows? Is TAPS only meant for flows or does it also support IP transport. I don't see an example that would embody "setup a connection to 192.0.1.1 port 80, but require IPsec. I guess it could be added, eg a WithVPN("IPsec") or something, but I'm not sure you can specify credentials without those being interpreted to be for the port 80 in this example ? Is this specifically out of scope, or just not (yet) specified? Related, lets say you want to only use a flow if it goes over TOR, I guess one could introduce a WithTOR() transport requirement. I'm a bit concerned that without an IANA registry for functions, this might cause conflicts in the future. - single credentials for multiple protocols? Does this document cause encouraging of re-using of key pairs for different protocols (eg TLS and IKEv2, or TLS 1.2 and QUIC). This might have security implications (eg using RSA as RSA-PKCS1.5 as well as RSA-PSS) - identity and server-certificate forces same use over different protocols? The current API kind of forces re-use of credentials for different protocols, eg: SecurityParameters.Set(server-certificate, myCertificate) // Specifying a Remote Endpoint is optional when using Listen Preconnection := NewPreconnection(LocalSpecifier, TransportProperties, SecurityParameters) Let's say that a server only supports TLS 1.2 with RSA-PKCS-1.5 and TLS 1.3 with RSASSA-PSS. We shouldn't use 1 RSA key from 1 certificate for these two different RSA operations. Would this mean we could never tell the TAPS API "TLS 1.2 or 1.3 is fine". Maybe that is okay and we should pick an keypair that works the same in 1.2 and 1.3, but we don't know what the future will hold. If we could set multiple identities, TAPS could pick the appropriate one. eg: SecurityParameters.Set(identity, myIdentity) SecurityParameters.Set(server-certificate, []myCertificate) (and possibly multiple identities too?) - Hostname vs FQDN Can WithHostname be unqualified? (God I hope not!) If not, can the call WithHostname be renamed to WithFQDN ? If it can be unqualified, how does one deal with credentials and identifiers, eg with a 'search domain' containing multiple domains, RemoteSpecifier.WithHostname("mail") could end up on either mail.example.com or mail.example.net (or heaven forbid, the .mail TLD) - WithPort and WithService, but not WithProtocol How does one choose their syslog service transport protocol, since syslog over udp and tcp are valid and both have the same service name? Or does WithService accept values like "514/udp" ? - ALPN I don't see a WithALPN method for setting the ALPN. - Preconnection vs Listener The arch document talks about Preconnection, Connection and Listener but this document in Section 3 places Listener as a Preconnection. |
2023-09-07
|
22 | Paul Wouters | [Ballot comment] - Camelcase vs Dromedariescase Why is it RemoteSpecifier.WithHostname and not RemoteSpecifier.WithHostName, while it is RemoteSpecifier.WithIPAddress and not RemoteSpecifier.WithIPaddress ? … [Ballot comment] - Camelcase vs Dromedariescase Why is it RemoteSpecifier.WithHostname and not RemoteSpecifier.WithHostName, while it is RemoteSpecifier.WithIPAddress and not RemoteSpecifier.WithIPaddress ? String: Instances are represented in a way that is common to the programming language, e.g. UTF-8. Why doesn't it define this just like the other basic types? eg: "Instances are represented in UTF-8" Also, how would that work for things like DNS (Ulabel vs Alabel) IP Address: An IPv4 or IPv6 address. Maybe reference RFC5952 ? It is not necessary for an application to handle all events; some events may have implementation-specific default handlers. The application should not assume that ignoring events (e.g., errors) is always safe. What is "ignoring events" vs "having a default handler for events" ? Wouldn't default handlers be handled outside the application, and thus not trigger an event towards the application? So that applications "ignoring events" would be unrelated to "implementation-specific default handlers"? Perhaps the last sentence should just start in a new paragraph to indicate these two things are separate unrelated notes? SecurityParameters.Set(identity, myIdentity) I assume myIdentity would be an array of Type and Value? Eg type=fqdn or type=RDN ? I don't understand this code: Connection := Preconnection.Initiate() Connection2 := Connection.Clone() Connection -> Ready<> Connection2 -> Ready<> //---- Ready event handler for any Connection C begin ---- C.Send(messageDataRequest) Where does "C" come from in "C.Send" ? The comment says "any Connection C"? I have a question on this code: Preconnections are reusable after being used to initiate a Connection, whether this Connection was closed or not. Hence, it would be correct to continue as follows after the above example: //.. carry out adjustments to the Preconnection, if desired Connection := Preconnection.Initiate() What would happen here? I can imagine a "compiler" turning this into a noop. I can also see it would kill the existing Connection state and start a new one. This could be to a different IP address (eg if the DNS name has A and AAAA). When starting a new one, what would happen to any Message or Event queues for Connection ? What is "credentials" (especially because previously we have myCertificate, so it is unclear if this now contains myKey and if so, where in the previous example myKey was conveyed to TAPS. Preconnection.AddRemote(RemoteCandidates) Should this not technically be: Preconnection.AddRemote([]RemoteCandidates) as the array contains at least a host and a stun server candidate? Maybe this is just the difference between you using the variable you define that has been assigned, versus a more C like prototype format, eg: Preconnection := NewPreconnection([]LocalEndpoint, So I guess if your example here had set LocalEndpoint := [a,b] you would not have used [] in the call ? Section 4.1: For the purposes of this document, these names are alphanumeric strings Is there another purpose? If it is outside this document, why does this document care? Does it try to set a standard here to ensure interoperable names? Maybe just remove the "For the purposes of this document," ? Vendor or implementation specific properties MUST use a string identifying the vendor or implementation as the Namespace What if Vendor Foo has a non-standard tcp property MagicSmoke? Does it go under tcp.Foo.MagicSmoke or under Foo.tcp.MagicSmoke or something else? Section 6.1 An Endpoint object can be configured with the following identifiers: * Hostname (string): This starts with listing endpoint identifiers with types (eg string and 16-bit integers) but then stops specifying their types further down. I guess WithService(), WithIPAddress() and WithInterface take a (string) Section 6.1.4 Perhaps it would be useful to add a Local Endpoint with ephemeral port before the Local Endpoint with static port example, as the ephemeral port should be the far more common case. Right now the examples might give the wrong impression a local port MUST be specified. SecurityParameters.Set() seems to allow to set our identiy and our certificate, but not the remote peer's identity or certificate? For example, one might want to pin a remote certificate and not just rely on a WithHostname() identifier being present as subjectAltname on a certificate. If security is opportunistic, it will allow Connections without transport security, but will still attempt to use security if available. I assume what is meant is "but will still attempt to use unauthenticated security if available" ? The Connection state, which can be one of the following: Establishing, Established, Closing, or Closed. I think the text in Section 8 should more clearly show the property names if the goal is to have different implementations use the identical name. Eg in this case, why not write: The Connection state ("state"). The next two entries are similarly lacking a clear keyword to use: Whether the Connection can be used to send data. Whether the Connection can be used to receive data. eg. why not define words for these to implementations will use the same words, in this case perhaps ReadySend and ReadyRcv ? Writing that now, perhaps "state" should be "State" then ? Section 8.1.1: If this property is an Integer It is best to define the actual type in this document and not let implementations choose, if the goal is to try and harmonize implementations. I also see no non-integer value being given here ? A higher value reflects a higher priority. This is uncommon in IETF protocols. Normally priority is down with lower numbers being higher priority. Why reverse it here? [ review to be continued from 8.1.3 ] NITS: Wouldn't the American spelling be "rendezvouzing" instead of "rendezvousing" :-) |
2023-09-07
|
22 | Paul Wouters | [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters |
2023-09-07
|
22 | Andrew Alston | [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston |
2023-09-07
|
22 | Lars Eggert | [Ballot discuss] # GEN AD review of draft-ietf-taps-interface-22 CC @larseggert Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/Uohwi2MvOOwswMfkE5w4mt9IZKE). … [Ballot discuss] # GEN AD review of draft-ietf-taps-interface-22 CC @larseggert Thanks to Thomas Fossati for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/Uohwi2MvOOwswMfkE5w4mt9IZKE). ## Discuss ### Section 4.1, paragraph 8 ``` * For IETF protocols, the name of a Protocol-specific Property SHOULD be specified in an IETF document published in the RFC Series. ``` For IETF protocols, i.e., protocols published on the IETF RFC stream, those names must IMO be also specified in IETF-stream RFCs. I see no reason to let other RFC streams make definitions for IETF protocols. ### Section 6.1, paragraph 13 ``` * Interface name (string), e.g., to qualify link-local or multicast addresses (see Section 6.1.2 for details): LocalSpecifier.WithInterface("en0") ``` How does an application learn which interface name strings are allowed/available on the system? The API doesn't seem to provide this information. Also, based on the examples, there seem to be special names such as "any" - where are those defined and how are conflicts with names used on the system avoided? ### Section 6.1.3, paragraph 6 ``` In order to scope an alias to a specific transport protocol, an Endpoint can specify a protocol identifier. AlternateRemoteSpecifier.WithProtocol(QUIC) ``` This is the first and only time protocol identifiers are used. What are they defined to be? ### Section 6.1.3, paragraph 9 ``` The following example shows a case where example.com has a server running on port 443, with an alternate port of 8443 for QUIC. RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier.WithHostname("example.com") RemoteSpecifier.WithPort(443) QUICRemoteSpecifier := NewRemoteEndpoint() QUICRemoteSpecifier.WithHostname("example.com") QUICRemoteSpecifier.WithPort(8443) QUICRemoteSpecifier.WithProtocol(QUIC) RemoteSpecifier.AddAlias(QUICRemoteSpecifier) ``` Why does the `RemoteSpecifier` definition not contain a `WithProtocol` clause for TCP/TLS? And what would that look like, given that TCP/TLS is a protocol combination? ### Section 6.2, paragraph 0 ``` 6.2. Specifying Transport Properties ``` This section defines a boatload of different properties, many of which are interacting with each other due to how our current transport protocols are implemented. Future interactions, due to future transport protocols potentially becoming available, are undefined. I question how a potential programmer is supposed to make informed choices here without needing to be aware of all of this background/baggage? ### Section 8.1.5, paragraph 4 ``` Default: Weighted Fair Queueing (see Section 3.6 in [RFC8260]) This property specifies which scheduler should be used among Connections within a Connection Group, see Section 7.4. A set of schedulers is described in [RFC8260]. ``` What is this scheduler scheduling? 7.4 is silent on this. I'm guessing this is related to `connPriority`? ### Section 9.1.3, paragraph 9 ``` If a Message Property contradicts a Connection Property, and if this per-Message behavior can be supported, it overrides the Connection Property for the specific Message. For example, if reliability is set to Require and a protocol with configurable per-Message reliability is used, setting msgReliable to false for a particular Message will allow this Message to be sent without any reliability guarantees. Changing the msgReliable Message Property is only possible for Connections that were established enabling the Selection Property perMsgReliability. ``` How is this going to work in the opposite case, i.e., if an unreliable connection was set up and then some messages are passed in which require reliable transmission? At connection open, the stack may have chosen a transport protocol that cannot support reliable transmission? (Also, I think this general principle of message > connection has other issues for other properties.) |
2023-09-07
|
22 | Lars Eggert | [Ballot comment] ## Comments I'm likely to abstain on this document, because I disagree that Proposed Standard is appropriate. This document (and its companion) outline … [Ballot comment] ## Comments I'm likely to abstain on this document, because I disagree that Proposed Standard is appropriate. This document (and its companion) outline as extremely intricate design, and I am not aware of any attempts to implement even a sizable subset of it. Given the various interactions between the API components and the attributes and behaviors of existing transport protocols (and their implementation), I strongly believe that in-depth experimentation with actual implementations is needed before we can have the confidence in the design we'd like to see for publication on the Standards Track. ### Section 1.1, paragraph 23 ``` * String: Instances are represented in a way that is common to the programming language, e.g. UTF-8. ``` If the intend of this API is to be language independent, it can't really fall back on assuming a defined string representation of a given language. Instead, it should define how strings are encoded. ### Section 4.1, paragraph 1 ``` Transport Properties are referred to by property names. For the purposes of this document, these names are alphanumeric strings in which the following characters are allowed: lowercase letters a-z, uppercase letters A-Z, digits 0-9, the hyphen -, and the underscore _. These names serve two purposes: ``` This allows property names that are indistinguishable from integers. Is that a bug or a feature? Also, are they case-sensitive? ### Section 4.1, paragraph 7 ``` Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- numbers/protocol-numbers.xhtml) are reserved for Protocol-specific Properties and MUST NOT be used for vendor or implementation-specific properties. Terms listed as keywords as in the protocol numbers registry SHOULD be avoided as any part of a vendor- or implementation-specific property name. ``` This doesn't work if vendors use property names that the IETF later adds to the IANA registry. Suggest to instead define a vendor-specific prefix/name here, ideally one that is illegal for the IANA registry. ### Section 6, paragraph 6 ``` If more than one Local Endpoint is specified on a Preconnection, then all the Local Endpoints on the Preconnection MUST represent the same host. For example, they might correspond to different interfaces on a multi-homed host, of they might correspond to local interfaces and a STUN server that can be resolved to a server reflexive address for a Preconnection used to make a peer-to-peer Rendezvous. ``` In order to make this MUST enforceable, a concrete definition of what "represent the same host" means is IMO needed. Is this a static or dynamic check? ### Section 6, paragraph 6 ``` If more than one Remote Endpoint is specified on the Preconnection, then all the Remote Endpoints on the Preconnection should represent the same service, to the extent that the application and the Transport Services system can validate that the Remote Endpoints are indeed the same service. For example, the Remote Endpoints might represent various network interfaces of a host, or a server reflexive address that can be used to reach a host, or a set of hosts that provide equivalent local balanced service. ``` It's a lowercase "should", but I still have no idea how a programmer or the API would verify whether all endpoints are the same service. Seems unenforceable. ### Section 6.1, paragraph 8 ``` * Port (a 16-bit integer): ``` Previously, only length-unlimited integer types were defined? ### Section 6.1, paragraph 10 ``` * Service (an identifier that maps to a port; either the name of a well-known service, or a DNS SRV service name to be resolved): RemoteSpecifier.WithService("https") ``` I assume when you say "name of a well-known service" you mean "service name associated with a port number on https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml"? It would be good to explicitly say that. Also, there seems to be an assumption that the OS provides `getservbyname` or similar - is this a reasonable assumption? ### Section 6.1.1, paragraph 4 ``` RemoteSpecifier.WithMulticastGroupIP(GroupAddress) ``` It's a design choice to not overload `WithIPAddress` here and instead define `WithMulticastGroupIP`. I'd have overloaded, in order to avoid the need for error handling if the wring type of IP address is passed in. ### Section 6.1.1, paragraph 3 ``` RemoteSpecifier.WithTTL(TTL) ``` I'd point out that since IPv6, we switched to "hop count" for the term, to make it clear it's not actually a time value (anymore). Suggest to use the more modern term? ### Section 6.1.4, paragraph 3 ``` RemoteSpecifier := NewRemoteEndpoint() RemoteSpecifier.WithHostname("example.com") RemoteSpecifier.WithService("https") ``` Does `WithService("https")` implicitly set `WithProtocol(TCP/TLS)` or is that missing from the example? If it does, which other such implications are defined? ### Section 6.2.5, paragraph 0 ``` 6.2.5. Use 0-RTT Session Establishment with a Safely Replayable Message ``` This is an awfully specific preference compared to all the others. Maybe make it a bit less specific by calling it "Initial Message will be Safely Replayable" without mentioning a specific use case such as 0-RTT? (Or maybe even define a "replayable" message flag, and only do 0-RTT if that is set on the first message.) ### Section 6.2.7, paragraph 4 ``` This property specifies the application's need for protection against corruption for all data transmitted on this Connection. Disabling this property could enable later control of the sender checksum coverage (see Section 9.1.3.6). ``` I don't know what "enable later control of the sender checksum coverage" is supposed to mean. Also, how does this (and `fullChecksumRecv`) intersect with `reliability`, which also talks about corruption? ### Section 8.1.1, paragraph 3 ``` Type: Integer (non-negative) or Full Coverage Default: Full Coverage ``` How is "Full Coverage" expressed? ### Section 8.1.8, paragraph 4 ``` Numeric values of these properties specify an upper-bound rate that a transfer is not expected to exceed (even if flow control and congestion control allow higher rates), and/or a lower-bound rate below which the application does not deem it will be useful. These are specified in bits per second. The enumerated value Unlimited indicates that no bound is specified. ``` Over what timescale, or is this supposed to apply to instantaneous bandwidth? Because an app can control how much data over time to feed into a connection, but cannot usually know what send rate that results in. ### Section 8.1.11.1, paragraph 3 ``` This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation at the sender. It is specified as the number of bytes. It exposes a value to the application based on the Maximum Packet Size (MPS) as described in Datagram PLPMTUD [RFC8899]. This can allow a sending stack to avoid unwanted fragmentation at the network-layer or segmentation by the transport layer. ``` Is this supposed to vary as PMTUD happens? ### Section 9.2.1, paragraph 2 ``` messageData := "hello" Connection.Send(messageData) The interpretation of a Message to be sent is dependent on the implementation, and on the constraints on the Protocol Stacks implied by the Connection’s transport properties. For example, a Message may be a single datagram for UDP Connections; or an HTTP Request for HTTP Connections. ``` I don't think you mean "UDP datagram here", since that would include the UDP header. UDP payload? ### Section 9.2.6, paragraph 2 ``` A Transport Services system gives no guarantees about how its expression of relative priorities will be realized. However, the Transport Services system will seek to ensure that performance of relatively-prioritized Connections and Messages is not worse with respect to those Connections and Messages than an equivalent configuration in which all prioritization properties are left at their defaults. ``` Without defining what is meant by "performance" in this case, it's not possible to know what "not worse" means. (Or how a transport system might seek to ensure that.) ### Section 9.3.2, paragraph 1 ``` Each call to Receive will be paired with a single Receive event, which can be a success or an error. This allows an application to provide backpressure to the transport stack when it is temporarily not ready to receive Messages. ``` Isn't the act of not reading and the resulting buffer growth already providing this backpressure? ### Too many authors The document has eight authors, which exceeds the recommended author limit. Has the sponsoring AD agreed that this is appropriate? ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Terms `natively` and `native`; alternatives might be `built-in`, `fundamental`, `ingrained`, `intrinsic`, `original` ### IP addresses Found IP block or address not inside RFC5737/RFC3849 example ranges: `232.1.1.1`. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 9.1.3.9, paragraph 4 ``` - prefered. + preferred. + + ``` #### Section 9.1.3.10, paragraph 3 ``` - this property to true will result in a sending endpount setting the - ^ + this property to true will result in a sending endpoint setting the + ^ ``` ### Outdated references Reference `[RFC8229]` to `RFC8229`, which was obsoleted by `RFC9329` (this may be on purpose). ### Grammar/style #### Section 1.1, paragraph 2 ``` ming language, e.g. UTF-8. If the intend of this API is to be language indep ^^^^^^ ``` The word "intend" is a verb. Did you mean the noun "intent"? #### Section 2, paragraph 2 ``` the kind of transport, can be bi-directional or unidirectional, and that ca ^^^^^^^^^^^^^^ ``` This word is normally spelled as one. #### Section 6.1.2, paragraph 3 ``` tener := Preconnection.Listen() Join an Source-Specific Multicast group in re ^^ ``` Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". #### Section 8, paragraph 9 ``` lgorithm); to prefer immediate acknowledgment from the peer endpoint when su ^^^^^^^^^^^^^^ ``` Do not mix variants of the same word ("acknowledgment" and "acknowledgement") within a single text. #### Section 8.1.6, paragraph 11 ``` onal Message Context, which allows to add Message Properties, identify Send ^^^^^^ ``` Did you mean "adding"? Or maybe you should add a pronoun? In active voice, "allow" + "to" takes an object, usually a pronoun. #### Section 8.1.10, paragraph 4 ``` In these cases, they add an additional transformation to further encode or e ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``` This phrase might be redundant. Consider either removing or replacing the adjective "additional". #### Section 9.3.2.3, paragraph 3 ``` paths and are not necessarily privacy sensitive. Still, some information cou ^^^^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 9.3.2.3, paragraph 3 ``` l, some information could be privacy sensitive because it might reveal usage ^^^^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. #### Section 14, paragraph 5 ``` cts (see Section 6.2) that are pre-configured with frequently used sets of p ^^^^^^^^^^^^^^ ``` Do not mix variants of the same word ("pre-configure" and "preconfigure") within a single text. ## 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. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2023-09-07
|
22 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
2023-09-07
|
22 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2023-09-07
|
22 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Robert Sparks for his ART ART early: https://mailarchive.ietf.org/arch/msg/art/g3nBK52CUcWroPMW2bZR15BjdRk/ and last call reviews … [Ballot comment] Thank you for the work on this document. Many thanks to Robert Sparks for his ART ART early: https://mailarchive.ietf.org/arch/msg/art/g3nBK52CUcWroPMW2bZR15BjdRk/ and last call reviews and to the authors for addressing Robert's comments. |
2023-09-07
|
22 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2023-09-07
|
22 | Murray Kucherawy | [Ballot comment] I have not completed my review prior to the telechat where this document is scheduled, but I wanted to go on record giving … [Ballot comment] I have not completed my review prior to the telechat where this document is scheduled, but I wanted to go on record giving early kudos to the document shepherd who took the time to give a comprehensive explanation as to why there are eight authors, saving us the investigation and debate. |
2023-09-07
|
22 | Murray Kucherawy | Ballot comment text updated for Murray Kucherawy |
2023-09-06
|
22 | Erik Kline | [Ballot discuss] # Internet AD comments for draft-ietf-taps-interface-22 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Discuss … [Ballot discuss] # Internet AD comments for draft-ietf-taps-interface-22 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Discuss ### S6.1.12 * "there is currently no portable standard format for a PvD identifier" RFC 8801 should be considered here. An argument can be made that there is no *single* format, but there certainly is a string FQDN PvD ID standard. I think it's fair to require that the FQDN PvD ID strings be considered MTI here, or that an implementation have some way to use handles that refer to these. Maybe that's what's meant here by the integer option mention and I'm just not getting the clue. |
2023-09-06
|
22 | Erik Kline | [Ballot comment] # Internet AD comments for draft-ietf-taps-interface-22 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ # Comments … [Ballot comment] # Internet AD comments for draft-ietf-taps-interface-22 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ # Comments ### S3 * "The application should not assume that ignoring events..." s/should not/SHOULD NOT/? ### S6.1 * "Connection can perform name resolution" Does the Connection do name resolution? I would have expected this to either be done by Preconnection or just "the API implementation". ### S6.1.3 * If calls like NewPreconnection() take an array of RemoteEndpoints why is it necessary to add one RemoteEndpoint to another via .AddAlias(), rather than just tossing into the []RemoteEndpoints array? ### S6.2 * It's probably too late for a bikeshed, but I find a Preference named "Ignore" to not mean "No Preference", as I read it. I would have expected something like a Preference of "None". To me, "Ignore" feels kinda somewhat like "Avoid" (or "Eschew" :D ). ### S6.2.1 * "without corruption"? I think I would have expected "without loss"; "without corruption" implies to me that there's some extra level of integrity checking go on (vis. S6.2.7). ### S6.2.13 * Why should the preference be Avoid for Rendezvous use cases? It seems to me like many Rendezvous uses are not necessarily long-lived and so might be Preference None (Ignore), or even Prefer. ### S9.1.3.7 * Same question as S6.2.1 above. ## Nits ### S5 * "Actions, events, and errors in implementations" -> "Action, event, and error objects in implementations" ### S6.1, S6.1.4 * "Port (a 16-bit integer)" Perhaps "unsigned integer", or "non-negative integer"? * ":0a" -> ":a", I think ### S6.1.5 * "newPreconnection(...)" -> "NewPreconnection(...)"? ### S9.1.3.10 * s/endpount/endpoint/ |
2023-09-06
|
22 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
2023-09-06
|
22 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
2023-09-06
|
22 | Martin Duke | [Ballot comment] I am excited about this doc, and can confirm based on some experience that this is basically implementable. Nevertheless there are a few … [Ballot comment] I am excited about this doc, and can confirm based on some experience that this is basically implementable. Nevertheless there are a few problems, and potentially significant errors: (S4.1) "Namespaces for each of the keywords provided in the IANA protocol numbers registry ... are reserved for Protocol-specific Properties and MUST NOT be used for vendor or implementation-specific properties." It's regrettable that this excludes QUIC, TLS, HTTP, and other candidates for protocols operating under this API. Would it be too much to add a registry for additional reserved names? Indeed, there is enough noise in the protocol number registry it might be better to just have a registry of the 10? protocols that today might conceivably operate under TAPS. (S7.3) This section confused me as to whether ICE is done by the Transport Service (paragraph 4), the app (paragraph 8), or both. (I think it's both.) Maybe state this more explicitly? (S7.4) What happens if a Clone command results in a connection with different properties (e.g. in a second connection, the peer rejects the necessary TCP option)? (S8, paragraph 3) "Therefore, it is RECOMMENDED that Protocol-specific Properties are used for properties common across different protocols and that Protocol-specific Properties are only used where specific protocols or properties are necessary." I think the first instance of "protocol-specific properties should be "generic properties"? (S8.2) UTO is not TCP-specific! QUIC does it too. Maybe this should be a generic property? (S9.2.6) "The Transport Services API does order connPriority over msgPriority. In the absence of other externalities (e.g., transport-layer flow control), a priority 1 Message on a priority 0 Connection will be sent before a priority 0 Message on a priority 1 Connection in the same group." Everywhere in this doc, larger integers = higher priorities. So IIUC the Priority 1 connection should be sent first! |
2023-09-06
|
22 | Martin Duke | [Ballot Position Update] New position, Yes, has been recorded for Martin Duke |
2023-09-06
|
22 | Robert Wilton | [Ballot comment] Hi, Moderate level comments: (1) As per the architecture doc, I think that it is great that you are defining a new transport … [Ballot comment] Hi, Moderate level comments: (1) As per the architecture doc, I think that it is great that you are defining a new transport API. I note that this API doesn't really include any standard APIs or structures to monitor the state of the transport sessions for a given application (i.e., API user). E.g., how many connections are currently open, total number of connections (since library was initialized), number of errored transport connections, drops, mtu issues, flow rates, etc. I think that with some of the changes to the Internet architecture (e.g., QUIC to cite one obvious example), it reduces the ability for network operators to monitor and debug network issues between applications. A potential corollary of this is that a lot more debug and diagnostics information will need to be made available to applications in a common way to allow application support staff, and users of those applications to better understand where in the network issues and failures are happening. It would seem unreasonable for me to hold a discuss on this document for what might be a lot of work and discussion that could take a long time to resolve but I hope that the authors and WG will consider whether there is further useful future work required in additional RFCs. Minor level comments: (2) p 6, sec 1.1. Terminology and Notation * Array: Denoted []Type, an instance takes a value for each of zero or more elements in a sequence of the given Type. An array may be of fixed or variable length. * Collection: An unordered grouping of one or more values of the same type. Perhaps calling it a Set may be better than Collection (if duplicates are not allowed) or a Bag (if duplicates are allowed). (3) p 17, sec 6.1. Specifying Endpoints Note that an IPv6 address specified with a scope (e.g. 2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to WithIPAddress with an unscoped address and WithInterface together. Would it not just be cleaner to not allow interface scoped IP addresses, and force the clients to use WithInterface, in the case they want to target a specific interface? (4) p 26, sec 6.2. Specifying Transport Properties Upon reading, the Preference type of a Selection Property changes into Boolean, where true means that the selected Protocol Stack supports the feature or uses the path associated with the Selection Property, and false means that the Protocol Stack does not support the feature or use the path. I misunderstood this on first reading - maybe explicitly state that the types for non Preference types are unchanged on a get, maybe give an example of the return type for section 6.2.11. (5) p 64, sec 9.2. Sending Data The optional endOfMessage parameter supports partial sending and is described in Section 9.2.3. If this is an asynchronous API, I presume that the caller must prevent any changes to, or freeing of, the messageData object until it has received a event to indicate that the send has successfully completed. Perhaps this is too detailed for this abstract level API and is left to the implementation. (6) p 70, sec 9.3.2. Receive Events Each call to Receive will be paired with a single Receive event, which can be a success or an error. This allows an application to provide backpressure to the transport stack when it is temporarily not ready to receive Messages. The backpressure aspect wasn't entirely clear to me. So, if an application can handle receiving multiple receive events at the same time, it can make multiple calls to receive without waiting for, or processing, any receive events? Is that how the application controls the backpressure? (7) p 70, sec 9.3.2. Receive Events Each call to Receive will be paired with a single Receive event, which can be a success or an error. This allows an application to provide backpressure to the transport stack when it is temporarily not ready to receive Messages. How does the transport stack know that the application has finished with the memory holding the message in the receive event, or is the expectation that the receive message contents is logically always allocated on the heap and it is responsibility of the receiver to free the memory once it is done with it? Regards, Rob |
2023-09-06
|
22 | Robert Wilton | [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton |
2023-09-05
|
22 | Warren Kumari | [Ballot comment] Firstly, thank you very much for writing this document -- I found it a fascinating read. I'd also like to thank Matt Brown … [Ballot comment] Firstly, thank you very much for writing this document -- I found it a fascinating read. I'd also like to thank Matt Brown for the DNS-DIR review, it was most helpful. I only have a few nits / suggestions to make: 1: S 1.4. Glossary of Key Terms *Endpoint: An identifier for one side of a Connection (local or remote), such as a hostnames or URL. I'm not really sure that the definition of "Endpoint" works. E.g: the definition of "Connection" is "Shared state of two or more endpoints that persists across Messages". Ok, fine. But can you really have shared state between two **identifiers**? I don't really see how I'd have shared state between e.g hostnames, but I can see how I'd have state between entities *identified* by an identifier like a hostname. I understand what you are aiming for (and also "endpoint" seems to be used in more than one context), but I don't think that the definition as written actually works... 2: S 2.1. Event-Driven API This paragraph compares and contrasts the Socket API and the Transport Services API, but in the paragraph starting with "For example, an application first issues a call to receive new data from the connection.", it is unclear under which paradigm you are meaning. I'd suggest: "For example, when using the Transport Services API, an application first ..." |
2023-09-05
|
22 | Warren Kumari | Ballot comment text updated for Warren Kumari |
2023-09-05
|
22 | Warren Kumari | [Ballot comment] Firstly, thank you very much for writing this document -- I found it a fascinating read. I only have a few nits / … [Ballot comment] Firstly, thank you very much for writing this document -- I found it a fascinating read. I only have a few nits / suggestions to make: 1: S 1.4. Glossary of Key Terms *Endpoint: An identifier for one side of a Connection (local or remote), such as a hostnames or URL. I'm not really sure that the definition of "Endpoint" works. E.g: the definition of "Connection" is "Shared state of two or more endpoints that persists across Messages". Ok, fine. But can you really have shared state between two **identifiers**? I don't really see how I'd have shared state between e.g hostnames, but I can see how I'd have state between entities *identified* by an identifier like a hostname. I understand what you are aiming for (and also "endpoint" seems to be used in more than one context), but I don't think that the definition as written actually works... 2: S 2.1. Event-Driven API This paragraph compares and contrasts the Socket API and the Transport Services API, but in the paragraph starting with "For example, an application first issues a call to receive new data from the connection.", it is unclear under which paradigm you are meaning. I'd suggest: "For example, when using the Transport Services API, an application first ..." |
2023-09-05
|
22 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
2023-09-05
|
22 | Roman Danyliw | [Ballot comment] Thank you to Sean Turner for the SECDIR review. ** Section 6.1. -- Per “Port (a 16-bit integer):”, shouldn’t this be “16-bit unsigned … [Ballot comment] Thank you to Sean Turner for the SECDIR review. ** Section 6.1. -- Per “Port (a 16-bit integer):”, shouldn’t this be “16-bit unsigned integer”? -- Per “Service (an identifier that maps to a port; either the name of a well-known service, or a DNS SRV service name to be resolved):”, what makes something a “well-known service”? Is this string have to be from https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml? -- Per “IP address (IPv4 or IPv6 address):”, is there a formal syntax for an IPv4 or IPv6 address that can be cited? ** Section 6.3. Editorial. Should the convention of “myVariableName” be used here? OLD SecurityParameters.Set(pre-shared-key, key, identity) NEW SecurityParameters.Set(pre-shared-key, myKey, myIdentity) ** Section 6 of draft-ietf-taps-arch-18 said: ==[ snip ]== However, a Transport Services implementation can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. ==[ snip ]== How does one use the API described in this document to convey equivalence? ** A few methods seem to be used in the prose without formal definition beyond the example: -- Section 6.1.1: WithTTL() -- Section 6.1.3: WithProtocol() |
2023-09-05
|
22 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2023-09-05
|
22 | Roman Danyliw | [Ballot discuss] ** Section 6.3. I’m having trouble understanding the level of abstraction used to specify the SecurityParameter API if the desired outcome is an … [Ballot discuss] ** Section 6.3. I’m having trouble understanding the level of abstraction used to specify the SecurityParameter API if the desired outcome is an interoperable solution. My top-line concern is around what are the defined security parameters are where are they formally defined. The API examples seem to suggest they are “identity, server-certificate, client-certificate, key-pair, supported-group, ciphersuite, signature-algorithm, and pre-shared-key.” A few examples of this ambiguity: -- “SecurityParameters.Set(identity, myIdentity)”: What is the “identity” parameter? What would be passed here? -- Per “SecurityParameters.Set(server-certificate, myCertificate)” and “SecurityParameters.Set(client-certificate, myCertificate)”, assuming myCertificate is an X.509 certificate, what format would that be passed in (e.g., PEM, DER)? -- What is in “myCertficate”: o can it be a certificate chain? o in the case of client-auth or a server, is this a bundle with both an X.509 and a private key? -- The parameters “supported-group”, “ciphersuite” and “signature-algorithm” all appear to be enumerated values. Where do those come from? |
2023-09-05
|
22 | Roman Danyliw | [Ballot comment] Thank you to Sean Turner for the SECDIR review. ** Section 6.1. -- Per “Port (a 16-bit integer):”, shouldn’t this be “16-bit unsigned … [Ballot comment] Thank you to Sean Turner for the SECDIR review. ** Section 6.1. -- Per “Port (a 16-bit integer):”, shouldn’t this be “16-bit unsigned integer”? -- Per “Service (an identifier that maps to a port; either the name of a well-known service, or a DNS SRV service name to be resolved):”, what makes something a “well-known service”? Is this string have to be from https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml? -- Per “IP address (IPv4 or IPv6 address):”, is there a formal syntax for an IPv4 or IPv6 address that can be cited? ** Section 6.3. Editorial. Should the convention of “myVariableName” be used here? OLD SecurityParameters.Set(pre-shared-key, key, identity) NEW SecurityParameters.Set(pre-shared-key, myKey, myIdentity) ** Section 6 of draft-ietf-taps-arch-18 said: ==[ snip ]== However, a Transport Services implementation can race different security protocols, e.g., if the application explicitly specifies that it considers them equivalent. ==[ snip ]== How does one use the API described in this document to convey equivalence? ** A few methods seem to be used in the prose without formal definition beyond the example: -- Section 6.1.1: WithTTL() -- Section 6.1.3: WithProtocol() |
2023-09-05
|
22 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2023-09-05
|
22 | Éric Vyncke | [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-taps-interface-22 Thank you for the work put into this document. Please find below some non-blocking COMMENT … [Ballot comment] # Éric Vyncke, INT AD, comments for draft-ietf-taps-interface-22 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 Anna Brunstrom for the shepherd's detailed write-up including the WG consensus, and the justification of the intended status and of the large number of authors. I can only support having all those authors cited (especially from current/past academia). Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request), please consider this int-dir review: https://datatracker.ietf.org/doc/review-ietf-taps-interface-22-intdir-telechat-jinmei-2023-09-01/ (while a positive review, I would appreciate a reply by authors, esp on issue 1) Other thanks to Matt Brown, the DNS directorate reviewer (at my request), please consider this dns -dir review: https://datatracker.ietf.org/doc/review-ietf-taps-interface-22-dnsdir-telechat-brown-2023-08-27/ I hope that this review helps to improve the document, Regards, -éric # COMMENTS ## Abstract and Section 1 It is not only about "multiple interfaces" but also about "multiple provisioning domains" (usually linked to interfaces), e.g., an interface can have several IPv6 addresses and several next-hops. RFC 7556 is only mentioned in Section 2. ## Section 1 `Action(param0, param1?, ...) / Event` the use of `\` is unclear... suggest using two lines ? Should param1 in Event() also be suffixed by a '?' ? Is `IP Address` scoped ? E.g., fe80::1%eth0 Can it be unicast, anycast, multicast ? Even if section 6.1 is about this issue, it may be worth already telling the readers. ## Section 3 `from a Remote Endpoint` does the use of 'a' preclude a multicast group endpoint ? ## Section 3.1 Useful section. Thanks. ## Section 4.1 It is a little underspecified whether the '.' is also removed when the Namespace component is omitted (I guess yes, but let's be specific). Should 'tcp' be in uppercase in `tcp Connection could support ` ? `IETF document published in the RFC Series` in which stream ? Are ISE or IAB or IRTF streams also OK ? ## Section 5 If not mistaken, then there are only 3 occurrences of a normative SHOULD and several other non-normative "should". Is it the intent ? ## Section 6.1 I am not sure whether I like the split between .WithIPAddress() and .WithInterface()... E.g., using "fe80::1%eth0" as an endpoint would be nicer ? Should there be a .WithPvD() to handle multiple PvDs on the same interface ? Even after reading section 6.2.12, it is unclear. ## Section 6.1.1 TTL is so legacy... Why not using RFC 8200 hop limit ? # NITS ## Section 6.1 and other places 2001:db8:4920:e29d:a420:7461:7073:0a is not a valid RFC 5952 address ;-) ## Section 8.1.11.13 s/It specified as the number of bytes/It *is* specified as *a* number of bytes/ ? |
2023-09-05
|
22 | Éric Vyncke | [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke |
2023-09-01
|
22 | Tatuya Jinmei | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Tatuya Jinmei. Sent review to list. Submission of review completed at an earlier date. |
2023-09-01
|
22 | Tatuya Jinmei | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Tatuya Jinmei. |
2023-08-30
|
22 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2023-08-27
|
22 | Matt Brown | Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Matt Brown. Sent review to list. |
2023-08-23
|
22 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Tatuya Jinmei |
2023-08-22
|
22 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Lou Berger |
2023-08-22
|
22 | Bruce Nordman | Assignment of request for Telechat review by IOTDIR to Bruce Nordman was rejected |
2023-08-22
|
22 | Jim Reid | Request for Telechat review by DNSDIR is assigned to Matt Brown |
2023-08-22
|
22 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Bruce Nordman |
2023-08-21
|
22 | Éric Vyncke | Requested Telechat review by IOTDIR |
2023-08-21
|
22 | Éric Vyncke | Requested Telechat review by INTDIR |
2023-08-21
|
22 | Éric Vyncke | Requested Telechat review by DNSDIR |
2023-08-19
|
22 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Sean Turner |
2023-08-16
|
22 | Amy Vezza | Placed on agenda for telechat - 2023-09-07 |
2023-08-16
|
22 | Zaheduzzaman Sarker | Ballot has been issued |
2023-08-16
|
22 | Zaheduzzaman Sarker | [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker |
2023-08-16
|
22 | Zaheduzzaman Sarker | Created "Approve" ballot |
2023-08-16
|
22 | Zaheduzzaman Sarker | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2023-08-16
|
22 | Zaheduzzaman Sarker | Ballot writeup was changed |
2023-07-06
|
22 | Brian Trammell | New version available: draft-ietf-taps-interface-22.txt |
2023-07-06
|
22 | Tommy Pauly | New version approved |
2023-07-06
|
22 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2023-07-06
|
22 | Brian Trammell | Uploaded new revision |
2023-06-05
|
21 | (System) | Changed action holders to Zaheduzzaman Sarker (IESG state changed) |
2023-06-05
|
21 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-06-05
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2023-06-05
|
21 | Brian Trammell | New version available: draft-ietf-taps-interface-21.txt |
2023-06-05
|
21 | Jenny Bui | Posted submission manually |
2023-04-26
|
20 | Zaheduzzaman Sarker | Revised id needed to address the IETF last call comments. |
2023-04-26
|
20 | (System) | Changed action holders to Brian Trammell, Michael Welzl, Reese Enghardt, Gorry Fairhurst, Mirja Kühlewind, Colin Perkins, Philipp Tiesel, Tommy Pauly, Zaheduzzaman Sarker (IESG state changed) |
2023-04-26
|
20 | Zaheduzzaman Sarker | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2023-04-24
|
20 | Sean Turner | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Sean Turner. Sent review to list. Submission of review completed at an earlier date. |
2023-04-24
|
20 | Sean Turner | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Sean Turner. |
2023-04-20
|
20 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events' |
2023-04-14
|
20 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-04-12
|
20 | Robert Sparks | Request for Last Call review by ARTART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2023-04-12
|
20 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2023-04-12
|
20 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-taps-interface-20, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-taps-interface-20, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Specialist |
2023-04-12
|
20 | Joe Clarke | Assignment of request for Last Call review by OPSDIR to Joe Clarke was rejected |
2023-04-12
|
20 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2023-04-10
|
20 | Thomas Fossati | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Thomas Fossati. Sent review to list. |
2023-04-06
|
20 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sean Turner |
2023-04-06
|
20 | Jean Mahoney | Request for Last Call review by GENART is assigned to Thomas Fossati |
2023-03-31
|
20 | Barry Leiba | Request for Last Call review by ARTART is assigned to Robert Sparks |
2023-03-30
|
20 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2023-03-30
|
20 | Cindy Morgan | The following Last Call announcement was sent out (ends 2023-04-14): From: The IESG To: IETF-Announce CC: Zaheduzzaman.Sarker@ericsson.com, anna.brunstrom@kau.se, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org … The following Last Call announcement was sent out (ends 2023-04-14): From: The IESG To: IETF-Announce CC: Zaheduzzaman.Sarker@ericsson.com, anna.brunstrom@kau.se, draft-ietf-taps-interface@ietf.org, taps-chairs@ietf.org, taps@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (An Abstract Application Layer Interface to Transport Services) to Proposed Standard The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'An Abstract Application Layer Interface to Transport Services' 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 2023-04-14. 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 describes an abstract application programming interface, API, to the transport layer that enables the selection of transport protocols and network paths dynamically at runtime. This API enables faster deployment of new protocols and protocol features without requiring changes to the applications. The specified API follows the Transport Services architecture by providing asynchronous, atomic transmission of messages. It is intended to replace the BSD sockets API as the common interface to the transport layer, in an environment where endpoints could select from multiple interfaces and potential transport protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ No IPR declarations have been submitted directly on this I-D. |
2023-03-30
|
20 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2023-03-30
|
20 | Cindy Morgan | Last call announcement was changed |
2023-03-30
|
20 | Zaheduzzaman Sarker | Last call was requested |
2023-03-30
|
20 | Zaheduzzaman Sarker | Ballot approval text was generated |
2023-03-30
|
20 | Zaheduzzaman Sarker | Ballot writeup was generated |
2023-03-30
|
20 | Zaheduzzaman Sarker | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2023-03-30
|
20 | Zaheduzzaman Sarker | Last call announcement was changed |
2023-03-29
|
20 | Brian Trammell | New version available: draft-ietf-taps-interface-20.txt |
2023-03-29
|
20 | Jenny Bui | Posted submission manually |
2023-03-09
|
19 | (System) | Changed action holders to Zaheduzzaman Sarker (IESG state changed) |
2023-03-09
|
19 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-03-09
|
19 | Tommy Pauly | New version available: draft-ietf-taps-interface-19.txt |
2023-03-09
|
19 | Jenny Bui | Posted submission manually |
2023-02-03
|
18 | (System) | Changed action holders to Colin Perkins, Michael Welzl, Gorry Fairhurst, Brian Trammell, Zaheduzzaman Sarker, Mirja Kühlewind, Tommy Pauly, Philipp Tiesel, Reese Enghardt (IESG state changed) |
2023-02-03
|
18 | Zaheduzzaman Sarker | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2023-01-15
|
18 | Anna Brunstrom | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document reached broad agreement, with contributions from most active WG members. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? This document specifies and abstract API for the Transport Services reference architecture described in the -arch draft; the proposed API is based on experience gained in one widely deployed production implementation and two open implementations deployed for research purposes, as listed in Appendix C of the -implementation draft. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. This draft has benefited from broad TSV area review within the WG itself, and has had secdir and artart early review. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal review necessary as no MIB models, YANG models, media types, or URI types etc. are used in the document. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? It does not contain a YANG module. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. No sections of the document are written in a formal language. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? The document has undergone both artart and secdir early review and has seen broad review overall to also receive comments for many of the int area topics (esp. v6). All identified issues have been resolved. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed standard. The requested type is consistent with the milestones for the working group and correctly reflected in the Intended RFC status field in the Datatracker. It is the proper type as the abstract API is based on experience from multiple implementations and intended to be used by multiple applications over different realizations of the API. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes; no IPR issues are known. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, the authors have all shown their willingness to be listed as such. The draft has 8 authors and editors. The wg believes there is a well-argued case for an exception to the 5 author rule. First: The TAPS work on the core API draft has been a 7-year journey. It forms the first IETF transport API, something not previously published by the IETF. An integrated team-based approach was recognized as important from early in the document development and was discussed a number of times. The resulting team drew from several previous projects, important initial contributions from two EU projects (NEAT,MAMI), independent work at TU Berlin and Glasgow and independent work at Apple, and a small number of others. Each author continues to play a key part in shaping the way the final document is structured, while bringing necessarily expertise across a wide area of topics (see github activity) to draw expertise on a wide range of subjects. Things have evolved many times, but this was essentially a team effort - not an editorial process to draw together contributions. Second, the topics span a very wide set of expertise - even for the IETF, and rather than make many documents, the wg purposely focused on three closely linked documents to cover: Understanding of applications use of transport; Architectural design; Privacy, Security and Policy in the stack; Trends in modern API and variations between programming languages, and use of callback, events, etc.; Detailed understanding of differences between the IETF transports; Understanding of STUN/ICE and Rendezvous; Understanding of NAT, details of using of IPv4 and IPv6, etc. The author lists for the other two core documents have been trimmed down to 5 authors, leaving a larger number of authors only for the API draft. Third, as the document passes through IETF review, IESG review and RFC-Ed the present authors have a commitment and style of working that is effective and ensures that details are not overlooked. This close working may not be typical of the IETF process, and likely is because of the nature of these specific specifications, motivating a longer author list. Overall, the draft represents a major investment by the entire author team. Normally the underpinning research contribution can be published in Journals, etc. However, in this case, people have been actively working on refining the spec for several years after their research to bring a consistent and new type of API to the IETF, and the final outcome is this spec. For the academic contributors, this contribution is only recognized by their Universities when they are authors. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are 2 instances of lines with non-ascii characters and a few lines that are too long and may need editing. The document has a "Security and Privacy Considerations" Section. According to the idnits tool these should be two separate sections. The authors decided to leave this as it is for now and let the ADs decide about this matter. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No non-IETF normative references. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No, the companion drafts will be submitted and published together. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). This document has no actions for IANA, which is appropriate. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No new IANA registries. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2023-01-13
|
18 | Zaheduzzaman Sarker | IESG state changed to AD Evaluation from Publication Requested |
2023-01-12
|
18 | Zaheduzzaman Sarker | IESG state changed to Publication Requested from AD Evaluation |
2022-12-21
|
18 | (System) | Changed action holders to Zaheduzzaman Sarker (IESG state changed) |
2022-12-21
|
18 | Zaheduzzaman Sarker | IESG state changed to AD Evaluation from Publication Requested |
2022-12-19
|
18 | Reese Enghardt | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document reached broad agreement, with contributions from most active WG members. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? This document specifies and abstract API for the Transport Services reference architecture described in the -arch draft; the proposed API is based on experience gained in one widely deployed production implementation and two open implementations deployed for research purposes, as listed in Appendix C of the -implementation draft. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. This draft has benefited from broad TSV area review within the WG itself, and has had secdir and artart early review. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal review necessary as no MIB models, YANG models, media types, or URI types etc. are used in the document. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? It does not contain a YANG module. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. No sections of the document are written in a formal language. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? The document has undergone both artart and secdir early review and has seen broad review overall to also receive comments for many of the int area topics (esp. v6). All identified issues have been resolved. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed standard. The requested type is consistent with the milestones for the working group and correctly reflected in the Intended RFC status field in the Datatracker. It is the proper type as the abstract API is based on experience from multiple implementations and intended to be used by multiple applications over different realizations of the API. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes; no IPR issues are known. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, the authors have all shown their willingness to be listed as such. The draft has 7 authors and editors. The wg believes there is a well-argued case for an exception to the 5 author rule. First: The TAPS work on the core API draft has been a 7-year journey. It forms the first IETF transport API, something not previously published by the IETF. An integrated team-based approach was recognized as important from early in the document development and was discussed a number of times. The resulting team drew from several previous projects, important initial contributions from two EU projects (NEAT,MAMI), independent work at TU Berlin and Glasgow and independent work at Apple, and a small number of others. Each author continues to play a key part in shaping the way the final document is structured, while bringing necessarily expertise across a wide area of topics (see github activity) to draw expertise on a wide range of subjects. Things have evolved many times, but this was essentially a team effort - not an editorial process to draw together contributions. Second, the topics span a very wide set of expertise - even for the IETF, and rather than make many documents, the wg purposely focused on three closely linked documents to cover: Understanding of applications use of transport; Architectural design; Privacy, Security and Policy in the stack; Trends in modern API and variations between programming languages, and use of callback, events, etc.; Detailed understanding of differences between the IETF transports; Understanding of STUN/ICE and Rendezvous; Understanding of NAT, details of using of IPv4 and IPv6, etc. The author lists for the other two core documents have been trimmed down to 5 authors, leaving a larger number of authors only for the API draft. Third, as the document passes through IETF review, IESG review and RFC-Ed the present authors have a commitment and style of working that is effective and ensures that details are not overlooked. This close working may not be typical of the IETF process, and likely is because of the nature of these specific specifications, motivating a longer author list. Overall, the draft represents a major investment by the entire author team. Normally the underpinning research contribution can be published in Journals, etc. However, in this case, people have been actively working on refining the spec for several years after their research to bring a consistent and new type of API to the IETF, and the final outcome is this spec. For the academic contributors, this contribution is only recognized by their Universities when they are authors. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are 2 instances of lines with non-ascii characters and a few lines that are too long and may need editing. The document has a "Security and Privacy Considerations" Section. According to the idnits tool these should be two separate sections. The authors decided to leave this as it is for now and let the ADs decide about this matter. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No non-IETF normative references. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No, the companion drafts will be submitted and published together. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). This document has no actions for IANA, which is appropriate. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No new IANA registries. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2022-12-19
|
18 | Reese Enghardt | Responsible AD changed to Zaheduzzaman Sarker |
2022-12-19
|
18 | Reese Enghardt | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2022-12-19
|
18 | Reese Enghardt | IESG state changed to Publication Requested from I-D Exists |
2022-12-19
|
18 | Reese Enghardt | Document is now in IESG state Publication Requested |
2022-12-19
|
18 | Reese Enghardt | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
2022-12-05
|
18 | Anna Brunstrom | # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the … # Document Shepherd Write-Up for Group Documents *This version is dated 4 July 2022.* Thank you for your service as a document shepherd. Among the responsibilities is answering the questions in this write-up to give helpful context to Last Call and Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in completing it is appreciated. The full role of the shepherd is further described in [RFC 4858][2]. You will need the cooperation of the authors and editors to complete these checks. Note that some numbered items contain multiple related questions; please be sure to answer all of them. ## Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? This document reached broad agreement, with contributions from most active WG members. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? This document specifies and abstract API for the Transport Services reference architecture described in the -arch draft; the proposed API is based on experience gained in one widely deployed production implementation and two open implementations deployed for research purposes, as listed in Appendix C of the -implementation draft. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. This draft has benefited from broad TSV area review within the WG itself, and has had secdir and artart early review. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. No formal review necessary as no MIB models, YANG models, media types, or URI types etc. are used in the document. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? It does not contain a YANG module. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. No sections of the document are written in a formal language. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? The document has undergone both artart and secdir early review and has seen broad review overall to also receive comments for many of the int area topics (esp. v6). All identified issues have been resolved. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Proposed standard. The requested type is consistent with the milestones for the working group and correctly reflected in the Intended RFC status field in the Datatracker. It is the proper type as the abstract API is based on experience from multiple implementations and intended to be used by multiple applications over different realizations of the API. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes; no IPR issues are known. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes, the authors have all shown their willingness to be listed as such. The draft has 7 authors and editors. The wg believes there is a well-argued case for an exception to the 5 author rule. First: The TAPS work on the core API draft has been a 7-year journey. It forms the first IETF transport API, something not previously published by the IETF. An integrated team-based approach was recognized as important from early in the document development and was discussed a number of times. The resulting team drew from several previous projects, important initial contributions from two EU projects (NEAT,MAMI), independent work at TU Berlin and Glasgow and independent work at Apple, and a small number of others. Each author continues to play a key part in shaping the way the final document is structured, while bringing necessarily expertise across a wide area of topics (see github activity) to draw expertise on a wide range of subjects. Things have evolved many times, but this was essentially a team effort - not an editorial process to draw together contributions. Second, the topics span a very wide set of expertise - even for the IETF, and rather than make many documents, the wg purposely focused on three closely linked documents to cover: Understanding of applications use of transport; Architectural design; Privacy, Security and Policy in the stack; Trends in modern API and variations between programming languages, and use of callback, events, etc.; Detailed understanding of differences between the IETF transports; Understanding of STUN/ICE and Rendezvous; Understanding of NAT, details of using of IPv4 and IPv6, etc. The author lists for the other two core documents have been trimmed down to 5 authors, leaving a larger number of authors only for the API draft. Third, as the document passes through IETF review, IESG review and RFC-Ed the present authors have a commitment and style of working that is effective and ensures that details are not overlooked. This close working may not be typical of the IETF process, and likely is because of the nature of these specific specifications, motivating a longer author list. Overall, the draft represents a major investment by the entire author team. Normally the underpinning research contribution can be published in Journals, etc. However, in this case, people have been actively working on refining the spec for several years after their research to bring a consistent and new type of API to the IETF, and the final outcome is this spec. For the academic contributors, this contribution is only recognized by their Universities when they are authors. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are 2 instances of lines with non-ascii characters and a few lines that are too long and may need editing. The document has a "Security and Privacy Considerations" Section. According to the idnits tool these should be two separate sections. The authors decided to leave this as it is for now and let the ADs decide about this matter. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. No. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? No non-IETF normative references. 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No, the companion drafts will be submitted and published together. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). This document has no actions for IANA, which is appropriate. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No new IANA registries. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2022-10-24
|
18 | Brian Trammell | New version available: draft-ietf-taps-interface-18.txt |
2022-10-24
|
18 | Tommy Pauly | New version approved |
2022-10-24
|
18 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2022-10-24
|
18 | Brian Trammell | Uploaded new revision |
2022-09-27
|
17 | Brian Trammell | New version available: draft-ietf-taps-interface-17.txt |
2022-09-27
|
17 | Brian Trammell | New version approved |
2022-09-27
|
17 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2022-09-27
|
17 | Brian Trammell | Uploaded new revision |
2022-09-26
|
16 | Aaron Falk | Notification list changed to anna.brunstrom@kau.se because the document shepherd was set |
2022-09-26
|
16 | Aaron Falk | Document shepherd changed to Anna Brunstrom |
2022-08-31
|
16 | Brian Trammell | New version available: draft-ietf-taps-interface-16.txt |
2022-08-31
|
16 | Tommy Pauly | New version approved |
2022-08-31
|
16 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Reese Enghardt , Tommy Pauly |
2022-08-31
|
16 | Brian Trammell | Uploaded new revision |
2022-07-13
|
15 | Reese Enghardt | Holding this doc until the arch, interface, and impl docs have had all outstanding comments addressed and been aligned with each other. We will send … Holding this doc until the arch, interface, and impl docs have had all outstanding comments addressed and been aligned with each other. We will send the three docs to IESG as a set. |
2022-07-13
|
15 | Reese Enghardt | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2022-03-22
|
15 | Reese Enghardt | Added to session: IETF-113: taps Wed-1300 |
2022-03-07
|
15 | Tommy Pauly | New version available: draft-ietf-taps-interface-15.txt |
2022-03-07
|
15 | (System) | Posted submission manually |
2022-01-03
|
14 | Brian Trammell | New version available: draft-ietf-taps-interface-14.txt |
2022-01-03
|
14 | (System) | New version approved |
2022-01-03
|
14 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Christopher Wood , Colin Perkins , Gorry Fairhurst , Kyle Rose , Michael Welzl … Request for posting confirmation emailed to previous authors: Brian Trammell , Christopher Wood , Colin Perkins , Gorry Fairhurst , Kyle Rose , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Theresa Enghardt , Tommy Pauly |
2022-01-03
|
14 | Brian Trammell | Uploaded new revision |
2021-10-19
|
13 | Sean Turner | Request for Early review by SECDIR Completed: Has Issues. Reviewer: Sean Turner. Sent review to list. |
2021-09-17
|
13 | Robert Sparks | Request for Early review by ARTART Completed: On the Right Track. Reviewer: Robert Sparks. Sent review to list. |
2021-08-05
|
13 | Tero Kivinen | Request for Early review by SECDIR is assigned to Sean Turner |
2021-08-05
|
13 | Tero Kivinen | Request for Early review by SECDIR is assigned to Sean Turner |
2021-07-31
|
13 | Barry Leiba | Request for Early review by ARTART is assigned to Robert Sparks |
2021-07-31
|
13 | Barry Leiba | Request for Early review by ARTART is assigned to Robert Sparks |
2021-07-30
|
13 | Reese Enghardt | Requested Early review by ARTART |
2021-07-30
|
13 | Reese Enghardt | Requested Early review by SECDIR |
2021-07-28
|
13 | Reese Enghardt | Changed document external resources from: None to: github_repo https://github.com/ietf-tapswg/api-drafts |
2021-07-22
|
13 | Reese Enghardt | Added to session: IETF-111: taps Tue-1430 |
2021-07-12
|
13 | Brian Trammell | New version available: draft-ietf-taps-interface-13.txt |
2021-07-12
|
13 | (System) | Posted submission manually |
2021-05-07
|
12 | Reese Enghardt | Added to session: interim-2021-taps-05 |
2021-04-11
|
12 | Aaron Falk | IETF WG state changed to In WG Last Call from WG Document |
2021-04-09
|
12 | Tommy Pauly | New version available: draft-ietf-taps-interface-12.txt |
2021-04-09
|
12 | (System) | Posted submission manually |
2021-02-22
|
11 | Michael Welzl | New version available: draft-ietf-taps-interface-11.txt |
2021-02-22
|
11 | (System) | New version approved |
2021-02-22
|
11 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Christopher Wood , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind … Request for posting confirmation emailed to previous authors: Brian Trammell , Christopher Wood , Colin Perkins , Gorry Fairhurst , Michael Welzl , Mirja Kuehlewind , Philipp Tiesel , Theresa Enghardt , Tommy Pauly , taps-chairs@ietf.org |
2021-02-22
|
11 | Michael Welzl | Uploaded new revision |
2020-11-02
|
10 | Tommy Pauly | New version available: draft-ietf-taps-interface-10.txt |
2020-11-02
|
10 | (System) | New version accepted (logged-in submitter: Tommy Pauly) |
2020-11-02
|
10 | Tommy Pauly | Uploaded new revision |
2020-07-27
|
09 | Michael Welzl | New version available: draft-ietf-taps-interface-09.txt |
2020-07-27
|
09 | (System) | New version approved |
2020-07-27
|
09 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Theresa Enghardt , Tommy Pauly , Michael Welzl , Mirja Kuehlewind , Gorry Fairhurst … Request for posting confirmation emailed to previous authors: Brian Trammell , Theresa Enghardt , Tommy Pauly , Michael Welzl , Mirja Kuehlewind , Gorry Fairhurst , Colin Perkins , Philipp Tiesel , Christopher Wood |
2020-07-27
|
09 | Michael Welzl | Uploaded new revision |
2020-07-27
|
08 | Michael Welzl | New version available: draft-ietf-taps-interface-08.txt |
2020-07-27
|
08 | (System) | New version approved |
2020-07-27
|
08 | (System) | Request for posting confirmation emailed to previous authors: Brian Trammell , Michael Welzl , Colin Perkins , Gorry Fairhurst , Tommy Pauly , Philipp Tiesel … Request for posting confirmation emailed to previous authors: Brian Trammell , Michael Welzl , Colin Perkins , Gorry Fairhurst , Tommy Pauly , Philipp Tiesel , Theresa Enghardt , Christopher Wood , Mirja Kuehlewind |
2020-07-27
|
08 | Michael Welzl | Uploaded new revision |
2020-07-13
|
07 | Tommy Pauly | New version available: draft-ietf-taps-interface-07.txt |
2020-07-13
|
07 | (System) | Posted submission manually |
2020-03-09
|
06 | Tommy Pauly | New version available: draft-ietf-taps-interface-06.txt |
2020-03-09
|
06 | (System) | Posted submission manually |
2019-11-04
|
05 | Tommy Pauly | New version available: draft-ietf-taps-interface-05.txt |
2019-11-04
|
05 | (System) | New version accepted (logged-in submitter: Tommy Pauly) |
2019-11-04
|
05 | Tommy Pauly | Uploaded new revision |
2019-11-04
|
05 | (System) | Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Philipp Tiesel , Christopher Wood , Colin Perkins , Brian Trammell … Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Philipp Tiesel , Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst , Mirja Kuehlewind , Tommy Pauly |
2019-11-04
|
05 | Tommy Pauly | Uploaded new revision |
2019-11-04
|
05 | Tommy Pauly | Uploaded new revision |
2019-07-12
|
04 | Aaron Falk | Added to session: IETF-105: taps Mon-1330 |
2019-07-08
|
04 | Michael Welzl | New version available: draft-ietf-taps-interface-04.txt |
2019-07-08
|
04 | (System) | New version approved |
2019-07-08
|
04 | (System) | Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , taps-chairs@ietf.org, Christopher Wood , Colin Perkins , Brian Trammell , … Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , taps-chairs@ietf.org, Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst , Mirja Kuehlewind , Philipp Tiesel |
2019-07-08
|
04 | Michael Welzl | Uploaded new revision |
2019-03-20
|
03 | Aaron Falk | Added to session: IETF-104: taps Fri-1050 |
2019-03-11
|
03 | Christopher Wood | New version available: draft-ietf-taps-interface-03.txt |
2019-03-11
|
03 | (System) | New version approved |
2019-03-11
|
03 | (System) | Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst … Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst , Mirja Kuehlewind , Philipp Tiesel |
2019-03-11
|
03 | Christopher Wood | Uploaded new revision |
2018-10-22
|
02 | Aaron Falk | Added to session: IETF-103: taps Wed-1540 |
2018-10-22
|
02 | Brian Trammell | New version available: draft-ietf-taps-interface-02.txt |
2018-10-22
|
02 | (System) | New version approved |
2018-10-22
|
02 | (System) | Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst … Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst , Mirja Kuehlewind , Philipp Tiesel |
2018-10-22
|
02 | Brian Trammell | Uploaded new revision |
2018-07-17
|
01 | Aaron Falk | Changed consensus to Yes from Unknown |
2018-07-17
|
01 | Aaron Falk | Discussed and hummed on at IETF-102 meeting in Montreal. |
2018-07-17
|
01 | Aaron Falk | Intended Status changed to Proposed Standard from None |
2018-07-12
|
01 | Aaron Falk | Added to session: IETF-102: taps Tue-1550 |
2018-07-02
|
01 | Brian Trammell | New version available: draft-ietf-taps-interface-01.txt |
2018-07-02
|
01 | (System) | New version approved |
2018-07-02
|
01 | (System) | Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst … Request for posting confirmation emailed to previous authors: Michael Welzl , Theresa Enghardt , Christopher Wood , Colin Perkins , Brian Trammell , Gorry Fairhurst , Mirja Kuehlewind , Philipp Tiesel |
2018-07-02
|
01 | Brian Trammell | Uploaded new revision |
2018-05-15
|
00 | Aaron Falk | Added to session: interim-2018-taps-01 |
2018-04-30
|
00 | Brian Trammell | New version available: draft-ietf-taps-interface-00.txt |
2018-04-30
|
00 | (System) | WG -00 approved |
2018-04-30
|
00 | Brian Trammell | Set submitter to "Brian Trammell ", replaces to (none) and sent approval email to group chairs: taps-chairs@ietf.org |
2018-04-30
|
00 | Brian Trammell | Uploaded new revision |