I am very unhappy with the past behavior of the DNS directorate. In particular they have in the past demonstrated a complete failure to accept the fact that protocols have to be compatible with deployment constraints.
DNSSEC has been delayed at least five years due to arguments over the importance of deployment constraints. This is not a community that is sufficiently in touch with reality to be relied on. There is no point in accepting a boat anchor being added to the protocol for the sake of getting through IESG review. At the end of the day the IESG review has much less importance than the deployability of the protocol. In particular nobody seems to have noticed the apparent loss of interest in DKIM from a certain party that happens to have one of the DNS servers that would be most affected by the proposal. I am rather more concerned about that than the opinion of the IESG as predicted by the DNS Directorate. There should be a registry of prefixes for the simple reason that this is now the way that the DNS is extended in practice. There is in fact such a registry, if the IETF does not act it will end up the defacto registry. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Farrell > Sent: Monday, October 16, 2006 10:21 AM > To: Scott Kitterman > Cc: [email protected] > Subject: Issue 1382 (was: Re: [ietf-dkim] New Issue: New > resource record type) > > > Scott, > > The last time we met we had this same issue wrt key records > with the result shown below (excerpted from [1]). > > I don't personally know if SSP records are in any way > different from key records, but it does seem to be the case > that there is some general opposition to (re-)using TXT. > > And we won't really be able to have the discussion with the > DNS folks (which will be necessary) until we have a concrete > protocol to discuss with 'em. > > So I'd suggest that we leave this issue [2] open for now, and > come back to the topic when we've got a concrete protocol on > which we can base the discussion. > > Does that sound ok for now? > > Stephen. > > [1] http://tools.ietf.org/wg/dkim/minutes?item=minutes66.html > [2] https://rt.psg.com/Ticket/Display.html?id=1382 > > "Bellovin on the DNS directorate issue: question about TXT vs > other RR for _domainkey. Spent 45 minutes at DNS directorate. > Steve not chair, but consensus. Quoting: > > "The DNS directorate is unhappy with using TXT records this > way. Some of the reasoning is spelled out in > draft-iab-dns-choices-03.txt. At the least, a registry of _ > names is needed, with provision for subtyping, but subtyping > RRs has long been known to be bad . In general, TXT > overloading can be likened to using HTTP as the universal > transport protocol; see RFC 3205 for why that's a bad idea. > > A more specific problem for this situation is the issue of wildcards. > Briefly, you can't have a wildcard _domainkeys record; given > that email is the major place where wildcards are used, this > is a serious issue." > > DNSSEC signing records at least may be found below > _domainkeys and other RRs deliberately or by accident. > > Olafur: If doc says "do not use wildcards" that'd be good. > Proposes an experiment to acquire a new type if the WG want > to try that (a fast process apparently). > > Doug - eai may expand record as well as longer keys. Suggests > that alternative to TXT might be good for that. > > Crocker: Question to Bellovin: Would DNS directorate assert a > DISCUSS. > Bellovin: No-one said DISCUSS, but unhappiness. On the plus > side, its a special record and we don't have to contend with > other TXT records. > > Way forward: WG will only specify a TXT for keys for now." > > > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
