Registry - not a policy proposal
[apologies for duplicate mails] Dear RIPE, soon there will be no more IPv4. However, we still have a registry of these addresses. Daniel Karrenberg and myself have produced a document (attached to this mail) which describes what we think the role of this registry should be after the runout of the unallocated IPv4 address space. We will present this document in the Address Policy WG, and would like to invite you to let us know your thoughts. The place for further discussion will be <address-policy-wg@ripe.net>. Thank you for your attention, Rob Blokzijl
On Wednesday 05 May 2010 at 11:15:36 Rob Blokzijl sent:
[apologies for duplicate mails]
Dear RIPE,
soon there will be no more IPv4. However, we still have a registry of these addresses.
Perhaps you mean "no more unallocated IPv4 addresses".
Daniel Karrenberg and myself have produced a document (attached to this mail) which describes what we think the role of this registry should be after the runout of the unallocated IPv4 address space.
We will present this document in the Address Policy WG, and would like to invite you to let us know your thoughts. The place for further discussion will be <address-policy-wg@ripe.net>.
Thank you for your attention,
Rob Blokzijl
On Wed, May 05, 2010 at 01:02:31PM +0300, Toni Stoev wrote:
On Wednesday 05 May 2010 at 11:15:36 Rob Blokzijl sent:
[apologies for duplicate mails]
Dear RIPE,
soon there will be no more IPv4. However, we still have a registry of these addresses.
Perhaps you mean "no more unallocated IPv4 addresses".
actualy, its all been allocated and has been for years its just likely that some of the pool holders may be dorment for a while (the IANA, the RIRs)
Daniel Karrenberg and myself have produced a document (attached to this mail) which describes what we think the role of this registry should be after the runout of the unallocated IPv4 address space.
We will present this document in the Address Policy WG, and would like to invite you to let us know your thoughts. The place for further discussion will be <address-policy-wg@ripe.net>.
Thank you for your attention,
Rob Blokzijl
Hi RIPE, In this proposal, to ensure the correct timing of this implementation, perhaps the following change on para. 1, from: On application for IPv4 resources when the RIPE NCC is holding the equivalent of a /8 or less of IPv4 address space, LIRs will receive IPv4 addresses according to the following: etc. to On application for IPv4 resources when the RIPE NCC is holding the equivalent of a /8 or less of IPv4 address space and the IANA free pool contains no available /8 blocks, LIRs will receive IPv4 addresses according to the following: Since the trigger conditions are stated only in the preamble and not the text itself. The conditions in the statement imply that if RIPE receives or retrieves addresses that bring its store back over 2^24, the allocation method reverts to "status quo". I think this is probably a good thing as you never know if the pool is suddenly revived again! Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood@imerja.com -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated.
Rob Blokzijl wrote: Just a couple of comments.... Ref. Section 5, "comprehensive":
From a "consumer's" point of view, the RIPE NCC Address Registry should return a valid answer about the status of *all* addresses in the IPv4 space.
The answer will necessarily be different, depending on the status of the address block and the authority regarding the answer. For those addresses, which are authoritatively managed by other RIRs, there should be an indication where to find "better" information. We are already pretty far down that path :-) Ref. Section 5, "correct": I think we shoukd find a better term than "actual use" :-) The registry imho is not in a position to rate or document the use of the address space, just the authorized holdership. This also relates to the Disincentives listed. Ref. Section 6, "Disincentives / cost": Proposal: "The cost should not be excessive|unreasonable in relation to the benefits for the Internet community." My reasoning here is that we cannot compare cost against (perceived) benefit and that the individual perception may be pretty extreme when it comes to payments :-) Thanks to the authors for taking the lead! Wilfried.
On Jun 1, 2010, at 2:57 AM, Wilfried Woeber, UniVie/ACOnet wrote: […]
Ref. Section 5, "comprehensive":
From a "consumer's" point of view, the RIPE NCC Address Registry should return a valid answer about the status of *all* addresses in the IPv4 space.
The answer will necessarily be different, depending on the status of the address block and the authority regarding the answer.
For those addresses, which are authoritatively managed by other RIRs, there should be an indication where to find "better" information. We are already pretty far down that path :-)
The 'user friendly' thing to do is probably to go and find them the end answer, rather than referring them to somewhere else to look up the answer. This is probably particularly important when the query is made by a piece of software that is not aware that it needs to follow a referral. Regards, Leo Vegoda
On Tue, Jun 01, 2010 at 08:43:49AM -0700, Leo Vegoda wrote:
Ref. Section 5, "comprehensive":
From a "consumer's" point of view, the RIPE NCC Address Registry should return a valid answer about the status of *all* addresses in the IPv4 space.
The answer will necessarily be different, depending on the status of the address block and the authority regarding the answer.
For those addresses, which are authoritatively managed by other RIRs, there should be an indication where to find "better" information. We are already pretty far down that path :-)
The 'user friendly' thing to do is probably to go and find them the end answer, rather than referring them to somewhere else to look up the answer. This is probably particularly important when the query is made by a piece of software that is not aware that it needs to follow a referral.
I believe that this is not always the best solution. Although this is generally good idea when user is querying registry using some API with well-defined output, I can imagine that simple redirection of text-based whois output from other registry can confuse the querying software. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Piotr Strzyzewski wrote:
On Tue, Jun 01, 2010 at 08:43:49AM -0700, Leo Vegoda wrote:
Ref. Section 5, "comprehensive":
From a "consumer's" point of view, the RIPE NCC Address Registry should return a valid answer about the status of *all* addresses in the IPv4 space.
The answer will necessarily be different, depending on the status of the address block and the authority regarding the answer.
For those addresses, which are authoritatively managed by other RIRs, there should be an indication where to find "better" information. We are already pretty far down that path :-)
The 'user friendly' thing to do is probably to go and find them the end answer, rather than referring them to somewhere else to look up the answer. This is probably particularly important when the query is made by a piece of software that is not aware that it needs to follow a referral.
I believe that this is not always the best solution. Although this is generally good idea when user is querying registry using some API with well-defined output, I can imagine that simple redirection of text-based whois output from other registry can confuse the querying software.
Well, redirection is one possible appraoch, actually an approach I do not really like ;-) Another possibility would be to have the targetted whois server do the legwork on behalf of the user. Then "just" give back the (correct(def.?)) answer. I presume this would require a considerable effort on the side of the RIRs (and NIRs, potentially using a different character set) and a much better understanding ref. the (compatible) format (and the components) of the result.
Piotr
$ set (dreaming mode=OFF), Wilfried
The 'user friendly' thing to do is probably to go and find them the end answer, rather than referring them to somewhere else to look up the answer.
Yes.
I believe that this is not always the best solution. Although this is generally good idea when user is querying registry using some API with well-defined output, I can imagine that simple redirection of text- based whois output from other registry can confuse the querying software.
This is why RIPE and the other 4 RIRs should get together and replace the obsolete and inadequate text whois protocol. ARIN has already moved away from text whois with a RESTful protocol that outputs the whois directory info in an XML format. If all RIRs would support the same protocol, then referral could be done seamlessly. Even if the inquiry comes in on the obsolete text whois protocol, the RIR will be able to decode "foreign" whois lookups the same way as they decode "local" ones. --Michael Dillon
Michael, On Wed, 2010-06-02 at 15:07 +0100, michael.dillon@bt.com wrote:
I believe that this is not always the best solution. Although this is generally good idea when user is querying registry using some API with well-defined output, I can imagine that simple redirection of text- based whois output from other registry can confuse the querying software.
This is why RIPE and the other 4 RIRs should get together and replace the obsolete and inadequate text whois protocol. ARIN has already moved away from text whois with a RESTful protocol that outputs the whois directory info in an XML format.
If all RIRs would support the same protocol, then referral could be done seamlessly. Even if the inquiry comes in on the obsolete text whois protocol, the RIR will be able to decode "foreign" whois lookups the same way as they decode "local" ones.
This protocol already exists. The RIPE NCC even ran a test server for a while: http://www.ripe.net/db/iris-pilot/ Some of the information links are broken, and the server doesn't appear to be up any more. The best place to look is probably the IETF CRISP working group RFCs: http://datatracker.ietf.org/wg/crisp/ The "requirements" document gives some useful background: http://datatracker.ietf.org/doc/rfc3707/ Full disclosure: I worked at both ARIN and the RIPE NCC during the times when a WHOIS replacement was envisioned and developed. The effort to implement IRIS was largely unsuccessful, but not because of missing technology IMHO. It was largely because nobody cares. The problems it solves are real, but they are not any organization's primary concerns. For my part, I'd be more than happy to help re-vamp the attempt to replace WHOIS, but I'm not sure it would do much good. -- Shane
On Jun 2, 2010, at 11:19 PM, Shane Kerr wrote:
This protocol already exists.
Actually, multiple whois replacement protocols exist and more are coming, albeit outside of the IETF context (e.g., multiple incompatible (as I understand it) RESTful Whois implementations).
The best place to look is probably the IETF CRISP working group RFCs:
Or Whois++ (RFC 1835) or Rwhois (RFC 2167). And we shouldn't forget (like some people can't forget the taste of Tequila after overindulging) X.500 and LDAP.
The effort to implement IRIS was largely unsuccessful,
"largely"?
but not because of missing technology IMHO. It was largely because nobody cares. The problems it solves are real, but they are not any organization's primary concerns.
Right. No one knows how to make money by standardizing on how to query and display registration data and the amount of money saved by a standardized system has (to date) been insufficient to drive enough interest to fix the myriad issues with the existing whois system. As a result, folks implement whatever they feel will solve their specific problem rather than looking to solve the more generic problem, with the end result being the need for clients to know who they are querying in order to send the appropriate query and parse the resulting output. Sub-optimal, but not surprising. Regards, -drc [Speaking personally and representing no one but myself. Really.]
participants (10)
-
bmanning＠vacation.karoshi.com -
David Conrad -
Jamie Stallwood -
Leo Vegoda -
michael.dillon＠bt.com -
Piotr Strzyzewski -
Rob Blokzijl -
Shane Kerr -
Toni Stoev -
Wilfried Woeber, UniVie/ACOnet