Re: [Stackevo] [IAB] draft-hardie-path-signals and draft-trammell-wire-image

"Brian Trammell (IETF)" <ietf@trammell.ch> Fri, 06 April 2018 10:01 UTC

Return-Path: <ietf@trammell.ch>
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 66831126DD9; Fri, 6 Apr 2018 03:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j4FOsGhEtRL; Fri, 6 Apr 2018 03:01:15 -0700 (PDT)
Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A35126D0C; Fri, 6 Apr 2018 03:01:14 -0700 (PDT)
Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D61143404FB; Fri, 6 Apr 2018 12:01:12 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.31864); Fri, 6 Apr 2018 12:01:12 +0200 (CEST)
Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 6 Apr 2018 12:01:12 +0200 (CEST)
Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 50844431; Fri, 06 Apr 2018 12:01:12 +0200
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
Message-Id: <0CB88447-0F7C-4A8E-BE70-7CDF29C9FCE9@trammell.ch>
Content-Type: multipart/signed; boundary="Apple-Mail=_C8B602F2-61EE-404D-BA58-9E3CE9E3A07B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Fri, 06 Apr 2018 12:01:11 +0200
In-Reply-To: <1641F7D4-E7E9-4A8D-88F2-3A07A0082AFD@mnot.net>
Cc: Stack Evolution Program <stackevo@iab.org>, IAB IAB <iab@iab.org>
To: Mark Nottingham <mnot@mnot.net>
References: <C986EAB5-CFE3-49AF-A19A-B087E63EE365@trammell.ch> <1641F7D4-E7E9-4A8D-88F2-3A07A0082AFD@mnot.net>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/uIPYIj33dUdSxRyPAaVIZFNuo3Y>
Subject: Re: [Stackevo] [IAB] draft-hardie-path-signals and draft-trammell-wire-image
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.22
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: Fri, 06 Apr 2018 10:01:18 -0000

hi Mark,

Answering -wire-images questions only in this reply...

> On 5 Apr 2018, at 02:55, Mark Nottingham <mnot@mnot.net> wrote:
> 
> Hi Brian,
> 
> 
>> On 4 Apr 2018, at 6:50 pm, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>> 
>> Greetings,
>> 
>> After discussion at our Friday morning London meeting (and thanks, all, on the program for your remarkable  Stack Evolution Program would like the IAB to consider two documents for publication on the IAB stream:
>> 
>> https://tools.ietf.org/html/draft-trammell-wire-image-03
> 
> I like this document. Two comments:
> 
> * 1. Introduction seems to skip around a discussion of whether participants in lower-layer protocols are also participants in "higher" layer protocols -- i.e., is participation transitive?

Hm, this is a good point...  I looked at this for a while, though, and I couldn't come up with text here without going down a side-tracked philosophical rabbit hole; suggestions?

> * 3.3.1. Invariants begs the question of what networks will do with the parts of the message that are *not* invariant, and the resulting strategies that protocol designers might take -- i.e., some form of encryption, greasing, etc. Not sure if we intend to publish a separate doc here, but it might be worth mentioning.

I've added some text here to the working copy (https://britram.github.io/draft-trammell-wire-image/draft-trammell-wire-image.html#rfc.section.3.3.1) -- is this what you had in mind?

Thanks, cheers,

Brian