Re: Starting in on a document

Raymond S Brand <[email protected]> wrote:
> You seem to be more optimistic than I am about resolving the 
> technical differences:

  I view those technical differences as one of implementation only.
The basic concepts, intentions, and outlines of the proposals are very
similar.


> 	Q(DOMAIN, IP)	=> YES/NO/UNKNOWN
> 	vs
> 	Q(DOMAIN)	=> LIST OF YES IPs/UNKNOWN

  Those two queries can be mapped to each other via a simple
transformation.  The choice of which one to implement will be based on
issues other than the structure of the query.

  e.g. I'm partial to Q(DOMAIN, IP), simply because it's the simplest
query which gets the information requested.  Most MTA's won't care to
have a list of the 100 or so SMTP servers AOL has.  They just want to
know if THIS ONE is ok.

> 	Individual OKs only
> 	vs
> 	CIDR/Wildcard OKs

  This is pretty much the same as the previous issue, in my opinion.

> 	Existing DNS RR types
> 	vs
> 	New DNS RR types

  We will not standardize new DNS RR types.  I have not seen any
reason as to why they would be *required* for any of the current
proposals.  I believe that we can do most, if not all, of the work
without defining new RR types.

  New RR types also mean that the solution will take even longer to
be deployed, as DNS administrators will be required to upgrade their
software, and not just their configuration files.

> 	DNS A RR type
> 	vs
> 	DNS TXT RR type

  The choice here depends again on the first issue: queries.  If the
query returns yes/no/unknown, then an A RR type may be sufficient.  If
the query returns large amounts of information, then a TXT record may
be required.

> I think that the only technical detail that everyone agrees on
> is the need for some kind of delegation mechanism.

  My opinion is that we should describe the smallest design and
implementation which will address as much of the problem as possible.
To me, this means Q(DOMAIN, IP), individual OK's, no new RR type, and
implemented via A RR.

  Alan DeKok.