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

[Mark Nottingham <[e-mail]>]

Hi Brian,


> On 4 Apr 2018, at 6:50 pm, Brian Trammell (IETF) <[e-mail]> 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? 

* 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.

> https://tools.ietf.org/html/draft-hardie-path-signals-03

Section 3 seems very good; the rest seems very... tentative. That's probably appropriate, except:

* 4.3 Replace These With Per-Transport Signals - the last two sentences here seem very wishy-washy. In combination with 4.4, it feels like it's trying to steer towards a PLUS-like solution, but only justifying it in terms of vague impact upon ossification.

Also, in 5. Recommendations, do we want to say anything about whether a protocol should *enable* path elements to add signals (at least within the protocol's control)?


> The wire image draft describes what a protocol's wire image is, and explores the situations that arise when a protocol splits its visible wire image from the information it uses for its own operation. (It started as a draft I wrote during the extended Singapore plenary discussion on encryption of protocols, riffing off Ted's observation from the dais that protocols with explicit wire images were a completely new thing, in part to describe what I mean when I use the term.)
> 
> The path signals draft recommends that protocol machinery be confidentiality protected, and that any signal exposed to on-path devices (outside confidentiality protection) be *explicitly* so exposed and integrity protected. It reiterates that metadata injection is considered harmful.
> 
> Thanks, cheers,
> 
> Brian (stackevo lead hat)

Cheers,


--
Mark Nottingham   https://www.mnot.net/