Re: [Stackevo] Next steps post-SPUD BoF

Brian Trammell <ietf@trammell.ch> Fri, 17 April 2015 09:44 UTC

Return-Path: <ietf@trammell.ch>
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 961471ACEA2 for <stackevo@ietfa.amsl.com>; Fri, 17 Apr 2015 02:44:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUriBMutH0F4 for <stackevo@ietfa.amsl.com>; Fri, 17 Apr 2015 02:44:09 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4C11A1A25 for <stackevo@iab.org>; Fri, 17 Apr 2015 02:44:08 -0700 (PDT)
Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id A1C081A0348; Fri, 17 Apr 2015 11:43:37 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_EA828C5C-9F21-4862-AF77-91A38363E4A2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b6
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <B75B87F8-CDC4-4484-A6A4-CFC03BBAB77B@ifi.uio.no>
Date: Fri, 17 Apr 2015 11:43:37 +0200
Message-Id: <2EF215A7-EB7A-4A2B-B956-091AEDB7F82F@trammell.ch>
References: <A03D8500-E6EC-4B37-AC77-31F47F8926EE@trammell.ch> <B75B87F8-CDC4-4484-A6A4-CFC03BBAB77B@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo/ZYsX7ZRypmfRW3Kyg9GwDGeGj9I>
Cc: "stackevo@iab.org" <stackevo@iab.org>
Subject: Re: [Stackevo] Next steps post-SPUD BoF
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: Fri, 17 Apr 2015 09:44:15 -0000

hi Michael,

sorry for the delay here, just realized a week had gone by...

> On 10 Apr 2015, at 15:48, Michael Welzl <michawe@ifi.uio.no> wrote:
> 
>> 
>> On 10 Apr 2015, at 15:28, Brian Trammell <ietf@trammell.ch> wrote:
>> 
>> Greetings, all,
>> 
>> First, I'd like to welcome Robert Sparks, Spencer Dawkins, Aaron Falk, and David Black to the IP Stack Evolution program!
>> 
>> Following a call between the SPUD BoF chairs and proponents earlier this week, it seems to us that moving toward forming a working group is not appropriate at this time. We're not doing engineering yet, and even forming a smallish WG to publish an experimental prototype protocol RFC would merely serve to reinforce the community's uneasiness expressed during the BoF about draft-hildebrand-spud-prototype becoming The Production SPUD Protocol with very little modification.
>> 
>> We have the beginnings of a set of research questions, mainly focusing on which information to selectively expose and incentives to do so, but there's not an RG charter there yet. (Indeed, in trying to figure out what of SPUD or SPUD-adjacent work *should* have a RG chartered around them, after a five minute conversation on IETF Friday afternoon, Mirja, Gorry, and I came up with "HOPS should be an RG." But that's a different thread.)
>> 
>> In short, we're still doing architecture, so the most appropriate home for this work right now is the IAB, and this program. Since the community is engaged in discussion on UDP encapsulation and middlebox cooperation on the spud@ietf.org list, we'll keep that discussion going, as well as discussion about experimentation with the SPUDlib prototype.
>> 
>> I have a document, draft-trammell-stackevo-newtea, which I'd like to see evolve into a set of architectural guidelines for encapsulations for transport evolution, following list discussion... this might be more appropriately named draft-xxx-spud-arch, since it what it really aims to talk about is "architecture for encapsulations that look like SPUD."  Also, following the example of the privsec program, I'd also like to select a "show runner" for the SPUD focus area; at this point, mainly to keep an eye on the list and to identify / find authors for anything we think might need to be a document coming out of that discussion.
>> 
>> Thoughts?
> 
> I like the idea of an RG a lot - not only HOPS but really also SPUD, because of the use cases. I haven't seen much convincing stuff there (in the "trust-but-verify" direction, I mean) and I think it can be done, and a RG seems to me to be a good basis for that?!

So the idea would be specifically to separate *what* to express in selective exposure approaches -- as opposed to any of the questions as to *how* -- and to work on this problem within an RG? Yeah, that's a good idea, though I'm not sure how separable the discussions will stay in practice, and I still think we'll need an experimental environment to play with these things.

(Would you be willing to help with draft RG charter language for such a group? ;) )

Other opinions on this within the program?

Thanks, cheers,

Brian

> 
> Cheers,
> Michael
> 
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo