On Thu, Nov 15, 2007 at 07:16:17PM +0000, Ian Jackson wrote: > > (I'm resending this lost mail from the 8th of November, intending to > restart the 7-day clock:) It seems the 7 day clock has stopped again a few days ago. We actually saw a total of 1 votes for this ballot, and 2 for one with an additional option. We seem to have: X S M F Ian 1 3 X 2 aj - - 1 2 Manoj 1 3 3 2 As far as I know, we have a quorum of 2. Option X seems to reach quorum with 2 >= 2. Option S and M don't reach quorum. Option X has a majority ratio of 2:1, which is smaller than the required 3:1. I think either way you look at it, we ended up with option F "Further discussion" > It seems that discussion on this has dried up. Although my very > similar proposal was defeated the first time, I think it probably by > now falls to me by default to propose a new version. So: I just wonder why so few people seem to have voted. Is there still a problem with the lists? Kurt > -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<- > > For the sake of clarity, we should at least have the libc maintainer's > position on the ballot, so I propose and call for a vote. > > -=-=-=-=-=- 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 F: Further discussion > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > I've left off `do not use rule 9, do not overrule maintainer' as a > choice as no-one seemed to be arguing for it. > > -8<- > > Here is my vote and my opinion: > > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > [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 > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > 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. > > > Ian. > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: noconv > > iQCVAwUBRzya/cMWjroj9a3bAQENxwQAgYG83KvPXS32JHWWoZLqafLIOHqDAnQa > 35ORgS3/Bf9QPvzJVzNBnmnMPjhtcodEpTMVpn8dmSone7h5BpB9zd5PNV+kkhlY > iXQKgg4oLsEpODyJ6txFjpkMTxI4JO4+lhQoTzIyVLW2nntrY3dvZm5VBx3I0FS+ > Ik6SXp+F1Ao= > =QqKO > -----END PGP SIGNATURE----- > > > -- > To UNSUBSCRIBE, email to debian-ctte-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org >
Attachment:
signature.asc
Description: Digital signature