On Wed, Mar 11, 2020 at 6:11 PM Eric Rescorla <ekr@xxxxxxxx> wrote:
On Wed, Mar 11, 2020 at 2:50 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:On Wed, Mar 11, 2020 at 09:48:29AM -0400, Paul Wouters wrote:
> On Tue, 10 Mar 2020, Pete Resnick wrote:
> > I think you're probably right. I know I've chaired in the past when I
> > didn't see the signs of bad things happening and failed to get out in
> > front of it. But the appeal, even if fruitless in the end, would have at
> > least made the chair, the AD, and IESG do a bit of post-mortem to figure
> > out what went wrong, so we should figure out some way to make them less
> > painful (as per your last paragraph).
>
> In this case, going via the ISE is a fine solution, provided this path
> isn't suddently blocked in the future before publication of the
> document, and providing the ISE agrees to publish. I have no idea what
> we would have to do procedurally, if the ISE path fails for some reason.
> As we cannot really appeal the ISE decision, we'd have to go back to the
> WG for an appeal, which also seems to not be the right place.
The ISE path can work some of the time, but it may not be a good habit.
First, why even bother with the ISE? Why not just make the relevant
registries Expert Review?I'm not interested in re-litigating the TLS DNSSEC experience, but I would note that nearly all of the TLS registries are in fact Specification Required, and an I-D is sufficient. To the extent to which there are RFCs required it is either:- To get a code point in one of the very small registries (alert, content type, handshake type...)- To get the "Recommended" mark attached to your registration.This decision was made specifically to avoid arguments about the merits of documents that the WG wasn't interested in.Then take this to the limit. Suppose we did some number TLS extensions
this way, with several overlapping somewhat, but in ways the authors did
not care to unify. What would happen?Well, we're running this experiment now, and have been ever since late 2018, so I guess we'll find out. So far it does not seem to have been an issue.
+1
I have wanted to see the IETF get itself out of the way of crypto code allocations for precisely this reason. We can't actually stop people taking a code point if they decide not to take no for an answer. The folk allocating MAC addresses discovered that when the storage folk hijacked a huge chunk out of the middle of their addressing space.
The IETF works by consensus but the Internet is an anarchy were the only constraint is the immense inertia of 40 years of legacy systems, 5 billion users and 30 billion end points.
