I have changed the subject line to reflect the fact that the IAB chair informs me that this is in fact a consultation period and not as was indicated in the original subject line a report of a decision already taken. The list of comments does not include my core objection made in the 'Domain Centric Administration' and XPTR drafts, that it is in fact possible to create 'midpoint' wildcards of the form '_prefix.*.example.com' by the simple measure of introducing a layer of indirection. This may be implemented by defining semantics for the existing PTR record in the forward DNS or by introducing one new RR to deal with the issue as is suggested in XPTR. [U] If you want to construct this wildcard you may use: *.example.com PTR _wildcard.example.com _prefix1._wildcard.example.com TXT "Text" _prefix2._wildcard.example.com SRV blah... _prefix3._wildcard.example.com NAPTR blah... The search strategy is then quite simple, if a search for the record itself returns no answer you look for the PTR record at the node to be queried, if that exists you concatenate the prefix to the result of the PTR indirection and do a lookup there. The strategy always completes in two or three lookups, there is never a requirement to do tree climbing. A DNS server can efficiently predict the optimum responses to send as additional records. It is fully compatible with other DNS extensions. This is not a small objection as the entire argument for using a new RR rather than overloading SRV, TXT or NAPTR is that midcard wildcards do not work. The paper wrongly concludes that creating new RRs is the only alternative to the 'tree searching' approaches that are potentially damaging to the core DNS infrastructure. [V] Even if the legacy DNS infrastructure becomes 100% capable of transmitting new RRs it will still be necessary for DNS administrators to update their server software to create new RRs. This is likely a good business model for the providers of standalone DNS servers but hardly practical for a platform vendor that issues new server platform upgrades in a 5 year deployment cycle. The proposed fixes for this problem are not applicable to providers of GUI based interfaces. The reason that I have let the XPTR draft expire is that I am waiting for the registration process for new RRs to be published. Before letting the draft expire I checked the status of choices and noted that it had been expired for 8 months and its author was no longer on the IAB. The minutes of the IAB meetings did not indicate that it was still a live issue so I and others assumed it to be withdrawn. Providing protocol designers with a viable architectural approach that avoids the need to do tree walking is a very useful and important thing for the IAB. Choices does not describe a viable approach. -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Patrik Fältström Sent: Wednesday, March 05, 2008 4:09 PM To: ietf@xxxxxxxx Cc: iab@xxxxxxx Subject: Re: Impending publication: draft-iab-dns-choices-05 As editor of thie IAB document, I have here collected the comments that have come so far. If I have missed some, please let me know. I will discuss these with the IAB. [A] It might be helpful to discuss the use of the Hesiod class at MIT in the past. [B] There is a typo on the front page of version -05, it says "standards track". [C] Explain more why so many people have used TXT records. [D] "fighting spam" is not a correct summary [E] It is not explained what "splitting an RRSet" implies when it is stated that it is a protocol violation [F] Clarification (due to a reference): Do you plan to publish draft- iab-dns-choices-05 before 2929bis? [G] The tone of the paper reflects very badly on the IAB and that it is not appropriate to second guess or assume the mental processes of designers. [H] draft-hallambaker-xptr-00.txt(*) should be referenced. [I] Objection: RRs are a finite resource, the mechanism does not scale. [J] Objection: Legacy infrastructure support is a real concern [K] Objection: Wildcard support is not a major concern [L] Objection: Wildcard support in legacy DNS is no less unsatisfactory under the proposed approach [M] Explain for example the design thinking that took place in the DKIM wg (that lead to use TXT records) [N] The following is unclear: "This implies that some other selection mechanism has to be applied as well..." [O] Change "This Resource Record Type can either be a..." in section 3.3 in a similar way as in section 3.2 [P] Change text around "kitchen sink record" in a way similar to [O]. [Q] Change sentence "The reason for this is that there is nothing to prevent collisions..." in section 5. [R] Sentence "that would probably need to be upgraded in any case as part of supporting a new application" is confusing. [S] Make more clear (specifically in section 6) when one talk about DNS software (as in DNS servers etc) and applications that originates the DNS queries. Example around "deployed DNS software today should support DNSSEC" [T] Argument "...but most such software is old enough and insecure enough that it should be updated for other reasons in any case..." is not clear. On top of this there are some pure editorial suggestions. Patrik (*) http://quimby.gnus.org/internet-drafts/draft-hallambaker-xptr-00.txt _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf