Re: [gnso-ff-pdp-may08] Information based solutions instead of policy based solutions

[Marc Perkel <marc@xxxxxxxxxx>]

Dave Piscitello wrote:
> I'm separating comments on TXT overloading from something else you 
> mention later that is very important.
> The scenario I think about when we talk about a free-format field like 
> TXT is the following:
> Community A says "Let's use TXT in the following way: dotted quad 
> followed by 3 space separated fields."
> Community B says "Let's use TXT in the following way: dotted quad 
> followed by 1 field."
> How does a DNS client know whether the TXT record it receives has been 
> populated by a name server attempting to comply with Community A or B? 
> What is a name server must comply with both communities?
> As an example of how this is handled in an IETF standard, several 
> protocols have "vendor-specific" fields (DHCP, NHRP and X-AUTH come to 
> mind). The vendor ID might be the 24 vendor/manufacture bits from an 
> Ethernet MAC, or whatever is needed to make absolutely sure that the 
> recipient of the protocol message/packet knows exactly how to process 
> the message.
> Now, look at your SpamHaus example. You've gone beyond just saying 
> "hey let's use TXT" to "hey, let's use TXT in a manner consistent with 
> a *standard*". In other words, to achieve what you want, you could use 
> the 127.0.0.0/8 space as a community/policy identifier for Marc's purpose.
> This is no longer overloading DNS TXT but *structuring* TXT in a 
> standard manner. I am very OK with this in principle, and would hope 
> that we would take such a proposal to the IETF as did the blacklisting 
> folks.
> Note that the blacklist folks are effectively created a new 
> identifier, and that this list should eventually be maintained by 
> IANA. Note also that if the DNSBL BCP is not approved, then the 
> assumed structure disappears and you're back to having ambiguity.
I'm assuming that if we go with this idea that we would write a 
specification for what the TXT response returns. What I would suggest is 
something that's expandable perhaps using keyword data pairs.
registrar="tucows.com" created="04-15-2006" changeinfo="4 20 100" 
techemail="abuse@xxxxxxxxxxx"