--On Thursday, February 26, 2015 10:59 -0500 Andrew Newton <andy@xxxxxx> wrote: > <snipping a lot of text...> > > On Wed, Feb 25, 2015 at 9:16 AM, John C Klensin > <john-ietf@xxxxxxx> wrote: > > >> If (as I believe to be the case) the main >> argument for this URI RR is that it is less problematic than >> NAPTR, S-NAPTR, U-NAPTR, and (maybe) SRV, then this document >> should probably include a plan about phasing some of those, or >> at least some instances of some of those, out. > I was unaware that there was a need for only one way to do > this. It seems to me that the multiple methods could co-exist > without collision. While I agree with your observations about > these methods, I do not like the idea of the IETF mandating > single solutions unnecessarily (in its specifications). Let me be a bit more clear. I don't see a need to "mandate a single solution". On the other hand, suppose we say "X is the standard way to do A", and then say "Y is the standard way to do A", and then say "Z is the standard way to do A". Unless we have suddenly started liking interoperability and operational problems (noting that, at least absent a lot of additional processing that would disqualify the registration, there is no way to ask the DNS for all of the records, RTYPE-independent, that are associated with a parent node and that have URIs in their DATA), it seems to me there is some obligation to offer guidance as to what should be used when. If that guidance is simply "just pick whatever appeals to you", I'm probably ok with that as long as we are explicit about it, but I don't think the issue of multiple RRTYPEs that do almost the same thing can be ignored. Especially given your LINK proposal, I'd find it equally reasonable to see a statement in the present doc that said "despite given the very general name 'URI', this RRTYPE is really designed for ENUM and things that are like it, while LINK may be more appropriate for use with the web and HTTP URLs in particular". Such a statement could also include more of a discussion about the difference between a normally-named node (e.g., "example.com") and a service-designation node (e.g., "_foo._bar.example.com") and their applicability. My objection in this area is not that we've specified more than one way to do similar things; it is that we are leaving the reader guessing as to how they might decide what to use and doing so without being explicit about that. >> If, instead, >> these five (or fewer, see below) types of >> potentially-iterative indirect references are to exist in >> parallel, it becomes reasonable to ask that a standards-track >> document explain how many more of them are expected or why we >> should assume this one is the last. > I'm confused. How can we know a better idea will come along > until it has actually surfaced? We probably can't. But, after more than three variations on the same theme, it seems to me to be reasonable to ask authors if they have reason to believe that they've actually got it right this time or if implementers should expect yet another variation in a year or so and to get that written down.... and to get their answers on the record. >> While multiple ways to do the >> same thing are sometimes an advantage, they are more often a >> source of confusion (and, again, potential bad implementation >> behavior and attack vectors). It would be _really_ good to >> do some architectural work that would lead to both design and >> applicability statements, rather than continuing to add more >> of them without an obvious plan. > I agree with a lot of things you have written here. But I'm > wary of any effort regarding a grand unifying architecture, if > that is where such an effort takes us... especially given the > recent discussions on URIs/URNs. That said, there may be room > for some discussion here as there are other ideas in this > space (https://datatracker.ietf.org/doc/draft-newton-link-rr/ > ). Precisely. I also note that, assuming that draft can be believed, it is asking for standards track but is not associated with a registration that has been made already and so doesn't get us into the "you should standardize this but don't have change control even pre-approval" situation. As to "grand unifying architecture", I'm probably going to get myself attacked from both sides for saying this but it appears to me that we have two grand unifying architectures in this space (DNS and URI) and they are both showing signs of being problematic (if not actually broken) for purposes to which people want to put them. best, john