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

[Ned Freed <[e-mail]>]

> On 6/8/2012 4:24 AM, Ned Freed wrote:
> >> 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.

> Whether, that's not correct.  The structure isn't even the same.

> When there is review, there is a sub-process that is absent from FCFS.
> That's a significant difference in form.

Again, this isn't as apparent as you seem to think.

> > What matters is the *content* of the form and the *timliness* of the
> >  response.

> Right.  And since we don't to empty processes, the process entails
> dealing with that review, either by the potentially chilling effect of
> spending significant time trying to anticipate objections and respond to
> them, or in reactively responding to actual concerns of the reviewer.

> Hence, both the politics and the effort are substantially different.

The evidence says otherwise. For example, the private SNMP MIB registration
used to be FCFS (and apparently no longer exists), yet we struggled mightily to
figure out how to do it. Port numbers, OTOH, were a snap, even though they
involve expert review.

> > And I'm not seeing overly onerous content requirements here.

> Of course not.  You're an informed and reasonable guy.  Not all
> reviewers are like that.  And not all submitters know enough to
> anticipate the concerns of reviewers.

Fair point. There is always a chance of the reviewer being unreasonable.

> 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.

> But this assumes a point I'm suggesting we consider carefully:  Having
> the process of finding the reviewer and managing the review process
> isn't free.  These are not like alternative routing algorithms:
> screwups have contained damage.  That makes the cost/benefit tradeoff
> questionable.

I think the number of these is certain to be very small so the cost
will be low.

> >> 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.

> the word 'might' undermines the strength of this point.

The claim that "The reviewwer might be slow or unreasonable." has similar
issues.

> >> 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.

> I think the strategic media content threat is from bad media types, not
> bad registrations.  By bad media types, I mean bad technologies that get
> into a position of market leverage.  And we can't do anything about them.

I wasn't talking about media types.

				Ned