Re: Sense of the WG: mDNS configuration?

[Aidan Williams <[e-mail]>]

Robert Elz wrote:
> 
>     Date:        Sat, 18 Aug 2001 17:16:29 -0700 (PDT)
>     From:        Bernard Aboba <[e-mail]>
>     Message-ID:  <[e-mail]>
> 
>   |       Domain Searchlist (draft-aboba-dhc-domsearch-05.txt)
>   |       mDNS enable (draft-guttman-dhc-mdns-enable-01.txt)
>   |       Name Service Searchlist (RFC 2937)
> 
> Either of the latter two - the mdns-enable option is basically just
> a special case of 2937, in a sense - but as I read 2937, it would need
> another DNS option defined anyway, so its option number can be used in
> the 2937 option (there's no current dhcp option giving the addresses
> of the servers for mDNS .. for obvious reasons).
> 
> That is, adapting 2937 is probably more work than it is worth, so mdns-enable
> is probably the better choice.
> 

I agree that RFC2937 is the right concept, but I don't understand why
it is a great deal of work to extend.

Extending RFC2937 has the advantage that mDNS can be slotted in between
whatever name lookup services are defined by it (e.g. NIS+, NetBIOS, ..).
What would you do if you got *both* and mdns-enable option, and an
RFC2937 option?

I can think of two options for extending 2937:

  1. add an RFC2937 option for mDNS, and use a seperate DHCP option
     to define the scopes.

     Doesn't seem to buy much else other than "getting with the existing
     program".  Allows mDNS to be slotted in with the other zoo of
     name services.

  2. add RFC2937 options for each mDNS scope to be checked.

     My initial thought was that this was a dumb idea because
     there might be a profusion of the same option, but with
     every random scope.  However, there are probably only
     two relevant multicast scopes: link-local and site-local.

     This would basically incorporate the mdns-enable work into
     the RFC2937 framework.

> dhc-domsearch (with the magic string) is just wrong - overloads an option
> with a totally irrelevant meaning.
> 

I whole-heartedly agree.

> When there's no dhcp server, those can
> be configured manually (or simply default to whatever the OS vendor
> decides is best - perhaps based upon an IETF recommendation).
> 

In the absence of configuration information, a sensible default
is to try mdns.  There isn't much else you can do (other than fail).

For IPv6, it seems that just about all DHCP options can be re-specified
as "stateless" router advert options, or new ICMP messages.
What would prevent this one going the same way?

regards
	aidan
____
:wq!


to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.