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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of Patrik Fältström
Sent: Wednesday, March 05, 2008 4:09 PM
To: ietf(_at_)ietf(_dot_)org
Cc: iab(_at_)iab(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf