[Top] [All Lists]

Re: Impending publication: draft-iab-dns-choices-05

2008-03-05 14:09:37
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  

[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.



IETF mailing list