Anthony Towns writes ("getaddrinfo() behaviour"):
> So here's my understanding of where we're at.Thanks. > First, fact finding. Everything here should be able to be agreed by > everyone. I'm afraid I don't agree with all of the things you claim as facts, and I don't agree with the analytical approach you're using anyway. But we've been over and over this and me repeating myself isn't going to help. So I'll skip straight to the meat. One thing you have pointed out is that we hadn't finished discussing whether or not etch should be fixed. > Conversely, if we don't consider this an RC issue, changing it for etch > doesn't seem appropriate, and at that point I don't see why we'd change > it for sid either (at least absent an update via the IETF standards track > process). I'd be interested to see explanations of why this should be > considered RC. I think that it should be changed in etch. If we change it in etch it will make our ftp admins' lives a lot easier, if nothing else, because they'll go back to being able to publish DNS round robin. There are no anticipated downsides to changing it in etch except of course the usual risk of a libc update. Ubuntu have backported the gai.conf configuration option to their libc without difficulty, although not in an update to an already released distribution. I can see that the stable release managers might have another view. We haven't really heard from them properly. My current feeling therefore is that we should overrule the libc maintainer to essentially propose this ourselves as an update for stable, which we would recommend but not insist that the stable RM should accept. Since I did the backport for Ubuntu I'm probably the right person to prepare the update for etch (not that it's very hard). > If so, conclusions that could potentially be drawn: > > (a) Using prefix matching to select IPv4 addresses isn't useful > (b) Using prefix matching to select IPv4 addresses is harmful > (c) Using prefix matching to select IPv4 addresses is harmful enough to > be an RC issue for Debian ... > If so, declaring this to be an RC issue justifies both an update to > etch and (if necessary, which I don't expect) an NMU for sid/lenny, > which seems all that's needed. I don't see why RCness is relevant for updating sid. Surely the TC should ensure that its decisions are implemented even if we consider the issue non-RC ? > I'm not sure if any or all of (d)-(f) would be sufficient recommendations > to close the issue for IPv6 as well, or if there's something else that > would make sense. I think we should avoid getting too bogged down with IPv6. We can safely leave that to the IETF to reconsider since we're evidently not going to overrule the libc maintainer on that point. Hence my wording that we think rule 6 shouldn't apply to IPv6 and we recommend the IETF "probably" abolish it. Ie, they should think about it with the more information and expertise available to them. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
