On May 21, 2013, at 1:32 PM, John C Klensin <john-ietf@xxxxxxx> wrote: > (Changing Subject lines -- this is about a set of general > principles that might affect this document, not about the > document) > > --On Tuesday, May 21, 2013 22:23 +0700 Randy Bush > <randy@xxxxxxx> wrote: > >> joe, >> >> i have read the draft. if published, i would prefer it as a >> proposed standard as it does specify protocol data objects. > > I would generally have that preference too. But it seems to me > that the combination of > > -- RRTYPEs (and a bunch of other protocol data objects > associated with different protocols) are allocated on > expert review > > -- The fact that those protocol data objects have > already been allocated is used to preempt IETF > consideration of issues that normally go into Standards > Track documents, including the criteria for Proposed > Standards in 2026. > > is fundamentally bad news for reasons that have little to do > with this document or RRTYPEs specifically. If the combination > is allowed, it provides an attack vector on the standards > process itself because someone can get a parameter approved on > the basis of ability to fill out a template and then insist that > the IETF approve and standardize it simply because it is > registered and in use. That would turn allocation of > parameters by expert review (and some related issues connected > to "deployed therefore it is ok" -- watch for another note) into > a rather large back door for standardization that could bypass > the 2026 and other less formal criteria, the IETF's > historically-strong position on change control, and so on. John, There are basically 3 different kinds of DNS RRtypes, - types that affect the behavior of the DNS protocol and are cached by resolvers, - types that have DATA and are cached by resolvers - meta Types that may affect processing but are not cached. DNSEXT in its wisdom has deemed the second group to be "harmless" as far as DNS is concerned and getting code to store data in DNS is a good thing, thus it is easy to get it. Getting code for the other classes requires IETF standards action. Documents that describe the DATA types use are encouraged to be published as Informational or some other stable reference. > > These are not new issues and we have historically dealt with > them in a number of ways that don't require moving away from > liberal allocation policies and toward "the IETF is in charge of > the Internet and has to approve everything". For example, we > have decided that media types don't have to be standardized > although certain types of names do. People then get to choose > between easy and quick registration and standardization, but > don't get to use the first to leverage the second. One could > argue that the pre-IETF (and very early) division between > "system" and "user" port numbers reflects the same sort of > distinction between a high standard for justification and > documentation and much lower ones. > As I explained DNS RRtype allocation has this separation. > It is possible (although I'm not convinced) that this discussion > should suggest some tuning of the allocation model for RRTYPEs. > Probably that model is ok and we just need to figure out clearer > ways to say "if you want standards track, don't get an > allocation first and try to use that as justification because > you will get a real Last Call anyway and everyone will end up a > little irritated". Or something else may be appropriate. But > it seems to me that, as soon as one wants to say "all protocol > parameters or other data values should be standardized" then > allocation models based on expert review are inappropriate. For > the RRTYPE case, that issue should, IMO, have been pushed with > the relevant WG when the decision to allow expert review was > made (and, again, IMO, that cure would be worse than the disease > because it would indirectly drive more folks toward overloading > of TXT and other existing types). If the expert thinks an application crosses from DATA space to Control space he is expected to reject the application and ask for clarification. So far nothing has shown up that crosses this boundary, so there is no problem. I will go as far as saying why should there be higher bar for getting a DNS RRTYPE than MIME media type ? Olafur