Re: [Spud] SPUD Scope?

[Szilveszter Nadas <[e-mail]>]

Hi,

>>Yes, the path is fraught with challenges; I don't disagree with most of 
>>your points.  On the other hand, call me an optimist, but I believe 
>>such a mechanism could not only help break the "ossification" logjam, 
>>but perhaps eventually shift the balance of power back toward the end 
>>users by giving them more choices w.r.t. network services.

I share the same belief.

I think that middleboxes must demonstrate their value for one of the ends in order to receive metadata. This is what I mean on them being explicit. However if they do demonstrate then I believe in giving them the information they want. 

I personally prefer that even without metadata a reasonable default service is available. How to achieve this is a good question. I guess regulators have bigger rule here than engineers. Though I believe that engineers are responsible to educate regulators to find the right path. Without the right regulation blocking when not getting metadata can always happen even if we make it harder with protocol design.

>I totally agree with you, as long as the underlying principles are:
>- explicit vs implicit service;
>- ability of endpoints to choose based on clear information about the service value vs leaked meta-data;
>- preservation of e2e security properties.
>
>I think the biggest (though not insurmountable) challenges are:
>- UX (as already noted by Daniel);
>- scale mechanism to n middle boxes.
>
>We probably need a good deal of research to solve scale and UX, and I hope stackevo has enough breath to account for this.

I agree. I am thinking about writing a draft along these lines and also include some example use cases with "good" cooperation examples.

Cheers,
Sz.