From nobody Fri Apr 6 11:54:39 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0532F126BF6 for ; Fri, 6 Apr 2018 11:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL1ojIjHUlcz for ; Fri, 6 Apr 2018 11:54:32 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385E8124D68 for ; Fri, 6 Apr 2018 11:54:32 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id p15so1376172pff.11 for ; Fri, 06 Apr 2018 11:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=sc8ToyG1JNBs5V7ESSQgtb2CWQ/XqeDLrw4wLc8ffTc=; b=ItBIGJXAeBFhDKcZJM4qmNaSiSgJ3QLKuVZ39ffdml5ZvXYQ0PN2HlDjBy85+68zVQ dFH/BhJ9YGmXG6pc1HDj2jDEIu9sgI6k1mWS4TLKEFf7Rz2tGdbywDQv5IAinXtDR3Xx ZOIqNSGMUXHkExBVJr0sPVKUnEY1X46v7AMrpFuOJxsGSC/yBKobkvhri3+j79c5a21P ayYnPojguL3d1uI5y0rcy1wac+veUQZp2lKIMw+oZfLU/aqY7mz/yFlEqSIWOe3L8rR5 XCJzTocnUHjarIEft2pYbi+wbzMpXIR+7CCSlj3C27LRB8URRy6eBQzsrVFLsHvcAIuK Uxfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=sc8ToyG1JNBs5V7ESSQgtb2CWQ/XqeDLrw4wLc8ffTc=; b=V0L3dIFPmxzdRokQQLU0d6R86oIr0UbZLbg72A7dYhYJtET4yO10Mx4TjGo5c7sVGf YpENZeAHDy9eNFQmWa+NhrxIEUWTs7RklPQAucY/2fClTZVB/FYsZw80spBWx4JWqpu5 l1FK5JZ3IE/xr6zwijKH1ryGWZoaFOUD3GQUFOsFV1nfFkKYQmV5nj/cK4eDkETxkTJu xow19nctAlsD3sUmlf/Ya+jy/LmQLIrklDQ95oLt7ZjZKFDvDbXf7C9v5nxLyvL7VhZk GXfRmQz3/mrOjYRk/YHJJeKfnPjct5s5ybWoCvtA5W3BYdXvBDZMbq/kGJppxrYI/Lmc 6uLw== X-Gm-Message-State: AElRT7GN1YStn12ylfZ1cI3ikgwolk+Ct4t1UxMacTxe1Qerh7YNTGDQ eXuKi4b10VL0cqCssg7695kPDGLA X-Google-Smtp-Source: AIpwx4/BAaU4cfYTCTZR/OvNmXbV/G+cBJPxxaIZllyqF3gaKWxZC0HfolbOkDYAiDnt3CHfAjeMMA== X-Received: by 10.99.163.9 with SMTP id s9mr18504574pge.187.1523040871065; Fri, 06 Apr 2018 11:54:31 -0700 (PDT) Received: from [172.19.37.209] (g2001-4878-a000-3000-81cd-0f0f-c521-4b4e.deploy.static.akamaitechnologies.com. [2001:4878:a000:3000:81cd:f0f:c521:4b4e]) by smtp.gmail.com with ESMTPSA id e82sm20909221pfh.115.2018.04.06.11.54.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Apr 2018 11:54:29 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Fri, 06 Apr 2018 14:54:27 -0400 X-Mailer: MailMate (1.11r5467) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_25477745-ED22-4B8A-9C0B-73E1ED7B213B_=" Archived-At: Subject: [Taps] draft notes from TAPS at IETF-101 in London X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2018 18:54:38 -0000 --=_MailMate_25477745-ED22-4B8A-9C0B-73E1ED7B213B_= Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Here are the notes from the meeting. Please send corrections or just = fix the = [Etherpad](http://etherpad.tools.ietf.org:9000/p/notes-ietf-101-taps?useM= onospaceFont=3Dtrue). --aaron ----- Transport Services (TAPS) working group - IETF101 Chairs: Aaron Falk, Zaheduzzaman Sarker Note taker : Tom Jones Aaron Administrivia - Blue sheets / scribe selection / NOTE WELL - 2 min - Agenda bashing - 3 min Agenda 1. Chairs update - 10 min Michael W: There was security stuff in minset that I took out. 2. A Survey of Transport Security Protocols, = draft-pauly-taps-transport-security-01, Christopher Wood, Apple. - 25 = min discussion point: - updates since last version and review remaining = issues - revisit goals as they pertain to new TAPS charter = text - possible adoption as a WG item Kyle Rose: In the proceess of working on this document there is = something that is making me uneasy and I was speaking about it to aaron. = It is about scope and scope creep, are we going to cover every security = protocol? So, I am wondering if a better approach might be to choose = enough protocols to analyse to cover the set of features that each of = these protocols might have and then derive a set of shim features that = are an interface to TAPS itself. If we try to go for everything we are = not going to get this done Chris Wood: I think looking at the implementations we will confirm or = deny if we got the selections correct. If there are things that we do = that are not in the standard that everyone does. I think that there are = out standing issuses on the github tracker to add these new protocols. = We could say for now to stick to the ones we have and maybe increase the = scope a little bit. we need to be sensitive to time. Kyle: We can go as far up in the stack as we want. There is envoy that = uses these protocols in a sense. You want to choose a set of protocols = from which you can distill out the fetures that a TAPS layer will need = and which protocols that you need to support. TLS and DTLS are the same = protocol at the record layer, but they differ. Chris: In theory I agree Brain Trammel: In favour of adoption. The question about scope, I think = we can go relatively quickly though the list of open issues and agree if = we are going to get something into the set of charactaristics. RFC8095 = has a glaring issue and doesn't talk about gQUIC, but QUIC doesn't add = any features. Two questions: one: post quamtum crypto...? I don't think that will change = anything Aaron: is it deployed on the internet brain: second: there is a split between handshake layer record layer, = this is very TLS chris: in the crypto set document we reprhased everything. brian: it seems a very natural way to seperate. aaron: great document. not sure if I am wearing my chair hat. To the = question of which protocols to include, we need input from the security = area. They might have priorities that we do't appreciate. The other = thing is, will all these security protocols be considered behind the = TAPS API? That's the way it looks from the diagram. chris: in practice we would go up to the TLS layer, higher is open to = debate. aaron: the goal is to allow applications on top of this thing. apps = people might not have as clean as a seperation. chris: this is another area of the scope that is fuzzy Tommy Pauly: what protocols are in scope, we should limit to the types = of things we have. they are providing a pseudo transport layere. aaron: could you come up with a test to see if a protocol is in the set? tommy: Yes. we are considering security protocols that behave like = transports kyle: we don't need to be exhaustive zahed: the scope of the doc is explicitly not limited to IETF protocols tommy: quic had an interesting discussion regarding the realtionship of = TLS and the layering of the QUIC protocol. We have an analysis of the = current IETF QUIC. If QUIC is in flux I am now sure how our doc can = track it. aaron: This isn't a critical problem. We can complete doc and let it = rest while QUIC matures. Then, we can revise our doc later to be = consistent. chris: the stream 0 problem they hope to have resolved by the next ietf, = hopefully they will align mirjia: quic, crpyto for quic is still tls. the handshake is the same = the record layer si not the same. chris: we need to review that text 3. A Minimal Set of Transport Services for TAPS Systems, = draft-ietf-taps-minset-02 - Michael Welzl, University of Oslo. -10 min discussion point: - updates from previous version aaron: is there anything in the document that lead to a seperate = discussion about security protocols mw: there is text that references the security document. aaron: do we think a minimun taps implementation must support some = security protocols. this document is one place, the security document is = another briain: I think, we do need to say it is an implementation requirement. = given the pattern of the rest of the documents we are putting security = on the side. draft-wood seems to be 80-95 minset+security. minset should = have a reference to the security document. mw: which it does aaron: In minset, we should say the minimum security requirements for a = TAPS system are captured in the security document kyle rose: a system using taps should have a minimum layer of security = built into it. are we going to say transport protocols shouldhave a way = to do security to be a taps transport mw: there is away to derrive the minimum set, security stuff is the = other document. phillip; for the usage document we have a seperation between minset and = usage for non security feattures, do we need the same for security = features? aaron: that one document will cover both tommy pauly: the security set is much smaller than the transport = features. if transport had come together more neatly we wouldn't have = need the documents. mirija: what is he plan for the decision tree mw: it stays as an example brain: previous conversation to reiterate, the three stage documents is = because we didn't know the process before we started. we know how to do = the process now. the security document can be faster. aaron: sounds like we agree. sounds like we are done aaron: shall we last call? hum: strong consensus in favor of moving draft-ietf-taps-minset to WGLC = (none opposed) mirija: shall we hum for the security document tommmy: we couldn't before the recharter. shall we hum for adoption? hum: strong consensus in favor of WG adoption of = draft-pauly-taps-transport-security (none opposed) 4. An Architecture for Transport Services, draft-pauly-taps-arch-00, = Tommy Pauly, Apple. -20 min (excluding discussion) discusion point: - Design principles - Terminology and concept definitions - Applicability for charter milestones 3 5. An Abstract Application Layer Interface to Transport Services, = draft-trammell-taps-interface-00, Brian Trammell, ETH Zurich. -20 min = (excluding discussion) discussion point: - the unified view (post sockets, NEAT, socket intents) - concepts of an interface at the level of a = language-independent, abstract asynchronous interface definition. - relation towards taps proposed architecture (see = agenda item 4) Jonathan: are you assuming dns is async? brian: yes mirja: I am wondering why the properties are in the api document brian: these are the things an application devleoper will have control = over it depends on what the application implements. mirja: are we assuming these are the mandatory ones brian: not yet, these are common, but not mandatory tommy: the implementation draft is focues on things that are hidden from = the application, these are knobs to turn, but option to use. kyle: a set of suggestions of things you could implement mw: we should clarify these are optional for an app to use, but not = optional to implement brian: we don't have normative language yes. today we are asking if this = is the correct approach. we need to back it up in the impl document jonathan: it is not tcp acks? kyle: it is not delivered brian: if we have a protocol for this we might want to include it. 6. Implementing Interfaces to Transport Services, = draft-brunstrom-taps-impl-00, Anna Brunstrom, Karlstad University. - 15 = min (excluding discussion) discussion point: - implementation aspects - relation to taps application layer interfaces Lorenzo: does the candidate gathering occur in two different time = phases? tommy: there are interleaved anna: conceptually there are different issues, they happen in parrell colin perkins: one of the open issus we have on this draft is resolving = all the issues, nat traversal, happy eyeballs, ice... colin perkins: to clarify, for udp one of the open issues is to = integreate with things like stun. we are aware there are details missing = at this point jonathon: you are forbidding half close anna: there is no functionality in the api tommy: a close is interpretted as a termination. we are still discussing = a half close. it is sending parameter, not a termination parameter 7. Combined discussion slot for agenda item 4,5 and 6. -30 min discussion point: - see agenda item 4,5 and 6. aaron: the most important thing I want out of this discussion is whether = or not to adopt them: hum: in favour: strong hum oppoosed: silence need more information: silence = aaron: OK, let's have a technical discussion... kyle rose: the section in rendevous, there is an intent for rendevous to = be very general. we are going to want that, it is not just dns but = sevice discovery by a database brain: we know that and we need help michael tuexen: two commmenso n send. you had ttl on partial = reliablilty. you had ataomic send. I agree there is a need to provide = the send call where a message begins and where a message stops. it could = be limiting to do atomic sends which limti the size of the message to = the size your stack can handle. brian: there is a notion of partial send and partial recv. if the lower = layer cannot find end of frame before end of buf you will get a partial = recv mt: I will provide when it is finished brain: a stream looks like one long message tommy: it os the smae for the send. feedback on naming would be good. = for a while we had content as the piece of data that you can send, = related to the larger overall message. we have changed the wording tobe = more message centered. there are properties of that message seperate to = the sending data. colin: rendevous, the inital goal is tosupport he and ice. once we have = that we generalise it to anything else. it is fairly clear there are a = bunch of terminology issues. suggestions welcome. tommy: on rendevous if when looking at use cases if you see things that = are limited by the current architecture please bring these up. colin: we are aware we need app level help with these. zahed: without chair hat. Policy, arch draft saysa there is a system = plicy, but there is nothing in api, impl says we have multiple policy. = Rename system, or api to include more on how to install polices. anna: there is some inconsistency in the naming tommy: api draft is about the interface provided to the application = developer. there is missing language about the api for a sysadmin, this = is an oversight. app isn't going tobe setting system policy. we should = add something about an administravie interface anna: there are different timescales on these things. zahed: you have priorities between different policies tommy: the architecture puts these in implementation concepts. the = classic example is on a phone blocking using cellular data. the part of = policy to interact is path selection properties. zahed: applicaitions need to say something about the policy that the = system should listen to. I am asking for clarification when you have = multiple policies active. anna: at the moment we only have the constraints you have to follow. in = practice it is more complicated and you have trade offs. some is imple = dependant jonaton: first it is better to say these are read only to the = application not invisilble brian and tommy: yep jonathon: the one event I didn't see is tcp low water. is it okay for me = to send tommy: this was brought upin the discussion. we are trying to avaoid = this, it is a propety of how you interact with the socket jonathon: not that specifically tommy: this is the point of the callback. we have this in public apis = already, don't enquque before you get teh call back jonathon: it would make you more confident if you were eating your own = dog food. could you implement quic on top of this or ice or rmcat briain: we have a plan for research on this in go, quic and tcp in this = api tommy: at apple we are using this internally and for our own prototpyes = for quic interop praveen: in terms of service, apps wanting lower latency higherthoruhg = put. in terms of those is there anything in this api. socket api cannot = provide intent phillipp: laughs theresa: right now we have the capacity profile, low latency or high = bandwidth. we have intents 'this is a big transfer' the app wants to be = as precise as possible. we need to figure out which properties to = include brian: all that right now is an appendix on the interface doc. = everything we didn't have concensus on what went into the appendix tommy: these are elements we have finalised the semantics for. look at = the appendix, open an issue on the ones you think are important. praveen: real value, that is what is missing. the abstraciton is great. = some sort of consistency guarentee would be useful tommy: for deployment it is important that the preferences can take this = into account. praveen: my question is different. if you did racing and end up with x = the app would prefer to keep picking that brian: there is chunnk of the arch we didn't talk about. the security = state cache and transport state cache. any implementation will have to = learn about paths. we can reccomend parameters. you need this cache to = make it work. tommy: in he we already do this, we are stick to addresses we have done gorry: on policy, there are multiple viewson what we have as inputs. = some are predictable and some are optimisation and tuning. I am also = concerned if we do everything we end up with a gaint spec. tim chown: the sysconfig you pull these from is a bottomeless pit. pvd = in intsrea is something interesting to me. brian: it sounds to me like there is a collection of things people = wouldlike to see. maybe a fourth doc. there is ahole we need to consider aaron: yes, we can't write it yet aaron: do you have a thought on cohabitation with applications that have = needs for more granularity from the api anna: part of that is protocol specific properties. aaron: does taps have to implement that. brian: no that won't work. this is tided to an issue we just noticed in = london. the interface document is the low performance version of the = document. We probably need to get out of the way for batch and memory = mapped io. we need holes in the api aaron: we have focus on simple should be easy, can complex things bipass = taps? tommy: my gut is that it should all go through taps. we cannot be worse = than existing standards. if all you do is allow someone to setseockopt = you expose that there is a socket there, which exposes things that might = not be true. have a mapping to important sockopts and have a mapping aaron: doc should say this thersa: about properties, we have a zoo. required, preffered, can be = quieried. I propose we make one section in api where we sort this out. phillipp: the taps system should have some auto mode where an app = specifies in an easy way "i am doing stuff, give me appropriate = transport" on the other hand allow the app to ask for precise transport = protocols with set properties. An app can mix and match with these = modes. How exactly to specify what I am going to do. tommy: I agree. It is really not diverging from what socket applicatons = do today. colin: this api is being built on our best guess of what it should look = liike and our protocol experience. It would be good to get WG input on = protocols that do not fit with this api. aaron: multicast colin: yes multicast, and maybe icn. If there are styles we should have = the discussion. aaron: taking the documents as working group items should not fix the = set of documents we work on aaron: I am going to assume WG adoption, we will confirm on the list brian: the authors put together a github org. do we want to bring that = under WG control. 8. Problem Statement Regarding IPv6 Address Usage, = draft-gont-taps-address-usage-problem-statement-00, Fernando Gont, SI6 = Networks. - 10 min discussion point: - whether the topic is of interest for this working = group - possibly adopting the I-D as working group document gorry: I see two things in the document. Something about use of ipv6 = addresses and policy and I see the need for a new api if we need to = react. I am interested in how 6man felt about privacy and use of = addresses. Maybe it shouldbe two documents. What happened in 6man? fernando: I presented twice, reponse was in belonged elsewhere. myself, = the properties might fall into 6man or int area. the api is something is = more clearly in taps ole: in 6 man we defined these mechanisms for generating addresses with = these properties. we have specifed one document on source address = selection with policy tables and ways for applications to make = preferences for which type of address. we are very much bottoms up we = made it available without an idea how it should be used. which is why we = wanted to drop it to the people that can make use of this. tommy: there are two seperate concerns. tha aspect of privacy and = security, when to use one over the other belongs in another document = which isn't in taps, maybe int area. however the mechanism for selecting = these is a taps arch selection property. as a server what source address = do I want to bias towards. this is all very relevant, the right place to = specify would be in the interface. rather than adopt, what if we add = this to the taps api? ferndando: for me that is fine. I agree there are two parts. the anaylse = of the properties is neccessary to do the other part. what I wonder is = where do you keep the analyse, the api could belong in a different = document. some place or another you need a disucssion on mapping = addresses. tommy: it would be useful to reference that document. also what should = the taps system do for default, listener vs outbound.where? aaron: I don't think it is us theresa: I see potential input to the impl draft. I see relationship to = the security params in the api draft gorry: is it possile to revise the draft to make it clearer between the = api and the problem space. this would really help me figure out who = should look at this. an api section should be in taps, the other section = needs someone looking at it. fernadon: forthe api we have a problme statement, but no api gorry: talk about the api implications in a seperate bit to where you = talk about implications tim chown: I thin the bulk ofits should happen here. 6774 says this = should happen for out bound, pvd may change this. --=_MailMate_25477745-ED22-4B8A-9C0B-73E1ED7B213B_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Here are the notes from the meeting. Please send correct= ions or just fix the Etherpa= d.

--aaron

Transport Services (TAPS) working group - IETF101

Chairs: Aaron Falk, Zaheduzzaman Sarker

Note taker : Tom Jones
Aaron

Administrivia

  • Blue sheets / scribe selection / NOTE WELL - 2 min
  • Agenda bashing - 3 min

Agenda

  1. Chairs update - 10 min

Michael W: There was security stuff in minset that I took= out.

  1. A Survey of Transport Security Protocols, draft-pauly-tap= s-transport-security-01, Christopher Wood, Apple. - 25 min discussion point: - updates since last version and review remaining issues - revisit goals as they pertain to new TAPS charter text - possible adoption as a WG item

Kyle Rose: In the proceess of working on this document th= ere is something that is making me uneasy and I was speaking about it to = aaron. It is about scope and scope creep, are we going to cover every sec= urity protocol? So, I am wondering if a better approach might be to choos= e enough protocols to analyse to cover the set of features that each of t= hese protocols might have and then derive a set of shim features that are= an interface to TAPS itself. If we try to go for everything we are not g= oing to get this done
Chris Wood: I think looking at the implementations we will confirm or den= y if we got the selections correct. If there are things that we do that a= re not in the standard that everyone does. I think that there are out sta= nding issuses on the github tracker to add these new protocols. We could = say for now to stick to the ones we have and maybe increase the scope a l= ittle bit. we need to be sensitive to time.

