From nobody Fri Aug 3 14:00: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 BD2C213113B for ; Fri, 3 Aug 2018 14:00:05 -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 O_SL2goxbq_O for ; Fri, 3 Aug 2018 14:00:01 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 A66CB1310F0 for ; Fri, 3 Aug 2018 14:00:01 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id 13-v6so2344483qkl.9 for ; Fri, 03 Aug 2018 14:00: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:mime-version; bh=OdDKjNMRQhACoim8OfRMtjDyJFlHt/6sV3Cdvzvnip0=; b=H2412sEjyX4hIZDrPDdwZ7B7sy0TlR8S1/w43b5PBr9xWxzCWJVBgiG/HWcuJkph8/ I4XjErYBza6a4G9aViscrw2/dintpgmv5YKgYIegIiInj9i11pteR1Kz7ghXuY4c6weU KukGMpw91ilIWDeOWSNkx9maFvvXrRUfrLO+8JKyzsYlaDdp2d7qpXSCHmvwSOPpanXh HHojLeVZ9lJXz7xQ2V8UDIATmeQ0K5o6XcszWh8WF7DMPBPGPzJ1OYOfcCFCF2WGbvjb DO3fhKBf47S/TBUOX8ZEMJL9C+pKHWscsiJW1UQJorl0BOo4O6C8XbZg6oeaXkVpwb5Z Ybww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=OdDKjNMRQhACoim8OfRMtjDyJFlHt/6sV3Cdvzvnip0=; b=tG7WZ8DXlDxfNycePej4pS8AWwyxU8nz27QZmquOOkG62FrePR8OP3XbMT7GX0pbnV r6M7aUgkjILspAXZIuLhL843Z/KZu6PyJjRBS8SABQ8Uf2dJsT/V22zrsBgs9oyCJx5t IxmPhUfwwcw57iIeR0Gwb0P93AxuudcK35Zvj0SgnHf1pBWv0OIoSaITmNHPa9vmDonT FHAOaXuPW8dNEBvkNNBGl8v3x10qmAvO6Lt/gEZrBu33NGke3tRCynv8LUDBWaDRhdDy amQZ59Bhu18Z6HRkT6/WPqmhPhuWVOsIxv22Ymm+XQkqOyr12mEdbq+xxJCceqmHDBvn G11g== X-Gm-Message-State: AOUpUlFi22pg2Pfs/pupySu0Pu4+cv8LbozvhmAfbpfhuHm2e2HqK3oB tWz6DblrKo+n4d/LNSyvqbwRNr2j X-Google-Smtp-Source: AAOMgpddpHd4X1UsmL04VHiojnmIl4BpLdqMx6lzyhkFstRi+D99U/bQ2gw3HWcRHQPZ4XACboBTBA== X-Received: by 2002:a37:84c3:: with SMTP id g186-v6mr5115419qkd.400.1533330000337; Fri, 03 Aug 2018 14:00:00 -0700 (PDT) Received: from [172.19.39.42] ([2001:4878:a000:3000:1d7f:39ab:a79d:15b3]) by smtp.gmail.com with ESMTPSA id x7-v6sm4788938qtc.66.2018.08.03.13.59.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Aug 2018 13:59:59 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Fri, 03 Aug 2018 16:59:59 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_F1E03A90-1519-4418-99FC-F368572A2ABA_=" Archived-At: Subject: [Taps] virtual interim date: Sept 12 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 03 Aug 2018 21:00:10 -0000 --=_MailMate_F1E03A90-1519-4418-99FC-F368572A2ABA_= Content-Type: text/plain; format=flowed; markup=markdown It's clear from the Doodle poll that the best time for an interim call is Tuesday, Sept. 12 at 11:00 EDT (GMT-4). I'll followup with webex coordinates once I can close the loop with the Secretariat. Thanks all for your prompt responses. --aaron --=_MailMate_F1E03A90-1519-4418-99FC-F368572A2ABA_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">It's clear from the Doodle poll that the best time for an = interim call is Tuesday, Sept. 12 at 11:00 EDT (GMT-4). I'll followup wi= th webex coordinates once I can close the loop with the Secretariat. Tha= nks all for your prompt responses.

--aaron

--=_MailMate_F1E03A90-1519-4418-99FC-F368572A2ABA_=-- From nobody Fri Aug 3 14:07:54 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023681310E6 for ; Fri, 3 Aug 2018 14:07:54 -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, 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 (1024-bit key) header.d=krose.org 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 k4Z4BUulfiov for ; Fri, 3 Aug 2018 14:07:52 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 2B8451310E5 for ; Fri, 3 Aug 2018 14:07:51 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j205-v6so12229405oib.4 for ; Fri, 03 Aug 2018 14:07:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mMmMhdxObpqFsh5xZYw6FyRZeFaVWqZJ8q1b/+kye6A=; b=OwRlsRkSGnEfWMm6ZopGDe9JrELziqS/z7xfKengWP6K21Fyvob5qwXnwcSIszJ/m7 g3a82s5YcEg7yJJXVZqa1nbA48K+1NqfkWMOjUOwYaqHPQZKRr+EJtUTy/1+Czpg4iK9 iwrTInHvNPmOKOGB8wJb/cwFQQcvXBo2gvjWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mMmMhdxObpqFsh5xZYw6FyRZeFaVWqZJ8q1b/+kye6A=; b=uR6GBetLq8C8jeEqP5XeEjwgZ8/Nau9o6WEfstkPjh3kXa2M1ZxsdqcWp2uISkSQNO dQxU0u6tuDOktxJrA61ZRvgIsQrOCz6Hi1S4Y140lCauIORWOdbBYlACPR9C5RqZ2+DB ijQ74yMb5lt4b+uRlEfy63TA4DDJMVjT3B5ugCYQ0MySRoj75GQwOh/Ihutu578r2pB4 6gsyZ3OpR59DrpOf12e9YtPDVxS3Hcfgyth2qJbHEnMcwfHvJY+VXf8soRF7aY+zXFIl 0qWpRYWGWctLiMUAZE7vc+uRwD3pZZhQ0OzyTfwEwCdnx4Kfof9Hu3x3Np71GYMo5hH0 zApA== X-Gm-Message-State: AOUpUlET9DYzgNiwku7fto0i5R7hvFeExmvD4wRz0JVkACC60H5NRZKC pdQJ6KjHijSARpSQVuEWSY+bj4BOpi8vbuIBiUFF/w== X-Google-Smtp-Source: AAOMgpdLYMHwi5QRttm2HP0AgF147Qd4IecuQyboIZqT78cNLEnrTb2XmnSHYcAXdAFr0CWtAUqwoBF3i6ZNd/+ijn0= X-Received: by 2002:aca:494b:: with SMTP id w72-v6mr5287862oia.293.1533330470335; Fri, 03 Aug 2018 14:07:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:204a:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 14:07:49 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:922b:34ff:fe5d:efa3] In-Reply-To: References: From: Kyle Rose Date: Fri, 3 Aug 2018 17:07:49 -0400 Message-ID: To: Aaron Falk Cc: taps WG Content-Type: multipart/alternative; boundary="00000000000002121b05728e5241" Archived-At: Subject: Re: [Taps] virtual interim date: Sept 12 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 03 Aug 2018 21:07:54 -0000 --00000000000002121b05728e5241 Content-Type: text/plain; charset="UTF-8" Tuesday the 11th or Wednesday the 12th? On Fri, Aug 3, 2018 at 4:59 PM, Aaron Falk wrote: > It's clear from the Doodle poll that the best time for an interim call is > Tuesday, Sept. 12 at 11:00 EDT (GMT-4). I'll followup with webex > coordinates once I can close the loop with the Secretariat. Thanks all for > your prompt responses. > > --aaron > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > --00000000000002121b05728e5241 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tuesday the 11th or Wednesday the 12th?

On Fri, Aug 3, 2018 at 4:5= 9 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

It's clear from the Doodle poll that the best time for an = interim call is Tuesday, Sept. 12 at 11:00 EDT (GMT-4). I'll followup = with webex coordinates once I can close the loop with the Secretariat. Tha= nks all for your prompt responses.

--aaron


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


--00000000000002121b05728e5241-- From nobody Fri Aug 3 14:09:50 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 941091310E5 for ; Fri, 3 Aug 2018 14:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_TVD_MIME_NO_HEADERS=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=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 j2KV0kqKPnV2 for ; Fri, 3 Aug 2018 14:09:45 -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 E9FF41310E3 for ; Fri, 3 Aug 2018 14:09:44 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id b15-v6so7653884qtp.11 for ; Fri, 03 Aug 2018 14:09:44 -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:embedded-html; bh=I7PwodQlmUqi6TtXB6lvauTv74taU/z8b47kTSwUHMA=; b=V8vQR9Gsxc45XLQMiyfSOj6RVX1OPg58JBsWw/GeKly57nmX1WT4GRCnkclzEcc5+H rWbYCPfdtE6oaxkcOEl9FVXxMCsMfXHdFX7sHtT6WXAh70YYIqyqGF+ZaFS/KUwxD1TW L+dJ3mn9oWUDFS3BVsAP36DfhRFfXY8J4/k++ZxolSsqvi12NaaG0uZVvjzYTnqQRrdv JsyNU1aJCxEPcDOaVRIK+hltqrf0SOm/Yk2jwOnIuy95KycTYNNIuoUGJnid6AqFo5KB BZs9l0DLhGYQ6ZvKU+1RP9MlK7UalJalzvNB8OMGZplr5xnAzaVPQzBvlSNIyPP7px8f EHuw== 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:embedded-html; bh=I7PwodQlmUqi6TtXB6lvauTv74taU/z8b47kTSwUHMA=; b=ZQ0KMjFFlpq6pOhxhdso4meJNjnh1v3xgfk9sFAsWN17BmcPHaG1sCb2uFKUJ75r5T OKEqHxgzROD3hcWDqEtr2+6/p942L7V5beUnTPoXbdjiiP6J1pHkzoFqHCxfkz+4uYd1 0P/rfmgi4uj1YfqTm8+70Gil4ckVNYVzFPwJgvw2DnK1UpgtSIuN41LfOv1P/mJvKlqb cGJlgPcbPMNp0xCdxYT6GtoNdECjbVlzFaDiAzj2NBEDD+r2zJ6lEMy4a6sXb/I8saCm CejLJtyzreq435uKUJaeBnozY8SROaSDpbCZOdJivVDeL/vh26A3USVjTMxFDs5ox87K UsoQ== X-Gm-Message-State: AOUpUlE8DwT7s8oxtkXpttNTmjwsc2GTTDhNCO+DIr430RdLrKU4sCx8 Aunf21xygwJtwAN3FlGQZiOGGakA X-Google-Smtp-Source: AAOMgpfeVL3rEw6fbq6XqzSYHk/CTCjQUWwhqmBjjXvvBjGcCSiyYzal9CY1MMy7hpfbZ0buJ2c4KQ== X-Received: by 2002:a0c:f5d3:: with SMTP id q19-v6mr5086007qvm.213.1533330583863; Fri, 03 Aug 2018 14:09:43 -0700 (PDT) Received: from [172.19.39.42] ([2001:4878:a000:3000:1d7f:39ab:a79d:15b3]) by smtp.gmail.com with ESMTPSA id t17-v6sm2039596qtp.96.2018.08.03.14.09.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Aug 2018 14:09:43 -0700 (PDT) From: "Aaron Falk" To: "Kyle Rose" Cc: "taps WG" Date: Fri, 03 Aug 2018 17:09:41 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <33D26BD7-5B86-4042-99F4-39403767118E@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_D89EAEE3-0C4F-4B14-A939-662DB818A89E_=" Embedded-HTML: [{"HTML":[423, 1203], "plain":[61, 526], "uuid":"A31CC783-A502-49EE-9657-D023A93EE8D6"}] Archived-At: Subject: Re: [Taps] virtual interim date: Sept 12 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 03 Aug 2018 21:09:48 -0000 --=_MailMate_D89EAEE3-0C4F-4B14-A939-662DB818A89E_= Weds. My bad. On 3 Aug 2018, at 17:07, Kyle Rose wrote: > Tuesday the 11th or Wednesday the 12th? > > On Fri, Aug 3, 2018 at 4:59 PM, Aaron Falk wrote: > >> It's clear from the Doodle poll that the best time for an interim call is >> Tuesday, Sept. 12 at 11:00 EDT (GMT-4). I'll followup with webex >> coordinates once I can close the loop with the Secretariat. Thanks all for >> your prompt responses. >> >> --aaron >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> >> --=_MailMate_D89EAEE3-0C4F-4B14-A939-662DB818A89E_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Weds. My bad.

On 3 Aug 2018, at 17:07, Kyle Rose wrote:

Tuesday the 11th or Wednesday the 12th?

On Fri, Aug 3, 2018 at 4= :59 PM, Aaron Falk <aaron.falk@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1= px #ccc solid;padding-left:1ex">
<= p dir=3D"auto">It's clear from the Doodle poll that the best time for= an interim call is Tuesday, Sept. 12 at 11:00 EDT (GMT-4). I'll fol= lowup with webex coordinates once I can close the loop with the Secretari= at. Thanks all for your prompt responses.

--aaron


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

--=_MailMate_D89EAEE3-0C4F-4B14-A939-662DB818A89E_=-- From nobody Fri Aug 3 14:20:46 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 69F6B130DFE; Fri, 3 Aug 2018 14:20:36 -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.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153333123630.18475.7764457471245175820@ietfa.amsl.com> Date: Fri, 03 Aug 2018 14:20:36 -0700 Archived-At: Subject: [Taps] Transport Services (taps) WG Virtual Meeting: 2018-09-12 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 21:20:37 -0000 The Transport Services (taps) Working Group will hold a virtual interim meeting on 2018-09-12 from 11:00 to 13:00 America/New_York. Agenda: Draft agenda: 1. Partial Send/Receive 2. 0-RTT 3. Implementation & testing Information about remote participation: https://ietf.webex.com/meet/taps | 316 448 940 Join by phone 1-650-479-3208 Call-in toll number (US/Canada) Access code: 316 448 940 From nobody Fri Aug 3 15:45:49 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 87A8D130DD3; Fri, 3 Aug 2018 15:45:48 -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, 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 sYtSA-pf88pN; Fri, 3 Aug 2018 15:45:44 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 21F7613107E; Fri, 3 Aug 2018 15:45:44 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id z143-v6so1560518ywa.7; Fri, 03 Aug 2018 15:45:44 -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=DK7ZR0lOzV7TzHscgfc1u64RCoJLU44OESHrTwQWRtU=; b=urmYtuZNxLzzFhJzDZ8gLeFbnzUKCAveueEjne/Com5p/wZfGIT2K9JTTAlkitZtO3 vy7zYfbFIaSyqj/yykZJifeYSejIYJXBXALRJpSTFlClxdVTt3JCZuIKEQ/4fcUauORk 4PxJgnt+lFTHmODdH+K0himuBYrr1AunfiKF50iiDH/PEipOho2PPVWvsuD3DyKaOD1B eu3r0+WLWe3JcCFOYqkY30WvQRjZG1lRCdM3vssnCSqWp45aY5Y4LON6bjL+yRirxkZK P/oHBcr/LnJHeNdiddu4h8SF/iDwwRpbB9xa9OvY5OJVRbrBy8GheIltIMthVNgpWdrG zCZA== 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=DK7ZR0lOzV7TzHscgfc1u64RCoJLU44OESHrTwQWRtU=; b=FIm+AHLoGqq3LcMHTNPzYUDKPEook86ehp1ctc2OVlK9rYKp6BTHkPBUKLbA1mr3hn Dr/2+hZXKuWc0kL3kVmwiNm5aJs1KkYtXhZSWjSvpkr6N0PfLgpzbMqzWggVeeGNmIap MCz59yuG6u5v8oxL6xPdLcDkYE/XyJDPPtDlBpkdwy1mXNi7D+Q4H/LPloqnWSqi/DnA pZd61XFTyctvu0RpZ9E7DlQDUm5W22i0a+UzcqW/cfQpm1UQ4guWn2oT1IESnCxFerQr dOh9pDird1dISUiWsrHLi90N3YpFh8scIFnZYj1H22iUbetT7ApT5yBL5ZvI/2rbhC2H fkWQ== X-Gm-Message-State: AOUpUlGCHYa6voWLpR327RsRnk/hGCWkHJjeEmBTweqkyqJmL4EwvzOY +ZTOfNSsVtu6RiSprp/6owO+pjMAE6PrxhvgEEXcfjNQ X-Google-Smtp-Source: AAOMgpcM2+AyWBENv/KhzijrWfcZMWpDaQ+7HNIzkHV2dcxxF7+0l/8OIjzwlLsH8ycTNLkbRJl6NJItLs1PxoB1UW8= X-Received: by 2002:a0d:edc2:: with SMTP id w185-v6mr3048678ywe.467.1533336342881; Fri, 03 Aug 2018 15:45:42 -0700 (PDT) MIME-Version: 1.0 References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> In-Reply-To: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 3 Aug 2018 17:45:29 -0500 Message-ID: To: draft-ietf-taps-minset@ietf.org Cc: taps-chairs@ietf.org, theresa@inet.tu-berlin.de, taps WG Content-Type: multipart/alternative; boundary="00000000000009ecf505728fb03f" Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 03 Aug 2018 22:45:48 -0000 --00000000000009ecf505728fb03f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear TAPsters, I've completed my AD review for this document, and have two high-level responses: - This looks good, and - I only have 8 pages of comments ... Please look these over, and ask for explanations if you need them. When we work through my comments, I'll request Last Call. And thanks for your work to date. Spencer I'm looking at this text Because the considered transport protocols conjointly cover a wide range of transport features, there is reason to hope that the resulting set (and the reasoning that led to it) will also apply to many aspects of other transport protocols. and wondering whether it's accurate to say "many aspects of other transport protocols that may be in use today, or may be designed in the future"? Part of my question is wrapped up in discussions about whether QUIC is a one-off new transport protocol, or whether QUIC is the first example of a new generation of transport protocols that are now worth designing because we know how to deploy them. This text For example, it does not help an application that talks to a library which offers its own communication interface if only the underlying Berkeley Sockets API is extended to offer "unordered message delivery", but the library only exposes an ordered bytestream. read oddly to me - I think the first "only" could be removed, unless I'm missing your point, but please take a look at that sentence for clarity. This text This "minimal set" can be implemented one-sided over TCP (or UDP, if certain limitations are put in place). This means that a sender-side transport system can talk to a standard TCP (or UDP) receiver, and a receiver-side transport system can talk to a standard TCP (or UDP) sender. was a bit difficult for me to read, and seems to mix explaining what "one-sided" means with the explanation that "one-sided" also applies to UDP, if certain limitations are put in place. I wonder if it is accurate to say This "minimal set" can be implemented "one-sided" over TCP. This means that a sender-side transport system can talk to a standard TCP receiver, and a receiver-side transport system can talk to a standard TCP sender. If certain limitations are put in place, the "minimal set" can also be implemented "one-sided" over UDP. Is "ungrouped communication" in For ungrouped connections, early configuration is necessary because it allows the transport system to know which protocols it should try to use. a well-understood term? I can guess at the meaning, but I'd be guessing, and RFCs 8095 and 8304 don't define or use either term.(Further down, I also see "grouped communications", and I'm guessing what that means, too, and Section 3.2.1 is even called "Connection groups", but doesn't clearly define what that means) I don't disagree with Note that this decision tree is not optimal for all cases. For example, if an application wants to use "Specify checksum coverage used by the sender", which is only offered by UDP-Lite, and "Configure priority or weight for a scheduler", which is only offered by SCTP, the above decision tree will always choose UDP-Lite, making it impossible to use SCTP's schedulers with priorities between grouped connections. The transport system must know which choice is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ more important for the application in order to make the best ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ decision. We caution implementers to be aware of the full set of trade-offs, for which we recommend consulting the list in Appendix A.2.1 when deciding how to initialize a connection. but I'm not sure how a general-purpose transport system will know which choice is more important for any arbitrary application. I see the Is this advice transport system implementers can act on? This isn't a big deal, but This also means that the active opening side is assumed to be the first side sending data. seems really reasonable for the vast majority of (client-server) applications, but I wonder if peer-to-peer applications will trip over a problem here ("I open a connection to you, but you already had data queued for me since we last connected and you sent it immediately" could be a scenario for SMTP or DTN, I guess). But I'll let you folks think about that= . This is a nit, but o A buffer limit (in bytes); when the sender has less then the ^^^^ than In this text, o Reliability: this parameter is used to convey a choice of: fully reliable (!UDP), unreliable without congestion control, unreliable (!UDP), partially reliable (see [RFC3758] and [RFC7496] for details on how to specify partial reliability) (!UDP). it took me some re-reading to figure out that "unreliable (!UDP)" meant something besides JUST "unreliable" (because UDP is "unreliable without congestion control"). Could this be clearer? I wonder about "unreliable with congestion control (!UDP)", but I'm guessing that this is the distinction you're making. This text in 7. Security Considerations Authentication, confidentiality protection, and integrity protection are identified as transport features by [RFC8095]. As currently deployed in the Internet, these features are generally provided by a protocol or layer on top of the transport protocol; no current full- featured standards-track transport protocol provides all of these transport features on its own. Therefore, these transport features are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply. The minimum security requirements for a transport system are discussed in a separate document [I-D.ietf-taps-transport-security]. confuses me, because I think at least two things are in play. First, I think the point you're probably making is that the underlying transport protocols remain unmodified, so the security considerations for each of those protocols apply unchanged, and this document isn't doing anything to create new security considerations. So, modulo SECDIR and SEC AD comments, I think that's all you need to say. Second, you guys are the experts, but I think a reference to [I-D.ietf-taps-transport-security] isn't actually needed for this document, because that document surveys security protocols, rather than specifying minimum security requirements. That document might someday discuss the minimum security requirements, in the way this document discusses the minimum set of transport services, but at least in https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that document is much more comparable to RFCs 8095 and 8304 than to this document. In Informative References, I see [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, . which is awesome (I wish more IETF people referred to IAB workshop reports), but the only place I see it referred to is in A.3.1. Sending Messages, Receiving Bytes: For example, if an application requests to transfer fixed-size messages of 100 bytes with partial reliability, this needs the receiving application to be prepared to accept data in chunks of 100 bytes. If, then, some of these 100-byte messages are missing (e.g., if SCTP with Configurable Reliability is used), this is the expected application behavior. With TCP, no messages would be missing, but this is also correct for the application, and the possible retransmission delay is acceptable within the best effort service model [RFC7305]. Still, the receiving application would separate the byte stream into 100-byte chunks. I was at that workshop, and it was pretty wide-ranging, so you might want to provide a section number with this reference to give an inquiring reader a chance of finding what you're referring to (I'm guessing the section number is 3.5, but I'm guessing). Just so you know - I did notice that Appendix A is two thirds of the page count for this document, and I agree that the material belongs in an appendix, and I think it's important for you to "show your work", in case anyone ever needs to update the minimal set in the future. So, I support what you're doing there. You folks know what you actually did, but I'm hoping that 2. Reduction: a shorter list of transport features is derived from the categorization in the first step. This removes all transport features that do not require application-specific knowledge or cannot be implemented with TCP or UDP. was actually "cannot be implemented with TCP, SCTP, or UDP". Was that an omission in this text, or do we need to chat? This text, Appendix A. Deriving the minimal set We approach the construction of a minimal set of transport features in the following way: 1. Categorization: the superset of transport features from [RFC8303] is presented, and transport features are categorized for later reduction. 2. Reduction: a shorter list of transport features is derived from the categorization in the first step. This removes all transport features that do not require application-specific knowledge or cannot be implemented with TCP or UDP. 3. Discussion: the resulting list shows a number of peculiarities that are discussed, to provide a basis for constructing the minimal set. 4. Construction: Based on the reduced set and the discussion of the transport features therein, a minimal set is constructed. The first three steps as well as the underlying rationale for constructing the minimal set are described in this appendix. The minimal set itself is described in Section 3. would have been clearer to me, if each step was labeled with the part of the document where this work appears (so, step 1 would be labeled "Section A.1", etc.), rather than providing the pointers at the end of the list. I couldn't tell whether you meant that these were the steps you took in the working group, or whether this was the organization of this appendix (plus Section 3), until I got to the paragraph at the end. Does Finally, some transport features are aggregated and/or slightly changed in the description below. These transport features are marked as "ADDED". The corresponding transport features are automatable, and they are listed immediately below the "ADDED" transport feature. mean "aggregated and/or slightly change from [RFC8303]"? I have the same question with In this description, transport services are presented following the nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", equivalent to "pass 2" in [RFC8303]. We also sketch how some of the transport features can be implemented by a transport system. For all transport features that are categorized as "functional" or "optimizing", and for which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on how to implement them over TCP and/or UDP is included. as I did above - is SCTP intentionally omitted from this paragraph? (Somewhere about here, I started thinking about "automated" - I didn't see a clear definition of this in the document. I think I understand what you mean at a hand-waving level, but you might consider adding a definition earlier in the document, so that's clearer without relying on context clues. I'm not going to list them off, but starting in Section A.1.1. CONNECTION Related Transport Features, I'm seeing a lot of analysis that includes some transport protocols and doesn't include others. I'm comparing o Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. Implementation: via a parameter in CONNECT.SCTP. Implementation over TCP: not possible. Implementation over UDP: not possible. which includes TCP, SCTP, and UDP, to something like o Hand over a message to reliably transfer during connection establishment Protocols: SCTP Functional because this can only work if the message is limited in size, making it closely tied to properties of the data that an application sends or expects to receive. Implementation: via a parameter in CONNECT.SCTP. Implementation over UDP: not possible. which does not mention TCP. There are a bunch of examples with this kind of omission. Is it worth showing a complete set of "Implementation over $Transport: not possible"s for each feature? If this next is too much trouble, do the right thing, but I notice that o Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP. Implementation over UDP: not possible (UDP is unreliable and there is no connection timeout). includes a parenthetical explanation of why a function is not possible to implement on a specific transport protocol, but most "not possible" entries don't have such an explanation. I mention this now, both because it might reduce the number of conversations with reviewers and ADs that you have starting with Last Call, and because you folks are likely the best equipped to add these explanations now, rather than someone else trying to guess what you were thinking later. And, while I was thinking about that, I started thinking about entries like Implementation over UDP: Do nothing (this is irrelevant in case of UDP because there, reliable data delivery is not assumed). and wondered how many of the "not possible" entries in the appendix might be "do nothing". If you had parenthetical explanations for why something is "not possible", or why an implementation might "do nothing", that would probably sharpen the difference for the average reader =E2=80=A6 And finally, at a high level, I don't understand why there are "Implementation over $Protocol" lines so often that name $Protocols that weren't listed in "Protocols:" at the beginning of each description. I have several guesses about what that might mean, but I bet all of them are wrong, so I have to ask. To the details ... Is this text o Reliably transfer a message, with congestion control Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Implementation over TCP: via SEND.TCP. With SEND.TCP, messages will not be identifiable by the receiver. Implementation over UDP: not possible. saying o Reliably transfer a message, with congestion control ... Implementation over TCP: via SEND.TCP. With SEND.TCP, message boundaries will not be identifiable by the receiver, because TCP provides a stream service. ... or something else? I have the same question about the next one o Unreliably transfer a message Protocols: SCTP, UDP(-Lite) Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. ADDED. This differs from the 2 automatable transport features below in that it leaves the choice of congestion control open. Implementation: via SEND.SCTP or SEND.UDP(-Lite). Implementation over TCP: use SEND.TCP. With SEND.TCP, messages will be sent reliably, and they will not be identifiable by the receiver. ("message boundaries"?) In section A.2, I have the same "is SCTP out or in?" question, especially around In the following list, we precede a transport feature with "T:" if an implementation over TCP is possible, "U:" if an implementation over UDP is possible, and "TU:" if an implementation over either TCP or UDP is possible. I don't understand A.2.1. CONNECTION Related Transport Features ESTABLISHMENT: o T: Hand over a message to reliably transfer (possibly multiple times) before connection establishment Is this saying "possibly retransmitting multiple times to achieve reliability", or something else? --00000000000009ecf505728fb03f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear TAPsters,=C2=A0

I've completed= my AD review for this document, and have two high-level responses:=C2=A0
  • This looks good, and=C2=A0
  • I only have 8 pages of = comments ...
Please look these over, and ask for explanations= if you need them. When we work through my comments, I'll request Last = Call.

And thanks for your work to date.=C2= =A0

Spencer

I'm = looking at this text

=C2=A0 =C2=A0Because the cons= idered
=C2=A0 =C2=A0transport protocols conjointly cover a wide r= ange of transport
=C2=A0 =C2=A0features, there is reason to hope = that the resulting set (and the
=C2=A0 =C2=A0reasoning that led t= o it) will also apply to many aspects of other
=C2=A0 =C2=A0trans= port protocols.

and wondering whether it's acc= urate to say "many aspects of other transport protocols that may be in= use today, or may be designed in the future"?=C2=A0

Part of my question is wrapped up in discussions about whether QUIC= is a one-off new transport protocol, or whether QUIC is the first example = of a new generation of transport protocols that are now worth designing bec= ause we know how to deploy them.

This text

=C2=A0 =C2=A0For example, it does not help an
= =C2=A0 =C2=A0application that talks to a library which offers its own
=
=C2=A0 =C2=A0communication interface if only the underlying Berkeley S= ockets API
=C2=A0 =C2=A0is extended to offer "unordered mess= age delivery", but the library
=C2=A0 =C2=A0only exposes an = ordered bytestream.=C2=A0

read oddly to me - I thi= nk the first "only" could be removed, unless I'm missing your= point, but please take a look at that sentence for clarity.=C2=A0

This text

=C2=A0 =C2=A0This "= ;minimal set" can be implemented one-sided over TCP (or UDP, if
<= div>=C2=A0 =C2=A0certain limitations are put in place).=C2=A0 This means th= at a sender-side
=C2=A0 =C2=A0transport system can talk to a stan= dard TCP (or UDP) receiver, and a
=C2=A0 =C2=A0receiver-side tran= sport system can talk to a standard TCP (or UDP)
=C2=A0 =C2=A0sen= der.

was a bit difficult for me to read, and seems= to mix explaining what "one-sided" means with the explanation th= at "one-sided" also applies to UDP, if certain limitations are pu= t in place. I wonder if it is accurate to say=C2=A0

=C2=A0 =C2=A0This "minimal set" can be implemented "one-si= ded" over TCP.=C2=A0 This means=C2=A0
=C2=A0 =C2=A0that a se= nder-side transport system can talk to a standard TCP receiver,
= =C2=A0 =C2=A0and a receiver-side transport system can talk to a standard TC= P sender.
=C2=A0 =C2=A0If certain limitations are put in place, t= he "minimal set" can also be=C2=A0
=C2=A0 =C2=A0impleme= nted "one-sided" over UDP.

Is "ungr= ouped communication" in=C2=A0

=C2=A0 =C2=A0Fo= r ungrouped connections, early configuration is necessary because
=C2=A0 =C2=A0it allows the transport system to know which protocols it sho= uld try
=C2=A0 =C2=A0to use.=C2=A0

a wel= l-understood term? I can guess at the meaning, but I'd be guessing, and= RFCs 8095 and 8304 don't define or use either term.(Further down, I al= so see "grouped communications", and I'm guessing what that m= eans, too, and Section 3.2.1 is even called "Connection groups", = but doesn't clearly define what that means)

I = don't disagree with=C2=A0

=C2=A0 Note that thi= s decision tree is not optimal for all cases.=C2=A0 For
=C2=A0 = =C2=A0example, if an application wants to use "Specify checksum covera= ge
=C2=A0 =C2=A0used by the sender", which is only offered b= y UDP-Lite, and
=C2=A0 =C2=A0"Configure priority or weight f= or a scheduler", which is only offered
=C2=A0 =C2=A0by SCTP,= the above decision tree will always choose UDP-Lite, making
=C2= =A0 =C2=A0it impossible to use SCTP's schedulers with priorities betwee= n
=C2=A0 =C2=A0grouped connections.=C2=A0 The transport system mu= st know which choice is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^^^^^^^^^
=C2=A0 =C2=A0more important for the applicat= ion in order to make the best
=C2=A0 =C2=A0^^^^^^^^^^^^^^^^^^^^^^= ^^^^^^^^^^^^
=C2=A0 =C2=A0decision.=C2=A0 We caution implementers= to be aware of the full set of
=C2=A0 =C2=A0trade-offs, for whic= h we recommend consulting the list in
=C2=A0 =C2=A0Appendix A.2.1= when deciding how to initialize a connection.

but= I'm not sure how a general-purpose transport system will know which ch= oice is more important for any arbitrary application. I see the Is this adv= ice transport system implementers can act on?

This= isn't a big deal, but=C2=A0

=C2=A0 This also = means that the active opening side is assumed to be the
=C2=A0 = =C2=A0first side sending data.

seems really reason= able for the vast majority of (client-server) applications, but I wonder if= peer-to-peer applications will trip over a problem here ("I open a co= nnection to you, but you already had data queued for me since we last conne= cted and you sent it immediately" could be a scenario for SMTP or DTN,= I guess). But I'll let you folks think about that.

This is a nit, but

=C2=A0 o=C2=A0 A buffer l= imit (in bytes); when the sender has less then the
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^ than

In this text,=C2=A0

=C2=A0 o=C2=A0 Reliability: t= his parameter is used to convey a choice of: fully
=C2=A0 =C2=A0 = =C2=A0 reliable (!UDP), unreliable without congestion control, unreliable
=C2=A0 =C2=A0 =C2=A0 (!UDP), partially reliable (see [RFC3758] and= [RFC7496] for
=C2=A0 =C2=A0 =C2=A0 details on how to specify par= tial reliability) (!UDP).=C2=A0

it took me some re= -reading to figure out that "unreliable (!UDP)" meant something b= esides JUST "unreliable" (because UDP is "unreliable without= congestion control"). Could this be clearer? I wonder about "unr= eliable with congestion control (!UDP)", but I'm guessing that thi= s is the distinction you're making.

This text = in 7.=C2=A0 Security Considerations

=C2=A0 =C2=A0A= uthentication, confidentiality protection, and integrity protection
=C2=A0 =C2=A0are identified as transport features by [RFC8095].=C2=A0 As= currently
=C2=A0 =C2=A0deployed in the Internet, these features = are generally provided by a
=C2=A0 =C2=A0protocol or layer on top= of the transport protocol; no current full-
=C2=A0 =C2=A0feature= d standards-track transport protocol provides all of these
=C2=A0= =C2=A0transport features on its own.=C2=A0 Therefore, these transport feat= ures
=C2=A0 =C2=A0are not considered in this document, with the e= xception of native
=C2=A0 =C2=A0authentication capabilities of TC= P and SCTP for which the security
=C2=A0 =C2=A0considerations in = [RFC5925] and [RFC4895] apply.=C2=A0 The minimum
=C2=A0 =C2=A0sec= urity requirements for a transport system are discussed in a
=C2= =A0 =C2=A0separate document [I-D.ietf-taps-transport-security].
<= br>
confuses me, because I think at least two things are in play.= First, I think the point you're probably making is that the underlying= transport protocols remain unmodified, so the security considerations for = each of those protocols apply unchanged, and this document isn't doing = anything to create new security considerations. So, modulo SECDIR and SEC A= D comments, I think that's all you need to say.=C2=A0

Second, you guys are the experts, but I think a reference to [I-D.i= etf-taps-transport-security] isn't actually needed for this document, b= ecause that document surveys security protocols, rather than specifying min= imum security requirements. That document might someday discuss the minimum= security requirements, in the way this document discusses the minimum set = of transport services, but at least in=C2=A0 https://tools.ietf.org/html= /draft-ietf-taps-transport-security-02 that document is much more compa= rable to RFCs 8095 and 8304 than to this document.=C2=A0

In Informative References, I see=C2=A0

=C2= =A0 [RFC7305]=C2=A0 Lear, E., Ed., "Report from the IAB Workshop on In= ternet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Technolog= y Adoption and Transition (ITAT)", RFC 7305,
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI 10.17487/RFC7305, July 2014,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.rfc-editor.org/info/rfc7305>.







=C2=A0 = =C2=A0We approach the construction of a minimal set of transport features
=C2=A0 =C2=A0in the following way:

=C2=A0= =C2=A01.=C2=A0 Categorization: the superset of transport features from [RF= C8303]
=C2=A0 =C2=A0 =C2=A0 =C2=A0is presented, and transport fea= tures are categorized for later
=C2=A0 =C2=A0 =C2=A0 =C2=A0reduct= ion.
=C2=A0 =C2=A02.=C2=A0 Reduction: a shorter list of transport= features is derived from
=C2=A0 =C2=A0 =C2=A0 =C2=A0the categori= zation in the first step.=C2=A0 This removes all transport
=C2=A0= =C2=A0 =C2=A0 =C2=A0features that do not require application-specific know= ledge or
=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be implemented with TC= P or UDP.
=C2=A0 =C2=A03.=C2=A0 Discussion: the resulting list sh= ows a number of peculiarities
=C2=A0 =C2=A0 =C2=A0 =C2=A0that are= discussed, to provide a basis for constructing the
=C2=A0 =C2=A0= =C2=A0 =C2=A0minimal set.
=C2=A0 =C2=A04.=C2=A0 Construction: Ba= sed on the reduced set and the discussion of the
=C2=A0 =C2=A0 = =C2=A0 =C2=A0transport features therein, a minimal set is constructed.

=C2=A0 =C2=A0The first three steps as well as the unde= rlying rationale for
=C2=A0 =C2=A0constructing the minimal set ar= e described in this appendix.=C2=A0 The
=C2=A0 =C2=A0minimal set = itself is described in Section 3.

would have been = clearer to me, if each step was labeled with the part of the document where= this work appears (so, step 1 would be labeled "Section A.1", et= c.), rather than providing the pointers at the end of the list. I couldn= 9;t tell whether you meant that these were the steps you took in the workin= g group, or whether this was the organization of this appendix (plus Sectio= n 3), until I got to the paragraph at the end.=C2=A0

Does=C2=A0

=C2=A0 Finally, some transport featu= res are aggregated and/or slightly
=C2=A0 =C2=A0changed in the de= scription below.=C2=A0 These transport features are
=C2=A0 =C2=A0= marked as "ADDED".=C2=A0 The corresponding transport features are=
=C2=A0 =C2=A0automatable, and they are listed immediately below = the "ADDED"
=C2=A0 =C2=A0transport feature.
<= br>
mean "aggregated and/or slightly change from [RFC8303]&q= uot;?

I have the same question with=C2=A0

=C2=A0 =C2=A0transport features can be implemented by a transport system.= =C2=A0 For all
=C2=A0 =C2= =A0exists in "pass 2" of [RFC8303], a brief discussion on how to<= /div>
=C2=A0 =C2=A0implement them over TCP and/or UDP is included.

as I did above - is SCTP intentionally omitted from th= is paragraph?=C2=A0

(Somewhere about here, I start= ed thinking about "automated" - I didn't see a clear definiti= on of this in the document. I think I understand what you mean at a hand-wa= ving level, but you might consider adding a definition earlier in the docum= ent, so that's clearer without relying on context clues.=C2=A0

I'm not going to list them off, but starting in Sectio= n A.1.1.=C2=A0 CONNECTION Related Transport Features, I'm seeing a lot = of analysis that includes some transport protocols and doesn't include = others. I'm comparing=C2=A0

=C2=A0 o=C2=A0 Ind= icate (and/or obtain upon completion) an Adaptation Layer via
=C2= =A0 =C2=A0 =C2=A0 an adaptation code point
=C2=A0 =C2=A0 =C2=A0 P= rotocols: SCTP
=C2=A0 =C2=A0 =C2=A0 Functional because it allows = to send extra data for the sake of
=C2=A0 =C2=A0 =C2=A0 identifyi= ng an adaptation layer, which by itself is application-
=C2=A0 = =C2=A0 =C2=A0 specific.
=C2=A0 =C2=A0 =C2=A0 Implementation: via = a parameter in CONNECT.SCTP.
=C2=A0 =C2=A0 =C2=A0 Implementation = over TCP: not possible.
=C2=A0 =C2=A0 =C2=A0 Implementation over = UDP: not possible.

which includes TCP, SCTP, and U= DP, to something like=C2=A0

=C2=A0 o=C2=A0 Hand ov= er a message to reliably transfer during connection
=C2=A0 =C2=A0= =C2=A0 establishment
=C2=A0 =C2=A0 =C2=A0 Protocols: SCTP
<= div>=C2=A0 =C2=A0 =C2=A0 Functional because this can only work if the messa= ge is limited in



includes a parenthetical explanation of why a function is= not possible to implement on a specific transport protocol, but most "= ;not possible" entries don't have such an explanation. I mention t= his now, both because it might reduce the number of conversations with revi= ewers and ADs that you have starting with Last Call, and because you folks = are likely the best equipped to add these explanations now, rather than som= eone else trying to guess what you were thinking later.=C2=A0
And, while I was thinking about that, I started thinking about = entries like=C2=A0

=C2=A0 =C2=A0 =C2=A0Implementat= ion over UDP: Do nothing (this is irrelevant in case of
=C2=A0 = =C2=A0 =C2=A0 UDP because there, reliable data delivery is not assumed).

and wondered how many of the "not possible"= ; entries in the appendix might be "do nothing". If you had paren= thetical explanations for why something is "not possible", or why= an implementation might "do nothing", that would probably sharpe= n the difference for the average reader =E2=80=A6

= And finally, at a high level, I don't understand why there are "Im= plementation over $Protocol" lines so often that name $Protocols that = weren't listed in "Protocols:" at the beginning of each descr= iption. I have several guesses about what that might mean, but I bet all of= them are wrong, so I have to ask.=C2=A0

To the de= tails ...

Is this text=C2=A0

<= div>=C2=A0 o=C2=A0 Reliably transfer a message, with congestion control
=C2=A0 =C2=A0 =C2=A0 Protocols: SCTP
=C2=A0 =C2=A0 =C2=A0 = Functional because this is closely tied to properties of the data
=C2=A0 =C2=A0 =C2=A0 that an application sends or expects to receive.
=C2=A0 =C2=A0 =C2=A0 Implementation: via SEND.SCTP.
=C2=A0 = =C2=A0 =C2=A0 Implementation over TCP: via SEND.TCP.=C2=A0 With SEND.TCP, m= essages
=C2=A0 =C2=A0 =C2=A0 will not be identifiable by the rece= iver.
=C2=A0 =C2=A0 =C2=A0 Implementation over UDP: not possible.=

saying

=C2=A0 o=C2=A0 Re= liably transfer a message, with congestion control
...
= =C2=A0 =C2=A0 =C2=A0 Implementation over TCP: via SEND.TCP.=C2=A0 With SEND= .TCP, message
=C2=A0 =C2=A0 =C2=A0 boundaries will not be identif= iable by the receiver, because TCP=C2=A0
=C2=A0 =C2=A0 =C2=A0 pro= vides a stream service.
...

or something= else?

I have the same question about the next one=

=C2=A0 o=C2=A0 Unreliably transfer a message
=C2=A0 =C2=A0 =C2=A0 Protocols: SCTP, UDP(-Lite)
=C2=A0 =C2= =A0 =C2=A0 Optimizing because only applications know about the time
=C2=A0 =C2=A0 =C2=A0 criticality of their communication, and reliably tr= ansfering a
=C2=A0 =C2=A0 =C2=A0 message is never incorrect for t= he receiver of a potentially
=C2=A0 =C2=A0 =C2=A0 unreliable data= transfer, it is just slower.
=C2=A0 =C2=A0 =C2=A0 ADDED.=C2=A0 T= his differs from the 2 automatable transport features
=C2=A0 =C2= =A0 =C2=A0 below in that it leaves the choice of congestion control open.
=C2=A0 =C2=A0 =C2=A0 Implementation: via SEND.SCTP or SEND.UDP(-Li= te).
=C2=A0 =C2=A0 =C2=A0 Implementation over TCP: use SEND.TCP.= =C2=A0 With SEND.TCP, messages
=C2=A0 =C2=A0 =C2=A0 will be sent = reliably, and they will not be identifiable by the
=C2=A0 =C2=A0 = =C2=A0 receiver.

("message boundaries"?)=

In section A.2, I have the same "is SCTP out= or in?" question, especially around=C2=A0

= =C2=A0 In the following list, we precede a transport feature with "T:&= quot; if an
=C2=A0 =C2=A0implementation over TCP is possible, &qu= ot;U:" if an implementation over
=C2=A0 =C2=A0UDP is possibl= e, and "TU:" if an implementation over either TCP or
= =C2=A0 =C2=A0UDP is possible.

I don't understa= nd=C2=A0

A.2.1.=C2=A0 CONNECTION Related Transport= Features

=C2=A0 =C2=A0ESTABLISHMENT:
=C2=A0 =C2=A0o=C2=A0 T: Hand over a message to reliably transf= er (possibly multiple
=C2=A0 =C2=A0 =C2=A0 times) before connecti= on establishment

Is this saying "possibly ret= ransmitting multiple times to achieve reliability", or something else?=
--00000000000009ecf505728fb03f-- From nobody Mon Aug 6 02:10: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 72EAA130EAF; Mon, 6 Aug 2018 02:10:20 -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 gN-b7dpdpIwO; Mon, 6 Aug 2018 02:10: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 7989F130EB0; Mon, 6 Aug 2018 02:10:17 -0700 (PDT) Received: from [192.168.1.100] (unknown [188.26.107.233]) (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 7263883975; Mon, 6 Aug 2018 11:10:14 +0200 (CEST) To: taps WG Cc: taps-chairs@ietf.org From: Fernando Gont 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: Date: Mon, 6 Aug 2018 10:58:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 06 Aug 2018 09:10:21 -0000 Folks, There has been some discussion over time about * draft-gont-taps-address-usage-problem-statement * draft-gont-taps-address-analysis The former describes problems we're facing nowaadys as a result of limited APIs, whereas the second discuss different properties of addresses, hopefully shedding some light on how we could make a better usage of the available addreses. Chairs: Do you think it would be reasonable to poll the wg for adoption of these two documents? 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 Mon Aug 6 02:45: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 457AB130EBC for ; Mon, 6 Aug 2018 02:45:10 -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 SdkQWjYdwGZS for ; Mon, 6 Aug 2018 02:45:05 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC61130F12 for ; Mon, 6 Aug 2018 02:45:05 -0700 (PDT) Received: from gorry-mac.erg.abdn.ac.uk (unknown [IPv6:2001:630:42:110:1464:b9e:8565:2e63]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5C44C1B0014F; Mon, 6 Aug 2018 10:44:54 +0100 (BST) To: Aaron Falk Cc: David Schinazi , Tommy Pauly , taps WG References: <5B573282.2050504@erg.abdn.ac.uk> <315C7FBD-D322-4506-813C-82BD0F612F28@gmail.com> From: Gorry Fairhurst Message-ID: <9e076fb7-c2fc-ac53-ce3e-3bd9429e931f@erg.abdn.ac.uk> Date: Mon, 6 Aug 2018 10:44:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <315C7FBD-D322-4506-813C-82BD0F612F28@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 06 Aug 2018 09:45:10 -0000 I quite like the idea of trying to design a simple registry format. If it looks good, I'd be happy to see this go forward. Gorry On 24/07/2018 19:13, Aaron Falk wrote: > > Caveat: I am not an expert on registries but my sense is that they are > most useful for interoperability. I think Gorry's concern about > redundancy much less important. And, in fact, it may take a while to > figure out how to describe the parameters. It might be more useful to > allow for variety in how these are defined to permit creative > approaches. YMMV of course. > > --aaron > > On 24 Jul 2018, at 10:06, G Fairhurst wrote: > > I don't yet know for sure myself.... > > On the one hand: I think a registry is a great way to capture the > "bundle" of things that we know about needing to send across the > API. Having common keywords (names) is a way to help people (who > wish to take this approach) from unwantingly choosing the same > function/param with a different name. And avoids accidentally > choosing the same key. I like these advantages. especially if I > thought people would use the registry. > > On the other hand, as an author I am still bemused about exactly > which list of items I think /need/ could appear in this registry. > I know some I'd expect, there are some I would not be surprised to > see, and some I'd expect not to see. Also this doesn't stop people > dreaming of slight variants of functions/params because they want > to be different or don't understand/agree with another definition, > especially since the concrete API isn't specified by the IETF. > > There are ways we could help support different uses, which I think > we should consider: > * We can define "well-known" IETF keywords that start with a > special prefix that require some IETF practice to assign; > * we can also define "public" keywords that have no prefix and are > first-come-first served, the easy way to get a unique entery. > * We can allow private defintions with some different prefix that > are not specified by IANA. (We simply preclude this format from > the registry). > > This approach has been used in many places, a simple, but similar > transport example is the Service Codes registry: > https://www.iana.org/assignments/service-codes/service-codes.xhtml > > - Let's all think about whether this is a useful approach for our API? > > Gorry > > > On 23/07/2018, 21:32, David Schinazi wrote: > > We had a similar discussion in the Babel WG regarding link > types in our data model - which isn't sent over the wire. > We landed on having an IANA registry of strings so there is > one place to find the mapping from string to specification. > We're planning on reserving all strings starting with an > underscore "_" for experimental use so the registry does not > get in anyone's way. > Apparently IANA registries have very low overhead. > Hope this helps. > > David > > On Jul 23, 2018, at 13:15, Tommy Pauly > wrote: > > Hello TAPS, > > Migrating a thread from GitHub to the email list, since it > needs broad WG input. I've pasted the discussion so far below. > > Essentially, the question is if we have a set of standard > properties for Transport Services APIs, should they have a > formal registry or not? > > Thanks, > Tommy > > ====================================== > > https://github.com/taps-api/drafts/issues/210 > > Philipp: > > We will end up with a set Turns out we might need a lot of > (protocol) specific properties, we should discuss whether > we need > an IANA registry of properties and how this will look like. > • Include Types ? > • Include Names ? > • Some numeric representation ? > What do we do with ENUM values? > > Mirja: > > I don't really understand why we would need a registry. > Who would > be using the registry? > > Tommy: > > I agree that a registry seems unnecessary; this is not a > matter > of protocol or on-the-wire standard. > > Philipp: > > If we don't want to clutter the basic API document, we > will end > up having at least a half a dozen documents defining specific > properties for different protocols. > Does anyone have a good alternative to collect all these > except > in an IANA registry? > > Tommy: > > We do not need to have documents specify every property. > Implementation should be allowed to extend as they need. > > Brian: > > this discussion does suggest that we might want to be more > explicit up front in the interface document about the > scope and > purpose of the document (i.e. this is meant primarily to > define a > standard API "shape", not the particular strings and > codepoints, > etc.). I'll file an issue. > > Colin: > > I agree with @tfpauly that we don't need to document every > property, and with @britram that we're documenting the > shape of > an abstract API, but I also see value in consistent property > naming across concrete implementations of that API. Some > form of > registry might make sense here. > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Mon Aug 6 11:27:25 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 21AE7130ED9 for ; Mon, 6 Aug 2018 11:27:23 -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 dwL8B3ej8pvp for ; Mon, 6 Aug 2018 11:27:20 -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 3D76D130E60 for ; Mon, 6 Aug 2018 11:27:20 -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 w76IQ4eq015443 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Aug 2018 20:26:04 +0200 Received: from [2001:bf0:c801:101:a8ae:3645:e6a5:af58] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fmkBd-0005x7-KB; Mon, 06 Aug 2018 20:24:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Philipp S. Tiesel" In-Reply-To: <9e076fb7-c2fc-ac53-ce3e-3bd9429e931f@erg.abdn.ac.uk> Date: Mon, 6 Aug 2018 20:26:00 +0200 Cc: Aaron Falk , David Schinazi , Tommy Pauly , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B573282.2050504@erg.abdn.ac.uk> <315C7FBD-D322-4506-813C-82BD0F612F28@gmail.com> <9e076fb7-c2fc-ac53-ce3e-3bd9429e931f@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Taps] To registry, or not to registry? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 06 Aug 2018 18:27:23 -0000 Hi, I also think a simple registry format to collect the properties that = might be used with the transport API is useful. While re-structuring the properties for the interface-01 draft, a format = for such a registry was always one of the next steps I considered. For a minimal registry, I guess we need to document two things A) name/string representing the property B) origin of the definition (RFC, draft, experiment, vendor, person = requesting it, =E2=80=A6) If we want something more expressive, I see following candidates for = additional attributes derived from the properties discussions: c) some free-text description d) type (as defined in whatever will follow Sec. 12.1 in interface-01) e) scope (Selection Properties (stuff that effects the pre-connection) = Connection Properties (stuff that effects the connection), Message = Properties) f) level of abstraction (whether the effect of this property is = strictly defined or interpreted by the transport system) =20 For the name/string (A), I definitely want to separate have some prefix = that reflects the kind or origin. I am still unsure what works best. The Prefix should make sure experiment, vendor, and other properties = can=E2=80=99t squat the namespace for RFCs. Is this a good starting point? Am I missing some important attribute candidates? AVE! Philipp S. Tiesel / phils=E2=80=A6 > On 6. Aug 2018, at 11:44, Gorry Fairhurst = wrote: >=20 >=20 > I quite like the idea of trying to design a simple registry format. If = it looks good, I'd be happy to see this go forward. >=20 > Gorry >=20 > On 24/07/2018 19:13, Aaron Falk wrote: >>=20 >> Caveat: I am not an expert on registries but my sense is that they = are most useful for interoperability. I think Gorry's concern about = redundancy much less important. And, in fact, it may take a while to = figure out how to describe the parameters. It might be more useful to = allow for variety in how these are defined to permit creative = approaches. YMMV of course. >>=20 >> --aaron >>=20 >> On 24 Jul 2018, at 10:06, G Fairhurst wrote: >>=20 >> I don't yet know for sure myself.... >>=20 >> On the one hand: I think a registry is a great way to capture the >> "bundle" of things that we know about needing to send across the >> API. Having common keywords (names) is a way to help people (who >> wish to take this approach) from unwantingly choosing the same >> function/param with a different name. And avoids accidentally >> choosing the same key. I like these advantages. especially if I >> thought people would use the registry. >>=20 >> On the other hand, as an author I am still bemused about exactly >> which list of items I think /need/ could appear in this registry. >> I know some I'd expect, there are some I would not be surprised to >> see, and some I'd expect not to see. Also this doesn't stop people >> dreaming of slight variants of functions/params because they want >> to be different or don't understand/agree with another definition, >> especially since the concrete API isn't specified by the IETF. >>=20 >> There are ways we could help support different uses, which I think >> we should consider: >> * We can define "well-known" IETF keywords that start with a >> special prefix that require some IETF practice to assign; >> * we can also define "public" keywords that have no prefix and are >> first-come-first served, the easy way to get a unique entery. >> * We can allow private defintions with some different prefix that >> are not specified by IANA. (We simply preclude this format from >> the registry). >>=20 >> This approach has been used in many places, a simple, but similar >> transport example is the Service Codes registry: >> https://www.iana.org/assignments/service-codes/service-codes.xhtml >>=20 >> - Let's all think about whether this is a useful approach for our = API? >>=20 >> Gorry >>=20 >>=20 >> On 23/07/2018, 21:32, David Schinazi wrote: >>=20 >> We had a similar discussion in the Babel WG regarding link >> types in our data model - which isn't sent over the wire. >> We landed on having an IANA registry of strings so there is >> one place to find the mapping from string to specification. >> We're planning on reserving all strings starting with an >> underscore "_" for experimental use so the registry does not >> get in anyone's way. >> Apparently IANA registries have very low overhead. >> Hope this helps. >>=20 >> David >>=20 >> On Jul 23, 2018, at 13:15, Tommy Pauly > > wrote: >>=20 >> Hello TAPS, >>=20 >> Migrating a thread from GitHub to the email list, since it >> needs broad WG input. I've pasted the discussion so far = below. >>=20 >> Essentially, the question is if we have a set of standard >> properties for Transport Services APIs, should they have a >> formal registry or not? >>=20 >> Thanks, >> Tommy >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> https://github.com/taps-api/drafts/issues/210 >>=20 >> Philipp: >>=20 >> We will end up with a set Turns out we might need a lot of >> (protocol) specific properties, we should discuss whether >> we need >> an IANA registry of properties and how this will look = like. >> =E2=80=A2 Include Types ? >> =E2=80=A2 Include Names ? >> =E2=80=A2 Some numeric representation ? >> What do we do with ENUM values? >>=20 >> Mirja: >>=20 >> I don't really understand why we would need a registry. >> Who would >> be using the registry? >>=20 >> Tommy: >>=20 >> I agree that a registry seems unnecessary; this is not a >> matter >> of protocol or on-the-wire standard. >>=20 >> Philipp: >>=20 >> If we don't want to clutter the basic API document, we >> will end >> up having at least a half a dozen documents defining = specific >> properties for different protocols. >> Does anyone have a good alternative to collect all these >> except >> in an IANA registry? >>=20 >> Tommy: >>=20 >> We do not need to have documents specify every property. >> Implementation should be allowed to extend as they need. >>=20 >> Brian: >>=20 >> this discussion does suggest that we might want to be more >> explicit up front in the interface document about the >> scope and >> purpose of the document (i.e. this is meant primarily to >> define a >> standard API "shape", not the particular strings and >> codepoints, >> etc.). I'll file an issue. >>=20 >> Colin: >>=20 >> I agree with @tfpauly that we don't need to document every >> property, and with @britram that we're documenting the >> shape of >> an abstract API, but I also see value in consistent = property >> naming across concrete implementations of that API. Some >> form of >> registry might make sense here. >>=20 >> =20 From nobody Mon Aug 6 13:02: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 29499129AB8; Mon, 6 Aug 2018 13:02:18 -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 WRs_2LOQWtQJ; Mon, 6 Aug 2018 13:02:14 -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 AC71112426A; Mon, 6 Aug 2018 13:02:14 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id n6-v6so15343432qtl.4; Mon, 06 Aug 2018 13:02:14 -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=mp9OpIN5+2aho2SqWKN0vpsJmT81yO2OWHVEuu5Dvy0=; b=tUHGqh2EosC2DeSTj+hu1jqhDd3aXKYTOU//+SyDZiYDRzLop57CJE6zKXP3rVtnpj ijsU4hH4GdbBB0gIrZWDyv+hY1i/4WTEHynz57Ze/lMu13BbpCIeSjw9JTw5xtSBZKtS saR2duPIRtZs0xMF3GuAVItgre050zzNi7myzpugGuAxzTAvvQY4MK5l1U7zFlq55J06 23rj2PFBYuzxXm22qlg2W0d7wv31zK51ajmMAFMw7dLkaAYoE+VDPTttEyG2f1QDtyTy kHnRtImKGnq+z31yiuSkRt340CGIueTGaedIhuOB5Jorb3do54PEb5GwnpQhrnEV+OeS OuWQ== 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=mp9OpIN5+2aho2SqWKN0vpsJmT81yO2OWHVEuu5Dvy0=; b=h9iXl2ldO1/URYjKN70R1pB4htWfOE9lFUszdLD/BMJ0vjH0exny+CHewXSba4jomm TLvw5Tp741CGPuct8v38hzKC1oG+K1wB/8xg4lzkuNPxGTKsTeiM3xrBvSbbxgp4v5uJ CK/zdZU7xIIqTGoOlNGRI3fFg1FELoA/n2XKsuuctxAMXya6msFlGu5KozqPZH5M8E6W 8Ta1lSjTZehgqeFYqvMb1JZ7P7lIdk5IKRDKMgSvHz5gNveQIS9kqwhZcvYKdDppTZSn qRMrK+klWubih+taWtyOWSevjnWr64ZN3eYJIj9t1dqqXW+8vQcP2ort1ke9R1f58ICL 9Utw== X-Gm-Message-State: AOUpUlEwHGw7wKYfDyanYoB3cWTcCyX9Bqt7P/fJRwN/rD1pgfesz9Bq n73hHU3WXNu3GKsRqZmKE9EpDWxi X-Google-Smtp-Source: AAOMgpdBB5gdOhO/2+7v+5M9945m1z+zdsm6K/FKHGmuBQNFMsh4dGEBkWokD25DFi6Tui9k9ADcjQ== X-Received: by 2002:aed:3966:: with SMTP id l93-v6mr16460128qte.48.1533585733605; Mon, 06 Aug 2018 13:02:13 -0700 (PDT) Received: from [172.19.36.224] ([2001:4878:a000:3000:94fc:5d5b:c97d:e5f0]) by smtp.gmail.com with ESMTPSA id 192-v6sm6437076qkf.74.2018.08.06.13.02.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 13:02:13 -0700 (PDT) From: "Aaron Falk" To: "Fernando Gont" Cc: "taps WG" , taps-chairs@ietf.org Date: Mon, 06 Aug 2018 16:02:11 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1817A91E-AA4A-4CD2-9BB5-397B896A5951_=" Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 06 Aug 2018 20:02:18 -0000 --=_MailMate_1817A91E-AA4A-4CD2-9BB5-397B896A5951_= Content-Type: text/plain; format=flowed Hi Fernando- draft-gont-taps-address-usage-problem-statement says > This document analyzes the impact of a number of properties of IPv6 > addresses on areas such as security and privacy, and analyzes how > IPv6 addresses are curently generated and employed by different > operating systems and applications. Finally, it provides a problem > statement by identifying and analyzing gaps that prevent systems > and > applications from fully-leveraging IPv6 addressing capabilities, > setting the basis for further work that could fill those gaps. I think the applicability of this work goes potentially far beyond TAPS as it applies to any application's use of IPv6 addresses. I'm a little worried that this wg doesn't contain sufficiently broad perspective to make recommendations. Indeed, I see TAPS as a consumer of this doc more than source of the recommendations. My opinion is that this is kind of out of scope for our wg. I would support another group with the right expertise to support it (maybe 6MAN or V6OPS). I think TAPS would provide some valuable input but I don't think we should be the venue for it's development. If the working group speaks up, I can be persuaded otherwise. --aaron On 6 Aug 2018, at 4:58, Fernando Gont wrote: > Folks, > > There has been some discussion over time about > > * draft-gont-taps-address-usage-problem-statement > * draft-gont-taps-address-analysis > > The former describes problems we're facing nowaadys as a result of > limited APIs, whereas the second discuss different properties of > addresses, hopefully shedding some light on how we could make a better > usage of the available addreses. > > Chairs: Do you think it would be reasonable to poll the wg for > adoption > of these two documents? > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 --=_MailMate_1817A91E-AA4A-4CD2-9BB5-397B896A5951_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hi Fernando-

draft-gont-taps-address-usage-problem-statement says

This document analyzes the impac= t of a number of properties of IPv6
addresses on areas such as security and privacy, and analyzes how
IPv6 addresses are curently generated and employed by different
operating systems and applications. Finally, it provides a problem statement by identifying and analyzing gaps that prevent systems and applications from fully-leveraging IPv6 addressing capabilities,
setting the basis for further work that could fill those gaps.

I think the applicability of this work goes = potentially far beyond TAPS as it applies to any application's use of IPv= 6 addresses. I'm a little worried that this wg doesn't contain sufficien= tly broad perspective to make recommendations. Indeed, I see TAPS as a c= onsumer of this doc more than source of the recommendations. My opinion = is that this is kind of out of scope for our wg. I would support another= group with the right expertise to support it (maybe 6MAN or V6OPS). I t= hink TAPS would provide some valuable input but I don't think we should b= e the venue for it's development.

If the working group speaks up, I can be persuaded otherw= ise.

--aaron


On 6 Aug 2018, at 4:58, Fernando Gont wrote:

Folks,

There has been some discussion over time about

* draft-gont-taps-address-usage-problem-statement
* draft-gont-taps-address-analysis

The former describes problems we're facing nowaadys as a result of
limited APIs, whereas the second discuss different properties of
addresses, hopefully shedding some light on how we could make a better usage of the available addreses.

Chairs: Do you think it would be reasonable to poll the wg for adoption of these two documents?

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

--=_MailMate_1817A91E-AA4A-4CD2-9BB5-397B896A5951_=-- From nobody Tue Aug 7 02:47: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 CF4AB130F84; Tue, 7 Aug 2018 02:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 cYtTNK7cbikZ; Tue, 7 Aug 2018 02:47:41 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03AD130F82; Tue, 7 Aug 2018 02:47:39 -0700 (PDT) Received: from [192.168.1.105] (unknown [188.26.107.233]) (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 56B94843DC; Tue, 7 Aug 2018 11:47:25 +0200 (CEST) To: Aaron Falk Cc: taps WG , taps-chairs@ietf.org References: From: Fernando Gont 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: <15865cd8-6e4e-0c49-a63b-5d53d662c8fb@si6networks.com> Date: Mon, 6 Aug 2018 22:51:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 09:47:43 -0000 On 08/06/2018 10:02 PM, Aaron Falk wrote: > Hi Fernando- > > draft-gont-taps-address-usage-problem-statement says > > This document analyzes the impact of a number of properties of IPv6 > addresses on areas such as security and privacy, and analyzes how > IPv6 addresses are curently generated and employed by different > operating systems and applications. Finally, it provides a problem > statement by identifying and analyzing gaps that prevent systems and > applications from fully-leveraging IPv6 addressing capabilities, > setting the basis for further work that could fill those gaps. > > I think the applicability of this work goes potentially far beyond TAPS > as it applies to any application's use of IPv6 addresses. I'm a little > worried that this wg doesn't contain sufficiently broad perspective to > make recommendations. FWIW, these doc don't try to make recommendations, but rather discuss the topic. Me, I see your point. Although, based on recent discussions on the taps list, it seems folks are willing to e.g. make decisions/recommendations regarding e.g. how to use addresses by default. > Indeed, I see TAPS as a consumer of this doc more > than source of the recommendations. My opinion is that this is kind of > out of scope for our wg. I would support another group with the right > expertise to support it (maybe 6MAN or V6OPS). I think TAPS would > provide some valuable input but I don't think we should be the venue for > it's development. FWIW, I brought this to taps upon suggestion I got on 6man... Thanks! CHeers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 7 04:59:43 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 A7AE8130FDB; Tue, 7 Aug 2018 04:59:41 -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 LCgc8EMW6xGb; Tue, 7 Aug 2018 04:59:39 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B26130FD7; Tue, 7 Aug 2018 04:59:39 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [173.38.220.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 301F72D4F96; Tue, 7 Aug 2018 11:59:38 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 1FE7A372009; Tue, 7 Aug 2018 13:59:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan In-Reply-To: Date: Tue, 7 Aug 2018 13:59:34 +0200 Cc: Fernando Gont , taps-chairs@ietf.org, taps WG , Bob Hinden Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 11:59:42 -0000 > draft-gont-taps-address-usage-problem-statement says >=20 > This document analyzes the impact of a number of properties of IPv6 > addresses on areas such as security and privacy, and analyzes how > IPv6 addresses are curently generated and employed by different > operating systems and applications. Finally, it provides a problem > statement by identifying and analyzing gaps that prevent systems and > applications from fully-leveraging IPv6 addressing capabilities, > setting the basis for further work that could fill those gaps. >=20 > I think the applicability of this work goes potentially far beyond = TAPS as it applies to any application's use of IPv6 addresses. I'm a = little worried that this wg doesn't contain sufficiently broad = perspective to make recommendations. Indeed, I see TAPS as a consumer of = this doc more than source of the recommendations. My opinion is that = this is kind of out of scope for our wg. I would support another group = with the right expertise to support it (maybe 6MAN or V6OPS). I think = TAPS would provide some valuable input but I don't think we should be = the venue for it's development. In 6man we have specifed how addresses are assigned to a link, different = =E2=80=9Ctypes=E2=80=9D of address and a set of properties that can be = associated with an address (or prefix). E.g: - addresses have lifetimes, (but they can be ripped away from under you = with little notice) - the choice of source address essentially chooses exit path in the = network - addresses have different privacy properties. statically configured = and in DNS, versus randomly generated changing every hour - addresses have different reachability, e.g. link-local, ULA and = global. - an IPv6 interface can have many addresses of different properties = assigned to it =46rom a 6man perspective, that=E2=80=99s where our competency ends. We = do not know how this should be exposed to applications or how the = transport layers should deal with it. It might not be taps, but this is something we=E2=80=99d sorely want to = punt up from the networking layer. Best regards, Ole 6man co-chair. From nobody Tue Aug 7 08:27: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 60CD1130EE3; Tue, 7 Aug 2018 08:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hD5wc-SA1yYe; Tue, 7 Aug 2018 08:27:09 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F789130E47; Tue, 7 Aug 2018 08:27:09 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 44D4B1B0023F; Tue, 7 Aug 2018 16:26:54 +0100 (BST) Message-ID: <5B69BA3D.9050505@erg.abdn.ac.uk> Date: Tue, 07 Aug 2018 16:26:53 +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: Ole Troan CC: Aaron Falk , Fernando Gont , taps-chairs@ietf.org, Bob Hinden , taps WG References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 15:27:13 -0000 To me, this topic is tricky to position, and there are still multiple parts across the two documents. One way could be to agree the properties of different address types on scope and stability, devoid of API and Application-considerations - I at the moment don't currently understand this enough to say if this is a new statement about the network layer or is restating what has been said before, so to me at least this seems to need network-layer clue. I see there may be a network layer security concern that may drive some considerations (seems more like that part is in draft-gont-taps-address-analysis) . To answer the immediate question: I think this doesn't look like TAPS should adopt that document. If this ID needs transport clue and spans multiple transport protocols, that could be reviewed by TSVWG if this had already strong support elsewhere? There is a mention of an API and usage concern. I haven't worked out if that is transport guidance, or whether the required mechanisms actually resembles PvD usage, and therefore looks more like a network-issue, (of course this is without a need for signalling from the network to identify properties). Possibly there is also a need for a new API, and if that needs the IETF to do new work, then to me that does look a lot like source address selection in TAPS. There could be useful input here to a few paras in the TAPS architecture. It's not clear to me that would require a new draft though in TAPS to achieve this. Gorry On 07/08/2018, 12:59, Ole Troan wrote: >> draft-gont-taps-address-usage-problem-statement says >> >> This document analyzes the impact of a number of properties of IPv6 >> addresses on areas such as security and privacy, and analyzes how >> IPv6 addresses are curently generated and employed by different >> operating systems and applications. Finally, it provides a problem >> statement by identifying and analyzing gaps that prevent systems and >> applications from fully-leveraging IPv6 addressing capabilities, >> setting the basis for further work that could fill those gaps. >> >> I think the applicability of this work goes potentially far beyond TAPS as it applies to any application's use of IPv6 addresses. I'm a little worried that this wg doesn't contain sufficiently broad perspective to make recommendations. Indeed, I see TAPS as a consumer of this doc more than source of the recommendations. My opinion is that this is kind of out of scope for our wg. I would support another group with the right expertise to support it (maybe 6MAN or V6OPS). I think TAPS would provide some valuable input but I don't think we should be the venue for it's development. > In 6man we have specifed how addresses are assigned to a link, different “types” of address and a set of properties that can be associated with an address (or prefix). > E.g: > - addresses have lifetimes, (but they can be ripped away from under you with little notice) > - the choice of source address essentially chooses exit path in the network > - addresses have different privacy properties. statically configured and in DNS, versus randomly generated changing every hour > - addresses have different reachability, e.g. link-local, ULA and global. > - an IPv6 interface can have many addresses of different properties assigned to it > > From a 6man perspective, that’s where our competency ends. We do not know how this should be exposed to applications or how the transport layers should deal with it. > It might not be taps, but this is something we’d sorely want to punt up from the networking layer. > > Best regards, > Ole > 6man co-chair. > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Aug 7 09:09:46 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 6C92C130F76; Tue, 7 Aug 2018 09:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, 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 1JBcizKDbFSO; Tue, 7 Aug 2018 09:09:41 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5556F130E62; Tue, 7 Aug 2018 09:09:41 -0700 (PDT) Received: from [192.168.10.187] (30.51-175-112.customer.lyse.net [51.175.112.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 8E1832D4F96; Tue, 7 Aug 2018 16:09:38 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15G77) In-Reply-To: <5B69BA3D.9050505@erg.abdn.ac.uk> Date: Tue, 7 Aug 2018 18:09:34 +0200 Cc: Aaron Falk , Fernando Gont , taps-chairs@ietf.org, Bob Hinden , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B69BA3D.9050505@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 16:09:45 -0000 Gorry, Good points. Or it could be repositioned to a statement from the Internet ar= ea to the upper layer working groups. =E2=80=9CIPv6 Network layer addresses p= roperties and behaviors, please be aware.=E2=80=9D To me at least there seems to be a disconnect. Address properties, selection= and lifetimes are not dealt with well (if at all) by transport layer and ap= plication implementations.=20 Cheers=20 Ole > On 7 Aug 2018, at 17:26, Gorry Fairhurst wrote: >=20 > To me, this topic is tricky to position, and there are still multiple part= s across the two documents. >=20 > One way could be to agree the properties of different address types on sco= pe and stability, devoid of API and Application-considerations - I at the m= oment don't currently understand this enough to say if this is a new stateme= nt about the network layer or is restating what has been said before, so to m= e at least this seems to need network-layer clue. I see there may be a netw= ork layer security concern that may drive some considerations (seems more li= ke that part is in >=20 >=20 > draft-gont-taps-address-analysis) >=20 > . >=20 > To answer the immediate question: I think this doesn't look like TAPS shou= ld adopt that document. If this ID needs transport clue and spans multiple t= ransport protocols, that could be reviewed by TSVWG if this had already stro= ng support elsewhere? >=20 > There is a mention of an API and usage concern. I haven't worked out if th= at is transport guidance, or whether the required mechanisms actually resemb= les PvD usage, and therefore looks more like a network-issue, (of course thi= s is without a need for signalling from the network to identify properties).= >=20 > Possibly there is also a need for a new API, and if that needs the IETF to= do new work, then to me that does look a lot like source address selection i= n TAPS. There could be useful input here to a few paras in the TAPS architec= ture. It's not clear to me that would require a new draft though in TAPS to a= chieve this. >=20 > Gorry >=20 > On 07/08/2018, 12:59, Ole Troan wrote: >>> draft-gont-taps-address-usage-problem-statement says >>>=20 >>> This document analyzes the impact of a number of properties of IPv6 >>> addresses on areas such as security and privacy, and analyzes how >>> IPv6 addresses are curently generated and employed by different >>> operating systems and applications. Finally, it provides a problem >>> statement by identifying and analyzing gaps that prevent systems and >>> applications from fully-leveraging IPv6 addressing capabilities, >>> setting the basis for further work that could fill those gaps. >>>=20 >>> I think the applicability of this work goes potentially far beyond TAPS a= s it applies to any application's use of IPv6 addresses. I'm a little worrie= d that this wg doesn't contain sufficiently broad perspective to make recomm= endations. Indeed, I see TAPS as a consumer of this doc more than source of t= he recommendations. My opinion is that this is kind of out of scope for our w= g. I would support another group with the right expertise to support it (may= be 6MAN or V6OPS). I think TAPS would provide some valuable input but I don'= t think we should be the venue for it's development. >> In 6man we have specifed how addresses are assigned to a link, different =E2= =80=9Ctypes=E2=80=9D of address and a set of properties that can be associat= ed with an address (or prefix). >> E.g: >> - addresses have lifetimes, (but they can be ripped away from under you w= ith little notice) >> - the choice of source address essentially chooses exit path in the netw= ork >> - addresses have different privacy properties. statically configured and= in DNS, versus randomly generated changing every hour >> - addresses have different reachability, e.g. link-local, ULA and global= . >> - an IPv6 interface can have many addresses of different properties assi= gned to it >>=20 >> =46rom a 6man perspective, that=E2=80=99s where our competency ends. We d= o not know how this should be exposed to applications or how the transport l= ayers should deal with it. >> It might not be taps, but this is something we=E2=80=99d sorely want to p= unt up from the networking layer. >>=20 >> Best regards, >> Ole >> 6man co-chair. >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Aug 7 09:27:58 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 7322413102D; Tue, 7 Aug 2018 09:27:55 -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 oWEUMEaZ_3qN; Tue, 7 Aug 2018 09:27:52 -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 164EA127AC2; Tue, 7 Aug 2018 09:27:51 -0700 (PDT) Received: from [192.168.1.105] (unknown [188.26.107.233]) (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 BF1A182EB7; Tue, 7 Aug 2018 18:27:43 +0200 (CEST) To: gorry@erg.abdn.ac.uk, Ole Troan Cc: Aaron Falk , taps-chairs@ietf.org, Bob Hinden , taps WG References: <5B69BA3D.9050505@erg.abdn.ac.uk> From: Fernando Gont 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: Date: Tue, 7 Aug 2018 18:26:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <5B69BA3D.9050505@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 16:27:56 -0000 Hello, Gorry, On 08/07/2018 05:26 PM, Gorry Fairhurst wrote: > To me, this topic is tricky to position, and there are still multiple > parts across the two documents. > > One way could be to agree the properties of different address types on > scope and stability, devoid of API and Application-considerations -  I > at the moment don't currently understand this enough to say if this is a > new statement about the network layer or is restating what has been said > before, so to me at least this seems to need network-layer clue.  I see > there may be a network layer security concern that may drive some > considerations (seems more like that part is in >  draft-gont-taps-address-analysis) For the most part, address types are specified, but there's not much guidance on how to use them. Depending on the perspective, I guess one might argue that guidance should come from internet area (6man for the ipv6 specific case, and intarea for ipv4... or even both). >From another POV, this sees to be related with TAPs. If you hve an api, there's not much you will be able to do (at least in a proper way :-) ), without appropriate guidance. > To answer the immediate question: I think this doesn't look like TAPS > should adopt that document. If this ID needs transport clue and spans > multiple transport protocols, that could be reviewed by TSVWG if this > had already strong support elsewhere? > > There is a mention of an API and usage concern. I haven't worked out if > that is transport guidance, That's mostly a problem statement: we don't have appropriate APIs to fully leverage IPv6 addressing. [....] > Possibly there is also a need for a new API, and if that needs the IETF > to do new work, then to me that does look a lot like source address > selection in TAPS. There could be useful input here to a few paras in > the TAPS architecture. It's not clear to me that would require a new > draft though in TAPS to achieve this. Could you please rovide a reference to the document so that I can take a look and review? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 7 09: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 2FF44130F24; Tue, 7 Aug 2018 09:28:13 -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 O3sJiD4w5RNZ; Tue, 7 Aug 2018 09:28:10 -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 E2C10127AC2; Tue, 7 Aug 2018 09:28:09 -0700 (PDT) Received: from [192.168.1.105] (unknown [188.26.107.233]) (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 51C0682ED5; Tue, 7 Aug 2018 18:27:52 +0200 (CEST) To: Ole Troan , gorry@erg.abdn.ac.uk Cc: Aaron Falk , taps-chairs@ietf.org, Bob Hinden , taps WG References: <5B69BA3D.9050505@erg.abdn.ac.uk> From: Fernando Gont 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: Date: Tue, 7 Aug 2018 18:27:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 16:28:13 -0000 On 08/07/2018 06:09 PM, Ole Troan wrote: > Gorry, > > Good points. Or it could be repositioned to a statement from the Internet area to the upper layer working groups. “IPv6 Network layer addresses properties and behaviors, please be aware.” > > To me at least there seems to be a disconnect. Address properties, selection and lifetimes are not dealt with well (if at all) by transport layer and application implementations. FWIW, that's my take as well. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 7 10:01:10 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 38B81130E43; Tue, 7 Aug 2018 10:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_NONE=-0.0001, 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 ZsOrp3HosFcf; Tue, 7 Aug 2018 10:01:01 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 47A6E12777C; Tue, 7 Aug 2018 10:01:01 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w77Guurv031564; Tue, 7 Aug 2018 10:00:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=mC8S2CBM5B9Ve1Zf0HeuAPBkCJnf9t8jfwl9eyyhw9Y=; b=MgodvjBpBIngEi5sDS1vF12aIj86FGMN3J3wXiolamZ+Aiv4s2FFnUfRYv2rHSVK0ZbZ gR559Gih5ID1KF0fai3czA4+dk9Dua2us+ndFGoksxN11ROtNLc00mCvbl3sM77NvLeC kipq1PMWjsj2Rk7EiL7m5o3NMj3GabJVNy4jryr/gzgUKzeV3Rq/4zdj9++M9EW+RCNj LPVD6UmF4iWckOA9h/YwIMNkveLXjSq+nCRwdn0mMZk0nGBcrHtjQ4TSh34uq2IEVIkR JF5BdXyJJfBPjKkp3qVilLA8+VWpgO78NzTU5mI49m75QssEU1iTlK9WTXfiZwCUCYZs uA== Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2kn8tu4grd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Aug 2018 10:00:54 -0700 X-AuditID: 1142370c-c13ff70000000be7-52-5b69d0410119 Received: from crk-mmpp-sz03.euro.apple.com ( [17.66.12.165]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 91.BE.03047.140D96B5; Tue, 7 Aug 2018 18:00:49 +0100 (BST) Received: from [17.230.168.12] (unknown [17.230.168.12]) by crk-mmpp-sz03.euro.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PD300EXYOL9O130@crk-mmpp-sz03.euro.apple.com>; Tue, 07 Aug 2018 18:00:49 +0100 (IST) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 12.0 \(3445.100.13.1\)) From: Tommy Pauly In-reply-to: Date: Tue, 07 Aug 2018 10:00:58 -0700 Cc: gorry@erg.abdn.ac.uk, Ole Troan , Aaron Falk , taps-chairs@ietf.org, Bob Hinden , taps WG Content-transfer-encoding: quoted-printable Message-id: References: <5B69BA3D.9050505@erg.abdn.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.3445.100.13.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi6MSzVNfxQma0wal9chZtv6exWmx9v4/N 4smqN2wWr9tmM1pMblvBZnF71SJWizsxDuweB499ZPTo+fyCyWPnrLvsHkuW/GTy+HCohz2A NYrLJiU1J7MstUjfLoErY9Iv0YKFkhU/LzSwNzCuFeli5OSQEDCRuDftHmMXIxeHkMAKJomH zVfYIJzZTBKrL55i72Lk4BAWkJDYvCcRpIFZQEti/c7jTCA2r4CFRHfnOTBbWMBcYtXTOywg NpuAisTxbxuYQWxOAWeJuVt/MYLYLAKqEidWfGAGmc8ssJlR4u7P60wQQ7Ulnry7wAox1Ebi 3NHPTBBHdDJJzJn4D6xbREBTYu7zI0wQZ6tJzL/9gnUCo8AsJEfNQnLULCRzFzAyr2IULUrN Saw00kstLcrXSywoyEnVS87P3cQIDnJznh2Mrw4aHmIU4GBU4uFdfDgzWog1say4MvcQowQH s5IIb3IdUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvZCXmaCGB9MSS1OzU1ILUIpgsEwenVANj xPXKFw85dkkVzWNk7P11tejfAb1sw8kCV6yMb8d2JhzbuTUu/c7J5U2H2x58aby7WW+O4Ob8 3mvNc14HS54Mvde8P0bSUZpfRGjdhh9ufF2y73q+9WV+lOUVWB+q8EbKJObFM/GL3PZHtkuG nZv8zoXvTsyhrvWL5vh7pl6t+FJ1xPbgsmVBSizFGYmGWsxFxYkARePR+24CAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-07_06:, , signatures=0 Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 17:01:08 -0000 > On Aug 7, 2018, at 9:26 AM, Fernando Gont = wrote: >=20 > Hello, Gorry, >=20 > On 08/07/2018 05:26 PM, Gorry Fairhurst wrote: >> To me, this topic is tricky to position, and there are still multiple >> parts across the two documents. >>=20 >> One way could be to agree the properties of different address types = on >> scope and stability, devoid of API and Application-considerations - = I >> at the moment don't currently understand this enough to say if this = is a >> new statement about the network layer or is restating what has been = said >> before, so to me at least this seems to need network-layer clue. I = see >> there may be a network layer security concern that may drive some >> considerations (seems more like that part is in=20 >> draft-gont-taps-address-analysis) >=20 > For the most part, address types are specified, but there's not much > guidance on how to use them. Depending on the perspective, I guess one > might argue that guidance should come from internet area (6man for the > ipv6 specific case, and intarea for ipv4... or even both). >=20 >> =46rom another POV, this sees to be related with TAPs. If you hve an = api, > there's not much you will be able to do (at least in a proper way :-) = ), > without appropriate guidance. >=20 >=20 >=20 >> To answer the immediate question: I think this doesn't look like TAPS >> should adopt that document. If this ID needs transport clue and spans >> multiple transport protocols, that could be reviewed by TSVWG if this >> had already strong support elsewhere? >>=20 >> There is a mention of an API and usage concern. I haven't worked out = if >> that is transport guidance,=20 >=20 > That's mostly a problem statement: we don't have appropriate APIs to > fully leverage IPv6 addressing. >=20 >=20 > [....] >> Possibly there is also a need for a new API, and if that needs the = IETF >> to do new work, then to me that does look a lot like source address >> selection in TAPS. There could be useful input here to a few paras in >> the TAPS architecture. It's not clear to me that would require a new >> draft though in TAPS to achieve this. >=20 > Could you please rovide a reference to the document so that I can take = a > look and review? The GitHub for the documents is: https://github.com/taps-api/drafts https://taps-api.github.io/drafts/draft-ietf-taps-arch.html https://taps-api.github.io/drafts/draft-ietf-taps-interface.html https://taps-api.github.io/drafts/draft-ietf-taps-impl.html I imagine that we could have a *brief* mention in the architecture, but = more importantly provide a path selection property in the Interface/API = document, with an implementation considerations section in the = Implementation document. Having an internet area draft to refer to from = the API specification would be useful. Tommy >=20 > Thanks, > --=20 > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Aug 7 10:04:46 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 E2AA8131065; Tue, 7 Aug 2018 10:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i2-GQV1Ic3wn; Tue, 7 Aug 2018 10:04:42 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id C801812777C; Tue, 7 Aug 2018 10:04:41 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A168B1B0023F; Tue, 7 Aug 2018 18:04:32 +0100 (BST) Message-ID: <5B69D120.6030104@erg.abdn.ac.uk> Date: Tue, 07 Aug 2018 18:04:32 +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: Tommy Pauly CC: Fernando Gont , Aaron Falk , taps-chairs@ietf.org, Bob Hinden , Ole Troan , taps WG References: <5B69BA3D.9050505@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 17:04:45 -0000 On 07/08/2018, 18:00, Tommy Pauly wrote: > >> On Aug 7, 2018, at 9:26 AM, Fernando Gont wrote: >> >> Hello, Gorry, >> >> On 08/07/2018 05:26 PM, Gorry Fairhurst wrote: >>> To me, this topic is tricky to position, and there are still multiple >>> parts across the two documents. >>> >>> One way could be to agree the properties of different address types on >>> scope and stability, devoid of API and Application-considerations - I >>> at the moment don't currently understand this enough to say if this is a >>> new statement about the network layer or is restating what has been said >>> before, so to me at least this seems to need network-layer clue. I see >>> there may be a network layer security concern that may drive some >>> considerations (seems more like that part is in >>> draft-gont-taps-address-analysis) >> For the most part, address types are specified, but there's not much >> guidance on how to use them. Depending on the perspective, I guess one >> might argue that guidance should come from internet area (6man for the >> ipv6 specific case, and intarea for ipv4... or even both). >> >>> From another POV, this sees to be related with TAPs. If you hve an api, >> there's not much you will be able to do (at least in a proper way :-) ), >> without appropriate guidance. >> >> >> >>> To answer the immediate question: I think this doesn't look like TAPS >>> should adopt that document. If this ID needs transport clue and spans >>> multiple transport protocols, that could be reviewed by TSVWG if this >>> had already strong support elsewhere? >>> >>> There is a mention of an API and usage concern. I haven't worked out if >>> that is transport guidance, >> That's mostly a problem statement: we don't have appropriate APIs to >> fully leverage IPv6 addressing. >> >> >> [....] >>> Possibly there is also a need for a new API, and if that needs the IETF >>> to do new work, then to me that does look a lot like source address >>> selection in TAPS. There could be useful input here to a few paras in >>> the TAPS architecture. It's not clear to me that would require a new >>> draft though in TAPS to achieve this. >> Could you please rovide a reference to the document so that I can take a >> look and review? > The GitHub for the documents is: > > https://github.com/taps-api/drafts > > https://taps-api.github.io/drafts/draft-ietf-taps-arch.html > https://taps-api.github.io/drafts/draft-ietf-taps-interface.html > https://taps-api.github.io/drafts/draft-ietf-taps-impl.html > > I imagine that we could have a *brief* mention in the architecture, To be clear - this is what I had in mind, that we ensure we mention that source interface selection is something that the arch can handle - whether it be by properties, or the way security expectations are satisfied, the available PvDs etc. But nothing much. > but more importantly provide a path selection property in the Interface/API document, with an implementation considerations section in the Implementation document. Having an internet area draft to refer to from the API specification would be useful. A little here also could make sense. Gorry > Tommy >> Thanks, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Aug 7 10:12:00 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 1ABAD130ED6; Tue, 7 Aug 2018 10:11: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, 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 Orzx6UgOz-fh; Tue, 7 Aug 2018 10:11:56 -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 7C40712777C; Tue, 7 Aug 2018 10:11:56 -0700 (PDT) Received: from [192.168.1.105] (unknown [188.26.107.233]) (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 B2AF780D77; Tue, 7 Aug 2018 19:11:53 +0200 (CEST) To: Tommy Pauly Cc: gorry@erg.abdn.ac.uk, Ole Troan , Aaron Falk , taps-chairs@ietf.org, Bob Hinden , taps WG References: <5B69BA3D.9050505@erg.abdn.ac.uk> From: Fernando Gont 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: <39559ba1-c3d7-aac3-4835-150e434cd98d@si6networks.com> Date: Tue, 7 Aug 2018 19:11:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Progress on address usage documents X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 07 Aug 2018 17:11:59 -0000 On 08/07/2018 07:00 PM, Tommy Pauly wrote: >> Could you please rovide a reference to the document so that I can take a >> look and review? > > The GitHub for the documents is: > > https://github.com/taps-api/drafts > > https://taps-api.github.io/drafts/draft-ietf-taps-arch.html > https://taps-api.github.io/drafts/draft-ietf-taps-interface.html > https://taps-api.github.io/drafts/draft-ietf-taps-impl.html Will review and send comments. Thanks! > I imagine that we could have a *brief* mention in the architecture, but more importantly provide a path selection property in the Interface/API document> with an implementation considerations section in the Implementation document. Having an internet area draft to refer to from the API specification would be useful. One of the questions is: where to pursue this? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Aug 15 12:46:23 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 4C0D4130DE3; Wed, 15 Aug 2018 12:46:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aaron.falk@gmail.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153436238123.3143.8989718453200647742.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 12:46:21 -0700 Archived-At: Subject: [Taps] taps - New Meeting Session Request for IETF 103 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 19:46:22 -0000 A new meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat tsvarea quic panrg tls capport avtcore rtcweb ipsecme httpbis Second Priority: tcpinc mptcp saag mmusic tram irtfopen People who must be present: Aaron Falk Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Anna Brunstrom Tommy Pauly Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Aug 15 13:26:19 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 4283B124BE5; Wed, 15 Aug 2018 13:26:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aaron.falk@gmail.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153436477823.3089.4993351871673183900.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 13:26:18 -0700 Archived-At: Subject: [Taps] taps - Update to a Meeting Session Request for IETF 103 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2018 20:26:18 -0000 An update to a meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpbis ipsecme rtcweb avtcore capport tls panrg quic tsvarea rmcat ippm tsvwg iccrg tcpm dispatch maprg cfrg Second Priority: tcpinc mptcp saag mmusic tram irtfopen People who must be present: Aaron Falk Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Anna Brunstrom Tommy Pauly Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Aug 20 01:57:38 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03947130F20; Mon, 20 Aug 2018 01:57:37 -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 0jQn_PPrb9ri; Mon, 20 Aug 2018 01:57:27 -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 93DDC130F1F; Mon, 20 Aug 2018 01:57:26 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1frg02-000FmU-Hn; Mon, 20 Aug 2018 10:57:22 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1frfzx-000CwT-CT; Mon, 20 Aug 2018 10:57:22 +0200 From: Michael Welzl Message-Id: <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> Content-Type: multipart/mixed; boundary="Apple-Mail=_3D38BCFA-80AD-4279-801D-6CB64EA53AA6" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 20 Aug 2018 10:57:13 +0200 In-Reply-To: Cc: draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, theresa@inet.tu-berlin.de, taps WG To: Spencer Dawkins References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; 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: D2DBBE9F485BF4A973DC5F752739C3EE0FB24BF5 Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 08:57:37 -0000 --Apple-Mail=_3D38BCFA-80AD-4279-801D-6CB64EA53AA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Spencer! Thank you so much for your detailed work and all these comments! I'm commenting in line below, and marking my comments with "MW:". I'm terminating my responses with a "--". I'm attaching an update which incorporates the changes described in this = email, but I'm delaying its submission until it's clear that this = conversation has converged. Cheers, Michael --- Dear TAPsters,=20 I've completed my AD review for this document, and have two high-level = responses:=20 This looks good, and=20 I only have 8 pages of comments ... Please look these over, and ask for explanations if you need them. When = we work through my comments, I'll request Last Call. And thanks for your work to date.=20 Spencer I'm looking at this text Because the considered transport protocols conjointly cover a wide range of transport features, there is reason to hope that the resulting set (and the reasoning that led to it) will also apply to many aspects of other transport protocols. and wondering whether it's accurate to say "many aspects of other = transport protocols that may be in use today, or may be designed in the = future"?=20 Part of my question is wrapped up in discussions about whether QUIC is a = one-off new transport protocol, or whether QUIC is the first example of = a new generation of transport protocols that are now worth designing = because we know how to deploy them. MW: Done -- This text For example, it does not help an application that talks to a library which offers its own communication interface if only the underlying Berkeley Sockets API is extended to offer "unordered message delivery", but the library only exposes an ordered bytestream.=20 read oddly to me - I think the first "only" could be removed, unless I'm = missing your point, but please take a look at that sentence for clarity.=20= MW: Done (first "only" removed) -- This text This "minimal set" can be implemented one-sided over TCP (or UDP, if certain limitations are put in place). This means that a sender-side transport system can talk to a standard TCP (or UDP) receiver, and a receiver-side transport system can talk to a standard TCP (or UDP) sender. was a bit difficult for me to read, and seems to mix explaining what = "one-sided" means with the explanation that "one-sided" also applies to = UDP, if certain limitations are put in place. I wonder if it is accurate = to say=20 This "minimal set" can be implemented "one-sided" over TCP. This = means=20 that a sender-side transport system can talk to a standard TCP = receiver, and a receiver-side transport system can talk to a standard TCP = sender. If certain limitations are put in place, the "minimal set" can also = be=20 implemented "one-sided" over UDP. MW: Done -- Is "ungrouped communication" in=20 For ungrouped connections, early configuration is necessary because it allows the transport system to know which protocols it should try to use.=20 a well-understood term? I can guess at the meaning, but I'd be guessing, = and RFCs 8095 and 8304 don't define or use either term.(Further down, I = also see "grouped communications", and I'm guessing what that means, = too, and Section 3.2.1 is even called "Connection groups", but doesn't = clearly define what that means) MW: Good catch, thanks! I added "Connection Group" to the terminology = section; this text block also explains "grouped" and "ungrouped". -- I don't disagree with=20 Note that this decision tree is not optimal for all cases. For example, if an application wants to use "Specify checksum coverage used by the sender", which is only offered by UDP-Lite, and "Configure priority or weight for a scheduler", which is only offered by SCTP, the above decision tree will always choose UDP-Lite, making it impossible to use SCTP's schedulers with priorities between grouped connections. The transport system must know which choice is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ more important for the application in order to make the best ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ decision. We caution implementers to be aware of the full set of trade-offs, for which we recommend consulting the list in Appendix A.2.1 when deciding how to initialize a connection. but I'm not sure how a general-purpose transport system will know which = choice is more important for any arbitrary application. I see the Is = this advice transport system implementers can act on? MW: Agreed; I removed this sentence. -- This isn't a big deal, but=20 This also means that the active opening side is assumed to be the first side sending data. seems really reasonable for the vast majority of (client-server) = applications, but I wonder if peer-to-peer applications will trip over a = problem here ("I open a connection to you, but you already had data = queued for me since we last connected and you sent it immediately" could = be a scenario for SMTP or DTN, I guess). But I'll let you folks think = about that. MW: I added the following paragraph at the beginning of section 3 (as = the second para) to address this issue: The arguments laid out in Appendix A.3 ("discussion") were used to make the final representation of the minimal set as short, simple and general as possible. There may be situations where these arguments do not apply -- e.g., implementers may have specific reasons to expose multi-streaming as a visible functionality to applications, or the restrictive open / close semantics may be problematic under some circumstances. In such cases, the representation in Appendix A.2 ("reduction") should be considered. -- =20 =20 This is a nit, but o A buffer limit (in bytes); when the sender has less then the ^^^^ than MW: Done -- In this text,=20 o Reliability: this parameter is used to convey a choice of: fully reliable (!UDP), unreliable without congestion control, unreliable (!UDP), partially reliable (see [RFC3758] and [RFC7496] for details on how to specify partial reliability) (!UDP).=20 it took me some re-reading to figure out that "unreliable (!UDP)" meant = something besides JUST "unreliable" (because UDP is "unreliable without = congestion control"). Could this be clearer? I wonder about "unreliable = with congestion control (!UDP)", but I'm guessing that this is the = distinction you're making. MW: Good catch, thanks! And yes, that's the distinction. I changed this = to the following, to be explicit about congestion control for all = choices: o Reliability: this parameter is used to convey a choice of: fully reliable with congestion control (!UDP), unreliable without congestion control, unreliable with congestion control (!UDP), partially reliable with congestion control (see [RFC3758] and [RFC7496] for details on how to specify partial reliability) (!UDP). -- This text in 7. Security Considerations Authentication, confidentiality protection, and integrity protection are identified as transport features by [RFC8095]. As currently deployed in the Internet, these features are generally provided by a protocol or layer on top of the transport protocol; no current full- featured standards-track transport protocol provides all of these transport features on its own. Therefore, these transport features are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply. The minimum security requirements for a transport system are discussed in a separate document [I-D.ietf-taps-transport-security]. confuses me, because I think at least two things are in play. First, I = think the point you're probably making is that the underlying transport = protocols remain unmodified, so the security considerations for each of = those protocols apply unchanged, and this document isn't doing anything = to create new security considerations. So, modulo SECDIR and SEC AD = comments, I think that's all you need to say.=20 Second, you guys are the experts, but I think a reference to = [I-D.ietf-taps-transport-security] isn't actually needed for this = document, because that document surveys security protocols, rather than = specifying minimum security requirements. That document might someday = discuss the minimum security requirements, in the way this document = discusses the minimum set of transport services, but at least in = https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that = document is much more comparable to RFCs 8095 and 8304 than to this = document.=20 MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't = have section 5. I believe section 5 in this document is an effort to do the same as = minset does, here; are you maybe asking for this section of = [I-D.ietf-taps-transport-security] to use a more authoritative tone? Either way, as things stand now, the existence = of [I-D.ietf-taps-transport-security] is used as a justification to not = include the security related features of TCP and SCTP in the minimum set, and I = think this citation is necessary. -- In Informative References, I see=20 [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, . which is awesome (I wish more IETF people referred to IAB workshop = reports), but the only place I see it referred to is in A.3.1. Sending = Messages, Receiving Bytes:=20 For example, if an application requests to transfer fixed-size messages of 100 bytes with partial reliability, this needs the receiving application to be prepared to accept data in chunks of 100 bytes. If, then, some of these 100-byte messages are missing (e.g., if SCTP with Configurable Reliability is used), this is the expected application behavior. With TCP, no messages would be missing, but this is also correct for the application, and the possible retransmission delay is acceptable within the best effort service model [RFC7305]. Still, the receiving application would separate the byte stream into 100-byte chunks. I was at that workshop, and it was pretty wide-ranging, so you might = want to provide a section number with this reference to give an = inquiring reader a chance of finding what you're referring to (I'm = guessing the section number is 3.5, but I'm guessing).=20 MW: Done (and you guessed right). -- Just so you know - I did notice that Appendix A is two thirds of the = page count for this document, and I agree that the material belongs in = an appendix, and I think it's important for you to "show your work", in = case anyone ever needs to update the minimal set in the future. So, I = support what you're doing there. MW: Thanks :) -- You folks know what you actually did, but I'm hoping that=20 2. Reduction: a shorter list of transport features is derived from the categorization in the first step. This removes all transport features that do not require application-specific knowledge or cannot be implemented with TCP or UDP. was actually "cannot be implemented with TCP, SCTP, or UDP". Was that an = omission in this text, or do we need to chat?=20 MW: the point was that TCP and UDP can't work as a fall-back in case = e.g. SCTP isn't available. As stated at the beginning of the document, = the minset can be implemented "one-sided" over TCP. (and with some = limitations, also UDP). For example: it's fine (within "best effort") to = always send everything in order when an application allows out-of-order = delivery - but there's simply no way to implement SCTP's out-of-band = transmission of a number ("Indicate (and/or obtain upon completion) an = Adaptation Layer via an adaptation code point") with TCP or UDP. If an = application relies on that, TCP or UDP fall-backs become impossible. We = were asked to avoid writing using the term "fall-back", for good = reasons, but this particular sentence may have ended up being less clear = as we simply replaced "fall-back" with "implemented with". I changed the sentence as follows, is it better? NEW: This removes all transport features that do not require = application-specific knowledge or would result in semantically incorrect = behavior if they were implemented over TCP or UDP. -- This text, Appendix A. Deriving the minimal set We approach the construction of a minimal set of transport features in the following way: 1. Categorization: the superset of transport features from [RFC8303] is presented, and transport features are categorized for later reduction. 2. Reduction: a shorter list of transport features is derived from the categorization in the first step. This removes all transport features that do not require application-specific knowledge or cannot be implemented with TCP or UDP. 3. Discussion: the resulting list shows a number of peculiarities that are discussed, to provide a basis for constructing the minimal set. 4. Construction: Based on the reduced set and the discussion of the transport features therein, a minimal set is constructed. The first three steps as well as the underlying rationale for constructing the minimal set are described in this appendix. The minimal set itself is described in Section 3. would have been clearer to me, if each step was labeled with the part of = the document where this work appears (so, step 1 would be labeled = "Section A.1", etc.), rather than providing the pointers at the end of = the list. I couldn't tell whether you meant that these were the steps = you took in the working group, or whether this was the organization of = this appendix (plus Section 3), until I got to the paragraph at the end.=20= MW: Done (and final paragraph removed) -- Does=20 Finally, some transport features are aggregated and/or slightly changed in the description below. These transport features are marked as "ADDED". The corresponding transport features are automatable, and they are listed immediately below the "ADDED" transport feature. mean "aggregated and/or slightly change from [RFC8303]"? MW: Yes, done. New sentence: Finally, some transport features are aggregated and/or slightly changed from [RFC8303] in the description below. -- I have the same question with=20 In this description, transport services are presented following the nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", equivalent to "pass 2" in [RFC8303]. We also sketch how some of the transport features can be implemented by a transport system. For all transport features that are categorized as "functional" or "optimizing", and for which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on how to implement them over TCP and/or UDP is included. as I did above - is SCTP intentionally omitted from this paragraph?=20 MW: Yes, for the same reason I gave above. I now prefaced the last = sentence with 'The "minimal set" derived in this document is meant to be = implementable "one-sided" over TCP, and, with limitations, UDP. Hence, = ...' -- (Somewhere about here, I started thinking about "automated" - I didn't = see a clear definition of this in the document. I think I understand = what you mean at a hand-waving level, but you might consider adding a = definition earlier in the document, so that's clearer without relying on = context clues.=20 MW: "automated" doesn't appear in the draft - I'm sure you mean = "automatable". It only appears in the appendix, where it's defined upon its first = occurrence, in paragraph 5 of Appendix A.1, as follows: "The transport = features of IETF transport protocols that do not require = application-specific knowledge and could therefore be transparently = utilized by a transport system are called "Automatable"." - maybe you = just missed this? I believe it's in the most suitable place. I now made = this sentence a bit clearer now, by changing it into: "The transport = features of IETF transport protocols that do not require = application-specific knowledge and could therefore be utilized by a = transport system on its own without involving the application are called = "Automatable"." -- I'm not going to list them off, but starting in Section A.1.1. = CONNECTION Related Transport Features, I'm seeing a lot of analysis that = includes some transport protocols and doesn't include others. I'm = comparing=20 o Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. Implementation: via a parameter in CONNECT.SCTP. Implementation over TCP: not possible. Implementation over UDP: not possible. which includes TCP, SCTP, and UDP, to something like=20 o Hand over a message to reliably transfer during connection establishment Protocols: SCTP Functional because this can only work if the message is limited in size, making it closely tied to properties of the data that an application sends or expects to receive. Implementation: via a parameter in CONNECT.SCTP. Implementation over UDP: not possible. which does not mention TCP. There are a bunch of examples with this kind = of omission. Is it worth showing a complete set of "Implementation over = $Transport: not possible"s for each feature? MW: Yes, done, for all the functional and optimizing features (as explained in the introductory text of Appendix A.1. -- If this next is too much trouble, do the right thing, but I notice that=20= o Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP. Implementation over UDP: not possible (UDP is unreliable and there is no connection timeout). includes a parenthetical explanation of why a function is not possible = to implement on a specific transport protocol, but most "not possible" = entries don't have such an explanation. I mention this now, both because = it might reduce the number of conversations with reviewers and ADs that = you have starting with Last Call, and because you folks are likely the = best equipped to add these explanations now, rather than someone else = trying to guess what you were thinking later.=20 And, while I was thinking about that, I started thinking about entries = like=20 Implementation over UDP: Do nothing (this is irrelevant in case of UDP because there, reliable data delivery is not assumed). and wondered how many of the "not possible" entries in the appendix = might be "do nothing". If you had parenthetical explanations for why = something is "not possible", or why an implementation might "do = nothing", that would probably sharpen the difference for the average = reader =E2=80=A6 MW: Done everywhere -- And finally, at a high level, I don't understand why there are = "Implementation over $Protocol" lines so often that name $Protocols that = weren't listed in "Protocols:" at the beginning of each description. I = have several guesses about what that might mean, but I bet all of them = are wrong, so I have to ask.=20 MW: maybe that's related to your confusion about the omission of SCTP, = which I hope I have addressed (as explained above). So that's answered by text that = appears just before we list the transport features, which now reads: "The "minimal set" derived in this document is meant to be implementable = "one-sided" over TCP, and, with limitations, UDP. Hence, for all = transport features that are categorized as "functional" or "optimizing", = and for which no matching TCP and/or UDP primitive exists in "pass 2" of = [RFC8303], a brief discussion on how to implement them over TCP and/or UDP is included." -- To the details ... Is this text=20 o Reliably transfer a message, with congestion control Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Implementation over TCP: via SEND.TCP. With SEND.TCP, messages will not be identifiable by the receiver. Implementation over UDP: not possible. saying o Reliably transfer a message, with congestion control ... Implementation over TCP: via SEND.TCP. With SEND..TCP, message boundaries will not be identifiable by the receiver, because TCP=20= provides a stream service. ... or something else? MW: It says what you suspect, and I updated the text as you propose = (although saying "byte stream" instead of just "stream"). -- I have the same question about the next one o Unreliably transfer a message Protocols: SCTP, UDP(-Lite) Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. ADDED. This differs from the 2 automatable transport features below in that it leaves the choice of congestion control open. Implementation: via SEND.SCTP or SEND.UDP(-Lite). Implementation over TCP: use SEND.TCP. With SEND.TCP, messages will be sent reliably, and they will not be identifiable by the receiver. ("message boundaries"?) MW: same here - I replaced "they" with "message boundaries" in the last = sentence. -- In section A.2, I have the same "is SCTP out or in?" question, = especially around=20 In the following list, we precede a transport feature with "T:" if an implementation over TCP is possible, "U:" if an implementation over UDP is possible, and "TU:" if an implementation over either TCP or UDP is possible. MW: I addressed this in the same way as the others above, by replacing = it with: "The "minimal set" derived in this document is meant to be implementable = "one-sided" over TCP, and, with limitations, UDP. In the following list, we = therefore precede ..." -- =20 =20 =20 I don't understand=20 A.2.1. CONNECTION Related Transport Features ESTABLISHMENT: o T: Hand over a message to reliably transfer (possibly multiple times) before connection establishment Is this saying "possibly retransmitting multiple times to achieve = reliability", or something else? MW: No, it means that a message is transferred reliably, and that it may = arrive multiple times; that's a long-winded way of saying "idempotence" for = TFO. I really don't want to change this text because it is a literal copy = from RFC 8303 - these text snippets tie these documents together. And, even though I agree that the wording could be better, I think it's = actually clear because this is describing a service to the application. Retransmissions to achieve reliability wouldn't be relevant to the = application; "transferring multiple times" can therefore only mean that the message = really is transferred from application A to application B multiple times, and this = is what can happen with TFO. ---- --Apple-Mail=_3D38BCFA-80AD-4279-801D-6CB64EA53AA6 Content-Disposition: attachment; filename=draft-ietf-taps-minset-05.txt Content-Type: text/plain; x-unix-mode=0644; name="draft-ietf-taps-minset-05.txt" Content-Transfer-Encoding: quoted-printable TAPS M. Welzl Internet-Draft S. Gjessing Intended status: Informational University of Oslo Expires: February 21, 2019 August 20, 2018 A Minimal Set of Transport Services for End Systems draft-ietf-taps-minset-05 Abstract This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 21, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Welzl & Gjessing Expires February 21, 2019 [Page 1] =0C Internet-Draft Minimal Transport Services August 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The Minimal Set of Transport Features . . . . . . . . . . . . 5 3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION . . . . . . . 5 3.2. MAINTENANCE . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Connection groups . . . . . . . . . . . . . . . . . . 8 3.2.2. Individual connections . . . . . . . . . . . . . . . 10 3.3. DATA Transfer . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. Sending Data . . . . . . . . . . . . . . . . . . . . 10 3.3.2. Receiving Data . . . . . . . . . . . . . . . . . . . 11 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13 Appendix A. Deriving the minimal set . . . . . . . . . . . . . . 15 A.1. Step 1: Categorization -- The Superset of Transport Features . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1.1. CONNECTION Related Transport Features . . . . . . . . 17 A.1.2. DATA Transfer Related Transport Features . . . . . . 33 A.2. Step 2: Reduction -- The Reduced Set of Transport Features . . . . . . . . . . . . . . . . . . . . . . . . 39 A.2.1. CONNECTION Related Transport Features . . . . . . . . 40 A.2.2. DATA Transfer Related Transport Features . . . . . . 41 A.3. Step 3: Discussion . . . . . . . . . . . . . . . . . . . 42 A.3.1. Sending Messages, Receiving Bytes . . . . . . . . . . 42 A.3.2. Stream Schedulers Without Streams . . . . . . . . . . 43 A.3.3. Early Data Transmission . . . . . . . . . . . . . . . 44 A.3.4. Sender Running Dry . . . . . . . . . . . . . . . . . 44 A.3.5. Capacity Profile . . . . . . . . . . . . . . . . . . 45 A.3.6. Security . . . . . . . . . . . . . . . . . . . . . . 46 A.3.7. Packet Size . . . . . . . . . . . . . . . . . . . . . 46 Appendix B. Revision information . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction The task of a transport system is to offer transport services to its applications, i.e. the applications running on top of the transport system. Ideally, it does so without statically binding applications to particular transport protocols. Currently, the set of transport services that most applications use is based on TCP and UDP (and protocols that are layered on top of them); this limits the ability for the network stack to make use of features of other transport Welzl & Gjessing Expires February 21, 2019 [Page 2] =0C Internet-Draft Minimal Transport Services August 2018 protocols. For example, if a protocol supports out-of-order message delivery but applications always assume that the network provides an ordered bytestream, then the network stack can not immediately deliver a message that arrives out-of-order: doing so would break a fundamental assumption of the application. The net result is unnecessary head-of-line blocking delay. By exposing the transport services of multiple transport protocols, a transport system can make it possible to use these services without having to statically bind an application to a specific transport protocol. The first step towards the design of such a system was taken by [RFC8095], which surveys a large number of transports, and [RFC8303] as well as [RFC8304], which identify the specific transport features that are exposed to applications by the protocols TCP, MPTCP, UDP(-Lite) and SCTP as well as the LEDBAT congestion control mechanism. This memo is based on these documents and follows the same terminology (also listed below). Because the considered transport protocols conjointly cover a wide range of transport features, there is reason to hope that the resulting set (and the reasoning that led to it) will also apply to many aspects of other transport protocols that may be in use today, or may be designed in the future. The number of transport features of current IETF transports is large, and exposing all of them has a number of disadvantages: generally, the more functionality is exposed, the less freedom a transport system has to automate usage of the various functions of its available set of transport protocols. Some functions only exist in one particular protocol, and if an application used them, this would statically tie the application to this protocol, limiting the flexibility of the transport system. Also, if the number of exposed features is exceedingly large, a transport system might become very difficult to use for an application programmer. Taking [RFC8303] as a basis, this document therefore develops a minimal set of transport features, removing the ones that could get in the way of transport flexibility but keeping the ones that must be retained for applications to benefit from useful transport functionality. Applications use a wide variety of APIs today. The transport features in the minimal set in this document must be reflected in *all* network APIs in order for the underlying functionality to become usable everywhere. For example, it does not help an application that talks to a library which offers its own communication interface if the underlying Berkeley Sockets API is extended to offer "unordered message delivery", but the library only exposes an ordered bytestream. Both the Berkeley Sockets API and the library would have to expose the "unordered message delivery" transport feature (alternatively, there may be ways for certain types Welzl & Gjessing Expires February 21, 2019 [Page 3] =0C Internet-Draft Minimal Transport Services August 2018 of libraries to use this transport feature without exposing it, based on knowledge about the applications -- but this is not the general case). In most situations, in the interest of being as flexible and efficient as possible, the best choice will be for a library to expose at least all of the transport features that are recommended as a "minimal set" here. This "minimal set" can be implemented "one-sided" over TCP. This means that a sender-side transport system can talk to a standard TCP receiver, and a receiver-side transport system can talk to a standard TCP sender. If certain limitations are put in place, the "minimal set" can also be implemented "one-sided" over UDP. 2. Terminology Transport Feature: a specific end-to-end feature that the transport layer provides to an application. Examples include confidentiality, reliable delivery, ordered delivery, message- versus-stream orientation, etc. Transport Service: a set of Transport Features, without an association to any given framing protocol, which provides a complete service to an application. Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire. Transport Service Instance: an arrangement of transport protocols with a selected set of features and configuration parameters that implements a single transport service, e.g., a protocol stack (RTP over UDP). Application: an entity that uses the transport layer for end-to-end delivery data across the network (this may also be an upper layer protocol or tunnel encapsulation). Application-specific knowledge: knowledge that only applications have. Endpoint: an entity that communicates with one or more other endpoints using a transport protocol. Connection: shared state of two or more endpoints that persists across messages that are transmitted between these endpoints. Connection Group: a set of connections which share the same configuration (configuring one of them causes all other connections in the same group to be configured in the same way). We call connections that belong to a connection group "grouped", while "ungrouped" connections are not a part of a connection group. Socket: the combination of a destination IP address and a destination port number. Welzl & Gjessing Expires February 21, 2019 [Page 4] =0C Internet-Draft Minimal Transport Services August 2018 Moreover, throughout the document, the protocol name "UDP(-Lite)" is used when discussing transport features that are equivalent for UDP and UDP-Lite; similarly, the protocol name "TCP" refers to both TCP and MPTCP. 3. The Minimal Set of Transport Features Based on the categorization, reduction, and discussion in Appendix A, this section describes a minimal set of transport features that end systems should offer. The described transport system can be implemented over TCP. Elements of the system that are not marked with "!UDP" can also be implemented over UDP. The arguments laid out in Appendix A.3 ("discussion") were used to make the final representation of the minimal set as short, simple and general as possible. There may be situations where these arguments do not apply -- e.g., implementers may have specific reasons to expose multi-streaming as a visible functionality to applications, or the restrictive open / close semantics may be problematic under some circumstances. In such cases, the representation in Appendix A.2 ("reduction") should be considered. As in Appendix A, Appendix A.2 and [RFC8303], we categorize the minimal set of transport features as 1) CONNECTION related (ESTABLISHMENT, AVAILABILITY, MAINTENANCE, TERMINATION) and 2) DATA Transfer related (Sending Data, Receiving Data, Errors). Here, the focus is on connections that the transport system offers as an abstraction to the application, as opposed to connections of transport protocols that the transport system uses. 3.1. ESTABLISHMENT, AVAILABILITY and TERMINATION A connection must first be "created" to allow for some initial configuration to be carried out before the transport system can actively or passively establish communication with a remote endpoint. All configuration parameters in Section 3.2 can be used initially, although some of them may only take effect when a connection has been established with a chosen transport protocol. Configuring a connection early helps a transport system make the right decisions. For example, grouping information can influence the transport system to implement a connection as a stream of a multi-streaming protocol's existing association or not. For ungrouped connections, early configuration is necessary because it allows the transport system to know which protocols it should try to use. In particular, a transport system that only makes a one-time choice for a particular protocol must know early about strict requirements that must be kept, or it can end up in a deadlock Welzl & Gjessing Expires February 21, 2019 [Page 5] =0C Internet-Draft Minimal Transport Services August 2018 situation (e.g., having chosen UDP and later be asked to support reliable transfer). As an example description of how to correctly handle these cases, we provide the following decision tree (this is derived from Appendix A.2.1 excluding authentication, as explained in Section 7): - Will it ever be necessary to offer any of the following? * Reliably transfer data * Notify the peer of closing/aborting * Preserve data ordering Yes: SCTP or TCP can be used. - Is any of the following useful to the application? * Choosing a scheduler to operate between connections in a group, with the possibility to configure a priority or weight per connection * Configurable message reliability * Unordered message delivery * Request not to delay the acknowledgement (SACK) of a message Yes: SCTP is preferred. No: - Is any of the following useful to the application? * Hand over a message to reliably transfer (possibly multiple times) before connection establishment * Suggest timeout to the peer * Notification of Excessive Retransmissions (early warning below abortion threshold) * Notification of ICMP error message arrival Yes: TCP is preferred. No: SCTP and TCP are equally preferable. No: all protocols can be used. - Is any of the following useful to the application? * Specify checksum coverage used by the sender * Specify minimum checksum coverage required by receiver Yes: UDP-Lite is preferred. No: UDP is preferred. Note that this decision tree is not optimal for all cases. For example, if an application wants to use "Specify checksum coverage used by the sender", which is only offered by UDP-Lite, and "Configure priority or weight for a scheduler", which is only offered Welzl & Gjessing Expires February 21, 2019 [Page 6] =0C Internet-Draft Minimal Transport Services August 2018 by SCTP, the above decision tree will always choose UDP-Lite, making it impossible to use SCTP's schedulers with priorities between grouped connections. We caution implementers to be aware of the full set of trade-offs, for which we recommend consulting the list in Appendix A.2.1 when deciding how to initialize a connection. To summarize, the following parameters serve as input for the transport system to help it choose and configure a suitable protocol: o Reliability: a boolean that should be set to true when any of the following will be useful to the application: reliably transfer data; notify the peer of closing/aborting; preserve data ordering. o Checksum coverage: a boolean to specify whether it will be useful to the application to specify checksum coverage when sending or receiving. o Configure message priority: a boolean that should be set to true when any of the following per-message configuration or prioritization mechanisms will be useful to the application: choosing a scheduler to operate between grouped connections, with the possibility to configure a priority or weight per connection; configurable message reliability; unordered message delivery; requesting not to delay the acknowledgement (SACK) of a message. o Early message timeout notifications: a boolean that should be set to true when any of the following will be useful to the application: hand over a message to reliably transfer (possibly multiple times) before connection establishment; suggest timeout to the peer; notification of excessive retransmissions (early warning below abortion threshold); notification of ICMP error message arrival. Once a connection is created, it can be queried for the maximum amount of data that an application can possibly expect to have reliably transmitted before or during transport connection establishment (with zero being a possible answer) (see Section 3.2.1). An application can also give the connection a message for reliable transmission before or during connection establishment (!UDP); the transport system will then try to transmit it as early as possible. An application can facilitate sending a message particularly early by marking it as "idempotent" (see Section 3.3.1); in this case, the receiving application must be prepared to potentially receive multiple copies of the message (because idempotent messages are reliably transferred, asking for idempotence is not necessary for systems that support UDP). After creation, a transport system can actively establish communication with a peer, or it can passively listen for incoming connection requests. Note that active establishment may or may not trigger a notification on the listening side. It is possible that Welzl & Gjessing Expires February 21, 2019 [Page 7] =0C Internet-Draft Minimal Transport Services August 2018 the first notification on the listening side is the arrival of the first data that the active side sends (a receiver-side transport system could handle this by continuing to block a "Listen" call, immediately followed by issuing "Receive", for example; callback- based implementations could simply skip the equivalent of "Listen"). This also means that the active opening side is assumed to be the first side sending data. A transport system can actively close a connection, i.e. terminate it after reliably delivering all remaining data to the peer (if reliable data delivery was requested earlier (!UDP)), in which case the peer is notified that the connection is closed. Alternatively, a connection can be aborted without delivering outstanding data to the peer. In case reliable or partially reliable data delivery was requested earlier (!UDP), the peer is notified that the connection is aborted. A timeout can be configured to abort a connection when data could not be delivered for too long (!UDP); however, timeout-based abortion does not notify the peer application that the connection has been aborted. Because half-closed connections are not supported, when a host implementing a transport system receives a notification that the peer is closing or aborting the connection (!UDP), its peer may not be able to read outstanding data. This means that unacknowledged data residing a transport system's send buffer may have to be dropped from that buffer upon arrival of a "close" or "abort" notification from the peer. 3.2. MAINTENANCE A transport system must offer means to group connections, but it cannot guarantee truly grouping them using the transport protocols that it uses (e.g., it cannot be guaranteed that connections become multiplexed as streams on a single SCTP association when SCTP may not be available). The transport system must therefore ensure that group- versus non-group-configurations are handled correctly in some way (e.g., by applying the configuration to all grouped connections even when they are not multiplexed, or informing the application about grouping success or failure). As a general rule, any configuration described below should be carried out as early as possible to aid the transport system's decision making. 3.2.1. Connection groups The following transport features and notifications (some directly from Appendix A.2, some new or changed, based on the discussion in Appendix A.3) automatically apply to all grouped connections: Welzl & Gjessing Expires February 21, 2019 [Page 8] =0C Internet-Draft Minimal Transport Services August 2018 (!UDP) Configure a timeout: this can be done with the following parameters: o A timeout value for aborting connections, in seconds o A timeout value to be suggested to the peer (if possible), in seconds o The number of retransmissions after which the application should be notifed of "Excessive Retransmissions" Configure urgency: this can be done with the following parameters: o A number to identify the type of scheduler that should be used to operate between connections in the group (no guarantees given). Schedulers are defined in [RFC8260]. o A "capacity profile" number to identify how an application wants to use its available capacity. Choices can be "lowest possible latency at the expense of overhead" (which would disable any Nagle-like algorithm), "scavenger", or values that help determine the DSCP value for a connection (e.g. similar to table 1 in [I-D.ietf-tsvwg-rtcweb-qos]). o A buffer limit (in bytes); when the sender has less than the provided limit of bytes in the buffer, the application may be notified. Notifications are not guaranteed, and it is optional for a transport system to support buffer limit values greater than 0. Note that this limit and its notification should operate across the buffers of the whole transport system, i.e. also any potential buffers that the transport system itself may use on top of the transport's send buffer. Following Appendix A.3.7, these properties can be queried: o The maximum message size that may be sent without fragmentation via the configured interface. This is optional for a transport system to offer, and may return an error ("not available"). It can aid applications implementing Path MTU Discovery. o The maximum transport message size that can be sent, in bytes. Irrespective of fragmentation, there is a size limit for the messages that can be handed over to SCTP or UDP(-Lite); because the service provided by a transport system is independent of the transport protocol, it must allow an application to query this value -- the maximum size of a message in an Application-Framed- Bytestream (see Appendix A.3.1). This may also return an error when data is not delimited ("not available"). o The maximum transport message size that can be received from the configured interface, in bytes (or "not available"). o The maximum amount of data that can possibly be sent before or during connection establishment, in bytes. Welzl & Gjessing Expires February 21, 2019 [Page 9] =0C Internet-Draft Minimal Transport Services August 2018 In addition to the already mentioned closing / aborting notifications and possible send errors, the following notifications can occur: o Excessive Retransmissions: the configured (or a default) number of retransmissions has been reached, yielding this early warning below an abortion threshold. o ICMP Arrival (parameter: ICMP message): an ICMP packet carrying the conveyed ICMP message has arrived. o ECN Arrival (parameter: ECN value): a packet carrying the conveyed ECN value has arrived. This can be useful for applications implementing congestion control. o Timeout (parameter: s seconds): data could not be delivered for s seconds. o Drain: the send buffer has either drained below the configured buffer limit or it has become completely empty. This is a generic notification that tries to enable uniform access to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification (as discussed in Appendix A.3.4 -- SCTP's "SENDER DRY" is a special case where the threshold (for unsent data) is 0 and there is also no more unacknowledged data in the send buffer). 3.2.2. Individual connections Configure priority or weight for a scheduler, as described in [RFC8260]. Configure checksum usage: this can be done with the following parameters, but there is no guarantee that any checksum limitations will indeed be enforced (the default behavior is "full coverage, checksum enabled"): o A boolean to enable / disable usage of a checksum when sending o The desired coverage (in bytes) of the checksum used when sending o A boolean to enable / disable requiring a checksum when receiving o The required minimum coverage (in bytes) of the checksum when receiving 3.3. DATA Transfer 3.3.1. Sending Data When sending a message, no guarantees are given about the preservation of message boundaries to the peer; if message boundaries are needed, the receiving application at the peer must know about them beforehand (or the transport system cannot use TCP). Note that an application should already be able to hand over data before the transport system establishes a connection with a chosen transport Welzl & Gjessing Expires February 21, 2019 [Page 10] =0C Internet-Draft Minimal Transport Services August 2018 protocol. Regarding the message that is being handed over, the following parameters can be used: o Reliability: this parameter is used to convey a choice of: fully reliable with congestion control (!UDP), unreliable without congestion control, unreliable with congestion control (!UDP), partially reliable with congestion control (see [RFC3758] and [RFC7496] for details on how to specify partial reliability) (!UDP). The latter two choices are optional for a transport system to offer and may result in full reliability. Note that applications sending unreliable data without congestion control should themselves perform congestion control in accordance with [RFC2914]. o (!UDP) Ordered: this boolean parameter lets an application choose between ordered message delivery (true) and possibly unordered, potentially faster message delivery (false). o Bundle: a boolean that expresses a preference for allowing to bundle messages (true) or not (false). No guarantees are given. o DelAck: a boolean that, if false, lets an application request that the peer would not delay the acknowledgement for this message. o Fragment: a boolean that expresses a preference for allowing to fragment messages (true) or not (false), at the IP level. No guarantees are given. o (!UDP) Idempotent: a boolean that expresses whether a message is idempotent (true) or not (false). Idempotent messages may arrive multiple times at the receiver (but they will arrive at least once). When data is idempotent it can be used by the receiver immediately on a connection establishment attempt. Thus, if data is handed over before the transport system establishes a connection with a chosen transport protocol, stating that a message is idempotent facilitates transmitting it to the peer application particularly early. An application can be notified of a failure to send a specific message. There is no guarantee of such notifications, i.e. send failures can also silently occur. 3.3.2. Receiving Data A receiving application obtains an "Application-Framed Bytestream" (AFra-Bytestream); this concept is further described in Appendix A.3.1). In line with TCP's receiver semantics, an AFra- Bytestream is just a stream of bytes to the receiver. If message boundaries were specified by the sender, a receiver-side transport system implementing only the minimum set of transport services defined here will still not inform the receiving application about them (this limitation is only needed for transport systems that are implemented to directly use TCP). Welzl & Gjessing Expires February 21, 2019 [Page 11] =0C Internet-Draft Minimal Transport Services August 2018 Different from TCP's semantics, if the sending application has allowed that messages are not fully reliably transferred, or delivered out of order, then such re-ordering or unreliability may be reflected per message in the arriving data. Messages will always stay intact - i.e. if an incomplete message is contained at the end of the arriving data block, this message is guaranteed to continue in the next arriving data block. 4. Conclusion By decoupling applications from transport protocols, a transport system provides a different abstraction level than the Berkeley sockets interface. As with high- vs. low-level programming languages, a higher abstraction level allows more freedom for automation below the interface, yet it takes some control away from the application programmer. This is the design trade-off that a transport system developer is facing, and this document provides guidance on the design of this abstraction level. Some transport features are currently rarely offered by APIs, yet they must be offered or they can never be used ("functional" transport features). Other transport features are offered by the APIs of the protocols covered here, but not exposing them in an API would allow for more freedom to automate protocol usage in a transport system. The minimal set presented in this document is an effort to find a middle ground that can be recommended for transport systems to implement, on the basis of the transport features discussed in [RFC8303]. 5. Acknowledgements The authors would like to thank all the participants of the TAPS Working Group and the NEAT and MAMI research projects for valuable input to this document. We especially thank Michael Tuexen for help with connection connection establishment/teardown and Gorry Fairhurst for his suggestions regarding fragmentation and packet sizes, and Spencer Dawkins for his extremely detailed and constructive review. This work has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No. 644334 (NEAT). 6. IANA Considerations XX RFC ED - PLEASE REMOVE THIS SECTION XXX This memo includes no request to IANA. Welzl & Gjessing Expires February 21, 2019 [Page 12] =0C Internet-Draft Minimal Transport Services August 2018 7. Security Considerations Authentication, confidentiality protection, and integrity protection are identified as transport features by [RFC8095]. As currently deployed in the Internet, these features are generally provided by a protocol or layer on top of the transport protocol; no current full- featured standards-track transport protocol provides all of these transport features on its own. Therefore, these transport features are not considered in this document, with the exception of native authentication capabilities of TCP and SCTP for which the security considerations in [RFC5925] and [RFC4895] apply. The minimum security requirements for a transport system are discussed in a separate document [I-D.ietf-taps-transport-security]. 8. References 8.1. Normative References [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of Transport Features Provided by IETF Transport Protocols", RFC 8303, DOI 10.17487/RFC8303, February 2018, . 8.2. Informative References [COBS] Cheshire, S. and M. Baker, "Consistent Overhead Byte Stuffing", September 1997, . [I-D.ietf-taps-transport-security] Pauly, T., Perkins, C., Rose, K., and C. Wood, "A Survey of Transport Security Protocols", draft-ietf-taps- transport-security-01 (work in progress), May 2018. [I-D.ietf-tsvwg-rtcweb-qos] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb- qos-18 (work in progress), August 2016. [LBE-draft] Bless, R., "A Lower Effort Per-Hop Behavior (LE PHB)", Internet-draft draft-tsvwg-le-phb-03, February 2018. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, . Welzl & Gjessing Expires February 21, 2019 [Page 13] =0C Internet-Draft Minimal Transport Services August 2018 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, DOI 10.17487/RFC3758, May 2004, . [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, "Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007, . [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, . [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, . [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)", RFC 7305, DOI 10.17487/RFC7305, July 2014, . [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, . [RFC7496] Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, "Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension", RFC 7496, DOI 10.17487/RFC7496, April 2015, . [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, Ed., "Services Provided by IETF Transport Protocols and Congestion Control Mechanisms", RFC 8095, DOI 10.17487/RFC8095, March 2017, . [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol", RFC 8260, DOI 10.17487/RFC8260, November 2017, . Welzl & Gjessing Expires February 21, 2019 [Page 14] =0C Internet-Draft Minimal Transport Services August 2018 [RFC8304] Fairhurst, G. and T. Jones, "Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite)", RFC 8304, DOI 10.17487/RFC8304, February 2018, . [WWDC2015] Lakhera, P. and S. Cheshire, "Your App and Next Generation Networks", Apple Worldwide Developers Conference 2015, San Francisco, USA, June 2015, . Appendix A. Deriving the minimal set We approach the construction of a minimal set of transport features in the following way: 1. Categorization (Appendix A.1): the superset of transport features from [RFC8303] is presented, and transport features are categorized for later reduction. 2. Reduction (Appendix A.2): a shorter list of transport features is derived from the categorization in the first step. This removes all transport features that do not require application-specific knowledge or would result in semantically incorrect behavior if they were implemented over TCP or UDP. 3. Discussion (Appendix A.3): the resulting list shows a number of peculiarities that are discussed, to provide a basis for constructing the minimal set. 4. Construction (Section 3): Based on the reduced set and the discussion of the transport features therein, a minimal set is constructed. A.1. Step 1: Categorization -- The Superset of Transport Features Following [RFC8303], we divide the transport features into two main groups as follows: 1. CONNECTION related transport features - ESTABLISHMENT - AVAILABILITY - MAINTENANCE - TERMINATION 2. DATA Transfer related transport features - Sending Data - Receiving Data - Errors Welzl & Gjessing Expires February 21, 2019 [Page 15] =0C Internet-Draft Minimal Transport Services August 2018 We assume that applications have no specific requirements that need knowledge about the network, e.g. regarding the choice of network interface or the end-to-end path. Even with these assumptions, there are certain requirements that are strictly kept by transport protocols today, and these must also be kept by a transport system. Some of these requirements relate to transport features that we call "Functional". Functional transport features provide functionality that cannot be used without the application knowing about them, or else they violate assumptions that might cause the application to fail. For example, ordered message delivery is a functional transport feature: it cannot be configured without the application knowing about it because the application's assumption could be that messages always arrive in order. Failure includes any change of the application behavior that is not performance oriented, e.g. security. "Change DSCP" and "Disable Nagle algorithm" are examples of transport features that we call "Optimizing": if a transport system autonomously decides to enable or disable them, an application will not fail, but a transport system may be able to communicate more efficiently if the application is in control of this optimizing transport feature. These transport features require application- specific knowledge (e.g., about delay/bandwidth requirements or the length of future data blocks that are to be transmitted). The transport features of IETF transport protocols that do not require application-specific knowledge and could therefore be utilized by a transport system on its own without involving the application are called "Automatable". Finally, some transport features are aggregated and/or slightly changed from [RFC8303] in the description below. These transport features are marked as "ADDED". The corresponding transport features are automatable, and they are listed immediately below the "ADDED" transport feature. In this description, transport services are presented following the nomenclature "CATEGORY.[SUBCATEGORY].SERVICENAME.PROTOCOL", equivalent to "pass 2" in [RFC8303]. We also sketch how functional or optimizing transport features can be implemented by a transport system. The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. Hence, for all transport features that are categorized as "functional" or "optimizing", and for which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], a brief discussion on how to implement them over TCP and/or UDP is included. Welzl & Gjessing Expires February 21, 2019 [Page 16] =0C Internet-Draft Minimal Transport Services August 2018 We designate some transport features as "automatable" on the basis of a broader decision that affects multiple transport features: o Most transport features that are related to multi-streaming were designated as "automatable". This was done because the decision on whether to use multi-streaming or not does not depend on application-specific knowledge. This means that a connection that is exhibited to an application could be implemented by using a single stream of an SCTP association instead of mapping it to a complete SCTP association or TCP connection. This could be achieved by using more than one stream when an SCTP association is first established (CONNECT.SCTP parameter "outbound stream count"), maintaining an internal stream number, and using this stream number when sending data (SEND.SCTP parameter "stream number"). Closing or aborting a connection could then simply free the stream number for future use. This is discussed further in Appendix A.3.2. o All transport features that are related to using multiple paths or the choice of the network interface were designated as "automatable". Choosing a path or an interface does not depend on application-specific knowledge. For example, "Listen" could always listen on all available interfaces and "Connect" could use the default interface for the destination IP address. A.1.1. CONNECTION Related Transport Features ESTABLISHMENT: o Connect Protocols: TCP, SCTP, UDP(-Lite) Functional because the notion of a connection is often reflected in applications as an expectation to be able to communicate after a "Connect" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol. Implementation: via CONNECT.TCP, CONNECT.SCTP or CONNECT.UDP(- Lite). o Specify which IP Options must always be used Protocols: TCP, UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Request multiple streams Welzl & Gjessing Expires February 21, 2019 [Page 17] =0C Internet-Draft Minimal Transport Services August 2018 Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Limit the number of inbound streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Specify number of attempts and/or timeout for the first establishment message Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery for data that is sent before or during connection establishment. Implementation: Using a parameter of CONNECT.TCP and CONNECT.SCTP. Implementation over UDP: Do nothing (this is irrelevant in case of UDP because there, reliable data delivery is not assumed). o Obtain multiple sockets Protocols: SCTP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Disable MPTCP Protocols: MPTCP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. Implementation: via a boolean parameter in CONNECT.MPTCP. o Configure authentication Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via parameters in CONNECT.TCP and CONNECT.SCTP. With TCP, this allows to configure Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows Welzl & Gjessing Expires February 21, 2019 [Page 18] =0C Internet-Draft Minimal Transport Services August 2018 to specify which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of security that is not supported by TCP; to be compatible, this should therefore only allow to authenticate all chunk types. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: Not possible (UDP does not offer this functionality). o Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. Implementation: via a parameter in CONNECT.SCTP. Implementation over TCP: not possible (TCP does not offer this functionality). Implementation over UDP: not possible (UDP does not offer this functionality). o Request to negotiate interleaving of user messages Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: via a parameter in CONNECT.SCTP. o Hand over a message to reliably transfer (possibly multiple times) before connection establishment Protocols: TCP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via a parameter in CONNECT.TCP. Implementation over UDP: not possible (UDP does not provide reliability). o Hand over a message to reliably transfer during connection establishment Protocols: SCTP Welzl & Gjessing Expires February 21, 2019 [Page 19] =0C Internet-Draft Minimal Transport Services August 2018 Functional because this can only work if the message is limited in size, making it closely tied to properties of the data that an application sends or expects to receive. Implementation: via a parameter in CONNECT.SCTP. Implementation over TCP: not possible (TCP does not allow identification of message boundaries because it provides a byte stream service) Implementation over UDP: not possible (UDP is unreliable). o Enable UDP encapsulation with a specified remote UDP port number Protocols: SCTP Automatable because UDP encapsulation relates to knowledge about the network, not the application. AVAILABILITY: o Listen Protocols: TCP, SCTP, UDP(-Lite) Functional because the notion of accepting connection requests is often reflected in applications as an expectation to be able to communicate after a "Listen" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol. ADDED. This differs from the 3 automatable transport features below in that it leaves the choice of interfaces for listening open. Implementation: by listening on all interfaces via LISTEN.TCP (not providing a local IP address) or LISTEN.SCTP (providing SCTP port number / address pairs for all local IP addresses). LISTEN.UDP(- Lite) supports both methods. o Listen, 1 specified local interface Protocols: TCP, SCTP, UDP(-Lite) Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Listen, N specified local interfaces Protocols: SCTP Welzl & Gjessing Expires February 21, 2019 [Page 20] =0C Internet-Draft Minimal Transport Services August 2018 Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Listen, all local interfaces Protocols: TCP, SCTP, UDP(-Lite) Automatable because decisions about local interfaces relate to knowledge about the network and the Operating System, not the application. o Specify which IP Options must always be used Protocols: TCP, UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Disable MPTCP Protocols: MPTCP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Configure authentication Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via parameters in LISTEN.TCP and LISTEN.SCTP. Implementation over TCP: With TCP, this allows to configure Master Key Tuples (MKTs) to authenticate complete segments (including the TCP IPv4 pseudoheader, TCP header, and TCP data). With SCTP, this allows to specify which chunk types must always be authenticated. Authenticating only certain chunk types creates a reduced level of security that is not supported by TCP; to be compatible, this should therefore only allow to authenticate all chunk types. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: not possible (UDP does not offer authentication). o Obtain requested number of streams Protocols: SCTP Welzl & Gjessing Expires February 21, 2019 [Page 21] =0C Internet-Draft Minimal Transport Services August 2018 Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Limit the number of inbound streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. Implementation: via a parameter in LISTEN.SCTP. Implementation over TCP: not possible (TCP does not offer this functionality). Implementation over UDP: not possible (UDP does not offer this functionality). o Request to negotiate interleaving of user messages Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: via a parameter in LISTEN.SCTP. MAINTENANCE: o Change timeout for aborting connection (using retransmit limit or time value) Protocols: TCP, SCTP Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE_TIMEOUT.TCP or CHANGE_TIMEOUT.SCTP. Implementation over UDP: not possible (UDP is unreliable and there is no connection timeout). Welzl & Gjessing Expires February 21, 2019 [Page 22] =0C Internet-Draft Minimal Transport Services August 2018 o Suggest timeout to the peer Protocols: TCP Functional because this is closely related to potentially assumed reliable data delivery. Implementation: via CHANGE_TIMEOUT.TCP. Implementation over UDP: not possible (UDP is unreliable and there is no connection timeout). o Disable Nagle algorithm Protocols: TCP, SCTP Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them. Implementation: via DISABLE_NAGLE.TCP and DISABLE_NAGLE.SCTP. Implementation over UDP: do nothing (UDP does not implement the Nagle algorithm). o Request an immediate heartbeat, returning success/failure Protocols: SCTP Automatable because this informs about network-specific knowledge. o Notification of Excessive Retransmissions (early warning below abortion threshold) Protocols: TCP Optimizing because it is an early warning to the application, informing it of an impending functional event. Implementation: via ERROR.TCP. Implementation over UDP: do nothing (there is no abortion threshold). o Add path Protocols: MPTCP, SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port SCTP Parameters: local IP address Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. Welzl & Gjessing Expires February 21, 2019 [Page 23] =0C Internet-Draft Minimal Transport Services August 2018 o Remove path Protocols: MPTCP, SCTP MPTCP Parameters: source-IP; source-Port; destination-IP; destination-Port SCTP Parameters: local IP address Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Set primary path Protocols: SCTP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Suggest primary path to the peer Protocols: SCTP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Configure Path Switchover Protocols: SCTP Automatable because the usage of multiple paths to communicate to the same end host relates to knowledge about the network, not the application. o Obtain status (query or notification) Protocols: SCTP, MPTCP SCTP parameters: association connection state; destination transport address list; destination transport address reachability states; current local and peer receiver window size; current local congestion window sizes; number of unacknowledged DATA chunks; number of DATA chunks pending receipt; primary path; most recent SRTT on primary path; RTO on primary path; SRTT and RTO on other destination addresses; MTU per path; interleaving supported yes/no MPTCP parameters: subflow-list (identified by source-IP; source- Port; destination-IP; destination-Port) Automatable because these parameters relate to knowledge about the network, not the application. Welzl & Gjessing Expires February 21, 2019 [Page 24] =0C Internet-Draft Minimal Transport Services August 2018 o Specify DSCP field Protocols: TCP, SCTP, UDP(-Lite) Optimizing because choosing a suitable DSCP value requires application-specific knowledge. Implementation: via SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(- Lite) o Notification of ICMP error message arrival Protocols: TCP, UDP(-Lite) Optimizing because these messages can inform about success or failure of functional transport features (e.g., host unreachable relates to "Connect") Implementation: via ERROR.TCP or ERROR.UDP(-Lite). o Obtain information about interleaving support Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: via STATUS.SCTP. o Change authentication parameters Protocols: TCP, SCTP Functional because this has a direct influence on security. Implementation: via SET_AUTH.TCP and SET_AUTH.SCTP. Implementation over TCP: With SCTP, this allows to adjust key_id, key, and hmac_id. With TCP, this allows to change the preferred outgoing MKT (current_key) and the preferred incoming MKT (rnext_key), respectively, for a segment that is sent on the connection. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: not possible (UDP does not offer authentication). o Obtain authentication information Protocols: SCTP Functional because authentication decisions may have been made by the peer, and this has an influence on the necessary application- level measures to provide a certain level of security. Implementation: via GET_AUTH.SCTP. Welzl & Gjessing Expires February 21, 2019 [Page 25] =0C Internet-Draft Minimal Transport Services August 2018 Implementation over TCP: With SCTP, this allows to obtain key_id and a chunk list. With TCP, this allows to obtain current_key and rnext_key from a previously received segment. Key material must be provided in a way that is compatible with both [RFC4895] and [RFC5925]. Implementation over UDP: not possible (UDP does not offer authentication). o Reset Stream Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Notification of Stream Reset Protocols: STCP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Reset Association Protocols: SCTP Automatable because deciding to reset an association does not require application-specific knowledge. Implementation: via RESET_ASSOC.SCTP. o Notification of Association Reset Protocols: STCP Automatable because this notification does not relate to application-specific knowledge. o Add Streams Protocols: SCTP Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Notification of Added Stream Protocols: STCP Welzl & Gjessing Expires February 21, 2019 [Page 26] =0C Internet-Draft Minimal Transport Services August 2018 Automatable because using multi-streaming does not require application-specific knowledge. Implementation: see Appendix A.3.2. o Choose a scheduler to operate between streams of an association Protocols: SCTP Optimizing because the scheduling decision requires application- specific knowledge. However, if a transport system would not use this, or wrongly configure it on its own, this would only affect the performance of data transfers; the outcome would still be correct within the "best effort" service model. Implementation: using SET_STREAM_SCHEDULER.SCTP. Implementation over TCP: do nothing (streams are not available in TCP, but no guarantee is given that this transport feature has any effect). Implementation over UDP: do nothing (streams are not available in UDP, but no guarantee is given that this transport feature has any effect). o Configure priority or weight for a scheduler Protocols: SCTP Optimizing because the priority or weight requires application- specific knowledge. However, if a transport system would not use this, or wrongly configure it on its own, this would only affect the performance of data transfers; the outcome would still be correct within the "best effort" service model. Implementation: using CONFIGURE_STREAM_SCHEDULER.SCTP. Implementation over TCP: do nothing (streams are not available in TCP, but no guarantee is given that this transport feature has any effect). Implementation over UDP: do nothing (streams are not available in UDP, but no guarantee is given that this transport feature has any effect). o Configure send buffer size Protocols: SCTP Automatable because this decision relates to knowledge about the network and the Operating System, not the application (see also the discussion in Appendix A.3.4). o Configure receive buffer (and rwnd) size Welzl & Gjessing Expires February 21, 2019 [Page 27] =0C Internet-Draft Minimal Transport Services August 2018 Protocols: SCTP Automatable because this decision relates to knowledge about the network and the Operating System, not the application. o Configure message fragmentation Protocols: SCTP Automatable because fragmentation relates to knowledge about the network and the Operating System, not the application. Implementation: by always enabling it with CONFIG_FRAGMENTATION.SCTP and auto-setting the fragmentation size based on network or Operating System conditions. o Configure PMTUD Protocols: SCTP Automatable because Path MTU Discovery relates to knowledge about the network, not the application. o Configure delayed SACK timer Protocols: SCTP Automatable because the receiver-side decision to delay sending SACKs relates to knowledge about the network, not the application (it can be relevant for a sending application to request not to delay the SACK of a message, but this is a different transport feature). o Set Cookie life value Protocols: SCTP Functional because it relates to security (possibly weakened by keeping a cookie very long) versus the time between connection establishment attempts. Knowledge about both issues can be application-specific. Implementation over TCP: the closest specified TCP functionality is the cookie in TCP Fast Open; for this, [RFC7413] states that the server "can expire the cookie at any time to enhance security" and section 4.1.2 describes an example implementation where updating the key on the server side causes the cookie to expire. Alternatively, for implementations that do not support TCP Fast Open, this transport feature could also affect the validity of SYN cookies (see Section 3.6 of [RFC4987]). Welzl & Gjessing Expires February 21, 2019 [Page 28] =0C Internet-Draft Minimal Transport Services August 2018 Implementation over UDP: not possible (UDP does not offer this functionality). o Set maximum burst Protocols: SCTP Automatable because it relates to knowledge about the network, not the application. o Configure size where messages are broken up for partial delivery Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation over TCP: not possible (TCP does not offer identification of message boundaries). Implementation over UDP: not possible (UDP does not fragment messages). o Disable checksum when sending Protocols: UDP Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity. Implementation: via SET_CHECKSUM_ENABLED.UDP. Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result). o Disable checksum requirement when receiving Protocols: UDP Functional because application-specific knowledge is necessary to decide whether it can be acceptable to lose data integrity. Implementation: via SET_CHECKSUM_REQUIRED.UDP. Implementation over TCP: do nothing (TCP does not offer to disable the checksum, but transmitting data with an intact checksum will not yield a semantically wrong result). o Specify checksum coverage used by the sender Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. Welzl & Gjessing Expires February 21, 2019 [Page 29] =0C Internet-Draft Minimal Transport Services August 2018 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result). Implementation over UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum when sending". o Specify minimum checksum coverage required by receiver Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. Implementation: via SET_MIN_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result). Implementation over UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum requirement when receiving". o Specify DF field Protocols: UDP(-Lite) Optimizing because the DF field can be used to carry out Path MTU Discovery, which can lead an application to choose message sizes that can be transmitted more efficiently. Implementation: via MAINTENANCE.SET_DF.UDP(-Lite) and SEND_FAILURE.UDP(-Lite). Implementation over TCP: do nothing (with TCP, the sending application is not in control of transport message sizes, making this functionality irrelevant). o Get max. transport-message size that may be sent using a non- fragmented IP packet from the configured interface Protocols: UDP(-Lite) Optimizing because this can lead an application to choose message sizes that can be transmitted more efficiently. Implementation over TCP: do nothing (this information is not available with TCP). Welzl & Gjessing Expires February 21, 2019 [Page 30] =0C Internet-Draft Minimal Transport Services August 2018 o Get max. transport-message size that may be received from the configured interface Protocols: UDP(-Lite) Optimizing because this can, for example, influence an application's memory management. Implementation over TCP: do nothing (this information is not available with TCP). o Specify TTL/Hop count field Protocols: UDP(-Lite) Automatable because a transport system can use a large enough system default to avoid communication failures. Allowing an application to configure it differently can produce notifications of ICMP error message arrivals that yield information which only relates to knowledge about the network, not the application. o Obtain TTL/Hop count field Protocols: UDP(-Lite) Automatable because the TTL/Hop count field relates to knowledge about the network, not the application. o Specify ECN field Protocols: UDP(-Lite) Automatable because the ECN field relates to knowledge about the network, not the application. o Obtain ECN field Protocols: UDP(-Lite) Optimizing because this information can be used by an application to better carry out congestion control (this is relevant when choosing a data transmission transport service that does not already do congestion control). Implementation over TCP: do nothing (this information is not available with TCP). o Specify IP Options Protocols: UDP(-Lite) Welzl & Gjessing Expires February 21, 2019 [Page 31] =0C Internet-Draft Minimal Transport Services August 2018 Automatable because IP Options relate to knowledge about the network, not the application. o Obtain IP Options Protocols: UDP(-Lite) Automatable because IP Options relate to knowledge about the network, not the application. o Enable and configure a "Low Extra Delay Background Transfer" Protocols: A protocol implementing the LEDBAT congestion control mechanism Optimizing because whether this service is appropriate or not depends on application-specific knowledge. However, wrongly using this will only affect the speed of data transfers (albeit including other transfers that may compete with the transport system's transfer in the network), so it is still correct within the "best effort" service model. Implementation: via CONFIGURE.LEDBAT and/or SET_DSCP.TCP / SET_DSCP.SCTP / SET_DSCP.UDP(-Lite) [LBE-draft]. Implementation over TCP: do nothing (TCP does not support LEDBAT congestion control, but not implementing this functionality will not yield a semantically wrong behavior). Implementation over UDP: do nothing (UDP does not offer congestion control). TERMINATION: o Close after reliably delivering all remaining data, causing an event informing the application on the other side Protocols: TCP, SCTP Functional because the notion of a connection is often reflected in applications as an expectation to have all outstanding data delivered and no longer be able to communicate after a "Close" succeeded, with a communication sequence relating to this transport feature that is defined by the application protocol. Implementation: via CLOSE.TCP and CLOSE.SCTP. Implementation over UDP: not possible (UDP is unreliable and hence does not know when all remaining data is delivered; it does also not offer to cause an event related to closing at the peer). Welzl & Gjessing Expires February 21, 2019 [Page 32] =0C Internet-Draft Minimal Transport Services August 2018 o Abort without delivering remaining data, causing an event informing the application on the other side Protocols: TCP, SCTP Functional because the notion of a connection is often reflected in applications as an expectation to potentially not have all outstanding data delivered and no longer be able to communicate after an "Abort" succeeded. On both sides of a connection, an application protocol may define a communication sequence relating to this transport feature. Implementation: via ABORT.TCP and ABORT.SCTP. Implementation over UDP: not possible (UDP does not offer to cause an event related to aborting at the peer). o Abort without delivering remaining data, not causing an event informing the application on the other side Protocols: UDP(-Lite) Functional because the notion of a connection is often reflected in applications as an expectation to potentially not have all outstanding data delivered and no longer be able to communicate after an "Abort" succeeded. On both sides of a connection, an application protocol may define a communication sequence relating to this transport feature. Implementation: via ABORT.UDP(-Lite). Implementation over TCP: stop using the connection, wait for a timeout. o Timeout event when data could not be delivered for too long Protocols: TCP, SCTP Functional because this notifies that potentially assumed reliable data delivery is no longer provided. Implementation: via TIMEOUT.TCP and TIMEOUT.SCTP. Implementation over UDP: do nothing (this event will not occur with UDP). A.1.2. DATA Transfer Related Transport Features A.1.2.1. Sending Data o Reliably transfer data, with congestion control Protocols: TCP, SCTP Welzl & Gjessing Expires February 21, 2019 [Page 33] =0C Internet-Draft Minimal Transport Services August 2018 Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.TCP and SEND.SCTP. Implementation over UDP: not possible (UDP is unreliable). o Reliably transfer a message, with congestion control Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Implementation over TCP: via SEND.TCP. With SEND.TCP, message boundaries will not be identifiable by the receiver, because TCP provides a byte stream service. Implementation over UDP: not possible (UDP is unreliable). o Unreliably transfer a message Protocols: SCTP, UDP(-Lite) Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. ADDED. This differs from the 2 automatable transport features below in that it leaves the choice of congestion control open. Implementation: via SEND.SCTP or SEND.UDP(-Lite). Implementation over TCP: use SEND.TCP. With SEND.TCP, messages will be sent reliably, and message boundaries will not be identifiable by the receiver. o Unreliably transfer a message, with congestion control Protocols: SCTP Automatable because congestion control relates to knowledge about the network, not the application. o Unreliably transfer a message, without congestion control Protocols: UDP(-Lite) Automatable because congestion control relates to knowledge about the network, not the application. Welzl & Gjessing Expires February 21, 2019 [Page 34] =0C Internet-Draft Minimal Transport Services August 2018 o Configurable Message Reliability Protocols: SCTP Optimizing because only applications know about the time criticality of their communication, and reliably transfering a message is never incorrect for the receiver of a potentially unreliable data transfer, it is just slower. Implementation: via SEND.SCTP. Implementation over TCP: By using SEND.TCP and ignoring this configuration: based on the assumption of the best-effort service model, unnecessarily delivering data does not violate application expectations. Moreover, it is not possible to associate the requested reliability to a "message" in TCP anyway. Implementation over UDP: not possible (UDP is unreliable). o Choice of stream Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see Appendix A.3.2. o Choice of path (destination address) Protocols: SCTP Automatable because it requires using multiple sockets, but obtaining multiple sockets in the CONNECTION.ESTABLISHMENT category is automatable. o Ordered message delivery (potentially slower than unordered) Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Implementation over TCP: By using SEND.TCP. With SEND.TCP, messages will not be identifiable by the receiver. Implementation over UDP: not possible (UDP does not offer any guarantees regarding ordering). o Unordered message delivery (potentially faster than ordered) Protocols: SCTP, UDP(-Lite) Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via SEND.SCTP. Welzl & Gjessing Expires February 21, 2019 [Page 35] =0C Internet-Draft Minimal Transport Services August 2018 Implementation over TCP: By using SEND.TCP and always sending data ordered: based on the assumption of the best-effort service model, ordered delivery may just be slower and does not violate application expectations. Moreover, it is not possible to associate the requested delivery order to a "message" in TCP anyway. o Request not to bundle messages Protocols: SCTP Optimizing because this decision depends on knowledge about the size of future data blocks and the delay between them. Implementation: via SEND.SCTP. Implementation over TCP: By using SEND.TCP and DISABLE_NAGLE.TCP to disable the Nagle algorithm when the request is made and enable it again when the request is no longer made. Note that this is not fully equivalent because it relates to the time of issuing the request rather than a specific message. Implementation over UDP: do nothing (UDP never bundles messages). o Specifying a "payload protocol-id" (handed over as such by the receiver) Protocols: SCTP Functional because it allows to send extra application data with every message, for the sake of identification of data, which by itself is application-specific. Implementation: SEND.SCTP. Implementation over TCP: not possible (this functionality is not available in TCP). Implementation over UDP: not possible (this functionality is not available in UDP). o Specifying a key id to be used to authenticate a message Protocols: SCTP Functional because this has a direct influence on security. Implementation: via a parameter in SEND.SCTP. Implementation over TCP: This could be emulated by using SET_AUTH.TCP before and after the message is sent. Note that this is not fully equivalent because it relates to the time of issuing the request rather than a specific message. Implementation over UDP: not possible (UDP does not offer authentication). Welzl & Gjessing Expires February 21, 2019 [Page 36] =0C Internet-Draft Minimal Transport Services August 2018 o Request not to delay the acknowledgement (SACK) of a message Protocols: SCTP Optimizing because only an application knows for which message it wants to quickly be informed about success / failure of its delivery. Implementation over TCP: do nothing (TCP does not offer this functionality, but ignoring this request from the application will not yield a semantically wrong behavior). Implementation over UDP: do nothing (UDP does not offer this functionality, but ignoring this request from the application will not yield a semantically wrong behavior). A.1.2.2. Receiving Data o Receive data (with no message delimiting) Protocols: TCP Functional because a transport system must be able to send and receive data. Implementation: via RECEIVE.TCP. Implementation over UDP: do nothing (UDP only works on messages; these can be handed over, the application can still ignore the message boundaries). o Receive a message Protocols: SCTP, UDP(-Lite) Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via RECEIVE.SCTP and RECEIVE.UDP(-Lite). Implementation over TCP: not possible (TCP does not support identification of message boundaries). o Choice of stream to receive from Protocols: SCTP Automatable because it requires using multiple streams, but requesting multiple streams in the CONNECTION.ESTABLISHMENT category is automatable. Implementation: see Appendix A.3.2. o Information about partial message arrival Protocols: SCTP Welzl & Gjessing Expires February 21, 2019 [Page 37] =0C Internet-Draft Minimal Transport Services August 2018 Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation: via RECEIVE.SCTP. Implementation over TCP: do nothing (this information is not available with TCP). Implementation over UDP: do nothing (this information is not available with UDP). A.1.2.3. Errors This section describes sending failures that are associated with a specific call to in the "Sending Data" category (Appendix A.1.2.1). o Notification of send failures Protocols: SCTP, UDP(-Lite) Functional because this notifies that potentially assumed reliable data delivery is no longer provided. ADDED. This differs from the 2 automatable transport features below in that it does not distinugish between unsent and unacknowledged messages. Implementation: via SENDFAILURE-EVENT.SCTP and SEND_FAILURE.UDP(- Lite). Implementation over TCP: do nothing (this notification is not available and will therefore not occur with TCP). o Notification of an unsent (part of a) message Protocols: SCTP, UDP(-Lite) Automatable because the distinction between unsent and unacknowledged is network-specific. o Notification of an unacknowledged (part of a) message Protocols: SCTP Automatable because the distinction between unsent and unacknowledged is network-specific. o Notification that the stack has no more user data to send Protocols: SCTP Welzl & Gjessing Expires February 21, 2019 [Page 38] =0C Internet-Draft Minimal Transport Services August 2018 Optimizing because reacting to this notification requires the application to be involved, and ensuring that the stack does not run dry of data (for too long) can improve performance. Implementation over TCP: do nothing (see the discussion in Appendix A.3.4). Implementation over UDP: do nothing (this notification is not available and will therefore not occur with UDP). o Notification to a receiver that a partial message delivery has been aborted Protocols: SCTP Functional because this is closely tied to properties of the data that an application sends or expects to receive. Implementation over TCP: do nothing (this notification is not available and will therefore not occur with TCP). Implementation over UDP: do nothing (this notification is not available and will therefore not occur with UDP). A.2. Step 2: Reduction -- The Reduced Set of Transport Features By hiding automatable transport features from the application, a transport system can gain opportunities to automate the usage of network-related functionality. This can facilitate using the transport system for the application programmer and it allows for optimizations that may not be possible for an application. For instance, system-wide configurations regarding the usage of multiple interfaces can better be exploited if the choice of the interface is not entirely up to the application. Therefore, since they are not strictly necessary to expose in a transport system, we do not include automatable transport features in the reduced set of transport features. This leaves us with only the transport features that are either optimizing or functional. A transport system should be able to communicate via TCP or UDP if alternative transport protocols are found not to work. For many transport features, this is possible -- often by simply not doing anything when a specific request is made. For some transport features, however, it was identified that direct usage of neither TCP nor UDP is possible: in these cases, even not doing anything would incur semantically incorrect behavior. Whenever an application would make use of one of these transport features, this would eliminate the possibility to use TCP or UDP. Thus, we only keep the functional and Welzl & Gjessing Expires February 21, 2019 [Page 39] =0C Internet-Draft Minimal Transport Services August 2018 optimizing transport features for which an implementation over either TCP or UDP is possible in our reduced set. The "minimal set" derived in this document is meant to be implementable "one-sided" over TCP, and, with limitations, UDP. In the following list, we therefore precede a transport feature with "T:" if an implementation over TCP is possible, "U:" if an implementation over UDP is possible, and "TU:" if an implementation over either TCP or UDP is possible. A.2.1. CONNECTION Related Transport Features ESTABLISHMENT: o T,U: Connect o T,U: Specify number of attempts and/or timeout for the first establishment message o T: Configure authentication o T: Hand over a message to reliably transfer (possibly multiple times) before connection establishment o T: Hand over a message to reliably transfer during connection establishment AVAILABILITY: o T,U: Listen o T: Configure authentication MAINTENANCE: o T: Change timeout for aborting connection (using retransmit limit or time value) o T: Suggest timeout to the peer o T,U: Disable Nagle algorithm o T,U: Notification of Excessive Retransmissions (early warning below abortion threshold) o T,U: Specify DSCP field o T,U: Notification of ICMP error message arrival o T: Change authentication parameters o T: Obtain authentication information o T,U: Set Cookie life value o T,U: Choose a scheduler to operate between streams of an association o T,U: Configure priority or weight for a scheduler o T,U: Disable checksum when sending o T,U: Disable checksum requirement when receiving o T,U: Specify checksum coverage used by the sender o T,U: Specify minimum checksum coverage required by receiver Welzl & Gjessing Expires February 21, 2019 [Page 40] =0C Internet-Draft Minimal Transport Services August 2018 o T,U: Specify DF field o T,U: Get max. transport-message size that may be sent using a non- fragmented IP packet from the configured interface o T,U: Get max. transport-message size that may be received from the configured interface o T,U: Obtain ECN field o T,U: Enable and configure a "Low Extra Delay Background Transfer" TERMINATION: o T: Close after reliably delivering all remaining data, causing an event informing the application on the other side o T: Abort without delivering remaining data, causing an event informing the application on the other side o T,U: Abort without delivering remaining data, not causing an event informing the application on the other side o T,U: Timeout event when data could not be delivered for too long A.2.2. DATA Transfer Related Transport Features A.2.2.1. Sending Data o T: Reliably transfer data, with congestion control o T: Reliably transfer a message, with congestion control o T,U: Unreliably transfer a message o T: Configurable Message Reliability o T: Ordered message delivery (potentially slower than unordered) o T,U: Unordered message delivery (potentially faster than ordered) o T,U: Request not to bundle messages o T: Specifying a key id to be used to authenticate a message o T,U: Request not to delay the acknowledgement (SACK) of a message A.2.2.2. Receiving Data o T,U: Receive data (with no message delimiting) o U: Receive a message o T,U: Information about partial message arrival A.2.2.3. Errors This section describes sending failures that are associated with a specific call to in the "Sending Data" category (Appendix A.1.2.1). o T,U: Notification of send failures o T,U: Notification that the stack has no more user data to send o T,U: Notification to a receiver that a partial message delivery has been aborted Welzl & Gjessing Expires February 21, 2019 [Page 41] =0C Internet-Draft Minimal Transport Services August 2018 A.3. Step 3: Discussion The reduced set in the previous section exhibits a number of peculiarities, which we will discuss in the following. This section focuses on TCP because, with the exception of one particular transport feature ("Receive a message" -- we will discuss this in Appendix A.3.1), the list shows that UDP is strictly a subset of TCP. We can first try to understand how to build a transport system that can run over TCP, and then narrow down the result further to allow that the system can always run over either TCP or UDP (which effectively means removing everything related to reliability, ordering, authentication and closing/aborting with a notification to the peer). Note that, because the functional transport features of UDP are -- with the exception of "Receive a message" -- a subset of TCP, TCP can be used as a replacement for UDP whenever an application does not need message delimiting (e.g., because the application-layer protocol already does it). This has been recognized by many applications that already do this in practice, by trying to communicate with UDP at first, and falling back to TCP in case of a connection failure. A.3.1. Sending Messages, Receiving Bytes For implementing a transport system over TCP, there are several transport features related to sending, but only a single transport feature related to receiving: "Receive data (with no message delimiting)" (and, strangely, "information about partial message arrival"). Notably, the transport feature "Receive a message" is also the only non-automatable transport feature of UDP(-Lite) for which no implementation over TCP is possible. To support these TCP receiver semantics, we define an "Application- Framed Bytestream" (AFra-Bytestream). AFra-Bytestreams allow senders to operate on messages while minimizing changes to the TCP socket API. In particular, nothing changes on the receiver side - data can be accepted via a normal TCP socket. In an AFra-Bytestream, the sending application can optionally inform the transport about message boundaries and required properties per message (configurable order and reliability, or embedding a request not to delay the acknowledgement of a message). Whenever the sending application specifies per-message properties that relax the notion of reliable in-order delivery of bytes, it must assume that the receiving application is 1) able to determine message boundaries, provided that messages are always kept intact, and 2) able to accept these relaxed per-message properties. Any signaling of such Welzl & Gjessing Expires February 21, 2019 [Page 42] =0C Internet-Draft Minimal Transport Services August 2018 information to the peer is up to an application-layer protocol and considered out of scope of this document. For example, if an application requests to transfer fixed-size messages of 100 bytes with partial reliability, this needs the receiving application to be prepared to accept data in chunks of 100 bytes. If, then, some of these 100-byte messages are missing (e.g., if SCTP with Configurable Reliability is used), this is the expected application behavior. With TCP, no messages would be missing, but this is also correct for the application, and the possible retransmission delay is acceptable within the best effort service model (see [RFC7305], Section 3.5). Still, the receiving application would separate the byte stream into 100-byte chunks. Note that this usage of messages does not require all messages to be equal in size. Many application protocols use some form of Type- Length-Value (TLV) encoding, e.g. by defining a header including length fields; another alternative is the use of byte stuffing methods such as COBS [COBS]. If an application needs message numbers, e.g. to restore the correct sequence of messages, these must also be encoded by the application itself, as the sequence number related transport features of SCTP are not provided by the "minimum set" (in the interest of enabling usage of TCP). A.3.2. Stream Schedulers Without Streams We have already stated that multi-streaming does not require application-specific knowledge. Potential benefits or disadvantages of, e.g., using two streams of an SCTP association versus using two separate SCTP associations or TCP connections are related to knowledge about the network and the particular transport protocol in use, not the application. However, the transport features "Choose a scheduler to operate between streams of an association" and "Configure priority or weight for a scheduler" operate on streams. Here, streams identify communication channels between which a scheduler operates, and they can be assigned a priority. Moreover, the transport features in the MAINTENANCE category all operate on assocations in case of SCTP, i.e. they apply to all streams in that assocation. With only these semantics necessary to represent, the interface to a transport system becomes easier if we assume that connections may be a transport protocol's connection or association, but could also be a stream of an existing SCTP association, for example. We only need to allow for a way to define a possible grouping of connections. Then, all MAINTENANCE transport features can be said to operate on connection groups, not connections, and a scheduler operates on the connections within a group. Welzl & Gjessing Expires February 21, 2019 [Page 43] =0C Internet-Draft Minimal Transport Services August 2018 To be compatible with multiple transport protocols and uniformly allow access to both transport connections and streams of a multi- streaming protocol, the semantics of opening and closing need to be the most restrictive subset of all of the underlying options. For example, TCP's support of half-closed connections can be seen as a feature on top of the more restrictive "ABORT"; this feature cannot be supported because not all protocols used by a transport system (including streams of an association) support half-closed connections. A.3.3. Early Data Transmission There are two transport features related to transferring a message early: "Hand over a message to reliably transfer (possibly multiple times) before connection establishment", which relates to TCP Fast Open [RFC7413], and "Hand over a message to reliably transfer during connection establishment", which relates to SCTP's ability to transfer data together with the COOKIE-Echo chunk. Also without TCP Fast Open, TCP can transfer data during the handshake, together with the SYN packet -- however, the receiver of this data may not hand it over to the application until the handshake has completed. Also, different from TCP Fast Open, this data is not delimited as a message by TCP (thus, not visible as a ``message''). This functionality is commonly available in TCP and supported in several implementations, even though the TCP specification does not explain how to provide it to applications. A transport system could differentiate between the cases of transmitting data "before" (possibly multiple times) or "during" the handshake. Alternatively, it could also assume that data that are handed over early will be transmitted as early as possible, and "before" the handshake would only be used for messages that are explicitly marked as "idempotent" (i.e., it would be acceptable to transfer them multiple times). The amount of data that can successfully be transmitted before or during the handshake depends on various factors: the transport protocol, the use of header options, the choice of IPv4 and IPv6 and the Path MTU. A transport system should therefore allow a sending application to query the maximum amount of data it can possibly transmit before (or, if exposed, during) connection establishment. A.3.4. Sender Running Dry The transport feature "Notification that the stack has no more user data to send" relates to SCTP's "SENDER DRY" notification. Such notifications can, in principle, be used to avoid having an unnecessarily large send buffer, yet ensure that the transport sender Welzl & Gjessing Expires February 21, 2019 [Page 44] =0C Internet-Draft Minimal Transport Services August 2018 always has data available when it has an opportunity to transmit it. This has been found to be very beneficial for some applications [WWDC2015]. However, "SENDER DRY" truly means that the entire send buffer (including both unsent and unacknowledged data) has emptied -- i.e., when it notifies the sender, it is already too late, the transport protocol already missed an opportunity to send data. Some modern TCP implementations now include the unspecified "TCP_NOTSENT_LOWAT" socket option that was proposed in [WWDC2015], which limits the amount of unsent data that TCP can keep in the socket buffer; this allows to specify at which buffer filling level the socket becomes writable, rather than waiting for the buffer to run empty. SCTP allows to configure the sender-side buffer too: the automatable Transport Feature "Configure send buffer size" provides this functionality, but only for the complete buffer, which includes both unsent and unacknowledged data. SCTP does not allow to control these two sizes separately. It therefore makes sense for a transport system to allow for uniform access to "TCP_NOTSENT_LOWAT" as well as the "SENDER DRY" notification. A.3.5. Capacity Profile The transport features: o Disable Nagle algorithm o Enable and configure a "Low Extra Delay Background Transfer" o Specify DSCP field all relate to a QoS-like application need such as "low latency" or "scavenger". In the interest of flexibility of a transport system, they could therefore be offered in a uniform, more abstract way, where a transport system could e.g. decide by itself how to use combinations of LEDBAT-like congestion control and certain DSCP values, and an application would only specify a general "capacity profile" (a description of how it wants to use the available capacity). A need for "lowest possible latency at the expense of overhead" could then translate into automatically disabling the Nagle algorithm. In some cases, the Nagle algorithm is best controlled directly by the application because it is not only related to a general profile but also to knowledge about the size of future messages. For fine-grain control over Nagle-like functionality, the "Request not to bundle messages" is available. Welzl & Gjessing Expires February 21, 2019 [Page 45] =0C Internet-Draft Minimal Transport Services August 2018 A.3.6. Security Both TCP and SCTP offer authentication. TCP authenticates complete segments. SCTP allows to configure which of SCTP's chunk types must always be authenticated -- if this is exposed as such, it creates an undesirable dependency on the transport protocol. For compatibility with TCP, a transport system should only allow to configure complete transport layer packets, including headers, IP pseudo-header (if any) and payload. Security is discussed in a separate document [I-D.ietf-taps-transport-security]. The minimal set presented in the present document therefore excludes all security related transport features: "Configure authentication", "Change authentication parameters", "Obtain authentication information" and and "Set Cookie life value" as well as "Specifying a key id to be used to authenticate a message". A.3.7. Packet Size UDP(-Lite) has a transport feature called "Specify DF field". This yields an error message in case of sending a message that exceeds the Path MTU, which is necessary for a UDP-based application to be able to implement Path MTU Discovery (a function that UDP-based applications must do by themselves). The "Get max. transport-message size that may be sent using a non-fragmented IP packet from the configured interface" transport feature yields an upper limit for the Path MTU (minus headers) and can therefore help to implement Path MTU Discovery more efficiently. Appendix B. Revision information XXX RFC-Ed please remove this section prior to publication. -02: implementation suggestions added, discussion section added, terminology extended, DELETED category removed, various other fixes; list of Transport Features adjusted to -01 version of [RFC8303] except that MPTCP is not included. -03: updated to be consistent with -02 version of [RFC8303]. -04: updated to be consistent with -03 version of [RFC8303]. Reorganized document, rewrote intro and conclusion, and made a first stab at creating a real "minimal set". -05: updated to be consistent with -05 version of [RFC8303] (minor changes). Fixed a mistake regarding Cookie Life value. Exclusion of security related transport features (to be covered in a separate Welzl & Gjessing Expires February 21, 2019 [Page 46] =0C Internet-Draft Minimal Transport Services August 2018 document). Reorganized the document (now begins with the minset, derivation is in the appendix). First stab at an abstract API for the minset. draft-ietf-taps-minset-00: updated to be consistent with -08 version of [RFC8303] ("obtain message delivery number" was removed, as this has also been removed in [RFC8303] because it was a mistake in RFC4960. This led to the removal of two more transport features that were only designated as functional because they affected "obtain message delivery number"). Fall-back to UDP incorporated (this was requested at IETF-99); this also affected the transport feature "Choice between unordered (potentially faster) or ordered delivery of messages" because this is a boolean which is always true for one fall-back protocol, and always false for the other one. This was therefore now divided into two features, one for ordered, one for unordered delivery. The word "reliably" was added to the transport features "Hand over a message to reliably transfer (possibly multiple times) before connection establishment" and "Hand over a message to reliably transfer during connection establishment" to make it clearer why this is not supported by UDP. Clarified that the "minset abstract interface" is not proposing a specific API for all TAPS systems to implement, but it is just a way to describe the minimum set. Author order changed. WG -01: "fall-back to" (TCP or UDP) replaced (mostly with "implementation over"). References to post-sockets removed (these were statments that assumed that post-sockets requires two-sided implementation). Replaced "flow" with "TAPS Connection" and "frame" with "message" to avoid introducing new terminology. Made sections 3 and 4 in line with the categorization that is already used in the appendix and [RFC8303], and changed style of section 4 to be even shorter and less interface-like. Updated reference draft-ietf-tsvwg- sctp-ndata to RFC8260. WG -02: rephrased "the TAPS system" and "TAPS connection" etc. to more generally talk about transport after the intro (mostly replacing "TAPS system" with "transport system" and "TAPS connection" with "connection". Merged sections 3 and 4 to form a new section 3. WG -03: updated sentence referencing [I-D.ietf-taps-transport-security] to say that "the minimum security requirements for a taps system are discussed in a separate security document", wrote "example" in the paragraph introducing the decision tree. Removed reference draft-grinnemo-taps-he-03 and the sentence that referred to it. Welzl & Gjessing Expires February 21, 2019 [Page 47] =0C Internet-Draft Minimal Transport Services August 2018 WG -04: addressed comments from Theresa Enghardt and Tommy Pauly. As part of that, removed "TAPS" as a term everywhere (abstract, intro, ..). WG -05: addressed comments from Spencer Dawkins. Authors' Addresses Michael Welzl University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 20 Email: michawe@ifi.uio.no Stein Gjessing University of Oslo PO Box 1080 Blindern Oslo N-0316 Norway Phone: +47 22 85 24 44 Email: steing@ifi.uio.no Welzl & Gjessing Expires February 21, 2019 [Page 48] --Apple-Mail=_3D38BCFA-80AD-4279-801D-6CB64EA53AA6-- From nobody Mon Aug 20 06:52:18 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 786A4130E45; Mon, 20 Aug 2018 06:52:16 -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 N5abD_YdfMek; Mon, 20 Aug 2018 06:52:13 -0700 (PDT) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 35FCE130E44; Mon, 20 Aug 2018 06:52:13 -0700 (PDT) Received: by mail-yw1-xc29.google.com with SMTP id s68-v6so6843670ywg.2; Mon, 20 Aug 2018 06:52:13 -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=+9IllWNIZZfLCgEVCF9NehJl7d3XdeVgv5eyQx1AZG8=; b=kOmy1wySI6QYUq5V3a2++EwD0Uznd78hTgbyKj3R7wANItO76Ln75goE7M6iI40wE5 SuBRaI+7eC6YWHN/AKUTMLgAzIHyz9n7dC5PHQTLl8LBW+nZRjjmBvIeBionwYV/Kheu hBxnLyrGyEU2/zFK8cFygQywlCD73q05H0ra4BeTw07QI38gGZX2af2uhPVYAB7tl0Hq hVq3FXo8Gp+5CaBY/HsiwVLgHAaonMf4cHFM6JCmPYzmwDkqMsjopIx33gDKGgWr1LDg AneY6Rdq334oXbZdVqhojRWjY/wELN1KxfYkY5DVbF3taNNKaScyk15XmRspIFwR5+8N oFqg== 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=+9IllWNIZZfLCgEVCF9NehJl7d3XdeVgv5eyQx1AZG8=; b=UtZOXin47vkxShtJpOXFMTYDzsl7TFKnW5I0cnbairxAnIqo9Oue+rlDY7YykRGlRO oNIOtGfRZw26bAhFjYNA5JVeLIv9AsdpMKyswPEyW/BsDQ1ACX3g8Oz92XGCAWdiFvL5 uaMF9JLeEfqHYro5RMfTgKYpVv7WX5O+6r1qd2MCdzzQAd23Ol40qt5uCndk0GzB/R3Z WwUhXkgcWC4f7wiJoBAKHfYt/wEXMa7rRgqOe8xBP4GdmkwuiwKRaXV4UFeqLTaPVc35 IykgKUYqgdsGK7fYccCNOeVh79HHebC1K4SjFSmtT/CxxtuL07LODngc4Q0figH9J8uu r9DQ== X-Gm-Message-State: AOUpUlFzUGnwQkyUeRLQLGaCO3XCM0pJpIlhpCqirdP8Oh2L/Ib8j3Qc AJa3bZ0hO8BUAoACjx9HqIp2CnLRATkf45Tfxg0fQ2nf X-Google-Smtp-Source: AA+uWPzJx7uRa61PLfZRqot6rDBLX/419Up4wu6wweXe9xMCObjEHY+oqy4eFEg386R5uULO/9ek+TCmscvbFSk1Jws= X-Received: by 2002:a81:7957:: with SMTP id u84-v6mr4472488ywc.285.1534773132188; Mon, 20 Aug 2018 06:52:12 -0700 (PDT) MIME-Version: 1.0 References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> In-Reply-To: <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> From: Spencer Dawkins at IETF Date: Mon, 20 Aug 2018 08:52:00 -0500 Message-ID: To: Michael Welzl Cc: draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , taps WG Content-Type: multipart/alternative; boundary="0000000000005adf890573de371e" Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 13:52:17 -0000 --0000000000005adf890573de371e Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl wrote: > Hi Spencer! > > Thank you so much for your detailed work and all these comments! > I'm commenting in line below, and marking my comments with "MW:". > I'm terminating my responses with a "--". > > I'm attaching an update which incorporates the changes described in this > email, but I'm delaying its submission until it's clear that this > conversation has converged. > We're pretty darned converged. I have a couple of follow-ups below, but I deleted everything that we're already good on (and thank you for those, in advance). My only significant question is on Section 7. Spencer > -- > > This text in 7. Security Considerations > > Authentication, confidentiality protection, and integrity protection > are identified as transport features by [RFC8095]. As currently > deployed in the Internet, these features are generally provided by a > protocol or layer on top of the transport protocol; no current full- > featured standards-track transport protocol provides all of these > transport features on its own. Therefore, these transport features > are not considered in this document, with the exception of native > authentication capabilities of TCP and SCTP for which the security > considerations in [RFC5925] and [RFC4895] apply. The minimum > security requirements for a transport system are discussed in a > separate document [I-D.ietf-taps-transport-security]. > > confuses me, because I think at least two things are in play. First, I > think the point you're probably making is that the underlying transport > protocols remain unmodified, so the security considerations for each of > those protocols apply unchanged, and this document isn't doing anything to > create new security considerations. So, modulo SECDIR and SEC AD comments, > I think that's all you need to say. > > Second, you guys are the experts, but I think a reference to > [I-D.ietf-taps-transport-security] isn't actually needed for this document, > because that document surveys security protocols, rather than specifying > minimum security requirements. That document might someday discuss the > minimum security requirements, in the way this document discusses the > minimum set of transport services, but at least in > https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that > document is much more comparable to RFCs 8095 and 8304 than to this > document. > > MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't > have section 5. > I believe section 5 in this document is an effort to do the same as minset > does, here; > are you maybe asking for this section of > [I-D.ietf-taps-transport-security] to use a > more authoritative tone? Either way, as things stand now, the existence of > [I-D.ietf-taps-transport-security] is used as a justification to not > include the > security related features of TCP and SCTP in the minimum set, and I think > this > citation is necessary. > So, for what it's worth, I wouldn't have ever noticed that Section 5 of [I-D.ietf-taps-transport-security] provided the equivalent of this document, based on the Abstract and Introduction, which both talk about surveys a lot more than minimum sets, but that's not your problem to solve (and I'm not providing AD comments on documents that the working group is still working on, because you guys are more likely to get stuff right than I am, so no action required from anyone else). But what is for you ... At a minimum, I'd suggest qualifying the reference to [I-D.ietf-taps-transport-security] as "Section 5 of [I-D.ietf-taps-transport-security] ", because I don't suppose that any other reviewer is more likely to figure this out than I am, but ... Quoting from the Introduction in -02 of I-D.ietf-taps-transport-security, what that draft is covering is 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. I may be confused about this, but I'm not seeing an obvious pattern match between those protocols and "security related features of TCP and SCTP in the minimum set". Is that document talking about what you hope it's talking about? Assuming so ... I'm probably struggling with the idea that there is no minimal set of transport services that doesn't involve one of the protocols listed in I-D.ietf-taps-transport-security or a near equivalent. That may really be the right thing for the working group to say, but I wanted to make sure that's the point that's being made, because that's what I think you're saying, by including the reference to I-D.ietf-taps-transport-security in your security considerations. If the last sentence read The minimum {delete "security"} requirements for a {insert "secure"} secure transport system are discussed in a separate document [I-D.ietf-taps-transport-security]. I'd agree with that statement, without anyone having to explain anything to me! But we'll be ready for Last Call on your next version, either way. > -- > > You folks know what you actually did, but I'm hoping that > > 2. Reduction: a shorter list of transport features is derived from > the categorization in the first step. This removes all transport > features that do not require application-specific knowledge or > cannot be implemented with TCP or UDP. > > was actually "cannot be implemented with TCP, SCTP, or UDP". Was that an > omission in this text, or do we need to chat? > > MW: the point was that TCP and UDP can't work as a fall-back in case e.g. > SCTP isn't available. As stated at the beginning of the document, the > minset can be implemented "one-sided" over TCP. (and with some > limitations, also UDP). For example: it's fine (within "best effort") to > always send everything in order when an application allows out-of-order > delivery - but there's simply no way to implement SCTP's out-of-band > transmission of a number ("Indicate (and/or obtain upon completion) an > Adaptation Layer via an adaptation code point") with TCP or UDP. If an > application relies on that, TCP or UDP fall-backs become impossible. We > were asked to avoid writing using the term "fall-back", for good reasons, > but this particular sentence may have ended up being less clear as we > simply replaced "fall-back" with "implemented with". > > I changed the sentence as follows, is it better? > > NEW: > > This removes all transport features that do not require > application-specific knowledge or would result in semantically incorrect > behavior if they were implemented over TCP or UDP. > I'm not entirely sure why, but this helps me a lot. Thanks for making the suggestion. It works for me. > > -- > > (Somewhere about here, I started thinking about "automated" - I didn't see > a clear definition of this in the document. I think I understand what you > mean at a hand-waving level, but you might consider adding a definition > earlier in the document, so that's clearer without relying on context > clues. > > MW: "automated" doesn't appear in the draft - I'm sure you mean > "automatable". > It only appears in the appendix, where it's defined upon its first > occurrence, in paragraph 5 of Appendix A.1, as follows: "The transport > features of IETF transport protocols that do not require > application-specific knowledge and could therefore be transparently > utilized by a transport system are called "Automatable"." - maybe you just > missed this? I believe it's in the most suitable place. I now made this > sentence a bit clearer now, by changing it into: "The transport features of > IETF transport protocols that do not require application-specific knowledge > and could therefore be utilized by a transport system on its own without > involving the application are called "Automatable"." > Good work. Here, you guessed what *I* meant. "Writing text is hard" - Spencer. Aaron has many examples of Spencer proving this, dating back to us being co-chairs in PILC in the late 1990s. But your suggested text (answers the comment I was trying to make, and) works for me. Thanks for that. > -- > > And finally, at a high level, I don't understand why there are > "Implementation over $Protocol" lines so often that name $Protocols that > weren't listed in "Protocols:" at the beginning of each description. I have > several guesses about what that might mean, but I bet all of them are > wrong, so I have to ask. > > MW: maybe that's related to your confusion about the omission of SCTP, > which I hope > I have addressed (as explained above). So that's answered by text that > appears just before we list the transport features, which now reads: > "The "minimal set" derived in this document is meant to be implementable > "one-sided" over TCP, and, with limitations, UDP. Hence, for all transport > features that are categorized as "functional" or "optimizing", and for > which no matching TCP and/or UDP primitive exists in "pass 2" of [RFC8303], > a brief discussion on how to implement > them over TCP and/or UDP is included." > Again, that's fixing my confusion above. Thanks for that. --0000000000005adf890573de371e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

Hi Spencer!

Thank you so much for your detailed work and all these comments!
I'm commenting in line below, and marking my comments with "MW:&qu= ot;.
I'm terminating my responses with a "--".

I'm attaching an update which incorporates the changes described in thi= s email, but I'm delaying its submission until it's clear that this= conversation has converged.

We're = pretty darned converged. I have a couple of follow-ups below, but I deleted= everything that we're already good on (and thank you for those, in adv= ance).

My only significant question is on Section = 7.=C2=A0

Spencer
=C2=A0
--

This text in 7.=C2=A0 Security Considerations

=C2=A0 =C2=A0Authentication, confidentiality protection, and integrity prot= ection
=C2=A0 =C2=A0are identified as transport features by [RFC8095].=C2=A0 As cu= rrently
=C2=A0 =C2=A0deployed in the Internet, these features are generally provide= d by a
=C2=A0 =C2=A0protocol or layer on top of the transport protocol; no current= full-
=C2=A0 =C2=A0featured standards-track transport protocol provides all of th= ese
=C2=A0 =C2=A0transport features on its own.=C2=A0 Therefore, these transpor= t features
=C2=A0 =C2=A0are not considered in this document, with the exception of nat= ive
=C2=A0 =C2=A0authentication capabilities of TCP and SCTP for which the secu= rity
=C2=A0 =C2=A0considerations in [RFC5925] and [RFC4895] apply.=C2=A0 The min= imum
=C2=A0 =C2=A0security requirements for a transport system are discussed in = a
=C2=A0 =C2=A0separate document [I-D.ietf-taps-transport-security].

confuses me, because I think at least two things are in play. First, I thin= k the point you're probably making is that the underlying transport pro= tocols remain unmodified, so the security considerations for each of those = protocols apply unchanged, and this document isn't doing anything to cr= eate new security considerations. So, modulo SECDIR and SEC AD comments, I = think that's all you need to say.

Second, you guys are the experts, but I think a reference to [I-D.ietf-taps= -transport-security] isn't actually needed for this document, because t= hat document surveys security protocols, rather than specifying minimum sec= urity requirements. That document might someday discuss the minimum securit= y requirements, in the way this document discusses the minimum set of trans= port services, but at least in=C2=A0 https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 tha= t document is much more comparable to RFCs 8095 and 8304 than to this docum= ent.

MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't= have section 5.
I believe section 5 in this document is an effort to do the same as minset = does, here;
are you maybe asking for this section of [I-D.ietf-taps-transport-security]= to use a
more authoritative tone?=C2=A0 Either way, as things stand now, the existen= ce of
[I-D.ietf-taps-transport-security] is used as a justification to not includ= e the
security related features of TCP and SCTP in the minimum set, and I think t= his
citation is necessary.

So, for what it&= #39;s worth, I wouldn't have ever noticed that Section 5 of=C2=A0=C2=A0= [I-D.ietf-taps-transport-security] provided the equivalent of this document= , based on the Abstract and Introduction, which both talk about surveys a l= ot more than minimum sets, but that's not your problem to solve (and I&= #39;m not providing AD comments on documents that the working group is stil= l working on, because you guys are more likely to get stuff right than I am= , so no action required from anyone else).=C2=A0

B= ut what is for you ...=C2=A0

At a minimum, I'd= suggest qualifying the reference to=C2=A0 [I-D.ietf-taps-transport-securit= y]=C2=A0 as "Section 5 of=C2=A0 [I-D.ietf-taps-transport-security]=C2= =A0", because I don't suppose that any other reviewer is more like= ly to figure this out than I am, but ...=C2=A0

Quo= ting from the Introduction in -02 of=C2=A0 I-D.ietf-taps-transport-security= , what that draft is covering is=C2=A0

=C2=A0= =C2=A0This document provides a survey of commonly used or notable network<= /div>
=C2=A0 =C2=A0security protocols, with a focus on how they interac= t and integrate
=C2=A0 =C2=A0with applications and transport prot= ocols.=C2=A0 Its goal is to supplement
=C2=A0 =C2=A0efforts to de= fine and catalog transport services [RFC8095] by
=C2=A0 =C2=A0des= cribing the interfaces required to add security protocols.=C2=A0 It
=C2=A0 =C2=A0examines Transport Layer Security (TLS), Datagram Transport= Layer
=C2=A0 =C2=A0Security (DTLS), Quick UDP Internet Connectio= ns with TLS (QUIC +
=C2=A0 =C2=A0TLS), MinimalT, CurveCP, tcpcryp= t, Internet Key Exchange with
=C2=A0 =C2=A0Encapsulating Security= Protocol (IKEv2 + ESP), SRTP (with DTLS), and
=C2=A0 =C2=A0WireG= uard.=C2=A0=C2=A0

I may be confused about th= is, but I'm not seeing an obvious pattern match between those protocols= and "security related features of TCP and SCTP in the minimum set&quo= t;. Is that document talking about what you hope it's talking about?=C2= =A0

Assuming so ... I'm probably struggling wi= th the idea that there is no minimal set of transport services that doesn&#= 39;t involve one of the protocols listed in I-D.ietf-taps-transport-securit= y or a near equivalent. That may really be the right thing for the working = group to say, but I wanted to make sure that's the point that's bei= ng made, because that's what I think you're saying, by including th= e reference to=C2=A0I-D.ietf-taps-transport-security in your security consi= derations.=C2=A0

If the last sentence read=C2=A0

=C2=A0 The minimum {delete "security"}=C2=A0 =C2=A0requirements for a {insert "secure"} secure trans= port system are discussed in a
=C2=A0 =C2=A0separate document [I-D.ietf-= taps-transport-security].

I'd agree with that statement, without anyone havin= g to explain anything to me!

But we'll be ready = for Last Call on your next version, either way.=C2=A0
=C2=A0
--

You folks know what you actually did, but I'm hoping that

=C2=A0 2.=C2=A0 Reduction: a shorter list of transport features is derived = from
=C2=A0 =C2=A0 =C2=A0 =C2=A0the categorization in the first step.=C2=A0 This= removes all transport
=C2=A0 =C2=A0 =C2=A0 =C2=A0features that do not require application-specifi= c knowledge or
=C2=A0 =C2=A0 =C2=A0 =C2=A0cannot be implemented with TCP or UDP.

was actually "cannot be implemented with TCP, SCTP, or UDP". Was = that an omission in this text, or do we need to chat?

MW: the point was that TCP and UDP can't work as a fall-back in case e.= g. SCTP isn't available. As stated at the beginning of the document, th= e minset can be implemented "one-sided" over TCP.=C2=A0 (and with= some limitations, also UDP). For example: it's fine (within "best= effort") to always send everything in order when an application allow= s out-of-order delivery - but there's simply no way to implement SCTP&#= 39;s out-of-band transmission of a number ("Indicate (and/or obtain up= on completion) an Adaptation Layer via an adaptation code point") with= TCP or UDP. If an application relies on that, TCP or UDP fall-backs become= impossible. We were asked to avoid writing using the term "fall-back&= quot;, for good reasons, but this particular sentence may have ended up bei= ng less clear as we simply replaced "fall-back" with "implem= ented with".

I changed the sentence as follows, is it better?

NEW:

This removes all transport features that do not require application-specifi= c knowledge or would result in semantically incorrect behavior if they were= implemented over TCP or UDP.

I'm n= ot entirely sure why, but this helps me a lot. Thanks for making the sugges= tion. It works for me.
=C2=A0

--

(Somewhere about here, I started thinking about "automated" - I d= idn't see a clear definition of this in the document. I think I underst= and what you mean at a hand-waving level, but you might consider adding a d= efinition earlier in the document, so that's clearer without relying on= context clues.

MW: "automated" doesn't appear in the draft - I'm sure yo= u mean "automatable".
It only appears in the appendix, where it's defined upon its first occu= rrence, in paragraph 5 of Appendix A.1, as follows: "The transport fea= tures of IETF transport protocols that do not require application-specific = knowledge and could therefore be transparently utilized by a transport syst= em are called "Automatable"."=C2=A0 - maybe you just missed = this? I believe it's in the most suitable place. I now made this senten= ce a bit clearer now, by changing it into: "The transport features of = IETF transport protocols that do not require application-specific knowledge= and could therefore be utilized by a transport system on its own without i= nvolving the application are called "Automatable"."

Good work. Here, you guessed what *I* meant.=C2= =A0

"Writing text is hard" - Spencer. Aa= ron has many examples of Spencer proving this, dating back to us being co-c= hairs in PILC in the late 1990s.=C2=A0

But your su= ggested text (answers the comment I was trying to make, and) works for me. = Thanks for that.
=C2=A0
--

And finally, at a high level, I don't understand why there are "Im= plementation over $Protocol" lines so often that name $Protocols that = weren't listed in "Protocols:" at the beginning of each descr= iption. I have several guesses about what that might mean, but I bet all of= them are wrong, so I have to ask.

MW: maybe that's related to your confusion about the omission of SCTP, = which I hope
I have addressed (as explained above). So that's answered by text that = appears just before we list the transport features, which now reads:
"The "minimal set" derived in this document is meant to be i= mplementable "one-sided" over TCP, and, with limitations, UDP. He= nce, for all transport features that are categorized as "functional&qu= ot; or "optimizing", and for which no matching TCP and/or UDP pri= mitive exists in "pass 2" of [RFC8303], a brief discussion on how= to implement
them over TCP and/or UDP is included."

=
Again, that's fixing my confusion above. Thanks for that.=C2=A0
--0000000000005adf890573de371e-- From nobody Mon Aug 20 07:11:32 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 6BB74130E39; Mon, 20 Aug 2018 07:11:30 -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 NVFYc6ReI5f5; Mon, 20 Aug 2018 07:11:27 -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 4961F130DDB; Mon, 20 Aug 2018 07:11:27 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1frktw-0006Aj-7h; Mon, 20 Aug 2018 16:11:24 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1frktt-0001Xo-K7; Mon, 20 Aug 2018 16:11:24 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Mon, 20 Aug 2018 16:11:20 +0200 Cc: draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> To: Spencer Dawkins X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; 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: 287386EE88EE04F33BC2B8FBFEFF17ABBB58A4FE Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 14:11:30 -0000 Hi, Thanks again ! > On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF = wrote: >=20 > Hi, Michael, >=20 > On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl = wrote: > Hi Spencer! >=20 > Thank you so much for your detailed work and all these comments! > I'm commenting in line below, and marking my comments with "MW:". > I'm terminating my responses with a "--". >=20 > I'm attaching an update which incorporates the changes described in = this email, but I'm delaying its submission until it's clear that this = conversation has converged. >=20 > We're pretty darned converged. I have a couple of follow-ups below, = but I deleted everything that we're already good on (and thank you for = those, in advance). >=20 > My only significant question is on Section 7.=20 Great - it seems this is also the only one that calls for a change of = the version that I now have. So, I'm removing the rest and just keeping = this: > -- >=20 > This text in 7. Security Considerations >=20 > Authentication, confidentiality protection, and integrity = protection > are identified as transport features by [RFC8095]. As currently > deployed in the Internet, these features are generally provided by = a > protocol or layer on top of the transport protocol; no current = full- > featured standards-track transport protocol provides all of these > transport features on its own. Therefore, these transport features > are not considered in this document, with the exception of native > authentication capabilities of TCP and SCTP for which the security > considerations in [RFC5925] and [RFC4895] apply. The minimum > security requirements for a transport system are discussed in a > separate document [I-D.ietf-taps-transport-security]. >=20 > confuses me, because I think at least two things are in play. First, I = think the point you're probably making is that the underlying transport = protocols remain unmodified, so the security considerations for each of = those protocols apply unchanged, and this document isn't doing anything = to create new security considerations. So, modulo SECDIR and SEC AD = comments, I think that's all you need to say.=20 >=20 > Second, you guys are the experts, but I think a reference to = [I-D.ietf-taps-transport-security] isn't actually needed for this = document, because that document surveys security protocols, rather than = specifying minimum security requirements. That document might someday = discuss the minimum security requirements, in the way this document = discusses the minimum set of transport services, but at least in = https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that = document is much more comparable to RFCs 8095 and 8304 than to this = document.=20 >=20 > MW: I would agree about [I-D.ietf-taps-transport-security] if it = didn't have section 5. > I believe section 5 in this document is an effort to do the same as = minset does, here; > are you maybe asking for this section of = [I-D.ietf-taps-transport-security] to use a > more authoritative tone? Either way, as things stand now, the = existence of > [I-D.ietf-taps-transport-security] is used as a justification to not = include the > security related features of TCP and SCTP in the minimum set, and I = think this > citation is necessary. >=20 > So, for what it's worth, I wouldn't have ever noticed that Section 5 = of [I-D.ietf-taps-transport-security] provided the equivalent of this = document, based on the Abstract and Introduction, which both talk about = surveys a lot more than minimum sets, but that's not your problem to = solve (and I'm not providing AD comments on documents that the working = group is still working on, because you guys are more likely to get stuff = right than I am, so no action required from anyone else).=20 >=20 > But what is for you ...=20 >=20 > At a minimum, I'd suggest qualifying the reference to = [I-D.ietf-taps-transport-security] as "Section 5 of = [I-D.ietf-taps-transport-security] ", because I don't suppose that any = other reviewer is more likely to figure this out than I am, but ...=20 >=20 > Quoting from the Introduction in -02 of = I-D.ietf-taps-transport-security, what that draft is covering is=20 >=20 > 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. =20 >=20 > I may be confused about this, but I'm not seeing an obvious pattern = match between those protocols and "security related features of TCP and = SCTP in the minimum set". Is that document talking about what you hope = it's talking about?=20 >=20 > Assuming so ... I'm probably struggling with the idea that there is no = minimal set of transport services that doesn't involve one of the = protocols listed in I-D.ietf-taps-transport-security or a near = equivalent. That may really be the right thing for the working group to = say, but I wanted to make sure that's the point that's being made, = because that's what I think you're saying, by including the reference to = I-D.ietf-taps-transport-security in your security considerations.=20 >=20 > If the last sentence read=20 >=20 > The minimum {delete "security"} > requirements for a {insert "secure"} secure transport system are = discussed in a > separate document [I-D.ietf-taps-transport-security]. >=20 > I'd agree with that statement, without anyone having to explain = anything to me! Can I just make this sentence replacement and be done with it? I mean, = it IS a very nice and clean solution, IMO... Cheers, Michael From nobody Mon Aug 20 08:34:27 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 E5773130E46; Mon, 20 Aug 2018 08:34:24 -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 C2gqemczQk5T; Mon, 20 Aug 2018 08:34:21 -0700 (PDT) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 6C01F130F52; Mon, 20 Aug 2018 08:34:21 -0700 (PDT) Received: by mail-yw1-xc2a.google.com with SMTP id q129-v6so6960154ywg.8; Mon, 20 Aug 2018 08:34:21 -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=dlqJhbaSuBRBUHTJ8VC+D3wCPrMeUbkTxfzndko37vo=; b=b+7uE4F+kJGSrvfwN14bQFF2DH3JSUPeHgTixvEiFmOw3M+ZVvSsPG+POh+khNyKRn 5iTnrMOd5dR2zCiM8w9gxxirxG+lseHH+8vLVhexp1tGYCNfYxx0gjp3NT6pyZ+lw0J6 +FiUs0ZE5BlU948N5vB24tGPf0iKQZbkukX0Jwu+VXZ9JZiXOZWUyGh1ozwcv40/wuVv lcBOrqmXMjQ4EmQl7oiqvnbGbhuG77Ud8ysKKGVTjmWLEkWk/bjpEJqQikVFAzZMRXoc cU44mdR6qCM+L9P94Ubbru73UkyQbNx/6L+EIDSMt07reRcQYMCh63fp3Do2LmD4SVrT EexQ== 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=dlqJhbaSuBRBUHTJ8VC+D3wCPrMeUbkTxfzndko37vo=; b=Do3lVkP6CN4rykG7qLmJ/xsMMp5/Ubj4mVr0u5UCh/SbIrJGVg/zzL5gONTyOOpiMc Ls1PWXsel0Vg9u9iyCeZiQTt2eok/epmltvmc9MXqOIXhSGDOuPpLfMdjTwAhLCHwNls weLvp4/bu829LZwfW2DQuZ1gj9bhWTcC48XJ1XzMKL6QaVv/ALthj8d1DjEmzYU5//eR u4mu4rO9oz1w7bcwbXLQ/cyP2zLk3YATSWhDgyU8aB/Wl29Y9T/rRBXp/oL5xaXqYydt cUMOE7MdcGn67/2lyC+FnxDi20I7Gm3iwAKfB1k7s03oTodQQNQUvyXEK68qcwTnZWeX 4vXg== X-Gm-Message-State: AOUpUlHlGX68NEtwsm3to14hs3ThIxcXwZ7iOXhdR06KjbF+UTrEXDpp P4xaEX+Bb7RRUHmXDm7F8RXjza6aMPc+sedIqzY= X-Google-Smtp-Source: AA+uWPxGEuUAZqz9XxHhxAnMMA2quRRVi6FeMWS49oma2Rpg4fEbuuqc5jEWobqEuKidjcq7gEFU9DlaqvmSv9ZdaGc= X-Received: by 2002:a81:5a8a:: with SMTP id o132-v6mr24654662ywb.411.1534779260491; Mon, 20 Aug 2018 08:34:20 -0700 (PDT) MIME-Version: 1.0 References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> In-Reply-To: <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> From: Spencer Dawkins at IETF Date: Mon, 20 Aug 2018 10:34:08 -0500 Message-ID: To: michawe@ifi.uio.no Cc: draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, theresa@inet.tu-berlin.de, taps@ietf.org Content-Type: multipart/alternative; boundary="000000000000a15cb60573dfa4a3" Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 20 Aug 2018 15:34:25 -0000 --000000000000a15cb60573dfa4a3 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Mon, Aug 20, 2018 at 9:11 AM Michael Welzl wrote: > Hi, > > Thanks again ! > > > > On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, Michael, > > > > On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl > wrote: > > Hi Spencer! > > > > Thank you so much for your detailed work and all these comments! > > I'm commenting in line below, and marking my comments with "MW:". > > I'm terminating my responses with a "--". > > > > I'm attaching an update which incorporates the changes described in this > email, but I'm delaying its submission until it's clear that this > conversation has converged. > > > > We're pretty darned converged. I have a couple of follow-ups below, but > I deleted everything that we're already good on (and thank you for those, > in advance). > > > > My only significant question is on Section 7. > > Great - it seems this is also the only one that calls for a change of the > version that I now have. So, I'm removing the rest and just keeping this: > > > > -- > > > > This text in 7. Security Considerations > > > > Authentication, confidentiality protection, and integrity protection > > are identified as transport features by [RFC8095]. As currently > > deployed in the Internet, these features are generally provided by a > > protocol or layer on top of the transport protocol; no current full- > > featured standards-track transport protocol provides all of these > > transport features on its own. Therefore, these transport features > > are not considered in this document, with the exception of native > > authentication capabilities of TCP and SCTP for which the security > > considerations in [RFC5925] and [RFC4895] apply. The minimum > > security requirements for a transport system are discussed in a > > separate document [I-D.ietf-taps-transport-security]. > > > > confuses me, because I think at least two things are in play. First, I > think the point you're probably making is that the underlying transport > protocols remain unmodified, so the security considerations for each of > those protocols apply unchanged, and this document isn't doing anything to > create new security considerations. So, modulo SECDIR and SEC AD comments, > I think that's all you need to say. > > > > Second, you guys are the experts, but I think a reference to > [I-D.ietf-taps-transport-security] isn't actually needed for this document, > because that document surveys security protocols, rather than specifying > minimum security requirements. That document might someday discuss the > minimum security requirements, in the way this document discusses the > minimum set of transport services, but at least in > https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that > document is much more comparable to RFCs 8095 and 8304 than to this > document. > > > > MW: I would agree about [I-D.ietf-taps-transport-security] if it didn't > have section 5. > > I believe section 5 in this document is an effort to do the same as > minset does, here; > > are you maybe asking for this section of > [I-D.ietf-taps-transport-security] to use a > > more authoritative tone? Either way, as things stand now, the existence > of > > [I-D.ietf-taps-transport-security] is used as a justification to not > include the > > security related features of TCP and SCTP in the minimum set, and I > think this > > citation is necessary. > > > > So, for what it's worth, I wouldn't have ever noticed that Section 5 of > [I-D.ietf-taps-transport-security] provided the equivalent of this > document, based on the Abstract and Introduction, which both talk about > surveys a lot more than minimum sets, but that's not your problem to solve > (and I'm not providing AD comments on documents that the working group is > still working on, because you guys are more likely to get stuff right than > I am, so no action required from anyone else). > > > > But what is for you ... > > > > At a minimum, I'd suggest qualifying the reference to > [I-D.ietf-taps-transport-security] as "Section 5 of > [I-D.ietf-taps-transport-security] ", because I don't suppose that any > other reviewer is more likely to figure this out than I am, but ... > > > > Quoting from the Introduction in -02 of > I-D.ietf-taps-transport-security, what that draft is covering is > > > > 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. > > > > I may be confused about this, but I'm not seeing an obvious pattern > match between those protocols and "security related features of TCP and > SCTP in the minimum set". Is that document talking about what you hope it's > talking about? > > > > Assuming so ... I'm probably struggling with the idea that there is no > minimal set of transport services that doesn't involve one of the protocols > listed in I-D.ietf-taps-transport-security or a near equivalent. That may > really be the right thing for the working group to say, but I wanted to > make sure that's the point that's being made, because that's what I think > you're saying, by including the reference to > I-D.ietf-taps-transport-security in your security considerations. > > > > If the last sentence read > > > > The minimum {delete "security"} > > requirements for a {insert "secure"} secure transport system are > discussed in a > > separate document [I-D.ietf-taps-transport-security]. > > > > I'd agree with that statement, without anyone having to explain anything > to me! > > Can I just make this sentence replacement and be done with it? I mean, it > IS a very nice and clean solution, IMO... > So, here's what I'm thinking ... I'm not sure if you saw my suggestion about qualifying the reference to [I-D.ietf-taps-transport-security] as "Section 5 of [I-D.ietf-taps-transport-security]", but assuming that we're good on that one ... Tl;dr = Spencer wants to make sure that his suggested text isn't overriding what the working group is thinking, but since the working group has been copied on this e-mail thread, it's probably fine to submit an updated draft and start Last Call. For anyone curious ... What I was reading into the original text was roughly minimal transport service set = this document + Section 5 of [I-D.ietf-taps-transport-security] The text I offered, is roughly minimal transport service set = this document minimal secure transport service set = this document + Section 5 of [I-D.ietf-taps-transport-security] We explicitly chartered TAPS for transport services in 2014, and didn't add responsibility for transport security until February of this year. It seems to me that publishing a minimal transport service set has value now, and publishing a minimal transport service set has additional value later. If that's the intention, my suggested text would work. If the intention was to say that the minimal transport service set requires transport security, the original text was correct and Spencer just missed a turn someplace, but a reasonable review question would be "if the minimal transport service set requires transport security, why publish the insecure part now?" Either answer is OK with me, but what's not OK is for me as AD, is tell the working group "I'm sure you meant THIS", in a way that doesn't invite "Spencer, we meant exactly THIS, and your comment explains why we don't have ADs write all the documents" :-) And thanks for your quick responses. That's always helpful. Spencer > Cheers, > Michael > > --000000000000a15cb60573dfa4a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

On Mon, Aug 20, 2018 at 9:11 AM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,

Thanks again !


> On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF <spencerdawkins.ietf@gmai= l.com> wrote:
>
> Hi, Michael,
>
> On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl <michawe@ifi.uio.no> wrote:
> Hi Spencer!
>
> Thank you so much for your detailed work and all these comments!
> I'm commenting in line below, and marking my comments with "M= W:".
> I'm terminating my responses with a "--".
>
> I'm attaching an update which incorporates the changes described i= n this email, but I'm delaying its submission until it's clear that= this conversation has converged.
>
> We're pretty darned converged. I have a couple of follow-ups below= , but I deleted everything that we're already good on (and thank you fo= r those, in advance).
>
> My only significant question is on Section 7.

Great - it seems this is also the only one that calls for a change of the v= ersion that I now have. So, I'm removing the rest and just keeping this= :


> --
>
> This text in 7.=C2=A0 Security Considerations
>
>=C2=A0 =C2=A0 Authentication, confidentiality protection, and integrity= protection
>=C2=A0 =C2=A0 are identified as transport features by [RFC8095].=C2=A0 = As currently
>=C2=A0 =C2=A0 deployed in the Internet, these features are generally pr= ovided by a
>=C2=A0 =C2=A0 protocol or layer on top of the transport protocol; no cu= rrent full-
>=C2=A0 =C2=A0 featured standards-track transport protocol provides all = of these
>=C2=A0 =C2=A0 transport features on its own.=C2=A0 Therefore, these tra= nsport features
>=C2=A0 =C2=A0 are not considered in this document, with the exception o= f native
>=C2=A0 =C2=A0 authentication capabilities of TCP and SCTP for which the= security
>=C2=A0 =C2=A0 considerations in [RFC5925] and [RFC4895] apply.=C2=A0 Th= e minimum
>=C2=A0 =C2=A0 security requirements for a transport system are discusse= d in a
>=C2=A0 =C2=A0 separate document [I-D.ietf-taps-transport-security].
>
> confuses me, because I think at least two things are in play. First, I= think the point you're probably making is that the underlying transpor= t protocols remain unmodified, so the security considerations for each of t= hose protocols apply unchanged, and this document isn't doing anything = to create new security considerations. So, modulo SECDIR and SEC AD comment= s, I think that's all you need to say.
>
> Second, you guys are the experts, but I think a reference to [I-D.ietf= -taps-transport-security] isn't actually needed for this document, beca= use that document surveys security protocols, rather than specifying minimu= m security requirements. That document might someday discuss the minimum se= curity requirements, in the way this document discusses the minimum set of = transport services, but at least in=C2=A0 https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that document is much more comparable to RFCs 8095 and 8304 than to this = document.
>
> MW: I would agree about [I-D.ietf-taps-transport-security] if it didn&= #39;t have section 5.
> I believe section 5 in this document is an effort to do the same as mi= nset does, here;
> are you maybe asking for this section of [I-D.ietf-taps-transport-secu= rity] to use a
> more authoritative tone?=C2=A0 Either way, as things stand now, the ex= istence of
> [I-D.ietf-taps-transport-security] is used as a justification to not i= nclude the
> security related features of TCP and SCTP in the minimum set, and I th= ink this
> citation is necessary.
>
> So, for what it's worth, I wouldn't have ever noticed that Sec= tion 5 of=C2=A0 [I-D.ietf-taps-transport-security] provided the equivalent = of this document, based on the Abstract and Introduction, which both talk a= bout surveys a lot more than minimum sets, but that's not your problem = to solve (and I'm not providing AD comments on documents that the worki= ng group is still working on, because you guys are more likely to get stuff= right than I am, so no action required from anyone else).
>
> But what is for you ...
>
> At a minimum, I'd suggest qualifying the reference to=C2=A0 [I-D.i= etf-taps-transport-security]=C2=A0 as "Section 5 of=C2=A0 [I-D.ietf-ta= ps-transport-security] ", because I don't suppose that any other r= eviewer is more likely to figure this out than I am, but ...
>
> Quoting from the Introduction in -02 of=C2=A0 I-D.ietf-taps-transport-= security, what that draft is covering is
>
>=C2=A0 =C2=A0 This document provides a survey of commonly used or notab= le network
>=C2=A0 =C2=A0 security protocols, with a focus on how they interact and= integrate
>=C2=A0 =C2=A0 with applications and transport protocols.=C2=A0 Its goal= is to supplement
>=C2=A0 =C2=A0 efforts to define and catalog transport services [RFC8095= ] by
>=C2=A0 =C2=A0 describing the interfaces required to add security protoc= ols.=C2=A0 It
>=C2=A0 =C2=A0 examines Transport Layer Security (TLS), Datagram Transpo= rt Layer
>=C2=A0 =C2=A0 Security (DTLS), Quick UDP Internet Connections with TLS = (QUIC +
>=C2=A0 =C2=A0 TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange = with
>=C2=A0 =C2=A0 Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with= DTLS), and
>=C2=A0 =C2=A0 WireGuard.=C2=A0
>
> I may be confused about this, but I'm not seeing an obvious patter= n match between those protocols and "security related features of TCP = and SCTP in the minimum set". Is that document talking about what you = hope it's talking about?
>
> Assuming so ... I'm probably struggling with the idea that there i= s no minimal set of transport services that doesn't involve one of the = protocols listed in I-D.ietf-taps-transport-security or a near equivalent. = That may really be the right thing for the working group to say, but I want= ed to make sure that's the point that's being made, because that= 9;s what I think you're saying, by including the reference to I-D.ietf-= taps-transport-security in your security considerations.
>
> If the last sentence read
>
>=C2=A0 =C2=A0The minimum {delete "security"}
>=C2=A0 =C2=A0 requirements for a {insert "secure"} secure tra= nsport system are discussed in a
>=C2=A0 =C2=A0 separate document [I-D.ietf-taps-transport-security].
>
> I'd agree with that statement, without anyone having to explain an= ything to me!

Can I just make this sentence replacement and be done with it?=C2=A0 I mean= , it IS a very nice and clean solution, IMO...

<= div>minimal=C2=A0transport=C2=A0service set =3D this document=C2=A0
minimal=C2=A0secure transport service set =3D this document + Section 5 = of=C2=A0 [I-D.ietf-taps-transport-security]=C2=A0

<= div>We explicitly chartered TAPS for transport services in 2014, and didn&#= 39;t add responsibility for transport security until February of this year.= It seems to me that publishing a minimal=C2=A0transport service set has va= lue now, and publishing a minimal transport service set has additional valu= e later.=C2=A0





Cheers,
Michael

--000000000000a15cb60573dfa4a3-- From nobody Mon Aug 20 23:48:39 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B67F130E04; Mon, 20 Aug 2018 23:48:37 -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 mkdnd5CIgtBz; Mon, 20 Aug 2018 23:48: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 B8CD0126CC7; Mon, 20 Aug 2018 23:48:33 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fs0St-0001vC-9d; Tue, 21 Aug 2018 08:48:31 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fs0Sq-000FgE-RK; Tue, 21 Aug 2018 08:48:30 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Tue, 21 Aug 2018 08:48:26 +0200 Cc: draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, theresa@inet.tu-berlin.de, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> To: Spencer Dawkins X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; 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: 85442E24114CD68941C1728B9821E58CA5A6669B Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 06:48:38 -0000 Hi, In line below: > On 20 Aug 2018, at 17:34, Spencer Dawkins at IETF = wrote: >=20 > Hi, Michael, >=20 > On Mon, Aug 20, 2018 at 9:11 AM Michael Welzl = wrote: > Hi, >=20 > Thanks again ! >=20 >=20 > > On 20 Aug 2018, at 15:52, Spencer Dawkins at IETF = wrote: > >=20 > > Hi, Michael, > >=20 > > On Mon, Aug 20, 2018 at 3:57 AM Michael Welzl = wrote: > > Hi Spencer! > >=20 > > Thank you so much for your detailed work and all these comments! > > I'm commenting in line below, and marking my comments with "MW:". > > I'm terminating my responses with a "--". > >=20 > > I'm attaching an update which incorporates the changes described in = this email, but I'm delaying its submission until it's clear that this = conversation has converged. > >=20 > > We're pretty darned converged. I have a couple of follow-ups below, = but I deleted everything that we're already good on (and thank you for = those, in advance). > >=20 > > My only significant question is on Section 7.=20 >=20 > Great - it seems this is also the only one that calls for a change of = the version that I now have. So, I'm removing the rest and just keeping = this: >=20 >=20 > > -- > >=20 > > This text in 7. Security Considerations > >=20 > > Authentication, confidentiality protection, and integrity = protection > > are identified as transport features by [RFC8095]. As currently > > deployed in the Internet, these features are generally provided = by a > > protocol or layer on top of the transport protocol; no current = full- > > featured standards-track transport protocol provides all of these > > transport features on its own. Therefore, these transport = features > > are not considered in this document, with the exception of native > > authentication capabilities of TCP and SCTP for which the = security > > considerations in [RFC5925] and [RFC4895] apply. The minimum > > security requirements for a transport system are discussed in a > > separate document [I-D.ietf-taps-transport-security]. > >=20 > > confuses me, because I think at least two things are in play. First, = I think the point you're probably making is that the underlying = transport protocols remain unmodified, so the security considerations = for each of those protocols apply unchanged, and this document isn't = doing anything to create new security considerations. So, modulo SECDIR = and SEC AD comments, I think that's all you need to say.=20 > >=20 > > Second, you guys are the experts, but I think a reference to = [I-D.ietf-taps-transport-security] isn't actually needed for this = document, because that document surveys security protocols, rather than = specifying minimum security requirements. That document might someday = discuss the minimum security requirements, in the way this document = discusses the minimum set of transport services, but at least in = https://tools.ietf.org/html/draft-ietf-taps-transport-security-02 that = document is much more comparable to RFCs 8095 and 8304 than to this = document.=20 > >=20 > > MW: I would agree about [I-D.ietf-taps-transport-security] if it = didn't have section 5. > > I believe section 5 in this document is an effort to do the same as = minset does, here; > > are you maybe asking for this section of = [I-D.ietf-taps-transport-security] to use a > > more authoritative tone? Either way, as things stand now, the = existence of > > [I-D.ietf-taps-transport-security] is used as a justification to not = include the > > security related features of TCP and SCTP in the minimum set, and I = think this > > citation is necessary. > >=20 > > So, for what it's worth, I wouldn't have ever noticed that Section 5 = of [I-D.ietf-taps-transport-security] provided the equivalent of this = document, based on the Abstract and Introduction, which both talk about = surveys a lot more than minimum sets, but that's not your problem to = solve (and I'm not providing AD comments on documents that the working = group is still working on, because you guys are more likely to get stuff = right than I am, so no action required from anyone else).=20 > >=20 > > But what is for you ...=20 > >=20 > > At a minimum, I'd suggest qualifying the reference to = [I-D.ietf-taps-transport-security] as "Section 5 of = [I-D.ietf-taps-transport-security] ", because I don't suppose that any = other reviewer is more likely to figure this out than I am, but ...=20 > >=20 > > Quoting from the Introduction in -02 of = I-D.ietf-taps-transport-security, what that draft is covering is=20 > >=20 > > 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. =20 > >=20 > > I may be confused about this, but I'm not seeing an obvious pattern = match between those protocols and "security related features of TCP and = SCTP in the minimum set". Is that document talking about what you hope = it's talking about?=20 > >=20 > > Assuming so ... I'm probably struggling with the idea that there is = no minimal set of transport services that doesn't involve one of the = protocols listed in I-D.ietf-taps-transport-security or a near = equivalent. That may really be the right thing for the working group to = say, but I wanted to make sure that's the point that's being made, = because that's what I think you're saying, by including the reference to = I-D.ietf-taps-transport-security in your security considerations.=20 > >=20 > > If the last sentence read=20 > >=20 > > The minimum {delete "security"} > > requirements for a {insert "secure"} secure transport system are = discussed in a > > separate document [I-D.ietf-taps-transport-security]. > >=20 > > I'd agree with that statement, without anyone having to explain = anything to me! >=20 > Can I just make this sentence replacement and be done with it? I = mean, it IS a very nice and clean solution, IMO... >=20 > So, here's what I'm thinking ...=20 >=20 > I'm not sure if you saw my suggestion about qualifying the reference = to [I-D.ietf-taps-transport-security] as "Section 5 of = [I-D.ietf-taps-transport-security]", but assuming that we're good on = that one ...=20 I saw it and agree. I thought that it's not necessary for the specific = sentence that you ended up proposing, but now I agree that even in this = sentence it's better. I'll update it to include "Section 5 of" just = ahead of this reference. > Tl;dr =3D Spencer wants to make sure that his suggested text isn't = overriding what the working group is thinking, but since the working = group has been copied on this e-mail thread, it's probably fine to = submit an updated draft and start Last Call.=20 I'll submit the update with the small correction above after this email. > For anyone curious ...=20 >=20 > What I was reading into the original text was roughly=20 >=20 > minimal transport service set =3D this document + Section 5 of = [I-D.ietf-taps-transport-security]=20 >=20 > The text I offered, is roughly=20 >=20 > minimal transport service set =3D this document=20 > minimal secure transport service set =3D this document + Section 5 of = [I-D.ietf-taps-transport-security]=20 I, for one, understood that and think that this is a fine solution. Cheers, Michael > We explicitly chartered TAPS for transport services in 2014, and = didn't add responsibility for transport security until February of this = year. It seems to me that publishing a minimal transport service set has = value now, and publishing a minimal transport service set has additional = value later.=20 >=20 > If that's the intention, my suggested text would work.=20 >=20 > If the intention was to say that the minimal transport service set = requires transport security, the original text was correct and Spencer = just missed a turn someplace, but a reasonable review question would be = "if the minimal transport service set requires transport security, why = publish the insecure part now?" >=20 > Either answer is OK with me, but what's not OK is for me as AD, is = tell the working group "I'm sure you meant THIS", in a way that doesn't = invite "Spencer, we meant exactly THIS, and your comment explains why we = don't have ADs write all the documents" :-) =20 >=20 > And thanks for your quick responses. That's always helpful. >=20 > Spencer > =20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Aug 20 23:56:02 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 34D67130E20; Mon, 20 Aug 2018 23:55:55 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <153483455517.22992.9099703673158303651@ietfa.amsl.com> Date: Mon, 20 Aug 2018 23:55:55 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-minset-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 06:55:56 -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 Minimal Set of Transport Services for End Systems Authors : Michael Welzl Stein Gjessing Filename : draft-ietf-taps-minset-05.txt Pages : 48 Date : 2018-08-20 Abstract: This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-minset-05 https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05 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 Tue Aug 21 05:35:47 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 7EEAA130F06; Tue, 21 Aug 2018 05:35:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-taps-minset@ietf.org, Theresa Enghardt , theresa@inet.tu-berlin.de, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153485492647.9380.6019483670820650622.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2018 05:35:26 -0700 Archived-At: Subject: [Taps] Last Call: (A Minimal Set of Transport Services for End Systems) to Informational RFC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2018 12:35:40 -0000 The IESG has received a request from the Transport Services WG (taps) to consider the following document: - 'A Minimal Set of Transport Services for End Systems' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-09-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Aug 21 11:44:09 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 E8DBB130E9C; Tue, 21 Aug 2018 11:44:06 -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 bKNUzxjEWDra; Tue, 21 Aug 2018 11:44:05 -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 21E59130E9F; Tue, 21 Aug 2018 11:44:05 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id r13-v6so2726504qtr.11; Tue, 21 Aug 2018 11:44:05 -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=jv8GKVF5a4Xr36HyaaWSG9LbMD1xFNyqilVkF0H1dQA=; b=ChHI2gQ7CgkihfGwBO5AIDWURKWyvu3tsJDmU8oluK1NtT5ZCi/Xxup45qnV4FDBrd Bcc1dHyRMLN/2sDJaoHR0ik6ZEp90Ngxo2JSwL3SBF1ju68e9andvAQSKP+HksR5ZZ9D 2vQAJz0dF7MiQyv/sEicJu7AhzKXSCdWADjP4r887VLBCeilfdKznIowcdgmB3qiWd4G kTz0rzZUldep8A2EXsY25q8GTJzfq0ovvbL3Zar8Vvsl2s0YJ51yko9eSOUWJ2M6dHNI SvN62acgqNSSIiqWW/AxWTz/cLB8T5Q0ns51S0W29Lotl8YT/sniGZnUP29zBG5UwpBe TfKg== 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=jv8GKVF5a4Xr36HyaaWSG9LbMD1xFNyqilVkF0H1dQA=; b=VrkIOJLzsGubHBIZnYjmy5BMSWIXVBuwB96dsIokFjP4mPwrkBSjKCgmdwBTcjPGGq PozkWSbbK7hPpKi6Krtwbhtj4BH8pXtRtj4fa/Es3vXjsae9PUengCpiRU9Uw7V17vmr d+zsxoNn7oGJ1Vm0UNsb/pb5WB6d7Ju39G0pUlI0HEuMPoiU7n27cI9psHV7b/sVqayK FVLbrqYXy+FW3zfP7p7nvPJW6/6hDKV3wp0O1bR1PWc2gwL/ip8gfTHTbXOF6fpMHZci XC8uALpixk8oY+olKVyepiXXSOlbUFq/0z8xElHN0/SdEZL3bTxq0zMiLPkPEmbnxmzt NIWA== X-Gm-Message-State: AOUpUlEI7WcLvJnvvE+vbOh/Xan0AY5LusOPo60cwDASW3ShVMwC79ro 2lcwewZg5IMrlFtMoHUotFY= X-Google-Smtp-Source: AA+uWPxuC6IAXs8EY3kSME2DTZfs+rmci2zvuyXT2TO9D0nAi0bMvhIGDkAHuAnvTYZyZleYFX1ygQ== X-Received: by 2002:ac8:24d0:: with SMTP id t16-v6mr51944899qtt.116.1534877044087; Tue, 21 Aug 2018 11:44:04 -0700 (PDT) Received: from [172.19.34.231] ([2001:4878:a000:3000:172:6cdd:f9c0:381e]) by smtp.gmail.com with ESMTPSA id y27-v6sm3991795qtj.58.2018.08.21.11.44.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 11:44:03 -0700 (PDT) From: "Aaron Falk" To: "Michael Welzl" Cc: "Spencer Dawkins" , draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, theresa@inet.tu-berlin.de, taps@ietf.org Date: Tue, 21 Aug 2018 14:44:02 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: <0986B9AC-13F4-4B9B-AADD-1940382DC77D@gmail.com> In-Reply-To: References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B421CD62-52D3-4578-8230-2661BFA4BD08_=" Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 18:44:07 -0000 --=_MailMate_B421CD62-52D3-4578-8230-2661BFA4BD08_= Content-Type: text/plain; format=flowed; markup=markdown Glad to see rapid convergence on these comments. My turn for a nit: On 21 Aug 2018, at 2:48, Michael Welzl wrote: > I'm not sure if you saw my suggestion about qualifying the reference > to [I-D.ietf-taps-transport-security] as "Section 5 of > [I-D.ietf-taps-transport-security]", but assuming that we're good on > that one ... > > > I saw it and agree. I thought that it's not necessary for the specific > sentence that you ended up proposing, but now I agree that even in > this sentence it's better. I'll update it to include "Section 5 of" > just ahead of this reference. The likelihood of an ID having it's sections renumbered is high enough that I don't think we should embed the section number in an RFC. I'd suggest using the section name as well in case one or both changes the reader is likely to make the connection: "Section 5 on Security Features and Transport Dependencies of ..." --aaron --=_MailMate_B421CD62-52D3-4578-8230-2661BFA4BD08_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Glad to see rapid convergence on these comments. My turn = for a nit:

On 21 Aug 2018, at 2:48, Michael Welzl wrote:

I'm not sure if you saw my suggesti= on about qualifying the reference to [I-D.ietf-taps-transport-security] = as "Section 5 of [I-D.ietf-taps-transport-security]", but assuming that= we're good on that one ...


I saw it and agree. I thought that it's not necessary for the specific se= ntence that you ended up proposing, but now I agree that even in this sen= tence it's better. I'll update it to include "Section 5 of" just ahead of= this reference.

The likelihood of an ID having it's sections= renumbered is high enough that I don't think we should embed the section= number in an RFC. I'd suggest using the section name as well in case on= e or both changes the reader is likely to make the connection: "Section = 5 on Security Features and Transport Dependencies of ..."

--aaron

--=_MailMate_B421CD62-52D3-4578-8230-2661BFA4BD08_=-- From nobody Tue Aug 21 13:28: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 E8218130ECC; Tue, 21 Aug 2018 13:27:59 -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 QTe2OhYnejXd; Tue, 21 Aug 2018 13:27:57 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::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 6EAA6130E52; Tue, 21 Aug 2018 13:27:57 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id l16-v6so6472391ybk.11; Tue, 21 Aug 2018 13:27:57 -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=h4mZoTf3/r1nFYkgRvAni7rRCT4+TUeAbAH4NTXEyYk=; b=Goy6Pv2FS7t2mdcUqla3LDFHVApR/nIbNaCpj/ifF3xnlmog+a00xh7imUEaNhyspu fJPPr8vVatxC/tOFXfo7CS0mWhMGeQhw5CYwf1jhyd0kWQ1ya51itnFGwB2TtqgC3dgw qRh9kWCU+uhVNsNob86ZvMuEBhVPu1IHUZ3SwZwXU4hHLOSCMUHe6PVERNH3X4uwKaWX QszAY6criBEQ3rir5LtrabEcAUrtin8lsrhS+eSJrScbnv3yzg4/5xu97uCX8xvhQK70 tnaCxQp8qxjXCeqEA6YT4NLGgpJvcA0dbUdyoG3lMagWbetIYUL7et9ji2sSGghQfW/1 kQxQ== 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=h4mZoTf3/r1nFYkgRvAni7rRCT4+TUeAbAH4NTXEyYk=; b=qoWTTvX9rTLSZKn41mGUWfyuZbXgPF8iZZmQKCTp4Nqehx4l7dqc0BZt++rzz8Sn2/ RsRbZPQ7mS8vfiouyg0dpNHpQ81daWMfv7rWgrs9gBa5SCVHKA365yQHGX6X9QGDgiXx CuRyVZd81afxhdT5/YqI+fXKymwLwfKioKnHJUZy+my7S4MAsg+JLdt0xxGSR0AhFYkP xdE2+a8vqE0BpoeW5/fZC7DY2aMlJewS0q0onCzZvfHpo+WtqFcSk8TrUHWPOtosTsEx pzcXCorFNdaExjB1dNufiYSu2FsQrdeh4T8ErOcogAkVA70hKys5FgHWkvQyUx7MCGor Wziw== X-Gm-Message-State: AOUpUlEKc/Ml3P+0m8MSF6z0rGbipkwmlwQ1uU/t6Tqpt3/i9FZNVYBy gtbEQZskB+t56x74OaUH1Q+df7bxw7a/gViM6WWwG0sS X-Google-Smtp-Source: AA+uWPyIUkpmGaDDYRb8kNjlfV4rAvPqck8SIEVvEK4C1fiwzZnv+rxj501MwGi5Ct/sOl3rZbPwtKdqAERTLQD9wAs= X-Received: by 2002:a25:c343:: with SMTP id t64-v6mr22039134ybf.399.1534883276429; Tue, 21 Aug 2018 13:27:56 -0700 (PDT) MIME-Version: 1.0 References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> <0986B9AC-13F4-4B9B-AADD-1940382DC77D@gmail.com> In-Reply-To: <0986B9AC-13F4-4B9B-AADD-1940382DC77D@gmail.com> From: Spencer Dawkins at IETF Date: Tue, 21 Aug 2018 15:27:44 -0500 Message-ID: To: Aaron Falk Cc: Michael Welzl , draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , taps WG Content-Type: multipart/alternative; boundary="00000000000076a0910573f7dc0d" Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 21 Aug 2018 20:28:00 -0000 --00000000000076a0910573f7dc0d Content-Type: text/plain; charset="UTF-8" Hi, Aaron, On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk wrote: > Glad to see rapid convergence on these comments. My turn for a nit: > > On 21 Aug 2018, at 2:48, Michael Welzl wrote: > > I'm not sure if you saw my suggestion about qualifying the reference to > [I-D.ietf-taps-transport-security] as "Section 5 of > [I-D.ietf-taps-transport-security]", but assuming that we're good on that > one ... > > > I saw it and agree. I thought that it's not necessary for the specific > sentence that you ended up proposing, but now I agree that even in this > sentence it's better. I'll update it to include "Section 5 of" just ahead > of this reference. > > The likelihood of an ID having it's sections renumbered is high enough > that I don't think we should embed the section number in an RFC. I'd > suggest using the section name as well in case one or both changes the > reader is likely to make the connection: "Section 5 on Security Features > and Transport Dependencies of ..." > I totally agree on this one. I only suggested adding the section number because I couldn't find any mention of the minimum set in the abstract or Introduction for [I-D.ietf-taps-transport-security], so a reader would have to scroll through the Table of Contents to notice it. I had a nagging feeling when I made the suggestion - thanks for fixing it. If I might make one other observation, there are a few places visible in https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for Section A (I think A.1) where there seems to be a missing newline between "Implementation over TCP:" and "Implementation over UDP:" - I saw more than one occurrence, but I think the first one to check is under "Specify checksum coverage used by the sender" for "Protocols: UDP-Lite". I had thought to make that observation as a response to the Last Call announcement, but Aaron sent his suggested change before I did that. I'll let the shepherds/chairs decide when to submit a revision that fixes these nits, but if you folks wanted to do that at the beginning of Last Call, I'd be fine with that, so review teams won't all make that suggestion. :-) Spencer > --aaron > --00000000000076a0910573f7dc0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Aaron,=C2=A0

Glad to see rapid convergence on these comments. My turn for = a nit:

On 21 Aug 2018, at 2:48, Michael Welzl wrote:

I'm not su= re if you saw my suggestion about qualifying the reference to [I-D.ietf-ta= ps-transport-security] as "Section 5 of [I-D.ietf-taps-transport-sec= urity]", but assuming that we're good on that one ...


I saw it and agree. I thought that it's not necessary for the specific = sentence that you ended up proposing, but now I agree that even in this sen= tence it's better. I'll update it to include "Section 5 of&quo= t; just ahead of this reference.

The likelihood of an ID having it's sectio= ns renumbered is high enough that I don't think we should embed the sec= tion number in an RFC. I'd suggest using the section name as well in c= ase one or both changes the reader is likely to make the connection: "= ;Section 5 on Security Features and Transport Dependencies of ..."

=

I totally agree on this = one. I only suggested adding the section number because I couldn't find= any mention of the minimum set in the abstract or Introduction for=C2=A0[I= -D.ietf-taps-transport-security], so a reader would have to scroll through = the Table of Contents to notice it. I had a nagging feeling when I made the= suggestion - thanks for fixing it.

If I might mak= e one other observation, there are a few places visible in=C2=A0https:= //tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-minset-05.txt for Secti= on A (I think A.1) where there seems to be a missing newline between "= Implementation over TCP:" and "Implementation over UDP:" - I= saw more than one occurrence, but I think the first one to check is under = "Specify checksum coverage used by the sender" for "Protocol= s: UDP-Lite". I had thought to make that observation as a response to = the Last Call announcement, but Aaron sent his suggested change before I di= d that.

I'll let the shepherds/chairs decide w= hen to submit a revision that fixes these nits, but if you folks wanted to = do that at the beginning of Last Call, I'd be fine with that, so review= teams won't all make that suggestion. :-)

Spe= ncer
=C2=A0

--aaron

--00000000000076a0910573f7dc0d-- From nobody Wed Aug 22 05:49:46 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 62C2B130E0F; Wed, 22 Aug 2018 05:49:44 -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 8yPZv5nmCQPj; Wed, 22 Aug 2018 05:49:40 -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 72370127333; Wed, 22 Aug 2018 05:49:40 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fsSZu-000Gl3-18; Wed, 22 Aug 2018 14:49:38 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fsSZs-0007G4-AG; Wed, 22 Aug 2018 14:49:37 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Wed, 22 Aug 2018 14:49:26 +0200 Cc: Aaron Falk , draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <9E7BD102-B5AF-43A5-A260-353C18F6171E@ifi.uio.no> References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> <0986B9AC-13F4-4B9B-AADD-1940382DC77D@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; 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: E10FBDF328256B9C7F7C564E7F046DF847EC776D Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 12:49:45 -0000 Hi, > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF = wrote: >=20 > Hi, Aaron,=20 >=20 > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk = wrote: > Glad to see rapid convergence on these comments. My turn for a nit: >=20 > On 21 Aug 2018, at 2:48, Michael Welzl wrote: >=20 > I'm not sure if you saw my suggestion about qualifying the reference = to [I-D.ietf-taps-transport-security] as "Section 5 of = [I-D.ietf-taps-transport-security]", but assuming that we're good on = that one ... >=20 >=20 > I saw it and agree. I thought that it's not necessary for the specific = sentence that you ended up proposing, but now I agree that even in this = sentence it's better. I'll update it to include "Section 5 of" just = ahead of this reference. >=20 > The likelihood of an ID having it's sections renumbered is high enough = that I don't think we should embed the section number in an RFC. I'd = suggest using the section name as well in case one or both changes the = reader is likely to make the connection: "Section 5 on Security Features = and Transport Dependencies of ..." >=20 >=20 > I totally agree on this one. I only suggested adding the section = number because I couldn't find any mention of the minimum set in the = abstract or Introduction for [I-D.ietf-taps-transport-security], so a = reader would have to scroll through the Table of Contents to notice it. = I had a nagging feeling when I made the suggestion - thanks for fixing = it. Done (in my local copy). Actually I thought of the same thing but wasn't = sure for one reason or another... I should have just gone for it! > If I might make one other observation, there are a few places visible = in https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-minset-05.txt = for Section A (I think A.1) where there seems to be a missing newline = between "Implementation over TCP:" and "Implementation over UDP:" - I = saw more than one occurrence, but I think the first one to check is = under "Specify checksum coverage used by the sender" for "Protocols: = UDP-Lite". I had thought to make that observation as a response to the = Last Call announcement, but Aaron sent his suggested change before I did = that. I don't see this; "Implementation over UDP" seems to start on a new line = everywhere. What I do see is that an extra empty line has = unintentionally ended up in there in a few places. Do you mean that = there SHOULD be an extra empty line? I'd find that a bit odd, unless I = add empty lines all over the place. E.g., consider the following block: *** o Indicate (and/or obtain upon completion) an Adaptation Layer via an adaptation code point Protocols: SCTP Functional because it allows to send extra data for the sake of identifying an adaptation layer, which by itself is application- specific. Implementation: via a parameter in CONNECT.SCTP. Implementation over TCP: not possible (TCP does not offer this functionality). Implementation over UDP: not possible (UDP does not offer this functionality). *** If I add an empty line above "Implementation over UDP", then I should = probably also add one above "Implementation over TCP", above = "Implementation", above the line beginning with "Functional" and above = "Protocols: SCTP", right? But then this gets huge... My tendency would be to remove the extra lines. HOWEVER: it seems that the diff you're pointing at is misleading :( I = just checked against my local .txt file: in one case, the extra line was = added in the diff because, in fact, there was a new page (new pages with = headers are not shown in the diff), and in another, I don't understand = where the extra line in the diff comes from - my .txt doesn't have it. Either way, my proposal would be to go for the style of the text block I = copied above. Is that ok? > I'll let the shepherds/chairs decide when to submit a revision that = fixes these nits, but if you folks wanted to do that at the beginning of = Last Call, I'd be fine with that, so review teams won't all make that = suggestion. :-) I'll do it as soon as I know what to do with line feeds! Cheers, Michael From nobody Wed Aug 22 06:20:57 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 81F3512F1AC; Wed, 22 Aug 2018 06:20:53 -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 1SUHrwrUPADP; Wed, 22 Aug 2018 06:20:50 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 825CE127333; Wed, 22 Aug 2018 06:20:50 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id l189-v6so613106ywb.10; Wed, 22 Aug 2018 06:20:50 -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=uwRMaK++AutPlfWJ4968qIQ/RKCnFHwzznh2zJ8xBUc=; b=d8/en0sp/tNLeXLJsSfVBv05KyAnIfTUrRNO4SuuS5Y1CUGc3bfSy3viO6+APQhG/h P7Kls5Jwz+V9U1Ugo3LOkVcrPeKdg3mKK9asgJez0enKTus2IlbFpphNHkQy38Jhpfer 33Tf5oO4Arpgz/HRE9c4fxLuC6KOoafJqD8plPUuXIqmfSpG+K8wlx9Zmr6A8FYPSNye I2Hz8/PTzIduPxQGjrPvZmCBGFTF/jvRgI+wdtY7JB8cFRHgRdKBEM9hMrBU+pGpmsGV svAZ3A2Eb6SlfpvL9Of1FLcG6Ov4Sn9PMCenxOw9+8cqRm2vY2nfA8JBvbZYmAjKT3zA 3HGA== 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=uwRMaK++AutPlfWJ4968qIQ/RKCnFHwzznh2zJ8xBUc=; b=Gzny8jrsVin/JsvgTXi+OtcQEg7QhyoLI9fV5E6zptU2F6qvh/KZiuI0+WReBxRGbz VsUeZuHdGuoniYY1CXNJAdGsAHmJdqujIDRseRW+3WVgzcVl38CvhaEeOE9KKwq3B2NF Y92ctM1HO5DSAkNQ3ciuqX+baqI5/w5auQW7QdhB8Et/POvLkexD80axqTF6QbTkbwwr 3PYDdr6nZVwQbj1aihBjuVYWwdTvJwJaBM3z3+bE8X1VA4NovsGdB/2dfVhlj3TPHlRe 5xbO6Vllm+rem6fpdT53cGO4iOPJa4fZQyW+TnTAVh13p5cAoO9oxGI0Rao+xHF8hm9G K9dw== X-Gm-Message-State: AOUpUlGwDfBsnPDT6/LnepKW7bS/vvDMllZXcWLDbJXCDPnCjC+J81kU O4sf4rMA45RaEp/QuvfdCeyQemOnqiJzUdr7ZGg= X-Google-Smtp-Source: AA+uWPwfP4yqxqpYvT05Wc3zm5bNfI9j56ZfZGfD+FdG2yhPa43u/jNmo61ehFhJnP22l1B7W5L/XHTJA/nODCgTpBw= X-Received: by 2002:a81:3d08:: with SMTP id k8-v6mr29326636ywa.393.1534944049563; Wed, 22 Aug 2018 06:20:49 -0700 (PDT) MIME-Version: 1.0 References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> <0986B9AC-13F4-4B9B-AADD-1940382DC77D@gmail.com> <9E7BD102-B5AF-43A5-A260-353C18F6171E@ifi.uio.no> In-Reply-To: <9E7BD102-B5AF-43A5-A260-353C18F6171E@ifi.uio.no> From: Spencer Dawkins at IETF Date: Wed, 22 Aug 2018 08:20:36 -0500 Message-ID: To: Michael Welzl Cc: Aaron Falk , draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , taps WG Content-Type: multipart/alternative; boundary="000000000000d30b890574060261" Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 13:20:54 -0000 --000000000000d30b890574060261 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl wrote: > Hi, > > > > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, Aaron, > > > > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk wrote: > > Glad to see rapid convergence on these comments. My turn for a nit: > > > > On 21 Aug 2018, at 2:48, Michael Welzl wrote: > > > > I'm not sure if you saw my suggestion about qualifying the reference to > [I-D.ietf-taps-transport-security] as "Section 5 of > [I-D.ietf-taps-transport-security]", but assuming that we're good on that > one ... > > > > > > I saw it and agree. I thought that it's not necessary for the specific > sentence that you ended up proposing, but now I agree that even in this > sentence it's better. I'll update it to include "Section 5 of" just ahead > of this reference. > > > > The likelihood of an ID having it's sections renumbered is high enough > that I don't think we should embed the section number in an RFC. I'd > suggest using the section name as well in case one or both changes the > reader is likely to make the connection: "Section 5 on Security Features > and Transport Dependencies of ..." > > > > > > I totally agree on this one. I only suggested adding the section number > because I couldn't find any mention of the minimum set in the abstract or > Introduction for [I-D.ietf-taps-transport-security], so a reader would have > to scroll through the Table of Contents to notice it. I had a nagging > feeling when I made the suggestion - thanks for fixing it. > > Done (in my local copy). Actually I thought of the same thing but wasn't > sure for one reason or another... I should have just gone for it! > > > > If I might make one other observation, there are a few places visible in > https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for > Section A (I think A.1) where there seems to be a missing newline between > "Implementation over TCP:" and "Implementation over UDP:" - I saw more than > one occurrence, but I think the first one to check is under "Specify > checksum coverage used by the sender" for "Protocols: UDP-Lite". I had > thought to make that observation as a response to the Last Call > announcement, but Aaron sent his suggested change before I did that. > > I don't see this; "Implementation over UDP" seems to start on a new line > everywhere. What I do see is that an extra empty line has unintentionally > ended up in there in a few places. Do you mean that there SHOULD be an > extra empty line? I'm not sure what I'm seeing is what you're seeing. Let's talk before asking you to type :-) I'm looking at the bottom of page 29, top of page 30, in the HTML version. That's for o Specify checksum coverage used by the sender Protocols: UDP-Lite What I'm seeing in HTML for this section, is o Specify checksum coverage used by the sender Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. Welzl & Gjessing Expires February 21, 2019 [Page 29] Internet-Draft Minimal Transport Services August 2018 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result). Implementation over So, I'm not seeing a newline before "Implementation" here. UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum when sending". But since I always use the HTML version, and that's not even the canonical version, I checked the same thing in the TXT version, but it also looks like o Specify checksum coverage used by the sender Protocols: UDP-Lite Functional because application-specific knowledge is necessary to decide for which parts of the data it can be acceptable to lose data integrity. Welzl & Gjessing Expires February 21, 2019 [Page 29] Internet-Draft Minimal Transport Services August 2018 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. Implementation over TCP: do nothing (TCP does not offer to limit the checksum length, but transmitting data with an intact checksum will not yield a semantically wrong result). Implementation over and I'm not seeing a newline before "Implementation" here, either. UDP: if checksum coverage is set to cover payload data, do nothing. Else, either do nothing (transmitting data with an intact checksum will not yield a semantically wrong result), or use the transport feature "Disable checksum when sending". So I should probably ask what format you're looking at, if you're not seeing what I'm seeing? Thanks for chasing this nit with me, by the way. Spencer > I'd find that a bit odd, unless I add empty lines all over the place. > E.g., consider the following block: > > *** > o Indicate (and/or obtain upon completion) an Adaptation Layer via > an adaptation code point > Protocols: SCTP > Functional because it allows to send extra data for the sake of > identifying an adaptation layer, which by itself is application- > specific. > Implementation: via a parameter in CONNECT.SCTP. > Implementation over TCP: not possible (TCP does not offer this > functionality). > Implementation over UDP: not possible (UDP does not offer this > functionality). > *** > > If I add an empty line above "Implementation over UDP", then I should > probably also add one above "Implementation over TCP", above > "Implementation", above the line beginning with "Functional" and above > "Protocols: SCTP", right? But then this gets huge... > > My tendency would be to remove the extra lines. > > HOWEVER: it seems that the diff you're pointing at is misleading :( I > just checked against my local .txt file: in one case, the extra line was > added in the diff because, in fact, there was a new page (new pages with > headers are not shown in the diff), and in another, I don't understand > where the extra line in the diff comes from - my .txt doesn't have it. > > Either way, my proposal would be to go for the style of the text block I > copied above. Is that ok? > > > > I'll let the shepherds/chairs decide when to submit a revision that > fixes these nits, but if you folks wanted to do that at the beginning of > Last Call, I'd be fine with that, so review teams won't all make that > suggestion. :-) > > I'll do it as soon as I know what to do with line feeds! > > Cheers, > Michael > > --000000000000d30b890574060261 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0
On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl <michawe@ifi.uio.no> wrote:
Hi,


> On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF <spencerdawkins.ietf@gmai= l.com> wrote:
>
> Hi, Aaron,
>
> On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk <aaron.falk@gmail.com> wrote:
> Glad to see rapid convergence on these comments. My turn for a nit: >
> On 21 Aug 2018, at 2:48, Michael Welzl wrote:
>
> I'm not sure if you saw my suggestion about qualifying the referen= ce to [I-D.ietf-taps-transport-security] as "Section 5 of [I-D.ietf-ta= ps-transport-security]", but assuming that we're good on that one = ...
>
>
> I saw it and agree. I thought that it's not necessary for the spec= ific sentence that you ended up proposing, but now I agree that even in thi= s sentence it's better. I'll update it to include "Section 5 o= f" just ahead of this reference.
>
> The likelihood of an ID having it's sections renumbered is high en= ough that I don't think we should embed the section number in an RFC. I= 'd suggest using the section name as well in case one or both changes t= he reader is likely to make the connection: "Section 5 on Security Fea= tures and Transport Dependencies of ..."
>
>
> I totally agree on this one. I only suggested adding the section numbe= r because I couldn't find any mention of the minimum set in the abstrac= t or Introduction for [I-D.ietf-taps-transport-security], so a reader would= have to scroll through the Table of Contents to notice it. I had a nagging= feeling when I made the suggestion - thanks for fixing it.

Done (in my local copy). Actually I thought of the same thing but wasn'= t sure for one reason or another... I should have just gone for it!


> If I might make one other observation, there are a few places visible = in https://tools.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-taps-minset-05.txt for Section A (I think A.1) where= there seems to be a missing newline between "Implementation over TCP:= " and "Implementation over UDP:" - I saw more than one occur= rence, but I think the first one to check is under "Specify checksum c= overage used by the sender" for "Protocols: UDP-Lite". I had= thought to make that observation as a response to the Last Call announceme= nt, but Aaron sent his suggested change before I did that.

I don't see this; "Implementation over UDP" seems to start on= a new line everywhere. What I do see is that an extra empty line has unint= entionally ended up in there in a few places. Do you mean that there SHOULD= be an extra empty line?=C2=A0

I'm not= sure what I'm seeing is what you're seeing. Let's talk before = asking you to type :-)

I'm looking at the bott= om of page 29, top of page 30, in the HTML version. That's for=C2=A0

=C2=A0 =C2=A0o=C2=A0 Specify checksum coverage = used by the sender
=C2=A0 =C2=A0 =C2=A0 Protocols: UDP-Lite
=

What I'm seeing in HTML for this section, is= =C2=A0

=C2=A0 =C2=A0o=C2=A0 Specify checksum = coverage used by the sender
=C2=A0 =C2=A0 =C2=A0 Protocols: UDP-L= ite
=C2=A0 =C2=A0 =C2=A0 Functional because application-specific = knowledge is necessary to
=C2=A0 =C2=A0 =C2=A0 decide for which p= arts of the data it can be acceptable to lose
=C2=A0 =C2=A0 =C2= =A0 data integrity.



= Welzl & Gjessing=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires February 21, 2019= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 29]
=C2=A0=
Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Minimal Transpor= t Services=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 August 2018
<= br>

=C2=A0 =C2=A0 =C2=A0 Implementation: via SET_C= HECKSUM_COVERAGE.UDP-Lite.
=C2=A0 =C2=A0 =C2=A0 Implementation ov= er TCP: do nothing (TCP does not offer to limit
=C2=A0 =C2=A0 =C2= =A0 the checksum length, but transmitting data with an intact checksum
=C2=A0 =C2=A0 =C2=A0 will not yield a semantically wrong result).=C2= =A0 Implementation over

So, I'm not seeing a n= ewline before "Implementation" here.=C2=A0

=C2=A0 =C2=A0 =C2=A0 UDP: if checksum coverage is set to cover payload d= ata, do
=C2=A0 =C2=A0 =C2=A0 nothing.=C2=A0 Else, either do nothi= ng (transmitting data with an
=C2=A0 =C2=A0 =C2=A0 intact checksu= m will not yield a semantically wrong result), or
=C2=A0 =C2=A0 = =C2=A0 use the transport feature "Disable checksum when sending".=

But since I always use the HTML version, an= d that's not even the canonical version, I checked the same thing in th= e TXT version, but it also looks like=C2=A0

= =C2=A0 =C2=A0o=C2=A0 Specify checksum coverage used by the sender
=C2=A0 =C2=A0 =C2=A0 Protocols: UDP-Lite
=C2=A0 =C2=A0 =C2=A0 Fu= nctional because application-specific knowledge is necessary to
= =C2=A0 =C2=A0 =C2=A0 decide for which parts of the data it can be acceptabl= e to lose
=C2=A0 =C2=A0 =C2=A0 data integrity.



Welzl & Gjessing=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Expires February 21, 2019=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [Page 29]
=0C
Internet-Draft=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Minimal Transport Services=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 August 2018


=C2=A0 = =C2=A0 =C2=A0 Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite.
=C2=A0 =C2=A0 =C2=A0 Implementation over TCP: do nothing (TCP does not off= er to limit
=C2=A0 =C2=A0 =C2=A0 the checksum length, but transmi= tting data with an intact checksum
=C2=A0 =C2=A0 =C2=A0 will not = yield a semantically wrong result).=C2=A0 Implementation over
and I'm not seeing a newline before "Implementation&qu= ot; here, either.=C2=A0

=C2=A0 =C2=A0 =C2=A0 UDP: = if checksum coverage is set to cover payload data, do
=C2=A0 =C2= =A0 =C2=A0 nothing.=C2=A0 Else, either do nothing (transmitting data with a= n
=C2=A0 =C2=A0 =C2=A0 intact checksum will not yield a semantica= lly wrong result), or
=C2=A0 =C2=A0 =C2=A0 use the transport feat= ure "Disable checksum when sending".

So I should probably ask what format you're looking at, if you'r= e not seeing what I'm seeing?

Thanks for chasi= ng this nit with me, by the way.

Spencer
=C2=A0
I'd find= that a bit odd, unless I add empty lines all over the place. E.g., conside= r the following block:

***
=C2=A0 =C2=A0o=C2=A0 Indicate (and/or obtain upon completion) an Adaptation= Layer via
=C2=A0 =C2=A0 =C2=A0 an adaptation code point
=C2=A0 =C2=A0 =C2=A0 Protocols: SCTP
=C2=A0 =C2=A0 =C2=A0 Functional because it allows to send extra data for th= e sake of
=C2=A0 =C2=A0 =C2=A0 identifying an adaptation layer, which by itself is ap= plication-
=C2=A0 =C2=A0 =C2=A0 specific.
=C2=A0 =C2=A0 =C2=A0 Implementation: via a parameter in CONNECT.SCTP.
=C2=A0 =C2=A0 =C2=A0 Implementation over TCP: not possible (TCP does not of= fer this
=C2=A0 =C2=A0 =C2=A0 functionality).
=C2=A0 =C2=A0 =C2=A0 Implementation over UDP: not possible (UDP does not of= fer this
=C2=A0 =C2=A0 =C2=A0 functionality).
***

If I add an empty line above "Implementation over UDP", then I sh= ould probably also add one above "Implementation over TCP", above= "Implementation", above the line beginning with "Functional= " and above "Protocols: SCTP", right?=C2=A0 But then this ge= ts huge...

My tendency would be to remove the extra lines.

HOWEVER: it seems that the diff you're pointing at is misleading=C2=A0 = :(=C2=A0 =C2=A0I just checked against my local .txt file: in one case, the = extra line was added in the diff because, in fact, there was a new page (ne= w pages with headers are not shown in the diff), and in another, I don'= t understand where the extra line in the diff comes from - my .txt doesn= 9;t have it.

Either way, my proposal would be to go for the style of the text block I co= pied above. Is that ok?


> I'll let the shepherds/chairs decide when to submit a revision tha= t fixes these nits, but if you folks wanted to do that at the beginning of = Last Call, I'd be fine with that, so review teams won't all make th= at suggestion. :-)

I'll do it as soon as I know what to do with line feeds!

Cheers,
Michael

--000000000000d30b890574060261-- From nobody Wed Aug 22 06:50: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 0CB0A130E7C; Wed, 22 Aug 2018 06:50:50 -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 g9u7DpBdYXOf; Wed, 22 Aug 2018 06:50:46 -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 941E2130EDA; Wed, 22 Aug 2018 06:50:46 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fsTX2-0004ds-4P; Wed, 22 Aug 2018 15:50:44 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fsTWy-000EId-1h; Wed, 22 Aug 2018 15:50:44 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Wed, 22 Aug 2018 15:50:38 +0200 Cc: Aaron Falk , draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> <0986B9AC-13F4-4B9B-AADD-1940382DC77D@gmail.com> <9E7BD102-B5AF-43A5-A260-353C18F6171E@ifi.uio.no> To: Spencer Dawkins X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; 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: 43EACDB403263E66182D42A80BFE784F012346BA Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 13:50:50 -0000 > On 22 Aug 2018, at 15:20, Spencer Dawkins at IETF = wrote: >=20 > Hi, Michael,=20 > On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl = wrote: > Hi, >=20 >=20 > > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF = wrote: > >=20 > > Hi, Aaron,=20 > >=20 > > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk = wrote: > > Glad to see rapid convergence on these comments. My turn for a nit: > >=20 > > On 21 Aug 2018, at 2:48, Michael Welzl wrote: > >=20 > > I'm not sure if you saw my suggestion about qualifying the reference = to [I-D.ietf-taps-transport-security] as "Section 5 of = [I-D.ietf-taps-transport-security]", but assuming that we're good on = that one .... > >=20 > >=20 > > I saw it and agree. I thought that it's not necessary for the = specific sentence that you ended up proposing, but now I agree that even = in this sentence it's better. I'll update it to include "Section 5 of" = just ahead of this reference. > >=20 > > The likelihood of an ID having it's sections renumbered is high = enough that I don't think we should embed the section number in an RFC. = I'd suggest using the section name as well in case one or both changes = the reader is likely to make the connection: "Section 5 on Security = Features and Transport Dependencies of ..." > >=20 > >=20 > > I totally agree on this one. I only suggested adding the section = number because I couldn't find any mention of the minimum set in the = abstract or Introduction for [I-D.ietf-taps-transport-security], so a = reader would have to scroll through the Table of Contents to notice it. = I had a nagging feeling when I made the suggestion - thanks for fixing = it. >=20 > Done (in my local copy). Actually I thought of the same thing but = wasn't sure for one reason or another... I should have just gone for it! >=20 >=20 > > If I might make one other observation, there are a few places = visible in = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-minset-05.txt for = Section A (I think A.1) where there seems to be a missing newline = between "Implementation over TCP:" and "Implementation over UDP:" - I = saw more than one occurrence, but I think the first one to check is = under "Specify checksum coverage used by the sender" for "Protocols: = UDP-Lite". I had thought to make that observation as a response to the = Last Call announcement, but Aaron sent his suggested change before I did = that. >=20 > I don't see this; "Implementation over UDP" seems to start on a new = line everywhere. What I do see is that an extra empty line has = unintentionally ended up in there in a few places. Do you mean that = there SHOULD be an extra empty line?=20 >=20 > I'm not sure what I'm seeing is what you're seeing. Let's talk before = asking you to type :-) >=20 > I'm looking at the bottom of page 29, top of page 30, in the HTML = version. That's for=20 >=20 > o Specify checksum coverage used by the sender > Protocols: UDP-Lite >=20 > What I'm seeing in HTML for this section, is=20 >=20 > o Specify checksum coverage used by the sender > Protocols: UDP-Lite > Functional because application-specific knowledge is necessary = to > decide for which parts of the data it can be acceptable to lose > data integrity. >=20 >=20 >=20 > Welzl & Gjessing Expires February 21, 2019 [Page = 29] > =20 > Internet-Draft Minimal Transport Services August = 2018 >=20 >=20 > Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. > Implementation over TCP: do nothing (TCP does not offer to limit > the checksum length, but transmitting data with an intact = checksum > will not yield a semantically wrong result). Implementation = over >=20 > So, I'm not seeing a newline before "Implementation" here.=20 >=20 > UDP: if checksum coverage is set to cover payload data, do > nothing. Else, either do nothing (transmitting data with an > intact checksum will not yield a semantically wrong result), or > use the transport feature "Disable checksum when sending". >=20 > But since I always use the HTML version, and that's not even the = canonical version, I checked the same thing in the TXT version, but it = also looks like=20 >=20 > o Specify checksum coverage used by the sender > Protocols: UDP-Lite > Functional because application-specific knowledge is necessary = to > decide for which parts of the data it can be acceptable to lose > data integrity. >=20 >=20 >=20 > Welzl & Gjessing Expires February 21, 2019 [Page = 29] > Internet-Draft Minimal Transport Services August = 2018 >=20 >=20 > Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. > Implementation over TCP: do nothing (TCP does not offer to limit > the checksum length, but transmitting data with an intact = checksum > will not yield a semantically wrong result). Implementation = over >=20 > and I'm not seeing a newline before "Implementation" here, either.=20 >=20 > UDP: if checksum coverage is set to cover payload data, do > nothing. Else, either do nothing (transmitting data with an > intact checksum will not yield a semantically wrong result), or > use the transport feature "Disable checksum when sending". >=20 > So I should probably ask what format you're looking at, if you're not = seeing what I'm seeing? When I talked about extra empty lines, I was looking at exactly what my = browser gives me when following the URL that you included: https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-minset-05.txt ... which is a side-by-side diff. But now I found it! The problem was that I did a text search for = "implementation over UDP", which failed to show me these cases due to = the line break *within* the phrase :-) Oh my :) Now I did a search for "UDP:" instead, and with that, I only find = precisely the two cases that you quote above. So I think that's it - = I'll fix and submit. > Thanks for chasing this nit with me, by the way. No, thanks to *you* for finding and telling ! Cheers, Michael From nobody Wed Aug 22 07:01:22 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 A2EAB128CFD; Wed, 22 Aug 2018 07:01:13 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <153494647358.21024.163795285951226284@ietfa.amsl.com> Date: Wed, 22 Aug 2018 07:01:13 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-minset-06.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2018 14:01:14 -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 Minimal Set of Transport Services for End Systems Authors : Michael Welzl Stein Gjessing Filename : draft-ietf-taps-minset-06.txt Pages : 48 Date : 2018-08-22 Abstract: This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-minset-06 https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-06 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 Aug 22 07:29:46 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 F12AC130DFC; Wed, 22 Aug 2018 07:29:44 -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 arn03M4TzK7X; Wed, 22 Aug 2018 07:29:42 -0700 (PDT) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 CC4F7130E0C; Wed, 22 Aug 2018 07:29:41 -0700 (PDT) Received: by mail-yw1-xc2c.google.com with SMTP id n207-v6so703790ywn.9; Wed, 22 Aug 2018 07:29:41 -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=yp7eZzn464khSyzF2T2aYJYbdHW+VVm+uMbeOxOS5/U=; b=psgaaXvTbAWAyAkdF0J7GY2HZ4LbIwUA/4KhXfuRi4deg7wFeO2jea4bz7Mi7WF88r mVkJ0nH8P3Th83fpd5Mxhf13XYOjZ1ol91nw8c0KxDeTWxcaTTKwbQnzC6WdDeO5yELQ 4kagqO7WcH3CyvGSWGDILXo5W6Ud5KgTBM+RqeQbQ/3A6Cf0+wl4eU/J3+v0/FTAcn3n 52Z/hE2OKTAhw3odEpt1CNYWzrSw2SS2l2D4PMQOyNx44P1W+ehMniOYEZT+7pu7Tf39 QcH2H2wKcBQsjiCyWPuYs3mQu4Phpr2VSjzbokozAGjJP3ioSDWpefEqWiNwpfPMspE1 YefA== 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=yp7eZzn464khSyzF2T2aYJYbdHW+VVm+uMbeOxOS5/U=; b=C8W/CChs0Hm/YSlLvbDvb2xjEquV7emED6fQ8opMJl9EI+wIPM9InC/HQHFAW4XJ0v WhjSCL6w0zYLW10bBYBU9UYHAL4Ix/4VxESo8/b/sZxMtPXh7+JfGoLUm/jo66AfpZ2V I5B9t09S48+JEBKqSVzBexNN02IGk2aarhDZoXdEOYCM3OGdDSuZd5yy/r7kktcnaPI9 pf6fegDkE7BDbzGnT0dRG6a3iZwGSH6nJgEjBh5TxQKBRU+qa8T6AZW9AlV1NtMedAL3 wXLHp+yffteJsX/lBLqceBAfM5WnUZkQhScj38yK6yzQY3j7+yQlBM9BlwKCu2Ohk9Az B5Ew== X-Gm-Message-State: APzg51C4a9WjzO2LS0qu62YODf8hjyemi9cy1JNvL/u+aJbkdSPyTqey rEKYX81GxqCBerXYAaauqlKrXcYTfblMf8aaDN6yTg== X-Google-Smtp-Source: ANB0VdasobOG8XQnXdorAMUbfxhzaZLouIgW5R6MYNeurT+2T3woe6sXSVfyXWefw8t+txexISl1HHyZGtutkG8C1nc= X-Received: by 2002:a81:4cca:: with SMTP id z193-v6mr113606ywa.411.1534948180877; Wed, 22 Aug 2018 07:29:40 -0700 (PDT) MIME-Version: 1.0 References: <153202988904.10474.9175892480215474965.idtracker@ietfa.amsl.com> <9D288441-913F-408F-9B1D-10CAEF4F5E6E@ifi.uio.no> <6451F511-509C-4C7E-8CE8-14B459D81EE3@ifi.uio.no> <0986B9AC-13F4-4B9B-AADD-1940382DC77D@gmail.com> <9E7BD102-B5AF-43A5-A260-353C18F6171E@ifi.uio.no> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 22 Aug 2018 09:29:27 -0500 Message-ID: To: Michael Welzl Cc: Aaron Falk , draft-ietf-taps-minset@ietf.org, taps-chairs@ietf.org, Theresa Enghardt , taps WG Content-Type: multipart/alternative; boundary="00000000000011e82d057406f978" Archived-At: Subject: Re: [Taps] Publication has been requested for draft-ietf-taps-minset-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 22 Aug 2018 14:29:45 -0000 --00000000000011e82d057406f978 Content-Type: text/plain; charset="UTF-8" Hi, Michael, On Wed, Aug 22, 2018 at 8:50 AM Michael Welzl wrote: > > > > On 22 Aug 2018, at 15:20, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, Michael, > > On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl > wrote: > > Hi, > > > > > > > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > > > Hi, Aaron, > > > > > > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk > wrote: > > > Glad to see rapid convergence on these comments. My turn for a nit: > > > > > > On 21 Aug 2018, at 2:48, Michael Welzl wrote: > > > > > > I'm not sure if you saw my suggestion about qualifying the reference > to [I-D.ietf-taps-transport-security] as "Section 5 of > [I-D.ietf-taps-transport-security]", but assuming that we're good on that > one .... > > > > > > > > > I saw it and agree. I thought that it's not necessary for the specific > sentence that you ended up proposing, but now I agree that even in this > sentence it's better. I'll update it to include "Section 5 of" just ahead > of this reference. > > > > > > The likelihood of an ID having it's sections renumbered is high enough > that I don't think we should embed the section number in an RFC. I'd > suggest using the section name as well in case one or both changes the > reader is likely to make the connection: "Section 5 on Security Features > and Transport Dependencies of ..." > > > > > > > > > I totally agree on this one. I only suggested adding the section > number because I couldn't find any mention of the minimum set in the > abstract or Introduction for [I-D.ietf-taps-transport-security], so a > reader would have to scroll through the Table of Contents to notice it. I > had a nagging feeling when I made the suggestion - thanks for fixing it. > > > > Done (in my local copy). Actually I thought of the same thing but wasn't > sure for one reason or another... I should have just gone for it! > > > > > > > If I might make one other observation, there are a few places visible > in https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt for > Section A (I think A.1) where there seems to be a missing newline between > "Implementation over TCP:" and "Implementation over UDP:" - I saw more than > one occurrence, but I think the first one to check is under "Specify > checksum coverage used by the sender" for "Protocols: UDP-Lite". I had > thought to make that observation as a response to the Last Call > announcement, but Aaron sent his suggested change before I did that. > > > > I don't see this; "Implementation over UDP" seems to start on a new line > everywhere. What I do see is that an extra empty line has unintentionally > ended up in there in a few places. Do you mean that there SHOULD be an > extra empty line? > > > > I'm not sure what I'm seeing is what you're seeing. Let's talk before > asking you to type :-) > > > > I'm looking at the bottom of page 29, top of page 30, in the HTML > version. That's for > > > > o Specify checksum coverage used by the sender > > Protocols: UDP-Lite > > > > What I'm seeing in HTML for this section, is > > > > o Specify checksum coverage used by the sender > > Protocols: UDP-Lite > > Functional because application-specific knowledge is necessary to > > decide for which parts of the data it can be acceptable to lose > > data integrity. > > > > > > > > Welzl & Gjessing Expires February 21, 2019 [Page 29] > > > > Internet-Draft Minimal Transport Services August 2018 > > > > > > Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. > > Implementation over TCP: do nothing (TCP does not offer to limit > > the checksum length, but transmitting data with an intact checksum > > will not yield a semantically wrong result). Implementation over > > > > So, I'm not seeing a newline before "Implementation" here. > > > > UDP: if checksum coverage is set to cover payload data, do > > nothing. Else, either do nothing (transmitting data with an > > intact checksum will not yield a semantically wrong result), or > > use the transport feature "Disable checksum when sending". > > > > But since I always use the HTML version, and that's not even the > canonical version, I checked the same thing in the TXT version, but it also > looks like > > > > o Specify checksum coverage used by the sender > > Protocols: UDP-Lite > > Functional because application-specific knowledge is necessary to > > decide for which parts of the data it can be acceptable to lose > > data integrity. > > > > > > > > Welzl & Gjessing Expires February 21, 2019 [Page 29] > > Internet-Draft Minimal Transport Services August 2018 > > > > > > Implementation: via SET_CHECKSUM_COVERAGE.UDP-Lite. > > Implementation over TCP: do nothing (TCP does not offer to limit > > the checksum length, but transmitting data with an intact checksum > > will not yield a semantically wrong result). Implementation over > > > > and I'm not seeing a newline before "Implementation" here, either. > > > > UDP: if checksum coverage is set to cover payload data, do > > nothing. Else, either do nothing (transmitting data with an > > intact checksum will not yield a semantically wrong result), or > > use the transport feature "Disable checksum when sending". > > > > So I should probably ask what format you're looking at, if you're not > seeing what I'm seeing? > > When I talked about extra empty lines, I was looking at exactly what my > browser gives me when following the URL that you included: > https://tools.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-05.txt > ... which is a side-by-side diff. > > But now I found it! The problem was that I did a text search for > "implementation over UDP", which failed to show me these cases due to the > line break *within* the phrase :-) > > Oh my :) > > Now I did a search for "UDP:" instead, and with that, I only find > precisely the two cases that you quote above. So I think that's it - I'll > fix and submit. > Excellent. We're already in Last Call, so no action needed from me, I think. > > Thanks for chasing this nit with me, by the way. > > No, thanks to *you* for finding and telling ! > I'm glad I could help. Spencer > Cheers, > Michael > > --00000000000011e82d057406f978 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,=C2=A0

On Wed, Aug 22, 2018 at 8:50 AM Michael Welzl <michawe@ifi.uio.no> wrote:


> On 22 Aug 2018, at 15:20, Spencer Dawkins at IETF <spencerdawkins.ietf@gmai= l.com> wrote:
>
> Hi, Michael,
> On Wed, Aug 22, 2018 at 7:49 AM Michael Welzl <michawe@ifi.uio.no> wrote:
> Hi,
>
>
> > On 21 Aug 2018, at 22:27, Spencer Dawkins at IETF <spencerdawkins.ietf= @gmail.com> wrote:
> >
> > Hi, Aaron,
> >
> > On Tue, Aug 21, 2018 at 1:44 PM Aaron Falk <aaron.falk@gmail.com> wrote:=
> > Glad to see rapid convergence on these comments. My turn for a ni= t:
> >
> > On 21 Aug 2018, at 2:48, Michael Welzl wrote:
> >
> > I'm not sure if you saw my suggestion about qualifying the re= ference to [I-D.ietf-taps-transport-security] as "Section 5 of [I-D.ie= tf-taps-transport-security]", but assuming that we're good on that= one ....
> >
> >
> > I saw it and agree. I thought that it's not necessary for the= specific sentence that you ended up proposing, but now I agree that even i= n this sentence it's better. I'll update it to include "Sectio= n 5 of" just ahead of this reference.
> >
> > The likelihood of an ID having it's sections renumbered is hi= gh enough that I don't think we should embed the section number in an R= FC. I'd suggest using the section name as well in case one or both chan= ges the reader is likely to make the connection: "Section 5 on Securit= y Features and Transport Dependencies of ..."
> >
> >
> > I totally agree on this one. I only suggested adding the section = number because I couldn't find any mention of the minimum set in the ab= stract or Introduction for [I-D.ietf-taps-transport-security], so a reader = would have to scroll through the Table of Contents to notice it. I had a na= gging feeling when I made the suggestion - thanks for fixing it.
>
> Done (in my local copy). Actually I thought of the same thing but wasn= 't sure for one reason or another... I should have just gone for it! >
>
> > If I might make one other observation, there are a few places vis= ible in https://tools.ietf.org/rf= cdiff?url2=3Ddraft-ietf-taps-minset-05.txt for Section A (I think A.1) = where there seems to be a missing newline between "Implementation over= TCP:" and "Implementation over UDP:" - I saw more than one = occurrence, but I think the first one to check is under "Specify check= sum coverage used by the sender" for "Protocols: UDP-Lite". = I had thought to make that observation as a response to the Last Call annou= ncement, but Aaron sent his suggested change before I did that.
>
> I don't see this; "Implementation over UDP" seems to sta= rt on a new line everywhere. What I do see is that an extra empty line has = unintentionally ended up in there in a few places. Do you mean that there S= HOULD be an extra empty line?
>
> I'm not sure what I'm seeing is what you're seeing. Let= 9;s talk before asking you to type :-)
>
> I'm looking at the bottom of page 29, top of page 30, in the HTML = version. That's for
>
>=C2=A0 =C2=A0 o=C2=A0 Specify checksum coverage used by the sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Protocols: UDP-Lite
>
> What I'm seeing in HTML for this section, is
>
>=C2=A0 =C2=A0 o=C2=A0 Specify checksum coverage used by the sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Protocols: UDP-Lite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Functional because application-specific know= ledge is necessary to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0decide for which parts of the data it can be= acceptable to lose
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data integrity.
>
>
>
> Welzl & Gjessing=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires February 21, 2= 019=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 29]
>=C2=A0
> Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Minimal Transport Serv= ices=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 August 2018
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Implementation: via SET_CHECKSUM_COVERAGE.UD= P-Lite.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Implementation over TCP: do nothing (TCP doe= s not offer to limit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the checksum length, but transmitting data w= ith an intact checksum
>=C2=A0 =C2=A0 =C2=A0 =C2=A0will not yield a semantically wrong result).= =C2=A0 Implementation over
>
> So, I'm not seeing a newline before "Implementation" her= e.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0UDP: if checksum coverage is set to cover pa= yload data, do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0nothing.=C2=A0 Else, either do nothing (tran= smitting data with an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intact checksum will not yield a semanticall= y wrong result), or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use the transport feature "Disable chec= ksum when sending".
>
> But since I always use the HTML version, and that's not even the c= anonical version, I checked the same thing in the TXT version, but it also = looks like
>
>=C2=A0 =C2=A0 o=C2=A0 Specify checksum coverage used by the sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Protocols: UDP-Lite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Functional because application-specific know= ledge is necessary to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0decide for which parts of the data it can be= acceptable to lose
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data integrity.
>
>
>
> Welzl & Gjessing=C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires February 21, 2= 019=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 29]
> Internet-Draft=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Minimal Transport Serv= ices=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 August 2018
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Implementation: via SET_CHECKSUM_COVERAGE.UD= P-Lite.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Implementation over TCP: do nothing (TCP doe= s not offer to limit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the checksum length, but transmitting data w= ith an intact checksum
>=C2=A0 =C2=A0 =C2=A0 =C2=A0will not yield a semantically wrong result).= =C2=A0 Implementation over
>
> and I'm not seeing a newline before "Implementation" her= e, either.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0UDP: if checksum coverage is set to cover pa= yload data, do
>=C2=A0 =C2=A0 =C2=A0 =C2=A0nothing.=C2=A0 Else, either do nothing (tran= smitting data with an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intact checksum will not yield a semanticall= y wrong result), or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use the transport feature "Disable chec= ksum when sending".
>
> So I should probably ask what format you're looking at, if you'= ;re not seeing what I'm seeing?

When I talked about extra empty lines, I was looking at exactly what my bro= wser gives me when following the URL that you included:
https://tools.ietf.org/rfcdiff?ur= l2=3Ddraft-ietf-taps-minset-05.txt
... which is a side-by-side diff.

But now I found it!=C2=A0 The problem was that I did a text search for &quo= t;implementation over UDP", which failed to show me these cases due to= the line break *within* the phrase=C2=A0 :-)

Oh my=C2=A0 =C2=A0:)

Now I did a search for "UDP:" instead, and with that, I only find= precisely the two cases that you quote above.=C2=A0 So I think that's = it - I'll fix and submit.

Excellent= . We're already in Last Call, so no action needed from me, I think.
=C2=A0
> Thanks for chasing t= his nit with me, by the way.

No, thanks to *you* for finding and telling !

I'm glad I could help.

Spencer
=C2=A0
Cheers,
Michael

--00000000000011e82d057406f978-- From nobody Sun Aug 26 22:04:01 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 C04AD130E69; Sun, 26 Aug 2018 22:03:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: Cc: draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153534622572.11764.16971261463087249495@ietfa.amsl.com> Date: Sun, 26 Aug 2018 22:03:45 -0700 Archived-At: Subject: [Taps] Secdir last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2018 05:03:46 -0000 Reviewer: Yaron Sheffer Review result: Not Ready The whole notion of TAPS is new to me, so I may be missing the point here. This document defines a minimal set of network APIs that should be available to applications, in order to allow multiple different transport protocols to be used as interchangeable plug-ins with minimal or no change to applications. However the document does not cover security, and instead refers readers to a security protocol survey (draft-ietf-taps-transport-security). There's a disconnect here: in many cases we want applications to be aware of security features. For example, a typical TCP-using application should choose whether to enable TLS encryption of the connection (or as a receiver, whether to require encryption), and if TLS is selected, should at the very least receive access to the authenticated address of the connection's peer. In other words, a meaningful minimal set of APIs cannot be defined without considering the effects and requirements of security protocols. Put differently, the application normally treats the transport protocol and the security protocol layered on it as one protocol. Hence the old name of TLS: Secure Socket Layer. The application sees a single socket, not one socket for transport and another for security. This has been the case for TCP for the last 20-odd years, and is unlikely to change any time soon. I have not surveyed the protocols discussed in this draft, and I don't know whether a viable transport-level security protocol exists for each of them. If this is not the case, then I guess the industry is not yet ready for the kind of solution proposed here. From nobody Mon Aug 27 08:53:40 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 0542D130E06; Mon, 27 Aug 2018 08:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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_NONE=-0.0001, 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 M9sc1t_fqbpV; Mon, 27 Aug 2018 08:53:22 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 F0648124C04; Mon, 27 Aug 2018 08:53:18 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w7RFq5Ie025250; Mon, 27 Aug 2018 08:53:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=ROZI3Odd4tmwNnZ+nqorC2+13ZVhYV7P7Hcah4MGPSc=; b=OcfQ9rklCMw+FDBBdJFhEiNUmJGClwF8tQY2jJMyV9GeZ9FmvGC6/lznSjTMPMbdv9c6 NlnUZLoqJRCGYb15X+AbeR0wgG8vfK42lEef4VS0/PtKT2+fhvnzpZwbd7vp1ESLPpYd Ciq3Y7ikG3BUijNnctiILL/tjQJM2PS6MqyRqYo1KezAnLWYFBxYknxCMaO7IgeI9lIc p1uJ8KbKy5d126ohgccnFxKqSNqXxbDiQIlW/ctKMsnHcCbFoMFG4TUqBzlr1zMiKKHo vgctu3wrp3o7aSOocRe0a0OBNhV8FVsZr3IIPQpUUDwrFZmIiYNT8715CMSAbxqTxhxV Yw== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp02.apple.com with ESMTP id 2m33pk4mbe-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 Aug 2018 08:53:18 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PE4006F7MST6H90@ma1-mtap-s02.corp.apple.com>; Mon, 27 Aug 2018 08:53:17 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PE400900LSPQ900@nwk-mmpp-sz13.apple.com>; Mon, 27 Aug 2018 08:53:17 -0700 (PDT) X-Va-A: X-Va-T-CD: c3998f68f5443d99dad98dff2fd2f9f7 X-Va-E-CD: cbfa0b2259f11418691e1c39b70cf19c X-Va-R-CD: 8b3096eb4796fec17348c9603c905ec8 X-Va-CD: 0 X-Va-ID: d09a0160-010d-4011-b194-829eeaf178bd X-V-A: X-V-T-CD: c3998f68f5443d99dad98dff2fd2f9f7 X-V-E-CD: cbfa0b2259f11418691e1c39b70cf19c X-V-R-CD: 8b3096eb4796fec17348c9603c905ec8 X-V-CD: 0 X-V-ID: 10a73a85-f8e7-4f70-b28d-c956685972b0 Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PE400900LS0MJ00@nwk-mmpp-sz13.apple.com>; Mon, 27 Aug 2018 08:53:16 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-27_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp14.corp.apple.com-10000_instance1 Received: from tpauly.scv.apple.com (tpauly.scv.apple.com [17.192.171.37]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PE400KZ4MSS5X10@nwk-mmpp-sz13.apple.com>; Mon, 27 Aug 2018 08:53:16 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <153534622572.11764.16971261463087249495@ietfa.amsl.com> Date: Mon, 27 Aug 2018 08:53:16 -0700 Cc: secdir@ietf.org, draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, taps@ietf.org Message-id: <11A6EDDC-06EE-47E5-B61B-ED6F7B5999A6@apple.com> References: <153534622572.11764.16971261463087249495@ietfa.amsl.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3445.100.21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-27_06:, , signatures=0 Archived-At: Subject: Re: [Taps] Secdir last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 15:53:24 -0000 Hi Yaron, This minimal set is a description of the surface that any generic API must have to cover the common *transport* features of protocols only. This document is not meant in itself to describe an API that applications use directly, but instead describe the distilled feature set from transport services (such as reliable/unreliable sending, etc). To that end, it essentially describes what you need to be able to use basic things like TCP, UDP, etc. Even without security considered, this distillation is a non-trivial task, thus it required this document. The security document that is referenced (draft-ietf-taps-transport-security) provides a similar survey and distillation for how transport security interfaces add more surface to control and interact with handshake and record layers used on top of/in conjunction with the base transport. The set of documents that actually describe the API surface that we want applications to use (draft-ietf-taps-arch, draft-ietf-taps-api, draft-ietf-taps-interface, draft-ietf-taps-impl) does indeed provide a unified abstraction for a secure transport connection. However, this surface depends upon both the distillation from draft-ietf-taps-minset and draft-ietf-taps-transport-security. There is no intention of promoting insecure connections for applications. Thanks, Tommy > On Aug 26, 2018, at 10:03 PM, Yaron Sheffer wrote: > > Reviewer: Yaron Sheffer > Review result: Not Ready > > The whole notion of TAPS is new to me, so I may be missing the point here. This > document defines a minimal set of network APIs that should be available to > applications, in order to allow multiple different transport protocols to be > used as interchangeable plug-ins with minimal or no change to applications. > > However the document does not cover security, and instead refers readers to a > security protocol survey (draft-ietf-taps-transport-security). > > There's a disconnect here: in many cases we want applications to be aware of > security features. For example, a typical TCP-using application should choose > whether to enable TLS encryption of the connection (or as a receiver, whether > to require encryption), and if TLS is selected, should at the very least > receive access to the authenticated address of the connection's peer. In other > words, a meaningful minimal set of APIs cannot be defined without considering > the effects and requirements of security protocols. > > Put differently, the application normally treats the transport protocol and the > security protocol layered on it as one protocol. Hence the old name of TLS: > Secure Socket Layer. The application sees a single socket, not one socket for > transport and another for security. This has been the case for TCP for the last > 20-odd years, and is unlikely to change any time soon. > > I have not surveyed the protocols discussed in this draft, and I don't know > whether a viable transport-level security protocol exists for each of them. If > this is not the case, then I guess the industry is not yet ready for the kind > of solution proposed here. > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Aug 27 11:14: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 6FD4612785F; Mon, 27 Aug 2018 11:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 3k5qWWJmDgr5; Mon, 27 Aug 2018 11:14:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1BF26130DBE; Mon, 27 Aug 2018 11:14:52 -0700 (PDT) Received: from unescapeable.local ([47.186.18.66]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7RIEp7H055141 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 Aug 2018 13:14:51 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.18.66] claimed to be unescapeable.local To: taps@ietf.org, draft-ietf-taps-interface@ietf.org From: Robert Sparks Message-ID: <3583fc16-2bbc-4f45-b2fd-9806e04ec0d9@nostrum.com> Date: Mon, 27 Aug 2018 13:14:50 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Taps] Small suggestion (I hope it's a NIT) for the introduction X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 18:14:58 -0000 I drew the genart review for the minset document. It made me go skim most the taps docs. I spotted a small thing that I think you meant, but do not currently say. The last line of the Introduction to the interface document says "deriving ... properties and ... features from ... RFC8095 and ...minset..." I think you want to say "RFC8095, minset, and taps-transport-security" If that's not right, please tell me why (it will affect my review of minset). RjS From nobody Mon Aug 27 12:15:13 2018 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AB2130EE6; Mon, 27 Aug 2018 12:15:12 -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 LI7v8sMP7GSK; Mon, 27 Aug 2018 12:15:10 -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 E7FDF130ECE; Mon, 27 Aug 2018 12:15:09 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fuMyg-00013Z-TW; Mon, 27 Aug 2018 21:15:06 +0200 Received: from 58.116.34.95.customer.cdi.no ([95.34.116.58] helo=[10.0.0.7]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fuMyg-0001Sj-3C; Mon, 27 Aug 2018 21:15:06 +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: <3583fc16-2bbc-4f45-b2fd-9806e04ec0d9@nostrum.com> Date: Mon, 27 Aug 2018 21:15:14 +0200 Cc: "taps@ietf.org" , draft-ietf-taps-interface@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7D3F2B62-D476-44AC-B60B-463094A857F3@ifi.uio.no> References: <3583fc16-2bbc-4f45-b2fd-9806e04ec0d9@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 95.34.116.58 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.116.58; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8FD633EFEBCF0F1AFCEBBB96CF434F3E8DE8F38F Archived-At: Subject: Re: [Taps] Small suggestion (I hope it's a NIT) for the introduction X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 19:15:12 -0000 Hi, I confirm that it=E2=80=99s a nit, and I=E2=80=99ll fix it. Cheers, Michael > On Aug 27, 2018, at 8:14 PM, Robert Sparks = wrote: >=20 > I drew the genart review for the minset document. It made me go skim = most the taps docs. I spotted a small thing that I think you meant, but = do not currently say. >=20 > The last line of the Introduction to the interface document says = "deriving ... properties and ... features from ... RFC8095 and = ...minset..." >=20 > I think you want to say "RFC8095, minset, and taps-transport-security" >=20 > If that's not right, please tell me why (it will affect my review of = minset). >=20 > RjS >=20 From nobody Mon Aug 27 13:00:49 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 DB309130DF5; Mon, 27 Aug 2018 13:00:34 -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 XgpTwQabO3pT; Mon, 27 Aug 2018 13:00:32 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 12559130DEA; Mon, 27 Aug 2018 13:00:31 -0700 (PDT) X-AuditID: 12074422-6f9ff7000000088b-33-5b84585c4782 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 91.D3.02187.D58548B5; Mon, 27 Aug 2018 16:00:30 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w7RK0Nmm018792; Mon, 27 Aug 2018 16:00:25 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w7RK0JaK028926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Aug 2018 16:00:21 -0400 Date: Mon, 27 Aug 2018 15:00:19 -0500 From: Benjamin Kaduk To: Tommy Pauly Cc: Yaron Sheffer , taps@ietf.org, draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, secdir@ietf.org Message-ID: <20180827200019.GW59914@kduck.kaduk.org> References: <153534622572.11764.16971261463087249495@ietfa.amsl.com> <11A6EDDC-06EE-47E5-B61B-ED6F7B5999A6@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11A6EDDC-06EE-47E5-B61B-ED6F7B5999A6@apple.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT142LaIk2WDKFyeLd9v/sFs82zmex +LDwIYvFnRiLiScOslqsuj+D3YHNY+vJH2weO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAlfG iUPtLAU9chUfuzaxNzCek+hi5OSQEDCRmHP/BGMXIxeHkMBiJomF+76zQjgbGSW6Oo6zQDhX mSTm310F5HBwsAioSrQuCATpZhNQkWjovswMYosIKEl0rNzMDFLPLNDGKHF1WQcjSEJYwENi 690WJhCbF2jdws+z2EHmCAmUS1z5kAoRFpQ4OfMJC4jNLKAlcePfSyaQEmYBaYnl/zhAwpwC thI3tv4FmygqoCyxt+8Q+wRGgVlIumch6Z6F0L2AkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqR rqlebmaJXmpK6SZGcEi7KO1gnPjP6xCjAAejEg/vBI6WaCHWxLLiytxDjJIcTEqivCweQCG+ pPyUyozE4oz4otKc1OJDjBIczEoivHs+N0cL8aYkVlalFuXDpKQ5WJTEee/XhEcLCaQnlqRm p6YWpBbBZGU4OJQkeNPCgYYKFqWmp1akZeaUIKSZODhBhvMADe8HqeEtLkjMLc5Mh8ifYtTl +PN+6iRmIZa8/LxUKXHeMJAiAZCijNI8uDmgVCSRvb/mFaM40FvCvK9AqniAaQxu0iugJUxA S2a8agBZUpKIkJJqYJyoF7Gy58nzlXYprzJX+T/b8MWg6Ma1Td6euwPypq1v8DWf4ZvW//vT QbFbix32tW16YVVyizVbXO9WsIqFruP7lwZByvv3qW4+d+Ff5InejUxfbq28xWWkpFjN8HR3 rFNOxjeLqTnav3/OfLjKQCTu3acWG7a361T6aj8ZGgkL2LIxTwj88kuJpTgj0VCLuag4EQAu ZJpIIAMAAA== Archived-At: Subject: Re: [Taps] Secdir last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 20:00:35 -0000 On Mon, Aug 27, 2018 at 08:53:16AM -0700, Tommy Pauly wrote: > Hi Yaron, > > This minimal set is a description of the surface that any generic API must have to cover the common *transport* features of protocols only. This document is not meant in itself to describe an API that applications use directly, but instead describe the distilled feature set from transport services (such as reliable/unreliable sending, etc). To that end, it essentially describes what you need to be able to use basic things like TCP, UDP, etc. Even without security considered, this distillation is a non-trivial task, thus it required this document. > > The security document that is referenced (draft-ietf-taps-transport-security) provides a similar survey and distillation for how transport security interfaces add more surface to control and interact with handshake and record layers used on top of/in conjunction with the base transport. FWIW, I think that draft-ietf-taps-transport-security would benefit from some more attention from the security (is it ready enough to ask for an early secdir review?). I looked at bits of the -01, and though the -02 is improved in some ways, I think there are still some incorrect statements present about some of the protocols in question, etc.. Anyone from secdir interested? -Ben > The set of documents that actually describe the API surface that we want applications to use (draft-ietf-taps-arch, draft-ietf-taps-api, draft-ietf-taps-interface, draft-ietf-taps-impl) does indeed provide a unified abstraction for a secure transport connection. However, this surface depends upon both the distillation from draft-ietf-taps-minset and draft-ietf-taps-transport-security. There is no intention of promoting insecure connections for applications. > > Thanks, > Tommy > > > On Aug 26, 2018, at 10:03 PM, Yaron Sheffer wrote: > > > > Reviewer: Yaron Sheffer > > Review result: Not Ready > > > > The whole notion of TAPS is new to me, so I may be missing the point here. This > > document defines a minimal set of network APIs that should be available to > > applications, in order to allow multiple different transport protocols to be > > used as interchangeable plug-ins with minimal or no change to applications. > > > > However the document does not cover security, and instead refers readers to a > > security protocol survey (draft-ietf-taps-transport-security). > > > > There's a disconnect here: in many cases we want applications to be aware of > > security features. For example, a typical TCP-using application should choose > > whether to enable TLS encryption of the connection (or as a receiver, whether > > to require encryption), and if TLS is selected, should at the very least > > receive access to the authenticated address of the connection's peer. In other > > words, a meaningful minimal set of APIs cannot be defined without considering > > the effects and requirements of security protocols. > > > > Put differently, the application normally treats the transport protocol and the > > security protocol layered on it as one protocol. Hence the old name of TLS: > > Secure Socket Layer. The application sees a single socket, not one socket for > > transport and another for security. This has been the case for TCP for the last > > 20-odd years, and is unlikely to change any time soon. > > > > I have not surveyed the protocols discussed in this draft, and I don't know > > whether a viable transport-level security protocol exists for each of them. If > > this is not the case, then I guess the industry is not yet ready for the kind > > of solution proposed here. > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > From nobody Mon Aug 27 13:02: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 6A981130EFC; Mon, 27 Aug 2018 13:01: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 SSwry7muSjZh; Mon, 27 Aug 2018 13:01:52 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 81595130F04; Mon, 27 Aug 2018 13:01:52 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id g197-v6so161708qke.5; Mon, 27 Aug 2018 13:01:52 -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=sPfHCmg76VAZrqG+BWy0l94A7ko2eleyw+FXE89kV5M=; b=cgIuJIwBGGAs8JO8CKVIC1u7UgpLnVBRFBg4fpupBmNuvbRPsWW0dp4JPMXWJcgbMC OdP9TrKuTQtP91hH4f7n96tb1MYFfChU7ou22AW/1QLNUMVqihv0FY7P1kNR8WtpMN3O GO8L61Zc5Q9JThB3gPGsYCBRePNDsZDV1yj3WQTbSUVwfLyZNJw9abQft6EyJMFdKATR 5XQdg0i0/8PRylJYZedN/tWpx8ULsjsIkGB8y+NiRkUQKv8S4mWXdGU1su/lO4FZgWlE XpN+zrEX/Ed20oUkgZdns+0S3Am8fHKsz2VZ3WqyJ7aINmNax5LSkj8DZzHcblFjaiQt 6n1A== 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=sPfHCmg76VAZrqG+BWy0l94A7ko2eleyw+FXE89kV5M=; b=kxjs86mSZIoKDm1EE9G4GrDX1wFJZX7ch58LZlj9rM6r9ENx/3+rKDWyR5qleJW8eB 2Du3GVYoS9PCQgALGY8Q1Bd2hAeSKzdpm9C0kAg1fewGNO9GCP0siX1NDPbzFrG8eN4X D8tebZT/PzD2OVq7FIRUJsh7/j7vXcPvtB5JrUpYS0TEzk92KIOG7SkSBr50Jgrlil6p opsIzgbTrbrRjiYa+Okd3DVh1UPzcULaS0nz1sfA/ogil8I7aHuxC7rC5smKNupxmHaj /pApT/PLZXAz5RHPRafM9r7D1v8wc1jzqCtGINqXfjsgv9i8pWkr8fe4WAajj35hnz+E fdmw== X-Gm-Message-State: APzg51DVAWqesSmajvk8Q/L9P7JfWE42wqXPj+X3URRtsD3kRKSMhNdE xPLEJ3z2UhLyfhB+FValzuc= X-Google-Smtp-Source: ANB0VdZtvWah34ynP4N+MQQjrhPP9XAp4kEmUJAVJpwaokWQiskfNnVsqrQKLXCeEupzrnfZe5iX2Q== X-Received: by 2002:a37:8542:: with SMTP id h63-v6mr14836364qkd.307.1535400111330; Mon, 27 Aug 2018 13:01:51 -0700 (PDT) Received: from [172.19.37.217] ([2601:184:4980:a321:8d9d:417f:9ca0:8d3c]) by smtp.gmail.com with ESMTPSA id a26-v6sm99003qtc.74.2018.08.27.13.01.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 13:01:50 -0700 (PDT) From: "Aaron Falk" To: "Benjamin Kaduk" Cc: "Tommy Pauly" , "Yaron Sheffer" , taps@ietf.org, draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, secdir@ietf.org Date: Mon, 27 Aug 2018 16:01:47 -0400 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: <20180827200019.GW59914@kduck.kaduk.org> References: <153534622572.11764.16971261463087249495@ietfa.amsl.com> <11A6EDDC-06EE-47E5-B61B-ED6F7B5999A6@apple.com> <20180827200019.GW59914@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_7EFFFC0B-70AE-430C-9D96-D832BCC85B63_=" Archived-At: Subject: Re: [Taps] Secdir last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 27 Aug 2018 20:02:00 -0000 --=_MailMate_7EFFFC0B-70AE-430C-9D96-D832BCC85B63_= Content-Type: text/plain; format=flowed My $0.02: I don't think it is too early for a SecDir review. --aaron (TAPS wg chair) On 27 Aug 2018, at 16:00, Benjamin Kaduk wrote: > On Mon, Aug 27, 2018 at 08:53:16AM -0700, Tommy Pauly wrote: >> Hi Yaron, >> >> This minimal set is a description of the surface that any generic API >> must have to cover the common *transport* features of protocols only. >> This document is not meant in itself to describe an API that >> applications use directly, but instead describe the distilled feature >> set from transport services (such as reliable/unreliable sending, >> etc). To that end, it essentially describes what you need to be able >> to use basic things like TCP, UDP, etc. Even without security >> considered, this distillation is a non-trivial task, thus it required >> this document. >> >> The security document that is referenced >> (draft-ietf-taps-transport-security) provides a similar survey and >> distillation for how transport security interfaces add more surface >> to control and interact with handshake and record layers used on top >> of/in conjunction with the base transport. > > FWIW, I think that draft-ietf-taps-transport-security would benefit > from > some more attention from the security (is it ready enough to ask for > an > early secdir review?). I looked at bits of the -01, and though the > -02 is > improved in some ways, I think there are still some incorrect > statements > present about some of the protocols in question, etc.. Anyone from > secdir > interested? > > -Ben > >> The set of documents that actually describe the API surface that we >> want applications to use (draft-ietf-taps-arch, draft-ietf-taps-api, >> draft-ietf-taps-interface, draft-ietf-taps-impl) does indeed provide >> a unified abstraction for a secure transport connection. However, >> this surface depends upon both the distillation from >> draft-ietf-taps-minset and draft-ietf-taps-transport-security. There >> is no intention of promoting insecure connections for applications. >> >> Thanks, >> Tommy >> >>> On Aug 26, 2018, at 10:03 PM, Yaron Sheffer >>> wrote: >>> >>> Reviewer: Yaron Sheffer >>> Review result: Not Ready >>> >>> The whole notion of TAPS is new to me, so I may be missing the point >>> here. This >>> document defines a minimal set of network APIs that should be >>> available to >>> applications, in order to allow multiple different transport >>> protocols to be >>> used as interchangeable plug-ins with minimal or no change to >>> applications. >>> >>> However the document does not cover security, and instead refers >>> readers to a >>> security protocol survey (draft-ietf-taps-transport-security). >>> >>> There's a disconnect here: in many cases we want applications to be >>> aware of >>> security features. For example, a typical TCP-using application >>> should choose >>> whether to enable TLS encryption of the connection (or as a >>> receiver, whether >>> to require encryption), and if TLS is selected, should at the very >>> least >>> receive access to the authenticated address of the connection's >>> peer. In other >>> words, a meaningful minimal set of APIs cannot be defined without >>> considering >>> the effects and requirements of security protocols. >>> >>> Put differently, the application normally treats the transport >>> protocol and the >>> security protocol layered on it as one protocol. Hence the old name >>> of TLS: >>> Secure Socket Layer. The application sees a single socket, not one >>> socket for >>> transport and another for security. This has been the case for TCP >>> for the last >>> 20-odd years, and is unlikely to change any time soon. >>> >>> I have not surveyed the protocols discussed in this draft, and I >>> don't know >>> whether a viable transport-level security protocol exists for each >>> of them. If >>> this is not the case, then I guess the industry is not yet ready for >>> the kind >>> of solution proposed here. >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> --=_MailMate_7EFFFC0B-70AE-430C-9D96-D832BCC85B63_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">My $0.02: I don't think it is too early for a SecDir revi= ew. --aaron (TAPS wg chair)

On 27 Aug 2018, at 16:00, Benjamin Kaduk wrote:

On Mon, Aug 27, 2018 at 08:53:16AM = -0700, Tommy Pauly wrote:

Hi Yaron,
This minimal set is a description of the surface that any generic API mus= t have to cover the common *transport* features of protocols only. This d= ocument is not meant in itself to describe an API that applications use d= irectly, but instead describe the distilled feature set from transport se= rvices (such as reliable/unreliable sending, etc). To that end, it essent= ially describes what you need to be able to use basic things like TCP, UD= P, etc. Even without security considered, this distillation is a non-triv= ial task, thus it required this document.

The security document that is referenced (draft-ietf-taps-transport-secur= ity) provides a similar survey and distillation for how transport securit= y interfaces add more surface to control and interact with handshake and = record layers used on top of/in conjunction with the base transport.

FWIW, I think that draft-ietf-taps-transport= -security would benefit from
some more attention from the security (is it ready enough to ask for an early secdir review?). I looked at bits of the -01, and though the -02 i= s
improved in some ways, I think there are still some incorrect statements<= br> present about some of the protocols in question, etc.. Anyone from secdi= r
interested?

-Ben

The set of = documents that actually describe the API surface that we want application= s to use (draft-ietf-taps-arch, draft-ietf-taps-api, draft-ietf-taps-inte= rface, draft-ietf-taps-impl) does indeed provide a unified abstraction fo= r a secure transport connection. However, this surface depends upon both = the distillation from draft-ietf-taps-minset and draft-ietf-taps-transpor= t-security. There is no intention of promoting insecure connections for a= pplications.

Thanks,
Tommy

On Aug 26, = 2018, at 10:03 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
=
Reviewer: Yaron Sheffer
Review result: Not Ready

The whole notion of TAPS is new to me, so I may be missing the point here= =2E This
document defines a minimal set of network APIs that should be available t= o
applications, in order to allow multiple different transport protocols to= be
used as interchangeable plug-ins with minimal or no change to application= s.

However the document does not cover security, and instead refers readers = to a
security protocol survey (draft-ietf-taps-transport-security).

There's a disconnect here: in many cases we want applications to be aware= of
security features. For example, a typical TCP-using application should ch= oose
whether to enable TLS encryption of the connection (or as a receiver, whe= ther
to require encryption), and if TLS is selected, should at the very least<= br> receive access to the authenticated address of the connection's peer. In = other
words, a meaningful minimal set of APIs cannot be defined without conside= ring
the effects and requirements of security protocols.

Put differently, the application normally treats the transport protocol a= nd the
security protocol layered on it as one protocol. Hence the old name of TL= S:
Secure Socket Layer. The application sees a single socket, not one socket= for
transport and another for security. This has been the case for TCP for th= e last
20-odd years, and is unlikely to change any time soon.

I have not surveyed the protocols discussed in this draft, and I don't kn= ow
whether a viable transport-level security protocol exists for each of the= m. If
this is not the case, then I guess the industry is not yet ready for the = kind
of solution proposed here.

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

--=_MailMate_7EFFFC0B-70AE-430C-9D96-D832BCC85B63_=-- From nobody Mon Aug 27 23:39:51 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 12A22130DEC; Mon, 27 Aug 2018 23:39:36 -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, 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 2tbjPwE3_p7r; Mon, 27 Aug 2018 23:39:34 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 31D3D130DDB; Mon, 27 Aug 2018 23:39:34 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id z25-v6so306434pgu.7; Mon, 27 Aug 2018 23:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+z5V0AFLi8r96xHmkKJSO4q+GUPsFJCQjrrQQPBqC04=; b=jA1MV7GucB4bICQcd+ENQs5ZJBswv4ULx4998/lcYon9ml1ydsVF8ihP4VBnnlS6Ec 1ptXj13r8rc9KucAJS8k0fe9BrYtRRWyI2U4zQrJZbEoa865HZB40vfY+Tqx8DAOjlbz gVY8uk+MGPp5oEH+qlwstlHHEQTREzMJh6lltRsXgclP64xyBOwi1R1rjjTv+zcdF5rE OVBPXnPoQ1zYYC7uSxywwS8jO2AvsQBogQYWasnCpwpogTb4JxbtdiOBtIYNn//MUjl+ 9czvLrrGhibvT8f1tD+ifBWiPkd+x/9CwyYxgxX8RVeHYE0Cbo93Wm8B3dHym4Dozufs fMdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+z5V0AFLi8r96xHmkKJSO4q+GUPsFJCQjrrQQPBqC04=; b=cPsTZ7a/1N9WpTzkmtSAJIHsLrRwAqxL8t4wMP7uNSOLuQFoJI82dgmA/wqlwu25/s qTdUPVCTcSp8o4veZDwPIi0XnhTfhofNWsT8gp+TVx8POY5iAZx0a7aKrsno7YctALyM maUhjKu5DBK40GHQG2UwzevrfNJJPkfnHzGeWyLkR0kG9xXIU2pPbsVR+C8svH7zRXC8 6F1/U0k/4LxRnWilY1oC9+95v7Vor83JJRiBWJmzK1NoTD6Dg+Aw9pCVIxqoNMQhgvOR 0ZuZqXMmbtYMGsn7MrgDkpPEHLreb2ACUR1uWzkvWphuvDnP74lRVbBZujVh21chPOKl +B5g== X-Gm-Message-State: APzg51AzZ1xoOF88JFZ2HcSUdEpTA/MFKEFEecKWrm3PyTlaSzMNxDbZ OR9pTH2KHZGFJxqsRse/z5ZdlO+ZWls= X-Google-Smtp-Source: ANB0VdalwBEVwtnPw6pMFzqtQQAvyccBaPA42ZIAagkXB1QoGppmdjkA8YTnnakRrhIzKXu+zu83fg== X-Received: by 2002:a62:34c4:: with SMTP id b187-v6mr128278pfa.15.1535438373503; Mon, 27 Aug 2018 23:39:33 -0700 (PDT) Received: from [10.20.8.46] ([209.37.97.194]) by smtp.gmail.com with ESMTPSA id h10-v6sm658340pfj.78.2018.08.27.23.39.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 23:39:32 -0700 (PDT) To: Tommy Pauly Cc: secdir@ietf.org, draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, taps@ietf.org References: <153534622572.11764.16971261463087249495@ietfa.amsl.com> <11A6EDDC-06EE-47E5-B61B-ED6F7B5999A6@apple.com> From: Yaron Sheffer Message-ID: <6c3e25c8-de15-a0dd-3706-72ca47475840@gmail.com> Date: Mon, 27 Aug 2018 23:39:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <11A6EDDC-06EE-47E5-B61B-ED6F7B5999A6@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Secdir last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 28 Aug 2018 06:39:36 -0000 Thank you Tommy for setting me straight on this. I appreciate the additional context. I looked at draft-ietf-taps-interface and it does seem to cover secure connection establishment well enough. With that in mind, I am OK with the Security Considerations in draft-ietf-taps-minset. Regards, Yaron On 27/08/18 08:53, Tommy Pauly wrote: > Hi Yaron, > > This minimal set is a description of the surface that any generic API must have to cover the common *transport* features of protocols only. This document is not meant in itself to describe an API that applications use directly, but instead describe the distilled feature set from transport services (such as reliable/unreliable sending, etc). To that end, it essentially describes what you need to be able to use basic things like TCP, UDP, etc. Even without security considered, this distillation is a non-trivial task, thus it required this document. > > The security document that is referenced (draft-ietf-taps-transport-security) provides a similar survey and distillation for how transport security interfaces add more surface to control and interact with handshake and record layers used on top of/in conjunction with the base transport. > > The set of documents that actually describe the API surface that we want applications to use (draft-ietf-taps-arch, draft-ietf-taps-api, draft-ietf-taps-interface, draft-ietf-taps-impl) does indeed provide a unified abstraction for a secure transport connection. However, this surface depends upon both the distillation from draft-ietf-taps-minset and draft-ietf-taps-transport-security. There is no intention of promoting insecure connections for applications. > > Thanks, > Tommy > >> On Aug 26, 2018, at 10:03 PM, Yaron Sheffer wrote: >> >> Reviewer: Yaron Sheffer >> Review result: Not Ready >> >> The whole notion of TAPS is new to me, so I may be missing the point here. This >> document defines a minimal set of network APIs that should be available to >> applications, in order to allow multiple different transport protocols to be >> used as interchangeable plug-ins with minimal or no change to applications. >> >> However the document does not cover security, and instead refers readers to a >> security protocol survey (draft-ietf-taps-transport-security). >> >> There's a disconnect here: in many cases we want applications to be aware of >> security features. For example, a typical TCP-using application should choose >> whether to enable TLS encryption of the connection (or as a receiver, whether >> to require encryption), and if TLS is selected, should at the very least >> receive access to the authenticated address of the connection's peer. In other >> words, a meaningful minimal set of APIs cannot be defined without considering >> the effects and requirements of security protocols. >> >> Put differently, the application normally treats the transport protocol and the >> security protocol layered on it as one protocol. Hence the old name of TLS: >> Secure Socket Layer. The application sees a single socket, not one socket for >> transport and another for security. This has been the case for TCP for the last >> 20-odd years, and is unlikely to change any time soon. >> >> I have not surveyed the protocols discussed in this draft, and I don't know >> whether a viable transport-level security protocol exists for each of them. If >> this is not the case, then I guess the industry is not yet ready for the kind >> of solution proposed here. >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > From nobody Tue Aug 28 14:38:54 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 9EC6E130F4C; Tue, 28 Aug 2018 14:38:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks To: Cc: draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153549231960.6181.5129820855641929896@ietfa.amsl.com> Date: Tue, 28 Aug 2018 14:38:39 -0700 Archived-At: Subject: [Taps] Genart last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2018 21:38:40 -0000 Reviewer: Robert Sparks Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-taps-minset-06 Reviewer: Robert Sparks Review Date: 2018-08-28 IETF LC End Date: 2018-09-04 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as an Informational RFC, but with nits to consider before publication. I had to read quite a bit more than just RFC8303 to understand what this document has to say. I suggest moving at least the transport- security document to normative, and probably also RFC8095. This was a big effort, and it appears that it was helpful to the folks working on the interface document, but it's not clear how it will be useful to implementers. The IESG should consider whether this, like requirements documents, needs to be in the RFC series. The most likely use I can see in the future would be for historians, and a different and shorter presentation would serve them better. If it proceeds to publication, consider the following nits: The conclusion (section 4) would be more useful if it were moved to the introduction (it says things more clearly than the introduction does now). Please check with the RFC Editor early about whether the [COBS] reference is sufficiently stable. And a couple of questions about the larger work for the group: The capacity profile concept as captured in this document (page 9) says it's a number. The interface document has the concept, with an enumeration. Ultimately, this is going to require a registry, and you might consider establishing it even though the interface is still supposed to be an abstract thing. The enumeration is looking pretty concrete. In Appendix A.1, this document had to "slightly change" the characterization of features from those in RFC8303, introducing this "ADDED" construct. That feels out of balance. Is this a warning sign that RFC8303 needs adjusting? From nobody Fri Aug 31 01:11:45 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 7030D126F72; Fri, 31 Aug 2018 01:11:43 -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.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <153570310340.29281.2562997381713680037@ietfa.amsl.com> Date: Fri, 31 Aug 2018 01:11:43 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-minset-07.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2018 08:11:44 -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 Minimal Set of Transport Services for End Systems Authors : Michael Welzl Stein Gjessing Filename : draft-ietf-taps-minset-07.txt Pages : 47 Date : 2018-08-31 Abstract: This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features in RFC 8303. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-minset-07 https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-minset-07 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 Aug 31 01:37:50 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 792E912D949; Fri, 31 Aug 2018 01:37:43 -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 NxBeXcy8nvcY; Fri, 31 Aug 2018 01:37:41 -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 D1FA5128CF3; Fri, 31 Aug 2018 01:37:40 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fvevx-0001vp-9o; Fri, 31 Aug 2018 10:37:37 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx12.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fvevv-0006BX-98; Fri, 31 Aug 2018 10:37:37 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: <153549231960.6181.5129820855641929896@ietfa.amsl.com> Date: Fri, 31 Aug 2018 10:37:32 +0200 Cc: gen-art@ietf.org, draft-ietf-taps-minset.all@ietf.org, ietf@ietf.org, taps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <526D1CA4-DD3D-4AEE-8B92-B120A6798C53@ifi.uio.no> References: <153549231960.6181.5129820855641929896@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; 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: 5ED5FBDC2DFA22F60583460063FA5F5E3FC2575A Archived-At: Subject: Re: [Taps] Genart last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 31 Aug 2018 08:37:43 -0000 Hi, Thank you very much for this careful review! We just posted a revision = ( -07 ) that, we believe, addresses these comments. A few answers in line below: > On 28 Aug 2018, at 23:38, Robert Sparks wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-taps-minset-06 > Reviewer: Robert Sparks > Review Date: 2018-08-28 > IETF LC End Date: 2018-09-04 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready for publication as an Informational RFC, but with nits > to consider before publication. >=20 > I had to read quite a bit more than just RFC8303 to understand what > this document has to say. I suggest moving at least the transport- > security document to normative, and probably also RFC8095. Done; > This was a big effort, and it appears that it was helpful to the folks > working on the interface document, but it's not clear how it will be > useful to implementers. The IESG should consider whether this, like > requirements documents, needs to be in the RFC series. The most likely > use I can see in the future would be for historians, and a different > and shorter presentation would serve them better. I beg to differ :) As much as I'd wish for that to happen, it would certainly be naive to = believe that all the world is going to switch to the new and shiny TAPS = API that is currently being defined. There will always be higher-level APIs that follow their own design. We = (authors) believe that the value of the minset document, aside from = helping the TAPS design process, is to give implementers of such = higher-level APIs advice on services that they should include (and may = so far not have thought about). =46rom the introduction: *** ... The transport features in the minimal set in this document must be reflected in *all* network APIs in order for the underlying functionality to become usable everywhere. For example, it does not help an application that talks to a library which offers its own communication interface if the underlying Berkeley Sockets API is extended to offer "unordered message delivery", but the library only exposes an ordered bytestream. Both the Berkeley Sockets API and the library would have to expose the "unordered message delivery" transport feature ... *** > If it proceeds to publication, consider the following nits: >=20 > The conclusion (section 4) would be more useful if it were moved to > the introduction (it says things more clearly than the introduction > does now). Done. This replaces a paragraph in the introduction that essentially = said the same thing as the conclusion did, but with clumsy language - so = thanks, that was very useful! > Please check with the RFC Editor early about whether the [COBS] > reference is sufficiently stable. Thanks again: it probably wasn't, and now it is - we missed to include = the seriesinfo tag that points at the Transactions on Networking = journal. > And a couple of questions about the larger work for the group: >=20 > The capacity profile concept as captured in this document (page 9) > says it's a number. The interface document has the concept, with an > enumeration. Ultimately, this is going to require a registry, and you > might consider establishing it even though the interface is still > supposed to be an abstract thing. The enumeration is looking pretty > concrete. There is an ongoing discussion about "To registry, or not to registry?" = in the TAPS list - not just about the capacity profile though. Here's = the thread: https://www.ietf.org/mail-archive/web/taps/current/msg01410.html > In Appendix A.1, this document had to "slightly change" the > characterization of features from those in RFC8303, introducing this > "ADDED" construct. That feels out of balance. Is this a warning sign > that RFC8303 needs adjusting? It isn't: different from this document, RFC 8303 does not make any = changes or derive anything from the services that protocols offer - it = just reflects what the protocol specifications say. In the minset document, there are only 3 items using the "ADDED" = construct, and this is only meant to streamline the derivation a little. = Take "Unreliably transfer a message", for example. This is based on (from RFC 8303) "Unreliably transfer a message, with = congestion control" for SCTP, and "Unreliably transfer a message, = without congestion control" for UDP(-Lite). The added "Unreliably = transfer a message" leaves the choice of congestion control open, such = that an application CAN simply say "Unreliably transfer a message" = without having to care about the choice of congestion control (unless it = wants to care, which comes at the cost of binding itself to either = UDP(-Lite) or SCTP). Cheers, Michael From nobody Fri Aug 31 10:42: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 2DB6B1294D7; Fri, 31 Aug 2018 10:42:13 -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, 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 FtHCehgqOMxm; Fri, 31 Aug 2018 10:42:11 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 E534D128CFD; Fri, 31 Aug 2018 10:42:10 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id y20-v6so1159370ybi.13; Fri, 31 Aug 2018 10:42:10 -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=Lc1McrUTQQ7JZeS537DgngCPZ9IiqWnOO/Op5WAA9eM=; b=O49FezoIYtSqOsEldK9gBVE0BQe032HbWq6DARPOvVNSaBQRF3vbRqYrRmAVXJ5Tgs YrwCLhfLQf14Ee1BoS+Ldsvjq5pPwbasiCpbVObHNJ4TE4I9kT4Bp9m4Yf55nJbeoqO+ 6Yw+6J/gcTygjyGcErZQC3OiI3Lg4jbjdV4br5vbaCjHXzgngdmhBTxp319QqtDLcMeN twhnC6JgI2vld7z+7I9nkXrLjpWRU0zEQvVPGJL3YqeqsTY17USjUXAUveckGv71SJMV iruZsseymW9ajj25eeMYnFFP1x6IhgsHM/9c76I5GNqbFUr0VfVae1vcqRaj2Q4ONpyY fl7Q== 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=Lc1McrUTQQ7JZeS537DgngCPZ9IiqWnOO/Op5WAA9eM=; b=XsBu8R5Wjq8GVF9MXdxK5uG9rN4Z5tpX+FTUWhF36QYcegmSQJltR1plUpvd3ikTO2 wX+r29QiKMyNfGpQCrXWMMWXeE2wQFiYG12dwAXqoe63UYRYxmV/kerP70kt0fwL7F3v 0py9JQW6r8jKAxLeQNOP8YLm5Qyb+tKXCmTC4ugFMEIX1sBV7tHeRIpgElims3scUFjh 86mMQ7GqCtUn5M4l4ylzCsGchovsDw5TnI3mIep04yPVTd3mqwdIXgkH46sd/8L6JPdp 3yQZ34P96V9iMucxqYIVGcYiy/jP83k2mKR0K74SFZSc9x8iqIxkx9eM71s9rVX6+EHU g37A== X-Gm-Message-State: APzg51Cm9h5JttlAu+o03CA3uYOvkfDuVFwxYmZB6QFgID3lVNHlg/G7 yFJKRM+Yc2eP0FVnAMVnCY75ZqrZ+H6UQVHdRJlICQ== X-Google-Smtp-Source: ANB0VdZlDWC6VUROYpwl/fz/f+imNYmR6lSfDxM6Qyaz7QYV40xnOLXZzsoDQPgBHiZfhdZJjBVskqn6Kcau907G0Gk= X-Received: by 2002:a25:570b:: with SMTP id l11-v6mr9198337ybb.490.1535737329623; Fri, 31 Aug 2018 10:42:09 -0700 (PDT) MIME-Version: 1.0 References: <153549231960.6181.5129820855641929896@ietfa.amsl.com> <526D1CA4-DD3D-4AEE-8B92-B120A6798C53@ifi.uio.no> In-Reply-To: <526D1CA4-DD3D-4AEE-8B92-B120A6798C53@ifi.uio.no> From: Spencer Dawkins at IETF Date: Fri, 31 Aug 2018 12:41:57 -0500 Message-ID: To: Michael Welzl Cc: Robert Sparks , gen-art , draft-ietf-taps-minset.all@ietf.org, IETF list , taps WG Content-Type: multipart/alternative; boundary="0000000000000026b70574beb689" Archived-At: Subject: Re: [Taps] Genart last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 31 Aug 2018 17:42:13 -0000 --0000000000000026b70574beb689 Content-Type: text/plain; charset="UTF-8" Thanks, Robert, for the careful read, and thanks, Michael, for the quick response. I have one thought, on Robert's last question. On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl wrote: > Hi, > > Thank you very much for this careful review! We just posted a revision ( > -07 ) that, we believe, addresses these comments. > > A few answers in line below: > > > On 28 Aug 2018, at 23:38, Robert Sparks wrote: > > > > Reviewer: Robert Sparks > > Review result: Ready with Nits ... > > In Appendix A.1, this document had to "slightly change" the > > characterization of features from those in RFC8303, introducing this > > "ADDED" construct. That feels out of balance. Is this a warning sign > > that RFC8303 needs adjusting? > > It isn't: different from this document, RFC 8303 does not make any changes > or derive anything from the services that protocols offer - it just > reflects what the protocol specifications say. > > In the minset document, there are only 3 items using the "ADDED" > construct, and this is only meant to streamline the derivation a little. > Take "Unreliably transfer a message", for example. > This is based on (from RFC 8303) "Unreliably transfer a message, with > congestion control" for SCTP, and "Unreliably transfer a message, without > congestion control" for UDP(-Lite). The added "Unreliably transfer a > message" leaves the choice of congestion control open, such that an > application CAN simply say "Unreliably transfer a message" without having > to care about the choice of congestion control (unless it wants to care, > which comes at the cost of binding itself to either UDP(-Lite) or SCTP). > Michael, this explanation helps a lot, but since I happen to know that Robert is out of town for the three-day weekend in the US, I'll guess on his behalf that "ADDED" may not be the word you're looking for - at a minimum, "transfer unreliably" in RFC 8303 being divided into "transfer unreliably with congestion control" and "transfer unreliably without congestion control" in this draft doesn't look like addition to me. Is this more about "refactoring the protocol-independent definition in RFC 8303"? But, whatever it is, if you two can figure out how to describe what's happening, that will probably help figure you and Robert agree on an understanding about how to handle his comment. Spencer --0000000000000026b70574beb689 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Robert, for the careful read, and thanks, Michael,= for the quick response. I have one thought, on Robert's last question.=

On Fri, Aug 31, 2018 a= t 3:37 AM Michael Welzl <michawe@i= fi.uio.no> wrote:
Hi,

Thank you very much for this careful review!=C2=A0 We just posted a revisio= n ( -07 ) that, we believe, addresses these comments.

A few answers in line below:

> On 28 Aug 2018, at 23:38, Robert Sparks <rjsparks@nostrum.com> wrote:
>
> Reviewer: Robert Sparks
> Review result: Ready with Nits

...
=C2=A0
> In Appendix A.1, thi= s document had to "slightly change" the
> characterization of features=C2=A0 from those in RFC8303, introducing = this
> "ADDED" construct. That feels out of balance. Is this a warn= ing sign
> that RFC8303 needs adjusting?

It isn't: different from this document, RFC 8303 does not make any chan= ges or derive anything from the services that protocols offer - it just ref= lects what the protocol specifications say.

In the minset document, there are only 3 items using the "ADDED" = construct, and this is only meant to streamline the derivation a little. Ta= ke "Unreliably transfer a message", for example.
This is based on (from RFC 8303) "Unreliably transfer a message, with = congestion control" for SCTP, and "Unreliably transfer a message,= without congestion control" for UDP(-Lite). The added "Unreliabl= y transfer a message" leaves the choice of congestion control open, su= ch that an application CAN simply say "Unreliably transfer a message&q= uot; without having to care about the choice of congestion control (unless = it wants to care, which comes at the cost of binding itself to either UDP(-= Lite) or SCTP).

Michael, this explanati= on helps a lot, but since I happen to know that Robert is out of town for t= he three-day weekend in the US, I'll guess on his behalf that "ADD= ED" may not be the word you're looking for - at a minimum, "t= ransfer unreliably" in RFC 8303 being divided into "transfer unre= liably with congestion control" and "transfer unreliably without = congestion control" in this draft doesn't look like addition to me= .=C2=A0

Is this more about "refactoring the p= rotocol-independent definition in RFC 8303"?=C2=A0

But, whatever it is, if you two can figure out how to describe what&#= 39;s happening, that will probably help figure you and Robert agree on an u= nderstanding about how to handle his comment.

Spen= cer
--0000000000000026b70574beb689-- From nobody Fri Aug 31 13:36:11 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 5C409130E06; Fri, 31 Aug 2018 13:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lT82vOoNGllo; Fri, 31 Aug 2018 13:35:50 -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 9E9B5124C04; Fri, 31 Aug 2018 13:35:49 -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 1fvq8w-0001n1-8m; Fri, 31 Aug 2018 22:35:46 +0200 Received: from 58.116.34.95.customer.cdi.no ([95.34.116.58] helo=[10.0.0.7]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1fvq8u-0001Yz-FZ; Fri, 31 Aug 2018 22:35:46 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A667823C-F7D9-43E6-9101-65845B07FFD5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 31 Aug 2018 22:35:53 +0200 In-Reply-To: Cc: Robert Sparks , gen-art , draft-ietf-taps-minset.all@ietf.org, IETF list , "taps@ietf.org" To: Spencer Dawkins References: <153549231960.6181.5129820855641929896@ietfa.amsl.com> <526D1CA4-DD3D-4AEE-8B92-B120A6798C53@ifi.uio.no> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 95.34.116.58 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.116.58; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.000, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 76B406DD637EDE13551BFE1AA0D0DD4B60AA45E3 Archived-At: Subject: Re: [Taps] Genart last call review of draft-ietf-taps-minset-06 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.27 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, 31 Aug 2018 20:35:54 -0000 --Apple-Mail=_A667823C-F7D9-43E6-9101-65845B07FFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Spencer, See below: > On Aug 31, 2018, at 7:41 PM, Spencer Dawkins at IETF = wrote: >=20 > Thanks, Robert, for the careful read, and thanks, Michael, for the = quick response. I have one thought, on Robert's last question. >=20 > On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl > wrote: > Hi, >=20 > Thank you very much for this careful review! We just posted a = revision ( -07 ) that, we believe, addresses these comments. >=20 > A few answers in line below: >=20 > > On 28 Aug 2018, at 23:38, Robert Sparks > wrote: > >=20 > > Reviewer: Robert Sparks > > Review result: Ready with Nits >=20 > ... > =20 > > In Appendix A.1, this document had to "slightly change" the > > characterization of features from those in RFC8303, introducing = this > > "ADDED" construct. That feels out of balance. Is this a warning sign > > that RFC8303 needs adjusting? >=20 > It isn't: different from this document, RFC 8303 does not make any = changes or derive anything from the services that protocols offer - it = just reflects what the protocol specifications say. >=20 > In the minset document, there are only 3 items using the "ADDED" = construct, and this is only meant to streamline the derivation a little. = Take "Unreliably transfer a message", for example. > This is based on (from RFC 8303) "Unreliably transfer a message, with = congestion control" for SCTP, and "Unreliably transfer a message, = without congestion control" for UDP(-Lite). The added "Unreliably = transfer a message" leaves the choice of congestion control open, such = that an application CAN simply say "Unreliably transfer a message" = without having to care about the choice of congestion control (unless it = wants to care, which comes at the cost of binding itself to either = UDP(-Lite) or SCTP). >=20 > Michael, this explanation helps a lot, but since I happen to know that = Robert is out of town for the three-day weekend in the US, I'll guess on = his behalf that "ADDED" may not be the word you're looking for - at a = minimum, "transfer unreliably" in RFC 8303 being divided into "transfer = unreliably with congestion control" and "transfer unreliably without = congestion control" in this draft doesn't look like addition to me.=20 >=20 > Is this more about "refactoring the protocol-independent definition in = RFC 8303=E2=80=9D?=20 Yes, =E2=80=9Crefactoring=E2=80=9D is exactly right - it=E2=80=99s not = adding anything new. We could just as well have left this without the = =E2=80=9CADDED=E2=80=9D cases and then had more explanations in the = =E2=80=9Cdiscussions=E2=80=9D section (appendix A.3), but these are so = minor that they don=E2=80=99t really merit a =E2=80=9Cdiscussion=E2=80=9D,= hence we felt that this way it=E2=80=99s shorter and clearer. If that helps, I can rename =E2=80=9CADDED=E2=80=9D into = =E2=80=9CREFACTORED=E2=80=9D? Cheers, Michael > But, whatever it is, if you two can figure out how to describe what's = happening, that will probably help figure you and Robert agree on an = understanding about how to handle his comment. >=20 > Spencer --Apple-Mail=_A667823C-F7D9-43E6-9101-65845B07FFD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Spencer,

See below:

On Aug 31, 2018, at 7:41 PM, = Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Thanks, Robert, for the careful read, and thanks, Michael, = for the quick response. I have one thought, on Robert's last = question.

On Fri, Aug 31, 2018 at 3:37 AM Michael Welzl = <michawe@ifi.uio.no> wrote:
Hi,

Thank you very much for this careful review!  We just posted a = revision ( -07 ) that, we believe, addresses these comments.

A few answers in line below:

> On 28 Aug 2018, at 23:38, Robert Sparks <rjsparks@nostrum.com> wrote:
>
> Reviewer: Robert Sparks
> Review result: Ready with Nits

...
 
> In Appendix = A.1, this document had to "slightly change" the
> characterization of features  from those in RFC8303, = introducing this
> "ADDED" construct. That feels out of balance. Is this a warning = sign
> that RFC8303 needs adjusting?

It isn't: different from this document, RFC 8303 does not make any = changes or derive anything from the services that protocols offer - it = just reflects what the protocol specifications say.

In the minset document, there are only 3 items using the "ADDED" = construct, and this is only meant to streamline the derivation a little. = Take "Unreliably transfer a message", for example.
This is based on (from RFC 8303) "Unreliably transfer a message, with = congestion control" for SCTP, and "Unreliably transfer a message, = without congestion control" for UDP(-Lite). The added "Unreliably = transfer a message" leaves the choice of congestion control open, such = that an application CAN simply say "Unreliably transfer a message" = without having to care about the choice of congestion control (unless it = wants to care, which comes at the cost of binding itself to either = UDP(-Lite) or SCTP).

Michael, this explanation helps a lot, = but since I happen to know that Robert is out of town for the three-day = weekend in the US, I'll guess on his behalf that "ADDED" may not be the = word you're looking for - at a minimum, "transfer unreliably" in RFC = 8303 being divided into "transfer unreliably with congestion control" = and "transfer unreliably without congestion control" in this draft = doesn't look like addition to me. 

Is this more about "refactoring the = protocol-independent definition in RFC = 8303=E2=80=9D? 

Yes, =E2=80=9Crefactoring=E2=80=9D is exactly = right - it=E2=80=99s not adding anything new. We could just as well have = left this without the =E2=80=9CADDED=E2=80=9D cases and then had more = explanations in the =E2=80=9Cdiscussions=E2=80=9D section (appendix = A.3), but these are so minor that they don=E2=80=99t really merit a = =E2=80=9Cdiscussion=E2=80=9D, hence we felt that this way it=E2=80=99s = shorter and clearer.

If that helps, I can = rename =E2=80=9CADDED=E2=80=9D into =E2=80=9CREFACTORED=E2=80=9D?

Cheers,
Michael


But, whatever it = is, if you two can figure out how to describe what's happening, that = will probably help figure you and Robert agree on an understanding about = how to handle his comment.

Spencer

= --Apple-Mail=_A667823C-F7D9-43E6-9101-65845B07FFD5--