From nobody Wed Apr 5 05:42:32 2017 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 60657127B57; Wed, 5 Apr 2017 05:42:24 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149139614433.1088.2745472070150554963@ietfa.amsl.com> Date: Wed, 05 Apr 2017 05:42:24 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:42:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : On the Usage of Transport Features Provided by IETF Transport Protocols Authors : Michael Welzl Michael Tuexen Naeem Khademi Filename : draft-ietf-taps-transports-usage-04.txt Pages : 49 Date : 2017-04-05 Abstract: This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite expose services to applications and how an application can configure and use the transport features that make up these services. It also discusses the service provided by the LEDBAT congestion control mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-04 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-04 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 Apr 5 05:45:56 2017 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 6E23A128D3E for ; Wed, 5 Apr 2017 05:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 IglHwbJqvY7h for ; Wed, 5 Apr 2017 05:45:51 -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 6330C128854 for ; Wed, 5 Apr 2017 05:45:50 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvkJo-0004Gn-Dy for taps@ietf.org; Wed, 05 Apr 2017 14:45:48 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx04.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvkJm-00056Y-5T for taps@ietf.org; Wed, 05 Apr 2017 14:45:48 +0200 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Apr 2017 14:45:45 +0200 References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> To: taps WG Message-Id: <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.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-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 53581 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.061, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 50966E6BEBBB68AD3C56E834055D4491330C628C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 12870 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:45:54 -0000 Dear all, This is the minor change that I promised at the last meeting - mainly to = include TCP Authentication (RFC 5925). Someone said that this document = should cite the other TAPS documents for context - very true! we did = that too. Finally, Gorry's comment regarding UDP's "close" (a recent email = discussion) was also incorporated. With this update, we authors believe that the document could now be = ready for WGLC. Cheers, Michael > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-ietf-taps-transports-usage-04.txt > Date: 5 Apr 2017 14:42:24 CEST > To: Michael T=C3=BCxen , Michael Welzl = , Michael Tuexen , Naeem = Khademi , > Resent-From: >=20 >=20 > A new version of I-D, draft-ietf-taps-transports-usage-04.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-ietf-taps-transports-usage > Revision: 04 > Title: On the Usage of Transport Features Provided by = IETF Transport Protocols > Document date: 2017-04-05 > Group: taps > Pages: 49 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-04.t= xt > Status: = https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-taps-transports-usage-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-usage-04 >=20 > Abstract: > This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite = expose > services to applications and how an application can configure and = use > the transport features that make up these services. It also > discusses the service provided by the LEDBAT congestion control > mechanism. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 From nobody Wed Apr 5 07:27:11 2017 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 DD364128768 for ; Wed, 5 Apr 2017 07:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 efWcYAo_SnXN for ; Wed, 5 Apr 2017 07:27:06 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B741127601 for ; Wed, 5 Apr 2017 07:27:06 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id x35so11831267qtc.2 for ; Wed, 05 Apr 2017 07:27:06 -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:content-transfer-encoding; bh=P6iktaMdSqRwUbon04ph7CNKpjxrZN8bjhN392rRMzo=; b=q+gZCzel0mboV7MeBFmdNYYQvMyYMTh1eGkEEZmKTB9JEIVEvkPKTe/EYGSXNcN4m2 jY2Ozlbtc2qX2nzfDB9HzIbnwkQ2rkDUT3SjIcGqoOWrjThXyZEnlPR1Fd3EWtZV7C1t RZjHBE2iIj3yv7Fr+jdqIEGc2IuzepAziBwI37dRVpJVL3vY0yZDKHcH/IT5MfjeuHaG d5yxspEwdDVBGrsgNJsAF+ZVXDZD9pKIyTWBKADEUjW3gWJ4KB3O987EkB9/M9SHz8Yj JP/8Urb3y9jJHA5Bnpr8EUVIPxnjdCldWOVLgeZ4IDr57zqjOkbgCJqy0qKSnrxDUjJz GdOA== 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:content-transfer-encoding; bh=P6iktaMdSqRwUbon04ph7CNKpjxrZN8bjhN392rRMzo=; b=l3oZm6JbnyQQ9Df64ZrzTRZc7ifZOhAFE2TbWQ92K5kGgZDLc5grPPe1fn17GzcXIn DRiEcg51JVfsZ/Mr/mmgpSUbX56I0D1+blwjyQ8hN2YF9PEwZeR2Sqt9/YEgzMyDQgT7 EXnkVEgHlTb7P7drQfZNLBygojBrJ6cYcm2Vx55c0UQxN8XMilVXBBd/vAu8ECvVhTuK FNmHNLVCHUcZ6we/6kp/IzfwMHOgUiosXAJRPF2DWFG28nUTT3xo+Dgtxo0LvhvDVMcS LgdMpQehXstElZf8L0PC+odNqPAh8+NC0iiSg536MbPTKqy26IKauzKCrzMZMpb7x5XI XfWg== X-Gm-Message-State: AFeK/H1NAsVm5cVpdiA16GDdt4kCNG8xxPUZJj6+ZYLnjNS+WMLAeNkzrkRj19i1OsFHFw== X-Received: by 10.200.46.208 with SMTP id i16mr29488096qta.13.1491402425534; Wed, 05 Apr 2017 07:27:05 -0700 (PDT) Received: from [172.19.34.227] ([2001:4878:8000:60:8de1:b8b2:8f64:b445]) by smtp.gmail.com with ESMTPSA id 44sm14103133qtn.56.2017.04.05.07.27.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Apr 2017 07:27:04 -0700 (PDT) From: "Aaron Falk" To: "Michael Welzl" Cc: "taps WG" Date: Wed, 05 Apr 2017 10:27:03 -0400 Message-ID: In-Reply-To: <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 14:27:10 -0000 Thanks, Michael! Once the rev for …-transports-udp-usage-… has been posted we’ll start the WGLC for both. —aaron On 5 Apr 2017, at 8:45, Michael Welzl wrote: > Dear all, > > This is the minor change that I promised at the last meeting - mainly > to include TCP Authentication (RFC 5925). Someone said that this > document should cite the other TAPS documents for context - very true! > we did that too. > Finally, Gorry's comment regarding UDP's "close" (a recent email > discussion) was also incorporated. > > With this update, we authors believe that the document could now be > ready for WGLC. > > Cheers, > Michael > > > >> Begin forwarded message: >> >> From: >> Subject: New Version Notification for >> draft-ietf-taps-transports-usage-04.txt >> Date: 5 Apr 2017 14:42:24 CEST >> To: Michael Tüxen , Michael Welzl >> , Michael Tuexen , Naeem >> Khademi , >> Resent-From: >> >> >> A new version of I-D, draft-ietf-taps-transports-usage-04.txt >> has been successfully submitted by Michael Welzl and posted to the >> IETF repository. >> >> Name: draft-ietf-taps-transports-usage >> Revision: 04 >> Title: On the Usage of Transport Features Provided by IETF Transport >> Protocols >> Document date: 2017-04-05 >> Group: taps >> Pages: 49 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-04.txt >> Status: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-taps-transports-usage-04 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-04 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-04 >> >> Abstract: >> This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite >> expose >> services to applications and how an application can configure and >> use >> the transport features that make up these services. It also >> discusses the service provided by the LEDBAT congestion control >> mechanism. >> >> >> >> >> 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. >> >> The IETF Secretariat >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Apr 5 11:03:26 2017 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 0CB41129469 for ; Wed, 5 Apr 2017 11:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 UbHYML7rYhJC for ; Wed, 5 Apr 2017 11:03:23 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 96DA8126C26 for ; Wed, 5 Apr 2017 11:03:23 -0700 (PDT) Received: from [128.9.184.101] ([128.9.184.101]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v35I1KIc004009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 11:01:23 -0700 (PDT) To: Michael Welzl , taps WG References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> From: Joe Touch Message-ID: <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> Date: Wed, 5 Apr 2017 11:01:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 18:03:25 -0000 On 4/5/2017 5:45 AM, Michael Welzl wrote: > This is the minor change that I promised at the last meeting - mainly to include TCP Authentication (RFC 5925). There are bugs in the description. TCP-AO was careful to say "TCP SEND, or a sequence of commands resulting in a SEND" (same for RECEIVE), regarding setting or viewing received key IDs (current and next), especially including ways to set/read these values even when a SEND or RECEIVE isn't issued (e.g., to affect retransmissions or ACKs). I didn't give a deep re-read and I don't recall from my earlier checks, but is there a discussion of using other operations to interact with connection parameters (socket options, ioctls), e.g., as part of the required interface? Joe From nobody Wed Apr 5 12:12:30 2017 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 82E7F128954 for ; Wed, 5 Apr 2017 12:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 OGwymGhljBTy for ; Wed, 5 Apr 2017 12:12:26 -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 B666D12709D for ; Wed, 5 Apr 2017 12:12:26 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvqLx-000Bnt-4o; Wed, 05 Apr 2017 21:12:25 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvqLw-0000Wz-Ed; Wed, 05 Apr 2017 21:12:25 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> Date: Wed, 5 Apr 2017 21:12:28 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 53591 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.043, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E7CDA475CFD1464E214125E9063ADB538163AB0D X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1087 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:12:30 -0000 Hi, Thanks a lot for checking this! > On Apr 5, 2017, at 8:01 PM, Joe Touch wrote: >=20 >=20 >=20 > On 4/5/2017 5:45 AM, Michael Welzl wrote: >> This is the minor change that I promised at the last meeting - mainly = to include TCP Authentication (RFC 5925). > There are bugs in the description. TCP-AO was careful to say "TCP = SEND, > or a sequence of commands resulting in a SEND" (same for RECEIVE), > regarding setting or viewing received key IDs (current and next), Hm, I saw this but didn=E2=80=99t get it - what is =E2=80=9Ca sequence = of commands resulting in a SEND=E2=80=9D (or RECEIVE) ? I just don=E2=80=99t get what that=E2=80=99s supposed to mean. E.g., = what else than SEND will send? > especially including ways to set/read these values even when a SEND or > RECEIVE isn't issued (e.g., to affect retransmissions or ACKs). I also saw this but didn=E2=80=99t see it as mandatory to provide (=E2=80=9C= It may be useful=E2=80=A6=E2=80=9D, the text says). Is this really very = useful? > I didn't give a deep re-read and I don't recall from my earlier = checks, > but is there a discussion of using other operations to interact with > connection parameters (socket options, ioctls), e.g., as part of the > required interface? Nothing that=E2=80=99s not in the RFCs=E2=80=A6 I did rephrase the = authentication stuff for TCP as =E2=80=9CCONNECTION.MAINTENANCE=E2=80=9D = primitives (set_auth, get_auth), stating that they=E2=80=99d be = implemented using SEND and RECV. Not much else available=E2=80=A6 If you say it=E2=80=99s important it can be added, I guess, but I find = it hard to derive that from the text in RFC 5925. Well, empty send=E2=80=99= s and receive=E2=80=99s are a way out, I suppose. Cheers, Michael From nobody Wed Apr 5 12:31:58 2017 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 1C8D41294AA for ; Wed, 5 Apr 2017 12:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 ZTnE6a4WKX-2 for ; Wed, 5 Apr 2017 12:31:54 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 6ED0712946D for ; Wed, 5 Apr 2017 12:31:53 -0700 (PDT) Received: from [128.9.184.101] ([128.9.184.101]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v35JVNwm023596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 12:31:24 -0700 (PDT) To: Michael Welzl References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> Cc: "taps@ietf.org" From: Joe Touch Message-ID: Date: Wed, 5 Apr 2017 12:31:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:31:56 -0000 On 4/5/2017 12:12 PM, Michael Welzl wrote: > Hi, > > Thanks a lot for checking this! > > >> On Apr 5, 2017, at 8:01 PM, Joe Touch wrote: >> >> >> >> On 4/5/2017 5:45 AM, Michael Welzl wrote: >>> This is the minor change that I promised at the last meeting - mainly to include TCP Authentication (RFC 5925). >> There are bugs in the description. TCP-AO was careful to say "TCP SEND, >> or a sequence of commands resulting in a SEND" (same for RECEIVE), >> regarding setting or viewing received key IDs (current and next), > Hm, I saw this but didn’t get it - what is “a sequence of commands resulting in a SEND” (or RECEIVE) ? > I just don’t get what that’s supposed to mean. E.g., what else than SEND will send? E.g., setting a socket option to set values then using SEND, or RECEIVE then socket options to read. The point was that the setting of those values can be asynchronous to the SEND/RECEIVE calls. > >> especially including ways to set/read these values even when a SEND or >> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs). > I also saw this but didn’t see it as mandatory to provide (“It may be useful…”, the text says). Is this really very useful? You might want/need to change keys on a BGP session even when you aren't yet ready to issue a SEND. You might want to check to see of the keys have changed due to retransmissions or ACKs even when you didn't issue a RECEIVE. > >> I didn't give a deep re-read and I don't recall from my earlier checks, >> but is there a discussion of using other operations to interact with >> connection parameters (socket options, ioctls), e.g., as part of the >> required interface? > Nothing that’s not in the RFCs… I did rephrase the authentication stuff for TCP as “CONNECTION.MAINTENANCE” primitives (set_auth, get_auth), stating that they’d be implemented using SEND and RECV. Not much else available… > > If you say it’s important it can be added, I guess, but I find it hard to derive that from the text in RFC 5925. Well, empty send’s and receive’s are a way out, I suppose. It's not just RFC 5925. The issue is whether there are other mandatory configurations or monitoring that is async to SEND/RECEIVE. If so, then you can't simply assume they occur only during those calls. Joe From nobody Wed Apr 5 12:46:31 2017 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 982221242F5 for ; Wed, 5 Apr 2017 12:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 WKrSGDhbEoQW for ; Wed, 5 Apr 2017 12:46:25 -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 03F8A127A90 for ; Wed, 5 Apr 2017 12:46:24 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvqsp-0001Y7-5s; Wed, 05 Apr 2017 21:46:23 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvqso-000F5T-MX; Wed, 05 Apr 2017 21:46:23 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: Date: Wed, 5 Apr 2017 21:46:25 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> To: Joe Touch X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 6 sum rcpts/h 11 sum msgs/h 6 total rcpts 53600 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.025, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0F8EDF848EED68A801183D9A5EDB6A58DEB04ED2 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 1092 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:46:28 -0000 > On Apr 5, 2017, at 9:31 PM, Joe Touch wrote: >=20 >=20 >=20 > On 4/5/2017 12:12 PM, Michael Welzl wrote: >> Hi, >>=20 >> Thanks a lot for checking this! >>=20 >>=20 >>> On Apr 5, 2017, at 8:01 PM, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 4/5/2017 5:45 AM, Michael Welzl wrote: >>>> This is the minor change that I promised at the last meeting - = mainly to include TCP Authentication (RFC 5925). >>> There are bugs in the description. TCP-AO was careful to say "TCP = SEND, >>> or a sequence of commands resulting in a SEND" (same for RECEIVE), >>> regarding setting or viewing received key IDs (current and next), >> Hm, I saw this but didn=E2=80=99t get it - what is =E2=80=9Ca = sequence of commands resulting in a SEND=E2=80=9D (or RECEIVE) ? >> I just don=E2=80=99t get what that=E2=80=99s supposed to mean. E.g., = what else than SEND will send? >=20 > E.g., setting a socket option to set values then using SEND, or = RECEIVE > then socket options to read. >=20 > The point was that the setting of those values can be asynchronous to > the SEND/RECEIVE calls. Okay, got it; socket options don=E2=80=99t exist in RFC 793 language, or = any of the RFCs updating it, I think=E2=80=A6 maybe this RFC should have invented such a function call? Anyway, I can = do this for you :-) to some degree, that=E2=80=99s the role of my = draft. I can say that RFC 5925 demands this functionality, and describe = SET_AUTH and GET_AUTH primitives that would map to that. >>> especially including ways to set/read these values even when a SEND = or >>> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs). >> I also saw this but didn=E2=80=99t see it as mandatory to provide = (=E2=80=9CIt may be useful=E2=80=A6=E2=80=9D, the text says). Is this = really very useful? > You might want/need to change keys on a BGP session even when you = aren't > yet ready to issue a SEND. You might want to check to see of the keys > have changed due to retransmissions or ACKs even when you didn't issue = a > RECEIVE. Okay=E2=80=A6 >>> I didn't give a deep re-read and I don't recall from my earlier = checks, >>> but is there a discussion of using other operations to interact with >>> connection parameters (socket options, ioctls), e.g., as part of the >>> required interface? >> Nothing that=E2=80=99s not in the RFCs=E2=80=A6 I did rephrase the = authentication stuff for TCP as =E2=80=9CCONNECTION.MAINTENANCE=E2=80=9D = primitives (set_auth, get_auth), stating that they=E2=80=99d be = implemented using SEND and RECV. Not much else available=E2=80=A6 >>=20 >> If you say it=E2=80=99s important it can be added, I guess, but I = find it hard to derive that from the text in RFC 5925. Well, empty = send=E2=80=99s and receive=E2=80=99s are a way out, I suppose. >=20 > It's not just RFC 5925. The issue is whether there are other mandatory > configurations or monitoring that is async to SEND/RECEIVE. If so, = then > you can't simply assume they occur only during those calls. There isn=E2=80=99t much; Nagle is an example - RFC 1122 just says that = the functionality to enable / disable must be there, without specifying = via which primitive that would happen. So, my draft says, in pass 2: o DISABLE_NAGLE.TCP: Pass 1 primitive / event: not specified Seems like I should do the same for set_auth and get_auth. Cheers, Michael From nobody Wed Apr 5 12:51:29 2017 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 BA5801294BB for ; Wed, 5 Apr 2017 12:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 1ZSjLyw4bano for ; Wed, 5 Apr 2017 12:51:12 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 D49C1127A90 for ; Wed, 5 Apr 2017 12:51:01 -0700 (PDT) Received: from [128.9.184.101] ([128.9.184.101]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v35JoE9B028324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 12:50:16 -0700 (PDT) To: Michael Welzl References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> Cc: "taps@ietf.org" From: Joe Touch Message-ID: Date: Wed, 5 Apr 2017 12:50:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:51:24 -0000 FWIW, the current setsockopt commands are an extension (IMO) of the STATUS command of RFC 793, allowing it to not only read connection information but also modify it. IMO, we should think of it in those terms, not merely "setsockopt" or "ioctl" or anything else. Joe On 4/5/2017 12:46 PM, Michael Welzl wrote: >> On Apr 5, 2017, at 9:31 PM, Joe Touch wrote: >> >> >> >> On 4/5/2017 12:12 PM, Michael Welzl wrote: >>> Hi, >>> >>> Thanks a lot for checking this! >>> >>> >>>> On Apr 5, 2017, at 8:01 PM, Joe Touch wrote: >>>> >>>> >>>> >>>> On 4/5/2017 5:45 AM, Michael Welzl wrote: >>>>> This is the minor change that I promised at the last meeting - mainly to include TCP Authentication (RFC 5925). >>>> There are bugs in the description. TCP-AO was careful to say "TCP SEND, >>>> or a sequence of commands resulting in a SEND" (same for RECEIVE), >>>> regarding setting or viewing received key IDs (current and next), >>> Hm, I saw this but didn’t get it - what is “a sequence of commands resulting in a SEND” (or RECEIVE) ? >>> I just don’t get what that’s supposed to mean. E.g., what else than SEND will send? >> E.g., setting a socket option to set values then using SEND, or RECEIVE >> then socket options to read. >> >> The point was that the setting of those values can be asynchronous to >> the SEND/RECEIVE calls. > Okay, got it; socket options don’t exist in RFC 793 language, or any of the RFCs updating it, I think… > maybe this RFC should have invented such a function call? Anyway, I can do this for you :-) to some degree, that’s the role of my draft. I can say that RFC 5925 demands this functionality, and describe SET_AUTH and GET_AUTH primitives that would map to that. > > >>>> especially including ways to set/read these values even when a SEND or >>>> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs). >>> I also saw this but didn’t see it as mandatory to provide (“It may be useful…”, the text says). Is this really very useful? >> You might want/need to change keys on a BGP session even when you aren't >> yet ready to issue a SEND. You might want to check to see of the keys >> have changed due to retransmissions or ACKs even when you didn't issue a >> RECEIVE. > Okay… > > >>>> I didn't give a deep re-read and I don't recall from my earlier checks, >>>> but is there a discussion of using other operations to interact with >>>> connection parameters (socket options, ioctls), e.g., as part of the >>>> required interface? >>> Nothing that’s not in the RFCs… I did rephrase the authentication stuff for TCP as “CONNECTION.MAINTENANCE” primitives (set_auth, get_auth), stating that they’d be implemented using SEND and RECV. Not much else available… >>> >>> If you say it’s important it can be added, I guess, but I find it hard to derive that from the text in RFC 5925. Well, empty send’s and receive’s are a way out, I suppose. >> It's not just RFC 5925. The issue is whether there are other mandatory >> configurations or monitoring that is async to SEND/RECEIVE. If so, then >> you can't simply assume they occur only during those calls. > There isn’t much; Nagle is an example - RFC 1122 just says that the functionality to enable / disable must be there, without specifying via which primitive that would happen. > So, my draft says, in pass 2: > > o DISABLE_NAGLE.TCP: > Pass 1 primitive / event: not specified > > Seems like I should do the same for set_auth and get_auth. > > Cheers, > Michael > From nobody Wed Apr 5 12:55:56 2017 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 9AEA3129493 for ; Wed, 5 Apr 2017 12:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 LqfBQiMMySdn for ; Wed, 5 Apr 2017 12:55:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 4098812941D for ; Wed, 5 Apr 2017 12:55:54 -0700 (PDT) Received: from [128.9.184.101] ([128.9.184.101]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v35JtMv1022357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 12:55:22 -0700 (PDT) To: Michael Welzl References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> Cc: "taps@ietf.org" From: Joe Touch Message-ID: Date: Wed, 5 Apr 2017 12:55:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:55:56 -0000 On 4/5/2017 12:46 PM, Michael Welzl wrote: > There isn’t much; Nagle is an example - RFC 1122 just says that the functionality to enable / disable must be there, without specifying via which primitive that would happen. > So, my draft says, in pass 2: > > o DISABLE_NAGLE.TCP: > Pass 1 primitive / event: not specified > > Seems like I should do the same for set_auth and get_auth. Set_auth and get_auth are either in the STATUS (as per my previous message) or SEND/RECEIVE. There may be other signals that need to be specified. E.g., RFC1122 has a few items that need to be indicated, but isn't clear about them being only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4). Joe From nobody Wed Apr 5 13:11:12 2017 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 9C889129439 for ; Wed, 5 Apr 2017 13:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 C3ZC2baUtB61 for ; Wed, 5 Apr 2017 13:11:06 -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 EB9E012948F for ; Wed, 5 Apr 2017 13:11:02 -0700 (PDT) Received: from mail-mx04.uio.no ([129.240.10.25]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvrGe-0003Pk-VL for taps@ietf.org; Wed, 05 Apr 2017 22:11:00 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx04.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvrGe-0006IY-FY; Wed, 05 Apr 2017 22:11:00 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: Date: Wed, 5 Apr 2017 22:10:59 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> To: Joe Touch X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx04.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 7 sum msgs/h 4 total rcpts 53602 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.039, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DE40DBBEF84C6DFC1B5B3988F9B2CED8C2C7B0ED X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1093 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 20:11:10 -0000 > On Apr 5, 2017, at 9:55 PM, Joe Touch wrote: >=20 >=20 >=20 > On 4/5/2017 12:46 PM, Michael Welzl wrote: >> There isn=E2=80=99t much; Nagle is an example - RFC 1122 just says = that the functionality to enable / disable must be there, without = specifying via which primitive that would happen. >> So, my draft says, in pass 2: >>=20 >> o DISABLE_NAGLE.TCP: >> Pass 1 primitive / event: not specified >>=20 >> Seems like I should do the same for set_auth and get_auth. > Set_auth and get_auth are either in the STATUS (as per my previous > message) or SEND/RECEIVE. What=E2=80=99s the problem with defining new primitives for these = things? It=E2=80=99s just an abstract API anyway. I actually removed STATUS in my draft because of the following reasoning = (quoting my own draft): *** The 'status' primitive was not included because [RFC0793] describes this = primitive as "implementation dependent" and states that it "could be excluded without = adverse effect=E2=80=9D. Moreover, while a data block containing specific information is = described, it is also stated that not all of this information may always be available. *** Because a TAPS system should be able to rely on things that are = available pretty much everywhere, this draft doesn=E2=80=99t include things that are optional for an = underlying transport to implement. > There may be other signals that need to be specified. E.g., RFC1122 = has > a few items that need to be indicated, but isn't clear about them = being > only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and = 4.2.4). Exactly my point - disabling Nagle is one of these things. So I gave = them names and call them primitives under =E2=80=9CCONNECTION.MAINTENANCE=E2= =80=9D. Shouldn=E2=80=99t matter, as long as the functionality is there? Cheers, Michael From nobody Wed Apr 5 13:34:04 2017 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 03CFB127275 for ; Wed, 5 Apr 2017 13:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 6bq406sBiLWe for ; Wed, 5 Apr 2017 13:34:00 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 47CF41294AF for ; Wed, 5 Apr 2017 13:33:56 -0700 (PDT) Received: from [128.9.184.101] ([128.9.184.101]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v35KXUNN004480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 13:33:31 -0700 (PDT) To: Michael Welzl References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> Cc: "taps@ietf.org" From: Joe Touch Message-ID: Date: Wed, 5 Apr 2017 13:33:31 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 20:34:02 -0000 Hi, Michael, On 4/5/2017 1:10 PM, Michael Welzl wrote: >> On Apr 5, 2017, at 9:55 PM, Joe Touch wrote: >> ... >> Set_auth and get_auth are either in the STATUS (as per my previous >> message) or SEND/RECEIVE. > What’s the problem with defining new primitives for these things? It’s just an abstract API anyway. You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., it does say that the management of these parameters can be via SEND/RECEIVE, but doesn't have to be. > I actually removed STATUS in my draft because of the following reasoning (quoting my own draft): > > *** > The 'status' primitive was not included because [RFC0793] describes this primitive as > "implementation dependent" and states that it "could be excluded without adverse effect”. That was true back when 793 was created, but hasn't been true effectively since 1122. > Moreover, while a data block containing specific information is described, it is also stated > that not all of this information may always be available. > *** > > Because a TAPS system should be able to rely on things that are available pretty much everywhere, > this draft doesn’t include things that are optional for an underlying transport to implement. Agreed - I'm saying that there MUST be a command by which some parameters of a connection can be monitored and altered after the connection is established but asynchronously from a SEND/RECEIVE call. You might say that you could accomplish the result with a zero-byte SEND or nonblocking RECEIVE, but that's ugly from an API viewpoint. > >> There may be other signals that need to be specified. E.g., RFC1122 has >> a few items that need to be indicated, but isn't clear about them being >> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4). > Exactly my point - disabling Nagle is one of these things. So I gave them names and call them primitives under “CONNECTION.MAINTENANCE”. > Shouldn’t matter, as long as the functionality is there? Oh, OK - then you would want to say that the keyID and nextkeyIDs fall under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. Joe From nobody Wed Apr 5 14:24:09 2017 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 25E0C129490 for ; Wed, 5 Apr 2017 14:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 zGtZ6q8tXzkK for ; Wed, 5 Apr 2017 14:24:04 -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 A9D84126BF6 for ; Wed, 5 Apr 2017 14:23:58 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvsPE-0008U6-NG for taps@ietf.org; Wed, 05 Apr 2017 23:23:56 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvsPE-000CVd-6m; Wed, 05 Apr 2017 23:23:56 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: Date: Wed, 5 Apr 2017 23:23:53 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <09F0C13E-EA17-4A7E-BA74-FFD36D1CD62D@ifi.uio.no> References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> To: Joe Touch X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 53604 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.056, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5353657E4D8AE07EB7151FE2F0A4B30DBAF8DF17 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1094 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 21:24:07 -0000 > On Apr 5, 2017, at 10:33 PM, Joe Touch wrote: >=20 > Hi, Michael, >=20 >=20 > On 4/5/2017 1:10 PM, Michael Welzl wrote: >>> On Apr 5, 2017, at 9:55 PM, Joe Touch wrote: >>> ... >>> Set_auth and get_auth are either in the STATUS (as per my previous >>> message) or SEND/RECEIVE. >> What=E2=80=99s the problem with defining new primitives for these = things? It=E2=80=99s just an abstract API anyway. > You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., = it > does say that the management of these parameters can be via > SEND/RECEIVE, but doesn't have to be. We seem to agree: see below - >> I actually removed STATUS in my draft because of the following = reasoning (quoting my own draft): >>=20 >> *** >> The 'status' primitive was not included because [RFC0793] describes = this primitive as >> "implementation dependent" and states that it "could be excluded = without adverse effect=E2=80=9D. >=20 > That was true back when 793 was created, but hasn't been true > effectively since 1122. Hmmm=E2=80=A6. what about the whole block defined in RFC793? It tells = you about rwnd, snd wnd, and strange stuff like security/compartment=E2=80= =A6 where to draw the line? I guess by knowing what is actually happening in OS=E2=80=99es out = there, for each of these items. That=E2=80=99s the quest I wasn=E2=80=99t = going to take - this draft is based on the RFCs. I=E2=80=99d also say that these things don=E2=80=99t matter much for a = (minimal) TAPS system - for many of these things, exposing them creates = an unnecessary dependency on the protocol. >> Moreover, while a data block containing specific information is = described, it is also stated >> that not all of this information may always be available. >> *** >>=20 >> Because a TAPS system should be able to rely on things that are = available pretty much everywhere, >> this draft doesn=E2=80=99t include things that are optional for an = underlying transport to implement. > Agreed - I'm saying that there MUST be a command by which some > parameters of a connection can be monitored and altered after the > connection is established but asynchronously from a SEND/RECEIVE call. >=20 > You might say that you could accomplish the result with a zero-byte = SEND > or nonblocking RECEIVE, but that's ugly from an API viewpoint. Agree to both - >>> There may be other signals that need to be specified. E.g., RFC1122 = has >>> a few items that need to be indicated, but isn't clear about them = being >>> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and = 4.2.4). >> Exactly my point - disabling Nagle is one of these things. So I gave = them names and call them primitives under =E2=80=9CCONNECTION.MAINTENANCE=E2= =80=9D. >> Shouldn=E2=80=99t matter, as long as the functionality is there? >=20 > Oh, OK - then you would want to say that the keyID and nextkeyIDs fall > under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. Exactly. Right now, the error is that the CONNECTION.MAINTENANCE = primitive description says that this uses =E2=80=98send=E2=80=99 or = =E2=80=98receive=E2=80=99. It shouldn=E2=80=99t. I=E2=80=99ll note that = for the next update (when I'll address more comments from WGLC), thanks! Cheers, Michael From nobody Wed Apr 5 14:31:43 2017 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 DAF501294AF for ; Wed, 5 Apr 2017 14:31: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, RP_MATCHES_RCVD=-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 SSEEJXA7iVRS for ; Wed, 5 Apr 2017 14:31:39 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 2AF4D12949D for ; Wed, 5 Apr 2017 14:31:37 -0700 (PDT) Received: from [128.9.184.101] ([128.9.184.101]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v35LV8k8023377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 5 Apr 2017 14:31:08 -0700 (PDT) To: Michael Welzl References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> <09F0C13E-EA17-4A7E-BA74-FFD36D1CD62D@ifi.uio.no> Cc: "taps@ietf.org" From: Joe Touch Message-ID: <285a7a58-20a9-2891-7a75-2f5ca404cc5d@isi.edu> Date: Wed, 5 Apr 2017 14:31:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <09F0C13E-EA17-4A7E-BA74-FFD36D1CD62D@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: v35LV8k8023377 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 21:31:42 -0000 On 4/5/2017 2:23 PM, Michael Welzl wrote: >> On Apr 5, 2017, at 10:33 PM, Joe Touch wrote: >> >> Hi, Michael, >> >> >> On 4/5/2017 1:10 PM, Michael Welzl wrote: >>>> On Apr 5, 2017, at 9:55 PM, Joe Touch wrote: >>>> ... >>>> Set_auth and get_auth are either in the STATUS (as per my previous >>>> message) or SEND/RECEIVE. >>> What’s the problem with defining new primitives for these things? It’s just an abstract API anyway. >> You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., it >> does say that the management of these parameters can be via >> SEND/RECEIVE, but doesn't have to be. > We seem to agree: see below - > > >>> I actually removed STATUS in my draft because of the following reasoning (quoting my own draft): >>> >>> *** >>> The 'status' primitive was not included because [RFC0793] describes this primitive as >>> "implementation dependent" and states that it "could be excluded without adverse effect”. >> That was true back when 793 was created, but hasn't been true >> effectively since 1122. > Hmmm…. what about the whole block defined in RFC793? It tells you about rwnd, snd wnd, and strange stuff like security/compartment… where to draw the line? Having a "window" into what TCP is doing is nice, but not necessary. Having a way to disable Nagle (or enable it, for that matter) is necessary. I'd draw the line at "required" to make TCP work correctly. > I guess by knowing what is actually happening in OS’es out there, for each of these items. That’s the quest I wasn’t going to take - this draft is based on the RFCs. IMO, it's hard to scrub those RFCs for this info. There was a time when the IETF decided that APIs were out of scope and a lot of the info you need was ignored in RFCs, or at best pushed to "honorable mention". > I’d also say that these things don’t matter much for a (minimal) TAPS system - for many of these things, exposing them creates an unnecessary dependency on the protocol. I don't know what the requirements are for a minimal TCP system, so there's no way to answer that. We ought to understand that for every protocol we design, but we don't. >>> Moreover, while a data block containing specific information is described, it is also stated >>> that not all of this information may always be available. >>> *** >>> >>> Because a TAPS system should be able to rely on things that are available pretty much everywhere, >>> this draft doesn’t include things that are optional for an underlying transport to implement. >> Agreed - I'm saying that there MUST be a command by which some >> parameters of a connection can be monitored and altered after the >> connection is established but asynchronously from a SEND/RECEIVE call. >> >> You might say that you could accomplish the result with a zero-byte SEND >> or nonblocking RECEIVE, but that's ugly from an API viewpoint. > Agree to both - > > >>>> There may be other signals that need to be specified. E.g., RFC1122 has >>>> a few items that need to be indicated, but isn't clear about them being >>>> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4). >>> Exactly my point - disabling Nagle is one of these things. So I gave them names and call them primitives under “CONNECTION.MAINTENANCE”. >>> Shouldn’t matter, as long as the functionality is there? >> Oh, OK - then you would want to say that the keyID and nextkeyIDs fall >> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. > Exactly. Right now, the error is that the CONNECTION.MAINTENANCE primitive description says that this uses ‘send’ or ‘receive’. It shouldn’t. I’ll note that for the next update (when I'll address more comments from WGLC), thanks! AOK. Joe From nobody Wed Apr 5 14:43:37 2017 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 3467F1294B1 for ; Wed, 5 Apr 2017 14:43: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 NhRTsohwgxhd for ; Wed, 5 Apr 2017 14:43:31 -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 069211294A2 for ; Wed, 5 Apr 2017 14:43:22 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvsi0-0001AU-Cj for taps@ietf.org; Wed, 05 Apr 2017 23:43:20 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cvshz-0000la-Go; Wed, 05 Apr 2017 23:43:20 +0200 From: Michael Welzl Message-Id: <3DF69369-1782-4B36-8DB7-5B043B32134B@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_EB51E0F2-8691-4DA8-ABE7-DA43BFAC3BB0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 5 Apr 2017 23:43:18 +0200 In-Reply-To: <285a7a58-20a9-2891-7a75-2f5ca404cc5d@isi.edu> Cc: "taps@ietf.org" To: Joe Touch References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> <09F0C13E-EA17-4A7E-BA74-FFD36D1CD62D@ifi.uio.no> <285a7a58-20a9-2891-7a75-2f5ca404cc5d@isi.edu> X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 7 sum msgs/h 3 total rcpts 53606 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.013, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6860CA431CB2E943DCAF8C2C6A88D3956B809373 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1095 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 21:43:34 -0000 --Apple-Mail=_EB51E0F2-8691-4DA8-ABE7-DA43BFAC3BB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 5, 2017, at 11:31 PM, Joe Touch wrote: >=20 >=20 >=20 > On 4/5/2017 2:23 PM, Michael Welzl wrote: >>> On Apr 5, 2017, at 10:33 PM, Joe Touch wrote: >>>=20 >>> Hi, Michael, >>>=20 >>>=20 >>> On 4/5/2017 1:10 PM, Michael Welzl wrote: >>>>> On Apr 5, 2017, at 9:55 PM, Joe Touch wrote: >>>>> ... >>>>> Set_auth and get_auth are either in the STATUS (as per my previous >>>>> message) or SEND/RECEIVE. >>>> What=E2=80=99s the problem with defining new primitives for these = things? It=E2=80=99s just an abstract API anyway. >>> You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., = it >>> does say that the management of these parameters can be via >>> SEND/RECEIVE, but doesn't have to be. >> We seem to agree: see below - >>=20 >>=20 >>>> I actually removed STATUS in my draft because of the following = reasoning (quoting my own draft): >>>>=20 >>>> *** >>>> The 'status' primitive was not included because [RFC0793] describes = this primitive as >>>> "implementation dependent" and states that it "could be excluded = without adverse effect=E2=80=9D. >>> That was true back when 793 was created, but hasn't been true >>> effectively since 1122. >> Hmmm=E2=80=A6. what about the whole block defined in RFC793? It tells = you about rwnd, snd wnd, and strange stuff like security/compartment=E2=80= =A6 where to draw the line? > Having a "window" into what TCP is doing is nice, but not necessary. >=20 > Having a way to disable Nagle (or enable it, for that matter) is = necessary. >=20 > I'd draw the line at "required" to make TCP work correctly. Yes - >> I guess by knowing what is actually happening in OS=E2=80=99es out = there, for each of these items. That=E2=80=99s the quest I wasn=E2=80=99t = going to take - this draft is based on the RFCs. >=20 > IMO, it's hard to scrub those RFCs for this info. There was a time = when > the IETF decided that APIs were out of scope and a lot of the info you > need was ignored in RFCs, or at best pushed to "honorable mention". >=20 >> I=E2=80=99d also say that these things don=E2=80=99t matter much for = a (minimal) TAPS system - for many of these things, exposing them = creates an unnecessary dependency on the protocol. >=20 > I don't know what the requirements are for a minimal TCP system, so > there's no way to answer that. I don=E2=80=99t think the group ever agreed on any - so my statement was = based on our (authors=E2=80=99) own rules, laid out in: https://tools.ietf.org/html/draft-gjessing-taps-minset = > We ought to understand that for every protocol we design, but we = don't. >=20 >>>> Moreover, while a data block containing specific information is = described, it is also stated >>>> that not all of this information may always be available. >>>> *** >>>>=20 >>>> Because a TAPS system should be able to rely on things that are = available pretty much everywhere, >>>> this draft doesn=E2=80=99t include things that are optional for an = underlying transport to implement. >>> Agreed - I'm saying that there MUST be a command by which some >>> parameters of a connection can be monitored and altered after the >>> connection is established but asynchronously from a SEND/RECEIVE = call. >>>=20 >>> You might say that you could accomplish the result with a zero-byte = SEND >>> or nonblocking RECEIVE, but that's ugly from an API viewpoint. >> Agree to both - >>=20 >>=20 >>>>> There may be other signals that need to be specified. E.g., = RFC1122 has >>>>> a few items that need to be indicated, but isn't clear about them = being >>>>> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and = 4.2.4). >>>> Exactly my point - disabling Nagle is one of these things. So I = gave them names and call them primitives under = =E2=80=9CCONNECTION.MAINTENANCE=E2=80=9D. >>>> Shouldn=E2=80=99t matter, as long as the functionality is there? >>> Oh, OK - then you would want to say that the keyID and nextkeyIDs = fall >>> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. >> Exactly. Right now, the error is that the CONNECTION.MAINTENANCE = primitive description says that this uses =E2=80=98send=E2=80=99 or = =E2=80=98receive=E2=80=99. It shouldn=E2=80=99t. I=E2=80=99ll note that = for the next update (when I'll address more comments from WGLC), thanks! >=20 > AOK. > Joe Thanks! Cheers, Michael --Apple-Mail=_EB51E0F2-8691-4DA8-ABE7-DA43BFAC3BB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 5, 2017, at 11:31 PM, Joe Touch <touch@isi.edu> = wrote:



On 4/5/2017 2:23 PM, Michael = Welzl wrote:
On Apr 5, 2017, at 10:33 = PM, Joe Touch <touch@isi.edu> wrote:

Hi, = Michael,


On 4/5/2017 1:10 = PM, Michael Welzl wrote:
On Apr 5, 2017, at 9:55 = PM, Joe Touch <touch@isi.edu> wrote:
...
Set_auth and get_auth are either in the STATUS (as per my = previous
message) or SEND/RECEIVE.
What=E2=80=99s the problem with defining new = primitives for these things? It=E2=80=99s just an abstract API = anyway.
You can, but 5925 says "SEND or = other" and "RECEIVE or other", i.e., it
does say that the = management of these parameters can be via
SEND/RECEIVE, = but doesn't have to be.
We seem to agree: see = below -


I actually = removed STATUS in my draft because of the following reasoning (quoting = my own draft):

***
The = 'status' primitive was not included because [RFC0793] describes this = primitive as
"implementation dependent" and states that it = "could be excluded without adverse effect=E2=80=9D.
That was true back when 793 was created, but = hasn't been true
effectively since 1122.
Hmmm=E2=80=A6. what about the whole block = defined in RFC793? It tells you about rwnd, snd wnd, and strange stuff = like security/compartment=E2=80=A6 where to draw the line?
Having a "window" into what TCP is doing is = nice, but not necessary.

Having a way to = disable Nagle (or enable it, for that matter) is necessary.

I'd draw the line at "required" to make TCP = work correctly.

Yes -


I guess by knowing what = is actually happening in OS=E2=80=99es out there, for each of these = items. That=E2=80=99s the quest I wasn=E2=80=99t going to take - this = draft is based on the RFCs.

IMO,= it's hard to scrub those RFCs for this info. There was a time when
the IETF decided that APIs were out of scope and a lot of the = info you
need was ignored in RFCs, or at best pushed to = "honorable mention".

I=E2=80=99d also say that these things don=E2=80=99= t matter much for a (minimal) TAPS system - for many of these things, = exposing them creates an unnecessary dependency on the protocol.

I don't know what the = requirements are for a minimal TCP system, so
there's no = way to answer that.

I don=E2=80=99t think the group ever agreed on any = - so my statement was based on our (authors=E2=80=99) own rules, laid = out in:
https://tools.ietf.org/html/draft-gjessing-taps-minset


We ought to = understand that for every protocol we design, but we don't.

= Moreover, while a data block containing specific information is = described, it is also stated
 that not all of this = information may always be available.
***

Because a TAPS system should be able to rely on things that = are available pretty much everywhere,
this draft doesn=E2=80= =99t include things that are optional for an underlying transport to = implement.
Agreed - I'm saying that there = MUST be a command by which some
parameters of a connection = can be monitored and altered after the
connection is = established but asynchronously from a SEND/RECEIVE call.
You might say that you could accomplish the result with a = zero-byte SEND
or nonblocking RECEIVE, but that's ugly = from an API viewpoint.
Agree to both -


There may be other signals that need to be specified. E.g., = RFC1122 has
a few items that need to be indicated, but = isn't clear about them being
only inside SEND/RECEIVE = commands (e.g., see sections 4.1.4 and 4.2.4).
Exactly my point - disabling Nagle is one of = these things. So I gave them names and call them primitives under = =E2=80=9CCONNECTION.MAINTENANCE=E2=80=9D.
Shouldn=E2=80=99t = matter, as long as the functionality is there?
Oh, OK - then you would want to say that the = keyID and nextkeyIDs fall
under BOTH SEND/RECEIVE and the = CONNECTION.MAINTENANCE section.
Exactly. = Right now, the error is that the CONNECTION.MAINTENANCE primitive = description says that this uses =E2=80=98send=E2=80=99 or =E2=80=98receive= =E2=80=99. It shouldn=E2=80=99t.  I=E2=80=99ll note that for the = next update (when I'll address more comments from WGLC), thanks!

AOK.
Joe

Thanks!

Cheers,
Michael

= --Apple-Mail=_EB51E0F2-8691-4DA8-ABE7-DA43BFAC3BB0-- From nobody Wed Apr 5 23:54:55 2017 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 C49BA1293FF for ; Wed, 5 Apr 2017 23:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 4K7xb2-FfQ77 for ; Wed, 5 Apr 2017 23:54:51 -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 E6875128BA2 for ; Wed, 5 Apr 2017 23:54:49 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cw1Jf-00074N-VK; Thu, 06 Apr 2017 08:54:47 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx01.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cw1Jf-00041u-BL; Thu, 06 Apr 2017 08:54:47 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <3DF69369-1782-4B36-8DB7-5B043B32134B@ifi.uio.no> Date: Thu, 6 Apr 2017 08:54:44 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <76C0A764-9EA1-4E73-8161-1C25306F6DE6@ifi.uio.no> References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> <09F0C13E-EA17-4A7E-BA74-FFD36D1CD62D@ifi.uio.no> <285a7a58-20a9-2891-7a75-2f5ca404cc5d@isi.edu> <3DF69369-1782-4B36-8DB7-5B043B32134B@ifi.uio.no> To: Joe Touch X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.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-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 6 sum msgs/h 3 total rcpts 53609 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.001, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 74BBE353CBE83DEC842DB61902B9A9EDCB633894 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 12875 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 06:54:54 -0000 BTW, Just a quick last question, to make sure I get this right: >>>> Oh, OK - then you would want to say that the keyID and nextkeyIDs = fall >>>> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. When handing over the keyID and nextkeyIDs on SEND, this just means that = these new values are valid from the time SEND was called, right? It's = not tied to the specific data block that's being handed over? (I'm asking because that's a difference to SCTP, where it's possible to = decide to authenticate a particular data chunk that's handed over. For = TCP, this would be pretty unusual, I think, but perhaps also = implementable...) Cheers, Michael From nobody Thu Apr 13 12:32:47 2017 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 E1C2412EB3D for ; Thu, 13 Apr 2017 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 mSRLtXL2gpkZ for ; Thu, 13 Apr 2017 12:32:44 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 B057212957A for ; Thu, 13 Apr 2017 12:32:44 -0700 (PDT) Received: from [128.9.184.107] ([128.9.184.107]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3DJWOAi010140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 13 Apr 2017 12:32:24 -0700 (PDT) To: Michael Welzl References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> <09F0C13E-EA17-4A7E-BA74-FFD36D1CD62D@ifi.uio.no> <285a7a58-20a9-2891-7a75-2f5ca404cc5d@isi.edu> <3DF69369-1782-4B36-8DB7-5B043B32134B@ifi.uio.no> <76C0A764-9EA1-4E73-8161-1C25306F6DE6@ifi.uio.no> Cc: "taps@ietf.org" From: Joe Touch Message-ID: <410aa055-f5bf-c9fb-ac1d-7ac020d686bd@isi.edu> Date: Thu, 13 Apr 2017 12:32:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <76C0A764-9EA1-4E73-8161-1C25306F6DE6@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v3DJWOAi010140 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:32:46 -0000 Hi, Michael, Sorry for the delay... On 4/5/2017 11:54 PM, Michael Welzl wrote: > BTW, > > Just a quick last question, to make sure I get this right: > >>>>> Oh, OK - then you would want to say that the keyID and nextkeyIDs fall >>>>> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. > When handing over the keyID and nextkeyIDs on SEND, this just means that these new values are valid from the time SEND was called, right? It's not tied to the specific data block that's being handed over? Correct. They're not tied to data the way the URG pointer is or SCTP authentications are. Joe > (I'm asking because that's a difference to SCTP, where it's possible to decide to authenticate a particular data chunk that's handed over. For TCP, this would be pretty unusual, I think, but perhaps also implementable...) > > Cheers, > Michael > From nobody Thu Apr 13 12:34:52 2017 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 020BA12EB4C for ; Thu, 13 Apr 2017 12:34:51 -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, RP_MATCHES_RCVD=-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 PRkhc_9cwFom for ; Thu, 13 Apr 2017 12:34:48 -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 BAAD412EB47 for ; Thu, 13 Apr 2017 12:34:48 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cykVz-0004gT-61; Thu, 13 Apr 2017 21:34:47 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cykVy-000Csu-Ng; Thu, 13 Apr 2017 21:34:47 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <410aa055-f5bf-c9fb-ac1d-7ac020d686bd@isi.edu> Date: Thu, 13 Apr 2017 21:34:46 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <19E9415A-C6CC-4DBD-B36A-C5E25F628ED8@ifi.uio.no> References: <149139614456.1088.11144210650627320456.idtracker@ietfa.amsl.com> <7A816B9B-AAC5-486A-B027-0F1B7F7DC71B@ifi.uio.no> <7fc48096-f840-3268-21fe-6460c4b79ec3@isi.edu> <10A25ABC-5B13-499A-9CAF-1D23076EE1CB@ifi.uio.no> <444E4992-5134-421E-B3B6-DA739C18E54C@ifi.uio.no> <9209993E-7938-4D58-B3C0-967FA605C494@ifi.uio.no> <09F0C13E-EA17-4A7E-BA74-FFD36D1CD62D@ifi.uio.no> <285a7a58-20a9-2891-7a75-2f5ca404cc5d@isi.edu> <3DF69369-1782-4B36-8DB7-5B043B32134B@ifi.uio.no> <76C0A764-9EA1-4E73-8161-1C25306F6DE6@ifi.uio.no> <410aa055-f5bf-c9fb-ac1d-7ac020d686bd@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 7 sum msgs/h 3 total rcpts 53800 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.036, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 578D66B2D48616A8C9977CD05E051C16CE510435 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1125 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New Version Notification for draft-ietf-taps-transports-usage-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:34:51 -0000 No worries about the delay, but thanks! Michael > On Apr 13, 2017, at 9:32 PM, Joe Touch wrote: >=20 > Hi, Michael, >=20 > Sorry for the delay... >=20 >=20 > On 4/5/2017 11:54 PM, Michael Welzl wrote: >> BTW, >>=20 >> Just a quick last question, to make sure I get this right: >>=20 >>>>>> Oh, OK - then you would want to say that the keyID and nextkeyIDs = fall >>>>>> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section. >> When handing over the keyID and nextkeyIDs on SEND, this just means = that these new values are valid from the time SEND was called, right? = It's not tied to the specific data block that's being handed over? > Correct. They're not tied to data the way the URG pointer is or SCTP > authentications are. >=20 > Joe >=20 >> (I'm asking because that's a difference to SCTP, where it's possible = to decide to authenticate a particular data chunk that's handed over. = For TCP, this would be pretty unusual, I think, but perhaps also = implementable...) >>=20 >> Cheers, >> Michael >>=20 >=20 From nobody Tue Apr 18 07:20:25 2017 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 AD3281318B9 for ; Tue, 18 Apr 2017 07:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tum.de 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 CEmmCjnavJwH for ; Tue, 18 Apr 2017 07:20:21 -0700 (PDT) Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [IPv6:2001:4ca0:0:103::81bb:ff89]) (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 0248C12F17A for ; Tue, 18 Apr 2017 07:20:21 -0700 (PDT) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 3w6nN25LpBzyTf for ; Tue, 18 Apr 2017 16:20:18 +0200 (CEST) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=tum.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tum.de; h= mime-version:content-transfer-encoding:content-id:content-type :content-type:content-language:accept-language:message-id:date :date:subject:subject:from:from:received:received:received :received; s=postout; t=1492525217; bh=tlVMIvYdwalqgvbYvmfmIY1sk 2CcNdEen2TMc0ov5DQ=; b=aUgde3X5s5LZFcoNupTfYR/tsRGVNlvCgnIWePZ6i 9OJewcDRoY55hd/NBDi63I7blrhS/nlvRdQbdNxQlMLhzyrQHPcgowBVicQelyu9 WczmlX+HL3hzxQp+ezjFCDf2N1dZ9S4UFg59d71ScH6iG2nYkU0tiY2Nfh3wmf2/ vfNZwU6O6+3U8dPr5NKyK1yQmbJk9EmDlX+W8IRejPwv9xapQPGTXzayO3kVVAmj FVWAIlM/2jJLHK5o1YNLPEcOr5NAsvz+mYlFz0+sOL4HRIQFKNJ9lN9EP4yTm0YU DpCal8FEERhQHHVmsiwBLrIo9dBlxBNaC62jzagVQZXsg== X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id 53nIbPdTwOFw for ; Tue, 18 Apr 2017 16:20:17 +0200 (CEST) Received: from BADWLRZ-SWMBX05.ads.mwn.de (unknown [IPv6:2001:4ca0:0:108::161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "BADWLRZ-SWMBX05", Issuer "BADWLRZ-SWMBX05" (not verified)) by postout1.mail.lrz.de (Postfix) with ESMTPS id 3w6nN16hw7zySb for ; Tue, 18 Apr 2017 16:20:17 +0200 (CEST) Received: from BADWLRZ-SWMBX02.ads.mwn.de (2001:4ca0:0:108::158) by BADWLRZ-SWMBX05.ads.mwn.de (2001:4ca0:0:108::161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.669.32; Tue, 18 Apr 2017 16:20:12 +0200 Received: from BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b]) by BADWLRZ-SWMBX02.ads.mwn.de ([fe80::19fa:4919:5296:5c3b%14]) with mapi id 15.01.0669.032; Tue, 18 Apr 2017 16:20:12 +0200 From: "Bajpai, Vaibhav" To: "taps@ietf.org" CC: "Bajpai, Vaibhav" Thread-Topic: review: draft-grinnemo-taps-he-02 Thread-Index: AQHSuE7kyIpfpltlPUWzq2nLmLE6GA== Date: Tue, 18 Apr 2017 14:20:12 +0000 Message-ID: <15976658-97f5-4080-a332-f539648b4b6e@BADWLRZ-SWMBX05.ads.mwn.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [131.159.24.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <37A8007A80FC684684AB2FEB4CF4A439@ads.mwn.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Taps] review: draft-grinnemo-taps-he-02 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 14:20:24 -0000 > Title: Happy Eyeballs for Transport Selection > URL: https://www.ietf.org/internet-drafts/draft-grinnemo-tap= s-he-02.txt Overall, I like this document (suggestions for improvements below). I hope = an HE mechanism helps get future transport protocols get wider adoption. -- Vaibhav To be compliant with RFC 6555 [RFC6555], the Policy Management component SHOULD, in those cases there are no policies telling otherwise, give prio= rity to IPv6 over IPv4. -- RFC 6555 does not give priority to v6. Yes, this was the original motivation for the document, but RFC 6555 states that the priority is dicta= ted by the address selection policy [RFC 6724]. In majority of the scenarios th= is boils down to giving priority to native v6. However, if a host has native v= 4 and Teredo connectivity, a HE implementation will happily give priority to native v4 over Teredo. To minimize the number of connection attempts that are initiated, the Transport Probing component SHOULD cache the outcome of connection attempts in a repository kept by the Policy Management component. Cached connection-attempt results SHOULD be valid for a configurable amount of time after which they SHOULD expire and have to be repeated. -- How long should this cache be? How is this configured? D then governs the delay between the initiation of the connection attempts C1 and C2. -- how is delay D determined? For the Transport Probing component to be able to efficiently use the connection-attempt cache, already-initiated, non-winning transport soluti= ons SHOULD NOT be terminated as soon as a winning connection has been establi= shed. -- I found this sentence confusing. Perhaps an example helps here. As pointed out in RFC 6555 [RFC6555], a HE algorithm should not waste networking resources by routinely making simultaneous connection attempts. To this end, the HE algorithm should cache the outcome of previous connection attempts to the same peer. The impact and efficiency of the HE algorithm has been evaluated in [Papastergiou16]. The paper suggests that caching significantly reduces the CPU load imposed by a HE mechanism. -- Perhaps make it clear that [Papastergiou16] discusses the impact of memo= ry and cpu resources on the end-host and not networking resources on the wi= re. Consider a scenario in which an IPv4-only client using the ... -- Why not v6-only client instead? :) -- It was unclear to me how the the list of candidate protocols is generate= d by the policy manager. An example would help here. I am even thinking perhaps this is out of scope of this document. -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany --------------------------= From nobody Tue Apr 18 08:09:47 2017 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 5EF4312EBBE; Tue, 18 Apr 2017 08:09:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: aafalk@akamai.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149252818530.16104.623596981792110863.idtracker@ietfa.amsl.com> Date: Tue, 18 Apr 2017 08:09:45 -0700 Archived-At: Subject: [Taps] taps - New Meeting Session Request for IETF 99 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 15:09:45 -0000 A new meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: maprg dispatch tcpm iccrg tsvwg ippm rmcat aqm tsvarea appsawg apparea quic Second Priority: webpush tcpinc nvo3 mptcp icnrg httpbis irtfopen Third Priority: mmusic tram People who must be present: Aaron Falk Michael Welzl Gorry Fairhurst Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Mirja Kuehlewind Tommy Pauly Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Apr 19 06:02:51 2017 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 D6897129548 for ; Wed, 19 Apr 2017 06:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.onmicrosoft.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 k8auDxKDZZeQ for ; Wed, 19 Apr 2017 06:02:42 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 285B212954A for ; Wed, 19 Apr 2017 06:02:42 -0700 (PDT) X-AuditID: c1b4fb2d-88bff70000004c5d-67-58f75fee4fc8 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id B7.98.19549.EEF57F85; Wed, 19 Apr 2017 15:02:40 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 19 Apr 2017 15:02:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y4FoRDKNifsYvrtARo6Mn1evLIq9K3ruC/wx19T5E4U=; b=IQQGkMlvBTyK57n+hMBMPixpjYHOd1Q2UCene+rWCO/ge4YzqZzcSAHG9SACRQT0sNq1y8bQowVUcUC4GCUTqcgiVLq2hfvQZdUc+pMa/mytUfLkmgS0ckSnFypspRCpz2PlLOY2OyGWqRZzqvsrOW9uvR4HJPLPx8PxwLMgZh0= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 13:02:38 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::7da3:c855:ffb:552b]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::7da3:c855:ffb:552b%18]) with mapi id 15.01.1047.008; Wed, 19 Apr 2017 13:02:38 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: IETF98 meeting minutes uploaded Thread-Index: AdK5DSIac37xQbSvR/SDhnSJC7+0JA== Date: Wed, 19 Apr 2017 13:02:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [109.225.125.147] x-microsoft-exchange-diagnostics: 1; AM3PR07MB292; 7:cWcWVF0BQddr55VRSw2umzp/bzHczKE2XluTl2AauIZel+bOOYRw5/RL5U5ZQ+xzd2CasQZJDEO8E9KSSb7OrupZPeMzgZYSxvs+dUVmeJqcDrE5WiNghZQLNG1h6YjLyBboS+p5Zt6VhxR7ouhNkjiz2yDH3xTBIATU26n/+7DO62qgRVQBQ9C7Tvw1/wXzmN5PPrwMBF4eedtsp8XALolTKptjYQClmobRHzyMeTmYW6D50FDsLRqM+J5RN3iYe9dBH5QNaGhHhdZLpdBm8Yyl8ASMPcHXu8JsydRx05xGWcUIN8TxvhCVZOHD3uR5M8c0uujfakmcdP8OTuYgjw== x-ms-office365-filtering-correlation-id: f09f77ab-a82f-4285-d6f4-08d487245aff x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM3PR07MB292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:AM3PR07MB292; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB292; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39860400002)(39840400002)(39450400003)(39850400002)(53754006)(5660300001)(66066001)(6506006)(2900100001)(38730400002)(3280700002)(86362001)(54356999)(50986999)(33656002)(5250100002)(6916009)(5640700003)(2501003)(3660700001)(110136004)(2906002)(6436002)(7696004)(966004)(102836003)(53936002)(7736002)(99286003)(3846002)(9686003)(6116002)(2351001)(55016002)(305945005)(25786009)(6306002)(189998001)(74316002)(8936002)(8676002)(1730700003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB292; H:AM3PR07MB292.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB2924FDB8F302308DE7A75D89F180AM3PR07MB292eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2017 13:02:37.9579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB292 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUyM2J7lO6H+O8RBg07lCzuxDgweixZ8pMp gDGKyyYlNSezLLVI3y6BK2PPySNsBT08FStWbGdsYLzF1cXIySEhYCLRv2MhSxcjF4eQwHpG iS+LDrGCJIQETjBKvHjlCJJgEehlljg5p4MRomoak8TPO8eYIZz7jBIPf78Ecjg42ARsJB4v 9gPpFhFQlri8fyMbiC0soCHRee0AI0RcV2LFlW8sELaeRM/Ju+wgrSwCqhIr5yuBhHkFoiR2 vlsAdgSjgJjE91NrmEBsZgFxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/rCDnMAp0M0p8mHcNqkhZ YsuRmUwgCQmBbmaJTye6oBK+Eg8//wJbLCFQK3FlTSREOFOi4d43qBIriY6Jx1khes8zSSzd OpEdIiEj0X92BlSinVVi5Y8mRogvpSTuXumEsmUkXtzZywpxdr7E+bsrmSBeE5Q4OfMJC8Sg AImfcz4yTWBUnYXku1lIWmYhaYGI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uL c9ONjPVSizKTi4vz8/TyUks2MQLTzMEtv3V3MK5+7XiIUYCDUYmH94H0twgh1sSy4srcQ4wS HMxKIrzrPnyNEOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9ChJBAemJJanZqakFqEUyWiYNT qoHRMSqt4c/GPsYbi9eZ+y94LbLp6Job3z8/nOmjFH5o5XJO989Bj0If/DeVanu3ba2SQXfy RU/NRqWw2Fih7mm6F18bdn6Ou2eRK+tgpfpejK83Jtw42Pev6rzdR/8fuBR36ZrAj8b3/7iV 42T/vn1s+1VptqOaR9sP0533fr9O0Ty75qOhhMhtJZbijERDLeai4kQAxAVCZy8DAAA= Archived-At: Subject: [Taps] IETF98 meeting minutes uploaded X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 13:02:50 -0000 --_000_AM3PR07MB2924FDB8F302308DE7A75D89F180AM3PR07MB292eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, Now you can access the meeting minutes from IETF98 here (https://www.ietf.o= rg/proceedings/98/minutes/minutes-98-taps-00.txt) Please have a look and send correction if required. BR Zahed and Aaron --_000_AM3PR07MB2924FDB8F302308DE7A75D89F180AM3PR07MB292eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi everyone,
 
Now you can access the meeting minutes from IETF98 here (https://www.ietf.org/proceedings/98/minutes/minutes-98-taps-= 00.txt)
 
Please have a look and send correction if required.
 
BR
 
Zahed and Aaron
 
 
 --_000_AM3PR07MB2924FDB8F302308DE7A75D89F180AM3PR07MB292eurprd_-- From nobody Wed Apr 19 07:00:43 2017 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 85D30129A96 for ; Wed, 19 Apr 2017 07:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIMHORPpqgng for ; Wed, 19 Apr 2017 07:00:40 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 E8B90129A92 for ; Wed, 19 Apr 2017 07:00:39 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id h67so20640379qke.0 for ; Wed, 19 Apr 2017 07:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=aOSFjFfp8Kylvt4gq91Ji9lzMh6KwwrOmDj1w9ON0R8=; b=IyW43cc4kwvBjAEeqLl/7ao90tPM3nogpQysPOANjXXY/nuUR1XqydIIkk0wgnXVfc 6982rksZpwDyWey3EllAOhFTaFagzO3NhPrLkrsDYdxqVuLdXXB+EkhKIBy+639zc3Gs DddMLB7lwQuT/y5R+uh2ihepr2VSGK8xRHeyVnUqWew5yGjTZnaX1RkdMCtvDeohJ9vP XpV/3qaVFxKzMIShdnR295/NdJK6YtsJlTqLoiWSQCeDsGJIeF1V1AxQxBEQPpn0BS0o w8E8B6le2cuRfos0WWO+u2kJTgnN9lmmymI6jB87peEHT1d3ya3gRhL92SHfatLvqnKz rOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=aOSFjFfp8Kylvt4gq91Ji9lzMh6KwwrOmDj1w9ON0R8=; b=NPSByzd3wrpsLuXQhtawxSiCyLzYmIEoGORwR7lm2RC974LW4vMn3tZ58VXWnH2Hph XByzjDawk3Ky9P2OSydeyrz7UtOSrB/VCNbmlRpeKCy7evXYBqbZC5PcjfykDcAEF8zY /bVp/9z2u2tmJk733IfzAk/x87+SmPBl4Wwo9UvQUKEFw6DHE80JjKBui82AyZCSmUj1 22lyWo8k01LWOr3IVpdu/8kYeauhbngZN+gD6ruyE7kaCXZcHRmSjyP+IU9ktPeC5oQV 343y4mtVYInzsnSYsHiaMDffyO/qroHKHyCQqB4l72c6/z+7MArUuvYbOsH42cg39VKv jpgQ== X-Gm-Message-State: AN3rC/6f/v1wsNSEEKZJQHFuvP45+sJA5bFimKh58djmtPxiA2pWHjOz uU2knRBFcAqASU3NZBI= X-Received: by 10.55.17.84 with SMTP id b81mr2604622qkh.167.1492610438683; Wed, 19 Apr 2017 07:00:38 -0700 (PDT) Received: from [172.19.35.43] ([2001:4878:8000:60:48d1:c44d:44d4:b83c]) by smtp.gmail.com with ESMTPSA id 1sm1898601qty.69.2017.04.19.07.00.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Apr 2017 07:00:37 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 19 Apr 2017 10:00:36 -0400 Message-ID: <11900EDB-ED8F-48F9-BD0C-0C1994C4FD1A@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_64562075-CE92-46CD-9984-3410BC619DF0_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: [Taps] adopting draft-gjessing-taps-minset X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 14:00:41 -0000 --=_MailMate_64562075-CE92-46CD-9984-3410BC619DF0_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Hi folks- In Chicago we discussed adopting the above-named draft as a wg doc for milestone #2. There was a small amount of support and no objections. I think folks aren’t that interested in milestone #2 but it does create a useful tool for guiding TAPS implementations. This is a call for discussion pro or con on TAPS adopting this draft. Relevant excerpt from the Chicago minutes below. —aaron ____ 2.2 draft-gjessing-taps-minset-04 , Stein Gjessing * Call for adoption * Aaron: call for hands of people who read the draft * 2 raised hands * Gorry: read the draft. Document seems as it should be. Not controversial. If the WG want a document in this space then it should be adopted. * Tommy Pauly: Agree with that. Certain parts in the discussion area that we should have more discussion on; word-smithing needed. A good thing to adopt: it has the right core in it. * Aaron: anybody from remote has a say on this? * Brian Trammell: "Yeah, do it." * Hannes Tschofenig: one question on scope, Are you trying to cover security layer into account? Shouldn't this cover security? for IoT any API document includes guidance for DTLS would be useful. * Aaron: Tried to get someone from security directorate to participate, but no one did, so we stuck with the stuff we knew. Would be useful to have an equivalent of TAPS that handled security stuff * Tommy: Any practical API guidance will need to include security. Can't leave it out. Is it possible to have another draft in TAPS that is the minset of security features * Aaron: might be a charter scope change, but might be entirely appropriate * Tommy: would try a draft with min-set format to include security features. * Aaron: Hannes would you be interested in this? yes. lets talk about it in the next meeting. * Gorry: Originally security was in-scope. would be cool to look at such draft. --=_MailMate_64562075-CE92-46CD-9984-3410BC619DF0_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi folks-

In Chicago we discussed adopting the above-named draft as= a wg doc for milestone #2. There was a small amount of support and no o= bjections. I think folks aren=E2=80=99t that interested in milestone #2 = but it does create a useful tool for guiding TAPS implementations. This = is a call for discussion pro or con on TAPS adopting this draft. Relevan= t excerpt from the Chicago minutes below.

=E2=80=94aaron

2.2 draft-gjessing-taps-minset-04 , Stein Gjessing

  • Call for adoption

  • Aaron: call for hands of people who read the draft

    • 2 raised hands

  • Gorry: read the draft. Document seems as it should be= =2E Not controversial. If the WG want a document in this space then it sh= ould be adopted.

  • Tommy Pauly: Agree with that. Certain parts in the di= scussion area that we should have more discussion on; word-smithing neede= d. A good thing to adopt: it has the right core in it.

  • Aaron: anybody from remote has a say on this?

  • Brian Trammell: "Yeah, do it."

  • Hannes Tschofenig: one question on scope, Are you try= ing to cover security layer into account? Shouldn't this cover security? = for IoT any API document includes guidance for DTLS would be useful.

    <= /li>

  • Aaron: Tried to get someone from security directorate= to participate, but no one did, so we stuck with the stuff we knew. Woul= d be useful to have an equivalent of TAPS that handled security stuff

    =

  • Tommy: Any practical API guidance will need to includ= e security. Can't leave it out. Is it possible to have another draft in T= APS that is the minset of security features

  • Aaron: might be a charter scope change, but might be = entirely appropriate

  • Tommy: would try a draft with min-set format to inclu= de security features.

  • Aaron: Hannes would you be interested in this? yes. l= ets talk about it in the next meeting.

  • Gorry: Originally security was in-scope. would be coo= l to look at such draft.

--=_MailMate_64562075-CE92-46CD-9984-3410BC619DF0_=-- From nobody Sat Apr 22 03:46:29 2017 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 CE5CE129416 for ; Sat, 22 Apr 2017 03:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 kg52M2OZgEwY for ; Sat, 22 Apr 2017 03:46:25 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6381A129483 for ; Sat, 22 Apr 2017 03:46:25 -0700 (PDT) Received: from [192.168.1.6] (unknown [87.66.240.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A1B7D67DCF0; Sat, 22 Apr 2017 12:46:14 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp5.sgsi.ucl.ac.be A1B7D67DCF0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1492857974; bh=RB8hyguWg7xkN1HNmcKBxMCEuAelHMNBNAhjQo6qs0c=; h=Reply-To:Cc:From:Subject:To:Date; b=qxSObPWbX95F12wS21Ptgwx2lCq5OgZutjZivWrp4uo88WigAAmAtQIDl4M09aJfZ UcOwkOapLGHGXr5FJNVH7E3Zagc/PIozs0JDeYZZ06uJPyXL6nMKpFsAh8YeQ4u+AM 8OCOQrHM4U+ANd36cPZM5Xfz7KFlFV483KL/iV8o= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-5 Reply-To: Olivier.Bonaventure@uclouvain.be Cc: Gregory Vander Schueren From: Olivier Bonaventure To: taps@ietf.org Message-ID: <7ed865f2-8dec-dba0-10fe-ecf567327978@uclouvain.be> Date: Sat, 22 Apr 2017 12:46:14 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: A1B7D67DCF0.A56BB X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [Taps] Analysis of the socket APIs in the wild X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2017 10:46:28 -0000 Hello, I haven't followed the discussions within the TAPS working group closely, but I think that you could be interested by some ongoing work from one of our students, Gregory Cander Schueren. He has developped an open-source application, tcpsnitch, that allows to collect lots of statistics about how real networked applications use the socket and related APIs to interact with the underlying network stack. The software runs on Linux and Android and currently collects mainly information about the interactions with UDP, IP and TCP. You can download it from https://github.com/GregoryVds/tcpsnitch and use it with your favorite applications on Linux or Android. All the data collected by the software is available on https://tcpsnitch.org and this website provides a first set of statistics and graphs about the collected dataset. I think that information about how real applications interact with the underlying TCP/IP stack could be valuable for the work performed within this working group. If you have ideas or suggestions for additional analysis, feel free to contact Gregory directly Best regards, Olivier