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