Re: [Edm] Please review draft-iab-use-it-or-lose-it-01

[Martin Thomson <[e-mail]>]

Hi Toerless,

Thanks for the review.

It's going to take me a little while to just read your email.  If there are specific items that you think need to be drawn out in particular, I would encourage you to open issues or new threads on just those.  It will be easy to lose things with an email this long.

I'm just going to reply to your meta-level comments here.  I might try to turn the rest of this into issues on the repository.

On Fri, Jul 16, 2021, at 01:46, Toerless Eckert wrote:
> I think it would be good to write that the problems an solutions likely
> fall all into three high level categories:
> 
> a) p2p protocol extension considerations.
> b) 3 or more party protocol extension considerations
>    (including middleboxes as supported parties).
> c) 2 or more party protocol considerations plus undesirable middleboxes.
> 
> Separating b) and c) is IMHO most important, 

I disagree.  The draft does acknowledge the fact that difficulty scales poorly as more protocol participants are involved, but this is not the focus of the draft at all.  The text exists to acknowledge that as a problem, but the core thesis is not that these are different but that they are _fundamentally_ the same.  The number of participants just scales the problem (often very quickly out of reach).

Your category (c) is almost out of scope.  The text on limiting unwanted participation is very narrowly focused here.  It only exists because it was necessary to point out that unprotected protocols can have more participants than expected and that - once the problem is identified - the most obvious solution seemed worth noting (not that it is always a *practical* solution, of course).

See also https://martinthomson.github.io/tmi/draft-thomson-tmi.html

> The other high-level suggestion is that at least in my opinion
> there is more that could be written about reasons.
> 
> IMHO: The deeper the extension point is within a protocol, and the
> more complex the protocols starte machienry reaction to
> unsupported extensions hs to be in the state machinery,
> the more difficult it is to make sure it will work correctly
> when needed. Of course, the most easy case is when you have
> extensible data structures signalled and some parts can
> just be ignored, but that is not always the semantic required.

I think that this is just a matter of degree.  Whether an extension point is hard to reach hasn't seemed to affect its availability in the cases we've gathered thus far.  It's whether people have been motivated to seek it and actively use it that has mattered.  It's not like the IP version field is hard to find or complicated.  And - not in the draft - arguably some of the extension points in SDP are harder to reach than others, but the hard ones (a=extmap) are often more reliable than the easy ones (RTP/SAVPF).