Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 2009-12-04, at 07:38, Phillip Hallam-Baker wrote: 'largely semantic?' Yes, by which I meant having little practical impact on the business of shifting packets on the network. The other text that you couldn't see due to the searing bright pain you apparently felt when presented with the two words you quoted would perhaps have helped to make that clear. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Wed, Dec 02, 2009 at 02:12:01PM -0500, Phillip Hallam-Baker wrote: The alternative would be to not use .local at all and insist on that approach as a means of avoiding ICANNs perceived perogatives. I think that would be a bad idea as the spec would not serve its intended purpose. I've been puzzling over what to make of that message since receiving it, and I still don't know. Since you admit in your last sentence that leaving .local out would in fact not achieve the goal of documenting a protocol in wide use (even if in limited cases, and in a way not apaprently enterprisey enough for your taste), why would you leave out .local? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
'largely semantic?' Please do not ever use that phrase again as an attempt to dismiss the importance of an argument SEMANTICS IS MEANING EVERY argument in the IETF is an argument in semantics, that is the alpha and omega of the IETF process. Arguments over semantics are only trivial when they are post-facto attempts to redefine the meaning of what has already been said, usually futile as one party or other attempts to misrepresent the content. Arguments over the semantics of a contract are not trivial. On Thu, Dec 3, 2009 at 11:18 PM, Joe Abley jab...@hopcount.ca wrote: On 2009-12-02, at 14:12, Phillip Hallam-Baker wrote: The alternative would be to not use .local at all and insist on that approach as a means of avoiding ICANNs perceived perogatives. I think that would be a bad idea as the spec would not serve its intended purpose. Given the existing deployed base of this protocol, and the desire expressed by many to document what has been deployed, I don't think that insisting that current practice change is a useful approach. I read on another list recently the observation that ICANN's draft applicant guidebook already reserves LOCAL as a name that can't be registered as a new gTLD. http://www.icann.org/en/topics/new-gtlds/draft-evaluation-procedures-clean-04oct09-en.pdf See the table on page 2-6. I have no involvement with the new gTLD programme at all, but it seems possible that concern over a clash between a local delegation from the root zone and the use of local by Apple and others is largely semantic. No doubt semantic concern can still be valid; however, I think the distinction between real lurking operational danger and theoretical possibility for conflict in the distant future is worth making. Joe -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 2009-12-02, at 14:12, Phillip Hallam-Baker wrote: The alternative would be to not use .local at all and insist on that approach as a means of avoiding ICANNs perceived perogatives. I think that would be a bad idea as the spec would not serve its intended purpose. Given the existing deployed base of this protocol, and the desire expressed by many to document what has been deployed, I don't think that insisting that current practice change is a useful approach. I read on another list recently the observation that ICANN's draft applicant guidebook already reserves LOCAL as a name that can't be registered as a new gTLD. http://www.icann.org/en/topics/new-gtlds/draft-evaluation-procedures-clean-04oct09-en.pdf See the table on page 2-6. I have no involvement with the new gTLD programme at all, but it seems possible that concern over a clash between a local delegation from the root zone and the use of local by Apple and others is largely semantic. No doubt semantic concern can still be valid; however, I think the distinction between real lurking operational danger and theoretical possibility for conflict in the distant future is worth making. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Tue, Dec 01, 2009 at 04:21:02PM -0800, SM wrote: Note that this use of the .local. suffix falls under IETF/IANA jurisdiction, not ICANN jurisdiction. This draft mentions that the IETF has the authority to instruct IANA to reserve pseudo-TLDs as required for protocol design purposes. There is no action requested from IANA for .local in the IANA Considerations section. There is in fact a request, it's just made indirectly. That was my complaint. I'm aware that the draft claims this is an IETF/IANA responsibility and not an ICANN one. I'm not sure I'm convinced, and I think the IESG should take that into account when making their decision about the draft. But I don't think it's a reason to hold it up anyway. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Wed, Dec 02, 2009 at 12:35:11PM -0500, Phillip Hallam-Baker wrote: I want my personal machines to be part of the .hallambaker.com DNS domain and look for configuration data there. I want my business machines to be part of the .defaultdenysecurity.com domain and look for configuration data there. My reading of the draft actually allows you to do this anyway. So what's the problem? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
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 chesh...@apple.com 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? Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
I don't think the IESG or ICANN should go there, or anywhere close. There are three options: 1) Do not reserve .local. This would effectively mean throwing out the draft as it depends on .local 2) Reserve .local for this particular protocol. This would be inconsistent with current legacy use and is neither necessary, nor appropriate. 3) IESG, IANA and ICANN note that by longstanding convention .local is already allocated for the purpose of local DNS configuration. Then the IESG notes that this draft specifies an example of such use and that requires appropriate wording in the draft to note that deployments must be aware that usage may not be consistent. There is a final option which would be that devices receive the default domain name that they are to use for configuration as part of the DHCP protocol and that this can be overriden. This seems rather more logical to me than declaring a magic number and considerably more flexible. I want my personal machines to be part of the .hallambaker.com DNS domain and look for configuration data there. I want my business machines to be part of the .defaultdenysecurity.com domain and look for configuration data there. On Wed, Dec 2, 2009 at 9:27 AM, Andrew Sullivan a...@shinkuro.com wrote: On Tue, Dec 01, 2009 at 04:21:02PM -0800, SM wrote: Note that this use of the .local. suffix falls under IETF/IANA jurisdiction, not ICANN jurisdiction. This draft mentions that the IETF has the authority to instruct IANA to reserve pseudo-TLDs as required for protocol design purposes. There is no action requested from IANA for .local in the IANA Considerations section. There is in fact a request, it's just made indirectly. That was my complaint. I'm aware that the draft claims this is an IETF/IANA responsibility and not an ICANN one. I'm not sure I'm convinced, and I think the IESG should take that into account when making their decision about the draft. But I don't think it's a reason to hold it up anyway. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
The alternative would be to not use .local at all and insist on that approach as a means of avoiding ICANNs perceived perogatives. I think that would be a bad idea as the spec would not serve its intended purpose. On Wed, Dec 2, 2009 at 1:55 PM, Andrew Sullivan a...@shinkuro.com wrote: On Wed, Dec 02, 2009 at 12:35:11PM -0500, Phillip Hallam-Baker wrote: I want my personal machines to be part of the .hallambaker.com DNS domain and look for configuration data there. I want my business machines to be part of the .defaultdenysecurity.com domain and look for configuration data there. My reading of the draft actually allows you to do this anyway. So what's the problem? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
At 06:27 02-12-2009, Andrew Sullivan wrote: There is in fact a request, it's just made indirectly. That was my complaint. I'll second your complaint. RFC 5226 provides guidelines to authors on what sort of text should be added to their documents in order to provide IANA clear guidelines. Indirect requests do not provide clear guidelines. I'm aware that the draft claims this is an IETF/IANA responsibility and not an ICANN one. I'm not sure I'm convinced, and I think the IESG should take that into account when making their decision about the draft. But I don't think it's a reason to hold it up anyway. I'm ambivalent about having all that in this draft as it is Informational. I would have suggested Standard Track if it wasn't for the Private DNS Namespaces section and the style of the draft. I suggest putting the .local request in a BCP for IETF Consensus and publishing the rest of this draft as Informational. The better approach, in my opinion, for the BCP document would be to have IANA has agreed ... instead of invoking RFC 2860. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
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 chesh...@apple.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 chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Dear colleagues, I have read draft-cheshire-dnsext-multicastdns-08. I have some comments. This is not an exhaustive or complete review, although I have shared some previous observations with the authors of the document. First, I must emphasise that, while I currently serve as one of the chairs of the DNS Extensions Working Group, I make my comments as an individual and not as Chair. Neither do I in any way speak for the community or the Working Group. I also want to emphasise that I was not involved in the early history of this draft, and had no official responsibilities of any sort to the DNSEXT WG when this draft came under discussion there some years ago. Given the long and painful history of the draft, and that the protocol it documents is manifestly successful and in wide use, I think it would be a disservice to interoperability if we did not publish it. If for no other reason, I support its publication (under the terms of the question put to us) as an Informational RFC. I think there are sections of the text that could be cleaned up. Leaving aside others' complaints about the number of Apple references in the document, there is a querulousness to the text that is a little jarring. Sentences like It is easy for those of us in the IETF community who run our own name servers at home to forget that the majority of computer users do not run their own name server and have no easy way to create their own host names, despite their evident truth and probable justification in light of some past comment on a mailing list, just aren't needed in a protocol document. If it were up to me, I'd take that sort of thing out. That said, I do not withold my support on this basis. The IANA Considerations section is a little coy in the way it notes that the document reserves .local. Moreover, the action is not merely to IANA, but strictly to ICANN, and I worry about the procedural rules for such an action. If there is a strong reason to put this document on the standards track, the use of .local is surely it. I like the way the document emphasises that, in a multicast environment, many of the assumptions one might make about uniqueness are wrong. I think this is quite right, and I hope clients and implementers will take heed. The discussion of port 5353 vs. 53 is comprehensive without rehashing the entire history of that debate. (Contrast this with my previous comment about querulous bits of the text. One can outline the background without sounding annoyed by snipers.) I am unwilling right now to make an argument in favour or against moving this document to the standards track. I think there are arguments to be constructed in both directions, but when I consider the value to interoperability, it seems to me that getting something published, even in a flawed way, is more important than picking exactly the right document stream. Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
At 14:29 01-12-2009, Andrew Sullivan wrote: The IANA Considerations section is a little coy in the way it notes that the document reserves .local. Moreover, the action is not merely to IANA, but strictly to ICANN, and I worry about the procedural rules for such an action. If there is a strong reason to put this document on the standards track, the use of .local is surely it. Quoting Section 3.1: Note that this use of the .local. suffix falls under IETF/IANA jurisdiction, not ICANN jurisdiction. This draft mentions that the IETF has the authority to instruct IANA to reserve pseudo-TLDs as required for protocol design purposes. There is no action requested from IANA for .local in the IANA Considerations section. In contrast, private uses of the DNS protocol on isolated private networks are not governed by ICANN. Since this change is a change to the core DNS protocol rules, it affects everyone, not just those machines using the ICANN-governed Internet. Is any other use of the DNS protocol governed by ICANN? Could the authors please drop the reference to the ICANN-governed Internet? I suggest dropping Section 3.1 as it is not the type of content generally discussed in an Informational document. In Section 6.3: iTunes users are accustomed to seeing a list of shared network music libraries in the sidebar of the iTunes window. There is no refresh button for the user to click because the list is expected to be always accurate, always reflecting the currently available libraries, without the user having to take any manual action to keep it that way. When a new library becomes available it promptly appears in the list, and when a library becomes unavailable it promptly disappears. It is vitally important that this responsive user interface be achieved without naive polling that would place an unreasonable burden on the network. The above is superfluous. In Section 15: A host SHOULD defend its host name (FQDN) on all active interfaces on which it is answering Multicast DNS queries. What does that mean? In Section 17: Set-top boxes (e.g. Apple's Apple TV) connected to a television can play music, photographic slide shows, and movies stored on the user's desktop computer (e.g. an iMac running iTunes) -- but only if that desktop computer is not asleep. Services like Apple's Back to My Mac allow users to access data on their home computers from remote locations, using screen sharing or file sharing -- but only if their computer at home is not asleep. Could the authors please remove such references? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
james woodyatt writes: If it could be published as standards-track, instead of informational, *without* *any* *further* *delay*, that would be excellent. However, I believe there is nothing to be gained for the Internet community by any further delay in publishing this important document. It should have been published years go, fergawdzakes. Faster, please. It's not difficult to get a standards-track RFC out quickly from this point. Unusual, yes, but not difficult. Mark Crispin did it in a week or so for RFC 4315 (another basically sound document with severe but superficial problems). The document author/editor has to react to comments and fix issues promptly. That's all there really is to it. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have reviewed draft (-08) and support it, on the Informational track. Review comments. * The NSEC type is used for negative responses (from a discussion in DNSEXT). However, the draft specifies that only the bitmap for types 0-255 is to be included. I feel this is overly constrained. The restriction may prove burdensome, also since those types are not really in use anyway (except DLV), the effect of the rule is very low. Is this for backwards compatibility? If it is for packet size, well, TXT records can be large too and are not disallowed either. * The document is verbose, but well written. * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. * The mdns resolver is highly integrated into the device it is on, with an 'active interest and notification API'-recommended, with interface changes (up down netmasks) and sleep-wake cycle information used. Thus this is very different from unicast DNS, whose servers are more independent. The rule to do punycode (unicast) to utf8 (multicast) conversion does not make the codebase smaller. * There is a line about the use of DNSSEC when mdns is used during a unicast DNS outage. The sentiment about protecting against forged answers is fine (this issue is handled well in general), but I think building a chain of trust towards DNSSEC-attested data is going to be very hard when unicast DNS is down. * I noted that the TC flag on unicast still means TCP fallback but this does not work in all cases. It is of course very useful to get large replies to legacy (unicast) queriers. Case: the other hosts can see a multicast query, and the full answer cannot be sent on multicast (due to size, even with TC=1 on multicast for message concatenation), the other hosts conclude there is no answer after timeout. The unicast response to the querier does have the required effect, but only for the original querier. This is probably not an issue since such large (9kb RR rdata) records are not common. A response that would trigger TCP connections from all multicast hosts on the network is probably not such a good idea :-) Some multicast error response, SERVFAIL for that query, so the other hosts do not modify their cache? (since existing code ignores rcode!=0, this is probably backwards compatible) * It may be prudent to have in conflict resolution a line that says that if repeated conflicted announcements of unique records are observed by another host, then the host SHOULD consider itself to have lost (and rename itself). Or put differently: if a particular host on the network keeps causing conflicts, get out of the way, even if the spec says you should have won, because this avoids packet-chatter on the network. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksM/mEACgkQkDLqNwOhpPjivQCbBx+PkX9gYv5k5ZjVs8Wa1dZW 93EAoIcyGETGZf4UYXZMcVoS2Y2WGY++ =l/6N -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
The biggest problem I have with this document is among those pointed out by Wouter: * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. As stated above, it's already a somewhat common practice to use .local in *private* DNS namespaces (e.g., corporate networks), whether we like it or not, and the current text in the mdns draft section 3 is incompatible with this (i.e., it proposes to break them). The current practice is cited in many places including: http://tools.ietf.org/html/draft-kato-dnsop-local-zones-00 While it has yet been described in a RFC, .local is used to provide a local subspace of the DNS tree. Formal delegation process has not been completed for this TLD. In spite of this informal status, .local has been used in many installations regardless of the awareness of the users. http://en.wikipedia.org/wiki/Top-level_domain The top-level pseudo domain local is required by the Zeroconf protocol. It is also used by many organizations internally, which may become a problem for those users as Zeroconf becomes more popular. And there's lots of places people have complained about this conflict with mdns, such as: http://lists.apple.com/archives/Macnetworkprog/2004/Oct/msg00089.html http://www.markwilson.co.uk/blog/2007/11/managing-simultaneous-access-to-resources-from-both-internal-and-external-dns-namespaces.htm http://www.macosxhints.com/article.php?story=20040806232315819 etc -Dave ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 25 Nov, 2009, at 01:52, W.C.A. Wijngaards wrote: * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. I think you may be misreading this. A statement of MUST do X does not imply MUST NOT do NOT X. A host implementing Multicast DNS, performing a Multicast DNS query, MUST send that query to the Multicast DNS port, or it won't work. There's no SHOULD about it. An implementation cannot choose to send the Multicast DNS query to a different port and expect it to work. A host implementing Multicast DNS generally implements a variety of other name resolution mechanisms like standard unicast DNS, NetBIOS, a local /etc/hosts file, etc., and names can be looked up via those mechanisms too. Indeed, you will find that if you install iTunes on your PC, even at a site that's set up a private DNS server for local, the sky does not fall. What happens is that Windows (and Mac OS X too) look up dot-local names both ways. Looking up names more than one way is not as efficient as it could be, and it might be better if we didn't have to do that, but it does work. I will add some text explaining this. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
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? Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * Internet Architecture Board * www.stuartcheshire.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I have reviewed draft (-08) and support it, on the Informational track. (apologies for any duplicates as I tried to send this unsubscribed) Review comments. * The NSEC type is used for negative responses (from a discussion in DNSEXT). However, the draft specifies that only the bitmap for types 0-255 is to be included. I feel this is overly constrained. The restriction may prove burdensome, also since those types are not really in use anyway (except DLV), the effect of the rule is very low. Is this for backwards compatibility? If it is for packet size, well, TXT records can be large too and are not disallowed either. * The document is verbose, but well written. * The rule that .local names MUST be sent to mdns(port 5353). I feel this is a little too strong, there are sites out there that have set ups with .local in their unicast DNS. Propose: SHOULD. * The mdns resolver is highly integrated into the device it is on, with an 'active interest and notification API'-recommended, with interface changes (up down netmasks) and sleep-wake cycle information used. Thus this is very different from unicast DNS, whose servers are more independent. The rule to do punycode (unicast) to utf8 (multicast) conversion does not make the codebase smaller. * There is a line about the use of DNSSEC when mdns is used during a unicast DNS outage. The sentiment about protecting against forged answers is fine (this issue is handled well in general), but I think building a chain of trust towards DNSSEC-attested data is going to be very hard when unicast DNS is down. * I noted that the TC flag on unicast still means TCP fallback but this does not work in all cases. It is of course very useful to get large replies to legacy (unicast) queriers. Case: the other hosts can see a multicast query, and the full answer cannot be sent on multicast (due to size, even with TC=1 on multicast for message concatenation), the other hosts conclude there is no answer after timeout. The unicast response to the querier does have the required effect, but only for the original querier. This is probably not an issue since such large (9kb RR rdata) records are not common. A response that would trigger TCP connections from all multicast hosts on the network is probably not such a good idea :-) Some multicast error response, SERVFAIL for that query, so the other hosts do not modify their cache? (since existing code ignores rcode!=0, this is probably backwards compatible) * It may be prudent to have in conflict resolution a line that says that if repeated conflicted announcements of unique records are observed by another host, then the host SHOULD consider itself to have lost (and rename itself). Or put differently: if a particular host on the network keeps causing conflicts, get out of the way, even if the spec says you should have won, because this avoids packet-chatter on the network. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAksOSkkACgkQkDLqNwOhpPg5PACfaUMmPV/IB5+AzDQ2rDlmQsnc nBkAnAv3WG5fdRoi41EKIWcyx/3oQblB =k2RH -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Thu Nov 26 09:28:41 2009, W.C.A. Wijngaards wrote: * It may be prudent to have in conflict resolution a line that says that if repeated conflicted announcements of unique records are observed by another host, then the host SHOULD consider itself to have lost (and rename itself). Or put differently: if a particular host on the network keeps causing conflicts, get out of the way, even if the spec says you should have won, because this avoids packet-chatter on the network. Wouldn't this lead to a potential attack by deliberately introducing a conflict and taking over a name? Currently, it's possible to take over a name by advertising, for example, an A record for a name with a higher IP address - since you can easily advertise a name with an arbitarily high IP address, this is fairly easy to do, but it'd be far simpler just to ignore the probe protcol entirely, as that leads to a more seamless takeover of a particular name in most circumstances. Of course, DNSSEC might help here, but presumes that either a participant has the ability to sign RRs online, or else is a silent partner with a preconfigured trust anchor. (In general, I find the comments in the document about DNSSEC somewhat hand-wavy, but I admit I lack much knowledge about DNSSEC). Still, if all participants have access to the private key for DNSSEC, that provides a significant number of possible attack points, I'd have thought - I'm assuming here that things like your network printer need to be configured with the private key, which may not be the case. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Wed, Nov 18, 2009 at 06:07:17AM -0800, The IESG iesg-secret...@ietf.org wrote a message of 23 lines which said: - 'Multicast DNS ' draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC I do not think that the publication of this document as it is would be a good idea. The main reason is that it reserves a Top-Level Domain (.local) which is already used at many sites, without any sort of reasonable process, except we already decided to use it and deployed the code. Unlike what the text of the I-D says in section 3.1, there is little evidence that IETF can do so. Unless what happened with RFC 2606, nothing indicates that IANA/ICANN or any other body agreed to the hijack. The I-D also gives questionable advices such as using .home or .lan which are not (and for good reasons) in RFC 2606. The only reasons given in the current discussion on ietf@ietf.org are it is already deployed and we need such a protocol for the dentist's office. The first one is weak: certainly, it should not be possible for any company to have a RFC just by deploying a protocol is has unilaterally conceived. The IETF is not a Patent Office: it *does* check the applications. Also, the I-D is not a pure description of a deployed protocol. For instance, it says it is even more important to use DNSSEC or other security mechanisms to ensure that the response is trustworthy while the current implementations have no such mechanism. The second reason is also questionable since IETF already has RFC 4795, which is not mentioned even once in the I-D we are discussing! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Nov 19, 2009, at 06:14 , Dave Cridland wrote: There exist a few protocols based around mDNS and DNS-SD, in particular in combination, and the general high-level design of both protocols is essentially sound. These are sometimes standards-track specifications of the IETF - I seem to recall some of the SIP related protocols are DNS-SD/mDNS based. In other SDOs, there are also standards track specifications based around the combination, such as the XSF's XEP-0174 - http://www.xmpp.org/extensions/xep-0174.html - and these are also reliant on a stable, well-specified, protocol. To my mind, this implies that both specifications need to be standards track, if that status has any meaning at all - and I firmly believe it should and does. Chiming in to add another ongoing standards effort that would like to reference this document by its RFC number: the TC32-TG21 - Proxying Support for Sleep Modes program at ECMA International, which is now circulating a draft for TC postal vote. See http://www.ecma-international.org/memento/TC32-TG21-M.htm for more information about this effort. One reason to prefer a standards track document here would be to preempt procedural objections in ISO/IEC about references to informational category IETF documents, which have been known to arise from time to time in that body. There is some concern in TC32-TG21 about such objections to ancillary citations of RFC 4795, which is *also* an informational category document. It's possible ISO/IEC won't object to the informational status of either document, but we have a chance to preempt those objections now by publishing mDNS as standards-track. That said, having an RFC number for an informational mDNS document-- in a small number of weeks-- would be orders of magnitude more preferable than not having it, and having to wait an indefinite period of time for a standards track RFC to be published, if that's what IETF decides to do. To make the obvious explicit, I support publishing this document as an RFC without any further delay. If it could be published as standards-track, instead of informational, *without* *any* *further* *delay*, that would be excellent. However, I believe there is nothing to be gained for the Internet community by any further delay in publishing this important document. It should have been published years go, fergawdzakes. Faster, please. -- james woodyatt j...@apple.com member of technical staff, communications engineering ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Mon Nov 23 00:17:45 2009, Lawrence Conroy wrote: There have been a number of cases where things are not developed within the IETF but are out there. Agreed. Whether or not folk LIKE those schemes/the companies that promulgate them/the author(s) /the document style/the weather is not really important. You make it sound like I have some trivial personal axe to grind - I do not, although I readily agree that I do not like the document style. (And I wasn't the only one to raise this comment about dns-sd, the sister document). Having an Informational RFC to describe these protocols or file formats is useful. If nothing else, it tells you what the heck is going on down the wire. Right, this much I agree with. And if this was an isolated protocol, I would not be concerned with it at all - it is, as you imply, what Informational is *for* - well, modulo the marketing, anyway. But there are, as I say, a number of standards-track protocols both in the IETF and other SDOs which depend on these two documents, just as was the case a year ago: http://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=44223tid=1244548867 As it happens, the IETF documents haven't advanced - and I wonder if that's in part because mDNS and DNS-SD haven't been made standards-track. I'm not arguing against the protocol's existence, and not against its documentation. I'm arguing that we should take the time to document it clearly, and ensure that it can be easily implemented in an interoperable manner from that documentation, and - potentially - make a handful of compatible changes where appropriate. Burying it in a WG to try (and fail) to turn this into an IETF standards-track document is not helpful. I fear that someone will go postal if we do Zeroconf again. There has been So much history that it is simply not worth repeating the pain. (I seem to recall discussions on this starting out @IETF-41 in LA, since which time it's in very wide use out there :). So you're primary argument against this not being made a standards track document is that it's an awful lot of work, and that it's bound to fail anyway. Well, I can't deny that it *is* a substantial amount of work, but given that this protocol is, as you point out, deployed in the wild, I'm not really sure this is a problem, and arguing the IETF shouldn't put documents on the standards track, with a working group, because it's a lot of work and might fail to produce a useful result does - to me, anyway - sound my irony alarm full blast. Isn't this what the IETF is *for*? So I reiterate - I see no reason not to charter a working group to revise this specification (and dns-sd), and I would welcome such a group being chartered such that it cannot make any incompatible changes to the protocol. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Dave Cridland writes: So I reiterate - I see no reason not to charter a working group to revise this specification (and dns-sd), and I would welcome such a group being chartered such that it cannot make any incompatible changes to the protocol. +1 Except that I'd put the compatibility requirement in terms of deployed code rather than the current draft. Mumble SRV RR mumble compression mumble. The final RFC must be compatible with a version b, c version d and e version f, and if possible with other deployed implementations known to the WG for some values of a-f. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On 11/23/09 6:49 AM, Dave Cridland wrote: On Mon Nov 23 00:17:45 2009, Lawrence Conroy wrote: Having an Informational RFC to describe these protocols or file formats is useful. If nothing else, it tells you what the heck is going on down the wire. Right, this much I agree with. And if this was an isolated protocol, I would not be concerned with it at all - it is, as you imply, what Informational is *for* - well, modulo the marketing, anyway. But there are, as I say, a number of standards-track protocols both in the IETF and other SDOs which depend on these two documents, just as was the case a year ago: http://www.ietf.org/ibin/c5i?mid=6rid=49gid=0k1=933k2=44223tid=1244548867 As it happens, the IETF documents haven't advanced - and I wonder if that's in part because mDNS and DNS-SD haven't been made standards-track. I'm not arguing against the protocol's existence, and not against its documentation. I'm arguing that we should take the time to document it clearly, and ensure that it can be easily implemented in an interoperable manner from that documentation, and - potentially - make a handful of compatible changes where appropriate. Burying it in a WG to try (and fail) to turn this into an IETF standards-track document is not helpful. I fear that someone will go postal if we do Zeroconf again. There has been So much history that it is simply not worth repeating the pain. (I seem to recall discussions on this starting out @IETF-41 in LA, since which time it's in very wide use out there :). So you're primary argument against this not being made a standards track document is that it's an awful lot of work, and that it's bound to fail anyway. Well, I can't deny that it *is* a substantial amount of work, but given that this protocol is, as you point out, deployed in the wild, I'm not really sure this is a problem, and arguing the IETF shouldn't put documents on the standards track, with a working group, because it's a lot of work and might fail to produce a useful result does - to me, anyway - sound my irony alarm full blast. Isn't this what the IETF is *for*? So I reiterate - I see no reason not to charter a working group to revise this specification (and dns-sd), and I would welcome such a group being chartered such that it cannot make any incompatible changes to the protocol. There are two separate actions that could be taken here: a. Publish draft-cheshire-dnsext-multicastdns as an Informational RFC (call it mDNS 1.0 if that makes people happy). b. Charter a WG to complete work on a standards-track protocol for the same or similar functionality (call it mDNS 1.1). Are you in favor of a-and-b, or b-only? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
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. The consensus seems to be: this document is important to get publish soon and is used by many other standards. Because of this, this draft is too important to publish it as standards track and we should publish it as informational instead. Anyways, I'm convinced that having this as a RFC is important and decided that I, like most other people, could care less if it was experimental or full standard as that will be close to irrelevant for what interoperability this enables on the internet. On 18 Nov 2009, at 15:41, Cullen Jennings wrote: Can someone walk me through the pro/cons of this being standards track vs informational? Thanks, Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Hello Cullen, I have started reading draft-cheshire-dnsext-multicastdns for an Apps Area review. I also started asking myself the question of standards track vs. informational. However, this was not in the general sense, but in regards to some very specific issues. In the general sense, I was assuming that this was Informational because it documented an existing practice and deployment by an existing company. Where I wasn't at all sure about whether Informational was appropriate was things such as reserving the top-level domain name .local with ICANN (Section 3). Of course the IETF has the rigth to do this, but shouldn't this be done in a standards track or BCP document? Regards,Martin. On 2009/11/19 0:41, Cullen Jennings wrote: Can someone walk me through the pro/cons of this being standards track vs informational? Thanks, Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:due...@it.aoyama.ac.jp ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Hi Cullen, folks, It seems to me ... There have been a number of cases where things are not developed within the IETF but are out there. Whether or not folk LIKE those schemes/the companies that promulgate them/the author(s) /the document style/the weather is not really important. Having an Informational RFC to describe these protocols or file formats is useful. If nothing else, it tells you what the heck is going on down the wire. IF the IESG wants to tag on a comment that the described protocol/ format is broken or conflicts with a more sensible IETF-anointed approach, it can and does. I support this as an Informational document. I would like this description out now. Burying it in a WG to try (and fail) to turn this into an IETF standards-track document is not helpful. I fear that someone will go postal if we do Zeroconf again. There has been So much history that it is simply not worth repeating the pain. (I seem to recall discussions on this starting out @IETF-41 in LA, since which time it's in very wide use out there :). Please can we ship this as an Informational, and soon? all the best, Lawrence On 18 Nov 2009, at 15:41, Cullen Jennings wrote: Can someone walk me through the pro/cons of this being standards track vs informational? Thanks, Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
+1 to Informational. Let's get this documentation out there in a stable reference. That doesn't preclude publishing a standards-track version in the future... On 11/22/09 5:17 PM, Lawrence Conroy wrote: Hi Cullen, folks, It seems to me ... There have been a number of cases where things are not developed within the IETF but are out there. Whether or not folk LIKE those schemes/the companies that promulgate them/the author(s) /the document style/the weather is not really important. Having an Informational RFC to describe these protocols or file formats is useful. If nothing else, it tells you what the heck is going on down the wire. IF the IESG wants to tag on a comment that the described protocol/format is broken or conflicts with a more sensible IETF-anointed approach, it can and does. I support this as an Informational document. I would like this description out now. Burying it in a WG to try (and fail) to turn this into an IETF standards-track document is not helpful. I fear that someone will go postal if we do Zeroconf again. There has been So much history that it is simply not worth repeating the pain. (I seem to recall discussions on this starting out @IETF-41 in LA, since which time it's in very wide use out there :). Please can we ship this as an Informational, and soon? all the best, Lawrence On 18 Nov 2009, at 15:41, Cullen Jennings wrote: Can someone walk me through the pro/cons of this being standards track vs informational? Thanks, Cullen smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Since people thought I was merely being amusing, instead of also intending to make a point, let me rephrase in a dry, dull, and serious tone, so I'm no longer told it was very amusing, but not much help. There exist a few protocols based around mDNS and DNS-SD, in particular in combination, and the general high-level design of both protocols is essentially sound. These are sometimes standards-track specifications of the IETF - I seem to recall some of the SIP related protocols are DNS-SD/mDNS based. In other SDOs, there are also standards track specifications based around the combination, such as the XSF's XEP-0174 - http://www.xmpp.org/extensions/xep-0174.html - and these are also reliant on a stable, well-specified, protocol. To my mind, this implies that both specifications need to be standards track, if that status has any meaning at all - and I firmly believe it should and does. Unfortunately, the specification of both of them suffers in, essentially, the same ways. - They use RFC 2119 language in an informational specification, which at the least carries with it a strong implication that the intent is to specify a standard. - They repeat the base specifications they refer to, and even in some cases contradict, for unclear benefit. (For example in mDNS, the mandatory requirement to use compression in the first label of an SRV record). - A considerable amount of space is given over to Apple trademarks, which I confess to finding deeply irritating. mDNS is not nearly so bad as DNS-SD in this regard, but this still applies. I have no problem with acknowledging the input of Apple here, but there's a thin line between acknowledgement and outright product placement. In summary, I think both specifications would derive enormous benefit from WG-level review and experienced specification-crafting. This need not result in any changes which are not backwards compatible - indeed, I find it unlikely given the levels of deployment that exist. FWIW, I see no need to go through an extensive BOF process, and - again given the levels of deployment - I'd anticipate rapid progress through the standards-track ought to be possible. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Can someone walk me through the pro/cons of this being standards track vs informational? Thanks, Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Wed Nov 18 15:41:18 2009, Cullen Jennings wrote: Can someone walk me through the pro/cons of this being standards track vs informational? Cons: For one thing, it's a lot of work to make a specification like this up to the quality of the standards-track. Some of the 20 or so mentions of Apple™ and its trademarks may be removed during the standardization work. It's much harder to get away with using apple.com™ for most of the example domains, for instance. The standards track doesn't mean anything anymore. It's so last decade. mDNS™ only really needs an RFC number, and a couple of trendy (preferably French™-sounding) product names carefully placed in the document. What if changes are demanded by those annoying DNS experts? That might break backwards compatibility with the existing deployment, starting from Apple™ Jaguar™ OS X™ 10™, in case I've not mentioned that in a few paragraphs. Pros: Only really annoying old stick-in-the-muds would think of anything positive to come out of making a consensus-driven, interoperable standards-track specification, which'd be almost completely out of the control of a single entity. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Multicast DNS ' draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. i support this proposal. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
Cullen Jennings wrote: Can someone walk me through the pro/cons of this being standards track vs informational? Apple supports it. Linux supports it (mostly). BSD supports it (mostly). So half the world supports it. When Microsoft too supports it, it is a standard. I do support it (becomming a standard). Well, making this a standard keeps people from building something colliding with existing implementations. Kind regards Peter -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: pe...@peter-dambier.de http://www.peter-dambier.de/ http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ULA= fd80:4ce1:c66a::/48 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC
On Nov 18, 2009, at 9:45 AM, Paul Vixie wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Multicast DNS ' draft-cheshire-dnsext-multicastdns-08.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. i support this proposal. +1 Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
