Re: [Taps] Concluded (Re: Consensus call on arch, interface, and impl, ACTION DUE by February 13th)

On 14/02/2024 23:12, Reese Enghardt wrote: Dear TAPS, The consensus call has concluded. The chairs have not seen any comments other than Tommy's words of encouragement below, thank you Tommy! So we'll conclude that there are no objections and that the documents are ready. Thanks again, al

Re: [Taps] Éric Vyncke's Discuss on draft-ietf-taps-arch-18: (with DISCUSS and COMMENT)

I also agree with what was threashed out, over quite some time, in the TAPS WG. I agree that someone can have a Transport Services system and could implement a different API to this - if that is what someone needed. The two are independent in this way, and other SDOs or companies could in futur

Re: [Taps] TAPS Dinner/Lunch at IETF117

On 12/07/2023 19:41, Reese Enghardt wrote: Hi, On 7/12/23 11:10, Tommy Pauly wrote: I’d be happy to meet up with TAPS folks for Monday/Tuesday/Wednesday lunch slots, depending on availability of everyone! That would work for me, too. Best, Reese _

Re: [Taps] Heads-up: Should we conclude TAPS after the three docs are done?

On 15/03/2023 20:52, Michael Welzl wrote: Hi ! I would love to have an interim. These are the things that I personally would like to discuss: 1) what could we now do to foster deployment of this? 2) is anyone really planning to write an http mapping document, ever? this would have to be (and

Re: [Taps] Normative language change in the Interface document (Re: I-D Action: draft-ietf-taps-interface-19.txt)

On 14/03/2023 10:24, Mirja Kuehlewind wrote: Hi all, first thanks for all the work! I reviewed the diffs below and actually have two questions on normative language, not on the content but on the use of normative language. In the arch doc, it's this sentence here " An application SHOULD NOT

Re: [Taps] Normative language change in the Interface document (Re: I-D Action: draft-ietf-taps-interface-19.txt)

On 10/03/2023 14:57, Brian Trammell (IETF) wrote: hi Reese, all, Apologies I haven’t been around on the answering-of-comments; it’s been a rough month. Thanks, all, for getting these revs of the documents out. I’ve reviewed the changes. - Arch changes are good, modulo the following non-blocki

[Taps] IPR: draft-ietf-taps-arch shepherd comments

ite “Yes” in good faith after having sent this email, and not getting any indication from anyone of you about IPRs. If there is anything, act immediately please. I know of no IPR relating to any of the 3 TAPS drafts. Best wishes, Gorry Fairhurst

Re: [Taps] Some comments on draft-ietf-taps-impl-12

On 05/08/2022 21:40, Fernando Gont wrote: Hi, Gorry, Thanks for all your responses! In-line On 5/8/22 12:00, Gorry Fairhurst wrote: Section 4.7.2.: On platforms with facilities to create a "virtual connection" for connectionless protocols implementations should use these mec

Re: [Taps] Some comments on draft-ietf-taps-impl-12

Thanks, I added trhese as issues #1054-1057, so we don't forget these topics. ... I also have one specific query below... On 05/08/2022 12:01, Fernando Gont wrote: Folks, Some comments/feedback on the aforementioned I-D: * Section 4.2.1.1. Local Endpoint candidates You should probably consi

Re: [Taps] Some comments on draft-ietf-taps-interface

On 05/08/2022 11:31, Fernando Gont wrote: 6.2.13. Use Temporary Local Address Name: useTemporaryLocalAddress Type: Preference Default: Avoid for Listeners and Rendezvous Connections. Prefer for other Connections. This property allows the application to express a preference for the use of tempora

Re: [Taps] Reviewing taps-impl-12

On 19/05/2022 12:47, Christian Amsüss wrote: Hello taps-impl authors, I've had a look at Implementing Interfaces to Transport Services from the point of view of a curious observer of the TAPS ecosystem without actual hands-on experience. (Also, I thought I'd review this for the ART review team -

Re: [Taps] Transport Services (taps) WG Virtual Meeting: 2021-12-08

aha ... me too, if nothing else, jitsi? Gorry On 08/12/2021 16:04, Tommy Pauly wrote: Yeah, I’m getting “unauthorized”... On Dec 8, 2021, at 8:03 AM, Martin Duke wrote: Meetecho login is down, so we may want to find ourselves an alternate app On Wed, Dec 8, 2021 at 7:51 AM Brian Trammell

Re: [Taps] Review of draft-ietf-taps-arch

These all look reasonable, and most easy to resolve. Now as github issues:-) Gorry On 20/10/2021 15:00, Aaron Falk wrote: Hi Michael- Thanks for the review. Glad to see the doc hasn’t ‘aged’ much as the others have been refined. Let’s assume I dropped the ball on reminding you about the rev

Re: [Taps] Artart early review of draft-ietf-taps-arch-11

On 17/09/2021 21:55, Robert Sparks via Datatracker wrote: Reviewer: Robert Sparks Review result: Not Ready This is an art-art early review of draft-ietf-taps-architecture My first observation and request is that the group rethink the separation of the architecture and interface documents. It is

Re: [Taps] W3C Web & Networks Interest Group

On 18/05/2021 22:05, Martin Duke wrote: This seems TAPS-ish: https://www.w3.org/2021/03/proposed-web-networks-charter.html I am not a W3C person, but do want to do a liaison statement about this? _

Re: [Taps] WGLC for draft-ietf-taps-interface (to conclude 26-Apr-2021)

On 11/04/2021 15:13, Aaron Falk wrote: Working group last call for the API draft starts now. Please review the draft and send comments to the list (including ‘ready to publish’ affirmations) or post issues/PRs to github . Thanks to the authors, edit

Re: [Taps] [Editorial Errata Reported] RFC8303 (6373)

*This seems like a typo that could be corrected, and I suggest the WG "Hold for Document Update", to correct future versions of the document when it is revised. Gorry * **On 29/12/2020 08:58, RFC Errata System wrote: The following errata report has been submitted for RFC8303, "On the Usage o

Re: [Taps] Should TAPS meet during IETF-108?

I'm OK  during the weeek or to skip the next interim, as long as we keep a couple of weeks clear either side of the IETF "meeting week:, so I don't end up with the weeks of IETF meetings that happended last time. Gorry On 26/05/2020 15:42, Kyle Rose wrote: Agreed 100%. Leslie and I are also ta

Re: [Taps] Intdir telechat review of draft-ietf-taps-transport-security-11

I think GRE (the one I know more) should be mentioned as existing somehow. even if the WG doesn't want to add an analysis of GRE! A suggested starting text blob proposal for GRE could be: Generic Routing Encapsulation [RFC2784] specifies a protocol for encapsulation of an arbitrary protoc

Re: [Taps] Kyle Rose's review of the API draft

"Avoid" should be "Prohibit", analogous to "Require" for selected properties. (Similarly, maybe the opposite of "Selected" is "Prohibited" in my alternative approach.) 11.1.10. Capacity Profile * Very little of this section is about cap

Re: [Taps] [ietf-tapswg/api-drafts] Reliable Data Transfer (Message) default - from Kyle Rose's review (#520)

We seem to need to decide what "Reliable Data Transfer" means to an Application. My point. expanding here a little, is: TAPS has to by default do something if the app doesn't say what it wants. So this is really about the default service chosen by TAPS.  A safe assumption is that an app not d

Re: [Taps] April interim: - My promised review of normative arch language (derived from github).

least. Sure - have you an idea for a "placeholder bullet" we can add to my list below... so we don't loose the thought... Gorry Mirja On 25.03.20, 17:03, "Taps on behalf of Gorry Fairhurst" wrote: As promised, I did a review of the arch draft and

Re: [Taps] April interim: - My promised review of normative arch language (derived from github).

As promised, I did a review of the arch draft and the PR that was recently done. There were comments that requested to remove some normative language that has been implemented in the current draft - where my review agreed, I have not commented further below. However, the latest revision, also

[Taps] Review of Arch wrt to normative requirements on the architecture

I have now reveiwed the Arch document for normative language, as promised. After the review, I would still be in favour of using RFC2119 language to describe what is required architecturally to be a TAPS system. In my review, I agree the number of requirements is now reduced. I really do won

Re: [Taps] draft-ietf-taps-interface-05 review

See in-line On 05/03/2020 07:30, Michael Welzl wrote: Hi, A few comments in line: On Mar 4, 2020, at 5:51 PM, Philipp S. Tiesel > wrote: Hi, Some of the remaining issues had already been discussed, but either did not lead to text or the text was lost. Let me com

Re: [Taps] WGLC for draft-ietf-taps-arch (Jan 7-20, 2020)

I have some minor editorial comments from a careful reading (see below). Best wishses, Gorry (P.S. I'm an editor for this document and I do think the I-D is ready to proceed). --- In Section 2: /The Socket API/ The text uses /sockets/, but previously the text in 2.1 talks about the Socket

Re: [Taps] On Profiles for TAPS Preconnections

Hi all, see below - how near are we to agreement? On 23/07/2019, 14:21, Brian Trammell (IETF) wrote: hi Tommy, all, On 22 Jul 2019, at 19:15, Tommy Pauly wrote: On Jul 22, 2019, at 6:56 PM, Philipp S. Tiesel wrote: Hi, On 22. Jul 2019, at 15:09, Tommy Pauly wrote: An issue we discu

Re: [Taps] How to handle Protocol stacks that are not equivalent

On 23/07/2019, 10:31, Tommy Pauly wrote: My initial impression here is that any protocol stacks that provide the same transport services, and thus can be raced as candidates, need to be equivalent. It ends up being a bit tautological. The description in the architecture explains what combinati

Re: [Taps] updated agenda - Re: Transport Services (taps) WG Virtual Meeting: 2019-05-08

Could we please add some time to discuss the parameters and defaults - Phil has been trying to get these into shape for some time and the text in the iD has evolved to a place where decisions now need to be made, and I'd really rather this was not pushed to the end of the agenda as "other issue

Re: [Taps] WGLC for draft-ietf-taps-transport-security (ending 4/29)

Review of draft-ietf-taps-transport-security-06. I have read the above document as a transport person, and contributor to the group and think this document contains the material that was discussed by the working group and is very near a version that is ready to publish. I have a number of co

Re: [Taps] To registry, or not to registry?

Michael On Aug 6, 2018, at 11:44 AM, Gorry Fairhurst wrote: I quite like the idea of trying to design a simple registry format. If it looks good, I'd be happy to see this go forward. Gorry On 24/07/2018 19:13, Aaron Falk wrote: Caveat: I am not an expert on registries but my se

Re: [Taps] Progress on address usage documents

On 07/08/2018, 18:00, Tommy Pauly wrote: On Aug 7, 2018, at 9:26 AM, Fernando Gont wrote: Hello, Gorry, On 08/07/2018 05:26 PM, Gorry Fairhurst wrote: To me, this topic is tricky to position, and there are still multiple parts across the two documents. One way could be to agree the

Re: [Taps] Progress on address usage documents

To me, this topic is tricky to position, and there are still multiple parts across the two documents. One way could be to agree the properties of different address types on scope and stability, devoid of API and Application-considerations - I at the moment don't currently understand this enou

Re: [Taps] To registry, or not to registry?

I quite like the idea of trying to design a simple registry format. If it looks good, I'd be happy to see this go forward. Gorry On 24/07/2018 19:13, Aaron Falk wrote: Caveat: I am not an expert on registries but my sense is that they are most useful for interoperability. I think Gorry's c

[Taps] Some editorial comments from a read through of draft-ietf-taps-transport-security-01

I have just quickly read the TAPS document on transport security and have a few comments that may be useful for the next revision, Gorry --- “TCP-AO adds authenticity” - should this be “TCP-AO adds authentication” our an authentication service? “AH adds per-datagram authenticity” - should thi

Re: [Taps] ACTION REQUIRED: updating session conflicts

ACK - works for me, I'd love to add: intarea (as a contributor, and TSVWG reviewer). My own conflicts map to what you have: First Priority: maprg tcpm iccrg tsvwg tsvarea Second Priority: rmcat, quic Gorry On 17/04/2018, 16:22, Aaron Falk wrote: Hi Folks- We should update our conflict lis

Re: [Taps] [Editorial Errata Reported] RFC8095 (5285)

This Errata seems valid. Sorry that was not spotted. Gorry On 12/03/2018, 03:54, RFC Errata System wrote: The following errata report has been submitted for RFC8095, "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms". -- You m

Re: [Taps] New Version Notification for draft-fairhurst-taps-neat-01.txt

We've just posted a minor rev to the ID. It contains corrections to INIT_FLOW; fixes to typos. It also includes a diagram, which we did not have time to draw before the meeting, but seemed useful for a discussion. Gorry On 13/11/2017, 13:34, internet-dra...@ietf.org wrote: A new version of I

Re: [Taps] IETF100 meeting agenda uploaded

It seems to me there are many ideas that could come forward if the work in TAPS progresses. To me the three IDs we currently have are quite different - and they seem to have different design goals. I suggest if the group is thinking of accepting work against the third item in the charter tha

Re: [Taps] New Version Notification for draft-fairhurst-taps-neat-00.txt

TAPers, I've just uploaded an Internet Draft on the NEAT User API, this draft provides a high-level overview of the transport interface to the actual NEAT System (available on GIT-Hub) and outlines how this forms an API that can offer TAPS-like services in an actual system. Gorry On 30/10/2

Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-udp-07.txt

TAPs people, Here is a new revison of the ID. We think this version addresses all requested changes aftre IESG review. There was also one request to adjust the abstract, but we have not done so (if the way in which the present abstract refers to taps-transport-usage is not as desired by our

Re: [Taps] One RFC, or two, for draft-ietf-taps-transports-usage and draft-ietf-taps-transports-usage-udp

On 14/09/2017, 15:55, Spencer Dawkins at IETF wrote: And, following up during the actual telechat ... On Wed, Sep 13, 2017 at 11:47 PM, Spencer Dawkins at IETF mailto:spencerdawkins.i...@gmail.com>> wrote: Dear TAPS working group, Multiple ADs have asked why these two drafts aren't

Re: [Taps] Benoit Claise's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

On 14/09/2017, 14:05, Benoit Claise wrote: Benoit Claise has entered the following ballot position for draft-ietf-taps-transports-usage-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this i

Re: [Taps] Suresh Krishnan's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT)

Thanks Suresh, please see below. On 14/09/2017, 00:12, Suresh Krishnan wrote: Suresh Krishnan has entered the following ballot position for draft-ietf-taps-transports-usage-udp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the

Re: [Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

On 11/09/2017, 16:48, Mirja Kühlewind wrote: Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-transports-usage-08: No Objection -- COMMENT:

Re: [Taps] Eric Rescorla's No Record on draft-ietf-taps-transports-usage-08: (with COMMENT)

Hi Eric, The text you mention is the final para of section 3 of RFC 7413. I suspect the most appropriate correction would be to identify the section number in the text, as done for other cited RFCs, e.g. Section 3 of RFC7413 states that a TCP implementations MUST NOT use TFO by default, but o

[Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-udp-05.txt

txt Date: Wed, 30 Aug 2017 02:19:23 -0700 From: internet-dra...@ietf.org To: Tom Jones , Godred Fairhurst , Gorry Fairhurst A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt has been successfully submitted by Godred Fairhurst and posted to the IETF repository. Name:

Re: [Taps] AD review of draft-ietf-taps-transports-usage-udp-04

Thanks Spencer, I have added new text which I hope addresses these issues in the next revision. Gorry On 24/08/2017, 21:09, Spencer Dawkins at IETF wrote: I'm actually pretty positive on this draft - most of what follows is editorial. Thanks, Spencer This text This document is intended

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

Thanks for dealing with this, comments in-line. On 16/05/2017 15:09, Michael Welzl wrote: Hi, Thanks a lot for your comments! Answers in line below, marked with [Michael]. When I say "done" I mean my local copy - still need to fix some more nits, but I thought sharing this answer already now

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

More below. On 12/05/2017, 16:27, Michael Welzl wrote: On May 12, 2017, at 3:24 PM, Gorry Fairhurst wrote: See below. On 12/05/2017, 13:31, Michael Welzl wrote: Hi, Thanks a lot for all your comments (plus the nits we authors of the other -usage draft received offline). I’ll try to

Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

See below. On 12/05/2017, 13:31, Michael Welzl wrote: Hi, Thanks a lot for all your comments (plus the nits we authors of the other -usage draft received offline). I’ll try to address them all - but there are a two technical questions in this email that made me stop, so I’ll cut all the edit

[Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

integrity protection > are identified as Transport Features by [RFC8095]. As currently > deployed in the Internet, these features are generally provided by a > protocol or layer on top of the transport protocol; no current full- > featured standards-track transport protocol provi

Re: [Taps] Comments on draft-gjessing-taps-minset-02 - just DSCP

On 26/03/2017, 13:59, Michael Welzl wrote: On Mar 26, 2017, at 12:13 PM, Gorry (erg) wrote: This reply is just about the DSCP and QoS. Everything you say about TAPS trying to set DSCP values seems consistent with normal diffserv use to me: Just because an app sets a DSCP does not mean the a

[Taps] Comments on draft-gjessing-taps-minset-02

This looks like good progress. A few very specific comments below: --- I see phrase: " Because QoS is out of scope of TAPS, this document assumes a "best effort" service model [RFC5290], [RFC7305]. " I'm not sure we need to state this. Although I agree that TAPS will not propose new QoS t

Re: [Taps] MTU / equivalent at the transport layer

It seems we can not find a common basis here. See below: On 14/12/2016 01:23, Joe Touch wrote: On 12/13/2016 5:34 AM, Gorry Fairhurst wrote: ... (1) I think we need a parameter returned to the App that is equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is useful to know how

Re: [Taps] MTU / equivalent at the transport layer

On 13/12/2016 12:53, Michael Welzl wrote: On 13 Dec 2016, at 11:05, Gorry Fairhurst wrote: On 13/12/2016 09:13, Michael Welzl wrote: Hi, This direction definitely makes sense to me, too. I see some tension here, though - on the one hand, Joe is (as usual) arguing "cleanliness",

Re: [Taps] MTU / equivalent at the transport layer

(and anything else appropriate -as you note). I am all in favour of such appropriate abstraction. Gorry On 12 Dec 2016, at 19:09, Joe Touch wrote: On 12/12/2016 10:58 AM, Gorry Fairhurst wrote: IMO, the app should never need to play with DF. It needs to know what it thinks the transport can deli

Re: [Taps] MTU / equivalent at the transport layer

On 12/12/2016 18:50, Joe Touch wrote: On 12/12/2016 3:45 AM, Gorry Fairhurst wrote: So what does that mean: that the API should contain a "don't fragment" flag from the application? Definitely. The use of DF in a datagram protocol is per-datagram decision - depending on wha

Re: [Taps] MTU / equivalent at the transport layer

On 12/12/2016 09:31, Michael Welzl wrote: Hi, Just trying to understand, so we're not talking past each other. Please note that I'm not trying to argue in any direction with my comments below, just asking for clarification: On 09 Dec 2016, at 18:32, Joe Touch wrote: On 12/9/2016 8:12 AM

Re: [Taps] MTU / equivalent at the transport layer

On 09/12/2016 08:09, Michael Welzl wrote: On 07 Dec 2016, at 20:29, Joe Touch wrote: FYI, there are two different "largest messages" at the transport layer: 1) the size of the message that CAN be delivered at all True... I wasn't thinking of that, but yes. 2) the size of the message that c

Re: [Taps] MTU / equivalent at the transport layer

Not quoite answering this question, but for DCCP this is clearly also a transport understanding of the maxmium datagram size, as in RFC 4340: "A DCCP implementation MUST maintain the maximum packet size (MPS) allowed for each active DCCP session." and "The MPS reported to the application SHOUL

Re: [Taps] New Version Notification for draft-fairhurst-taps-transports-usage-udp-03.txt

We have just submitted an updated copy of the UDP usage draft we have been working on in TAPS. Specifically: (1) It omits the text for pass 2 and 3 that we now expect to be directly incorporated in draft-ietf-taps-transport-usage. Michael Welzl I think indicated that this text will be copied f

[Taps] Going forward with draft-fairhurst-taps-transports-usage-udp-02 in TAPS?

At the TAPS meeting in Berlin, I said the authors think that all the comments we knew about have been addressed by new text. I also took away a promise to ask about the proposed publication of this UDP/UDP-Lite usage draft. My suggestion at the meeting was that the TAPS WG should adopt the UD

[Taps] : New Version Notification for draft-fairhurst-taps-transports-usage-udp-02.txt

We have submitted a new version of the UDP Usage document. This incorporates changes to fix some details, but more importantly a set of changes that were motivatd by review comments for the 01 version. The authors hope this version now incorporates all details needed to allow the TAPS WG to p

[Taps] new TAPS ID: draft-fairhurst-taps-transports-usage-udp-00

We have just posted a new ID: Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols https://datatracker.ietf.org/doc/draft-fairhurst-taps-transports-usage-udp/ This document provides input on UDP and UDP-Lite usage for the TAPS WG. In putting this t

Re: [Taps] IETF planning

On 26/10/2015 13:46, Michael Welzl wrote: On 26. okt. 2015, at 14.17, Aaron Falk mailto:aaron.f...@gmail.com>> wrote: On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst mailto:go...@erg.abdn.ac.uk>> wrote: On 22/10/2015 15:14, Aaron Falk wrote: > draft-welzl-

Re: [Taps] IETF planning

On 22/10/2015 15:14, Aaron Falk wrote: > draft-welzl-taps-transports currently only covers TCP and SCTP. But then: how many other protocols? > It seems people agree that the protocols covered in draft-welzl-taps-transports should be a subset of the protocols covered in draft-ietf-taps

Re: [Taps] document progress update?

I'd have thought it was worth seeing if FECFRAME fits as something to talk about. It is used in places. There are transport concerns that differ and could be highlighted - because some uses require pre-provisioned capacity (aka, do not have CC), so we probably need to say something about m

Re: [Taps] draft minutes -- please review

On 06/08/2015 09:50, Mirja Kühlewind wrote: ant to mention that there are different kinds of congestion control (as it is already done in the doc) but there is no need to e.g. describe LEDBAT in detail. I fixed some minor English NiTS and added this to the Etherpad version: http://etherpad.too

Re: [Taps] Fwd: I-D Action: draft-ietf-taps-transports-02.txt

This version includes my first go at a table, in section 4.1, I'm hoping this will stimulate some input/corrections, or even perhaps alternate list of what to see here. Please discuss, or send comments via the TAPS list. gorry straw On 07/02/2015 12:41, Brian Trammell wrote: Greetings,

[Taps] Fwd: Fwd: Re: So, catching back up on the charter

So on the Charter, as at: https://datatracker.ietf.org/doc/charter-ietf-taps/ This is a much longer rant than I wanted, so if you read no more, the main point is in the next para: I think the M18 milestone (also called No 3) is well-intentioned, especially if targeted as an EXP RFC. To me thi