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@xxxxxxxxx> 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@xxxxxxxxx> > * Wizard Without Portfolio, Apple Inc. > * Internet Architecture Board > * www.stuartcheshire.org > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf