Re: Last Call: <draft-cheshire-dnsext-multicastdns-12.txt> (Multicast DNS) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stephane,

I won't speak to the complaints you raise below, other than to say that as an IANA port reviewer, we need to have this problem sorted, and now. Perhaps not every other request, but nearly every other request is for a UDP port for discovery. I do believe that the work should be done properly and that Apple should be willing to modify their implementation accordingly, if changes are required, as discussed below.

Eliot

On 10/27/10 9:36 AM, Stephane Bortzmeyer wrote:
On Tue, Oct 26, 2010 at 07:58:25AM -0700,
 The IESG <iesg-secretary@xxxxxxxx> wrote 
 a message of 31 lines which said:

The IESG has received a request from an individual submitter to consider
the following document:
- 'Multicast DNS'
  <draft-cheshire-dnsext-multicastdns-12.txt> as a Proposed Standard
There are several issues at stake:

1) Proposed Standard is certainly not the appropriate status. There
was never an IETF consensus about a solution for "link-local"
DNS. There were two competing proposals (the first one, RFC 4795, is
not even mentioned in draft-cheshire-dnsext-multicastdns, which I find
extremely petty). There is zero reason to give a special treatment to
"multicast DNS" (a bad name, since it is not the DNS at all). A
reasonable status would be Experimental since it was the one used for
SPF (now RFC 4408) which, like "multicast DNS", was widely implemented
when published as a RFC (as of today, 20Â% of domains in .FR have a
SPF record).

2) I let ICANN state if they agree or not about the hijacking of a TLD
in appendix G. But the mention of RFC 2026 is dangerous. RFC 2026 says
"IANA has agreed to the four top level domain name reservations" while
nothing indicate such an agreement here. 

3) The advice in Appendix H is extremely bad and must be removed:
suggesting people to use dummy TLD is quite dangerous since these TLD
are not reserved in any way and could be delegated by ICANN at any
moment. The proper solution for local domains is to use a subdomain of
a registered domain (local.example.org, for instance).

_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]