RE: FW: IETF copying conditions
Paul Hoffman writes (RE: FW: IETF copying conditions): Which SDOs that you participate in want to see other SDOs publishing *incompatible* versions of their protocols? The Debian project has published a small (by IETF standards) but significant body of work specifying the interoperation and behaviour of the various parts of what they regard as a modern Unix system, particularly as regards the behaviour of package management systems and the interoperation between separately-maintained packages. The Debian standards documents (the core of which I originally wrote but which have been greatly expanded and enhanced and are now maintained by others) are released under a licences which permit modified redistribution with a definite expectation that derivative systems might want to do things differently. That a different system might do things differently would not be good for Debian so we don't encourage it. We would prefer to keep Debian and its derivatives as close as possible so that we can share development work (particularly, so that we can all benefit from each others' improvements). However, the whole point of Free Software (and thus the point of Debian) is that people are free to modify it. If that means that they are free to cause it to run to incompatible standards, so be it. And that freedom needs to be practically exerciseable collectively as well as individually, so must include the freedom to properly communicate within their own project what they are doing. So we do not use the law to prevent our derivatives from using modified versions of our standards documents if they regard it as necessary. Debian is a not insignificant organisation. There are around 1000 members with voting rights. Many of Debian's choices both at a technical and political level have been influential in the relevant fields. Ian. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Keith Moore writes (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)'to Proposed Standard): The whole idea that local names should look like DNS names and be queried through the same APIs and user interfaces seems, well, wrong (or dubious at best), and needs serious study for the implications of applications using those APIs and the impact of such names on DNS, no? No. Or at least, the point of having something like a link-local name resolution protocol is that you can use the same interfaces to look up the local names when using the link-local protocol, as you do when looking up real DNS names when using the real DNS protocol. That way all the existing applications work and don't need to be changed. Otherwise you would be suggesting building an entirely new protocol and application stack, with changes to every application to support the link-local scheme, which is obviously out of the question. So what you're saying is that you're opposed to whole concept of link-local name resolution. And that therefore you favour LLMNR because it doesn't (in your view) provide it ! Of course you are wrong on this last point - LLMNR will be deployed behind the same APIs currently used to do real DNS lookups. I think that what you've done with your posting, really, is demonstrate Stuart Cheshire's claim that LLMNR is for blocking effort ! IMO, local names and a lookup service for local names would be extremely useful, but neither the names nor the query interface should look much like DNS - the names should look different because otherwise there's too much potential for confusion with DNS names, and the query service should look different because local name lookup service probably can't make the same kinds of consistency or stability assurances that DNS does. To say that, is to say that work on LLMNR should never have been started. There is no demand for a local name resolution protocol which doesn't present a DNS API to applications. You may well say that the whole concept of local name resolution, if it must be presented to applications behind a DNS API, is a bad idea and I have some sympathy with that view - but that's no argument for LLMNR against mDNS ! Stuart seems to be claiming that the people who first told him to take is mDNS away from the IETF, and LLMNR's authors, have that view - and that LLMNR is the result of those people producing a protocol which is intended to look enough like mDNS to fool people but is deliberately _not_ intended to do any of the things that mDNS is good for ! Ian. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Margaret Wasserman writes (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard): The .local doesn't come from either mDNS or LLMNR... The user types it and/or an application includes it in the domain name look-up. So, if the user tries to look up twiki.local, what happens? As I understand it, one of three things will happen: (1) If the system implements mDNS, the .local domain is treated specially, so this just goes out as a link-local request. This is fine and as intended, of course. (2) If the system implements LLMNR, there will first be a global DNS lookup for twiki.local, which will fail. Then, a link-local name request will be tried. This is not fine, as Peter Dambier's experience shows. Firstly, it generates unwanted queries up towards the DNS root (apparently in large numbers, too!). Secondly, if measures are taken to get rid of that unwanted root server traffic, by having (for example) an ISP's caching DNS proxies return 127.0.0.1 or some other answer that the querier will accept, the querier breaks. Why does the querier break ? Well precisely because of the namespace confusion I was just talking about. The querier assumes - without any kind of justification - that queries for .local (or whatever other domain the LLMNR administrator has chosen) will always be happily answered with NXDOMAIN by the `real' DNS as seen from the end system. But, given that choices (2) and (3) involve the same interaction with the DNS, I'm not sure how one can argue that LLMNR makes things any worse than things would be without it. Perhaps you could argue that mDNS makes things better, but that is only true for this one non-existent TLD -- all three systems would generate a bogus global DNS query if I did a DNS lookup for isoc.frog. LLMNR _insists_ on you picking _some_ part of the DNS space and then abusing it this way. Think broader than just the exact effect of the resolution protocol. With any kind of resolution protocol - even with normal DNS - there are decisions to be made about which names to configure in hosts. Those names will then be used for DNS (or DNS-like) lookups. It is true that all of these systems - full DNS, mDNS and LLMNR - will generate bogus DNS queries if systems are configured with bogus names. Part of the mDNS protocol is the expectation that you will configure your hosts to expect certain services to be provided at names in `.local'. If mDNS were an IETF protocol then the RFC would come with an IANA action to allocate mDNS the `.local' TLD - and, de facto, the deployment of mDNS has meant that any other use of `.local' is now difficult or impossible. You may argue that this was wrong, but the mDNS authors did try to get their very sensible protocol put through the IETF process and were told where to go. That's a failure of the whole IETF, not just of the mDNS authors. But only LLMNR _encourages_ (maybe even requires) you to configure your systems with bogus names ! LLMNR hosts will _always_ generate bogus DNS queries for these nonexistent names, and they will always break if and when the real DNS suddenly provides data for those names (either because the relevant nameserver operators are fed up of the query traffic, or because in their wisdom - the namespace belongs to them after all - they've decided to publish some data they themselves want to use). The bogosity of the names in LLMNR is quite different from the problem (if there is a problem) with mDNS. With mDNS the functionality - or the brokenness, if you prefer to look at it like that - is confined to .local. It neither affects mDNS hosts' view of `normal' internet DNS names, nor generates queries to normal internet DNS servers. Ian. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Margaret Wasserman writes (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard): Other than a few minor issues that are being dealt with in a -43 update, I don't think that anyone has raised a blocking technical issue with the LLMNR specification during this IETF LC. If you (or anyone else) has intended to raise a blocking technical issue, either with LLMNR itself or with its ability to coexist with mDNS, please make that clearer to me. Just to be clear, I am intending my contributions to this argument as descriptions of what I see as blocking technical issues with LLMNR. It seems to me from my reading of the specifications that: * LLMNR is a ghastly protocol which should not be on the IETF Standards Track. * mDNS is a superior protocol to LLMNR in nearly all relevant respects. * The IETF should abandon LLMNR and put mDNS on the Standards Track. I'd like to reiterate that I entered this discussion with a strong presupposition towards IETF processes as opposed to third-party activities. As I have read the specifications, and the arguments of those we see reported here, I have become steadily more convinced that Stuart is right about the politics and that LLMNR critics - such as I now am - are right about the technical issues. I am somewhat concerned, for example, that someone could implement LLMNR thinking that it is the same thing as mDNS and only later find that the two do not interoperate. Or that some vendors will ship LLMNR while others ship mDNS, so that products from different vendors will not interoperate. Do others have any thoughts on whether the publication of LLMNR is likely to cause confusion along these lines? It seems to me that these kinds of confusion are almost what the LLMNR proponents are _aiming_ for ! On the other hand, the DNSEXT WG has worked for several years to produce the LLMNR specification, and I don't see anything fundamentally wrong with the mechanism that we have produced (people should respond to the IETF LC if they see blocking technical issues). The LLMNR specification is _terrible_. The issue with namespace ownership, that I've been hammering on about, should in my opinion *of itself* be sufficient to block progress of LLMNR on the Standards Track. The authors of that specification gave change control to the IETF community, and they have gone through 40+ document iterations, working towards a document that would achieve DNSEXT consensus. That process was not followed for mDNS (because it was not the chosen solution), and we currently only have one document (LLMNR) that has reached IETF WG consensus and has been submitted for standards publication. If we believe Stuart Cheshire's description of events, it is not the case that the IETF has chosen LLMNR over mDNS. Rather a subset of the IETF (mainly associated with the DNSEXT WG) were so upset with mDNS as a concept that they have sabotaged it. Furthermore, the point of this exercise is not to measure how much hard work the LLMNR authors have put into their draft. The fact that it has been through 40 document iterations should be a cause for worry, not a cause for applause ! The point of this exercise is for the IETF, as a whole, to standardise on the best protocols. It is possible, in an IETF LC, that we could learn that we do not have IETF consensus to publish something that was produced by an IETF WG. That would be an exceptional and unpleasant situation, [...] If this situation is considered exceptional then I can only think that the mechanisms for detecting it are broken ! Surely it is obvious that it will often be the case that an IETF Last Call will bring the attention of many more people to a situation - and most of those people will not share a community background with the WG members. It is not surprising that in some subset of those cases, it turns out that the WG have gone off in some undesirable direction (either out of technical error or political machination). The WG is a part of the whole IETF and should be subject to its opinions. Ian. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Christian Huitema writes (RE: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard): A key technical difference between LLMNR and the initial MDNS proposal is precisely that LLMNR has no concept of a .local top level domain. While that is true, the next statement: Usage of LLMNR does not promote queries to this zone. is not. LLMNR _requires_ the use of names which do not resolve in the global DNS, and does a global DNS query for each lookup. Although LLMNR doesn't suggest the use of `.local', given that many people don't have a suitable domain to use, they'll use `.local' or something else. This is indeed a key difference between LLMNR and MDNS. MDNS assumes that there is a special zone for local names, which would be linked to the topology. LLMNR assumes that names are independent of the topology, that a host called foo.example.net retains the same name as it move to different locations. There were ample debates of this point in the working group, and the decisions to not creating special names and not linking names to topology do reflect WG consensus. Even if that is so, this posistion doesn't seem to reflect IETF consensus. It is nonsense to say that a `link-local multicast name resolution protocol' provides DNS data which is not linked to the topology ! To say that the _names_ are not linked to the topology is to miss the point and thus to mislead. Given that the _answers_ depend on the topology, wouldn't it be a good idea to be able to indicate that this topology-dependent behaviour is - or is not - desired ? LLMNR only provides that switch - turning on and off topology- dependent behaviour - on a per-host basis. mDNS provides it on a per-lookup basis in a nice easy-to-configure way: specify names in .local and get topology-dependent answers; specify other names and get consistent answers. Ian. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Brian E Carpenter writes (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard): Ian Jackson wrote: Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find senior IETF/IESG people seriously contemplating the kind of namespace confusion which is fundamental in the LLMNR protocol design. Can you spell that out please? Since it uses a different port number, where does the confusion occur? What does the port number have to do with it ? That's an implementation detail (from the point of view of this complaint; many other complaints might well be about these kind of details). The LLMNR model supposes that when an application asks for data of a certain type associated with a certain name (ie, when the application thinks it's asking for a DNS query) answers may come from either the real DNS system or, even if the real DNS is authoritative for the relevant name but denies that it exists, from LLMNR. See draft-ietf-dnsext-mdns-42 s2 bullet point [2]. It is not true that separating LLMNR out on a different port, and introducing other incompatibilities, prevents confusion between LLMNR and the real DNS. Applications will still see a bizarre mix of real and LLMNR data. On the other hand, mDNS has a much better scheme: the mDNS specification defines the tree under `.local' for mDNS use. Names in .local are looked up with mDNS and names elsewhere via the real DNS. This means that applications always either see the data intended for them, or (transient) failure if the relevant mechanism isn't available. Stuart Cheshire makes IMO a very cogent argument in [EMAIL PROTECTED], where he says: ] What's weird about LLMNR is that it blurs what's global and what's local. ] With LLMNR you can call your television tv.ietf.org if you want, and as ] long as the IETF's name server returns NXDOMAIN (which it does today) ] then a LLMNR-compliant host will fail over to local multicast and resolve ] that name to your television's address. This sends a very strange message ] to end users -- it suggests they can use any name they want in any domain ] they want without having to communicate with any registry. It also means ] that every failed DNS query will result in a LLMNR multicast on the local ] network, and (worse) every intentional LLMNR query needs to be preceded ] by a failed DNS query to some unsuspecting DNS server somewhere. ] ] mDNS says that local is a free-for-all playground where anyone can use ] any name and no one has any more right to a particular name than anyone ] else. LLMNR didn't want to do that, but what they've effectively ended up ] doing instead is saying that the root of the DNS namespace (and ] everything below it) is a free-for-all playground where anyone can use ] any name they want. In addition, mDNS's limitation to `.local' means that deliberate additional incompatibilities to avoid cache pollution in the real DNS is not necessary; since mDNS is only used for names in `.local', normal precuations against unsolicited DNS replies will prevent the main DNS namespace being polluted with mDNS data. If we are to so strongly fear pollution, mDNS's wide deployment ought to provide some evidence for this from operational experience ! Where is that evidence ? Ian. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Brian E Carpenter writes (Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard): Russ Allbery wrote: ... I think your criteria doesn't survive logical scrutiny. If other people have access to the standard, can implement the standard, and can build on the standard to create a newer revision of it, I can't imagine what definition of proprietary you're using that would apply. But mDNS is not on the standards track and LLMNR is proposed to be on the standards track. That, I think, is why Stuart has raised the issue. I'm finding this discussion quite disturbing. It seems that the proposal is that the IETF should bless LLMNR because LLMNR is on the Blessing Track. Surely the reasons for the IETF to bless LLMNR as opposed to mDNS should be based on technical details and deployment experience ? In which case it seems clear that mDNS is far superior. It's more widely deployed, more widely implemented, and not COMPLETELY INSANE ! Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find senior IETF/IESG people seriously contemplating the kind of namespace confusion which is fundamental in the LLMNR protocol design. The mDNS approach at least isolates the damage (if you consider it damage) to a specific subregion of the DNS, which you can choose to have on your search path or in your configuration - or not. It's a shame they chose `.local' (which was previously thought to be reserved for local system administrators) but that's too late to change now. This mistake has happened in part because the relevant IETF WG failed to properly engage with the mDNS authors ! I'm in general not a big fan of zeroconf, multicast, or anything else you might think of as weirdo DNS extensions. I'm something of a luddite. But if we're going to have an IETF-standardised protocol to address this problem area, surely we should choose the protocol that's (a) widely deployed, (b) technically superior and (c) less weird ? I haven't read the drafts in detail, but I have read the LLMNR FAQ, expecting to find a biased account of the differences which would lead me to want to read the other side of the story. But in nearly all of the cases, I found myself disagreeing with the LLMNR way of doing things, despite the best efforts of the text I was reading ! As long as they are Internet-Drafts they all have the same status, work in progress, except that LLMNR has gained WG consensus. From what I can see it might be more accurate to say that the DNSEXT WG has been captured by people who have a bee in their bonnet about killing mDNS, or who are at the very least badly misguided. Ian. (not usually a fan of people making wild-sounding statements about IETF WG conspiracies, either!) [1] GNU adns, http://www.chiark.greenend.org.uk/~ian/adns/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard
The IESG writes (Last Call: 'The APPLICATION/MBOX Media-Type' to Proposed Standard ): The IESG has received a request from an individual submitter to consider the following document: - 'The APPLICATION/MBOX Media-Type ' draft-hall-mime-app-mbox-02.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2004-09-06. I have the following comments: * This specification is incomplete. There are unresolved issues regarding the semantics of the format. * Since mbox files are text files (assuming that any binary messages in the mailbox are themselves encoded) and can be read sensibly with the naked eye, the content type should be text/* not application/*. This will also remove ambiguity surrounding line endings. * Since an mbox is actually an aggregate type - a way of encoding a set of RFC822 messages - transfer encodings other than 7bit and 8bit should be discouraged. The spec should probably deprecate them in most cases. * The Proposed Standard should either include or refer to a specific mbox format. The fact that there are variant implementations doesn't mean that the Proposed Standard should hesitate to declare those broken (at least, broken when a file is sent as text/mbox). Those variant implementations are not wholly interoperable anyway, and in order to write software which deals correctly with text/mbox it will be necessary for the spec to say what the format is supposed to be ! * The format specified should be that described in Rahu Dhesi's posting to comp.mail.misc in 1996, [EMAIL PROTECTED]. * If an mbox file contains messages with unencoded binary data, the file is difficult to sensibly process on a machine with non-UN*X line-endings, because of the bare CRs in the binary data. (Bare LFs are fine and look just like line endings, with From_-escaping and all.) As far as I can tell there is then no non-lossy representation of the file which allows sensible local processing by non-mbox-specific tools. This issue should be resolved (or at least acknowledged). Ian. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
The IESG writes ("Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to
Informational"):
The IESG has received a request to consider Registry Registrar Protocol
(RRP) Version 1.1.0 draft-hollenbeck-rrp-00.txt as an Informational
RFC. This has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
[EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by January 13, 2000.
I can see at least the following problems with this protocol, in
addition to those described in it:
* The TRANSFER command, when used to approve a transfer, does not
specify to which registrar the domain is to be transferred. The
document says that the details of transfer arrangements should be
handled out-of-band by eg electronic mail. However, that would not
prevent a domain mistakenly or maliciously being transferred to the
wrong new registrar. It is essential that this deficiency in the
protocol is corrected or worked around forthwith, as currently a
malicious registrar who is able to manipulate unsecured out-of-band
email may be able to cause the domain to be transferred to themselves
instead of to the intended recipient registrar.
A workaround would be for the intended recipient to send (via another
protocol) to the donor an authenticated confirmation to the that it
had successfully lodged the transfer request, so that if the donor is
willing to transfer to that registrar it can safely approve the
transfer. However, the technical integrity of this scheme depends on
the registry never unexpectedly losing or timing out transfer
requests, and on donors to keep a record of all recent transfer
requests to ensure that the right request is accepted; the sociolegal
integrity of such a workaround may depend on extremely complicated
contractual issues, which is not my field of expertise. In any case
this caveat should be addressed in any Information RFC.
* The use of passwords for identifying registrars rather than the
certificate information corresponding to the SSL session is very
unwise. The secret(s) which identify a registrar should never leave
that registrar. For example, a security compromise at the registry
would require all the registrars' passwords to be changed, and
redistributed via secure out-of-band channels. Furthermore, the use
of passwords makes it impossible to use secure hardware to store the
critical key material. This misfeature should be fixed in future
versions and implementations.
* The use of registry local time in time stamps is absurd (and will
likely lead to daylight saving change bugs etc.). The time used
should be in UTC, or preferably elapsed civil time measured as the
number of non-leap seconds since a suitable epoch. This misfeature
should be fixed in a future protocol version.
* The use of SSL, rather than individually authenticating requests and
responses (or batches of them), means that there is no audit trail,
verifiable by a third party, for resolving disputes. This bug should
be fixed in a future protocol version.
I think that any Informational RFC describing this protocol should at
the very least mention these deficiencies as well as those it already
lists.
Ian.
