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 [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
signature.asc
Description: Digital signature
