--On Tuesday, May 21, 2013 15:42 -0400 Olafur Gudmundsson <o...@ogud.com> wrote:
>... > 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. Seems perfectly reasonable > Documents that describe the DATA types use are encouraged to > be published as Informational or some other stable reference. Reasonable too. My problem here, which I hope was clear from the note from which you quoted, is that a request/document in the second category was proposed for Standards Track and then that comments that would be entirely appropriate for a Last Call on a Standards Track document were essentially rejected on the grounds that they would require changes to already-registered RRTYPEs. >> 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. But the request for publication in the Standards Track violates it. >> 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. We are agreed that isn't an issue here. > 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 ? With the understanding that I don't think it has anything to do with this situation, one could justify a different (and maybe higher) bar in two ways. First, the media type names are structured so that, a few historical exceptions aside, one can tell what category they are in by looking at the names. To get that effect with RRTYPEs, one would have to take the categories you spell out about and create (as a silly example) type names starting in "1" for the first category, "2" for the second, and so on, or otherwise lexically distinguish the second category from the other two. Second, the potential code space for media types may be a tad larger than the potential RRTYPE code space. But, again, I think the question is irrelevant here -- I've not advocating changing the allocation rules, only keeping the relationship between already-allocated RRTYPEs and the Standards Track into the categories you have described above. --On Tuesday, May 21, 2013 15:24 -0400 Joe Abley <jab...@hopcount.ca> wrote: > Code-points in the RRType registry are assigned by expert > review (not simply by "filling out a template" as someone > suggested earlier). I was the one who said "filling out a template" and that reflects a bad attitude toward many expert reviews. That attitude and what underlies it has nothing to do with this situation. > If the suggestion is that the standards > track is not available for any work that involves a code point > that was assigned early, then I wonder what process is > imagined for any future DNS work which aims at the standards > track. Presumably the same mechanism that has now been used for other registrations that are normally expert review (or less) but that interact with standards-track work: one develops a specification normally, puts it through the standards track, and only then asks IANA to register the relevant parameters (and either asks or directs the expert to sign off). If the existing RRTYPE registration rules prohibit that, I would suggest they are badly broken but I can't imagine how they could be written to specify such a prohibition. One could argue that all of our "expert review" procedures should say "expert review except where the standards track is used for other reasons" but the application of good sense says that the expert should either consider the IETF Standards Track review adequate and sign off or should be screaming loudly about the deficiencies during Last Call. Once more, the only important thing I'm objecting to here is registering the RRTYPEs using the expert method, then asking for Standards Track publication, then responding to Last Call comments by saying something equivalent to "you don't get to discuss that because these types are already registered". I think one can either say "standards track is not needed, publish the description of the types as Informational" or that there is an obligation on whomever is proposing standards track to figure out how to make the review process work properly and without the existing registrations being considered as a constraint. I don't think that is very complex or unreasonable. YMMD. john