Re: dynamic update of multicast (forward and reverse)

[bmanning@ISI.EDU]

> 
> > From: Robert Elz <kre@munnari.OZ.AU>
> > Compiling a long list of multicast names into every application
> > that needs to translate names into addresses, just in case
> > it happens to be handed a multicast name or address to translate
> > seems about as weird a suggestion as any I've heard recently.
> >
> > Compiling things like IETF-1-VIDEO.MCAST.NET into applications
> > would truly be insane.
> >
> OK.  I will add the statement that multicast names are not resolved
> using this technique.  There, that was easy.

But wait Bill,  What did Robert say?  I think his operative word was
-COMPILE- with the target being applications.  When I see this I think
of the traditional WHOIS client with a compiled in address.

I don't think this is reflected in your revised section.

> > This question needs to be restarted, nodes aren't multicast
> > or unicast, they handle both.   If you're asking if anyone
> > believes that ICMP name requests sent to multicast addresses
> > should be answered, then no, I would doubt you'll find many
> > takers.
> >
> Good, I'll add that note to the draft.

Not many implies that there are some.  I happen to think it is a good 
idea to have all of them respond.  The "storm" that the replies generate
is going to be how catastrophic?

> The section now reads:
> 
>     Only a few well-known multicast addresses are populated in the
>     IN-ADDR domain. The ephemeral nature of most multicast addresses is
>     not conducive to cooperative secure updating.
> 
>     However, the technique described here is not useful for multicast
>     addresses. A query to a multicast address could result in a storm of
>     replies. Most multicast groups are not named, or the member nodes
>     are not configured with the name. Well-known multicast addresses
>     should continue to use the IN-ADDR method.
> 

Define "well-known" please?  Anyone can do the registration process and
thereby become "well-known".

-- 
--bill