-----BEGIN PGP SIGNED MESSAGE----- This time can we _please_ try to get quorum ? You must send in your vote within 7 days of me sending this message, for it to count, ie by approximately 2007-12-06 19:50 +0000.
-8<- 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we DO overrule the maintainer. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. We do NOT overrule the maintainer. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished for IPv4, and that it should be reconsidered for IPv6. -8<- -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [ ] Choice M: Leave the choice up to the maintainers. [ ] Choice F: Further discussion -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- For clarity, with the above I do the following formal acts: * Propose the resolution you see between -8<- marks (represented in the ballot as choice X) * Propose but do not accept two separate amendments for ballot choices S and M each of which deletes the text of the resolution and replaces it with the corresponding summary line. * Call for a vote. I hereby also vote as follows: [1] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [2] Choice F: Further discussion [3] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [4] Choice M: Leave the choice up to the maintainers. My rationale: Introduction 1. We have been asked to rule on the application of RFC3484 section 6 rule 9 by the resolver in glibc. 2. Rule 9 requires a host to sort addresses according to the length of the initial prefix common with the host's own address, when deciding which of a peer's addresses to try in which order. Thus eg, a host 172.18.45.11 would prefer to make a connection to 172.18.45.6 rather than to 172.31.80.8. 3. This has been implemented in glibc upstream by having the DNS resolver sort addresses before passing them to the application via getaddrinfo. Background and history 4. Prior to the publication and implementation of RFC3484, and prior to the introduction of getaddrinfo, most hosts would use an implementation of gethostbyname to find IPv4 addresses to use for a peer, given its hostname. gethostbyname has almost universally returned the addresses in the order supplied by whatever DNS nameserver it was using. 5. In 1993, the then-ubiquitous nameserver implementation BIND was modified to implement a feature known as `DNS Round Robin'. This does not need to be explained in detail, but the intended and actual effect was that clients would be provided addresses (and other records) in a deliberately varying order, so that in the aggregate clients' choice of address to use would be distributed uniformly across the published addresses. 6. Between then and the recent implementation of rule 9 by some hosts, DNS round robin became universally deployed. It has been implemented by other nameservers and has become a de facto standard at least for the interpretation of multiple IPv4 addresses in the global DNS. IPv6 transition 7. The primary use of getaddrinfo is to replace gethostbyname when an application is converted to support IPv6. gethostbyname cannot be sensibly used to support IPv6; while there are other interfaces that can be used instead, the routine practice has been to make certain very consistent sets of changes to applications, which include replacing the use of gethostbyname by getaddrinfo. 8. gethostbyname in current glibc does not implement rule 9. The effect therefore is that whether a particular host follows rule 9 for a particular protocol depends mainly on whether that particular version of the application in question has been updated in the host's operating system to support IPv6. (As well as, of course, whether the operating system's getaddrinfo uses rule 9.) 9. There are no known applications which specifically desire the rule 9 behaviour; we know of no case where an application uses getaddrinfo specifically to get rule 9. 10. There is therefore no rational reason for the difference between the behaviour of gethostbyname and getaddrinfo, other than perhaps implementation convenience. Compatibility and benefits 11. Rule 9 is incompatible with the DNS Round Robin. Prior to rule 9, a system administrator would publish multiple addresses in the intent and expectation of getting roughly equal client load on each address. 12. When Debian's apt changed its behaviour to follow rule 9, it broke ftp.us.debian.org because the load suddenly became very unbalanced. Thus this incompatibility causes actual operational problems. 13. We know of no situations where multiple IPv4 addresses on the global Internet are published with the intent and expectation that rule 9 will be followed by client systems. 14. The nature of the IPv4 address space structure suggests that rule 9 is not in practice useful for IPv4 on the global Internet. History and status of RFC3484 15. RFC3484 and rule 9 forms part of a document set published as part of early IPv6 work. 16. At the time of publication of RFC3484, the intended IPv6 addressing architecture had a significantly different shape. 3484 and rule 9 appear to form part of a set of behaviours which go alongside rapid renumbering, which has now fallen out of favour. 17. There is no evidence that the authors of RFC3484, which is specifically headed as an IPv6 document, considered specifically the behaviour for IPv4 or realised that the specification conflicted with the widely-used DNS Round Robin. 18. RFC3484 was a product of IPv6 (ie networking) working groups, not DNS working groups. Standards 18. The purpose of standards is interoperability. Where following a standard makes us less interoperable we should not follow the standard. Debian is entitled to deviate from standards, including published documents, if we consider it appropriate to do so. 19. We should of course consider carefully before going against a published document. However, when the situation is clear, we should not be overly reluctant to do so. In cases where de jure and de facto standards disagree, we must make a judgement which we prefer based on all of the circumstances. 20. In any case RFC3484 is currently `Proposed Standard', which is the earliest and least mature form of standards track document, which can be expected to have rough edges. Conclusions 21. Rule 9 is not the standard behaviour for IPv4, RFC3484 notwithstanding. Round Robin is the de facto standard behaviour (despite not having been officially standardised), and there can be little justification for making such a radical change at this stage. 22. RFC3484 is therefore in error when it applies rule 9 to IPv4. Not using rule 9 for IPv4 is unquestionably preferable. 23. It appears that RFC3484 is also unhelpful for IPv6. However, since there is no existing de-facto standard for IPv6, this conclusion is arguable. 24. Therefore I would insist on traditional DNS Round Robin, rather than rule 9, for IPv4; but I would only recommend against rule 9 in the case of IPv6. 25. It is clear that the IETF needs to revisit this issue and I would formally recommend to them that they do so. Backporting to current stable 26. In my opinion this change should be backported to current stable. However, this decision does not need to be taken now. We can wait for experience with the change in unstable and testing, which will help convince doubters that there is no compatibility problem. 27. I encourage the submitter and other interested parties to pursue getting this changed in a stable update, and to bring the matter back to the Technical Committee if necessary to achieve this. Responsibility of the Technical Committee to decide 28. One committee member has insisted on the presence of `leave the choice up to the maintainer' on the ballot (option M). My understanding of the meaning of this wording is that if that option wins we refuse to make a decision on the matter and also refuse to deal with it any more. Ie, this option is equivalent to Further Discussion except that the committee will not discuss or vote any more but instead considers the matter closed. 29. I do not consider it appropriate for the committee to decline to issue a ruling. Once a matter has reached us it is for us to make a decision and we should not abdicate that responsibility. If the committee disagrees with the maintainer, but not sufficiently overwhelmingly so as to be able to overrule the maintainer, we should nevertheless issue a ruling clearly stating that we disagree. In this particular case the committee does seem to have a sufficient majority to overrule, if we can only get the mechanics of voting working properly. 30. It has also been suggested that we should not overrule the maintainer unless we consider the bug release-critical. This is an abdication of the responsibility of the committee. In particular, whether or not to overrule the maintainer should depend primarily on how _clear_ it is that the maintainer is wrong, rather than on how _serious_ the consequences are. The constitution's supermajority condition gives effect to the requirement for high confidence in a decision to overrule, and of course individual committee members will want to be sure of their ground in such a case. 31. Therefore I reject the suggestions that we should not decide the matter, or that we should not overrule without concluding that the problem is release-critical. Ian. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBR08YRMMWjroj9a3bAQHTYQP8Dr1sO32ZVHanP33C+CUDfpEqMvtKSC+z pEEQ9glm9UmUNUoQzyaMztst1RDfZtihsLyepKIwbw/OV8Jl1gti5+aLbQe7IqwT 7wtGFHmejeBiI7KUNjjVUrsf/cuvog8FVetZXiNq6c9TGspBms/AUJ/G0vNzFw5c smw/X2zfAwM= =T/Pb -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]