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
<cheshire(_at_)apple(_dot_)com> 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 <cheshire(_at_)apple(_dot_)com>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
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/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf