I would agree that on the whole we want people to register RR types through the standardization process. However, if someone actually followed our process, as Patrik did, and defined the RR type and documented it, and then this document sat around for eight years, as it did, I don't think it's reasonable to hold Patrik accountable for that, and I think it discourages others from bringing work to the IETF. On 3/6/15 4:22 PM, John C Klensin wrote: > --On Friday, March 06, 2015 12:51 +0100 Eliot Lear > <lear@xxxxxxxxx> wrote: > >> I just wanted to say that I think it's a bad idea to make this >> thing informational. The fact is that URI has been kicking >> around for years upon years, and what we are doing now is >> documenting existing practice. PS is a perfectly fine >> instrument to gain experience, warts and all, with URI. > Eliot, > > The counterargument is that we've gotten into a trap. In > theory, PS implies something that we can use, as you say, to > gain experience, etc. But that experience is useless unless the > IETF has practical change control and can make alterations > dictated by community review (before PS approval or after that > experience accumulates). > > Because this RRTYPE is already registered and the registration > cannot be changed in an incompatible way, that condition doesn't > apply -- any experience we gain could only be used to inform an > Applicability Statement that might say "don't use this" or "use > this only if if series of other conditions have been met". Such > an Applicability Statement (or nearly-equivalent BCP) could > perfectly well be issued against an Informational document. > > The various Last Call design reviews have identified several > changes that people would like to make to the RRTYPE itself (I > am not claiming consensus for any of them because they haven't > been discussed sufficiently). However, this cannot be a normal > Last Call for a normal would-be PS spec, because those changes > [1] cannot be considered and, if appropriate, made. > > I think this "register by Expert Review, freeze technical > content, and then discuss standardization" path is a problem, > potentially a serious one, for the IETF. But I think the place > to sort it out is in our norms for Expert Review leading to > registrations, e.g., in draft-leiba-cotton-iana-5226bis or in > changes to the (IIR, unwritten) "IETF has change control" and > the very explicit "known defects" rule in 2026. Until and > unless such changes occur, I just don't see a way to put this on > the standards track that does not result in worse problems. > > best, > john > > [1] While most of the focus of the discussions has been on > security, there are some other substantive issues too. For > example, (i) given that this RRTYPE moves the service being > requested from the RDATA to the Owner of the DNS entry, is > "Weight" still justified and is it likely to cause more trouble > than it is worth or (ii) given recent controversies about kinds > and uses of URIs, including the debate about how much different > URNs should be from URLs and generic (but presumably > location-oriented) URIs, should there be restrictions on the > type and/or content of URIs that are considered appropriate for > use with the RRTYPE? The issue isn't what the answer to those > question should it; it is that they can't really be asked. > > >
Attachment:
signature.asc
Description: OpenPGP digital signature