Re: Using SUBMIT without bothering the user (was Re: MyDoom, Sorbig - Ac

--On Thursday, 05 February, 2004 20:41 -0500 Keith Moore 
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
> Mumble.  configuration is a Hard Problem.  With very few
> exceptions most of the solutions I've seen to do configuration
> end up making the situation more complex, less fault-tolerant,
> and harder to configure correctly - and it's usually because
> they key off of the wrong thing for the particular quantity
> they're trying to configure.  For example, DHCP is really only
> good for things that are inherently tied to the network
> location, which isn't much besides address, netmask, and
> default route.  (and it botches address configuration by
> making IP addresses ephemeral).
Keith,

You are putting your finger on exactly the things that make me 
uncomfortable with the Email SRV draft.  But most of them are 
also issues we explore in the draft.
On a devil's advocate basis, let me respond to your DHCP comment 
above by saying "it all depends on how DHCP is used and in which 
environments... and that it may be lots more appropriate for 
some than for others".  Specifically,
        * there are issues of defaults and overrides of
        information obtained elsewhere that are matters of
        implementation and configuration, not of the DHCP specs.
        E.g., if my host has an address (or an SMTP server, or a
        printer list) already, should it bother asking DHCP?
        And, if it does ask (whether always or in the hope of
        getting some values which it doesn't have already),
        should the DHCP values override or supplement the
        pre-existing ones, or should they be ignored?
        
        * suppose there is information I can obtain through
        either DHCP or SRV or some other mechanism.   Should I
        ask all of them, and in which order?  And, if I get back
        inconsistent results... (see previous paragraph).
        
        * sometimes, but not always, "network location" (or
        "network topology") are actually pretty well connected
        to administrative/ policy domains.  The appropriateness
        of that association may depend on local issues that have
        little or nothing to do with anything that can be said
        --technically or morally-- Internet-wide and, sometimes,
        with how other protocols are configured.  Using the
        Submit case as an example, if access to the LAN
        supported by a DHCP server is closely controlled, and
        that LAN contains an SMTP server that is configured to
        act as a relay for anything originating from that LAN,
        then having DHCP dispense the name or address of that
        server may be completely appropriate (although having
        every SMTP client attached to the LAN may not be).
        
        * and, of course, whether the addresses DHCP dispenses
        are ephemeral or not is also a matter of configuration.
        With some configurations, it is a tool for centralized
        management of addresses within a (physical or logical)
        LAN, but those addresses are no less stable than if they
        were configured into the hosts on that LAN one at a
        time.   It just makes renumbering with, e.g., a change
        in ISPs, a lot easier.

The real problem with Submit (and many other potential SRV and 
DHCP targets/values), it seems to me, is that someone has to 
make a policy decision about the semantics of the server or 
service that is being searched for.  When there is only one 
choice of semantics, the answer of which protocol to use and how 
to use it typically becomes pretty simple.  When there are 
several --and Submit is clearly an example of that, with "based 
on local network" versus "based on my usual address" being only 
two of the choices-- then things get complicated.  And it is not 
clear whether "configure in the desired semantics and the right 
protocol search order(s)" is going to be easier for that poor 
user than "just configure in the right host".
    john