Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
* Ian Jackson (ian@davenant.greenend.org.uk) [070928 19:23]:
> Pierre Habouzit writes ("Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch"):
> > On Fri, Sep 28, 2007 at 03:56:31PM +0000, Ian Jackson wrote:
> > > I don't know if you've been following the argument on the TC list
> > > about bug #438179. I think the Technical Committee are probably going
> > > to rule that sid's glibc ought to be changed so that it does not
> > > implement RFC3484 section 6 rule 9 prefix-length based sorting for
> > > IPv4. This will restore the traditional DNS round robin.
> >
> > FWIW I still believe that someone in the thread had a point and that
> > getaddrinfo should use an extension being e.g. AI_UNSORTED and that the
> > issue should be raised to the IETF.
>
> An extension along these lines is no good because the purpose is to
> make applications which are updated (usually by upstream) to use IPv6
> to continue to behave the same way they used to when they do IPv4.
> Saying that we should offer an extension to getaddrinfo to have the
> correct behaviour amounts to saying that all callers of getaddrinfo in
> Debian should be changed.
How about doing it the other way - adding an AI_SORTED to the function?
> > This argument is pure crap and prevent anyone interested to post to
> > the TC list. This has pissed me beyond repair on this problem, and I
> > believe I wasn't the only one. IMHO, the TC isn't functional with a
> > restricted mailing list. debian-release is not under the same
> > censorship, and looks though pretty functional to me.
>
> I'm sorry you don't like the way we run our mailing list but that is a
> matter for us.
This becomes off-topic in this thread, but perhaps as time passes by,
there might be another good setup of the mailing list - perhaps let's
have some input from the list masters on it.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
Reply to: