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

[Martin Thomson <[e-mail]>]

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: 

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
>