Kyle: We can go as far up in the stack as we want. There = is envoy that uses these protocols in a sense. You want to choose a set o= f protocols from which you can distill out the fetures that a TAPS layer = will need and which protocols that you need to support. TLS and DTLS are = the same protocol at the record layer, but they differ.
Chris: In theory I agree
Brain Trammel: In favour of adoption. The question about scope, I think w= e can go relatively quickly though the list of open issues and agree if w= e are going to get something into the set of charactaristics. RFC8095 has= a glaring issue and doesn't talk about gQUIC, but QUIC doesn't add any f= eatures. Two questions:
one: post quamtum crypto...? I don't think that will change anything<= br> Aaron: is it deployed on the internet
brain: second: there is a split between handshake layer record layer, thi= s is very TLS
chris: in the crypto set document we reprhased everything.
brian: it seems a very natural way to seperate.
aaron: great document. not sure if I am wearing my chair hat. To the ques= tion of which protocols to include, we need input from the security area.= They might have priorities that we do't appreciate. The other thing is, = will all these security protocols be considered behind the TAPS API? That= 's the way it looks from the diagram.
chris: in practice we would go up to the TLS layer, higher is open to= debate.
aaron: the goal is to allow applications on top of this thing. apps peopl= e might not have as clean as a seperation.
chris: this is another area of the scope that is fuzzy
Tommy Pauly: what protocols are in scope, we should limit to the type= s of things we have. they are providing a pseudo transport layere.
aaron: could you come up with a test to see if a protocol is in the set? =
tommy: Yes. we are considering security protocols that behave like tr= ansports
kyle: we don't need to be exhaustive
zahed: the scope of the doc is explicitly not limited to IETF protocols tommy: quic had an interesting discussion regarding the realtionship of T= LS and the layering of the QUIC protocol. We have an analysis of the curr= ent IETF QUIC. If QUIC is in flux I am now sure how our doc can track it.=
aaron: This isn't a critical problem. We can complete doc and let it res= t while QUIC matures. Then, we can revise our doc later to be consistent.=
chris: the stream 0 problem they hope to have resolved by the next ietf, = hopefully they will align
mirjia: quic, crpyto for quic is still tls. the handshake is the same the= record layer si not the same.
chris: we need to review that text

  1. A Minimal Set of Transport Services for TAPS Systems, dra= ft-ietf-taps-minset-02 - Michael Welzl, University of Oslo. -10 min discussion point: - updates from previous version

aaron: is there anything in the document that lead to a s= eperate discussion about security protocols
mw: there is text that references the security document.
aaron: do we think a minimun taps implementation must support some securi= ty protocols. this document is one place, the security document is anothe= r
briain: I think, we do need to say it is an implementation requirement. g= iven the pattern of the rest of the documents we are putting security on = the side. draft-wood seems to be 80-95 minset+security. minset should hav= e a reference to the security document.
mw: which it does
aaron: In minset, we should say the minimum security requirements for a T= APS system are captured in the security document
kyle rose: a system using taps should have a minimum layer of security bu= ilt into it. are we going to say transport protocols shouldhave a way to = do security to be a taps transport
mw: there is away to derrive the minimum set, security stuff is the other= document.
phillip; for the usage document we have a seperation between minset and u= sage for non security feattures, do we need the same for security feature= s?
aaron: that one document will cover both
tommy pauly: the security set is much smaller than the transport features= =2E if transport had come together more neatly we wouldn't have need the = documents.
mirija: what is he plan for the decision tree
mw: it stays as an example
brain: previous conversation to reiterate, the three stage documents is b= ecause we didn't know the process before we started. we know how to do th= e process now. the security document can be faster.
aaron: sounds like we agree. sounds like we are done
aaron: shall we last call?

hum: =

strong consensus in favor of moving draft-ietf-taps-minset to WGLC (none =
opposed)

mirija: shall we hum for the security document
tommmy: we couldn't before the recharter. shall we hum for adoption?

hum: =

strong consensus in favor of  WG adoption of draft-pauly-taps-transport-s=
ecurity =

(none opposed)

  1. An Architecture for Transport Services, d= raft-pauly-taps-arch-00, Tommy Pauly, Apple. -20 min (excluding discussio= n)
    discusion point:
    - Design principles
    - Terminology and concept definitions
    - Applicability for charter milestones 3

  2. An Abstract Application Layer Interface t= o Transport Services, draft-trammell-taps-interface-00, Brian Trammell, E= TH Zurich. -20 min (excluding discussion)
    discussion point:
    - the unified view (post sockets, NEAT, socket intents)
    - concepts of an interface at the level of a language-indepen= dent, abstract asynchronous interface definition.
    - relation towards taps proposed architecture (see agenda ite= m 4)

Jonathan: are you assuming dns is async?
brian: yes
mirja: I am wondering why the properties are in the api document
brian: these are the things an application devleoper will have control ov= er it depends on what the application implements.
mirja: are we assuming these are the mandatory ones
brian: not yet, these are common, but not mandatory
tommy: the implementation draft is focues on things that are hidden from = the application, these are knobs to turn, but option to use.
kyle: a set of suggestions of things you could implement
mw: we should clarify these are optional for an app to use, but not optio= nal to implement
brian: we don't have normative language yes. today we are asking if this = is the correct approach. we need to back it up in the impl document

jonathan: it is not tcp acks?
kyle: it is not delivered
brian: if we have a protocol for this we might want to include it.

  1. Implementing Interfaces to Transport Services, draft-brun= strom-taps-impl-00, Anna Brunstrom, Karlstad University. - 15 min (exclud= ing discussion) discussion point: - implementation aspects - relation to taps application layer interfaces

Lorenzo: does the candidate gathering occur in two differ= ent time phases?
tommy: there are interleaved
anna: conceptually there are different issues, they happen in parrell
= colin perkins: one of the open issus we have on this draft is resolving a= ll the issues, nat traversal, happy eyeballs, ice...

colin perkins: to clarify, for udp one of the open issues= is to integreate with things like stun. we are aware there are details m= issing at this point

jonathon: you are forbidding half close
anna: there is no functionality in the api
tommy: a close is interpretted as a termination. we are still discussing = a half close. it is sending parameter, not a termination parameter

  1. Combined discussion slot for agenda item 4,5 and 6. -30 m= in discussion point: - see agenda item 4,5 and 6.

aaron: the most important thing I want out of this discus= sion is whether or not to adopt them:

hum: =

    in favour: strong hum
      oppoosed: silence
      need more information: silence

aaron: OK, let's have a technical discussion...

kyle rose: the section in rendevous, there is an intent f= or rendevous to be very general. we are going to want that, it is not jus= t dns but sevice discovery by a database
brain: we know that and we need help
michael tuexen: two commmenso n send. you had ttl on partial reliablilty.= you had ataomic send. I agree there is a need to provide the send call w= here a message begins and where a message stops. it could be limiting to = do atomic sends which limti the size of the message to the size your stac= k can handle.
brian: there is a notion of partial send and partial recv. if the lower l= ayer cannot find end of frame before end of buf you will get a partial re= cv
mt: I will provide when it is finished
brain: a stream looks like one long message
tommy: it os the smae for the send. feedback on naming would be good. for= a while we had content as the piece of data that you can send, related t= o the larger overall message. we have changed the wording tobe more messa= ge centered. there are properties of that message seperate to the sending= data.
colin: rendevous, the inital goal is tosupport he and ice. once we have t= hat we generalise it to anything else. it is fairly clear there are a bun= ch of terminology issues. suggestions welcome.
tommy: on rendevous if when looking at use cases if you see things that a= re limited by the current architecture please bring these up.
colin: we are aware we need app level help with these.
zahed: without chair hat. Policy, arch draft saysa there is a system plic= y, but there is nothing in api, impl says we have multiple policy. Rename= system, or api to include more on how to install polices.
anna: there is some inconsistency in the naming
tommy: api draft is about the interface provided to the application devel= oper. there is missing language about the api for a sysadmin, this is an = oversight. app isn't going tobe setting system policy. we should add some= thing about an administravie interface
anna: there are different timescales on these things.
zahed: you have priorities between different policies
tommy: the architecture puts these in implementation concepts. the classi= c example is on a phone blocking using cellular data. the part of policy = to interact is path selection properties.
zahed: applicaitions need to say something about the policy that the syst= em should listen to. I am asking for clarification when you have multiple= policies active.
anna: at the moment we only have the constraints you have to follow. in p= ractice it is more complicated and you have trade offs. some is imple dep= endant
jonaton: first it is better to say these are read only to the application= not invisilble
brian and tommy: yep
jonathon: the one event I didn't see is tcp low water. is it okay for me = to send
tommy: this was brought upin the discussion. we are trying to avaoid this= , it is a propety of how you interact with the socket
jonathon: not that specifically
tommy: this is the point of the callback. we have this in public apis alr= eady, don't enquque before you get teh call back
jonathon: it would make you more confident if you were eating your own do= g food. could you implement quic on top of this or ice or rmcat
briain: we have a plan for research on this in go, quic and tcp in this a= pi
tommy: at apple we are using this internally and for our own prototpyes f= or quic interop
praveen: in terms of service, apps wanting lower latency higherthoruhg pu= t. in terms of those is there anything in this api. socket api cannot pro= vide intent
phillipp: laughs
theresa: right now we have the capacity profile, low latency or high band= width. we have intents 'this is a big transfer' the app wants to be as pr= ecise as possible. we need to figure out which properties to include
brian: all that right now is an appendix on the interface doc. everything= we didn't have concensus on what went into the appendix
tommy: these are elements we have finalised the semantics for. look at th= e appendix, open an issue on the ones you think are important.
praveen: real value, that is what is missing. the abstraciton is great. s= ome sort of consistency guarentee would be useful
tommy: for deployment it is important that the preferences can take this = into account.
praveen: my question is different. if you did racing and end up with x th= e app would prefer to keep picking that
brian: there is chunnk of the arch we didn't talk about. the security sta= te cache and transport state cache. any implementation will have to learn= about paths. we can reccomend parameters. you need this cache to make it= work.
tommy: in he we already do this, we are stick to addresses we have done gorry: on policy, there are multiple viewson what we have as inputs. some= are predictable and some are optimisation and tuning. I am also concerne= d if we do everything we end up with a gaint spec.
tim chown: the sysconfig you pull these from is a bottomeless pit. pvd in= intsrea is something interesting to me.
brian: it sounds to me like there is a collection of things people wouldl= ike to see. maybe a fourth doc. there is ahole we need to consider
aaron: yes, we can't write it yet

aaron: do you have a thought on cohabitation with applica= tions that have needs for more granularity from the api
anna: part of that is protocol specific properties.
aaron: does taps have to implement that.
brian: no that won't work. this is tided to an issue we just noticed in l= ondon. the interface document is the low performance version of the docum= ent. We probably need to get out of the way for batch and memory mapped i= o. we need holes in the api
aaron: we have focus on simple should be easy, can complex things bipass = taps?
tommy: my gut is that it should all go through taps. we cannot be worse t= han existing standards. if all you do is allow someone to setseockopt you= expose that there is a socket there, which exposes things that might not= be true. have a mapping to important sockopts and have a mapping
aaron: doc should say this

thersa: about properties, we have a zoo. required, preffe= red, can be quieried. I propose we make one section in api where we sort = this out.
phillipp: the taps system should have some auto mode where an app specifi= es in an easy way "i am doing stuff, give me appropriate transport" on th= e other hand allow the app to ask for precise transport protocols with se= t properties. An app can mix and match with these modes. How exactly to s= pecify what I am going to do.
tommy: I agree. It is really not diverging from what socket applicatons d= o today.
colin: this api is being built on our best guess of what it should look l= iike and our protocol experience. It would be good to get WG input on pro= tocols that do not fit with this api.
aaron: multicast
colin: yes multicast, and maybe icn. If there are styles we should have t= he discussion.
aaron: taking the documents as working group items should not fix the set= of documents we work on
aaron: I am going to assume WG adoption, we will confirm on the list

brian: the authors put together a github org. do we want = to bring that under WG control.

  1. Problem Statement Regarding IPv6 Address Usage, draft-gon= t-taps-address-usage-problem-statement-00, Fernando Gont, SI6 Networks. -= 10 min discussion point: - whether the topic is of interest for this working group - possibly adopting the I-D as working group document

gorry: I see two things in the document. Something about = use of ipv6 addresses and policy and I see the need for a new api if we n= eed to react. I am interested in how 6man felt about privacy and use of a= ddresses. Maybe it shouldbe two documents. What happened in 6man?
fernando: I presented twice, reponse was in belonged elsewhere. myself, t= he properties might fall into 6man or int area. the api is something is m= ore clearly in taps
ole: in 6 man we defined these mechanisms for generating addresses with t= hese properties. we have specifed one document on source address selectio= n with policy tables and ways for applications to make preferences for wh= ich type of address. we are very much bottoms up we made it available wit= hout an idea how it should be used. which is why we wanted to drop it to = the people that can make use of this.
tommy: there are two seperate concerns. tha aspect of privacy and securit= y, when to use one over the other belongs in another document which isn't= in taps, maybe int area. however the mechanism for selecting these is a = taps arch selection property. as a server what source address do I want t= o bias towards. this is all very relevant, the right place to specify wou= ld be in the interface. rather than adopt, what if we add this to the tap= s api?

ferndando: for me that is fine. I agree there are two parts. the anaylse = of the properties is neccessary to do the other part. what I wonder is wh= ere do you keep the analyse, the api could belong in a different document= =2E some place or another you need a disucssion on mapping addresses. tommy: it would be useful to reference that document. also what should th= e taps system do for default, listener vs outbound.where?
aaron: I don't think it is us
theresa: I see potential input to the impl draft. I see relationship to t= he security params in the api draft
gorry: is it possile to revise the draft to make it clearer between the a= pi and the problem space. this would really help me figure out who should= look at this. an api section should be in taps, the other section needs = someone looking at it.
fernadon: forthe api we have a problme statement, but no api
gorry: talk about the api implications in a seperate bit to where you tal= k about implications
tim chown: I thin the bulk ofits should happen here. 6774 says this shoul= d happen for out bound, pvd may change this.

--=_MailMate_25477745-ED22-4B8A-9C0B-73E1ED7B213B_=-- From nobody Tue Apr 17 08:23:01 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2C212D94E for ; Tue, 17 Apr 2018 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSTSIapdFm52 for ; Tue, 17 Apr 2018 08:22:57 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8F2212D88D for ; Tue, 17 Apr 2018 08:22:57 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id y5-v6so4037097ybg.0 for ; Tue, 17 Apr 2018 08:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=m2zqdtsImbyx90UqjUV+yhdGbdv+F0PMDCp4Q2qpHtA=; b=Si2OzDBuc9WzvffBPVO8UVsTL4tKYzoZeDiiOAf4Ayn65Bi4lGsfEcQ36oTX/ia9ij QWLSQkoIf0wyF8uq6LG+b6dOjsTXe4kGySYqSGeqf1/3RU4OEyfsCQ0v9LXb7iw6FIVD Z5icrKkeOYrZDNbnCTEZQ2IxNDR0s4W0fhqtSC5OAmw8RtfNJVX2JA0UZ2s8AZtADHLv 7njy05KqLinivFz5MQS5jfWLQH+AJX2/2zHbN+Lpr2LWMzk36zhdFl9ySCjB06uXEdg3 hka+xpihjxgOAd0aCl2SDo8xkgngFSRYjnwV+IUrH5hQ7tH3ju4I1E0MQBd/50yR9Gdu McLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=m2zqdtsImbyx90UqjUV+yhdGbdv+F0PMDCp4Q2qpHtA=; b=I/5Za3WFtv/3CUfvRxfSg6KhvHQxVE5Mdx4HVe6rHi9f9OaUqucc8vxvll+dLlNfiJ OvFOJhEwWcPtMQCDF1HrP35Q4wWezCGpi6osTv5XIgs+OQKhh0qhdMjiGgDm6xqSuus5 UjvJ1iIF0sMmHT8qOw+F9vr+VI0DT3hvvu+0FQTyW6KbL+IOJtlsaRSIkOD9R8eQeWQk PKReXysKv24xV8DeUnH/wx9EXtznEaTuBqgH82Sumh9GYXaskP1kqSDbXS3DhKltHTIe P8ZjBrL1TeikW3bQmJMrgyvlujwUosrsmfziTN+2Ex3G7OfHkcrFJWpj5sCk5Fpl7WUe 6lug== X-Gm-Message-State: ALQs6tCXYCTKt0fRzzdgogIpSguvDqvnUfy83nDNPbQcHIPGIMf+7kqO Ej8RzRa95OMIaVmOiFX8fZzQVuZn X-Google-Smtp-Source: AIpwx49E4qHNl7FTmtC5rEme0u0/mTUsi3XqHNV7dy1guDyCMSVfGgO9CORriklbswkXpABUzB9Ejw== X-Received: by 2002:a25:3542:: with SMTP id c63-v6mr1703097yba.493.1523978576479; Tue, 17 Apr 2018 08:22:56 -0700 (PDT) Received: from [172.19.36.252] ([2001:4878:a000:3000:6487:a70e:d396:21]) by smtp.gmail.com with ESMTPSA id x15sm7006797ywj.19.2018.04.17.08.22.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Apr 2018 08:22:55 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Tue, 17 Apr 2018 11:22:53 -0400 X-Mailer: MailMate (1.11.1r5471) Message-ID: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_74886857-59DB-4919-B2EE-459195EA0FCC_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] ACTION REQUIRED: updating session conflicts X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:22:59 -0000 --=_MailMate_74886857-59DB-4919-B2EE-459195EA0FCC_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Hi Folks- We should update our conflict list for scheduling TAPS meetings during the IETF week. Here’s the algorithm I’d like you to consider: * If you are an author/editor in TAPS and an author/editor or chair in another wg, that is a first priority conflict * If you are a contributor to TAPS and an author/editor or chair in another wg, that is a second priority conflict * If you are a contributor to TAPS and a contributor to another wg (which you feel you should attend), that **may** be a conflict depending on how many priority of the work to TAPS. * If you feel you “should attend” TAPS and another wg, that is not a conflict (sorry!) I propose the revised conflict list below based on my (imperfect) understanding of current TAPS contributors. There’s been some discussion that “third priority” is confusing to the secretariat so I’m hoping we can converge on just two. Please send feedback. Thanks. --aaron First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic Second Priority: tcpinc mptcp saag mmusic tram tls irtfopen OLD: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag Third Priority: mmusic tram sacm mile ipwave cfrg --=_MailMate_74886857-59DB-4919-B2EE-459195EA0FCC_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Folks-

We should update our conflict list for scheduling TAPS me= etings during the IETF week. Here=E2=80=99s the algorithm I=E2=80=99d li= ke you to consider:

  • If you are an author/editor in TAPS and an author/editor or chair in = another wg, that is a first priority conflict
  • If you are a contributor to TAPS and an author/editor or chair in ano= ther wg, that is a second priority conflict
  • If you are a contributor to TAPS and a contributor to another wg (whi= ch you feel you should attend), that may be a conflict d= epending on how many priority of the work to TAPS.
  • If you feel you =E2=80=9Cshould attend=E2=80=9D TAPS and another wg, = that is not a conflict (sorry!)

I propose the revised conflict list below based on my (im= perfect) understanding of current TAPS contributors. There=E2=80=99s bee= n some discussion that =E2=80=9Cthird priority=E2=80=9D is confusing to t= he secretariat so I=E2=80=99m hoping we can converge on just two.

Please send feedback. Thanks.

--aaron

First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmca= t tsvarea quic
Second Priority: tcpinc mptcp saag mmusic tram tls irtfopen

OLD:
First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag
Third Priority: mmusic tram sacm mile ipwave cfrg

--=_MailMate_74886857-59DB-4919-B2EE-459195EA0FCC_=-- From nobody Tue Apr 17 08:36:29 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55A312D947 for ; Tue, 17 Apr 2018 08:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVfBiwzZB945 for ; Tue, 17 Apr 2018 08:36:25 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 65437126E64 for ; Tue, 17 Apr 2018 08:36:25 -0700 (PDT) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 7874B1B00140; Tue, 17 Apr 2018 16:35:52 +0100 (BST) Message-ID: <5AD61457.5010908@erg.abdn.ac.uk> Date: Tue, 17 Apr 2018 16:35:51 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Aaron Falk CC: taps WG References: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> In-Reply-To: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] ACTION REQUIRED: updating session conflicts X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:36:28 -0000 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 list for scheduling TAPS meetings during > the IETF week. Heres the algorithm Id like you to consider: > > * If you are an author/editor in TAPS and an author/editor or chair > in another wg, that is a first priority conflict > * If you are a contributor to TAPS and an author/editor or chair in > another wg, that is a second priority conflict > * If you are a contributor to TAPS and a contributor to another wg > (which you feel you should attend), that *may* be a conflict > depending on how many priority of the work to TAPS. > * If you feel you should attend TAPS and another wg, that is not a > conflict (sorry!) > > I propose the revised conflict list below based on my (imperfect) > understanding of current TAPS contributors. Theres been some > discussion that third priority is confusing to the secretariat so > Im hoping we can converge on just two. > > Please send feedback. Thanks. > > --aaron > > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic > Second Priority: tcpinc mptcp saag mmusic tram tls irtfopen > > OLD: > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic > Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag > Third Priority: mmusic tram sacm mile ipwave cfrg > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Apr 17 08:39:29 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CFC12DA11 for ; Tue, 17 Apr 2018 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bm74RKrTY2tb for ; Tue, 17 Apr 2018 08:39:22 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4706126E64 for ; Tue, 17 Apr 2018 08:39:21 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B4B6C34025C; Tue, 17 Apr 2018 17:39:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.6595); Tue, 17 Apr 2018 17:39:17 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 17 Apr 2018 17:39:17 +0200 (CEST) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 51992706; Tue, 17 Apr 2018 17:39:17 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9A2E267A-C97E-4108-8185-B3EF3C381953"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 17 Apr 2018 17:39:16 +0200 In-Reply-To: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> Cc: taps WG To: Aaron Falk References: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Taps] ACTION REQUIRED: updating session conflicts X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:39:27 -0000 --Apple-Mail=_9A2E267A-C97E-4108-8185-B3EF3C381953 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 17 Apr 2018, at 17:22, Aaron Falk wrote: >=20 > Hi Folks- >=20 > We should update our conflict list for scheduling TAPS meetings during = the IETF week. Here=E2=80=99s the algorithm I=E2=80=99d like you to = consider: >=20 > =E2=80=A2 If you are an author/editor in TAPS and an = author/editor or chair in another wg, that is a first priority conflict > =E2=80=A2 If you are a contributor to TAPS and an author/editor = or chair in another wg, that is a second priority conflict > =E2=80=A2 If you are a contributor to TAPS and a contributor to = another wg (which you feel you should attend), that may be a conflict = depending on how many priority of the work to TAPS. > =E2=80=A2 If you feel you =E2=80=9Cshould attend=E2=80=9D TAPS = and another wg, that is not a conflict (sorry!) > I propose the revised conflict list below based on my (imperfect) = understanding of current TAPS contributors. There=E2=80=99s been some = discussion that =E2=80=9Cthird priority=E2=80=9D is confusing to the = secretariat so I=E2=80=99m hoping we can converge on just two. >=20 > Please send feedback. Thanks. >=20 > --aaron >=20 > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea = quic +panrg (I chair). Cheers, Brian > Second Priority: tcpinc mptcp saag mmusic tram tls irtfopen >=20 > OLD: > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea = quic > Second Priority: tcpinc nvo3 mptcp icnrg httpbis dots i2nsf saag > Third Priority: mmusic tram sacm mile ipwave cfrg >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_9A2E267A-C97E-4108-8185-B3EF3C381953 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlrWFSQACgkQihK3vwvq RqNDDQ/+JcZNFdcM11k1T87hfSesGwobAue6nFHHKiXvjmXreGpK4bi3aG/ybcHy 9D1JQLFjN5b1ej0yHR7cj43Wz+AT5uNUxpXZAg+989Q87EE5AsUZDpGfBn1Mwoq/ qAwvgFCC1OU18exW4HrIfblQRq3idE6IgC5/q5vOJQv8hiZXG+up6xxdk7gO/aCy 8NSskLsUxdZnQNqQWKHk8cH3DhV8SEwUBwe6inlODJqvnJu6dO8pl3MYfbn7cOYM A2PNS+th74BcmkG2PEQouZyS89IB8qLhfQufduI7LogaaTE9/hU/U2FROcjTS6bV 2J29wWRJDWlbswfycZ8P//+V8t1dY7hyYfWxxEgvPDL3pHvAIgFYP2zI4Ig6anUM I/hXNrqWnG6cHPvhKxFOkfCMMjHAuO1rMPOtQWyllEXQRqynz9F/TtKSm5f8R/t2 fjh04VkXS7F6pfk9GzygcPl/vH91VSfG2DVdF8BTGt3NEaC03/Hk5odTNfIdqSj9 FNMd/0G1NCZtWLk4M5Rz4lY/UK3klrLb8hwwXj46v1g1XstKswdNn5t4tt/d+F2U 8X9aZSA9SJLxqjhiTpeplEkUycU0PZ5WPM/psl4WxvNK2pntxyAfErv0CSldCrE6 VkEAcBZpfiW+zkfpqVCPENtxUjnwDz+oUq4NY0bEKxoxxL9cjls= =7dOa -----END PGP SIGNATURE----- --Apple-Mail=_9A2E267A-C97E-4108-8185-B3EF3C381953-- From nobody Tue Apr 17 08:46:16 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D59F126BF3 for ; Tue, 17 Apr 2018 08:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yJa8v05aTIQ for ; Tue, 17 Apr 2018 08:46:13 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000021200FC for ; Tue, 17 Apr 2018 08:46:12 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h28so7013061ywk.5 for ; Tue, 17 Apr 2018 08:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dDS9xnihCksXEtvKksi+iCQ+Yb2+UukXalmju/aD+wU=; b=Qh0DBDi8SryenhB3Hlr7HNOiBWUllqtwxcFzdPOUTa3BeLej6n4ZxRlPQU4CEUqazB q08c7umas8T2Emcz/UPd7d2k5PTW3/rAYp8oTWNVSMATg5sYi/1+lWbB3BSw7awuWK2b C2/5y7MQ8psZAMpU6F9tZz/PnOzb84zjSVZTZHw1YdnzJzPf95/BTi0jSIWYaFnmFEcT 9V4Tr7gMzPb17+lgPgYmvMwyO9V1S0Xehb+dWm4VXBWYJnRFBuBx1JwSXk8uPLRnQExV dlLEOiwS+0IAD3ht/AK+K0KgIKIjg4xqtsXEnY4p5xmimydd8QFyLUivqz0QgqXw60Il FeIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dDS9xnihCksXEtvKksi+iCQ+Yb2+UukXalmju/aD+wU=; b=SNSbYcjxMyAdxwXc0qOkhFj5821cOLCvdLlEY8BHDpubzNaFIEEcxTxCCGqDKNqcyy C41C90xBLUZaJrD64xzESa/HyJte8ATWhFkD+FzxXziZ2dkaaERnLKgdrVXQepKdhsd4 OTFe1wiiLJJMhfMVCJGs1vH3NF42xubWIyYxRtQZMOiUjw2aHJUdr6TI6wPusRGsKYEn ZbjIxq5Oxg+C7VGOTbD9rEFhkyqA8bpDByjIsunTJRy+n3ySpPCdfj8OI6QqdQUifePd 2By3zzVo4P7IoTEXpwEk5mc87twehiBybBBZYE4u1y+beQlVHZ15B+uap0jYRDIX0R7W LxEQ== X-Gm-Message-State: ALQs6tDBDpvp1xHdug0mHs3LRIYrFFcc/ISCw0vejvSVD8+HC+/zivqE gr2nhnV0Js0yNcr2fsDNtEOta4bHjHQAgU5phHA= X-Google-Smtp-Source: AIpwx4/1Flo4wpy5WVFtuQlynhqPELaJTA9bULBEprAQA9drizu5E41KcktMj2pc97zWMKhuFMRlTPi0TLlpjog1fGI= X-Received: by 10.129.47.18 with SMTP id v18mr1680695ywv.350.1523979970889; Tue, 17 Apr 2018 08:46:10 -0700 (PDT) MIME-Version: 1.0 References: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> In-Reply-To: From: Christopher Wood Date: Tue, 17 Apr 2018 15:46:00 +0000 Message-ID: To: "Brian Trammell (IETF)" Cc: Aaron Falk , taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] ACTION REQUIRED: updating session conflicts X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2018 15:46:14 -0000 On Tue, Apr 17, 2018 at 8:39 AM Brian Trammell (IETF) wrote: > > On 17 Apr 2018, at 17:22, Aaron Falk wrote: > > > > Hi Folks- > > > > We should update our conflict list for scheduling TAPS meetings during the IETF week. Here=E2=80=99s the algorithm I=E2=80=99d like you to conside= r: > > > > =E2=80=A2 If you are an author/editor in TAPS and an author/edito= r or chair in another wg, that is a first priority conflict > > =E2=80=A2 If you are a contributor to TAPS and an author/editor o= r chair in another wg, that is a second priority conflict > > =E2=80=A2 If you are a contributor to TAPS and a contributor to a= nother wg (which you feel you should attend), that may be a conflict depending on how many priority of the work to TAPS. > > =E2=80=A2 If you feel you =E2=80=9Cshould attend=E2=80=9D TAPS an= d another wg, that is not a conflict (sorry!) > > I propose the revised conflict list below based on my (imperfect) understanding of current TAPS contributors. There=E2=80=99s been some discu= ssion that =E2=80=9Cthird priority=E2=80=9D is confusing to the secretariat so I= =E2=80=99m hoping we can converge on just two. > > > > Please send feedback. Thanks. > > > > --aaron > > > > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic > +panrg (I chair). +TLS, too, where I co-author two drafts. Thanks, Chris From nobody Thu Apr 19 08:26:54 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D804D12DA24 for ; Thu, 19 Apr 2018 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb1-ZoiCWz3i for ; Thu, 19 Apr 2018 08:26:52 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C592812DA21 for ; Thu, 19 Apr 2018 08:26:51 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id l11-v6so6146957qtj.10 for ; Thu, 19 Apr 2018 08:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=CppXp6x69q2R8gpghXqaMxC98ZD6EmBa5blLV27b7+s=; b=hvuyHzbReYmTvWs6bhZV1bCQ9BFzTYHcGwR9QurHLLM8jIWSiW+l8tOoP9PYLWDeDq MpIgoPa9WKOGbmM6hJ4fQHQchHoZuvnlWfd9fSqEZf7gNJaJxwcEgukL8tHliaqkDuXf P5x+GK8o1h+B8PzC7bNKKn8IJPdr5z86mp2aS4SMarqZNW6+Asu0p46/1jz5DkDaqgcX 4lbZodVYsdQad8cvNIQ80/mL+je2fe41claSQp3tBA1ejEmyYS/M06pcKC6VtwP15dKS Kw+psDGFkcZhH8QkmL34tgdkdxjfkbuuztXt+M/V2MhfoTe5cz6+Mk3qGMI6Zm7KyHSh mO2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CppXp6x69q2R8gpghXqaMxC98ZD6EmBa5blLV27b7+s=; b=qcfSQ45nPQzp23FQrb2g+1nTgNbJPELohlmwH4yqOfJlAVrM3AkEpVzDtlWf8TdM2Q r98b5SaQSwS6PaJgOCCRlq3lsjBMVP4risE9eEl90YJS7BBeePEFs9hQqT1R3YTrHCrb Hk2UpuDLP2Rffu9xw5mncwQ9GQp1xrasNFH2ckhVe6k2ABuN2g1OM+dfZLvfmE9gFRF8 hLNM8OI9kP93G6J7s+QpVe8JCBZHrwvsoRf1kyK8vlRHoJ9Xf9XjAJiMHq6WkCzDJBCp m2dq78Mnz/LwDV/dAAyzCkw/uCvv1V5fHqg1weflbje3Va7U3eV81iG1tipJKAduUMXp fSzg== X-Gm-Message-State: ALQs6tBn/ZIaOxWYUd8WkmgvTrClxufpqPdfWmjs1RoPDaMyRU9GlBQp 854cxl9J6p+NShwd1TNmFqcjamO9 X-Google-Smtp-Source: AIpwx4/7ACGu8WX/IBkO+DRFYPzWuvYpSLD/S3CJsnpOEgullQ/rwl+e0vzN9juOrNoNTzAV0qy3IA== X-Received: by 2002:ac8:35f0:: with SMTP id l45-v6mr6481714qtb.317.1524151610436; Thu, 19 Apr 2018 08:26:50 -0700 (PDT) Received: from [172.19.32.178] ([2001:4878:a000:3000:30e1:1977:12e8:6730]) by smtp.gmail.com with ESMTPSA id a20sm2887022qkb.17.2018.04.19.08.26.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Apr 2018 08:26:49 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Thu, 19 Apr 2018 11:26:48 -0400 X-Mailer: MailMate (1.11.1r5471) Message-ID: <69535325-C8E9-49E3-AFC6-4D2C6183C83B@gmail.com> In-Reply-To: References: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_ED6F8908-8E22-4BDD-8F13-390DD1F029F7_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] ACTION REQUIRED: updating session conflicts X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 15:26:54 -0000 --=_MailMate_ED6F8908-8E22-4BDD-8F13-390DD1F029F7_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Updated: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg tls Second Priority: tcpinc mptcp saag mmusic tram irtfopen Any other input? --aaron On 17 Apr 2018, at 11:46, Christopher Wood wrote: > On Tue, Apr 17, 2018 at 8:39 AM Brian Trammell (IETF) > > wrote: > > > >>> On 17 Apr 2018, at 17:22, Aaron Falk wrote: >>> >>> Hi Folks- >>> >>> We should update our conflict list for scheduling TAPS meetings >>> during > the IETF week. Here’s the algorithm I’d like you to consider: >>> >>> • If you are an author/editor in TAPS and an author/editor >>> or > chair in another wg, that is a first priority conflict >>> • If you are a contributor to TAPS and an author/editor or >>> chair > in another wg, that is a second priority conflict >>> • If you are a contributor to TAPS and a contributor to >>> another > wg (which you feel you should attend), that may be a conflict > depending on > how many priority of the work to TAPS. >>> • If you feel you “should attend” TAPS and another wg, >>> that is > not a conflict (sorry!) >>> I propose the revised conflict list below based on my (imperfect) > understanding of current TAPS contributors. There’s been some > discussion > that “third priority” is confusing to the secretariat so I’m > hoping we can > converge on just two. >>> >>> Please send feedback. Thanks. >>> >>> --aaron >>> >>> First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea >>> quic >> +panrg (I chair). > > +TLS, too, where I co-author two drafts. > > Thanks, > Chris --=_MailMate_ED6F8908-8E22-4BDD-8F13-390DD1F029F7_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Updated:

First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmca= t tsvarea quic panrg tls
Second Priority: tcpinc mptcp saag mmusic tram irtfopen

Any other input?

--aaron

On 17 Apr 2018, at 11:46, Christopher Wood wrote:

On Tue, Apr 17, 2018 at 8:39 AM Bri= an Trammell (IETF) <ietf@trammell.ch>
wrote:


On 17 Apr 2018, at 17:22, Aaron Falk &= lt;aaron.falk@gmail.com> wrote:

Hi Folks-

We should update our conflict list for scheduling TAPS meetings during

the IETF week. Here=E2=80=99s t= he algorithm I=E2=80=99d like you to consider:

=E2=80=A2 If you are an author/e= ditor in TAPS and an author/editor or

chair in another wg, that is a = first priority conflict

=E2=80=A2 If you are a contribut= or to TAPS and an author/editor or chair

in another wg, that is a second= priority conflict

=E2=80=A2 If you are a contribut= or to TAPS and a contributor to another

wg (which you feel you should a= ttend), that may be a conflict depending on
how many priority of the work to TAPS.

=E2=80=A2 If you feel you =E2=80= =9Cshould attend=E2=80=9D TAPS and another wg, that is

not a conflict (sorry!)

I propose the revised conflict list be= low based on my (imperfect)

understanding of current TAPS c= ontributors. There=E2=80=99s been some discussion
that =E2=80=9Cthird priority=E2=80=9D is confusing to the secretariat so = I=E2=80=99m hoping we can
converge on just two.

Please send feedback. Thanks.

--aaron

First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic

+panrg (I chair).

+TLS, too, where I co-author two drafts.
=
Thanks,
Chris

--=_MailMate_ED6F8908-8E22-4BDD-8F13-390DD1F029F7_=-- From nobody Thu Apr 19 08:45:38 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A05120227 for ; Thu, 19 Apr 2018 08:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yly9MEV_bqe9 for ; Thu, 19 Apr 2018 08:45:35 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27AED12D86E for ; Thu, 19 Apr 2018 08:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1524152734; x=2388066334; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fr/j0FzJmBv9oPj11ynUdNRLCihaP1G2WPDuCNt0zNg=; b=ddF+rKik3Q3ST6pEIstQqDI0S9kTsxnP4ME7Xw7K9N3rxkOeSbvP8owdu1UjN4D+ Jksqp6PFpZMQsxwgd58CTgJPawiXbWD3fW0c3RxDIL7TguXChoMJ8xxeDIxxO0pf 5fU38mN56jxVP/QZDWOwBHDaLBZi/x+Nyjiy0UGVo/2VvfBSAELZeb8Oiwro/+XL NrT60WofbxwN07jHYTW4KuX9QBm0jxWNvQqPRz742wm39PALWqFtBif8NN4Vy8L4 GoJ3CoiJzcaqvNW52PuOeoaHVKtFxG6xFAvuokpIrvqsRPwHH37gJMkDkFqxNEhI POs7t6I3IO8gnSxMSVL44A==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id CA.6F.04908.E99B8DA5; Thu, 19 Apr 2018 08:45:34 -0700 (PDT) X-AuditID: 11973e16-446529e00000132c-3a-5ad8b99edf9d Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 79.A4.23499.E99B8DA5; Thu, 19 Apr 2018 08:45:34 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2LQOs9FwfXve6UzaWXwOqA)" Received: from [17.234.119.40] (unknown [17.234.119.40]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P7F00FXIVRUWYD0@nwk-mmpp-sz12.apple.com>; Thu, 19 Apr 2018 08:45:34 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Thu, 19 Apr 2018 08:45:28 -0700 In-reply-to: <69535325-C8E9-49E3-AFC6-4D2C6183C83B@gmail.com> Cc: taps WG To: Aaron Falk References: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> <69535325-C8E9-49E3-AFC6-4D2C6183C83B@gmail.com> X-Mailer: Apple Mail (2.3445.100.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUi2FAYoTtv540og893rSzafk9jtbgT48Dk sXPWXXaPJUt+MgUwRXHZpKTmZJalFunbJXBl/P48galgpUvF4cnH2RsYr1h1MXJySAiYSCy9 e5+pi5GLQ0hgNZPEkiWdQA4HWKJpjQlEfAOTxPPdx1lBGngFBCV+TL7HAmIzC4RJrNjzhh2i aCKTxNuWRnaQZmEBCYnNexJBatgEVCSOf9vADBLmFbCRWLdRDiQsLGAvsWPOHbCRLAKqEh83 fgQr4RSwlbj0PQViurTE0m+TGUFsEaCSZS/a2SA2vWaU2Ly1ix3ifmWJhT9vgp0gITCHTaJn 8UT2CYxCs5CcOgvJqbOAdjALqEtMmZILEdaWePLuAiuErSax8PciJmTxBYxsqxiFchMzc3Qz 88z1EgsKclL1kvNzNzGCYmC6ndgOxoerrA4xCnAwKvHwflh3I0qINbGsuDL3EKM0B4uSOO8Z +YtRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjdWvivaStGa0o77n6dNfXzxMJpz+eamwoe vfvWQClUYeqzLbuOspRNWNRmald71u9Z1Ncomb36St3HLb6lBdbaP177Z03VKz69Rp1WP4YD zT9sf5VGXchO7uy7vcdgkd8r05kbIn69erRVLp/vQfT0d4qZX4XelnCznb6U232F4/W5S+tr GrcrsRRnJBpqMRcVJwIAJMjb4mICAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUi2FB8RnfezhtRBgeemlu0/Z7GanEnxoHJ Y+esu+weS5b8ZApgiuKySUnNySxLLdK3S+DK+P15AlPBSpeKw5OPszcwXrHqYuTgkBAwkWha Y9LFyMUhJLCBSeL57uOsXYycHLwCghI/Jt9jAbGZBcIkVux5ww5RNJFJ4m1LIztIs7CAhMTm PYkgNWwCKhLHv21gBgnzCthIrNsoBxIWFrCX2DHnDthIFgFViY8bP4KVcArYSlz6ngIxXVpi 6bfJjCC2CFDJshftbBCbXjNKbN7axQ6SkBBQllj48yb7BEb+WUium4XkullAY5kF1CWmTMmF CGtLPHl3gRXCVpNY+HsRE7L4Aka2VYwCRak5iZWmeokFBTmpesn5uZsYwSFbGLGD8f8yq0OM AhyMSjy8H9bdiBJiTSwrrsw9xCjBwawkwuvdDhTiTUmsrEotyo8vKs1JLT7EKM3BoiTOe1n+ epSQQHpiSWp2ampBahFMlomDU6qBseGewzLTux7Cbd2xzid/3EwMsInV2/75ZIWY8fpbAgW/ 7nC3fb1+jnnJdd8JYo/3tlyrvbf91uPHjwM6qrewvb4/MTo50z3mNvsxqak7r5e5P7xe2ygo WJEQ815sbr7Hu1+xkutYn87Wc65nOj39I+e1fbYLt6/7HXs+/F+SUdMb2yu2cyt3uCixFGck GmoxFxUnAgCIL7E2VQIAAA== Archived-At: Subject: Re: [Taps] ACTION REQUIRED: updating session conflicts X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2018 15:45:37 -0000 --Boundary_(ID_2LQOs9FwfXve6UzaWXwOqA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Aaron, I=E2=80=99m also an author/editor for capport and ipsecme, so I=E2=80=99d = like to add those to the list if possible. Thanks, Tommy > On Apr 19, 2018, at 8:26 AM, Aaron Falk wrote: >=20 > Updated: >=20 > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea = quic panrg tls > Second Priority: tcpinc mptcp saag mmusic tram irtfopen >=20 > Any other input? >=20 > --aaron >=20 > On 17 Apr 2018, at 11:46, Christopher Wood wrote: >=20 > On Tue, Apr 17, 2018 at 8:39 AM Brian Trammell (IETF) = > wrote: >=20 >=20 > On 17 Apr 2018, at 17:22, Aaron Falk wrote: >=20 > Hi Folks- >=20 > We should update our conflict list for scheduling TAPS meetings during >=20 > the IETF week. Here=E2=80=99s the algorithm I=E2=80=99d like you to = consider: >=20 > =E2=80=A2 If you are an author/editor in TAPS and an author/editor or >=20 > chair in another wg, that is a first priority conflict >=20 > =E2=80=A2 If you are a contributor to TAPS and an author/editor or = chair >=20 > in another wg, that is a second priority conflict >=20 > =E2=80=A2 If you are a contributor to TAPS and a contributor to = another >=20 > wg (which you feel you should attend), that may be a conflict = depending on > how many priority of the work to TAPS. >=20 > =E2=80=A2 If you feel you =E2=80=9Cshould attend=E2=80=9D TAPS and = another wg, that is >=20 > not a conflict (sorry!) >=20 > I propose the revised conflict list below based on my (imperfect) >=20 > understanding of current TAPS contributors. There=E2=80=99s been some = discussion > that =E2=80=9Cthird priority=E2=80=9D is confusing to the secretariat = so I=E2=80=99m hoping we can > converge on just two. >=20 > Please send feedback. Thanks. >=20 > --aaron >=20 > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea = quic >=20 > +panrg (I chair). >=20 > +TLS, too, where I co-author two drafts. >=20 > Thanks, > Chris >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_2LQOs9FwfXve6UzaWXwOqA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Aaron,

I=E2=80=99m = also an author/editor for capport and ipsecme, so I=E2=80=99d like to = add those to the list if possible.

Thanks,
Tommy

On Apr 19, 2018, at 8:26 AM, = Aaron Falk <aaron.falk@gmail.com> wrote:

Updated:

First Priority: maprg = dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg tls
= Second Priority: tcpinc mptcp saag mmusic tram irtfopen

Any other input?

--aaron

On 17 Apr 2018, at 11:46, Christopher Wood = wrote:

On Tue, Apr = 17, 2018 at 8:39 AM Brian Trammell (IETF) <ietf@trammell.ch>
wrote:


On 17 Apr 2018, at 17:22, Aaron Falk <aaron.falk@gmail.com> wrote:

Hi Folks-

We should update our conflict list for scheduling TAPS meetings = during

the IETF week. = Here=E2=80=99s the algorithm I=E2=80=99d like you to consider:

=E2=80=A2 If you are an author/editor in TAPS and an = author/editor or

chair in another = wg, that is a first priority conflict

=E2=80=A2 If you are a contributor to TAPS and an = author/editor or chair

in another wg, that = is a second priority conflict

=E2=80=A2 If you are a contributor to TAPS and a = contributor to another

wg (which you feel = you should attend), that may be a conflict depending on
how many priority of the work to TAPS.

=E2=80=A2 If you feel you =E2=80=9Cshould attend=E2=80=9D= TAPS and another wg, that is

not a conflict = (sorry!)

I propose the revised conflict list below based on my = (imperfect)

understanding of = current TAPS contributors. There=E2=80=99s been some discussion
that =E2=80=9Cthird priority=E2=80=9D is confusing to the secretariat so = I=E2=80=99m hoping we can
converge on just two.

Please send feedback. Thanks.

--aaron

First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea = quic

+panrg (I chair).

+TLS, too, where I co-author two = drafts.

Thanks,
Chris

