Re: [Taps] draft-trammell-post-sockets

Based on the discussions we had with several folks after the meeting, the feeling was that the some of the Post Sockets API approach probably was in scope for the third item of the TAPS charter. Here's that item for reference: "3) Specify experimental support mechanisms to provide the Transport

Re: [Taps] draft-trammell-post-sockets

cope of charter item 3: maybe, to some degree, > but at this point more useful as input to item 2 IMO. > > Cheers, > Michael > > >> On Nov 16, 2016, at 4:12 PM, Tommy Pauly > <mailto:tpa...@apple.com>> wrote: >> >> Based on the discussions we h

Re: [Taps] agenda planning for chicago

Hi Aaron, We should have updates by March on the Post-Sockets progress, as well as filling in details that we we're able to get to last time. Please do allocate an agenda slot for that! Thanks, Tommy > On Dec 21, 2016, at 7:25 AM, Aaron Falk wrote: > > The secretariat has issued the call for

Re: [Taps] [irsg] Experimental Breakout Room Layout

Sounds like a neat idea! Worth a try at least. Tommy > On Feb 13, 2017, at 7:28 PM, Aaron Falk wrote: > > Hey TAPS working group- > > I think this layout would be a good fit for our ‘seminar-style’ discussion. > Any objection to trying it in Chicago? > > —aaron > > Forwarded message: > >>

[Taps] TAPS: Software Guidelines for Protocol Evolution

;d be happy to continue working on it. Best, Tommy > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-pauly-taps-guidelines-00.txt > Date: February 7, 2017 at 4:05:58 PM PST > To: Tommy Pauly > > > A new

Re: [Taps] agenda planning for chicago

> On Feb 23, 2017, at 12:55 AM, Michael Welzl wrote: > > >> On Feb 22, 2017, at 3:54 PM, Aaron Falk wrote: >> >> Trimming for focus… >> What are the key questions TAPS should be focusing on at this meeting? >>> I can think of these 3 major questions that appeared to us when

Re: [Taps] New Version Notification for draft-grinnemo-taps-he-02.txt

> On Mar 27, 2017, at 6:35 PM, Anna Brunstrom wrote: > > Hi Joe, > > Thanks for your comments! > On 2017-03-21 23:41, Joe Touch wrote: >> Hi, all, >> >> Some observations: >> >> - HE-trans MUST NOT be used to try different combinations of options within >> a given transport >> > > Sounds

Re: [Taps] WGLC start for -transports-usage- docs

Agreed, these both look ready to go! Just a few minor typographical nits below; these could be cleaned up later. Best, Tommy Usage Draft: - In Section 3.1, the style of most items is lower case without underscores; however there are "USER TIMEOUT event:” and "ERROR_REPORT event:”, and then the

[Taps] User-Space Networking in iOS 11

Hello, I wanted to point the TAPS group to some of the work that we announced this week at WWDC that relates to the Post-Sockets API effort. You can see a video of the session here (relevant section at ~13:50), along with the slides: https://developer.apple.com/videos/play/wwdc2017/707

Re: [Taps] User-Space Networking in iOS 11

HI Michael, > On Jun 8, 2017, at 7:13 PM, Michael Tuexen > wrote: > > On 8. Jun 2017, at 15:50, Tommy Pauly wrote: >> >> Hello, >> >> I wanted to point the TAPS group to some of the work that we announced this >> week at WWDC that relates to

Re: [Taps] User-Space Networking in iOS 11

> On Jun 9, 2017, at 4:55 PM, Michael Tuexen > wrote: > >> On 9. Jun 2017, at 12:16, Tommy Pauly wrote: >> >> HI Michael, >> >>> On Jun 8, 2017, at 7:13 PM, Michael Tuexen >>> wrote: >>> >>> On 8. Jun 2017, at 15:50, T

Re: [Taps] User-Space Networking in iOS 11

> On Jun 9, 2017, at 10:04 AM, Mikael Abrahamsson wrote: > > On Fri, 9 Jun 2017, Tommy Pauly wrote: > >> The kernel is still responsible for managing the port namespace between >> applications, and demultiplexing incoming packets to the correct processes. >> Si

Re: [Taps] Socket Intents Draft – draft-tiesel-taps-socketintents-00

Hi Philipp, Thanks for sharing this document! Providing an API for generic network intents is something of a Holy Grail—valuable but elusive to nail down. This document should be a good place to start a conversation, and I look forward to discussing it in Prague. A few initial comments: - I’d

Re: [Taps] Prague agenda planning

Hi Aaron, We have a draft we’ll be publishing in the next week that does a survey of Transport Security protocols, and the interfaces they expose to the transport layer as well as applications. We’d like to have a slot to discuss this topic with the WG. Thanks, Tommy > On Jun 27, 2017, at 12:

Re: [Taps] Prague agenda planning

proposing this as a wg item? > > --aaron > > On 27 Jun 2017, at 16:22, Tommy Pauly wrote: > > Hi Aaron, > > We have a draft we’ll be publishing in the next week that does a survey of > Transport Security protocols, and the interfaces they expose to the transport &

Re: [Taps] Prague agenda planning

> On Jun 29, 2017, at 9:07 AM, Brian Trammell (IETF) wrote: > > hi Aaron, > >> On 29 Jun 2017, at 17:36, Aaron Falk wrote: >> >> Updating. Our agenda time is much more productive if we can home in on >> specific questions to discuss rather than just give document overviews. >> Authors & ot

[Taps] Fwd: New Version Notification for draft-pauly-taps-transport-security-00.txt

> A new version of I-D, draft-pauly-taps-transport-security-00.txt > has been successfully submitted by Christopher A. Wood and posted to the > IETF repository. > > Name: draft-pauly-taps-transport-security > Revision: 00 > Title:A Survey of Transport Security Protocol

[Taps] Fwd: New Version Notification for draft-kuehlewind-taps-crypto-sep-00.txt

> Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for draft-kuehlewind-taps-crypto-sep-00.txt > Date: July 3, 2017 at 8:08:21 AM PDT > To: Mirja Kuehlewind , Christopher Wood > , Tommy Pauly , "Christopher A. Wood"

[Taps] New Drafts on Transport Security Interface for TAPS

Hello, We’ve just posted two new documents that start addressing how to incorporate security protocols into the TAPS framework for use alongside transport protocols. At the meeting in Chicago, the question of how security protocols should be handled was brought up, and we suggested writing a dr

Re: [Taps] User-Space Networking in iOS 11

link? I ask this because the user-space packet io needs a different > driver for different links as far as i know. b) does the user space > networking always performs better than the kernel counterpart? > > Many thanks > Zhen > > On Fri, Jun 9, 2017 at 3:50 AM, Tommy Pauly w

Re: [Taps] Charter change for security

Agreed. Thanks for the text proposal, Kyle! Tommy > On Jul 18, 2017, at 12:15 PM, Brian Trammell (IETF) wrote: > > +1. > > Cheers, > > Brian > >> On 18 Jul 2017, at 12:02, Michael Welzl wrote: >> >> Agree 100% - I think this proposal is exactly the right way to do it. >> >> Cheers, >> Mic

Re: [Taps] singapore

Sounds good! We're planning on having an update to the Post Sockets document, as well as consolidating some documents around Connection Establishment (Happy Eyeballs + other Racing) and Policy. Thanks, Tommy > On Aug 14, 2017, at 12:07 PM, Aaron Falk wrote: > > Hi all- > > My assumption is t

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

Hi Spencer, As an API implementer, I would say this: - I did need to reference the content of both documents (or the equivalent information that is included in the documents, before they were complete) in our implementation - However, implementing the API details for unconnected datagram-based

Re: [Taps] call for agenda items

I've just revised my "guidelines" draft to be "Guidelines for Racing During Connection Establishment": https://datatracker.ietf.org/doc/draft-pauly-taps-guidelines/ https://tools.ietf.org/html/draft-pauly-taps-guidelines-01

Re: [Taps] call for agenda items

; somewhere in > the doc:, i think:) A fair point! We can definitely find a better term. Parallel might work, although really what we want to discuss here is mainly a staggered-start race of the various options. Best, Tommy > > On Wed, Oct 25, 2017 at 5:54 AM, Tommy Pauly <mailto:

Re: [Taps] IETF100 meeting agenda uploaded

One quick thought on this: I think that the charter item 3 (the recommended mechanisms for deploying a TAPS system) can and should certainly include multiple documents. These documents we'll be talking about are in no way mutually exclusive, so I don't think we should be thinking of it as "hear

Re: [Taps] IETF100 meeting agenda uploaded

elzl wrote: > > Hi, > > I almost agree :-)I agree that there should be several documents, along > the lines of what you write - but I do think there should be only one API… > > Cheers, > Michael > > >> On Nov 5, 2017, at 9:44 PM, Tommy Pauly > <mail

Re: [Taps] Review of draft-trammell-taps-post-sockets-03

Hi Michael, Just a couple initial notes that may help: - The version diff you should look at is between -01 and -03. -02 is the same as -03, but had a typo. - You've mentioned previously that you thought that Post requires both peers to use that API. That is absolutely not the case in any way.

Re: [Taps] Review of draft-trammell-taps-post-sockets-03

> On Nov 11, 2017, at 10:36 AM, Michael Welzl wrote: > > >> On Nov 11, 2017, at 10:06 AM, Tommy Pauly wrote: >> >> Hi Michael, >> >> Just a couple initial notes that may help: >> >> - The version diff you should look at is between -01

Re: [Taps] API design: dependencies or buffer control?

The code I work with does TCP_NOTSENT_LOWAT by default, so we have a fair amount of experience with it. If you're using sockets with TCP_NOTSENT_LOWAT, and you're doing asynchronous non-blocking socket operations, then you don't have the annoyance of getting these "empty" callbacks you're referr

Re: [Taps] Review of draft-trammell-taps-post-sockets-03

> On Nov 11, 2017, at 2:09 PM, Michael Welzl wrote: > > Hi, > > In line: > >> On Nov 11, 2017, at 11:58 AM, Tommy Pauly > <mailto:tpa...@apple.com>> wrote: >> >> >> >>> On Nov 11, 2017, at 10:36 AM, Michael Welzl >> <

Re: [Taps] API design: dependencies or buffer control?

> On Nov 13, 2017, at 10:08 AM, Michael Welzl wrote: > > >> On Nov 13, 2017, at 7:54 AM, Tommy Pauly wrote: >> >> The code I work with does TCP_NOTSENT_LOWAT by default, so we have a fair >> amount of experience with it. > > I figured :-) AFAI

Re: [Taps] I-D Action: draft-ietf-taps-minset-00.txt

A couple initial comments on the minset document: In Section 4: - Title should be "4. A MinSet Abstract Interface" not "4. An MinSet Abstract Interface" For this: 3. Not offer any of the transport features of these protocols and the LEDBAT congestion control mechanism that do not req

Re: [Taps] Charter change for security

nge request to the ADs… > > —aaron > > > On 18 Jul 2017, at 13:40, Robert Moskowitz wrote: > >> I just joined this list. >> >> I can work with this. >> >> Bob >> >> On 07/18/2017 01:36 PM, Tommy Pauly wrote: >>> Agreed. Th

[Taps] TAPS Documents for Charter Item 3

Hello TAPS, In Singapore, there was much discussion about where we go after the minset drafts, and what documents will form charter item 3: 3) Specify experimental support mechanisms to provide the Transport Services identified in work item 2. This document will explain how to select and engag

Re: [Taps] TAPS Documents for Charter Item 3

> On Jan 11, 2018, at 12:23 AM, Michael Welzl wrote: > > Hi Tommy, > > A few answers below: > >> On Jan 10, 2018, at 6:11 PM, Tommy Pauly > <mailto:tpa...@apple.com>> wrote: >> >> Hello TAPS, >> >> In Singapore, there was much d

Re: [Taps] TAPS Documents for Charter Item 3

t tolerable given the > researchy nature of the wg. > > —aaron > > On 18 Jan 2018, at 10:02, Christopher Wood wrote: > > On Thu, Jan 11, 2018 at 7:28 AM, Tommy Pauly <mailto:tpa...@apple.com>> wrote: > > >> On Jan 11, 2018, at 12:23 AM, Michael Welzl >

Re: [Taps] IPv6 address usage problem statement?

Yes, I think this topic is very relevant to the work that can be done in updated transport APIs, specifically around Path Selection. This is relevant both for initial connection establishment (when we’re racing various transport protocols across different paths, we need to know which local addre

Re: [Taps] For comment: TAPS milestone revisions

+ 1 This list looks good to me, if the rest of the WG is happy with it! Tommy > On Feb 13, 2018, at 2:20 PM, Michael Welzl wrote: > > I think this is a great way forward! > > Cheers, > Michael > > >> On Feb 13, 2018, at 7:43 PM, Aaron Falk > > wrote: >> >> Dear

Re: [Taps] Call for agenda items

Hi Zahed & Aaron, We’ve posted the first of three new documents proposed for milestone 3, "An Architecture for Transport Services” (please go read it, everyone!): https://datatracker.ietf.org/doc/draft-pauly-taps-arch https://tools.ietf.o

Re: [Taps] [TAPS] Call for agenda items

> On Mar 5, 2018, at 11:14 AM, Anna Brunstrom wrote: > > Hi Zahed, Aaron, all, > On 2018-03-01 15:54, Brian Trammell wrote: >> hi Zahed, Aaron, all, >> >> > On 27 Feb 2018, at 18:28, Tommy Pauly >> > <mailto:tpa...@apple.com>>; wrote: >&

Re: [Taps] conflicting policies

Agreed that the implementations should not do “magical” or unexpected things. In the example question there are actually two elements at play: - How to rank preferences and policies at connection establishment time - How to treat path changes that may be disruptive to established connections For

Re: [Taps] ACTION REQUIRED: updating session conflicts

Hi Aaron, I’m also an author/editor for capport and ipsecme, so I’d like to add those to the list if possible. Thanks, Tommy > On Apr 19, 2018, at 8:26 AM, Aaron Falk wrote: > > Updated: > > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg > tls > Second Priorit

[Taps] Minset WGLC Review

Hello TAPS, I’ve just done a read through of the current minset draft. Overall, looks good! I have a few nits, but these can all be addressed in the next revision: - The first sentence of the abstract is a bit hard to parse for someone who isn’t coming from the context of the working group: "

[Taps] New Transport Networking APIs in iOS 12 beta

Hello TAPS! This week we released Network.framework, a new set of transport APIs, as part of the beta for iOS 12 and macOS Mojave. This API provides support for connections and listeners using TCP, UDP, TLS, and DTLS; connecting by name or service, with happy eyeballs support for addresses, in

Re: [Taps] New Transport Networking APIs in iOS 12 beta

transports like SCTP and QUIC! The model of the connection sending and receiving messages is sufficiently generic to support any of the TAPS protocols. Best, Tommy On Jun 9, 2018, at 11:38 AM, Michael Tuexen wrote: >> On 8. Jun 2018, at 18:29, Tommy Pauly wrote: >> &

Re: [Taps] New Transport Networking APIs in iOS 12 beta

> On Jun 15, 2018, at 1:00 AM, Michael Welzl wrote: > > Hi, > > Thanks for sharing this! It’s quite interesting - > > >> On Jun 11, 2018, at 6:47 PM, Jonathan Lennox > > wrote: >> >> I’ve read over Apple’s new API. (One note: the URL that Tommy sent a link >> to

Re: [Taps] Call for agenda item for IETF 102

It looks like TAPS has a 2.5 hour slot, which is good! We’ll be publishing some -01 versions of the architecture, interface, and implementation drafts before the submission deadline, so I think we should have slots for those documents. We haven’t worked out the details yet, but I imagine having

Re: [Taps] Call for agenda item for IETF 102

> On Jun 28, 2018, at 7:40 AM, Tom Jones wrote: > >> On Thu, Jun 28, 2018 at 06:41:04AM -0700, Tommy Pauly wrote: >> One other agenda proposal I’d like to make is a section highlighting >> some implementation experiences that can influence our drafts. I think >>

Re: [Taps] Agenda for IETF 102

I can do the architecture update presentation. Best, Tommy > On Jul 6, 2018, at 2:15 AM, Brian Trammell (IETF) wrote: > > hi Zahed, > > Sign me up to present -interface. > > Thanks, cheers, B > > Sent from my iPhone > >> On 5 Jul 2018, at 23:29, Zaheduzzaman Sarker >> wrote: >> >> Hi, >>

[Taps] To registry, or not to registry?

Hello TAPS, Migrating a thread from GitHub to the email list, since it needs broad WG input. I've pasted the discussion so far below. Essentially, the question is if we have a set of standard properties for Transport Services APIs, should they have a formal registry or not? Thanks, Tommy

Re: [Taps] IPv6 address usage

Picking this thread up again, I would like to see us incorporate IPv6 address selection into a post-sockets API model. Here's a straw man proposal of how we can expose this via the TAPS Interface: - A new property for Local Address Preference, which can be a tuple of: 1. Stable/Public 2.

Re: [Taps] IPv6 address usage

f used by default > on very short live connections > > Just a thought > > -éric > > On 25/07/2018, 12:02, "Taps on behalf of Tom Jones" on behalf of t...@erg.abdn.ac.uk> wrote: > >On Tue, Jul 24, 2018 at 07:58:27PM -0700, Christopher Wood wrote: >

Re: [Taps] Progress on address usage documents

> 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 properties of different addr

Re: [Taps] Secdir last call review of draft-ietf-taps-minset-06

Hi Yaron, This minimal set is a description of the surface that any generic API must have to cover the common *transport* features of protocols only. This document is not meant in itself to describe an API that applications use directly, but instead describe the distilled feature set from trans

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

/07/2018, 21:32, David Schinazi wrote: >>> >>> We had a similar discussion in the Babel WG regarding link >>> types in our data model - which isn't sent over the wire. >>> We landed on having an IANA registry of strings so there is >>

Re: [Taps] Transport Services (taps) WG Virtual Meeting: 2018-09-12

Hi Aaron, 1. I think those discussion points are still relevant, as they've had continuing discussion on the open GitHub issues. 2. Based on discussion, I think it would be helpful to add a conversation to review Connection and Message Properties (https://github.com/taps-api/drafts/issues/218)

Re: [Taps] QUIC API for WebRTC

Hi Michael, Thanks for sharing! We recently saw this too, and my impression is similar. Ideally, from a WebRTC application's perspective, we should have a TAPS system that helps set up ICE, determines which protocol stack to use (SCTP/DTLS, SRTP, QUIC, etc), and lets the application interact wi

Re: [Taps] QUIC API for WebRTC

> On 11 Oct 2018, at 17:14, Tommy Pauly wrote: > > I think this also brings up a point that it may be good to have a discussion > in Bangkok with the group about getting a bit more in detail to how TAPS can > best serve WebRTC use cases, and make that aspect of the API really c

Re: [Taps] call for TAPS agenda items

> On Oct 19, 2018, at 10:42 AM, Aaron Falk wrote: > > 3rd prod for Bangkok agenda items... > > On 15 Oct 2018, at 10:53, Aaron Falk wrote: > > The final agenda moved TAPS to Weds Afternoon II and 90 minutes. > > Here are the issues raised on the list for discussion in Bangkok: > > TAPS Regi

[Taps] Discussing QUIC API mappings in TAPS

Hello QUIC, I wanted to highlight to the working group that this week we'll be having a discussion around transport API mappings for QUIC in the Transport Services (TAPS) working group. The goal is to ensure that applications are able to smoothly migrate to QUIC from other protocols, even when

[Taps] Discussing WebRTC API mappings in TAPS

Hello rtcweb, Based on recent proposals for WebRTC APIs to run over QUIC, the Transport Services (TAPS) working group will be spending some time this week looking at the usefulness and applicability of our flexible transport APIs for use in WebRTC. One of the main goals is providing an API surf

Re: [Taps] document plan / milestone update

That schedule looks good to me, and is what I recall from the meeting discussion as well! Best, Tommy > On Nov 13, 2018, at 1:23 PM, Aaron Falk wrote: > > Just recapping the discussion in Bangkok, I think we agreed the to the > following plan: > > March 2019: complete a WG review for draft-i

[Taps] Request for TAPS Architecture Document Review

Hello TAPS, In Bangkok, we decided that we want to wrap up the TAPS architecture document by March, and that we'd do a set of revisions and reviews prior to our January interim. I've gone through and incorporated reviews and issues from Gorry, Mirja, and Michael. Thanks! I'd like to request th

Re: [Taps] call for agenda items at TAPS IETF-104

One topic that I’d like to discuss on the core documents, that’s been raised previously as a vague area, is how to actually implement framing protocols. The API document references framing and deframing, but we need more specificity into how that is implemented. This is an area that I've been wo

Re: [Taps] API drafts repository has been migrated

Fantastic, thanks for getting this done! Now, to make some PRs before the Prague submission deadlines =) Best, Tommy > On Mar 5, 2019, at 2:06 PM, Brian Trammell (IETF) wrote: > > Greetings, all, > > > The API drafts repository is now at: > > https://github.com/ietf-tapswg/api-drafts > > T

Re: [Taps] call for agenda items at TAPS IETF-104

Hi Jake, Sorry I hadn't replied! Apparently my Mail decided to sort your emails into junk, so I only just saw Michael's response now to alert me to this thread. Regarding the YANG format, I think that's a really interesting idea and I would definitely like to see a presentation in Prague regard

[Taps] Please review: open PRs for TAPS documents

Hello TAPS, We'll be revving the Architecture/Interface/Implementation documents soon, and we have a few outstanding PRs: https://github.com/ietf-tapswg/api-drafts/pulls I wanted to solicit input and feedback from the group as we go to merge these in by Monday. Many of these are new, and based

Re: [Taps] Updated draft-jholland-taps-api-yang

Hi Jake, Thanks for updating the document! It's really useful to see things written out this way. Comments inline, responding to your "oddities". > On Mar 9, 2019, at 10:09 PM, Holland, Jake wrote: > > Hi taps, > > Thanks for the feedback to all who commented, and since it > seems maybe there

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

Thanks, Aaron! I've just done an editorial pass on the document now that we believe it is technically complete. Some of the nits addressed: - Remove redundancy between intro and abstract - Update language on Security Features to have a consistent tense/voice between definitions of features - R

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

On Apr 10, 2019, at 5:10 AM, IESG Secretary wrote: > > The Transport Services (taps) Working Group will hold > a virtual interim meeting on 2019-05-08 from 11:00 to 13:00 America/New_York. > > Agenda: > Topics: > * Framing I've created a Pull Request to add framing to the Interface document.

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

> On May 7, 2019, at 11:52 AM, Aaron Falk wrote: > > Collating the input from the thread. Who will lead the discussion on the > implementation draft? > > I suppose it would make sense for Anna and I to lead the implementation discussion, as editors. However, we'd appreciate people's input a

[Taps] Framing Protocol APIs in iOS and macOS

Hello TAPS, I wanted to share some new API that we've just released in beta as part of Network.framework that's based on the framer work for the TAPS API! You can now create framing protocols that you insert into your connections and listeners to parse messages over streams; if anyone wants to

Re: [Taps] call for TAPS agenda items

> On Jun 30, 2019, at 2:34 PM, Aaron Falk wrote: > > What shall we use our face-time for in Montreal? > > Some topics from our last interim > > seem like good candidates for updates. Can we refine them with specifi

[Taps] On Profiles for TAPS Preconnections

An issue we discussed today in the TAPS meeting was whether or not we should add a concept of "profiles" to the Transport Services APIs. An example of a profile is a "reliable, secure, in-order stream"; or "unreliable datagrams". Another way to think of these profiles are as convenient ways to i

Re: [Taps] On Profiles for TAPS Preconnections

> 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 discussed today in the TAPS meeting was whether or not we should >> add a concept of "profiles&q

Re: [Taps] On Profiles for TAPS Preconnections

are already convenience features in other places of > the API which should be removed if we agree on keeping the complexity to the > bare minimum for the core interface. > > Best regards, > Max > > Am 22.07.2019 19:15 schrieb Tommy Pauly : > > > On Jul 22, 2019, at 6

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

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 combinations are allowed based on preference—if you

Re: [Taps] On Profiles for TAPS Preconnections

, at 10:35 AM, Philipp S. Tiesel wrote: > > > >> On 23. Jul 2019, at 09:40, Tommy Pauly > <mailto:tpa...@apple.com>> wrote: >> >> Yes, I would be happier with suggesting something like >> TransportProperties.WithProfile(profile), rather than replacing th

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

> On Jul 23, 2019, at 11:19 AM, Theresa Enghardt > wrote: > > Hi, > >> On 23/07/2019, 10:31, Tommy Pauly wrote: >>> […] if you don't require reliability, then a UDP protocol stack is >>> equivalent to a message protocol over TCP. If you d

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

Hi Joe, Yes, I completely agree. The current text in -arch expresses this as: 2. Both stacks MUST offer the same transport services, as required by the application. For example, if an application specifies that it requires reliable transmission of data, then a Protocol S

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

rrectly, this boils down to the fact that if two > protocols are in the candidate set for racing they are also equivalent? Thus > we dont have to worry about unequivalent protocols as they are never part of > the same candidate set anyway? > > Best > Max > > > > A

Re: [Taps] I-D Action: draft-ietf-taps-transport-security-07.txt

sport Security Protocols >Authors : Christopher A. Wood > Theresa Enghardt > Tommy Pauly > Colin Perkins > Kyle Rose > Filename: draft-ietf-taps-transport-se

Re: [Taps] TAPS (secure) connection maangement Q

Hi Toerless, Thanks for the questions! Definitely an interesting topic. I think what you're trying to get at, checking the client's authentication properties on the server, is described here: https://tools.ietf.org/html/draft-ietf-taps-interface-04#section-5.3.2. o Trust verification callb

Re: [Taps] TAPS Sept 2019 Interim Agenda?

> On Sep 17, 2019, at 8:13 AM, Aaron Falk wrote: > > Michael- > > You make a good observation. It looks like activity has slowed on GitHub. > Indeed, it's been a bit slow. I intend to make PRs for a number of the issues I have currently assigned; particularly, the goal is to do some more work

Re: [Taps] call for TAPS agenda topics

Right, I'd ask that we spend a good chunk of time discussing the security document. Since we have 90 minutes, perhaps allocate 20-30 minutes for that? I've just posted the -05 versions of the three main documents. I'd suggest that we spend a good chunk of time going through the issues list, and

Re: [Taps] call for TAPS agenda topics

I can lead the discussion around implementation issues, as Anna will be remote. Best, Tommy > On Nov 6, 2019, at 2:54 PM, Aaron Falk wrote: > > Thanks, Brian. > > We need discussion leads for -architecture, -implementation, and -security. > > --aaron > > On 5 Nov 2019, at 0:58, Brian Trammel

Re: [Taps] WebTransport and taps

> On Nov 14, 2019, at 10:18 AM, Mirja Kuehlewind wrote: > > Hi taps folks (also cc’ing the WebTransport list), > > I assume that people on the taps list are aware of the WebTransport effort > that will have a BoF meeting on 13:30-15:00 Wednesday. I had another look at > the WebTransport docu

Re: [Taps] I-D Action: draft-ietf-taps-transport-security-10.txt

t is a work item of the Transport Services WG of the IETF. > >Title : A Survey of the Interaction Between Security > Protocols and Transport Services >Authors : Theresa Enghardt > Tommy Pauly > Colin Per

Re: [Taps] finishing things

> On Nov 19, 2019, at 6:09 PM, tom petch wrote: > > - Original Message - > From: "Aaron Falk" mailto:aaron.f...@gmail.com>> > Sent: Monday, November 18, 2019 2:28 AM > >> On 17 Nov 2019, at 22:48, tom petch wrote: >> >>> I am not sure which three you have in mind but suspect that it d

Re: [Taps] Interim call this Friday

> On Dec 17, 2019, at 6:58 AM, Aaron Falk wrote: > >  > We’re having a call on Friday (11am US ET). The goals of the call are to > resolve any open issues that would prevent -arch from going to last call. We > can also use the time to resolve any open issues on -security. > > Can the author

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

Hi Gorry, Thanks for the comments! I've created a pull request here: https://github.com/ietf-tapswg/api-drafts/pull/411 I am including comments inline to respond to the individual points. Best, Tommy > On Jan 11, 2020, at 3:18 AM, Gorry Fairhurst wrote: > > I have some minor editorial commen

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

Thanks for your review Theresa! We’ll incorporate your GitHub comments soon. As editor, I think this document should be ready to publish with these minor changes added in. Thanks, Tommy > On Jan 20, 2020, at 4:28 AM, Theresa Enghardt wrote: > >  > Hi all, > > I reviewed the document again

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

> On Apr 9, 2020, at 7:58 AM, Magnus Westerlund > wrote: > > Hi, > > Eric and I have discussed this and the proposal is a clarifying change to the > initial statement in Section 3: > > OLD: > >This section contains brief descriptions of the various security >protocols currently

Re: [Taps] TAPS April Interim Scheduling

Hi Aaron, I’d like to add one topic to the agenda (which seems pretty open at this point, mainly being issue review), specifically on handling Multicast and Multiplexing with Connection Groups. We’ve recognized that our text in the TAPS specs around multicast has been lacking for a while, and

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

Thanks for these details, Gorry! I finally got around to making this PR. Please take a look, and we’ll discuss tomorrow: https://github.com/ietf-tapswg/api-drafts/pull/564 Best, Tommy > On Mar 25, 2020, at 9:02 AM, Gorry Fairhurst wrote: >

Re: [Taps] Murray Kucherawy's Yes on draft-ietf-taps-transport-security-11: (with COMMENT)

Hi Murray, Thanks for the review! You can find an updated version of the document, that incorporates the nits you point out, here: https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html

Re: [Taps] [Last-Call] [Iot-directorate] Iotdir telechat review of draft-ietf-taps-transport-security-11

Hi Mohit, Thanks for the review! You can find an updated version of the document here: https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html

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

Hi Brian, Thanks for the review! You can find an updated version of the document here: https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html

Re: [Taps] Robert Wilton's Yes on draft-ietf-taps-transport-security-11: (with COMMENT)

Hi Robert, Thanks for the review, and I’m glad this was a useful reference for you. You can find an updated version of the document here: https://ietf-tapswg.github.io/draft-ietf-taps-transport-security/draft-ietf-taps-transport-security.html

  1   2   >