Re: [Stackevo] Breakfast Tuesday Morning

Eliot Lear <lear@cisco.com> Tue, 17 July 2018 12:29 UTC

Return-Path: <lear@cisco.com>
X-Original-To: stackevo@ietfa.amsl.com
Delivered-To: stackevo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDE0130E7F for <stackevo@ietfa.amsl.com>; Tue, 17 Jul 2018 05:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 0guqVaovPVSH for <stackevo@ietfa.amsl.com>; Tue, 17 Jul 2018 05:29:33 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E4A127333 for <stackevo@iab.org>; Tue, 17 Jul 2018 05:29:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4628; q=dns/txt; s=iport; t=1531830573; x=1533040173; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=PmEKc/NGJVx1MHrMUCCU6pqkeFxTzbLOfNjZfQ43JFM=; b=T51RIqjzsvTJbVNXwhbVf5bHx/ZrMoEa85SacB2u52x8yGv27mk6SEBA AkbxtwfkcXQFmdObupQ99Yi+Usthnm0P10l4/9ou5g1AqYdYZCOvzSAbP 0XYXvSBH25/2h1MjTOd7DZAq8eBuuNokRPHuwdQDarooS0RAuzkdd1Awn 8=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B4AQCi301b/xbLJq1cGQEBAQEBAQEBAQEBAQcBAQEBAYQsbRIog32IY41FJJU5gXoIAxgPg39GAoMRNRcBAgEBAgEBAm0cDIU2AQEBAQMBASFLFwQLEQQBAQEqAgInKAgGAQwGAgEBgxwBgWcDFQ+qRIEuhxMXgwwPixiBOAyCXoMZAQEBAoReglUCh12GJYtaCYNdgVlUiRcGggaGFoVJijmHW4FDATWBUjMaCBsVO4JpCYIbGINFhRSFQD0wAQEBjTwBAQ
X-IronPort-AV: E=Sophos; i="5.51,365,1526342400"; d="asc'?scan'208"; a="5168825"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jul 2018 12:29:31 +0000
Received: from [10.61.225.138] ([10.61.225.138]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w6HCTUxm021470; Tue, 17 Jul 2018 12:29:31 GMT
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>, Stackevo <stackevo@iab.org>
References: <5EE3F417-54D6-4F4E-8EC9-3F64B659A630@trammell.ch> <DM5PR2101MB08058BA800C417B5803E051DA35D0@DM5PR2101MB0805.namprd21.prod.outlook.com>
From: Eliot Lear <lear@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ==
Message-ID: <f11a3fe1-d1aa-331a-6411-d1cbdc79bdc9@cisco.com>
Date: Tue, 17 Jul 2018 14:29:30 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <DM5PR2101MB08058BA800C417B5803E051DA35D0@DM5PR2101MB0805.namprd21.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="DpxdFSv7FyvOWY6KMtRPxyQfPJ8gxkNFN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/Mm_y98AgOZUE12ul8ajqppDyJh0>
Subject: Re: [Stackevo] Breakfast Tuesday Morning
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 17 Jul 2018 12:29:36 -0000

Hi Dave,

I'm sorry I couldn't attend.  I think the draft is definitely timely and
worthwhile.  Maybe even overdue ;-). I particularly like your example on
slide 4.  One observation I would make: the IETF is in a good position
to codify the technical aspects of these schemes so as to keep them to a
minimum.  As a for instance. <hashofpublickey> doesn't seem to me to be
something that is particualrly unique to OCF.  What *could be* unique to
OCF is perhaps the algorithm that is used in the hash, but then perhaps
that is something that could be worked on if people care enough.

Anyway, just some thoughts.

Eliot


On 16.07.18 23:46, Dave Thaler wrote:
> Since undoubtedly someone will ask me to send pointers to this list after the discussion, I'll do so now.
> Pre-reading anything before the meeting is not required.
>
> Slides from IETF 99: https://datatracker.ietf.org/meeting/99/materials/slides-99-dispatch-mult-transport-uris-00
> Minutes from IETF 99 artarea discussion: https://datatracker.ietf.org/meeting/99/materials/minutes-99-dispatch-00
> Subsequent ART/URI-review thread (on one page): http://ietf.10.n7.nabble.com/art-Internet-Draft-Using-URIs-With-Multiple-Transport-Stacks-td538558.html 
>
> During the program meeting, I plan to talk to slides 2-3 of the deck above, and verbally summarize 
> what's in the other two links.  We can then discuss Adam's question to the IAB.
>
> Dave
>
> -----Original Message-----
> From: Dave Thaler 
> Sent: Sunday, July 15, 2018 4:52 PM
> To: 'Brian Trammell (IETF)' <ietf@trammell.ch>; Stackevo <stackevo@iab.org>
> Subject: RE: [Stackevo] Breakfast Tuesday Morning
>
> Brian Trammell writes:
>> feel free to propose a concrete topic of discussion
> I have a topic to propose.  
> draft-thaler-appsawg-multi-transport-uris is basically a problem statement, surveying various things people do today.
> It was reviewed by artarea/dispatch back at IETF 99 and had support (all issues raised so far have been addressed), and I've been talking to Alexey and Adam about AD-sponsoring.
>
> However, there's no actual recommendations, which would be a separate effort/doc, as discussed in artarea at IETF 99.
> The W3C TAG tried and failed to get any consensus, so I'm not optimistic the IETF could either (and I'm not sure whether the IAB could either for that matter).
>
> Adam wrote:
>> I'll bend the ear of various IAB members to see whether they think there's hope of making progress on the second document you mention.
> Since one of the main issues is how to deal with protocol stacks, it seems that the Stackevo program might the most logical program for such question.
>
> Dave
>
>
>
>
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo
>