_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Boundary_(ID_2LQOs9FwfXve6UzaWXwOqA)-- From nobody Fri Apr 20 01:22:15 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177412704A for ; Fri, 20 Apr 2018 01:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgkSKvgr_Uyh for ; Fri, 20 Apr 2018 01:22:12 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691B81204DA for ; Fri, 20 Apr 2018 01:22:12 -0700 (PDT) Received: from [81.187.2.149] (port=48024 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f9RJ2-000700-N7; Fri, 20 Apr 2018 09:22:10 +0100 From: Colin Perkins Message-Id: <88273332-EC8C-476A-B064-397AC7230829@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_BFAEA318-6D94-4761-8283-B280B73D037C" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 20 Apr 2018 09:22:05 +0100 In-Reply-To: <69535325-C8E9-49E3-AFC6-4D2C6183C83B@gmail.com> Cc: taps WG To: Aaron Falk References: <77121A9C-9AC3-46F5-8FCA-B147A8CD8DF4@gmail.com> <69535325-C8E9-49E3-AFC6-4D2C6183C83B@gmail.com> X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Taps] ACTION REQUIRED: updating session conflicts X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 08:22:14 -0000 --Apple-Mail=_BFAEA318-6D94-4761-8283-B280B73D037C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Apr 2018, at 16:26, Aaron Falk wrote: >=20 > Updated: >=20 > First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea = quic panrg tls > Second Priority: tcpinc mptcp saag mmusic tram irtfopen >=20 I have drafts in AVTCORE and RTCWEB, so it=E2=80=99d be good if they = could be on the list. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_BFAEA318-6D94-4761-8283-B280B73D037C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 19 Apr 2018, at 16:26, Aaron Falk <aaron.falk@gmail.com> wrote:

Updated:

First Priority: maprg = dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg tls
= Second Priority: tcpinc mptcp saag mmusic tram = irtfopen


I have drafts in AVTCORE and RTCWEB, so it=E2=80=99d be good if they = could be on the list.

-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_BFAEA318-6D94-4761-8283-B280B73D037C-- From nobody Mon Apr 30 07:11:59 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D73721267BB; Mon, 30 Apr 2018 07:11:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152509751782.11735.13692780814915986184@ietfa.amsl.com> Date: Mon, 30 Apr 2018 07:11:57 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-arch-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:11:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Architecture for Transport Services Authors : Tommy Pauly Brian Trammell Anna Brunstrom Godred Fairhurst Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-arch-00.txt Pages : 19 Date : 2018-04-30 Abstract: This document provides an overview of the architecture of Transport Services, a system for exposing the features of transport protocols to applications. This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services. It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-arch-00 https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 30 07:12:27 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A40B312E88A; Mon, 30 Apr 2018 07:12:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152509753861.11782.12058353432285229687@ietfa.amsl.com> Date: Mon, 30 Apr 2018 07:12:18 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-interface-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 14:12:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Abstract Application Layer Interface to Transport Services Authors : Brian Trammell Michael Welzl Theresa Enghardt Godred Fairhurst Mirja Kuehlewind Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-interface-00.txt Pages : 36 Date : 2018-04-30 Abstract: This document describes an abstract programming interface to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime. It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-interface-00 https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 30 08:25:19 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB74B120713 for ; Mon, 30 Apr 2018 08:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pfWqNwXaOT8 for ; Mon, 30 Apr 2018 08:25:15 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5C61241F5 for ; Mon, 30 Apr 2018 08:25:15 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id m16-v6so11323230qtg.13 for ; Mon, 30 Apr 2018 08:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=vUjKU9SJhOiXDtgYGnHbhp8kQpkDzJ2wFyDcU1JoT5U=; b=ANTr+hWbhzULSAzusq4Gt37+3fkj+FRuI6WydWdGpDQn0i+gjShvX1IMPzTj9HZ7xF kGR3+Num2E51P6LJWJnr9Df6xFV/2tMmc+Id7bnGyuN79+07AlEJ2f+mDSciUitch/n1 O3FOiTaqNrmu+UM+vrmAQ7ZM+KQmjjiHd+Oq5i7f93gJ9It76ysefCD1gFvycQPybfpB /dsrPWje1xqunTSA7bu9NqTPpTErW9JuXUwz1uIkuIjMbYGrIB0gm1zXIOrcIr5F46k9 Z14Q/0RVLOmr2VantRCuBR7Oop1EiovP9fg3p1+5CPbi4p1HSYIFlDK9TsZMytPeP/8p yPyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=vUjKU9SJhOiXDtgYGnHbhp8kQpkDzJ2wFyDcU1JoT5U=; b=uBfUearbIcXz1p+pkAgKoyIrvwuEv0rq738piiZ8sxicgV0bej54arqgFw7ezgo7T9 nPWct0aBATKFO2Yu67LB9Tmw//hizrtj+7q32IElxvHhbh30nlAyvOyHZguGHyR+FOWj 5Yh6qqlpuT1zy6eNkG9XBeTi8vaW5+cOmEPRQLEpSk9RTECRZz/AKs3w8oTT1rHFhaxj vmpnIayVTDs0jM0J57VbwIQn+cdayI/VPkqDzUDtfpqtpluPzXInLqliTnW1i8ErcsPZ fTdzrTG8u/448u+4qshzfJThun9NDqpgpSTTt74qEgQ1dlKAfQXIpT9TmyY2UI8OX/Ge U+aA== X-Gm-Message-State: ALQs6tB23GlV8/98p2uHpImRtNlnCFXCldBbPDt7MOXsd6guKei20t9n yi7HzCwOYar0FGWcwY+DHTrvgwaS X-Google-Smtp-Source: AB8JxZq2KlQ0oCcW4xE7x+Yhm/gpwGU3BeKdNcuLNkANP8kjKbxafV/2BoXFmdIQbFFjiimU+dxkVw== X-Received: by 2002:aed:3bcc:: with SMTP id s12-v6mr11773516qte.83.1525101914035; Mon, 30 Apr 2018 08:25:14 -0700 (PDT) Received: from [172.19.37.125] ([2001:4878:a000:3000:28bc:d1c0:228:8dc5]) by smtp.gmail.com with ESMTPSA id j25-v6sm5745638qtn.29.2018.04.30.08.25.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Apr 2018 08:25:13 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Mon, 30 Apr 2018 11:25:11 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: <8FC842E4-0B7B-4A5D-AF6D-BE4D015A244B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_693AFA29-D191-41EE-A95F-9BA02DE52BB1_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] virtual interim meeting X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 15:25:18 -0000 --=_MailMate_693AFA29-D191-41EE-A95F-9BA02DE52BB1_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit We’d like to hold an interim call to discuss the new docs. * Duration: 2hrs * Method: WebEx * Time zones to accommodate: PDT, EDT, BST, CEST * Schedule: w/o May 14 Agenda: 1. open issues in draft-ietf-taps-interface-00.txt (Brian) 2. open issues in draft-ietf-taps-arch-00.txt (Tommy) 3. open issues in draft-ietf-taps-impl-00.txt (Anna) (if submitted) 4. open issues in draft-ietf-taps-transport-security-01.txt (Chris) (if submitted) The hasn’t been approved yet but I’d like to quickly agree on a date. Please use this Doodle if you plan to attend and contribute. (If you just want to lurk, you are welcome but don’t make us schedule around you. :) LINK: https://doodle.com/poll/w92dudq592bvuzb6 (This is the first time I’ve scheduled an interim so I may get a few process bits wrong...) --aaron --=_MailMate_693AFA29-D191-41EE-A95F-9BA02DE52BB1_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

We=E2=80=99d like to hold an interim call to discuss the = new docs.

  • Duration: 2hrs
  • Method: WebEx
  • Time zones to accommodate: PDT, EDT, BST, CEST
  • Schedule: w/o May 14

Agenda:

  1. open issues in draft-ietf-taps-interface-00.txt (Brian)
  2. open issues in draft-ietf-taps-arch-00.txt (Tommy)
  3. open issues in draft-ietf-taps-impl-00.txt (Anna) (if sub= mitted)
  4. open issues in draft-ietf-taps-transport-security-01.txt = (Chris) (if submitted)

The hasn=E2=80=99t been approved yet but I=E2=80=99d like= to quickly agree on a date. Please use this Doodle if you plan to atten= d and contribute. (If you just want to lurk, you are welcome but don=E2=80= =99t make us schedule around you. :)

LINK: https://doodle.com/poll/w92dudq592bvuzb6

(This is the first time I=E2=80=99ve scheduled an interim= so I may get a few process bits wrong...)

--aaron

--=_MailMate_693AFA29-D191-41EE-A95F-9BA02DE52BB1_=-- From nobody Mon Apr 30 11:17:03 2018 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1B9124239; Mon, 30 Apr 2018 11:17:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aafalk@akamai.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152511222173.11731.16547245366091966965.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2018 11:17:01 -0700 Archived-At: Subject: [Taps] taps - New Meeting Session Request for IETF 102 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 18:17:02 -0000 A new meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg tls capport AVTCORE RTCWEB ipsecme Second Priority: tcpinc mptcp saag mmusic tram irtfopen People who must be present: Aaron Falk Spencer Dawkins Zaheduzzaman Sarker Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Apr 30 12:51:13 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB485126D0C for ; Mon, 30 Apr 2018 12:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ft5O1P9nDR4f for ; Mon, 30 Apr 2018 12:51:10 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8BF12420B for ; Mon, 30 Apr 2018 12:51:10 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id y5-v6so3472583ybg.0 for ; Mon, 30 Apr 2018 12:51:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1jak52ExxH1wHj6erH5AP016hpuzC7WmSYdJwmWG0d8=; b=iebIVItV/PVr5walSps/IqJxv3hbFWO05CvlZZnh5Ar9JnrUXWNQ5NE+j+MZC6q4D4 V72MYsK6Jg8TXWucaSmyCXJlqEndJ4QIyvc8tL934h0jf0LoTm7nLVTm/Kh2ZsOa0h61 2G7e56UCG70Ianm3Wy6uv5BhjwNyIEgSq8FMmIOUrPAmp+BOpyqh7v3KDwDKrE1PgLGo /rti09NYOVnMWa0aQ+wHVAi0gtEslv8AXyk2aygFmF+wTNEwfUeihEvyQeTm55UeYy1F kVrUP8t+YTK1Q3um1leZ0hmcWcDX38fnwQHyWsmCD6R9QH+guSaQ/Vx7eDoD5ImT4iWV Rv2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1jak52ExxH1wHj6erH5AP016hpuzC7WmSYdJwmWG0d8=; b=avQkaxWb0/DlDgXmLPvpwKLqBxu8MJZ2re//487zMugAiJLabv0fnaJeeDDBz+n5Jb gvxibWeVOILK/PmyvHDkRz36RQpVixauVO1LfuZ9NQeYcq86X2zqSSHc0QEsc1Sqbw4R C+BD2D+2M/1LE/37NcTIJMoaNglFlWzxFWT2T5j2NvqsoYSCgDv4LQ1ufbxq2/sYRa7C dELdW9n63PIXy1Rt5sX8DsWpKhj5QJ7XoaXhcTmsSWnNbv3TgFUF3wC96dgjnCo3oVWg +IdF0un9UV8Ndpt+6Qy91zahU9uLQw7MP9DEw/LyGuk/8i7p5zIP9ThW2544yePrjKMw tcZg== X-Gm-Message-State: ALQs6tBDuAgRLHFdLpGw4m/N8hrr0HfYeWDIlpDooP1qR9cimTNwIcoY 6MMvAoQ3MJZI20jIQGArvuvmMqWgRNaZW6Hv2UI= X-Google-Smtp-Source: AB8JxZoj5XNjjtgK0Z3cvF4F+rSPON9oXBVkNMtDNT6ZcAsgc6vfNHOXmWvhsnmldLNhD7l9RkrPJhagOW9CYP3iySc= X-Received: by 2002:a25:b214:: with SMTP id i20-v6mr8159836ybj.471.1525117868899; Mon, 30 Apr 2018 12:51:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:d014:0:0:0:0:0 with HTTP; Mon, 30 Apr 2018 12:51:08 -0700 (PDT) In-Reply-To: <8FC842E4-0B7B-4A5D-AF6D-BE4D015A244B@gmail.com> References: <8FC842E4-0B7B-4A5D-AF6D-BE4D015A244B@gmail.com> From: Spencer Dawkins at IETF Date: Mon, 30 Apr 2018 14:51:08 -0500 Message-ID: To: Aaron Falk Cc: taps WG Content-Type: multipart/alternative; boundary="000000000000d11b0e056b162cfa" Archived-At: Subject: Re: [Taps] virtual interim meeting X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 19:51:12 -0000 --000000000000d11b0e056b162cfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Aaron, On Mon, Apr 30, 2018 at 10:25 AM, Aaron Falk wrote: > We=E2=80=99d like to hold an interim call to discuss the new docs. > > - Duration: 2hrs > - Method: WebEx > - Time zones to accommodate: PDT, EDT, BST, CEST > - Schedule: w/o May 14 > > Agenda: > > 1. open issues in draft-ietf-taps-interface-00.txt (Brian) > 2. open issues in draft-ietf-taps-arch-00.txt (Tommy) > 3. open issues in draft-ietf-taps-impl-00.txt (Anna) (if submitted) > 4. open issues in draft-ietf-taps-transport-security-01.txt (Chris) > (if submitted) > > The hasn=E2=80=99t been approved yet but I=E2=80=99d like to quickly agre= e on a date. > Please use this Doodle if you plan to attend and contribute. (If you just > want to lurk, you are welcome but don=E2=80=99t make us schedule around y= ou. :) > > LINK: https://doodle.com/poll/w92dudq592bvuzb6 > > (This is the first time I=E2=80=99ve scheduled an interim so I may get a = few > process bits wrong...) > We don't do a lot of virtual interims in TSV, but we'll make that happen, even if we have to adjust a few things along the way. Spencer --000000000000d11b0e056b162cfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Aaron,

On Mon, Apr 30, 2018 at 10:25 AM, Aaron Falk &l= t;aaron.falk@gmai= l.com> wrote:

We=E2=80=99d like to hold an interim call to discuss the ne= w docs.

  • Duration: 2hrs
  • Method: WebEx
  • Time zones to accommodate: PDT, EDT, BST, CEST
  • Schedule: w/o May 14

Agenda:

  1. open issues in draft-ietf-taps-interface-00.txt (Brian= )
  2. open issues in draft-ietf-taps-arch-00.txt (Tommy)
  3. open issues in draft-ietf-taps-impl-00.txt (Anna) (if submi= tted)
  4. open issues in draft-ietf-taps-transport-security-01.t= xt (Chris) (if submitted)

The hasn=E2=80=99t been approved yet but I=E2=80=99d like t= o quickly agree on a date. Please use this Doodle if you plan to attend an= d contribute. (If you just want to lurk, you are welcome but don=E2=80=99t= make us schedule around you. :)

LINK: https://doodle.com/poll/w92d= udq592bvuzb6

(This is the first time I=E2=80=99ve scheduled an interim s= o I may get a few process bits wrong...)

=

We don't do a lot of virtual interims in TSV, but w= e'll make that happen, even if we have to adjust a few things along the= way.

Spencer=C2=A0
--000000000000d11b0e056b162cfa--