Hiya,
On 28/10/2020 00:32, Sean Turner wrote:
Stephen, Given that there appears to be emerging consensus around the "issue discussion mode with email summaries sounds" presented in Chris' email from just last week can we let that settle?
My bet is that yes the WG will land on that bad answer. I contend that it is highly unlikely useful summaries of the barrage of githubbery can be regularly generated, unless some of those messaging there decide to send mail to the list as needed and allow time for responses from those with other things to do that hour. (That's not a thing within WG chairs' power to grant of course but it would be nice.) I'd be much happier about all that if someone would go back and do that summarising for e.g. the last month's traffic. I suspect that poor person would find the task hard or maybe give up. I encourage anyone to take a look and see how easy/hard they think that might be. (Just to be clear: I don't think anyone here is trying to be a bad actor - I figure it's more a case of understandably not taking into account that there are more people involved in the WG's work than are active in a particular way on github. Still, there is "not taking into account" going on, so not all's well.)
We can certainly get a summary together - granted there have been interim meetings with published minutes [0][1].
Those are fine. No complaint from me there. (Albeit that I had to miss some, but that was my problem.)
We could also adopt an approach similar to the QUIC WG where they would declare a particular draft version one that they would run interop on. We would need to decide on the process of declaring what that version was as well as moving to the next version.
I think that would be good, yes. Just pick some iterations and get agreement that enough people will implement and do enough testing to be useful and take enough results into account in the next iteration. Lotsa judgement needed but not a showstopper. Way better than the current situation IMO so yes please try direct us in that direction if you can. Cheers, S. PS: I got another 8 mails wrt the esni draft since I sent the earlier numbers. One of those had some human readable content maybe, though it was context-free in that context;-)
[1] https://datatracker.ietf.org/doc/minutes-interim-2020-tls-03-202009210800/spt [0] https://datatracker.ietf.org/doc/minutes-interim-2020-tls-02-202009031000/
On Oct 27, 2020, at 16:31, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: Hiya, The latest ECH draft from Oct 16 says "ECH uses draft-05 of HPKE for public key encryption."The latest HPKE draft (-06) from Oct 23 has a few minor incompatible changes (for good but relatively trivial reasons).So for interop ECH apparently requires use of an outdated I-D, despite the one week difference in publishing and a common co-author. It seems a bit mad that all that githubbery results in such a lack of co-ordination in two closely related specs. Anyway, I can manage to handle both HPKE-05 and HPKE-06 but this seems like yet another case where there is too much githubbery going on with the result that two closely linked drafts with a common co-author end up out of whack despite being issued within a week of one another. That and the velocity of discussion and changes on github are a major disincentive (for me) for implementing ECH. I simply do not have the cycles to keep up with it as it has been happening these last months. If that were the goal of the authors and those endlessly commenting on github (and I do not believe it is), then they would be close to reaching that goal. Can we not please freeze this stuff for at least long enough to get implementations done and somewhat tested? Frankly, I expect my plea here to be more or less ignored just as my previous entreaties were. I decided to send it anyway on the basis that the perhaps what seems like an obvious failure of the current approach (ECH can't interop unless you use an outdated I-D for HPKE) might show that all this apparent high velocity discussion on github is not as effetcive as claimed (in at least this case). Thanks, Stephen._______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
OpenPGP_0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
