Re: [Stackevo] Fwd: New Version Notification for draft-trammell-stackevo-newtea-00.txt
Ted Hardie <ted.ietf@gmail.com> Thu, 12 March 2015 21:00 UTC
Return-Path: <ted.ietf@gmail.com>
X-Original-To: stackevo@ietfa.amsl.com
Delivered-To: stackevo@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6C71A90AC for <stackevo@ietfa.amsl.com>; Thu, 12 Mar 2015 14:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable
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 4-sdDUYWKFVR for <stackevo@ietfa.amsl.com>; Thu, 12 Mar 2015 14:00:27 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811B51A90AA for <stackevo@iab.org>; Thu, 12 Mar 2015 14:00:27 -0700 (PDT)
Received: by igal13 with SMTP id l13so2459328iga.1 for <stackevo@iab.org>; Thu, 12 Mar 2015 14:00:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l+p3V4Zqw32uR0e9qYqpU/9b75oybILBuNUOY6eV67A=; b=X4qZqomJJ8tfz8KTZkQdGhIfvC4siUUAZppumWlPSEnDxbw63dalqiqUvoLIyoB0Oe ypBIaNgsh+JDnrYHtl/WYLX5+2ua8qQ9gtmH6AZK99y/wBTnVnCjhvORyqreFOOErL+c XvGCcC3OKjcSoPT8sgJj1wYrBretN57OPU/q/I9RNV2SBbye1hnIbp7KSwPlKpxCfOXy OiciO/LhY3vD3jeTw4bM8wOYIrzxdaXcY3+5GSXNeLWCHJB4d3fZZaUyKERm1SHvP6mS 3s/H+n1fXGGmsFbmryFHp3Vcl5kGcb2zLZZGz/tCmT5ojPjYsj9cT0dUz0q+07fkl4wN fTIA==
MIME-Version: 1.0
X-Received: by 10.107.167.145 with SMTP id q139mr79232745ioe.16.1426194026886; Thu, 12 Mar 2015 14:00:26 -0700 (PDT)
Received: by 10.42.129.17 with HTTP; Thu, 12 Mar 2015 14:00:26 -0700 (PDT)
In-Reply-To: <B9D785C7-A559-4CC2-B52C-BF63146B65C6@trammell.ch>
References: <20150309174102.19512.93730.idtracker@ietfa.amsl.com> <B9D785C7-A559-4CC2-B52C-BF63146B65C6@trammell.ch>
Date: Thu, 12 Mar 2015 14:00:26 -0700
Message-ID: <CA+9kkMD9=dP+gqrPPZZLty5xHhU9jCCE-OsNT-EazJ3SJqwiSg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary="001a114299905a7e6a05111dacbd"
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo/H7-bdovqQ3upHqYWqZpppnFBDUM>
Cc: stackevo@iab.org, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Stackevo] Fwd: New Version Notification for draft-trammell-stackevo-newtea-00.txt
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IP Stack Evolution Program Mailing List <stackevo.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo>, <mailto:stackevo-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/stackevo/>
List-Post: <mailto:stackevo@iab.org>
List-Help: <mailto:stackevo-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo>, <mailto:stackevo-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2015 21:00:30 -0000
Hi Brian, Thanks for throwing something together (and it's amusing to see a draft which declares itself to have been done "a few minutes before" the deadline). Two thoughts, just as quick: First, you make an important observation about the scope of comparison, but you've buried it a bit. You note that declarative marking aims "to treat all markings on packets and flows as relative to other markings on packets and flows from the same sender". That should get a much bigger play in the next version, I think, as it both explains why the incentive to lie is no longer present and has a huge impact on the system. Per-sender comparative state make sense in some contexts (the scheduler in a browser, based on traffic from tabs, for example), but it gets harder and harder as you increase the number of senders and in some contexts may simply be too expensive. Doing this in contexts where you are already doing packet or flow state manipulation seems the likely target of this work, and it may be best to make it more explicit. The second thought is around reputation. There's a lot of experience with reputation systems that suggests that the ability to mint new identities and the ability to assign reputation are in conflict. NAT, DHCP-reassignment, new IPv6 privacy addresses and many other issues make assigning this reputation to IP-layer addresses problematic. Doing it at above that layer with a long-lived cryptographic token has very serious privacy implications and doing it without one means you can mint an identifier freely. A reputation that lasts for the duration of the flow doesn't have these issues, and it may be the best we can do at the moment. Thanks again for kicking off the discussion, Ted On Thu, Mar 12, 2015 at 3:00 AM, Brian Trammell <ietf@trammell.ch> wrote: > Greetings, all, > > Shortly before the Monday deadline, I threw together a couple of thoughts > into a document that might eventually evolve into a more architectural view > of the vocabulary of the things we can expect to be able to deployably say > with SPUD (separate from the current discussion on the scope of the tube > ID). This follows from discussions about trying to keep markings > declarative. > > Comments welcome. > > Thanks, cheers, > > Brian > > > Begin forwarded message: > > > > From: internet-drafts@ietf.org > > To: "Brian Trammell" <ietf@trammell.ch>, "Brian Trammell" < > ietf@trammell.ch> > > Subject: New Version Notification for > draft-trammell-stackevo-newtea-00.txt > > Date: 9 Mar 2015 18:41:02 CET > > > > > > A new version of I-D, draft-trammell-stackevo-newtea-00.txt > > has been successfully submitted by Brian Trammell and posted to the > > IETF repository. > > > > Name: draft-trammell-stackevo-newtea > > Revision: 00 > > Title: Thoughts on New Transport Encapsulation Approaches > > Document date: 2015-03-09 > > Group: Individual Submission > > Pages: 6 > > URL: > http://www.ietf.org/internet-drafts/draft-trammell-stackevo-newtea-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-trammell-stackevo-newtea/ > > Htmlized: > http://tools.ietf.org/html/draft-trammell-stackevo-newtea-00 > > > > > > Abstract: > > This document presently consists of a collection of unordered > > thoughts about new approaches to using encapsulation in support of > > stack evolution and new transport protocol deployment in an > > increasingly encrypted Internet. It aims eventually to enumerate a > > set of architectural assumptions for transport evolution based upon > > new encapsulations, and discuss limitations on the vocabulary used in > > each of these new interfaces necessary to achieve deployment > > > > > > > > > > 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 > > > > > _______________________________________________ > Stackevo mailing list > Stackevo@iab.org > https://www.iab.org/mailman/listinfo/stackevo > >
- [Stackevo] Fwd: New Version Notification for draf… Brian Trammell
- Re: [Stackevo] Fwd: New Version Notification for … Ted Hardie
- Re: [Stackevo] New Version Notification for draft… Brian Trammell
- Re: [Stackevo] New Version Notification for draft… Ted Hardie
- Re: [Stackevo] [Spud] New Version Notification fo… Szilveszter Nadas