This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/cooperation-wg@ripe.net/
[cooperation-wg] Internet governance
- Previous message (by thread): [cooperation-wg] Internet governance
- Next message (by thread): [cooperation-wg] Internet governance
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Roland Perry
roland at internetpolicyagency.com
Fri Nov 22 17:18:18 CET 2013
In message <5648A8908CCB564EBF46E2BC904A75B19681060D46 at EXVPMBX100-1.exc.icann.org>, at 09:48:58 on Thu, 21 Nov 2013, Leo Vegoda <leo.vegoda at 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
- Previous message (by thread): [cooperation-wg] Internet governance
- Next message (by thread): [cooperation-wg] Internet governance
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]