Subject: RE: draft-ietf-ipv6-ula-central-02

From: "Azinger, Marla" <[email-masked]>
Date: Mon, 18 Jun 2007 18:29:57 -0400

Michael-  I dont believe that was the intent and there might be a little misinterpretation here due to how it was written.  The document says:

>The designated allocation authority is required to document how they
   will meet the requirements described in Section 3.2 of this document
   in an RFC.<

This states the RIR's need to document how they will meet the requirements once section 3.2.  It dont believe the author intends for RIR's to write an RFC.  I believe the intent of the sentence you question is actually saying in a round about way that RIR's need to use their policy process and write policy's that will meet the requirements stated in section 3.2 of the draft.  Thus, synchronizing the RFC and RIR policy.

Or at least that is what I had discussed on a conference call with R. Hinden and T. Narten before the revision was made.  So Bob or Thomas, correct me if I am wrong here...

Cheers!
Marla

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 18, 2007 2:40 PM
To: [email-masked]
Subject: draft-ietf-ipv6-ula-central-02

In this draft it has some requirements for generating ULA-C prefixes and
then in 7.0 it requires the RIRs to publish an RFC documenting how they
will implement these requirements.

I think it would be better not to require the RIRs to also go through
the RFC process after a ULA-C RFC has been issued, if it ever gets to
that point. One possible solution is to downgrade this to simply require
the RIRs to publish an RIR document explaining how they implement
section 3.2.

But a better way is for the ULA-C document to include this. I note that
any algorithm for checking (and registering) a generated prefix in the 5
RIR databases could easily be done in advance so that each RIR keeps a
supply of unique ULA-C prefixes on hand based on their forecast rate of
requests for such addresses. That means that an applicant does not have
to wait for turnaround time of the uniqueness test. As far as protocols
for communication between the RIRs, this should also be specified in the
ULA-C document, however it should not develop any new protocols, merely
specify that something like XML-RPC or REST be used, and the semantics
of the transaction which should be atomic, i.e. test uniqueness and
register in one transaction. This transaction should provide some kind
of positive response so that there is no possibility of a false
positive. And since it will likely be most heavily used to register
batches of unique ULA-C prefixes, it should allow for a single
transaction to register the entire batch (or at least as many are
actually unique). Race conditions can occur here but it is not necessary
for a protocol or application to resolve these since this can be done by
some manual exception process. As long as conflicting prefixes (ones
which have not passed all 5 RIR checks) are removed from all the
databases regularly, that is sufficient.

-------------------------------------------------------
Michael Dillon
Capacity Management, 66 Prescot St., London, E1 8HG, UK
Mobile: +44 7900 823 672 
Internet: [email-masked]
Phone: +44 20 7650 9493 Fax: +44 20 7650 9030
http://www.btradianz.com
 
One Community One Connection One Focus 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2007 10:26:24 +0200

> Or at least that is what I had discussed on a conference call with R. Hinden and T. Narten before the revision was made.  So Bob or Thomas, correct me if I am wrong here...

Marla, if your interpretation is correct (and I hope it is)
the words "in an RFC" need to be deleted from the draft.

    Brian