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

[Tommy Pauly <[e-mail]>]

> On Jul 16, 2021, at 1:06 AM, Martin Thomson <[e-mail]> wrote:
> 
> Replying to myself.  Very bad form.  Sorry.
> 
> Hi again Toerless,
> 
> I started reading through your feedback and I found some of it really helpful.  I've made a bunch of edits in response.  If you are willing to review the following pull request, that would be great.
> 
> Here's a link: 

Since I don’t see the link in my email, here it is:

https://github.com/intarchboard/draft-use-it-or-lose-it/pull/52/files <https://github.com/intarchboard/draft-use-it-or-lose-it/pull/52/files>

> 
> I won't do a blow-by-blow response.  I'm afraid that I don't have that much time.
> 
> Just one note.  Throughout you mention authentication where the draft uses the word "cryptography".  My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things.  Are you perhaps reading that word with the narrow meaning of "encryption"?
> 
> Cheers,
> Martin
> 
> On Fri, Jul 16, 2021, at 17:14, Martin Thomson wrote:
>> 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).
>> 
>> -- 
>> Edm mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/edm
>> 
> 
> -- 
> Edm mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/edm