>> (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". >> (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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
