________________________________________ From: Tony Finch [EMAIL PROTECTED] On Behalf Of Tony Finch [EMAIL PROTECTED] Sent: Friday, November 14, 2008 4:11 AM To: Hardie, Ted Cc: Andrew Sullivan; [email protected] Subject: Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages
On Thu, 13 Nov 2008, Ted Hardie wrote: > > That's an example in which an A record in this zone has the standard DNS > meaning and the expectation is that you can use it construct a URI. > The other A records have a specific meaning in which the data returned > indicates that indicates something about its reputation in a specific > context (what reputation etc. being context specific). One of these > things is not like the other. Using the same record type for both > creates a need to generate some other context that enables you to figure > out what was really meant. I understand the argument that DNSBLs break the DNS data model. What I don't see is any evidence that this causes interoperability problems. Tony. -- f.anthony.n.finch <[EMAIL PROTECTED]> http://dotat.at/ VIKING NORTH UTSIRE SOUTH UTSIRE: WEST OR SOUTHWEST 5 OR 6 INCREASING 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN VIKING. ROUGH, BECOMING VERY ROUGH OR HIGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST. Since you now have two different meanings for what an A record is, you now need two different code trees that understand what A records are, and those code trees are not interoperable. Standard libraries called in this circumstance won't work, and you'll need some mechanism to disambiguate the context so you know when to call the special library for a-record-in-dsnbl versus the code in a-record-in-standard-dns. At the moment, this is by application, but it may not always stay that way. Since new RRs are substantially easier to get and use than they used to be, Andrew and Olafur have suggested that this work transition to using one, so that the current re-use can be phased out. I support that, and I would be very concerned about the IETF standardizing something that breaks the DNS model. We've started down that path on a couple of occasions, and it hasn't been all that pretty. Having the DNS remain a single namespace with as few context dependencies as we can is pretty important, in my opinion, and the costs to moving back into the standard way of doing things (over time, as they pointed out) does not appear to be onerous, especially if tied to some other transition. regards, Ted Hardie _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
