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,

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

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

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

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

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

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

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

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,

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

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

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

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

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 capacity. Traffic Profile? G

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

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

at 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 the

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

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

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

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

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

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

, 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 sense is that they are most

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

[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

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

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

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

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

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

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

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

Date: Wed, 30 Aug 2017 02:19:23 -0700 From: internet-dra...@ietf.org To: Tom Jones <t...@erg.abdn.ac.uk>, Godred Fairhurst <go...@erg.abdn.ac.uk>, Gorry Fairhurst <go...@erg.abdn.ac.uk> A new version of I-D, draft-ietf-taps-transports-usage-udp-05.txt has been successful

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

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

generally provided by a > protocol or layer on top of the transport protocol; no current full- > featured standards-track transport protocol provides these features > on its own. Therefore, these features are not considered in this > document, with the exception of native auth

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

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

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

[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

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

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: