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

Re: Call for Votes (was Re: glibc's getaddrinfo() sort order)

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

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?


>  -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 would prefer to make a connection to
> rather than to
>  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.
> Version: 2.6.3ia
> Charset: noconv
> 35ORgS3/Bf9QPvzJVzNBnmnMPjhtcodEpTMVpn8dmSone7h5BpB9zd5PNV+kkhlY
> iXQKgg4oLsEpODyJ6txFjpkMTxI4JO4+lhQoTzIyVLW2nntrY3dvZm5VBx3I0FS+
> Ik6SXp+F1Ao=
> =QqKO
> -- 
> 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

Reply to: