Subject: Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 Nov 2009 18:23:29 -0500

I am not so sure that immediately going to PS is the best approach
considering the overall objective. My goal here would be to encourage
the widest possible adoption of the spec by equipment manufacturers.

The weakness I see in both the Microsoft and the Apple attempts to
simplify ease of net device configuration is that the use cases are
centered on the consumer with only minor consideration being given to
enterprise use. This is a poor adoption strategy as consumers do not
in general issue RFPs and thus attract rather little notice in
marketing departments. I somehow doubt that even educated consumers
will think to ask for UPnP support in a focus group.

The features that are being supported are features that are equally
important to the cost conscious enterprise. Configuration of network
devices costs far too much and is far too error prone.

90% of this proposal is equally relevant to the enterprise case. But
the multicast part is not. I have managed networks with tens, hundreds
of thousands of devices. There is no way that I am ever going to turn
on any protocol that involves broadcast or multicast as a
configuration mechanism. Rather too much of my network bandwidth is
consumed by idle chatter between machines as it is.

On the question of 'hijacking' of .local, I don't see any problem.
There is no way on earth that ICANN could possibly sell that TLD if
they tried, far too much relies on it not being routed.

I would see a problem if there was a likelihood here that we would end
up with different semantics for .local names. I don't think that is
likely to happen.

.local was set aside years ago for something of this nature, I don't
see a problem with using it here.

On Mon, Nov 30, 2009 at 1:39 PM, Stuart Cheshire <[email-masked]> wrote:
> On 23 Nov, 2009, at 09:11, Cullen Jennings wrote:
>
>> Pretty much all the emails I have received on this have suggested we
>> should just go publish it now. To be clear, I was not talking about forming
>> a WG to go do a standards track version of this. I was talking about
>> clicking one flag in the data tracker and changing it from information to
>> standards track and publishing the draft "as is" as standards track.
>
>
> I support this, with one modification: I don't think we need to commit to
> publishing this draft literally "as is".
>
> People like Dave Cridland have pointed out legitimate style criticisms,
> which I'm happy to fix in the next couple of weeks.
>
> As I'm sure you know (but others may not) a Standards-Track RFC doesn't need
> a Working Group. It's possible to have an Individual Submission
> Standards-Track RFC, subject to the IETF community reviewing it and finding
> it to be worthwhile, and this would not be the first time I've done that.
> Last year we published RFC 5227, "IPv4 Address Conflict Detection", as an
> Individual Submission Standards-Track RFC.
>
> I think Multicast DNS easily meets criteria for Proposed Standard. In fact,
> in terms of stability, maturity, deployment, number of independent
> implementations, etc., it easily meets criteria that for other protocols
> would qualify them for Draft Standard status.
>
> When other Standards-Track RFCs and other standards bodies (ECMA, WiFi
> alliance, ISO/IEC, XMPP, etc.) need to reference Multicast DNS, having a
> Standards-Track document to reference helps avoid procedural objections.
>
> Stuart Cheshire <[email-masked]>
> * Wizard Without Portfolio, Apple Inc.
> * Internet Architecture Board
> * www.stuartcheshire.org
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Dec 2009 12:27:37 -0500

If multicast worked it would be the ideal protocol for NNTP. As far as
an NNTP client is concerned, the protocol could be functioning over
multicast.

In practice of course multicast would not be a useful protocol for
NNTP because you would at a minimum need a separate multicast channel
per newsgroup since not every news server is interested in every
group. So under the covers NNTP is doing something more intelligent at
the application layer that ensures that packets only travel over the
wire to devices that are interested in them.

This proposal uses multicast and thus every device will see a lot of
traffic it has no interest in or use for. That is a bad application
architecture in my view. It is only tolerable to the extent that in a
LAN you can use Ethernet broadcast in place of multicast.

That is why I am somewhat skeptical of your claim that the protocol is
widely deployed. There is no way that a multicast packet can rout in
or out of this house as far as I am aware and I find it unlikely that
would change. There is no way that multicast would traverse a properly
configured firewall either.

I do not understand quite why there is this obsession with the idea
that network configuration should be performed at the peer level. It
has given us a series of protocols that network managers spend their
time working to disable because they are unacceptably chatty and
horrendously slow. I do not want my coffee pot participating in my
network as a peer. I want it to have the minimum network access to
support its function and absolutely nothing more.

Both my Mac and my Windows boxes take a noticeable length of time to
work out what is on the local network here. Even the wired endpoints
occasionally lose synchronization with each other.

DECNet solved this problem twenty years ago, and therefore the patents
must have expired. Instead of every machine in the network trying to
manage it you nominate a small number of machines as members of the
cluster and give them a vote. Only the three to seven members of the
cluster need to spend any time chattering and keeping their network
databases in sync. If any voting member of the quorum fails, its
functions are taken over by the remaining ones.

There is a network quorum, a voting member of the quorum only updates
network status information if it has a recent vote from a quorum of
voting members. This ensures that the network database is always
consistent even if the network cable is cut. (Yes, they didn't degrade
as well as they should in Decnet, but that was an implementation
mistake, not an architectural constraint).

It is worth pointing out some features that this architecture
supported that are not available on the Internet in anything like the
same form. You could write a server application in a couple of hours
that was fully ACID and fault tolerant.  The system would stay running
even if a machine died. And when the other machine came back it could
resync transparently.

I do not think multicast is at all important to this proposal. It is a
case of using a glass hammer to drive home a nail.

On Mon, Nov 30, 2009 at 7:56 PM, Stuart Cheshire <[email-masked]> wrote:
> On 30 Nov, 2009, at 15:23, Phillip Hallam-Baker wrote:
>
>> 90% of this proposal is equally relevant to the enterprise case.
>> But the multicast part is not.
>
> The document is called "Multicast DNS". Which parts of the document do you
> think do *not* relate to multicast?
>