In message
<5648a8908ccb564ebf46e2bc904a75b19681060...@exvpmbx100-1.exc.icann.org>,
at 09:48:58 on Thu, 21 Nov 2013, Leo Vegoda <[email protected]>
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
