Kyle Rose has done a nice job with the minutes based on hi= s and Dave Lawrence's notes.=C2=A0 Many thanks, guys!

TAPS folk: please review these minutes and send comments to the list.

Thanks,

--aaron

taps minutes=

IETF-94 Yokohama

Reported by David Lawrence an= d Kyle Rose

Note Well covered.

1. Agenda bashing

<= span class=3D"" style=3D"margin:0px;padding:1px 0px">2. WG Status

3. draft-ietf-taps-transport= s

4. draft-welzl-ta= ps-transports

5. A = way forward for "document 2"

6. AOB

Dec 2015 planned: Document 1, in= formational, to be sent to IESG defining services provided by IETF transpor= t protos and congestion control mechanisms.

-----------------= -------------------------------------------------------------

<= div id=3D"magicdomid18" class=3D"" style=3D"margin:0px;padding:0px;color:rg= b(0,0,0);font-family:monospace;font-size:12px;line-height:16px">Brian Trammell, speaking on draf= t-ietf-taps-transports (version 7)

<= /div>

Charter and abstract basic= ally unchanged since last meeting.=C2=A0 Thinks the document is ready for D= ecember publication.=C2=A0 There are a few editor's notes which can mos= tly be dropped, except for some text needed in 3.9.2 about the RTP interfac= e.=C2=A0 Drop section 4.1 (Transport Matrix).=C2=A0 Then push as -08 and re= ady for WGLC.

Poll of room:=C2=A0 anyone see any issues to pr= event it going to WGLC?=C2=A0 Silence.

<= span class=3D"" style=3D"margin:0px;padding:1px 0px">----------------------= --------------------------------------------------------

Naeem Khademi, speaking on draft-welz= l-taps-transports-00

Scope of the draft: describe only exis= ting IETF protos for two endpoint comms.=C2=A0 Covers only TCP and SCTP cur= rently, but he intends to cover all the protocols listed.

Goa= l: use a generic approach to help designers/API devs to know how to use the= protocols.

3 pass approach:

1. relevant parts of proto RFCs are summarized a= s to what they provide and how they are used. Identify all defined forms of= interaction between the proto and its user.

2. categorize into connection-relat= ed vs. data transmission, such as identifying connect() in TCP as connectio= n-related and sending and receiving as about data transmission.

3. present a sup= erset of all services in all protos, turning it upside down.=C2=A0 For each= service, list which protocols provide it.

Karen: T= he document here needs to refer to latest RFCs on SCTP, like 6458, not just= 4960.

Christian: W= e use protocols based on how they work and what costs are involved, not sol= ely based on the API that's available. Some cost resulting from an impl= ementation that does not appear anywhere in the API needs to be taken into = account.

Aaron: Pro= blem as he understood it is that there is a desire to be able to use new pr= otocols (starting with existing standards) where they would work, and fall = back to older protocols where they don't work. Goal wasn't composit= ion, but to use the best protocol you can that works end-to-end.

Mirja: What's needed is a= good interface for choosing the right protocol.

Christian: Choose HTTP over TCP because the= y want to get through firewalls, or need to limit overhead, etc.=C2=A0

Brian: deconstructing a= nd reconstructing each protocol has been a very useful process.=C2=A0 Would= be interesting to see whether you get the same result if you used SCTP'= ;s abstract API vs the newer SCTP socket api.

Mic (?): Doesn&= #39;t seem that your looked at differences in implementations from RFC spec= ifications.=C2=A0 Really should cover that.

Naeem: Hope to cover implementations as doc evolve= s.

Gorry via Jabber: Just add the protos from mailing list di= scussion (UDP, UDP-Lite, MPTCP, DTLS and TLS). And probably DCCP. (General = agreement on Cory's suggestion.) Will confirm on mailing list.

Aaron: Who's read the document? Raise your hands.

Not many people have read the do= cument, but at least the people at the microphone had.

Aaron= : Hum if we should adopt doc (as supplement to target 1). Some humming. Not= ? Silence.

Determined that a milestone should be added based = on what the document addresses, but this does not require a change to the W= G scope, and therefore no change required to the charter. (Aaron) It is als= o the case that two documents can address one milestone. (Brian T.)<= /div>

Naeem will change his document to conform to the group's termino= logy throughout. (Implication is that the other document will be changed as= well, if necessary.)

--------------------------------------= ----------------------------------------

Stein Gjessing on document 2, defining taps system be= tween application layer and transport layer.

Thinks that draf= t-welzl-taps-transport should really be addressing the needs of document 2,= specifing a minimal taps interface to the transport protos.

= A document 3 is needed to describe an abstract interface between taps and a= pplication.

Aaron: Looking for volunteers to do close review = of draft-ietf-taps-tranports-08.=C2=A0 (Silence, unfortunately.)

AOB: ... none.

--94eb2c08813afebbdb0524b0a9a1-- From nobody Mon Nov 16 15:30:19 2015 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 467261A8F43 for ; Mon, 16 Nov 2015 15:30:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151116233018.27918.68134.idtracker@ietfa.amsl.com> Date: Mon, 16 Nov 2015 15:30:18 -0800 From: IETF Secretariat Archived-At: Subject: [Taps] Milestones changed for taps WG X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 23:30:18 -0000 Changed milestone "Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms", set due date to December 2015 from June 2015, added draft-ietf-taps-transports to milestone. Changed milestone "Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support", set due date to July 2016 from December 2015. Changed milestone "Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG", set due date to July 2017 from March 2016. Changed milestone "Recharter or conclude.", set due date to November 2017 from March 2016. URL: https://datatracker.ietf.org/wg/taps/charter/ From nobody Tue Nov 17 00:26:23 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C81B2C7B for ; Tue, 17 Nov 2015 00:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham 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 oIHMLS1rDIr5 for ; Tue, 17 Nov 2015 00:26:18 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 7E7CE1B2C7A for ; Tue, 17 Nov 2015 00:26:18 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zybai-0001PB-8r; Tue, 17 Nov 2015 09:26:16 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zybah-000100-Lr; Tue, 17 Nov 2015 09:26:16 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Tue, 17 Nov 2015 09:26:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <834552EA-50F3-4F67-A1D4-5FAF8BFD2561@ifi.uio.no> References: To: Aaron Falk X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 6 sum msgs/h 3 total rcpts 35281 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EA9C445D2F090123ED37D97BC7F68F01F7A7BACF X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 8423 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: David C Lawrence , Kyle Rose , "taps@ietf.org" Subject: Re: [Taps] Draft TAPS minutes from IETF-94 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 08:26:21 -0000 Hi, Two comments in line: > On 17 Nov 2015, at 00:21, Aaron Falk wrote: >=20 > Kyle Rose has done a nice job with the minutes based on his and Dave = Lawrence's notes. Many thanks, guys! >=20 > TAPS folk: please review these minutes and send comments to the list. >=20 > Thanks, >=20 > --aaron >=20 > taps minutes > IETF-94 Yokohama > Reported by David Lawrence and Kyle Rose >=20 > Note Well covered. >=20 > 1. Agenda bashing > 2. WG Status > 3. draft-ietf-taps-transports > 4. draft-welzl-taps-transports > 5. A way forward for "document 2" > 6. AOB >=20 > Dec 2015 planned: Document 1, informational, to be sent to IESG = defining services provided by IETF transport protos and congestion = control mechanisms. >=20 > = --------------------------------------------------------------------------= ---- > Brian Trammell, speaking on draft-ietf-taps-transports (version 7) >=20 > Charter and abstract basically unchanged since last meeting. Thinks = the document is ready for December publication. There are a few = editor's notes which can mostly be dropped, except for some text needed = in 3.9.2 about the RTP interface. Drop section 4.1 (Transport Matrix). = Then push as -08 and ready for WGLC. >=20 > Poll of room: anyone see any issues to prevent it going to WGLC? = Silence. >=20 > = --------------------------------------------------------------------------= ---- > Naeem Khademi, speaking on draft-welzl-taps-transports-00 >=20 > Scope of the draft: describe only existing IETF protos for two = endpoint comms. Covers only TCP and SCTP currently, but he intends to = cover all the protocols listed. >=20 > Goal: use a generic approach to help designers/API devs to know how to = use the protocols. >=20 > 3 pass approach: >=20 > =E2=80=A2 1. relevant parts of proto RFCs are summarized as to = what they provide and how they are used. Identify all defined forms of = interaction between the proto and its user. >=20 > =E2=80=A2 2. categorize into connection-related vs. data = transmission, such as identifying connect() in TCP as connection-related = and sending and receiving as about data transmission. >=20 > =E2=80=A2 3. present a superset of all services in all protos, = turning it upside down. For each service, list which protocols provide = it. >=20 > Karen: The document here needs to refer to latest RFCs on SCTP, like = 6458, not just 4960. > Christian: We use protocols based on how they work and what costs are = involved, not solely based on the API that's available. Some cost = resulting from an implementation that does not appear anywhere in the = API needs to be taken into account. > Aaron: Problem as he understood it is that there is a desire to be = able to use new protocols (starting with existing standards) where they = would work, and fall back to older protocols where they don't work. Goal = wasn't composition, but to use the best protocol you can that works = end-to-end. > Mirja: What's needed is a good interface for choosing the right = protocol. > Christian: Choose HTTP over TCP because they want to get through = firewalls, or need to limit overhead, etc.=20 > Brian: deconstructing and reconstructing each protocol has been a very = useful process. Would be interesting to see whether you get the same = result if you used SCTP's abstract API vs the newer SCTP socket api. >=20 > Mic (?): Doesn't seem that your looked at differences in = implementations from RFC specifications. Really should cover that. > Naeem: Hope to cover implementations as doc evolves. Having watched it on the mic, I can't remember the statement on the mic = or how it was phrased right now - but I do remember that Naeem's answer = was about covering other protocols than just SCTP and TCP. In the = minutes here it looks different. > Gorry via Jabber: Just add the protos from mailing list discussion = (UDP, UDP-Lite, MPTCP, DTLS and TLS). And probably DCCP. (General = agreement on Cory's suggestion.) Will confirm on mailing list. >=20 > Aaron: Who's read the document? Raise your hands. > Not many people have read the document, but at least the people at the = microphone had. >=20 > Aaron: Hum if we should adopt doc (as supplement to target 1). Some = humming. Not? Silence. >=20 > Determined that a milestone should be added based on what the document = addresses, but this does not require a change to the WG scope, and = therefore no change required to the charter. (Aaron) It is also the case = that two documents can address one milestone. (Brian T.) >=20 > Naeem will change his document to conform to the group's terminology = throughout. (Implication is that the other document will be changed as = well, if necessary.) >=20 > = --------------------------------------------------------------------------= ---- > Stein Gjessing on document 2, defining taps system between application = layer and transport layer. >=20 > Thinks that draft-welzl-taps-transport should really be addressing the = needs of document 2, specifing a minimal taps interface to the transport = protos. This is wrong, it's not what was presented. Stein said that document 2 = should be **based upon** draft-welzl-taps-transport because this = explains the "how", not the "what" (which is addressed by = draft-ietf-taps-transports). Cheers, Michael From nobody Tue Nov 17 07:08:51 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B409E1A900B for ; Tue, 17 Nov 2015 07:08:49 -0800 (PST) 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, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham 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 iGuAY_G-CKsb for ; Tue, 17 Nov 2015 07:08:46 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 2FC461A8F3E for ; Tue, 17 Nov 2015 07:08:46 -0800 (PST) Received: by ykdv3 with SMTP id v3so12275689ykd.0 for ; Tue, 17 Nov 2015 07:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FH0F2+9Gvmx+gWCIeyKxMBoW3WqECI48p4pcBZ3esn8=; b=ZsYApZIsdtpoS1yWrGvJk7KztH/9pNJORCVjM1BUBSkDJLoBzsNZKLbvz0uHD/Mn+o 7Kq5pX2xn/Kg4sZWSZrMP6eHlvq7/ugRXQlahiI7HpuSjWjjr69gLmzWLf1kORzl48tH 1PGNMymOtpqsncfTnH9ctUSxmIHzmb1/xftJshjMHdS0kIju3I/H7AOwkY+VkcRv8NCh Hv818djWxvEIysnJktp9vH6ESanwslhIXcPz2+WFoIqZGC5f2ZenIvs69B9YJLvxNvWz Ho/L1MBxKT93J+NYKB619Fc4jNiWC8F66E94cLmYIGUZtGgI3CPcs6g0zlz3BkFMo6HE /jyQ== MIME-Version: 1.0 X-Received: by 10.13.240.66 with SMTP id z63mr40783689ywe.261.1447772925368; Tue, 17 Nov 2015 07:08:45 -0800 (PST) Received: by 10.37.95.2 with HTTP; Tue, 17 Nov 2015 07:08:45 -0800 (PST) In-Reply-To: <834552EA-50F3-4F67-A1D4-5FAF8BFD2561@ifi.uio.no> References: <834552EA-50F3-4F67-A1D4-5FAF8BFD2561@ifi.uio.no> Date: Tue, 17 Nov 2015 10:08:45 -0500 Message-ID: From: Aaron Falk To: Michael Welzl Content-Type: multipart/alternative; boundary=94eb2c035ec8eea2230524bde699 Archived-At: Cc: David C Lawrence , Kyle Rose , "taps@ietf.org" Subject: Re: [Taps] Draft TAPS minutes from IETF-94 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 15:08:49 -0000 --94eb2c035ec8eea2230524bde699 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Michael. I've put fixes in the etherpad version. Feel free to review & revise at http://etherpad.tools.ietf.org:9000/p/notes-ietf-94-taps= . --aaron On Tue, Nov 17, 2015 at 3:26 AM, Michael Welzl wrote: > Hi, > > Two comments in line: > > > > > On 17 Nov 2015, at 00:21, Aaron Falk wrote: > > > > Kyle Rose has done a nice job with the minutes based on his and Dave > Lawrence's notes. Many thanks, guys! > > > > TAPS folk: please review these minutes and send comments to the list. > > > > Thanks, > > > > --aaron > > > > taps minutes > > IETF-94 Yokohama > > Reported by David Lawrence and Kyle Rose > > > > Note Well covered. > > > > 1. Agenda bashing > > 2. WG Status > > 3. draft-ietf-taps-transports > > 4. draft-welzl-taps-transports > > 5. A way forward for "document 2" > > 6. AOB > > > > Dec 2015 planned: Document 1, informational, to be sent to IESG definin= g > services provided by IETF transport protos and congestion control > mechanisms. > > > > > -------------------------------------------------------------------------= ----- > > Brian Trammell, speaking on draft-ietf-taps-transports (version 7) > > > > Charter and abstract basically unchanged since last meeting. Thinks th= e > document is ready for December publication. There are a few editor's not= es > which can mostly be dropped, except for some text needed in 3.9.2 about t= he > RTP interface. Drop section 4.1 (Transport Matrix). Then push as -08 an= d > ready for WGLC. > > > > Poll of room: anyone see any issues to prevent it going to WGLC? > Silence. > > > > > -------------------------------------------------------------------------= ----- > > Naeem Khademi, speaking on draft-welzl-taps-transports-00 > > > > Scope of the draft: describe only existing IETF protos for two endpoint > comms. Covers only TCP and SCTP currently, but he intends to cover all t= he > protocols listed. > > > > Goal: use a generic approach to help designers/API devs to know how to > use the protocols. > > > > 3 pass approach: > > > > =E2=80=A2 1. relevant parts of proto RFCs are summarized as to wh= at they > provide and how they are used. Identify all defined forms of interaction > between the proto and its user. > > > > =E2=80=A2 2. categorize into connection-related vs. data transmis= sion, > such as identifying connect() in TCP as connection-related and sending an= d > receiving as about data transmission. > > > > =E2=80=A2 3. present a superset of all services in all protos, tu= rning it > upside down. For each service, list which protocols provide it. > > > > Karen: The document here needs to refer to latest RFCs on SCTP, like > 6458, not just 4960. > > Christian: We use protocols based on how they work and what costs are > involved, not solely based on the API that's available. Some cost resulti= ng > from an implementation that does not appear anywhere in the API needs to = be > taken into account. > > Aaron: Problem as he understood it is that there is a desire to be able > to use new protocols (starting with existing standards) where they would > work, and fall back to older protocols where they don't work. Goal wasn't > composition, but to use the best protocol you can that works end-to-end. > > Mirja: What's needed is a good interface for choosing the right protoco= l. > > Christian: Choose HTTP over TCP because they want to get through > firewalls, or need to limit overhead, etc. > > Brian: deconstructing and reconstructing each protocol has been a very > useful process. Would be interesting to see whether you get the same > result if you used SCTP's abstract API vs the newer SCTP socket api. > > > > Mic (?): Doesn't seem that your looked at differences in implementation= s > from RFC specifications. Really should cover that. > > Naeem: Hope to cover implementations as doc evolves. > > Having watched it on the mic, I can't remember the statement on the mic o= r > how it was phrased right now - but I do remember that Naeem's answer was > about covering other protocols than just SCTP and TCP. In the minutes her= e > it looks different. > > > > Gorry via Jabber: Just add the protos from mailing list discussion (UDP= , > UDP-Lite, MPTCP, DTLS and TLS). And probably DCCP. (General agreement on > Cory's suggestion.) Will confirm on mailing list. > > > > Aaron: Who's read the document? Raise your hands. > > Not many people have read the document, but at least the people at the > microphone had. > > > > Aaron: Hum if we should adopt doc (as supplement to target 1). Some > humming. Not? Silence. > > > > Determined that a milestone should be added based on what the document > addresses, but this does not require a change to the WG scope, and > therefore no change required to the charter. (Aaron) It is also the case > that two documents can address one milestone. (Brian T.) > > > > Naeem will change his document to conform to the group's terminology > throughout. (Implication is that the other document will be changed as > well, if necessary.) > > > > > -------------------------------------------------------------------------= ----- > > Stein Gjessing on document 2, defining taps system between application > layer and transport layer. > > > > Thinks that draft-welzl-taps-transport should really be addressing the > needs of document 2, specifing a minimal taps interface to the transport > protos. > > This is wrong, it's not what was presented. Stein said that document 2 > should be **based upon** draft-welzl-taps-transport because this explains > the "how", not the "what" (which is addressed by > draft-ietf-taps-transports). > > Cheers, > Michael > > --94eb2c035ec8eea2230524bde699 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks, Michael.=C2=A0 I've put fixes in the etherpad = version.=C2=A0 Feel free to review & revise at=C2=A0http://etherpad.tools.iet= f.org:9000/p/notes-ietf-94-taps.

--aaron

On Tue, Nov 17, 2= 015 at 3:26 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

Hi,

Two comments in line:

> On 17 Nov 2015, at 00:21, Aaron Falk <aaron.falk@gmail.com> wrote:
>
> Kyle Rose has done a nice job with the minutes based on his and Dave L= awrence's notes.=C2=A0 Many thanks, guys!
>
> TAPS folk: please review these minutes and send comments to the list.<= br> >
> Thanks,
>
> --aaron
>
> taps minutes
> IETF-94 Yokohama
> Reported by David Lawrence and Kyle Rose
>
> Note Well covered.
>
> 1. Agenda bashing
> 2. WG Status
> 3. draft-ietf-taps-transports
> 4. draft-welzl-taps-transports
> 5. A way forward for "document 2"
> 6. AOB
>
> Dec 2015 planned: Document 1, informational, to be sent to IESG defini= ng services provided by IETF transport protos and congestion control mechan= isms.
>
> ----------------------------------------------------------------------= --------
> Brian Trammell, speaking on draft-ietf-taps-transports (version 7)
>
> Charter and abstract basically unchanged since last meeting.=C2=A0 Thi= nks the document is ready for December publication.=C2=A0 There are a few e= ditor's notes which can mostly be dropped, except for some text needed = in 3.9.2 about the RTP interface.=C2=A0 Drop section 4.1 (Transport Matrix)= .=C2=A0 Then push as -08 and ready for WGLC.
>
> Poll of room:=C2=A0 anyone see any issues to prevent it going to WGLC?= =C2=A0 Silence.
>
> ----------------------------------------------------------------------= --------
> Naeem Khademi, speaking on draft-welzl-taps-transports-00
>
> Scope of the draft: describe only existing IETF protos for two endpoin= t comms.=C2=A0 Covers only TCP and SCTP currently, but he intends to cover = all the protocols listed.
>
> Goal: use a generic approach to help designers/API devs to know how to= use the protocols.
>
> 3 pass approach:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 1. relevant parts of proto RFCs ar= e summarized as to what they provide and how they are used. Identify all de= fined forms of interaction between the proto and its user.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 2. categorize into connection-rela= ted vs. data transmission, such as identifying connect() in TCP as connecti= on-related and sending and receiving as about data transmission.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 3. present a superset of all servi= ces in all protos, turning it upside down.=C2=A0 For each service, list whi= ch protocols provide it.
>
> Karen: The document here needs to refer to latest RFCs on SCTP, like 6= 458, not just 4960.
> Christian: We use protocols based on how they work and what costs are = involved, not solely based on the API that's available. Some cost resul= ting from an implementation that does not appear anywhere in the API needs = to be taken into account.
> Aaron: Problem as he understood it is that there is a desire to be abl= e to use new protocols (starting with existing standards) where they would = work, and fall back to older protocols where they don't work. Goal wasn= 't composition, but to use the best protocol you can that works end-to-= end.
> Mirja: What's needed is a good interface for choosing the right pr= otocol.
> Christian: Choose HTTP over TCP because they want to get through firew= alls, or need to limit overhead, etc.
> Brian: deconstructing and reconstructing each protocol has been a very= useful process.=C2=A0 Would be interesting to see whether you get the same= result if you used SCTP's abstract API vs the newer SCTP socket api. >
> Mic (?): Doesn't seem that your looked at differences in implement= ations from RFC specifications.=C2=A0 Really should cover that.
> Naeem: Hope to cover implementations as doc evolves.

Having watched it on the mic, I can't remember the statemen= t on the mic or how it was phrased right now - but I do remember that Naeem= 's answer was about covering other protocols than just SCTP and TCP. In= the minutes here it looks different.

> Gorry via Jabber: Just add the protos from mailing list discussion (UD= P, UDP-Lite, MPTCP, DTLS and TLS). And probably DCCP. (General agreement on= Cory's suggestion.) Will confirm on mailing list.
>
> Aaron: Who's read the document? Raise your hands.
> Not many people have read the document, but at least the people at the= microphone had.
>
> Aaron: Hum if we should adopt doc (as supplement to target 1). Some hu= mming. Not? Silence.
>
> Determined that a milestone should be added based on what the document= addresses, but this does not require a change to the WG scope, and therefo= re no change required to the charter. (Aaron) It is also the case that two = documents can address one milestone. (Brian T.)
>
> Naeem will change his document to conform to the group's terminolo= gy throughout. (Implication is that the other document will be changed as w= ell, if necessary.)
>
> ----------------------------------------------------------------------= --------
> Stein Gjessing on document 2, defining taps system between application= layer and transport layer.
>
> Thinks that draft-welzl-taps-transport should really be addressing the= needs of document 2, specifing a minimal taps interface to the transport p= rotos.

This is wrong, it's not what was presented. Stein said that docu= ment 2 should be **based upon** draft-welzl-taps-transport because this exp= lains the "how", not the "what" (which is addressed by = draft-ietf-taps-transports).

Cheers,
Michael

--94eb2c035ec8eea2230524bde699--