Hi Barry, On Jun 21, 2012, at 9:29 PM, Barry Leiba 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. 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". On our status call on Monday you explained me that both types of documents have IETF last calls these days. Hence, I wonder whether there is any practical difference? > >>> (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. I made a mistake here and responded too quickly. I will respond to that issue in my mail to Mike since it very much relates to an issue he raised. > >> 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 Ciao Hannes _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
