In message <5648A8908CCB564EBF46E2BC904A75B19681060D46@EXVPMBX100-1.exc.icann.org>, at 09:48:58 on Thu, 21 Nov 2013, Leo Vegoda <leo.vegoda@icann.org> writes
At the end of June 2002, ripe-246 documented the policy that had been developed based on the experience gained through ripe-196. As you note, it did not cater to IXPs but that problem was solved about later, with the publication ripe-256 in early August, which documented "IPv6 Address Space Policy for Internet Exchange Points."
I remember this being an issue at RIPE meetings in 2000.
I expect it was, although don't remember specific discussions. The bootstrap policy was always intended as a short term experiment to find out what was needed in the longer term. Not discussing IXPs' needs would have been odd.
They were discussed, but getting acceptance of the concept that IXPs are neutral, with the idea of a single "upstream" not really applying, was a struggle. We at the IXPs could see it, obviously.
But aside from the fog over the timescale, can you give us a quick run-down of the relevance to this issue of "running code"? After all, the purpose of this list (and the WG) is to foster co-operation and capacity building with other stakeholder groups not familiar with IETF (and other technical) jargon.
As I see it, running code is a synonym for "things that work" and developing things that work generally requires prototyping, testing and revision. I think this is a good example of a process that tested a policy, found where it needed to be improved for the general case (ISP use) and also came up with other policies that supported edge cases, like IXPs and root DNS servers (ripe-223).
"Things that work" is a good alternative description, because it doesn't quite so much imply you have to make a physical working prototype (which several people I've spoken to assume is the case) to test the concept - debating it in the abstract is good enough. -- Roland Perry