Re: IAB wire-image work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Micheal,

One comment/question below:

> On 23. Mar 2019, at 16:41, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
> 
> 
> Ted Hardie <ted.ietf@xxxxxxxxx> wrote:
>> The Wire Image of a Network Protocol (draft-iab-wire-image)
> 
>> Both are products of the IAB’s Stack Evolution Program, which has been
>> considering the behavior of on-path network elements which observe
>> network flows, especially when these are encrypted.  
> 
> Thank you for this work.
> It is very interesting description.
> 
> I would have liked to separate out the definition of the wire image a bit
> From the value judgement that having a smaller wire-image is a good thing.

I don’t think the doc says that the wire image needs necessarily to be small.

This is in the draft:

“… the protocol's wire image should
   therefore be designed to explicitly expose information to those
   network functions deemed important by the designers in an obvious
   way.  The wire image should expose as little other information as
   possible.”

Which just says that you need to design the wire image carefully to only expose things you really want to expose and not expose (or at least minimise) anything else (wherever possible). 

Where in the draft did you read that the wire image needs to be small. If that is in there or could be misinterpreted that way, we should fix that.

Mirja



> 
> I read the document wondering if there was going to be a abstraction to
> document what the wire-image of a protocol is.  I saw no such thing, and
> probably such an effort might result in attempts to boil an ocean.
> 
> I then wondered as I read the document if some kind of "WIRE IMAGE
> CONSIDERATIONS" section might be suggested.   I have put "PRIVACY
> CONSIDERATIONS" headings in a few documents, and I know others have too.
> I think that the wire-image description could fit into such a section.
> 
> The document could have wistfully wondered if we'd have a different
> architecture had TCP made it's port numbers clearly invariant.
> The document could perhaps beat people over the head a bit harder in this
> area.
> 
> Thank you for this document.
> 
> --
> Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
> 
> 





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux