Just FYI -- notes from RIR discussion

[Leslie Daigle <leslie@thinkingcat.com>]

Howdy,

Harald and I had the opportunity to sit down with some
of the RIR heads this morning at RIPE in Amsterdam.
I wrote down some "aide-memoire"-type notes, below.
These are really informal, not particularly vetted with
the other participants in the room (except Harald) etc etc,
so please do not recirculate.  If there are things
that seem not-quite-right, please ask -- I may simply
have captured them wrong.

There, with caveat almost as long as the notes themselves,
and promises of more specific follow up for any 
action items...

IETF/IAB/RIR Liaison meeting
Amsterdam, Netherlands
January 28, 2003
----------------------------

Hartmut Glaser -- LACNIC board member
Ray Plzak -- ARIN
Axel Pawlik -- RIPE
Paul Wilson -- APNIC (on phone for parts)
Harald Alvestrand -- IETF Chair
Leslie Daigle -- IAB Chair
Anne Lord -- APNIC


We agree that these meetings should be held on an
as-needed, ad hoc basis, typically at RIR or IETF
meetings.

Leslie will set up mailing list.

First issue -- Ray raises the problem with RFC3138 (extended
assignments in 233/8.  It is an informational RFC with no
IANA considerations.  The issue is that it says "allocations
to be made by RIRs", but they don't feel they were consulted
(published in June 2001).   RIRs may have to take it to their
membership (though Ray isn't yet convinced this is something
they need to take to membership).  At any rate, if they are
to do it, they need an IANA considerations to clarify
the process -- allocating one piece to each RIR, RIRs 
performing a joint management function of the whole space,
etc.

Harald asks how they handle global assignments (assignments
that are not obviously tied to a region).  Answer:  they act together (a
process is established per assignment).


Experimental allocations

Cited examples of experiments -- the 6bone experiment; 39/8 subnetting 
experiment (RFC 1797). Policy originated in APNIC region, passed in APNIC 
and RIPE without RIRs observing controversy, and only
hit the fan when it came up on ARIN.  RIRs assert they don't understand
why the pushback.

Leslie raises the issue that there are experiments getting
technical pushback within the IETF, but it would be a problem
if they simultaneously asked for and received experimental
allocations.

Harald -- we need to document the kinds of concerns we have;
that there are certain types of experiments that would
have global impact (e.g., Teredo/shipworm).

Ray -- if the IETF thinks this (registries being allowed to
allocate space for the purpose of conducting experiments)
is not a good idea, it should document that concern and get it into an
open forum (e.g., PPML).  Harald takes a step back:  should there be
*any* route to get allocation for experiments?  (The fact that 
this is currently doable via IETF experimental & IANA route) is an 
implementation detail.

One of the implicit questions -- should IANA be doing *any*
direct allocations?  Ray expresses some of the concerns that
RIRs have over the fact that the IANA is currently doing some
(e.g., for experimental, but also for ICANN) -- that they
assign addresses without having to have policy in place.
The RIRs do everything with policy and policy checks (e.g.,
open-discussion about policies, controls, management, policies
for termination).

Leslie will go back to the IAB with a more detailed description
of what this is all about.  IAB can't decide what to do on
its own -- this is starting to smell like something that has
the scope of something that would need to be an I-D and
eventual RFC.  We may need to define a process for evaluating
the technical merits of a proposed experiment in terms of
impact on the Internet infrastructure (not the experiment itself).

Ray will put a stop to ARIN discussion -- pending IAB input.
Anne Lord, for APNIC, says that they will forward any received requests
to this liaison group so that we can figure out who should vet the
experiment (this is in line with
their current policy).


Final issue... what happens to multicast space in the case
of a catastrophic failure of IANA (ICANN).  In the case of
the catastrophic failure of a Registry, they have plans in
place (they each escrow the others' sensitive data, do
staff exchanges) and their assertion is that the other RIRs
would take over the function (i.e., not revert to IANA/ICANN).

Harald points out that the IETF IANA document defines the
function in terms of "the universe of things, except unicast
IP addresses" -- i.e., multicast addresses could live there.
The IETF would probably want the RIRs to pick it up if IANA
ICANN failed, but we're not yet at a point to be able to assert
that.

Action for the IAB -- finish documenting the IETF IANA function,
and once we get that agreement, work on escrow agreements
for all the data.  As we work out that, we might work out agreements
with the RIRs for them to take on management of the multicast
space in that case. 

--

-------------------------------------------------------------------
"An essential element of a successful journey
   is recognizing when you have arrived."
  -- ThinkingCat  (c.1983 - 2002)

Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------