On 21 Jun 2012, at 19:29, Barry Leiba <barryle...@computer.org> wrote:
>>> (1) Why Informational? Everything else at that level seems to >>> be specified in a standards track or BCP level RFC, and IETF >>> Consensus is required. [1] I think you have to do this as >>> standards track. Did I miss something? >>> >> Standards Track is OK. > > Stephen: > Yeah, I'm not sure Standards Track is needed. On this bit: I personally don't care, except that we don't have to do it twice because someone later on thinks the opposite and wins that argument, which I'd rather not have at all (My one-track mind:-) Doing the 4 week last call means once is enough. But I'm ok with whatever the WG want. S > Other than "Other > documents like it are Standards Track," explain why Informational > doesn't work. Is there some procedural reason that these IANA actions > can't be done with an Informational document? Is there any > expectation that this will be reviewed and modified and progress along > any sort of track at all? Certainly, this doesn't define any sort of > "standard" that I can see. > > Informational documents in the IETF Stream *do* have "IETF Consensus". > >>> (2) Do you *really* want RFC or specification required for all >>> registrations? I don't care, but there is a trend away from >>> that at the moment since its been found to discourage >>> registrations in a lot of cases. Perhaps expert review would >>> be ok? No trying to push you one way or the other, I just >>> wanted to check. > ... >> If the goal is to get this document inline with what our existing documents >> say >> then 'Specification Required' would be the right policy here as well. > > Hannes: > I'm going to really push hard on this point: the goal is *NOT* to make > all the registration policies the same, and I will resist that > strongly. The *goal* is to use for each registry a registration > policy that makes sense for *that* registry. That means that you > (well, someone) need to tell me why *this* registry needs the > strictness that you pick for it. What will the harm be in leaving it > to Expert Review, and letting the designated expert decide how much > documentation to require? And remember, you can document guidelines > for the designated expert. For that matter, what will the *harm* be > in simply letting it be First Come First Served? > > We have far too many too-strict registration policies in effect, and > they often come back and bite on the ass the very people who picked > the policies. > >> So, I am curious where to hit the right level of process here to find the >> sweetspot >> between low overhead and high quality specifications. > > You also need to consider whether poorly documented and unused > extensions really cause any *harm*. If some bozo writes a bad spec > for a stupid idea, and no one implements it because the spec is bad > and the idea is stupid, so what? On the other hand, if some big > company decides it's too much trouble to follow IETF procedures and > chooses not to register their extension, but everyone winds up using > it because they're big and it's necessary, what was the point of > making the registration hard? > > That's the real balance we have to look at. > > Barry _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
