Re: [TLS] ECH & HPKE versions as an example of too much githubbery

[Eric Rescorla <[e-mail]>]

On Tue, Oct 27, 2020 at 4:20 PM Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> On 27/10/2020 23:06, Eric Rescorla wrote:
> > On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
> > <[e-mail]> wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 27/10/2020 22:28, Mark Nottingham wrote:
> >>> Stephen,
> >>>
> >>> I don't think what you're complaining about can be attributed to
> >>> GitHub. Tools are just tools, how they're used is what's
> >>> relevant (i.e., this could just as easily happen over e-mail).
> >>
> >> Sorta. I doubt the volume of traffic would've happened via email
> >> for non-contentious, not-trivial-but-not-earthshaking topics.
> >>
> >> I "watch" the repos for these drafts, and in just the last month,
> >> I've seen 401 esni emails, 127 hpke emails and 157 dns-alt-svc
> >> emails. That's too many, is encouraged by the tools IMO and has to
> >> mean a lot not being discussed on the list that ought be.
> >>
> >> So I do think the tooling is really part of this. But yes, had
> >> someone taken on the mega-task of bringing the useful bits of those
> >> 683 mails per month to the list, it may have been that the mismatch
> >> would've been avoided.
> >>
> >
> > This seems to me like it makes the argument for the tooling. Namely
> > that it enables low friction participation on details.
>
> It enables that for *some* whose workflow that matches.
> That is not the IETF process (yet).


In fact, it *is* the IETF process, or rather one permitted IETF process,
since RFC 8874. If you think the chairs are not following the IETF process,
I would encourage you to contact the AD rather than arguing with me.


> Trying to do interop now is at your own risk.
>
> That's a non-answer. I didn't claim any loss so risk isn't
> relevant. It's being denied the opportunity to implement by
> the continually moving target that is my problem, not a
> risk nor financial loss.
>

And what I'm saying here is that specifications go through stages where
they are stable enough to implement and other stages where they are in flux
and people should hold off on implementing, or at least trying to get
interop. Currently, we are in the latter period.


Mozilla implemented -02, but not, so far as I recall, later
> versions. It's been two years since -02 was published.


Yes. We've been waiting for the spec to stabilize to the point where it was
worth cutting a new version. We are now working on that.



> I don't think
> we've come that far at all since (there are
> modest improvements but not two years worth) and I do
> think the tooling is responsible for some of those delays,
> certainly this year.
>

Yes, I appreciate that that's your opinion. It's not mine.

-Ekr