[Top] [All Lists]

Re: Using SUBMIT without bothering the user (was Re: MyDoom, Sorbig - Actions taken?)

2004-02-06 10:20:32

--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).


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".


<Prev in Thread] Current Thread [Next in Thread>