From nobody Wed May 2 06:32:05 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 00BC3126FDC for ; Wed, 2 May 2018 06:32:04 -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 t2nVtHtVCW5l for ; Wed, 2 May 2018 06:32:02 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 EBE65126FB3 for ; Wed, 2 May 2018 06:32:01 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id f1-v6so18367162qtj.6 for ; Wed, 02 May 2018 06:32:01 -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=oIUmkSsR1aNiiE6mq0O3aC2qaaSHftUsBRMawimnBFE=; b=nlbjnvMYG1cZ9CcSoLbDOhI6NHLOGSHqffBzSR/yyn4rirtpzZ+WHmgaMrPgblQsT7 upHfk3EUBqoTZVUrghCD9BgeyGUmoyEvoPgbHXer810fkam055Gx8QkBwY35xbcBpvGi fl0qnwscKn/x4cZiKD0e7I/RoF58eD1s1Ozc1cY/WRKHImM2VfMpb9y/zy7GrSKtFTm9 uX6pJx5gVJkwXvgIawQ+n3gQe3ExBr7Fc1uqksy4/FiViLaVwXOuq8Z21U1rkifwpIhj IVcF+sD3WRY9K8CvXhHBwf/fqouJl4RM+Ua6Fe/JASvLNxRQUmIXMuD71EVvxfFChMTx 4U2A== 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=oIUmkSsR1aNiiE6mq0O3aC2qaaSHftUsBRMawimnBFE=; b=AHmJ+ak7Ey1VHurwh4jFjJHa/5OsW4tT/J/4sVqDSVnrdl2z/7KyFBLd3Ef76RHZtp QL7OabShFxnggyIWZzAa1+sBC+eHfAxY8pDja/xo2HFf9LOQikcTOpx6+l1xX7ESEl2F 64yqsZXFlbg+xh8POh++q8fn6NyKxOGTU3fCkIl6TUY1qjLbQrAVWi2C9vEXNlvvWwmE dNM25MSHbtzrIjJARUQ+a6+JIngYUcb2JfeLY7k9+vEIuz2UpGNLWFe79naKBaMMkCRk 7Pctcl0fxDccRv7j3j02d9UBhQZxDW0V8ziz6/shldXTegOHi7/NxCI4mhJBd1mIbVFt Ts4Q== X-Gm-Message-State: ALQs6tD3lLO9Cbgzh37zlczuRfDK61fV/mtQImyKPdSYb6VBoY81JtOP x89XrvK7Qp5r/YL36x+35WVIjy3X X-Google-Smtp-Source: AB8JxZoWObBrkWq5l1+uEAdWF7+7DtNEOksr/FulUci1rbNhIErmH+e+NIq01J3cRZUsdMJUUDR87A== X-Received: by 2002:ac8:10d:: with SMTP id e13-v6mr15844848qtg.403.1525267920688; Wed, 02 May 2018 06:32:00 -0700 (PDT) Received: from [172.19.34.129] ([2001:4878:a000:3000:54f8:be58:fb18:4285]) by smtp.gmail.com with ESMTPSA id s58-v6sm10309632qtc.81.2018.05.02.06.31.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 May 2018 06:31:59 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 02 May 2018 09:31:58 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: In-Reply-To: <8FC842E4-0B7B-4A5D-AF6D-BE4D015A244B@gmail.com> References: <8FC842E4-0B7B-4A5D-AF6D-BE4D015A244B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1F2FE752-747B-4273-8351-2271F9531727_=" Content-Transfer-Encoding: 8bit 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: Wed, 02 May 2018 13:32:04 -0000 --=_MailMate_1F2FE752-747B-4273-8351-2271F9531727_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Looks like Weds 11:00-13:00 EDT, 17:00-19:00 CEST, 8:00-10:00 PDT is the winner. Please mark your calendars. I'll followup with dial-in info. --aaron On 30 Apr 2018, at 11:25, Aaron Falk wrote: > 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_1F2FE752-747B-4273-8351-2271F9531727_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Looks like Weds 11:00-13:00 EDT, 17:00-19:00 CEST, 8:00-1= 0:00 PDT is the winner. Please mark your calendars. I'll followup with = dial-in info.

--aaron

On 30 Apr 2018, at 11:25, 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 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_1F2FE752-747B-4273-8351-2271F9531727_=-- From nobody Wed May 2 07:50:13 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 6F3CD120726; Wed, 2 May 2018 07:50:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152527260621.11264.4938766168451022865@ietfa.amsl.com> Date: Wed, 02 May 2018 07:50:06 -0700 Archived-At: Subject: [Taps] Transport Services (taps) WG Virtual Meeting: 2018-05-16 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: Wed, 02 May 2018 14:50:06 -0000 The Transport Services (taps) Working Group will hold a virtual interim meeting on 2018-05-16 from 11:00 to 13:00 America/New_York. 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) Information about remote participation: WebEx: https://ietf.webex.com/meet/taps From nobody Thu May 10 07:53:06 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 7CB1A1243FE; Thu, 10 May 2018 07:53:05 -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 dgCHFj-EZ1qe; Thu, 10 May 2018 07:53:04 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 E8B731241FC; Thu, 10 May 2018 07:53:00 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id q13-v6so2893215qtp.4; Thu, 10 May 2018 07:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=ZjY1/atPjjKY3gFlxHgwQAYkEs9hn429mXl33hl5nGQ=; b=SOTd4/jqLbBRhEo/dDhH2fSQu9CZKE210yFfbbponSNsCItciEjcJhpT7KCr726Wea TYZjO80GjgKjHlgAYpiJjoYsnDQxXpoyGOA/yRJzVeM+KeDO1WlJ9C5U3BNL01Lpux6e Oa3Rpdv4+t7Xy3lkcuT71NO+5oGu94e1EpmXvekjpA9gQ110f3Tn8X0m5qGuwvHuYDc9 nqwDrHkMhFeV0Y0rn09qJJb0txz3HROs4+axQgyYJHso7FUUaRPbh1DOvgRDML7xYiBx XkcuYC0MqYhPu+7CgcpBZOfNR+vdDtLxK1vB0k3TEmFkdJOnq6ltSrSCpWpNO1q5uC1S dpQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=ZjY1/atPjjKY3gFlxHgwQAYkEs9hn429mXl33hl5nGQ=; b=tbMTiW6RvQwe5WyHT14kKmDISEgmEtCBd8gL0lsAz9xcc98LcvoSSYoha7CHRkRLVl DZSxz4kk2q9d+unWRXtxDtHOUOEJ6cVLqpWkqF6EEOkBCT9RQ3JSun+mL21w9FKkR5ZE dmw/J4l/dx4L7DU/OACBek43ypoMP+hbcRi0JFUTMlDhP1Wpe2M6QjI8Zg8BOCZoHvFW 7l6+9+HKT7SuBir1wcoE1PfRtxr0t8zeIuSmr0okFoZysF1jeQuL4nCB2AyRBOyr0PUW Fkeekvb7wSIsZFTsgOjA5OzLJVFDZMJpmfPL+Iq1Wq/DQJ6wCFZqAvYW61onJ10+nRCD isUw== X-Gm-Message-State: ALKqPwdA+O56fdKhZ67wupRkw++eAWj4Krn6i9jgH9ehoPlXDVPAvvqK ZeGAVJ54zC0kS7D4fqvEf/FZDZeK X-Google-Smtp-Source: AB8JxZqw2e1ajCqMTqSQGJ0xgvYzi5vIJOiKDN3aVCRaVA2Do2TUNpThSanXDj4thyDOm9VAX+JvLw== X-Received: by 2002:ac8:15a:: with SMTP id f26-v6mr1656996qtg.32.1525963979700; Thu, 10 May 2018 07:52:59 -0700 (PDT) Received: from [172.19.36.182] ([2001:4878:a000:3000:84ab:ff30:d6e6:2f79]) by smtp.gmail.com with ESMTPSA id z16-v6sm747067qta.34.2018.05.10.07.52.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 07:52:59 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Cc: draft-ietf-taps-minset@ietf.org Date: Thu, 10 May 2018 10:52:57 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_BB34A769-421F-4EB5-8FA3-FBA2A169EDC3_=" Archived-At: Subject: [Taps] working group last call for draft-ietf-taps-minset 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, 10 May 2018 14:53:05 -0000 --=_MailMate_BB34A769-421F-4EB5-8FA3-FBA2A169EDC3_= Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Dear TAPS working group, As discussed in London, it's time to last call = [draft-ietf-taps-minset-03](https://tools.ietf.org/html/draft-ietf-taps-m= inset-03). A Minimal Set of Transport Services for TAPS Systems draft-ietf-taps-minset-03 Abstract This draft recommends a minimal set of IETF Transport Services offered by end systems supporting TAPS, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. Please read the draft and send comments to the list. This document is = planned to be an Informational RFC. Statements along the lines of = 'ready to publish' are also welcome. WGLC will conclude in two weeks on May 24, 2018. --aaron (for the chairs) --=_MailMate_BB34A769-421F-4EB5-8FA3-FBA2A169EDC3_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Dear TAPS working group,

As discussed in London, it's time to last call draft-ietf-taps-minset-03. 

          A Minim=
al Set of Transport Services for TAPS Systems
                       draft-ietf-taps-minset-03

Abstract

   This draft recommends a minimal set of IETF Transport Services
   offered by end systems supporting TAPS, and gives guidance on
   choosing among the available mechanisms and protocols.  It is based
   on the set of transport features in RFC 8303.

Please read the draft and send comments to the list. This= document is planned to be an Informational RFC. Statements along the li= nes of 'ready to publish' are also welcome.

WGLC will conclude in two weeks on May 24, 2018.

--aaron (for the chairs)

--=_MailMate_BB34A769-421F-4EB5-8FA3-FBA2A169EDC3_=-- From nobody Fri May 11 04:26:44 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 5055412E88F for ; Fri, 11 May 2018 04:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 zKfbuZvY_0bm for ; Fri, 11 May 2018 04:26:40 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 42A3012E88D for ; Fri, 11 May 2018 04:26:39 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 054DFAF; Fri, 11 May 2018 13:26:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1526037979; bh=VJMdouvH82mEfK0NfLEUFpQw5jWVbzdguaWsjHlk+yQ=; h=Date:From:To:Subject:In-Reply-To:References:From; b=So/t14B9X4CEYXVJqkYPgzeJRDOX72QGshCBF1+95Sznzrq8J7m8wUc023xZNW6La 816xjT70XSaGM39WLLPCsP083hzYZaqrFS/JKRh3/dwOveicouu9Ug4WNI06g2e0js 7bssue7DoeLxovnh5pYP0wfWFZ47d/rzWVgn8WsM= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 032FC9F for ; Fri, 11 May 2018 13:26:19 +0200 (CEST) Date: Fri, 11 May 2018 13:26:18 +0200 (CEST) From: Mikael Abrahamsson To: taps WG In-Reply-To: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> Message-ID: References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset 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, 11 May 2018 11:26:42 -0000 On Thu, 10 May 2018, Aaron Falk wrote: > Please read the draft and send comments to the list. This document is > planned to be an Informational RFC. Statements along the lines of > 'ready to publish' are also welcome. I've never read this document before, but read all the main body now. I did not read all of the appendices. I did read A3.7 plus search for my pet peeve, which is trying to avoid IP level fragmentation in communication plus handling path MTU blackhole detection/mitigation. It seems lots of what I was looking for is here. The main body (minus appendices) is easy to read and makes sense to me. I guess some details will be cleared up in a future document that actually specifies the APIs and how they would look. A3.7 at least gives possibility for applications to get PMTU information, that's great. However, I couldn't find exactly how an application can be helped to determine the actual working PMTU by specifying some kind of probe packets that are devoid of actual "content", ie padded to max PMTU size? At least that would be understood by two TAPS systems for the protocols where this isn't already implementable in other ways (I imagine this can be done for SCTP and TCP without the application having to get much involved, but will be harder for UDP). So to implement some kind of "test if PMTU actually works" TAPS functionality? I know I'm late in the game here and haven't followed TAPS closely, so something like this might already be in there, but it's decided to not go into the minimum requirements? Anyhow, for a first-time reader, this document seems fine and nothing jumped out to me as being wrong in it (of the parts that I read). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri May 11 08:06:41 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 3887912D94E for ; Fri, 11 May 2018 08:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4TIzgXqcE6pg for ; Fri, 11 May 2018 08:06:33 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 0A2BF1200C1 for ; Fri, 11 May 2018 08:06:32 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fH9cr-0005AV-W0; Fri, 11 May 2018 17:06:30 +0200 Received: from [160.80.82.29] by mail-mx03.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fH9cr-000EvG-BM; Fri, 11 May 2018 17:06:29 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Fri, 11 May 2018 17:06:26 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1C27F481-AFD7-40D5-BA8E-A85C599DA684@ifi.uio.no> References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 160.80.82.29 is neither permitted nor denied by domain of ifi.uio.no) client-ip=160.80.82.29; envelope-from=michawe@ifi.uio.no; helo=[160.80.82.29]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.058, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5EE1902F39B4161563DAA50CC82C3634CB0C5348 Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset 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, 11 May 2018 15:06:40 -0000 Dear Mikael, Thanks a lot for reading, and thanks for your feedback! Answers in = line: > On May 11, 2018, at 1:26 PM, Mikael Abrahamsson = wrote: >=20 > On Thu, 10 May 2018, Aaron Falk wrote: >=20 >> Please read the draft and send comments to the list. This document is = planned to be an Informational RFC. Statements along the lines of = 'ready to publish' are also welcome. >=20 > I've never read this document before, but read all the main body now. = I did not read all of the appendices. >=20 > I did read A3.7 plus search for my pet peeve, which is trying to avoid = IP level fragmentation in communication plus handling path MTU blackhole = detection/mitigation. >=20 > It seems lots of what I was looking for is here. The main body (minus = appendices) is easy to read and makes sense to me. I guess some details = will be cleared up in a future document that actually specifies the APIs = and how they would look. A3.7 at least gives possibility for = applications to get PMTU information, that's great. >=20 > However, I couldn't find exactly how an application can be helped to = determine the actual working PMTU by specifying some kind of probe = packets that are devoid of actual "content", ie padded to max PMTU size? This document is strictly based on RFCs 8303 and 8304. These RFCs list = what TCP, MPTCP, SCTP, UDP, UDP-Lite and LEDBAT offer, according to = their spec. =46rom this, on top of UDP, you=E2=80=99d have to implement this = functionality by yourself inside your application, and using the UDP = functionality that=E2=80=99s covered by draft-ietf-taps-minset you can = do this on top of a transport system that only offers this =E2=80=9Cminimu= m set". However, this is only a minimal set of functionality that = transport systems should expose; it is quite okay for a transport system = to offer functionality that goes beyond it. > At least that would be understood by two TAPS systems for the = protocols where this isn't already implementable in other ways (I = imagine this can be done for SCTP and TCP without the application having = to get much involved, but will be harder for UDP). Yes - > So to implement some kind of "test if PMTU actually works" TAPS = functionality? This is a question about draft-ietf-taps-interface, and for the current = version of this draft, the answer is no. Note that a TAPS transport = system can be deployed one-sided, i.e. there=E2=80=99s no signaling = side-channel or anything; so for some questions, such as =E2=80=9Cdoes = the PMTU actually work=E2=80=9D, only your application may know the = answer. This said, we could think about supporting = draft-ietf-tsvwg-datagram-plpmtud in draft-ietf-taps-interface. Given = that Gorry is an author of both drafts, I expect him to have an opinion = on that :) > I know I'm late in the game here and haven't followed TAPS closely, so = something like this might already be in there, but it's decided to not = go into the minimum requirements? This minimum set is only based on what the examined protocols can = currently do. If people think a transport system should be able to do = more, I=E2=80=99d suggest to directly propose this for = draft-ietf-taps-interface. > Anyhow, for a first-time reader, this document seems fine and nothing = jumped out to me as being wrong in it (of the parts that I read). Good to know, thanks! Cheers, Michael From nobody Fri May 11 08:08:59 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 1F7CD12EAB5 for ; Fri, 11 May 2018 08:08:55 -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 ySS5iuXWrk7j for ; Fri, 11 May 2018 08:08:52 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 29D2D1200C1 for ; Fri, 11 May 2018 08:08:47 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id f13-v6so7442330qtp.10 for ; Fri, 11 May 2018 08:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:references:mime-version; bh=ENvOM37L7PtiE5tevGx7PiToK/6Rh5F6qLV2iJQhTqA=; b=dft/q1h2IJFyNAriR09vwX2aclrSUw4xdjuHobeu/PXJ5YyDyJuTKMlIA9nFyiEzmT +gtoV544GrwVS2QzPq7WA47htH0aCbdHAfzKd0ZtbzuHkigUIRYEgvnp+Fdcj9A+8MPU L+zXA3TfHQ5t9ybmwRaaXKCCEjUNPKXcOFffiaIN/3oqmD0U/rCplypwIQWn0dbYstsk amZx/5naq+TlMUK7sudIZ2VIgCWGPjvdx4Jy8qQMjgnmNcHelSi1v16yq2uN3IijQL2l wi3f1YBjj6m35Ibk5OaCvn9VZJUkXYLejKVA28Hvr6lha+GmNgaJecDc9dGa6CSEKLRM NwEQ== 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:references :mime-version; bh=ENvOM37L7PtiE5tevGx7PiToK/6Rh5F6qLV2iJQhTqA=; b=ibkVBNK5Zt9AIEGNRWHZngsg6xOJQ1YWgLXgk+btsvaJ4ZfE4weKEhQmEjn5IbfUP5 kE0XfGXhy9ko4nwM593ColHN2dtZY2OG1mTc4D7geM77jtujnLDZn+X1m8oZkcQQDA7e +phFFctbWfIqXx+MDxpOlBFCXjLOXSdbf2NrHSRvpCpHXVuioocMTyh4IHgYQqX6+o41 9DZ5Hn04BmBDu2XAOATQqQOl8N+rN+uDzRsL/+1Ef9CRspzoxrfKfyfMCTJNI3Pncg1B +RRVMfCsqyhIki1Aij0HEM1022LGAZ5NjRWkbDGELXGpjoYhaWw5Ig8RaBNYv/isYdwa uIIQ== X-Gm-Message-State: ALKqPwfIPbcnAjp5J/RxSa/YpLU+BW6jNG72O1RIBR8b76+BkwnFUv9W q8mNj4F7e/9Tc7ogA3VlCfkkesDH X-Google-Smtp-Source: AB8JxZqF6Mcg1O8tcm3QfY/dIZBekhY/9d40tHAICUOOrmD1UULlgxN8iUo5B+N6+fQU/IeR4q11hA== X-Received: by 2002:a0c:b02e:: with SMTP id k43-v6mr5496746qvc.231.1526051325844; Fri, 11 May 2018 08:08:45 -0700 (PDT) Received: from [172.19.36.182] ([2001:4878:a000:3000:469:455c:84b:fd48]) by smtp.gmail.com with ESMTPSA id t125-v6sm2552330qkb.90.2018.05.11.08.08.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 May 2018 08:08:44 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Fri, 11 May 2018 11:08:42 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: <36265E49-01D2-4E63-A872-C9F821246193@gmail.com> References: <152527260621.11264.4938766168451022865@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_7A421397-DD4C-460C-9059-2DBC07D9E135_=" Archived-At: Subject: [Taps] Reminder: Transport Services (taps) WG Virtual Meeting: 2018-05-16 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, 11 May 2018 15:08:58 -0000 --=_MailMate_7A421397-DD4C-460C-9059-2DBC07D9E135_= Content-Type: text/plain; format=flowed Forwarded message: > From: IESG Secretary > To: IETF-Announce > Cc: taps@ietf.org > Subject: Transport Services (taps) WG Virtual Meeting: 2018-05-16 > Date: Wed, 02 May 2018 07:50:06 -0700 > > The Transport Services (taps) Working Group will hold > a virtual interim meeting on 2018-05-16 from 11:00 to 13:00 > America/New_York. > > 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) > > Information about remote participation: > WebEx: https://ietf.webex.com/meet/taps --=_MailMate_7A421397-DD4C-460C-9059-2DBC07D9E135_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= br>

Forwarded message:

From: IESG Secretary <iesg-secre= tary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: taps@ietf.org
Subject: Transport Services (taps) WG Virtual Meeting: 2018-05-16
Date: Wed, 02 May 2018 07:50:06 -0700

The Transport Services (taps) Working Group will hold
a virtual interim meeting on 2018-05-16 from 11:00 to 13:00 America/New_Y= ork.

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 s= ubmitted)

Information about remote participation:
WebEx: = https://ietf.webex.com/meet/taps

--=_MailMate_7A421397-DD4C-460C-9059-2DBC07D9E135_=-- From nobody Fri May 11 11:43:38 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 EF474126C2F; Fri, 11 May 2018 11:43:30 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152606421093.10589.5961535081637061241@ietfa.amsl.com> Date: Fri, 11 May 2018 11:43:30 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-01.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: Fri, 11 May 2018 18:43:31 -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 : A Survey of Transport Security Protocols Authors : Tommy Pauly Colin Perkins Kyle Rose Christopher A. Wood Filename : draft-ietf-taps-transport-security-01.txt Pages : 30 Date : 2018-05-11 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard. This survey is not limited to protocols developed within the scope or context of the IETF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-01 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-01 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 Fri May 11 11:44: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 DECDA12711B for ; Fri, 11 May 2018 11:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 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] 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 ne_81p2ictdh for ; Fri, 11 May 2018 11:44:16 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 225C7126C2F for ; Fri, 11 May 2018 11:44:16 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l15-v6so1866467ywk.3 for ; Fri, 11 May 2018 11:44:16 -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; bh=0Rvswg3IiV8EEVzCjHkNWG/24DOvrUnxSiybX+5p7Oc=; b=OqNVR2vLwTKklNb+4b5eVZAYHJ1CfSiq3HGswVBUUjJUhYuT7C/6jNiiIr32fIE3jF gizDw9w1EkrnIvSi0K4OPHzsBSfy/2IU785XbuccAC/liQYyCICrEVw3EVdYcdIFb+2/ yfct2R+Rq+JHvtfYTbH4YAIpQHLr1BYGcVxdl2Cn/vGyH8nSLk2FMdFRVAnCCteJ1+Ph uNUBk8tCC1UjLLIL67Fl6h25hVj3plaHRt/N3SyhUOgYGQWLjcOD9sz5ZqXNgLLFMarC LPhwVlarUiM4nY1pz+8hUIApr4bkSdgQHlozJb693P/wlT3lMoeovQNMgsQwAvfvPRo0 O0iA== 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; bh=0Rvswg3IiV8EEVzCjHkNWG/24DOvrUnxSiybX+5p7Oc=; b=fF7nmOb8KjBTikvCTvOud41SqOiWMpPEDr1kru+sr8bRoGotIsk/zKtoIJGIvg30XX 4Pj08VgkHDHW6zqiuMSGClO4fMCYNfEElLFdVE5SnSztorhVb/+XtYDs5iSljNsIf1hM zPi363/juNZb97zcqZnNADv/ESnTTytJejZi6QVjj8WsCjHh28e1XigIvLRZyhU6HenM jNJSH9wZeBTBuhWYA3I9RN+b8dph/kxK795UMlfoNnm9iYYp9EaKCIUEt+ER1l82iY0g v9p3m4ICWcKU6pGRSYcmn4KyPtZWSX8x28qk7nSLVaHurc8tM9DXEiNND9vMwL9dnL1d Xegg== X-Gm-Message-State: ALKqPweGF8GP3GlixbPvM8ZvLxof17KgQgh6BHxtOl8/ykjQVl7/ad+Q x2Ybh4gId4sYYxz2r/HlNcZwi30mcnxNF5kLJzc= X-Google-Smtp-Source: AB8JxZqT/z+3DAhCB7XghnyG51s54E9yxSZCOjP7ZOz1DFA51+f2UjiqDdWCCOEJmJN+Xzj0GtNhE8Bma44NYiAXXeQ= X-Received: by 2002:a81:4705:: with SMTP id u5-v6mr99357ywa.350.1526064255175; Fri, 11 May 2018 11:44:15 -0700 (PDT) MIME-Version: 1.0 References: <152527260621.11264.4938766168451022865@ietfa.amsl.com> <36265E49-01D2-4E63-A872-C9F821246193@gmail.com> In-Reply-To: <36265E49-01D2-4E63-A872-C9F821246193@gmail.com> From: Christopher Wood Date: Fri, 11 May 2018 11:44:03 -0700 Message-ID: To: Aaron Falk Cc: taps WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Taps] Reminder: Transport Services (taps) WG Virtual Meeting: 2018-05-16 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, 11 May 2018 18:44:18 -0000 FYI, the survey was updated. Here's a pointer to the latest version: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ Best, Chris On Fri, May 11, 2018 at 8:09 AM Aaron Falk wrote: > Forwarded message: > From: IESG Secretary > To: IETF-Announce > Cc: taps@ietf.org > Subject: Transport Services (taps) WG Virtual Meeting: 2018-05-16 > Date: Wed, 02 May 2018 07:50:06 -0700 > The Transport Services (taps) Working Group will hold > a virtual interim meeting on 2018-05-16 from 11:00 to 13:00 America/New_York. > 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) > Information about remote participation: > WebEx: https://ietf.webex.com/meet/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue May 15 10:59:04 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 6990112E044 for ; Tue, 15 May 2018 10:59:02 -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 l-wGG20oijPr for ; Tue, 15 May 2018 10:59:00 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 D5625124E15 for ; Tue, 15 May 2018 10:58:58 -0700 (PDT) X-Envelope-From: phils@in-panik.de X-Envelope-To: Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w4FHwawd017793 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 15 May 2018 19:58:36 +0200 Received: from [2001:bf0:c001:30:18fc:9101:38f9:aada] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fIeCo-0003XU-Kt for taps@ietf.org; Tue, 15 May 2018 19:57:46 +0200 From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <75DA5EC4-CD71-4770-A72E-DBC4D38E4055@in-panik.de> Date: Tue, 15 May 2018 19:58:32 +0200 To: taps WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [Taps] Background to Socket Intents / Size to be Received Intent in draft-ietf-taps-interface 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, 15 May 2018 17:59:02 -0000 Hi, we have pushed a new paper on Socket Intents to arxiv.org, which has been in the peer-review process for quite some while.=20 This paper contains the research side of the =E2=80=9CSize to be = Received Intent=E2=80=9D from draft-ietf-taps-interface, Appendix 1 and demonstrates its use. It also contains background to the talk Theresa gave at the PANRG=20 session in London. Available at: https://arxiv.org/abs/1804.08484 Abstract: In today's Internet, mobile devices are connected to multiple access networks, e.g., WiFi/DSL and LTE. To take advantage of the networks' diverse paths characteristics (delay, bandwidth, and reliability) and aggregate bandwidth, we need smart strategies for choosing which interface(s) to use for what traffic. In this paper, we present an approach how to tackle this challenge as part of the Operating System (OS): With the concept of Socket Intents, applications can express what the y know about their communication pattern and their preferences. Using our Socket Intents Prototype and our modified BSD Socket Interface, this information is used to choose the most appropriate path or path combination on a per message or per connection basis. We evaluate our system based on the use case of Web browsing: Using our prototype and a client-side proxy, we show the feasibility and benefits of our design. Using a flow-based simulator and a full factorial experimental design, we study a broad range of access network combinations (based on typical DSL and LTE scenarios) and real workloads (Alexa Top 100 and Top 1000 Web Sites). Our policies achieve performance benefits in more than 50% of the cases and speedups of more than factor two in 20% of the cases without adding overhead in the other cases. AVE! Philipp S. Tiesel / phils=E2=80=A6 From nobody Wed May 16 07:26:05 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 6BA3812D7ED for ; Wed, 16 May 2018 07:26:03 -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 TRupsYv6fjYA for ; Wed, 16 May 2018 07:26:01 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 3F6FE12D7E6 for ; Wed, 16 May 2018 07:26:01 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id h2-v6so1250267qtp.7 for ; Wed, 16 May 2018 07:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:references:mime-version; bh=xb+gIQZ0uZY43fbcb+Z5X/JIVwUNzQqi3VDIjex0b80=; b=X/Cg0Q4q1LG7MpfAff/79JtHesBPGXRhLiT0UhY12dfCKo/t2ibEMNxjrwISEUax7c SfG677WcDw7Y9iKwcAUjgqzu1lFgFZ3YkyzktFBtQXokY2EnGQbk2khLnmtUNU8VZ7mj sWaxNIcNXpsaxwzP4m3RgXCGb67GsZgyeDJs0W/Yg5x51sEcPA9Hky6Kt6HyUHkVQsjq vBy3YI2tEpGgXPH9YSdpiRhbHgvjkV27bJRQQquGrbFbL0Xd837Dkaz1y0Dr2pHsUV89 /bx4rk0YHrFvyNccb2lbBEV46VVbq4Ewy4m1b0Ol9HKjAa4Fw4p/vZxvRztfYhBnLxU9 lpxA== 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:references :mime-version; bh=xb+gIQZ0uZY43fbcb+Z5X/JIVwUNzQqi3VDIjex0b80=; b=fxhycDNLfO966Us7xKz3tihHjeL+if+/JJnBejTOUT4LeZSPrsIxWFaPYyh/4sN4oG B+y0wsJYIlayMm3OMMd8Xi7/LPa6OVdFTqXJy0Mnehw+E9cKF+BMzrCV4Y1EiFanoFIs DF2Fa4dMt+DyjrfrxER9CmA7qr3SLVxJwiVGp+/RhzD4971/85m76tU3/dEaK3KRDM1Z tKqH2aQYpX1pmQpFGdbyTPMCDpM6qtgbhZBEZ4887JMho/x1PNGKg/GmIBFkGrBofL5A dSQ6//+L/pDjI+9Qv9SC/0NubqV4kSWQ7syqU1Fuz0WHd0Scsb+872l1+nZ8E2X/bl8H jVgw== X-Gm-Message-State: ALKqPwekbYXC8KFd13VgSkoyes1MDX9bk1zMElvRLLuEFX91MFBdzBQ1 1XulASsnV1bVn3V7EFpYdIqzYrBIvis= X-Google-Smtp-Source: AB8JxZo+KQeu5McDgYsecoWdX7MP/bXpVwAaucmOmQEKLjhfm0GQtOKOA5DvT0xYSoZ7c+ZHyxy3hg== X-Received: by 2002:a0c:91b5:: with SMTP id n50-v6mr1127201qvn.20.1526480759782; Wed, 16 May 2018 07:25:59 -0700 (PDT) Received: from [172.19.35.152] ([2001:4878:a000:3000:98f2:2a1:fca7:6016]) by smtp.gmail.com with ESMTPSA id r32-v6sm2156838qtr.55.2018.05.16.07.25.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 May 2018 07:25:58 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 16 May 2018 10:25:57 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: <0734F7EC-33C2-4042-94E9-F76AFE179DF4@gmail.com> References: <152527260621.11264.4938766168451022865@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_276ED4BE-C60A-47FA-9443-18A094C19590_=" Archived-At: Subject: [Taps] Transport Services (taps) WG Virtual Meeting: TODAY 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: Wed, 16 May 2018 14:26:04 -0000 --=_MailMate_276ED4BE-C60A-47FA-9443-18A094C19590_= Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable Slight revision to agenda below. The Transport Services (taps) Working Group will hold a virtual interim meeting on 2018-05-16 from 11:00 to 13:00 = America/New_York. Agenda: 1. Issues list in draft-ietf-taps-interface-00.txt and draft-ietf-taps-arch-00.txt (Brian & Tommy) https://github.com/taps-api/drafts/issues?q=3Dis%3Aissue+is%3Aopen+la= bel%3Adiscuss (1 hr) 2. open issues in draft-ietf-taps-transport-security-01.txt (Chris) (15min) Information about remote participation: WebEx: https://ietf.webex.com/meet/taps --=_MailMate_276ED4BE-C60A-47FA-9443-18A094C19590_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Slight revision to agenda below.

The Transport Services (taps) Working Group will hold
= a virtual interim meeting on 2018-05-16 from 11:00 to 13:00 America/New_Y= ork.

Agenda:

  1. Issues list in draft-ietf-taps-interface-= 00.txt and
    draft-ietf-taps-arch-00.txt (Brian & Tommy)
    https://github.com/taps-api= /drafts/issues?q=3Dis%3Aissue+is%3Aopen+label%3Adiscuss
    (1 hr)

  2. open issues in draft-ietf-taps-transport-= security-01.txt (Chris)
    (15min)

Information about remote participation:
WebEx: https://ietf.webex.com/meet/taps

--=_MailMate_276ED4BE-C60A-47FA-9443-18A094C19590_=-- From nobody Wed May 16 23:44:52 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 ED368127867 for ; Wed, 16 May 2018 23:44:49 -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, RCVD_IN_DNSWL_MED=-2.3] 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 BekaQ0EfRKUz for ; Wed, 16 May 2018 23:44:48 -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 660B4127873 for ; Wed, 16 May 2018 23:44:48 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 8F5581B0013B for ; Thu, 17 May 2018 07:44:16 +0100 (BST) Message-ID: <5AFD24BF.8000608@erg.abdn.ac.uk> Date: Thu, 17 May 2018 07:44:15 +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: taps WG Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] Some editorial comments from a read through of draft-ietf-taps-transport-security-01 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, 17 May 2018 06:44:50 -0000 I have just quickly read the TAPS document on transport security and have a few comments that may be useful for the next revision, Gorry --- “TCP-AO adds authenticity” - should this be “TCP-AO adds authentication” our an authentication service? “AH adds per-datagram authenticity” - should this also be “authentication”. - - - Section 3: “ This section contains descriptions of security protocols that currently used to protect data being sent over a network.” - is this /are currently used/. - - - “AEAD” - please define when first used - - - Section 3.2.1. “ DTLS is modified from TLS to account for packet loss, reordering, and duplication that may occur when operating over UDP.” - to account for doesn’t quite explain that these things happen and this can work with them, first time I read I wondered whether this implied some features to retransmit etc. Is it clearer to say something like: “ DTLS is modified from TLS to operate with the possibility of packet loss, reordering, and duplication that may occur when operating over UDP. - - - Similarly making this change is maybe(?) clearer: “Since datagrams may be replayed, “ to “Since datagrams can be replayed, “ - - - Section 3.2.3 States a dependency on PMTU discovery. I think this dependency is on choosing a datgarm size (which is true of any UDP usage - section 3.2 of RFC8085). — Section 3.3 omits a reference to IETF QUIC. - - - Section 3.3.3, QUIC also in the same way relies on a PMTU. (as in DTLS). - in the same vein, I think gQUIC has chosen a fixed datgram size. - - - Section 3.4.1.2 “ESP Security Associations” - I think you need to define SA here? - - - [RFC3545] - appears as text, rather than a reference. - - - Section 3.5.2 “(RFC5763) Mandatory mutually authenticated key exchange.” - The brackets around the reference appear unusual. - - - Section 3.8.1 “These keys are used” - The word /these/ reads odd, maybe: - “The keys are used” - - - From nobody Thu May 17 04:16:14 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 BBB8B12D77A for ; Thu, 17 May 2018 04:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TWIaOb6IYf7F for ; Thu, 17 May 2018 04:16:10 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [130.149.220.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3D68F12D7E4 for ; Thu, 17 May 2018 04:16:10 -0700 (PDT) Received: from [IPv6:2001:638:809:ff1f::8295:dc6d] (unknown [IPv6:2001:638:809:ff1f::8295:dc6d]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 1C371593 for ; Thu, 17 May 2018 13:16:09 +0200 (CEST) To: taps@ietf.org References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= xsBNBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAHNKFRoZXJlc2EgRW5naGFyZHQgPHRoZXJlc2FAc29tZXNlcnZlci5kZT7CwJgEEwEKAEIC GyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE7xG3phZ0Plgk2BDpgz007xx2oPcF AlqgJ4EFCRC919sACgkQgz007xx2oPf5lAf/VKgireR+/7Pg+sNigE+25bYRjezB5CPz0rPk YQndvFNbegCPKIXlIUbCwAuj1BW4qgBvNzq3X6lsGQ+wE30bKxnRLfjNW4PDGqbT2SsdJPOH b4KOnwaZjLGkDXaqABmkejHEg2hyi1on5JHEWFKz24qsFGosSCH3ZrOrKo9boZS5Md6+J0P/ y8gSCgS2ABYuo9VhyoDWD9hDRF1d7mvRUzACVieSxTOgwFsTCfsNmRnlZjTKjrEWhgpG1W0v 2J6xthOaE9J4TA2uWIi4t6+gvbiseXclzu2KxKrxy+xXEDD7hUb+JvvVLKkhjXwqbyx3lQoS Vy/MEw80YybnHyYFYM7ATQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149JBtI8Oh4Ywktc1ExL uZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjNd6uFEdFNLtf+2/Qq jVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1WmMcXMQX+Npwv9plE JOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5w8p8OYN41q0vqefB aMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsgXurujk0OvEFhhkQo nVRXUYmLTM0EXQARAQABwsBlBBgBAgAPAhsMBQJW+lhqBQkNGAjEAAoJEIM9NO8cdqD3fK4H /2Jk05xp6eL8jTQO4kpdZtngbP4dxZ9vwgbdmKsN5Rln88Xm5HH8GXHzxU0hY2pLU0QoPzE5 B//tEbM34tYLNXSQScc8UVvfsh3Qup4OmagkAGHPs3lSLnvX17IUaDuhjJcHeDNE0h3ZmhLc XaHijcuxn2OvCVT3qpE5C6voC/IwNQSQGyPogDxfD1IpL7u3aqAmGnuIkLLCnm8DFl3wcGur w3wbVLuMV/WHXvIVgvvjf0fWCKBiyDMimVr2tPEMv/MgRU7BcuMvJx8I4fnC03Wm0BD6Wti+ 01JN0gcYBRNUHnEl/IzOo8A0lHSV5V9Hd/X5G7kkslTSK1xLZMabOCTCwHwEGAEKACYCGwwW IQTvEbemFnQ+WCTYEOmDPTTvHHag9wUCWqAnjQUJEL3X5wAKCRCDPTTvHHag99GLB/0f0E0h NezbAsWOt6PvBXxegI7nPeI3hNN4rP/ZcDQJCvs6OSpsSSWWeUa/LAk6wKyt+JwcYv55eTu1 Zd/wsybRA4DWkSADug3Kcans7rlYbiQ33eP08UD/ST6eSpa3O27DcoEClKrK0QFpqrB144bm YJZhrACOlIgjYGj6v0iCEf2aIyACxPTjg4+PdAwpJkDNMTMd6QS5hr8Bmp8XEsUTbtZ0NmkS rO9De5ogNtjHkdtP7G0sklzOkQ12JPDK8c3g/A1J9ZpzK/VMDtYzZC6yCzk5VHBokhDKm+gZ GXRhrBoceDGkuCz/HevYiqadNdOF5r5bH+JhKs8UW/isRtL/ Message-ID: <5ee8025e-9737-2fca-b648-3187f135c526@inet.tu-berlin.de> Date: Thu, 17 May 2018 13:16:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset 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, 17 May 2018 11:16:13 -0000 Dear all, I have read the draft, including the appendix, and I think it is in good shape and can be published. However, I stumbled across the following clarification issue: In Section 3, it says: "elements of the system that may prohibit implementation over UDP are marked with "!UDP".  To implement a transport system that can also work over UDP, these marked transport features should be excluded." Does this really mean that a transport system should not implement, e.g., 0-RTT, or otherwise it will not work over UDP? Maybe I'm just confused what "work over UDP" means at this point - I would assume it means that UDP is one of the possible choices of transport protocols. But perhaps it means that UDP is the protocol that the transport system can always fall back to, which the draft should make more clear. In fact, is this the same as "implementation over either TCP or UDP is possible" as used in Appendix A.2 paragraph 2 and A.3? Nits: "a TAPS transport system" - sounds redundant to me? Maybe "transport system implementing TAPS"? (Introduction 2. paragraph; Conclusion) "if an application would use them" --> "if an application used them" (Introduction, 3. paragraph) "[…] a sender-side TAPS system implementing it can talk to […]" - What does the "it" refer to here? The TAPS system? If so, can we drop the "implementing it"? "Here, the focus is on connections that the transport system offers, as opposed to connections of transport protocols that the transport system uses." - Maybe the distinction would be even more clear if we specified "on connections that the transport system offers as an abstraction to the application, as opposed to […]"? Best, Theresa From nobody Thu May 17 05:28: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 4FF1012D874 for ; Thu, 17 May 2018 05:28:15 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 zXRRBG0qlfYk for ; Thu, 17 May 2018 05:28:12 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 B3196129515 for ; Thu, 17 May 2018 05:28:12 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fJI0v-0007LL-KP; Thu, 17 May 2018 14:28:09 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.6]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fJI0s-000Foa-JQ; Thu, 17 May 2018 14:28:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <5ee8025e-9737-2fca-b648-3187f135c526@inet.tu-berlin.de> Date: Thu, 17 May 2018 14:27:42 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3D4AA6DB-5850-40EB-9B61-55DA025FE003@ifi.uio.no> References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> <5ee8025e-9737-2fca-b648-3187f135c526@inet.tu-berlin.de> To: Theresa Enghardt X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.6]; X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.102, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EBADE8DE29293662A6C2EAE723095649115E52F2 Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset 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, 17 May 2018 12:28:15 -0000 Hi, Thanks a lot for reading and for your feedback! Answers in line: > On May 17, 2018, at 1:16 PM, Theresa Enghardt = wrote: >=20 > Dear all, >=20 > I have read the draft, including the appendix, and I think it is in = good > shape and can be published. >=20 > However, I stumbled across the following clarification issue: >=20 > In Section 3, it says: "elements of the system that may prohibit > implementation over UDP are marked with "!UDP". To implement a > transport system that can also work over UDP, these marked transport > features should be excluded." > Does this really mean that a transport system should not implement, > e.g., 0-RTT, or otherwise it will not work over UDP? Maybe I'm just > confused what "work over UDP" means at this point - I would assume it > means that UDP is one of the possible choices of transport protocols. Well, it means that 0-RTT excludes UDP. ( This reads odd here because you call it =E2=80=9C0-RTT=E2=80=9D; = that=E2=80=99s why we have the longer phrasing in the draft: =E2=80=9Creli= able transmission before or during connection establishment (!UDP)=E2=80=9D= =3D> it=E2=80=99s about =E2=80=9Creliable=E2=80=9D. ) > But perhaps it means that UDP is the protocol that the transport = system > can always fall back to, which the draft should make more clear. In > fact, is this the same as "implementation over either TCP or UDP is > possible" as used in Appendix A.2 paragraph 2 and A.3? Yes! =E2=80=9Ccan always fall back to=E2=80=9D is what is meant. = We=E2=80=99ll try to phrase this better (specifically, the wording "fall = back=E2=80=9D was eliminated upon request by Tommy Pauly). > Nits: Thanks, we=E2=80=99ll address them! Cheers, Michael From nobody Thu May 17 08:30:22 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 6688B12DA16; Thu, 17 May 2018 08:30:21 -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 7BfcE_3yooK0; Thu, 17 May 2018 08:30:18 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 C941A12EB16; Thu, 17 May 2018 08:30:17 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id g13-v6so6273064qth.8; Thu, 17 May 2018 08:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=uX0a9yk2yp5msJRSJ7u6CEQ1KnR56tysS04hiq0keTo=; b=hquXSgsuyi8oYkeQe/kYcqAOpuFAwsOC5knqfBOg02kBSMbsEe3PKwZ+toOH5GoKHr iTfldlGiTRUHXrvtAf7qhU0jnQJdjjJMJ29dzH1hjpwEO6JCa/D470ctWG9XqMTg96M7 q1WxDmN3uBP2siBRyQq1dsNyk2LbyasHoE8fC1cd1CI4X0NYmZXJl3mJrSdpz12MXyg7 0tZpsDhQJopgsFd5k59lK99NpaSu3++WB83xO5qv73QjqvqzJUHxknk2LnQa+kl0pkCK MFbx1pc97dktT+p2Zz00zX9tEtoPofsx7MIr1kWL4lrlWCIMp3MWbA4CHhfhNiwPTb+w SGoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=uX0a9yk2yp5msJRSJ7u6CEQ1KnR56tysS04hiq0keTo=; b=Tm/gchv+VhH1rJBvCfXtq+2FkFmYIW86tGhjGPda779XoCXjoOkyI2kqwnULGRAeUo lIbKUh+6sMc1BXWNvIns16TkSyPkVK3l1j5a++WUFnMYZzcLG+cu3ZlJM+2YYiLMkrd4 EY7r9q0vqAlMud/3bCS04Df5XbbuTWxJMeeZW1q6y6tcB0Z4rnRDKtHSgeC6EOtkqukn BMsYFv5KSt7Hmvr5tPochHZphNmN3UC0qK+a9M9fS4VvkgvgwzbT7+yTpc5OwFfxlhMT 51Q/uD0mo/18Cd1UoJHdey+pa+FFxGkY9ctsCSBQNVlTsYHAU4zaVmeUhkc9cA6VN3U3 4Zow== X-Gm-Message-State: ALKqPwdt9aE3ABzGFiY+YYwkMq0zxFBwA6Pont1UuTFrXB2keLFxNoaY uDjvncmyI474NgEZ36k84nKvOg1f X-Google-Smtp-Source: AB8JxZqaDPCZh15LLop1QtRNILWkCV5c65gs+Xryxvoq7Zd9rKZyiOf2w9Csf+nmTPQoyNPNrpI+dA== X-Received: by 2002:ac8:167d:: with SMTP id x58-v6mr5839435qtk.152.1526571016551; Thu, 17 May 2018 08:30:16 -0700 (PDT) Received: from [172.19.36.178] ([2001:4878:a000:3000:588:aacc:8856:d946]) by smtp.gmail.com with ESMTPSA id y55-v6sm3893739qtc.56.2018.05.17.08.30.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 May 2018 08:30:15 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Cc: draft-ietf-taps-minset@ietf.org Date: Thu, 17 May 2018 11:30:16 -0400 X-Mailer: MailMate (1.11.2r5479) Message-ID: <3F4C0CD4-9D7A-42AD-9A1D-A19C47321E69@gmail.com> In-Reply-To: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_0FD477ED-AB63-4478-AFF7-907AE5E2B210_=" Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset 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, 17 May 2018 15:30:21 -0000 --=_MailMate_0FD477ED-AB63-4478-AFF7-907AE5E2B210_= Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable I've received a request to extend the WGLC for this doc. We'll accept = comments until June 4th. --aaron On 10 May 2018, at 10:52, Aaron Falk wrote: > Dear TAPS working group, > > As discussed in London, it's time to last call = > [draft-ietf-taps-minset-03](https://tools.ietf.org/html/draft-ietf-taps= -minset-03). > > A Minimal Set of Transport Services for TAPS Systems > draft-ietf-taps-minset-03 > > Abstract > > This draft recommends a minimal set of IETF Transport Services > offered by end systems supporting TAPS, and gives guidance on > choosing among the available mechanisms and protocols. It is = > based > on the set of transport features in RFC 8303. > > > Please read the draft and send comments to the list. This document is = > planned to be an Informational RFC. Statements along the lines of = > 'ready to publish' are also welcome. > > WGLC will conclude in two weeks on May 24, 2018. > > --aaron (for the chairs) --=_MailMate_0FD477ED-AB63-4478-AFF7-907AE5E2B210_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I've received a request to extend the WGLC for this doc. = We'll accept comments until June 4th.

--aaron

On 10 May 2018, at 10:52, Aaron Falk wrote:

Dear TAPS working group,

As discussed in London, it's time to last call draft-ietf-taps-minset-03.

          A Minim=
al Set of Transport Services for TAPS Systems
                       draft-ietf-taps-minset-03

Abstract

   This draft recommends a minimal set of IETF Transport Services
   offered by end systems supporting TAPS, and gives guidance on
   choosing among the available mechanisms and protocols.  It is based
   on the set of transport features in RFC 8303.

Please read the draft and send comments to the list. This= document is planned to be an Informational RFC. Statements along the li= nes of 'ready to publish' are also welcome.

WGLC will conclude in two weeks on May 24, 2018.

--aaron (for the chairs)

--=_MailMate_0FD477ED-AB63-4478-AFF7-907AE5E2B210_=-- From nobody Thu May 17 09:23:34 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 B0323120725 for ; Thu, 17 May 2018 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 QKXuMmv13lFk for ; Thu, 17 May 2018 09:23:24 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 413781271DF for ; Thu, 17 May 2018 09:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1526574203; x=2390487803; 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=kkPor4FU6VlDgScP+5WNeN4lvnZtd6sB/Dc1CQV9NH0=; b=2Yd+69TkAmIlxJ8/IK7rLlWsNAZF0uJGpuUGf6eBM5yLtDObCSN0PxlfZBccgkkt KrTPxP1hK/JTnaNnngzDxm7rowGoewI0gGsoo6Q2DTiQSPUR6vkKbrnHeFEt/fB3 r/v3MaI3JFwe9/8vBSVzbMvKzr/dLLo2zg6rzuBL7CD2Lye1phe52HiRjkemx0ZN G8euK7j3P/1TantXDJq4OXiH1J3+7CBPvdmtGEMsycD8PQ1Uls5XsBkWHZMgf8ER GFqt9FV1a1DM6q2hnaBDBROjBVgIwL+T/lyGrrkUV6ucds3tiV8wNg3Wd6H5q+KY ZAaP1UsJP9DH3Pb3LYCBqw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id C1.44.07147.B7CADFA5; Thu, 17 May 2018 09:23:23 -0700 (PDT) X-AuditID: 11973e12-d46b29e000001beb-51-5afdac7b0336 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 78.B1.11536.B7CADFA5; Thu, 17 May 2018 09:23:23 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.230.167.202] (unknown [17.230.167.202]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P8V0024BS6ZNT40@nwk-mmpp-sz10.apple.com> for taps@ietf.org; Thu, 17 May 2018 09:23:23 -0700 (PDT) Sender: cawood@apple.com From: Chris Wood Content-transfer-encoding: quoted-printable Message-id: <89499603-82CE-4509-9F00-9FA9BD93CB3B@apple.com> Date: Thu, 17 May 2018 09:23:22 -0700 To: taps@ietf.org X-Mailer: Apple Mail (2.3475.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupiluLIzCtJLcpLzFFi42IRbCgM161e8zfKoHumpcWdGAdGjyVLfjIF MEZx2aSk5mSWpRbp2yVwZXy5OomloEez4vuiU0wNjKcUuhg5OSQETCQuf/jH1sXIxSEksJpJ 4vriD8wwiVl9t5kgEhuYJHY+mQ6W4BUQlPgx+R5LFyMHB7OAusSUKbkQNUuZJDbfWsYKUiMs ICHxes9EsHo2AWWJCwcXsoPYzALaEk/eXYCqUZY4dPQPO8RMG4n7LR1MIDaLgKrEtB3vWUBs EaBdW092s0IcJC9xbe52dgj7JKvE3VWMExgFZiE5aRbCSbOQbFvAyLyKUSg3MTNHNzPPRC+x oCAnVS85P3cTIyjwptsJ7WA8tcrqEKMAB6MSD++LiX+jhFgTy4orcw8xSnOwKInzXpjwO0pI ID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDozsDR3mL/WNpgxTDL4dMntrafsrKrn5+jWP2tuts xikJvLPsPh6cHriG4d0J36iJQhOmb5M+mua/+ZLno3ebGLufCz4/bLW+nK1tu7a+Qky7On/D qd1n53lmHtl1/h4bX86lboGZU/ZWXLhjn+Jgddgu8aThn9Vejce/nJ4yQfhg0s5Me8NVGkos xRmJhlrMRcWJABA7wYYdAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHJMWRmVeSWpSXmKPExsUi2FBcpVu95m+UwZx3ZhZ3YhwYPZYs+ckU wBjFZZOSmpNZllqkb5fAlfHl6iSWgh7Niu+LTjE1MJ5S6GLk5JAQMJGY1XebqYuRi0NIYAOT xM4n05lBErwCghI/Jt9j6WLk4GAWUJeYMiUXomYpk8TmW8tYQWqEBSQkXu+ZCFbPJqAsceHg QnYQm1lAW+LJuwtQNcoSh47+YYeYaSNxv6WDCcRmEVCVmLbjPQuILQK0a+vJblaIg+Qlrs3d zj6BkXcWkjNmIZwxC8mGBYzMqxgFilJzEitN9BILCnJS9ZLzczcxgkOlMHwH479lVocYBTgY lXh4X0z8GyXEmlhWXJl7iFGCg1lJhNevEijEm5JYWZValB9fVJqTWnyIUZqDRUmcVyL0T5SQ QHpiSWp2ampBahFMlomDU6qBcVph5Zxuq8Agy+5vfNkrUu5ufPkhNe7F/pplucFxqmIp884z rPjrlO31zLMyJWTPOcYd0pr+zdw2IiH1tj9S8xbO3OZ6/3ePQaHtjNldN3MmcsvGnxRdZ3Jv zdmlz/yfW9dO/vb0Q0fPvb1uRQYZ387ZfPqZ/DmMq1nteuzjOVOef7detpOtQ4mlOCPRUIu5 qDgRAGfDnLsRAgAA Archived-At: Subject: [Taps] TAPS interim meeting notes 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, 17 May 2018 16:23:27 -0000 Hi everyone, Here are notes from yesterday=E2=80=99s call.=20 Best, Chris =E2=80=94=E2=80=94 # TAPS Interim (5/16/2018) ## Participants Aaron Falk / TAPS Working Group Chair=20 Spencer Dawkins / Transport Area Director=20 Philipp S. Tiesel=20 Gorry Fairhurst / UoA=20 Theresa=20 Michael Welzl=20 Brian Trammell=20 Colin Perkins=20 Jonathan Lennox=20 Anna Brunstrom / KAU=20 Tommy Pauly=20 Chris Wood Marie-Jos=C3=A9 Montpetit=20 Kyle Rose=20 Marie-Jos=C3=A9=20 Mirja Kuehlewind ## https://github.com/taps-api/ - https://github.com/taps-api/drafts/issues/35 - Several options: - Specify a registry for enumerated path types and services. In = IANA? Elsewhere? - Alternatively, make registry implementation specific (and punt = the issue) - Both: use "local" registry, and point to IANA one for = guidelines and recommendations. - bitram: against pointing to IANA registry mess - Perhaps consider specifying special PVDs too - https://github.com/taps-api/drafts/issues/37 - Pass - https://github.com/taps-api/drafts/issues/53 - Marking Final on messages allows multiple messages per connection = to be sent, and also maps to TCP FIN nicely - Receivers can check the Final property to see if the connection is = complete - Whether or not setting Final on a Send is reflected on the = recevier is a property of the transport. (TCP handles this nicely, UDP = not so much.) - https://github.com/taps-api/drafts/issues/59 - (Unrelated to #60) - Goal is to have more abstract Intents enforced (?) by the policy = engine - Should survey applications and extract concrete use cases for this = feature - Choosing the right level of abstraction will be challenging - https://github.com/taps-api/drafts/issues/60 - Which parameters should be standardized? Still unclear. Half may = be duped to #59. - Propose moving discussion to #59 and closing. - https://github.com/taps-api/drafts/issues/102 - Cannot depend on DPRIVE or correctness of name resolution. - Application should control when resolution occurs, probably before = connections start (during preconnection). - Why do applications want to know about the time of resolution? - Applications might want specific behavior during pre-connect = and connect stages, e.g., to permit resolution across one interface over = another - Want to balance latency and privacy considerations - Should make privacy-respecting resolution strategies the default, = and allow applications to opt in to aggressive (privacy unfriendly) = strategies - Earliest time for resolution is during system setup, e.g., if = system has a cache of domains previously queried in the past - Side bar: missing a Privacy Considerations section in all three = drafts: https://github.com/taps-api/drafts/issues/177 - Should these be scattered or colocated? Not all documents are = reviewed at the same time. - https://github.com/taps-api/drafts/issues/112 - Deferred to in-person discussion - Issue: how does one offer early data support in the API - (See issue for proposals) - Apple: Send/enqueue as much idempotent data before calling = Start(), and let the protocol configuration(s) and implementation(s) = figure out if it can be sent as early data or not - What about receiver side distinguishing between early data and = not? - https://github.com/taps-api/drafts/issues/179 - https://github.com/taps-api/drafts/issues/147 - No response from Mark Handley yet - Will decompose the issue into specific API points to consider - https://github.com/taps-api/drafts/issues/153 - Ready for text - https://github.com/taps-api/drafts/issues/160 - Per-context threads are needed for servers supporting many = simultaneous connections - Applications should be able to tune the number of contexts, and = number of threads per context (perhaps bound to number of available = cores) - One thread per socket is probably best practice - Teardown events should be generated locally, not from remote = events (RST) - Need implementation text (from Tom) before closing - https://github.com/taps-api/drafts/issues/170 - Do we have a solid use case for this? - Could bring back Source and Sink for multicast, or allow RO or WO = properties for connections ## https://github.com/mami-project/draft-pauly-transport-security - Changes from 00 - Rewrite section 4 to better articular mandatory vs optional = features, and their transport and application dependencies (PR #27) - Add text to protocol descriptions=20 - Started security review, still awaiting feedback - Outstanding issues: - Protocol descriptions need more text (WIP) - Selection rationale: = https://github.com/mami-project/draft-pauly-transport-security/issues/29 - ... "we chose because it represents the superset of all = interesting security features the TAPS API needs to express" ... ## WG issues - minset is in WGLC -- please read and provide comments - Will push out one week to allow for more reviews =20= From nobody Thu May 17 13:38:41 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 14A19126BF3 for ; Thu, 17 May 2018 13:38:41 -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 WSnXfDXcrvAe for ; Thu, 17 May 2018 13:38:38 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 BE98F1241FC for ; Thu, 17 May 2018 13:38:38 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g16-v6so1749504ywk.0 for ; Thu, 17 May 2018 13:38:38 -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=wS86h7/xxhC9w/kdqAtwVzJgVCHQ/WdmbXtC/yScH0I=; b=Lu6h8LS2Pzfh+9p24J5ISmyodXv1fgtOCx++b+5Bcu0V3GcrPF4EaV4mVK2E20mEhm aOpuT5u2rBJ+pNxJHd9+O4/Nrx7mlYQqijdGOMcarG6iVJv672yu9c8Gkmv9O8UskUwZ n8vrfc7EK34VHSG/dV1EyPjcHHwdeCzIlIxWXkQ79fcNk+yildBaXOFwOFgcC0bpDkTd z1xyPppOaQ7QNHQLMzLThhqGgUJA7Bv9RhRMfeUcv5rsa8Ng3WY2oT+P1tdDpNlui5YY tj6kOdsjgEtxJvbVuwPOdD+LAhbGDrSokYRGZldDyQfGEKTUnW1WSscy1n+UmfanFCCm nt4A== 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=wS86h7/xxhC9w/kdqAtwVzJgVCHQ/WdmbXtC/yScH0I=; b=QKXQVbBTIRm7xsty/haGFhmtx6wLqBc0EO8s/a3aCn7MBwmGJD/9uRGie+xza4ETUI X0P82lmHcaAWknG4/3smOlBOAxxQa2KJYz50lb1kiVgCdIYN4Zfvquf4muqotmBhVYWQ 9K887UUh+htMn6D6PLz4vraAaxOGCYcn9rk1RyS9ZOLWGwwZJ6VtQybYeQ+YgfOC8gH/ gaEbCrjtIIcnr5c5h6PwAec7bxEtrHfI593Js74EgCAAESi1bB/Nh/e6IkkJD4LvQ34M Ny9gF8m6d0pA5zARtBVNCrWb93PddrAylFDzak0IV6gr6+sZ51OkUg8toKcmSBl5xCNS uq4A== X-Gm-Message-State: ALKqPwekvfzQO/Fq+lyQRuuzBdxsOEnrsQdy+E19+iiwq5K4+14CwGl/ D92lcj5r58UhKJnlPbQIc5iGRXTfMyyVWmBQ/pLG6A== X-Google-Smtp-Source: AB8JxZqJLz0rlu3AxgIAzvk0iZJkOt/u5/sQ6ErcKypoYqdEHjbPCeo4ghR1faxEi5dw21jvMTaJQWiN33lgscIIQuM= X-Received: by 2002:a81:9a8f:: with SMTP id r137-v6mr3442094ywg.119.1526589517614; Thu, 17 May 2018 13:38:37 -0700 (PDT) MIME-Version: 1.0 References: <5AFD24BF.8000608@erg.abdn.ac.uk> In-Reply-To: <5AFD24BF.8000608@erg.abdn.ac.uk> From: Christopher Wood Date: Thu, 17 May 2018 13:38:25 -0700 Message-ID: To: gorry@erg.abdn.ac.uk Cc: taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Some editorial comments from a read through of draft-ietf-taps-transport-security-01 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, 17 May 2018 20:38:41 -0000 Thanks, Gorry! Please see inline below. Best, Chris On Wed, May 16, 2018 at 11:44 PM Gorry Fairhurst wrote: > =E2=80=9CTCP-AO adds authenticity=E2=80=9D > - should this be =E2=80=9CTCP-AO adds authentication=E2=80=9D our an auth= entication service? > =E2=80=9CAH adds per-datagram authenticity=E2=80=9D > - should this also be =E2=80=9Cauthentication=E2=80=9D. I think the current text is more correct. If anyone else feels strongly about this, we can change it. > - - - > Section 3: > =E2=80=9C This section contains descriptions of security protocols that > currently used to protect data being sent over a network.=E2=80=9D > - is this /are currently used/. Yes, will fix. > - - - > =E2=80=9CAEAD=E2=80=9D > - please define when first used Will do. > - - - > Section 3.2.1. > =E2=80=9C DTLS is modified from TLS to account for packet loss, reorderin= g, and > duplication that may occur when operating over UDP.=E2=80=9D > - to account for doesn=E2=80=99t quite explain that these things happen a= nd this > can work with them, first time I read I wondered whether this implied > some features to retransmit etc. > Is it clearer to say something like: > =E2=80=9C DTLS is modified from TLS to operate with the possibility of pa= cket loss, > reordering, and > duplication that may occur when operating over UDP. > - - - I'm comfortable with this new text Thanks for the proposal! > Similarly making this change is maybe(?) clearer: > =E2=80=9CSince datagrams may be replayed, =E2=80=9C > to > =E2=80=9CSince datagrams can be replayed, =E2=80=9C > - - - Agreed. > Section 3.2.3 > States a dependency on PMTU discovery. I think this dependency is on > choosing a datgarm size (which is true of any UDP usage - section 3.2 of > RFC8085). > =E2=80=94 > Section 3.3 omits a reference to IETF QUIC. Good catch. I'll add one! > - - - > Section 3.3.3, > QUIC also in the same way relies on a PMTU. (as in DTLS). > - in the same vein, I think gQUIC has chosen a fixed datgram size. > - - - > Section 3.4.1.2 > =E2=80=9CESP Security Associations=E2=80=9D > - I think you need to define SA here? Will do. > - - - > [RFC3545] - appears as text, rather than a reference. Will fix. > - - - > Section 3.5.2 > =E2=80=9C(RFC5763) Mandatory mutually authenticated key exchange.=E2=80= =9D > - The brackets around the reference appear unusual. > - - - > Section 3.8.1 > =E2=80=9CThese keys are used=E2=80=9D > - The word /these/ reads odd, maybe: > - =E2=80=9CThe keys are used=E2=80=9D > - - - > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu May 17 13:39: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 609AB1270B4 for ; Thu, 17 May 2018 13:39: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 Y_M5YbisSATZ for ; Thu, 17 May 2018 13:39:12 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::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 7B9221241FC for ; Thu, 17 May 2018 13:39:04 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id i17-v6so1738145ywg.13 for ; Thu, 17 May 2018 13:39:04 -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=B8RbdXfW8Iu3BHoQtzuhSCV0TQ1bGihe8Rmw3SWk2Bs=; b=bhQ3bhNKkeTQ2EyrZIHrE5jKH8sG4Xgij4cPf/jHrk3t9cQhge/yFFVHngI0oZUxFh DgJQr7xuUlLBAAg36Vd/J/y+hzL7b2IVvnXHS/47HaT49HJbUo02epNMFawQNb0T9cQj ti5pBXIgquIpfDiMZp+/PTKrS3XwnFCZhPb8Umd/E922BqQAOIUT8fC0lXcjNTB9lpWL 9g1YfeiwFm05QDf896it+ZCRiwBHfewX+Wu0NskQpTpwSgUtpQh/YObl2eT0lneObu1u NTnAksMWv3nNXlkjBn0CKvRiU48NzMOdJqR3Du/3dMhVAM2iRUsu9e4r6PprC/kH/E1U O7ZA== 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=B8RbdXfW8Iu3BHoQtzuhSCV0TQ1bGihe8Rmw3SWk2Bs=; b=cHVRfQQnaQvG+Ey4rcXPoeZz4b+jy9e5Jn6M4D/UYSTQCcouivMDm3mRMU/cHI1pFd kpyZtZsWF2TYxZ6MAywJ83a9+HBtKNw7O8dI7Iz8Q6QhhjXUR2Or1jZ7ue7y4GATKTfE 7UVWRx0uzF5gbQc//8sfBzYGN+Jb1QH2QvgnLUbkANI28XNYXln3iWBqjgvaDwzI4NnA fRSI8+wU3XpQJ+HQ/XFuGPDWzLK+bG3/1LBXEWuLrNB5/75mjf3Zu0NANyNbdXtySFvI +FIW0ziaIVmQaGKyBidekUyPyH+sKsVSF8A5+QQXcF5mzk0jLf6j4SWLIvPE7XtRZn8k EPCw== X-Gm-Message-State: ALKqPwfriFyodfYhyxnIP/d3b6PTNenLbJFliy7eXOeJ0cKWu5qF3FPm omZTZEiZm3HfETWuFcWxI0C9jVzaoWUwiyL+OFM= X-Google-Smtp-Source: AB8JxZpcGzqShrXgF86qdnwjDICHlnJNASLAC43RWV9vE4cDoRd0vj7SSQpK4pG3+3z+edqKjaTeLv0p3wY/z+Sde8s= X-Received: by 2002:a81:ad1c:: with SMTP id l28-v6mr3437691ywh.57.1526589543602; Thu, 17 May 2018 13:39:03 -0700 (PDT) MIME-Version: 1.0 References: <5AFD24BF.8000608@erg.abdn.ac.uk> In-Reply-To: From: Christopher Wood Date: Thu, 17 May 2018 13:38:52 -0700 Message-ID: To: gorry@erg.abdn.ac.uk Cc: taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Some editorial comments from a read through of draft-ietf-taps-transport-security-01 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, 17 May 2018 20:39:15 -0000 Also, I filed this issue to track addressing your comments: https://github.com/mami-project/draft-pauly-transport-security/issues/30 Best, Chris On Thu, May 17, 2018 at 1:38 PM Christopher Wood < christopherwood07@gmail.com> wrote: > Thanks, Gorry! Please see inline below. > Best, > Chris > On Wed, May 16, 2018 at 11:44 PM Gorry Fairhurst > wrote: > > =E2=80=9CTCP-AO adds authenticity=E2=80=9D > > - should this be =E2=80=9CTCP-AO adds authentication=E2=80=9D our an au= thentication > service? > > =E2=80=9CAH adds per-datagram authenticity=E2=80=9D > > - should this also be =E2=80=9Cauthentication=E2=80=9D. > I think the current text is more correct. If anyone else feels strongly > about this, we can change it. > > - - - > > Section 3: > > =E2=80=9C This section contains descriptions of security protocols that > > currently used to protect data being sent over a network.=E2=80=9D > > - is this /are currently used/. > Yes, will fix. > > - - - > > =E2=80=9CAEAD=E2=80=9D > > - please define when first used > Will do. > > - - - > > Section 3.2.1. > > =E2=80=9C DTLS is modified from TLS to account for packet loss, reorder= ing, and > > duplication that may occur when operating over UDP.=E2=80=9D > > - to account for doesn=E2=80=99t quite explain that these things happen= and this > > can work with them, first time I read I wondered whether this implied > > some features to retransmit etc. > > Is it clearer to say something like: > > =E2=80=9C DTLS is modified from TLS to operate with the possibility of = packet > loss, > > reordering, and > > duplication that may occur when operating over UDP. > > - - - > I'm comfortable with this new text Thanks for the proposal! > > Similarly making this change is maybe(?) clearer: > > =E2=80=9CSince datagrams may be replayed, =E2=80=9C > > to > > =E2=80=9CSince datagrams can be replayed, =E2=80=9C > > - - - > Agreed. > > Section 3.2.3 > > States a dependency on PMTU discovery. I think this dependency is on > > choosing a datgarm size (which is true of any UDP usage - section 3.2 o= f > > RFC8085). > > =E2=80=94 > > Section 3.3 omits a reference to IETF QUIC. > Good catch. I'll add one! > > - - - > > Section 3.3.3, > > QUIC also in the same way relies on a PMTU. (as in DTLS). > > - in the same vein, I think gQUIC has chosen a fixed datgram size. > > - - - > > Section 3.4.1.2 > > =E2=80=9CESP Security Associations=E2=80=9D > > - I think you need to define SA here? > Will do. > > - - - > > [RFC3545] - appears as text, rather than a reference. > Will fix. > > - - - > > Section 3.5.2 > > =E2=80=9C(RFC5763) Mandatory mutually authenticated key exchange.=E2=80= =9D > > - The brackets around the reference appear unusual. > > - - - > > Section 3.8.1 > > =E2=80=9CThese keys are used=E2=80=9D > > - The word /these/ reads odd, maybe: > > - =E2=80=9CThe keys are used=E2=80=9D > > - - - > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps From nobody Thu May 17 13:52:02 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 37BAB127419 for ; Thu, 17 May 2018 13:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, 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 P_7QGbId7rQ0 for ; Thu, 17 May 2018 13:51:57 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 1D46E1270B4 for ; Thu, 17 May 2018 13:51:57 -0700 (PDT) Received: from [192.168.0.11] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 57FED1B001FE; Thu, 17 May 2018 21:51:53 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Thu, 17 May 2018 21:51:52 +0100 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <965D7BCE-24AB-4509-86F8-5D41923130EA@erg.abdn.ac.uk> References: <5AFD24BF.8000608@erg.abdn.ac.uk> To: Christopher Wood Archived-At: Subject: Re: [Taps] Some editorial comments from a read through of draft-ietf-taps-transport-security-01 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, 17 May 2018 20:52:00 -0000 Great, Gorry=20 > On 17 May 2018, at 21:38, Christopher Wood w= rote: >=20 > Also, I filed this issue to track addressing your comments: > https://github.com/mami-project/draft-pauly-transport-security/issues/30 >=20 > Best, > Chris > On Thu, May 17, 2018 at 1:38 PM Christopher Wood < > christopherwood07@gmail.com> wrote: >=20 >> Thanks, Gorry! Please see inline below. >=20 >> Best, >> Chris >=20 >> On Wed, May 16, 2018 at 11:44 PM Gorry Fairhurst >> wrote: >=20 >>> =E2=80=9CTCP-AO adds authenticity=E2=80=9D >>> - should this be =E2=80=9CTCP-AO adds authentication=E2=80=9D our an aut= hentication >> service? >=20 >>> =E2=80=9CAH adds per-datagram authenticity=E2=80=9D >>> - should this also be =E2=80=9Cauthentication=E2=80=9D. >=20 >> I think the current text is more correct. If anyone else feels strongly >> about this, we can change it. >=20 >>> - - - >>> Section 3: >>> =E2=80=9C This section contains descriptions of security protocols that >>> currently used to protect data being sent over a network.=E2=80=9D >>> - is this /are currently used/. >=20 >> Yes, will fix. >=20 >>> - - - >>> =E2=80=9CAEAD=E2=80=9D >>> - please define when first used >=20 >> Will do. >=20 >>> - - - >>> Section 3.2.1. >>> =E2=80=9C DTLS is modified from TLS to account for packet loss, reorderi= ng, and >>> duplication that may occur when operating over UDP.=E2=80=9D >>> - to account for doesn=E2=80=99t quite explain that these things happen a= nd this >>> can work with them, first time I read I wondered whether this implied >>> some features to retransmit etc. >>> Is it clearer to say something like: >>> =E2=80=9C DTLS is modified from TLS to operate with the possibility of p= acket >> loss, >>> reordering, and >>> duplication that may occur when operating over UDP. >>> - - - >=20 >> I'm comfortable with this new text Thanks for the proposal! >=20 >>> Similarly making this change is maybe(?) clearer: >>> =E2=80=9CSince datagrams may be replayed, =E2=80=9C >>> to >>> =E2=80=9CSince datagrams can be replayed, =E2=80=9C >>> - - - >=20 >> Agreed. >=20 >>> Section 3.2.3 >>> States a dependency on PMTU discovery. I think this dependency is on >>> choosing a datgarm size (which is true of any UDP usage - section 3.2 of= >>> RFC8085). >>> =E2=80=94 >>> Section 3.3 omits a reference to IETF QUIC. >=20 >> Good catch. I'll add one! >=20 >>> - - - >>> Section 3.3.3, >>> QUIC also in the same way relies on a PMTU. (as in DTLS). >>> - in the same vein, I think gQUIC has chosen a fixed datgram size. >>> - - - >>> Section 3.4.1.2 >>> =E2=80=9CESP Security Associations=E2=80=9D >>> - I think you need to define SA here? >=20 >> Will do. >=20 >>> - - - >>> [RFC3545] - appears as text, rather than a reference. >=20 >> Will fix. >=20 >>> - - - >>> Section 3.5.2 >>> =E2=80=9C(RFC5763) Mandatory mutually authenticated key exchange.=E2=80=9D= >>> - The brackets around the reference appear unusual. >>> - - - >>> Section 3.8.1 >>> =E2=80=9CThese keys are used=E2=80=9D >>> - The word /these/ reads odd, maybe: >>> - =E2=80=9CThe keys are used=E2=80=9D >>> - - - >=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps From nobody Mon May 21 01:41: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 9BF0112E87D for ; Mon, 21 May 2018 01:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kFyRePm7-0tv for ; Mon, 21 May 2018 01:41:23 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 B3E3612E878 for ; Mon, 21 May 2018 01:41:23 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fKgNd-0004ZX-3z for taps@ietf.org; Mon, 21 May 2018 10:41:21 +0200 Received: from 197.red-217-126-10.staticip.rima-tde.net ([217.126.10.197] helo=[172.26.0.138]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fKgNa-000B0H-OF for taps@ietf.org; Mon, 21 May 2018 10:41:20 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <07299EC9-1130-447A-A85B-1FBA39C6CBB0@ifi.uio.no> Date: Mon, 21 May 2018 10:41:13 +0200 To: "taps@ietf.org" X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 217.126.10.197 is neither permitted nor denied by domain of ifi.uio.no) client-ip=217.126.10.197; envelope-from=michawe@ifi.uio.no; helo=[172.26.0.138]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 63A7D6B0B0A3D6031F7E089E134F648F10D4AA6F Archived-At: Subject: [Taps] Comments on draft-ietf-taps-transport-security-01 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, 21 May 2018 08:41:28 -0000 Hi, As promised, I have read this update now. Overall, this is certainly a = useful (and, for me, educational! Thanks :) ) document - a good starting = point, yet in my opinion it still needs some work. My apologies for saying these things so late: I have read previous = iterations of this document, but somehow the bigger issues below have = never stood out to me as clearly as they do now. Sorry! Here are my comments: The main problem that I see is a missing "red thread=E2=80=9D - e.g. = when deriving the security features in section 4: as a reader, I would = expect there to be a 1:1 mapping from the protocol features in section 3 = to the security features in section 4, yet there isn=E2=80=99t. For = example: sec. 3.10, CurveCP, has, in sec. 3.10.2, protocol features such = as =E2=80=9C1-RTT session bootstrapping=E2=80=9D and =E2=80=9CSender-chose= n explicit nonces, =E2=80=A6=E2=80=9D, and these are not listed in = section 4 as such. I guess this is okay because =E2=80=9CProtocol = features=E2=80=9D are internal details, not exposed to an application? = But then this should be made clear in section 3, and the security = features that we see listed in section 4 should be listed in sec. 3 per = protocol with the same wording so that we can see a connection from = section 3 to section 4. Similarly, what is the rationale for making some features mandatory and = some optional in section 4? Reasons for this choice should be explicitly = laid out at the beginning of section 4. Maybe the reason can be derived = from section 5=E2=80=A6 see below: Once you=E2=80=99ve laid out the =E2=80=9Cinterface=E2=80=9D (I=E2=80=99ll= come to that) as you do in section 5, just from looking at this list, = it=E2=80=99s easy to see that TLS gives us everything except: - Authentication Delegation - Explicit (as opposed to =E2=80=9Cdirect=E2=80=9D) pre-shared key = import - Transport mobility =E2=80=A6 and none of these are mandatory according to section 4 (so = maybe that could be seen as a reason to not make them mandatory?). TLS = could be a general recommendation, combined with an explanation that, if = you want one of these things listed above, you need to implement a = protocol other than TLS, but then you need to be aware of the protocol = dependencies that such a protocol choice brings with it. Generally, as an implementer of a transport system, this document now = tells me quite clearly which features I must offer (and it tells me = which protocols I then must support). However, the trade-offs are not so = clear. I see trade-offs in the protocol dependencies that you list in = section 3; then there are Transport Dependencies listed in section 4, = but only for the optional features, and it says =E2=80=9CNone=E2=80=9D = almost everywhere=E2=80=A6 yet, in section 3, there are tons of = =E2=80=9CProtocol Dependencies=E2=80=9D, so I find this surprising. Another missing =E2=80=9Cred thread=E2=80=9D: why do the transport = features have different names in sections 4 and 5? I would expect to = find =E2=80=9CTransport mobility=E2=80=9D in section 4, but there it=E2=80= =99s =E2=80=9CConnection mobility=E2=80=9D. Similarly, I=E2=80=99d = expect to find =E2=80=9CSession cache management=E2=80=9D (from sec. = 5.1) in section 4, but there it=E2=80=99s called =E2=80=9CSession = caching and management=E2=80=9D. I think the whole document would look = much more uniform and better structured with some clearer mappings - = from section 3 to the listed security features in section 4 and the = =E2=80=9Cinterfaces=E2=80=9D in section 5. This brings me to the next issue: I think there=E2=80=99s a terminology = problem with this document. The terminology section, in line with all = other TAPS documents, mentions =E2=80=9Cconfidentiality=E2=80=9D as an = example of a =E2=80=9CTransport Feature=E2=80=9D. Further down, = =E2=80=9CSecurity Feature=E2=80=9D is introduced. Given the description = of Transport Feature, a Security Feature is a special case of a = Transport Feature. Maybe the first sentence of the Security Feature = definition could be changed to say =E2=80=9CA Transport Feature that a = network security layer provides to applications.=E2=80=9D Section 3 = then talks about =E2=80=9CProtocol features=E2=80=9D; these are maybe = not offered to applications, so I think it=E2=80=99s fine to use this = term, but you should also define it in the Terminology section. Then, = Section 5 talks about Transport Security Protocol Interfaces - but that = term isn=E2=80=99t defined anywhere. I think these =E2=80=9Cinterfaces=E2=80= =9D are really Security Features, no? Actually, given that they seem to = be the same but with slightly different wording, I wonder if sections 4 = and 5 could be merged =E2=80=A6 or maybe they should be switched in = order: section 5 should appear first, calling them Security Features, = and then what is now Section 4 could come after, deriving which ones of = them are mandatory and optional, as well as list transport / application = dependencies. Some smaller things / nits: I find it strange that this draft cites only RFC 8095 but no other TAPS = documents. In particular, because it complements draft-ietf-taps-minset in the = process of TAPS, I think it should reference back to it. (The minset draft says that it doesn=E2=80=99t discuss security because = this is covered in draft-ietf-taps-transport-security, but then = draft-ietf-taps-transport-security only says that it complements RFC = 8095 - this gives readers following the link from minset a confusing = context). Section 3.2.3: Path MTU Discovery surprised me here. What does that = mean? That DTLS relies on an application implementing PMTUD (as it=E2=80=99= s over UDP), and then telling DTLS about it? Doesn=E2=80=99t DTLS do = this on its own? Why not? Sorry for asking a DTLS question, surely = it=E2=80=99s me=E2=80=A6 but just listing PMTUD as a dependency isn=E2=80=99= t a good enough explanation, I think. sec. 3.3: when I first read =E2=80=9CA mapping for QUIC over TLS 1.3 has = been specified to provide this handshake=E2=80=9D, I was surprised. I = mean, given that TLS runs over TCP, this sentence sounds like something = really doesn=E2=80=99t match here. Only in sec. 3.3.3 you explain =E2=80=9C= TLS within QUIC relies on a reliable stream abstraction for its = handshake=E2=80=9D. Well that=E2=80=99s what I thought, but then this = should probably be brought earlier - =E2=80=9Cmapping for QUIC over TLS = 1.3=E2=80=9D just sounds like QUIC uses TLS, which uses TCP, which is of = course wrong. Maybe it=E2=80=99s just the word =E2=80=9Cover=E2=80=9D - = using =E2=80=9Cwith=E2=80=9D instead would already make this clearer. sec. 3 sentence 1: =E2=80=9C=E2=80=A6security protocols that _are_ currently used to =E2=80=A6= =E2=80=9D sec 3.3.1 1st sentence after bullet list: =E2=80=9CThe QUIC transport layer support_S_ multiple streams=E2=80=A6=E2=80= =9D Same para, 3rd sentence: =E2=80=9CThe TLS handshake, along with further = records, are sent over this stream.=E2=80=9D - did you mean to say = =E2=80=9CThe TLS handshake messages=E2=80=9D ? sec 3.4, line 2: =E2=80=9Ceither as for creating tunnels (tunnel-mode)=E2=80=9D - I = think the =E2=80=9Cas=E2=80=9D should be removed here? penultimate sentence of sec. 3.5.1: =E2=80=9C=E2=80=A6DTLS-offered certificates match that which are offered = over SIP=E2=80=9D - is =E2=80=9Cthat=E2=80=9D correct here? (should it = be =E2=80=9Cthe ones=E2=80=9D or something like that?) 3.10.1 par 5: This begins with =E2=80=9CUnlike TCP, =E2=80=A6=E2=80=9D - isn=E2=80=99t = this strange to say, for being too obvious? Or did you mean to say = tcpcrypt? Well actually even TCP has cookies for some form of =E2=80=9Csource = validation=E2=80=9D, with TFO. Of course that=E2=80=99s a limited use, = but =E2=80=A6 maybe simply removing =E2=80=9CUnlike TCP=E2=80=9D here = would make this clearer. 4.2, =E2=80=9CMutual authentication=E2=80=9D and =E2=80=9CSource = validation=E2=80=9D: the sentence describing these features says = =E2=80=9Cmust=E2=80=9D, yet it=E2=80=99s in the section of optional = features. While this doesn=E2=80=99t really matter, it makes for a = slightly surprising read, and would IMO be better as a factual statement = - e.g. =E2=80=9CTransport security protocols allow each endpoint to = authenticate the other =E2=80=A6=E2=80=9D and =E2=80=9CSource = validation is provided to mitigate =E2=80=A6=E2=80=9D Sec 5.1.: missing line break after: - Session Cache Management - Connection Termination - Pre-Shared Key Export =E2=80=A6 and before =E2=80=9CProtocols=E2=80=9D in the =E2=80=9CIdentity = Validation=E2=80=9D item. That=E2=80=99s it - I hope this is helpful! Cheers, Michael From nobody Tue May 22 11:13:23 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 3717F129C6C for ; Tue, 22 May 2018 11:13:22 -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 6AhSIhNNCjQJ for ; Tue, 22 May 2018 11:13:19 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 8C30612AAB6 for ; Tue, 22 May 2018 11:13:19 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id h11-v6so5062386ywc.8 for ; Tue, 22 May 2018 11:13:19 -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=hhuiV+kzqChAHCkQb5ijSnsF5PLbHQsiT07e6NWIckY=; b=lb3X6t20rfsI3HhYYJBbat/XYI9qJA8RIEs64i0LgoptKS/tnOz2TnQKhc2siynOqO Xi0b5Oz7Zwiun5J2W7yesp462ag+QsFkg3GP0AXnfGHyf7vHdWoLiawyRxKXKD7qdwYQ 0UC9iP/4o/5ntXN3S+DE2oA0gtc3k6NlEGnTQ6EhqtEHj+xdW0LzDxrCJveWN8J219g7 7dKDFH9beEh0+8JTF0w2ju6MmxHv6U0NMyTenrjvLtYH+asQLo5BFXTZ+4B1FBJ12Bi1 a39MRXa/hCWp/gFZxTORHsdAGWsxcEcogs4iMwP+BAba+uCDmEaY0qARr4QLn+ybyu/q Frig== 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=hhuiV+kzqChAHCkQb5ijSnsF5PLbHQsiT07e6NWIckY=; b=UqKPJLlP6NEQ8Gp74bgx96LKT59Ta9dnrBEEbQp/7AK4SY5nfmMpYnXXTplNGue9ol cWkyuieVK6FsHcl0SHykb2NBeLi8sCpEoJt0gIxm+KYFdG1uk2iMQcwOGHoodK4eTv70 OnhN1W/qVVcg3oESOInNTUqjJY46MDRQavffGgVyOZ486Ky7rg7n5mVMRCCfQv6RIftG KEYNE9YrJm0/8wPEyQVbmWbPFNDKMQlA7VVUlTAJ0BRTHECb5x5CZnykoduyOLZUuRsS izSzqzW7jjw7RMGCaeLnADLyXzfCibAPgQ0c37wOIHi9AkD6ey1fp4LP+eKBKQUXCseR 6MfQ== X-Gm-Message-State: ALKqPwfNTKoU7PajnduVSvQT1nIxxB5/YfHmveHpUJ94rGxU2nPSSnWk EpT3gkpH9Pn7vnLw6DXKILz08LN2El11BbnI8a8= X-Google-Smtp-Source: AB8JxZpVjAQ1JaBACvPdXQPVMI7Rw7qm4+de6qhOKor0sGxjYnis47EJS0gFSXqyrrkxCDspoXGFPQsxI5EoFciMYXU= X-Received: by 2002:a81:9a8f:: with SMTP id r137-v6mr80123ywg.119.1527012798342; Tue, 22 May 2018 11:13:18 -0700 (PDT) MIME-Version: 1.0 References: <07299EC9-1130-447A-A85B-1FBA39C6CBB0@ifi.uio.no> In-Reply-To: <07299EC9-1130-447A-A85B-1FBA39C6CBB0@ifi.uio.no> From: Christopher Wood Date: Tue, 22 May 2018 11:13:06 -0700 Message-ID: To: Michael Welzl Cc: taps WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] Comments on draft-ietf-taps-transport-security-01 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, 22 May 2018 18:13:22 -0000 Hi Michael, Many thanks for reading the document and taking time to provide comments! They are greatly appreciated. I've filed #33 ( https://github.com/mami-project/draft-pauly-transport-security/issues/33) to address them. Please see inline below for responses. Best, Chris > The main problem that I see is a missing "red thread=E2=80=9D - e.g. when deriving the security features in section 4: as a reader, I would expect there to be a 1:1 mapping from the protocol features in section 3 to the security features in section 4, yet there isn=E2=80=99t. For example: sec. = 3.10, CurveCP, has, in sec. 3.10.2, protocol features such as =E2=80=9C1-RTT sess= ion bootstrapping=E2=80=9D and =E2=80=9CSender-chosen explicit nonces, =E2=80= =A6=E2=80=9D, and these are not listed in section 4 as such. I guess this is okay because =E2=80=9CProtocol features=E2=80=9D are internal details, not exposed to an application? But = then this should be made clear in section 3, and the security features that we see listed in section 4 should be listed in sec. 3 per protocol with the same wording so that we can see a connection from section 3 to section 4. Excellent point. Tying the two together will go a long way in making selection for mandatory and optional protocol features more clear. > Similarly, what is the rationale for making some features mandatory and some optional in section 4? Reasons for this choice should be explicitly laid out at the beginning of section 4. In general, our rationale for mandatory features is that they were offered by most popular protocols and are "critical" for the security protocol to operate correctly. Optional features are those protocols can work around. > Maybe the reason can be derived from section 5=E2=80=A6 see below: > Once you=E2=80=99ve laid out the =E2=80=9Cinterface=E2=80=9D (I=E2=80=99l= l come to that) as you do in section 5, just from looking at this list, it=E2=80=99s easy to see that TL= S gives us everything except: > - Authentication Delegation > - Explicit (as opposed to =E2=80=9Cdirect=E2=80=9D) pre-shared key import > - Transport mobility > =E2=80=A6 and none of these are mandatory according to section 4 (so mayb= e that could be seen as a reason to not make them mandatory?). TLS could be a general recommendation, combined with an explanation that, if you want one of these things listed above, you need to implement a protocol other than TLS, but then you need to be aware of the protocol dependencies that such a protocol choice brings with it. > Generally, as an implementer of a transport system, this document now tells me quite clearly which features I must offer (and it tells me which protocols I then must support). However, the trade-offs are not so clear. I see trade-offs in the protocol dependencies that you list in section 3; then there are Transport Dependencies listed in section 4, but only for the optional features, and it says =E2=80=9CNone=E2=80=9D almost everywhere=E2= =80=A6 yet, in section 3, there are tons of =E2=80=9CProtocol Dependencies=E2=80=9D, so I find this s= urprising. Indeed. These sections fell out of sync. I'll fix that. > Another missing =E2=80=9Cred thread=E2=80=9D: why do the transport featur= es have different names in sections 4 and 5? I would expect to find =E2=80=9CTransp= ort mobility=E2=80=9D in section 4, but there it=E2=80=99s =E2=80=9CConnection = mobility=E2=80=9D. Similarly, I=E2=80=99d expect to find =E2=80=9CSession cache management=E2=80=9D (from= sec. 5.1) in section 4, but there it=E2=80=99s called =E2=80=9CSession caching and management=E2=80= =9D. I think the whole document would look much more uniform and better structured with some clearer mappings - from section 3 to the listed security features in section 4 and the =E2=80=9Cinterfaces=E2=80=9D in section 5. This is a simple oversight. In addressing your first comment, I'll make we unify the terminology too. > This brings me to the next issue: I think there=E2=80=99s a terminology p= roblem with this document. The terminology section, in line with all other TAPS documents, mentions =E2=80=9Cconfidentiality=E2=80=9D as an example of a = =E2=80=9CTransport Feature=E2=80=9D. Further down, =E2=80=9CSecurity Feature=E2=80=9D is intro= duced. Given the description of Transport Feature, a Security Feature is a special case of a Transport Feature. Maybe the first sentence of the Security Feature definition could be changed to say =E2=80=9CA Transport Feature that a netw= ork security layer provides to applications.=E2=80=9D Section 3 then talks abo= ut =E2=80=9CProtocol features=E2=80=9D; these are maybe not offered to applica= tions, so I think it=E2=80=99s fine to use this term, but you should also define it in = the Terminology section. Then, Section 5 talks about Transport Security Protocol Interfaces - but that term isn=E2=80=99t defined anywhere. I think= these =E2=80=9Cinterfaces=E2=80=9D are really Security Features, no? Not quite. They're interfaces to the security protocols. Those interfaces may of course drive or control certain features. > Actually, given that they seem to be the same but with slightly different wording, I wonder if sections 4 and 5 could be merged =E2=80=A6 or maybe th= ey should be switched in order: section 5 should appear first, calling them Security Features, and then what is now Section 4 could come after, deriving which ones of them are mandatory and optional, as well as list transport / application dependencies. Interesting suggestion. I'll see if that can be done. > Some smaller things / nits: > I find it strange that this draft cites only RFC 8095 but no other TAPS documents. > In particular, because it complements draft-ietf-taps-minset in the process of TAPS, I think it should reference back to it. > (The minset draft says that it doesn=E2=80=99t discuss security because t= his is covered in draft-ietf-taps-transport-security, but then draft-ietf-taps-transport-security only says that it complements RFC 8095 - this gives readers following the link from minset a confusing context). Good point. I'll add the citation. > Section 3.2.3: Path MTU Discovery surprised me here. What does that mean? That DTLS relies on an application implementing PMTUD (as it=E2=80=99s over= UDP), and then telling DTLS about it? Doesn=E2=80=99t DTLS do this on its own? Wh= y not? Sorry for asking a DTLS question, surely it=E2=80=99s me=E2=80=A6 but just = listing PMTUD as a dependency isn=E2=80=99t a good enough explanation, I think. Clients have to set the maximum DTLS fragment (record) size, as each record must fit within a single datagram. > sec. 3.3: when I first read =E2=80=9CA mapping for QUIC over TLS 1.3 has = been specified to provide this handshake=E2=80=9D, I was surprised. I mean, give= n that TLS runs over TCP, this sentence sounds like something really doesn=E2=80= =99t match here. Only in sec. 3.3.3 you explain =E2=80=9CTLS within QUIC relies on a r= eliable stream abstraction for its handshake=E2=80=9D. Well that=E2=80=99s what I t= hought, but then this should probably be brought earlier - =E2=80=9Cmapping for QUIC over TL= S 1.3=E2=80=9D just sounds like QUIC uses TLS, which uses TCP, which is of course wrong. Maybe it=E2=80=99s just the word =E2=80=9Cover=E2=80=9D - using =E2=80=9Cwi= th=E2=80=9D instead would already make this clearer. Agreed. "Over" is not the correct word here. I'll fix that. > sec. 3 sentence 1: > =E2=80=9C=E2=80=A6security protocols that _are_ currently used to =E2=80= =A6=E2=80=9D > sec 3.3.1 1st sentence after bullet list: > =E2=80=9CThe QUIC transport layer support_S_ multiple streams=E2=80=A6=E2= =80=9D > Same para, 3rd sentence: =E2=80=9CThe TLS handshake, along with further r= ecords, are sent over this stream.=E2=80=9D - did you mean to say =E2=80=9CThe TLS= handshake messages=E2=80=9D ? > sec 3.4, line 2: > =E2=80=9Ceither as for creating tunnels (tunnel-mode)=E2=80=9D - I think= the =E2=80=9Cas=E2=80=9D should be removed here? > penultimate sentence of sec. 3.5.1: > =E2=80=9C=E2=80=A6DTLS-offered certificates match that which are offered = over SIP=E2=80=9D - is =E2=80=9Cthat=E2=80=9D correct here? (should it be =E2=80=9Cthe ones=E2=80= =9D or something like that?) It should, and Colin refactored that section since your email to fix it. > 3.10.1 par 5: > This begins with =E2=80=9CUnlike TCP, =E2=80=A6=E2=80=9D - isn=E2=80=99t= this strange to say, for being too obvious? Or did you mean to say tcpcrypt? > Well actually even TCP has cookies for some form of =E2=80=9Csource valid= ation=E2=80=9D, with TFO. Of course that=E2=80=99s a limited use, but =E2=80=A6 maybe sim= ply removing =E2=80=9CUnlike TCP=E2=80=9D here would make this clearer. Good point! I'll fix that, or add a blurb about excluding TFO. > 4.2, =E2=80=9CMutual authentication=E2=80=9D and =E2=80=9CSource validati= on=E2=80=9D: the sentence describing these features says =E2=80=9Cmust=E2=80=9D, yet it=E2=80=99s in = the section of optional features. While this doesn=E2=80=99t really matter, it makes for a slightly surprising read, and would IMO be better as a factual statement - e.g. =E2=80=9CTransport security protocols allow each endpoint to authenticate t= he other =E2=80=A6=E2=80=9D and =E2=80=9CSource validation is provided to mitigate = =E2=80=A6=E2=80=9D +1 > Sec 5.1.: missing line break after: > - Session Cache Management > - Connection Termination > - Pre-Shared Key Export Thanks! Will fix. From nobody Tue May 22 22:37:03 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 92E2B1241F5 for ; Tue, 22 May 2018 22:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HkrAK_PDs_ak for ; Tue, 22 May 2018 22:36:59 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 0B6D612025C for ; Tue, 22 May 2018 22:36:58 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fLMSG-0003lr-Cl; Wed, 23 May 2018 07:36:56 +0200 Received: from 197.red-217-126-10.staticip.rima-tde.net ([217.126.10.197] helo=[172.26.0.138]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fLMRo-0000kC-CT; Wed, 23 May 2018 07:36:55 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: Date: Wed, 23 May 2018 07:36:25 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2936645E-42DD-404A-9AB4-1D9A3A81DD0E@ifi.uio.no> References: <07299EC9-1130-447A-A85B-1FBA39C6CBB0@ifi.uio.no> To: Christopher Wood X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 217.126.10.197 is neither permitted nor denied by domain of ifi.uio.no) client-ip=217.126.10.197; envelope-from=michawe@ifi.uio.no; helo=[172.26.0.138]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 94D6D6711C6DFD22719E3BA3DE18E24EAE6877D7 Archived-At: Subject: Re: [Taps] Comments on draft-ietf-taps-transport-security-01 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: Wed, 23 May 2018 05:37:01 -0000 Hi, > On May 22, 2018, at 8:13 PM, Christopher Wood = wrote: >=20 > Hi Michael, >=20 > Many thanks for reading the document and taking time to provide = comments! > They are greatly appreciated. I've filed #33 ( Gee, thanks to you for this friendly response after getting so much work = thrown in your face! :) seriously, sorry for this! I=E2=80=99m only keeping and answering things that I think call for an = answer - everything I removed has my implicit positive ACK=E2=80=A6 and I mark my response with [MW]. >> Similarly, what is the rationale for making some features mandatory = and > some optional in section 4? Reasons for this choice should be = explicitly > laid out at the beginning of section 4. >=20 > In general, our rationale for mandatory features is that they were = offered > by most popular protocols and are "critical" for the security protocol = to > operate correctly. Optional features are those protocols can work = around. [MW] I think that=E2=80=99s fine - but please state this in the draft. >> This brings me to the next issue: I think there=E2=80=99s a = terminology problem > with this document. The terminology section, in line with all other = TAPS > documents, mentions =E2=80=9Cconfidentiality=E2=80=9D as an example of = a =E2=80=9CTransport > Feature=E2=80=9D. Further down, =E2=80=9CSecurity Feature=E2=80=9D is = introduced. Given the > description of Transport Feature, a Security Feature is a special case = of a > Transport Feature. Maybe the first sentence of the Security Feature > definition could be changed to say =E2=80=9CA Transport Feature that a = network > security layer provides to applications.=E2=80=9D Section 3 then = talks about > =E2=80=9CProtocol features=E2=80=9D; these are maybe not offered to = applications, so I > think it=E2=80=99s fine to use this term, but you should also define = it in the > Terminology section. Then, Section 5 talks about Transport Security > Protocol Interfaces - but that term isn=E2=80=99t defined anywhere. I = think these > =E2=80=9Cinterfaces=E2=80=9D are really Security Features, no? >=20 > Not quite. They're interfaces to the security protocols. Those = interfaces > may of course drive or control certain features. I see where you=E2=80=99re coming from=E2=80=A6 but the way the = terminology is, and was interpreted in other TAPS documents so far, is = that =E2=80=9Cprovides to applications=E2=80=9D in the phrase "a = specific feature that a network security layer provides to = applications=E2=80=9D really means that this is visible in the API. You = already use the (new) term =E2=80=9Cprotocol feature=E2=80=9D to talk = about things that may not be visible in the API. Do you need yet another = term, then? If so, maybe you should define =E2=80=9CInterface=E2=80=9D = in the Terminology section too to clarify how this is different. >> Section 3.2.3: Path MTU Discovery surprised me here. What does that = mean? > That DTLS relies on an application implementing PMTUD (as it=E2=80=99s = over UDP), > and then telling DTLS about it? Doesn=E2=80=99t DTLS do this on its = own? Why not? > Sorry for asking a DTLS question, surely it=E2=80=99s me=E2=80=A6 but = just listing PMTUD as > a dependency isn=E2=80=99t a good enough explanation, I think. >=20 > Clients have to set the maximum DTLS fragment (record) size, as each = record > must fit within a single datagram. Oh, wow, so it is true -- you have to do PMTUD in your application to = properly use DTLS?? Note the previous comment from Mikael Abrahamsson in his email about = minset: he wondered if a TAPS system should offer PMTUD. If using DTLS is such a hassle, maybe the answer should be yes? (being = application-independent, for UDP, I think this could only be done with a = mechanism such as draft-ietf-tsvwg-datagram-plpmtud ) Sorry for the digression! Cheers, Michael From nobody Wed May 23 08:46: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 AD44812E058 for ; Wed, 23 May 2018 08:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kf_FaZ6osdmF for ; Wed, 23 May 2018 08:45:57 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 1D43E12711E for ; Wed, 23 May 2018 08:45:57 -0700 (PDT) Received: from [137.50.150.131] (oa-edu-150-131.wireless.abdn.ac.uk [137.50.150.131]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 612901B0015C; Wed, 23 May 2018 16:45:56 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (15E216) In-Reply-To: <2936645E-42DD-404A-9AB4-1D9A3A81DD0E@ifi.uio.no> Date: Wed, 23 May 2018 16:45:55 +0100 Cc: Christopher Wood , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <07299EC9-1130-447A-A85B-1FBA39C6CBB0@ifi.uio.no> <2936645E-42DD-404A-9AB4-1D9A3A81DD0E@ifi.uio.no> To: Michael Welzl Archived-At: Subject: Re: [Taps] Comments on draft-ietf-taps-transport-security-01 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: Wed, 23 May 2018 15:46:00 -0000 Just on the discovery of PMTU... On 23 May 2018, at 06:36, Michael Welzl wrote: >>> Section 3.2.3: Path MTU Discovery surprised me here. What does that mean= ? >> That DTLS relies on an application implementing PMTUD (as it=E2=80=99s ov= er UDP), >> and then telling DTLS about it? Doesn=E2=80=99t DTLS do this on its own? W= hy not? >> Sorry for asking a DTLS question, surely it=E2=80=99s me=E2=80=A6 but jus= t listing PMTUD as >> a dependency isn=E2=80=99t a good enough explanation, I think. >>=20 >> Clients have to set the maximum DTLS fragment (record) size, as each reco= rd >> must fit within a single datagram. >=20 > Oh, wow, so it is true -- you have to do PMTUD in your application to prop= erly use DTLS?? > Note the previous comment from Mikael Abrahamsson in his email about minse= t: he wondered if a TAPS system should offer PMTUD. > If using DTLS is such a hassle, maybe the answer should be yes? (being a= pplication-independent, for UDP, I think this could only be done with a mech= anism such as draft-ietf-tsvwg-datagram-plpmtud ) > Sorry for the digression! >=20 > Cheers, > Michael That is fine - the reality is you do not need PMTUD. However, if you choose a= low PMTU this impacts efficiency. If you use a larger PMTU - then you impact robustness - unless you provide b= lack hole detection. That does not help efficiency, for that the endpoint wo= uld need to probe. If the transport system offered PMTUD the system could d= o this with the Apps blessing, but likely without the Apps involvement. The difference between tcp and udp is that the API needs to support this. T= his is needed for the stack to do PMTUD. Otherwise an app could ask the stac= k to do black hole detection. Some apps may instead just do all the PMTUD vi= a an API. That is three ways of working. All of which can be used with Dplpm= tud. Gorry= From nobody Thu May 24 05:11:21 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 AFC8E12DA16 for ; Thu, 24 May 2018 05:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 IUL967qKbuaQ for ; Thu, 24 May 2018 05:11:17 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA51812DA6F for ; Thu, 24 May 2018 05:11:16 -0700 (PDT) Received: from [192.168.1.58] (unknown [195.91.238.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 633568362A; Thu, 24 May 2018 14:11:12 +0200 (CEST) From: Fernando Gont To: taps WG Cc: "gorry@erg.abdn.ac.uk" , Tommy Pauly References: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <0faea4bf-0b40-bcd8-e0c7-ab6d6f83ac5a@si6networks.com> Date: Thu, 24 May 2018 15:11:47 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <6823b853-670f-ee08-cf2e-9c435d8eb1fd@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] IPv6 address usage 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, 24 May 2018 12:11:20 -0000 Folks, Any thoughts? Thanks! Fernando On 03/21/2018 07:58 PM, Fernando Gont wrote: > Folks, > > Based on the feedback received today, I have split our document > > into this two documents: > > * Problem statement with respect to limitations of the Sockets API: > > > * Analysis of IPv6 address properties: > > > Your feedback will be appreciated. We'd also appreciate guidance on how > to move forward. :-) > > Thanks! > > Best regards, > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri May 25 06:57:53 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 7B3D6126CB6; Fri, 25 May 2018 06:57:51 -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.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152725667141.13005.6707113407819267511@ietfa.amsl.com> Date: Fri, 25 May 2018 06:57:51 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-impl-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: Fri, 25 May 2018 13:57:51 -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 : Implementing Interfaces to Transport Services Authors : Anna Brunstrom Tommy Pauly Theresa Enghardt Karl-Johan Grinnemo Tom Jones Philipp S. Tiesel Colin Perkins Michael Welzl Filename : draft-ietf-taps-impl-00.txt Pages : 37 Date : 2018-05-25 Abstract: The Transport Services architecture [I-D.pauly-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-impl-00 https://datatracker.ietf.org/doc/html/draft-ietf-taps-impl-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 Wed May 30 07:46: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 05D1112E889 for ; Wed, 30 May 2018 07:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 jDFzkPomk1nd for ; Wed, 30 May 2018 07:45:57 -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 DC17912EAA4 for ; Wed, 30 May 2018 07:45:46 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 63F6A340D3E for ; Wed, 30 May 2018 16:45:44 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.5012); Wed, 30 May 2018 16:45:44 +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 for ; Wed, 30 May 2018 16:45:44 +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 56597069 for taps@ietf.org; Wed, 30 May 2018 16:45:44 +0200 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_F0FEA6FD-6D2D-47BB-B0E0-A09FDC3FBE83"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Message-Id: <214D1D3A-E789-425D-B572-11204DBAA9D8@trammell.ch> Date: Wed, 30 May 2018 16:45:43 +0200 To: taps WG X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: [Taps] minset WGLC 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: Wed, 30 May 2018 14:46:00 -0000 --Apple-Mail=_F0FEA6FD-6D2D-47BB-B0E0-A09FDC3FBE83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, I've done a final pass of minset; it is IMO ready to go up to the IESG. (One last impression on reading the document again after having been = away from it for so long: the density of parenthetical (!UDP) remarks = really does make me wonder why we persist in pretending that UDP is a = transport-layer protocol :) but the approach taken here is IMO a good = one.) Cheers, Brian --Apple-Mail=_F0FEA6FD-6D2D-47BB-B0E0-A09FDC3FBE83 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlsOuRcACgkQihK3vwvq RqOFKxAApmjHrv53jAafOQvHfErsagZjwTitSyUNtT3F01rHAV20rDFYgruoim3L f2nRjg/y4d5rekBDszZcZJpQebbu8/+i92qcMhIBpZ1P+G5a7/x4uvDxht7pONEN 2yedbZ5QZ5tR0WD5R/c9P1SEUZO0YZ/gqXv0PeIDAYKjYXIetxkb5bBOfWqtOTc3 AmIhwjPeAVdslzaVR5KO/ehRlX7C+hc5CslqXjYQBhL7dyd80pKuNDGcMZSk2hX9 B7xilki8BjuWYSMQ6hC0qu5l3yh8OW5ezgyfOaP3i7IyxeuTSo2R3Rr8TzRSuCv/ fQRUr1A6XAyyVn9qifyimYkyKPGvvSUfX9SItP5WuaOE36E5eDqIQFJjv95hwI6S kfJMLKhRbO+FvCMXj8QWDU9C0ggPzWNp3oJM1s2Eby7HAfFlp+6tO32dylxhRZcM qmZsY5vAJf4zR6kjyynAEUgFOZtL5yEpN2kOmPvILfIgR3rwBPjCqOy0lxFZEWeS 0E7cTBsDRsvHbQj6Y4OMdtukpXFag5lL+yup54q3l0MECC4kdvYoIlN1/TD56QGe NeCtZ7/t/Z5dGcJ0kyKF7Ty5JdSUVrgydV0McRtyYa9GumHYwkt4tEPrvnWFK2TU SpjSrOK24TEnje2kpsbXi3xuANiriGg62WRb0RePW0ecU4XCHuE= =LZXz -----END PGP SIGNATURE----- --Apple-Mail=_F0FEA6FD-6D2D-47BB-B0E0-A09FDC3FBE83-- From nobody Wed May 30 07:51:20 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 57F5C12EAB1; Wed, 30 May 2018 07:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 5wlvUpsQ_3UE; Wed, 30 May 2018 07:51:16 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 1CC9A12EA59; Wed, 30 May 2018 07:51:16 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 18-v6so42865297wml.2; Wed, 30 May 2018 07:51:16 -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; bh=W/BnogrZDF3gAUovSa1r0Vo8tW4Yxek22iSEAHb+d7c=; b=YC3uGKrbKLqK439wz117DE+MVLwTCQhQ2K7uC9xD8tujnl/A1HPJ11/yGHodvaN5lH 8kueZ1xeW7DebnKfcYDi0H9MPNEcTNh7eDl8l2X28bDuYWw9rcqK0Un+o6X9iRfDGamd AZIOdx3hRZ4oxiaq/YmwiipCbbLSDeFiH4Ecb3xYZTqyNPevf+TAI/nImEunApzu+EVo az2kl5RNsOFsbwVPeGxGSV0YeY9BJkZ7OlekFW2R4HU0ql30xg7ralCWl+g5Cc6qza6w lnkt3x3ETyz9grNrwL8+eyhXU0E2hMiy7Z/EzEJm6w4GFpWt9TxNeE355fuPEoNfJCum Oa8A== 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; bh=W/BnogrZDF3gAUovSa1r0Vo8tW4Yxek22iSEAHb+d7c=; b=g4xWSMVOYtuk/Kpffx9HKa8RvdJKpbeVeeMT1rnzpPFIA7LqRjy/ZWzTffh427Reso ZQJlbUzNOFcXu6eKwaIOPV+gLri8PUTBpbElWdTUssKtZHuXJcKjDp4YYDcNMyoU8G8j m+q8cJznIbkiZVHDM3Gsif3CTO8HObxxRJ4z6qOjmG/pa8CAYGIWRoC0UhJCfWf2xiwO w8MoZxmYSRcnO161oEO41a9cUc1Id8Snyr6ginhH674OblKnupNYsBWQKDuckaLsWiay VohOWFEfMRcmhoWw5YaG3N39ryxQuLdXNyCtw5p48Tc3hS81fSlVmgGG2BM4nBfDAdFc FlIA== X-Gm-Message-State: ALKqPwecGmEcLzpxnns3GrqQWYPzqmMm99kWm8WMj+dPyRafNp9Iij1R F023kQlopzYsrwn8SbXozOonnIVFT63vjVxVR/cVzA== X-Google-Smtp-Source: ADUXVKIHGv/n/bG2QGKwsjOEZyd5FmhmViL7jJtpe4qevcBSBVyYHaRI0kGwp0bjM8b+bXMyKzjMVQhBh9D9Otk3k+c= X-Received: by 2002:a50:99d0:: with SMTP id n16-v6mr3839852edb.111.1527691874406; Wed, 30 May 2018 07:51:14 -0700 (PDT) MIME-Version: 1.0 References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> <3F4C0CD4-9D7A-42AD-9A1D-A19C47321E69@gmail.com> In-Reply-To: <3F4C0CD4-9D7A-42AD-9A1D-A19C47321E69@gmail.com> From: Aaron Falk Date: Wed, 30 May 2018 10:51:03 -0400 Message-ID: To: taps WG Cc: draft-ietf-taps-minset@ietf.org Content-Type: multipart/alternative; boundary="000000000000801586056d6d7b09" Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset 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: Wed, 30 May 2018 14:51:19 -0000 --000000000000801586056d6d7b09 Content-Type: text/plain; charset="UTF-8" Reminder: working group last call concludes next Monday. Please review this doc and send comments &/or 'ready to publish'. --aaron On Thu, May 17, 2018 at 11:30 AM Aaron Falk wrote: > I've received a request to extend the WGLC for this doc. We'll accept > comments until June 4th. > > --aaron > > On 10 May 2018, at 10:52, Aaron Falk wrote: > > Dear TAPS working group, > > As discussed in London, it's time to last call draft-ietf-taps-minset-03 > . > > A Minimal Set of Transport Services for TAPS Systems > draft-ietf-taps-minset-03 > > Abstract > > This draft recommends a minimal set of IETF Transport Services > offered by end systems supporting TAPS, and gives guidance on > choosing among the available mechanisms and protocols. It is based > on the set of transport features in RFC 8303. > > Please read the draft and send comments to the list. This document is > planned to be an Informational RFC. Statements along the lines of 'ready to > publish' are also welcome. > > WGLC will conclude in two weeks on May 24, 2018. > > --aaron (for the chairs) > > --000000000000801586056d6d7b09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reminder: working group last call concludes next Monday.= =C2=A0 Please review this doc and send comments &/or 'ready to publ= ish'.

--aaron

On Thu, May 17, 2018 at 11:30 AM Aaron Falk <aaron.falk@gmail.com> wrote:

I've received a request to extend the WGLC for this doc= . We'll accept comments until June 4th.

--aaron

On 10 May 2018, at 10:52, Aaron Falk wrote:

Dear TAPS working group,

As discussed in London, it's time to last call draft-ietf-taps-minset-03.

          A Minimal Set of Transpo=
rt Services for TAPS Systems
                       draft-ietf-taps-minset-03

Abstract

   This draft recommends a minimal set of IETF Transport Services
   offered by end systems supporting TAPS, and gives guidance on
   choosing among the available mechanisms and protocols.  It is based
   on the set of transport features in RFC 8303.

Please read the draft and send comments to the list. This d= ocument is planned to be an Informational RFC. Statements along the lines = of 'ready to publish' are also welcome.

WGLC will conclude in two weeks on May 24, 2018.

--aaron (for the chairs)

--000000000000801586056d6d7b09-- From nobody Thu May 31 04:32:47 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 08B3412EB15; Thu, 31 May 2018 04:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Fzw7e2B6lR1Y; Thu, 31 May 2018 04:32:43 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 26C7912D9FF; Thu, 31 May 2018 04:32:41 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTP id w4VBVxWv009606 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 May 2018 13:31:59 +0200 Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fOLnO-0005xi-5b; Thu, 31 May 2018 13:31:06 +0200 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7774E77E-A26B-41CB-AD7D-AC10DF4770D7" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Thu, 31 May 2018 13:31:57 +0200 In-Reply-To: Cc: taps WG , draft-ietf-taps-minset@ietf.org To: Aaron Falk References: <5293278D-D3BF-409E-965A-E57C5BB2F038@gmail.com> <3F4C0CD4-9D7A-42AD-9A1D-A19C47321E69@gmail.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Taps] working group last call for draft-ietf-taps-minset 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, 31 May 2018 11:32:47 -0000 --Apple-Mail=_7774E77E-A26B-41CB-AD7D-AC10DF4770D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I just found time to re-read the document and have no objections. As a note: the Appendix is several the length of the main document. It = somehow makes sense, but might face criticism without explanation why. > On 30. May 2018, at 16:51, Aaron Falk wrote: >=20 > Reminder: working group last call concludes next Monday. Please = review this doc and send comments &/or 'ready to publish'. >=20 > --aaron >=20 > On Thu, May 17, 2018 at 11:30 AM Aaron Falk > wrote: > I've received a request to extend the WGLC for this doc.. We'll accept = comments until June 4th. >=20 > --aaron >=20 > On 10 May 2018, at 10:52, Aaron Falk wrote: >=20 > Dear TAPS working group, >=20 > As discussed in London, it's time to last call = draft-ietf-taps-minset-03 = . >=20 > A Minimal Set of Transport Services for TAPS Systems > draft-ietf-taps-minset-03 >=20 > Abstract >=20 > This draft recommends a minimal set of IETF Transport Services > offered by end systems supporting TAPS, and gives guidance on > choosing among the available mechanisms and protocols. It is based > on the set of transport features in RFC 8303. > Please read the draft and send comments to the list. This document is = planned to be an Informational RFC. Statements along the lines of 'ready = to publish' are also welcome. >=20 > WGLC will conclude in two weeks on May 24, 2018. >=20 > --aaron (for the chairs) >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_7774E77E-A26B-41CB-AD7D-AC10DF4770D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = just found time to re-read the document and have no objections.

As a note: the Appendix = is several the length of the main document. It somehow makes sense, but = might face criticism without explanation why.

On 30. = May 2018, at 16:51, Aaron Falk <aaron.falk@gmail.com> wrote:

Reminder: working group last call concludes next = Monday.  Please review this doc and send comments &/or 'ready = to publish'.

--aaron

On Thu, May 17, 2018 = at 11:30 AM Aaron Falk <aaron.falk@gmail.com> wrote:

I've = received a request to extend the WGLC for this doc.. We'll accept = comments until June 4th.

--aaron

On 10 May 2018, at 10:52, Aaron Falk wrote:

Dear TAPS = working group,

As discussed in London, = it's time to last call draft-ietf-taps-minset-03.

          A Minimal Set of Transport =
Services for TAPS Systems
                       draft-ietf-taps-minset-03

Abstract

   This draft recommends a minimal set of IETF Transport Services
   offered by end systems supporting TAPS, and gives guidance on
   choosing among the available mechanisms and protocols.  It is based
   on the set of transport features in RFC 8303.

Please read the draft and send = comments to the list. This document is planned to be an Informational = RFC. Statements along the lines of 'ready to publish' are also = welcome.

WGLC will conclude in two weeks = on May 24, 2018.

--aaron (for the = chairs)

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

AVE!
  Philipp S. Tiesel / phils=E2=80=A6-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

= --Apple-Mail=_7774E77E-A26B-41CB-AD7D-AC10DF4770D7-- From nobody Thu May 31 09:18:12 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 E44431270A0 for ; Thu, 31 May 2018 09:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 gJBk7VuhnThr for ; Thu, 31 May 2018 09:18:08 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 6D2A6126CF9 for ; Thu, 31 May 2018 09:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1527783485; x=2391697085; 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=SsROHx7QwYlvh1MScUG1cuHNTkMiF7dA6R/S0G8BsYs=; b=c1b+ek0xfZUIetOjYyXq3O/cZymd+YLK/ERV3pKWyyfPPum6ppsZLmbEBQuT38O+ yl5oWtp323bHzHXMT2p6vZVsDUHsT/wjjtv7ucaQiHKmY0nsbaCnp+NXG6yxkPPt 9aljsBmgyVHQqcJjAbA+tLPUA60aKAOzAsTuV4L6lzvuXa/GdvJEcI9sZ+ohyro9 1biB55Vu/jOlXhrgULe+NuHkb8EeLg9GRVXm562Z3JSgR8g5VLS4iDG7XH+FKTZ9 P/fN61YtW/RsNjOV3pWOMVFCZ25fUYNaaHYi4Xbg8nWB4dVz3Tg2rtIdWr3q4NZ7 JNJ4SScRo/S27PNDpxi9KQ==; X-AuditID: 11973e13-b209c9e00000242c-36-5b10203ce23f Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id B8.8D.09260.C30201B5; Thu, 31 May 2018 09:18:05 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0P9L002HMPA3GV70@ma1-mtap-s02.corp.apple.com>; Thu, 31 May 2018 09:18:04 -0700 (PDT) Received: from [17.234.74.125] (unknown [17.234.74.125]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P9L00NPTPA21EC0@nwk-mmpp-sz10.apple.com>; Thu, 31 May 2018 09:18:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 66479cc87bfe6c0c619fa0f100b7edfa X-Va-E-CD: c52d6f7fbbdbd4470f8194e6ad3d83e1 X-Va-R-CD: 7a70530821f7261df47c3f6dc1684fc4 X-Va-CD: 0 X-Va-ID: 060fdb8d-ec8e-41ef-9609-e03271c323e3 X-V-A: X-V-T-CD: 6dc75cca81846fa71c65d95092fcaebe X-V-E-CD: c52d6f7fbbdbd4470f8194e6ad3d83e1 X-V-R-CD: 7a70530821f7261df47c3f6dc1684fc4 X-V-CD: 0 X-V-ID: 4278e6ca-d297-4f84-94d6-d5c3e230a7e0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-31_08:,, signatures=0 Sender: tpauly@apple.com From: Tommy Pauly Content-transfer-encoding: quoted-printable Message-id: Date: Thu, 31 May 2018 09:17:44 -0700 To: draft-ietf-taps-minset@ietf.org, taps WG X-Mailer: Apple Mail (2.3445.100.6.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42IR1PBh07VVEIg2aDrKYrFwf5rFnRgHJo8l S34yBTBGcdmkpOZklqUW6dslcGVseMlVsE2o4sSaFuYGxh7+LkZODgkBE4mHs7eydTFycQgJ 7GOSmLpvMjNIgldAUOLH5HssXYwcHMwC6hJTpuRC1Gxkkrg2aQ0bSI2QwEQmiXO9ARCD2CX+ /NrBAmFrSzTeX8AKY39+fJ4Zxv70/RAjhM0lsWDraVaQ+RICuhJXtmhAhNkk1p9YwgRha0mc 6J0KZ9+8eY0Rxp61dy/UeE6J818mskPYOhIf3vyHimdL/Dz6mR1kvLCAhMTmPYkgYTYBFYnj 3zaAXcMMdM2TdxfAyoUFpCVOnr4H9bmNxMe/Z8A+YRFQlThx6zvYtyJA8b0du6DOUZXYcbiL dQKj9CykwJqFCKxZSDYsYGRexSiUm5iZo5uZZ6qXWFCQk6qXnJ+7iREUgdPthHcwnl5ldYhR gINRiYdX4wt/tBBrYllxZe4hRmkOFiVxXjljoJBAemJJanZqakFqUXxRaU5q8SFGJg5OKWBM HnVlOKR/85FN8qsXd6WN3yxlTV7wsGR6Wlh59xNxP9/YbZ0Hj92+P+9LpJaYwp3vTpsT5z6J f9trU7Pbgdv07ZKpYYeS5bsDU14JKOrZ/9W/M+dNgLKMO/NXC8Uccc+PM3X0q50eW16rOh63 3LpwpVTAuZvb3qjvNCmd2tjMPOPl/Acvwn8osRRnJBpqMRcVJwIAaPaqaaECAAA= Archived-At: Subject: [Taps] Minset WGLC Review 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, 31 May 2018 16:18:10 -0000 Hello TAPS, I=E2=80=99ve just done a read through of the current minset draft. = Overall, looks good! I have a few nits, but these can all be addressed = in the next revision: - The first sentence of the abstract is a bit hard to parse for someone = who isn=E2=80=99t coming from the context of the working group: "This draft recommends a minimal set of IETF Transport Services offered by end systems supporting TAPS, and gives guidance on choosing among the available mechanisms and protocols.=E2=80=9D We use the term =E2=80=9CTAPS=E2=80=9D as a well-known term here, which = I don=E2=80=99t think it is necessarily. In our = architecture/API/implementation documents we=E2=80=99re trying to avoid = using TAPS as term, and using Transport Services more instead. That=E2=80=99= s not to say we should remove the usage of TAPS here, but perhaps do the = Transport Services (TAPS) definition somewhere up-front. Also, why is = this is minimal set of =E2=80=9CIETF" services? I assume this means =E2=80= =9Ca minimal set of Transport Services defined in IETF protocols=E2=80=9D,= but it feels heavy on the jargon. - Same point of defining =E2=80=9CTAPS=E2=80=9D for the introduction.=E2=80= =99 - Introduction: "For example, it does not help an application that talks to a middleware=E2=80=A6=E2=80=9D Does the application talk to =E2=80=9Ca middleware=E2=80=9D? I = understand the use of =E2=80=9Cthe middleware=E2=80=9D later, but it = seems to me that middleware should have the same usage as = =E2=80=9Csoftware=E2=80=9D, and we don=E2=80=99t use =E2=80=9Ca = software=E2=80=9D generally. - Section 3 Personally, I=E2=80=99d add an Oxford comma here: "Based on the = categorization, reduction and discussion=E2=80=A6=E2=80=9D to "Based on = the categorization, reduction, and discussion=E2=80=A6" - Section 3.1 Is there a reason we use underscore style for the parameters? = =E2=80=9CChecksum_coverage=E2=80=9D, =E2=80=9CConfig_msg_prio=E2=80=9D, = etc. While I understand that these may be the code symbols you use in a = C program, you=E2=80=99re not using this style or these symbols = elsewhere, and it would be clearer to write out =E2=80=9CConfigure = message priority=E2=80=9D, etc. It will also look more palatable to more = modern language styles =3D) Thanks, Tommy=