Re: Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
From: John C Klensin john-i...@jck.com 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. This seems to be the only truly controversial point, and it is very important. The IETF does not promote something to a standard just because someone (or even lots of people) are already doing it. It is, however, perfectly acceptable to document it, and even to document that some other group has anointed it as a standard within *their* practice. Dale
Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
(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 ra...@psg.com 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. 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. 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). best, john where you goin' with that gun in your hand? i am not at all sanguine about the issues raised in the in sec cons. i accept that NTRE038D may have asked that these be in the dns, but seems to me that it is ill advised and some other means to meet their actual needs might be found. e.g. what's the matter with logs?
Re: Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
On May 21, 2013, at 1:32 PM, John C Klensin john-i...@jck.com 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 ra...@psg.com 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
Re: Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
--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
