Re: IESG review of draft-hubbard-registry-guidelines-03.txt

Brian Carpenter CERN-CN <brian@dxcoms.cern.ch> Wed, 07 August 1996 08:36 UTC

Received: from ietf.org by ietf.org id aa08317; 7 Aug 96 4:36 EDT
Received: from cnri by ietf.org id aa08313; 7 Aug 96 4:36 EDT
Received: from nico.aarnet.edu.au by CNRI.Reston.VA.US id aa03911; 7 Aug 96 4:36 EDT
Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id RAA03819 for <cidrd@iepg.org>; Wed, 7 Aug 1996 17:48:25 +1000
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA21005; Wed, 7 Aug 1996 09:47:35 +0200 (MET DST)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA17779; Wed, 7 Aug 1996 09:47:29 +0200
Message-Id: <9608070747.AA17779@dxcoms.cern.ch>
Subject: Re: IESG review of draft-hubbard-registry-guidelines-03.txt
To: Daniel Karrenberg <Daniel.Karrenberg@ripe.net>
Date: Wed, 07 Aug 1996 09:47:29 +0200
Sender: ietf-archive-request@ietf.org
From: Brian Carpenter CERN-CN <brian@dxcoms.cern.ch>
Cc: tli@jnx.com, kwe@6sigmanets.com, cidrd@iepg.org, piara@apnic.net
In-Reply-To: <199608070714.HAA10033@kantoor.ripe.net> from "Daniel Karrenberg" at Aug 7, 96 09:14:01 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

>   > Creating a market which encompasses _both_ addressing and routing 
>   > must be the true goal of PIARA.  
> 
> Yes!  Yes!  Yes!  I imagine it could be two seperately developing but
> *compatible* markets though. Now am I nitpicking? Maybe.
> 
>   > Unfortunately NO
>   > ONE (and I most emphatically include myself) has a good clue of how to do
>   > this.
> 
> Unfortunately very true.  Conceptually there are *two* hard problems:
> finding market models that work *and* developing the current mechanisms
> into them.  All this needs to be done in real time on a moving target,

To quote myself (draft-carpenter-metrics-00.txt)

   3.4. Number of announced routes (number)

   Applicable: at inter-ISP peering points; at connection of subscribers
   with more than one subnet.

   Measured by: analysis of routing tables.


The question is, how can ISPs be persuaded to put something
like this into their pricing structure? What would happen if
one major ISP did this before the others? It's very hard to see
how this can be run as an experiment; like route filters,
or flap damping, it can only be for real.

  Brian