Re: [apps-discuss] Comments on draft-ietf-appsawg-received-state

[Ned Freed <[e-mail]>]

> On 6/7/2012 12:59 PM, Barry Leiba wrote:
> > I think this is a good idea.  I think FCFS would also be adequate, and
> > encourage the WG to use that.  The reason is that it's far better to
> > encourage people to register status codes that they want to use, and not
> > to put barriers in the way.  The usual reluctance to use FCFS is concern
> > that people will register a bunch of garbage.  In fact, (1) this hasn't
> > ever happened

Um, in the case of media types at least, it hasn't happened *because* of
expert review. I can point at several examples of registration attempts
that didn't make any sense and which were rejected for that reason.

> and (2) IANA would ask the IESG to intervene if they got a
> > suspicious flood of registration requests.

> +1

> The justification for expert is "quality control".  The side-effect is a
> disincentive to register.

Er, not really. From a registrant's point of view the process is essentially
the same with or without expert review: Fill in a form, submit it, wait
for a response.

What matters is the *content* of the form and the *timliness* of the response.
We initially screwed up both of those with media types: The rules for filling
out the form were much too strict, we didn't define the form content
adequately, and when the form was submitted responses were nowhere near timely
and in fact sometimes there was no response at all. Oh, and we called for
mailing list review of all proposals, and then didn't respond to review
requests in a timely way.

And I'm not seeing overly onerous content requirements here. So the
only factor is whether or not an expert can be found that can review
in a timely way. If that proves to be impossible then maybe FCFS makes
sense, but if not I'd prefer to see expert review remain.

> Do we make it easier and let in some cruft along with the good stuff or
> do we make it harder and keep out some good stuff because registering is
> too much hassle?

In this particular case cruft has a potential negative consequence:
Someone looks at the registry and says "why doesn't your product produce
this state". And they may not like the response that the state doesn't
make a lick of sense.

> I think the latter is the better choice, because the cruft doesn't
> actually hurt anything and there's a very, very large namespace that can
> afford to be wasted.

> As Barry notes, the actual 'threat' is quite small and the damage from
> its being realized is also negligible.

The threat is indeed very small. Not so sure about the damage.

				Ned