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

Call for Votes (getaddrinfo)


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.


 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.


 -=-=-=-=-=- 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:


 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

 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

 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.


 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.


 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

 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

 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.


Version: 2.6.3ia
Charset: noconv


Reply to: