Re: [Fwd: [Asrg] Re: Documents for LMAP BOF]

On Sat, Feb 07, 2004 at 09:00:19PM -0500, Yakov Shafranovich wrote:
>
>       http://www.taugh.com/draft-levine-fsv-00.txt
>
> Read fast, we have to sumit I-D's for Seoul by Monday.
> 


Ok, now my comments to this draft:


It is focussing on the two strategies blocked or factored
records. 




4. Mail server considerations

I don't think that this is correct. Whether you want to 
have blocked or factored entries does not really depend on 
the traffic rate of your own server. It definitely depends on 
the structure of the verified domain and whether this belongs
to a large network with many senders, which can be described 
with a single network mask, or with many single roaming users, 
which need fresh lookups every time. I especially doubt that
it depends on whether the MTA is a single- or multiprocess relay. 
If this makes a difference, then the implementation is poor. 
BTW, DNS records are usually cached in the DNS server, not (only) in
the mail server. Especially for high volume mail relays it is 
advisable and usual to have a DNS cache so close, that DNS queries
to this cache are not expensive in time. However, I do not think 
that it makes a difference whether to have a one-shot-implementation
or an always running relay. 










   The TXT record contains a series of char-
   acter strings, each of which is either an IP address or a CIDR
   range. 

Yet another one...





   The two low octets of the A record at _fsv contains the number of
   text strings in the corresponding TXT record so that if, for
   example, the TXT record contains six strings the A record contains
   0.0.0.6.  The high two octets are reserved for future use and must
   be zero.


I really don't like this idea. We shouldn't try to abuse every
single RR type for anything else, especially not A records to store
integer numbers. Maybe have a look at Microsoft's CallerID proposal
which uses the first two characters to order records. I proposed in a
comment to Microsoft to use subsequent numbers instead of just any. 
This allows both to check for completeness and to order them
correctly.




   If a domain exists but
   sends no mail, its _fsv TXT record contains a single null string
   and the A record contains 0.0.0.0.

How many of those domains will exist to be resonable for all
other millions of domains to carry an extra record? 



   Other than standard CNAME records, FSV provides no facilities for
   nesting, indirection, range merging, or any other operations on its
   contents.  A CNAME record can be used if a domain's FSV data is
   identical to another domain's data.  Otherwise, each domain must
   list its full set of servers.  If a domain's data is derived from
   another domain's data or its own MX data, the domain's management
   is free to use any software it wants to construct the FSV data, but
   that process is invisible to and of no interest to FSV clients.


Now the author is shooting himself into the leg. That's
contraproductive. 

If you want to do so, you need to update the zone table every time
anything changes. To make this possible, you need to give your 
entries a very short TTL. But a few lines above the author mentioned
the need to cache the entries in order to keep DNS traffic down. 
That's a direct contradiction.




Sorry, don't get me wrong. But that draft does not convince me. 
It smells pretty much like a "me too" draft to join the club.
I'm under the impression that the small proposals are aimed to 
just being a little bit different than the existing proposals rather
than solving a real problem. At some points it is based on assumptions 
which do not seem to be correct.

regards
Hadmut