Dear Colleagues, on the agenda for the Adress Policy WG next week is a presentation of a document titled "IPv4 Maintenance Policy", attached to this mail. This is a document that is slightly different from or usual type of policy documents: it is an attempt to consolidate those policies and practices that will still be relevant after the depletion of the IPv4 free pool. The aim is to have a consistent and complete collection of all things relevant to IPv4 for the years to come. Read, digest, enjoy - and discuss :-) Best regards, Rob Blokzijl
On 13 April 2012 12:33, Rob Blokzijl <k13@nikhef.nl> wrote:
The aim is to have a consistent and complete collection of all things relevant to IPv4 for the years to come.
Might it be an idea for this document to reference the polices that create each of the individual "elements" so that someone can use it as a reference to find the full wording of the policy that applies? J -- James Blessing 07989 039 476
On 13/04/2012 12:33, Rob Blokzijl wrote:
This is a document that is slightly different from or usual type of policy documents: it is an attempt to consolidate those policies and practices that will still be relevant after the depletion of the IPv4 free pool.
The aim is to have a consistent and complete collection of all things relevant to IPv4 for the years to come.
Rob, I think the idea of a policy summary document is good; I agree with James Blessing's suggestion that it might be better to institute it as a set of pointers to existing documentation rather than repeating text from other documents. Also it should be made clear that this is a summary rather than a statement of policy in itself, so that we do not end up with potential discrepancies due to multiple documents making statements on the same issues. I.e. we should strive towards policy atomicity. Nick
HI, On Sun, Apr 15, 2012 at 05:56:29PM +0100, Nick Hilliard wrote:
I think the idea of a policy summary document is good; I agree with James Blessing's suggestion that it might be better to institute it as a set of pointers to existing documentation rather than repeating text from other documents. Also it should be made clear that this is a summary rather than a statement of policy in itself, so that we do not end up with potential discrepancies due to multiple documents making statements on the same issues. I.e. we should strive towards policy atomicity.
As far as I understand, this document is to *replace* the existing IPv4 policy documents. Eventually, with a formal PDP, after the initial round(s) of discussion and improvement. So there wouldn't be anything else to point to. Looking forward to a lively discussion on Thursday :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 15 Apr 2012, at 22:09, Gert Doering wrote:
Looking forward to a lively discussion on Thursday :-)
Indeed! I expect to start the ball rolling on Wednesday, with a discussion of services for legacy resource holders. As I currently see things, legacy resources don't need address policy work, and so should be out of scope for APWG. Services for legacy resource holders do need attention and seem to me to fall naturally within the scope of the NCC Services WG. My slides have to be checked by my co-authors before I can place them on the meeting web site. I'll do this as soon as possible. /Niall
On 13/04/12 12:33, Rob Blokzijl wrote:
Dear Colleagues,
on the agenda for the Adress Policy WG next week is a presentation of a document titled "IPv4 Maintenance Policy", attached to this mail.
This is a document that is slightly different from or usual type of policy documents: it is an attempt to consolidate those policies and practices that will still be relevant after the depletion of the IPv4 free pool.
The aim is to have a consistent and complete collection of all things relevant to IPv4 for the years to come.
I have no comment one way or the other on such a document, however I do strongly feel that iff this becomes a formal policy proposal then Rob, as the final PDP appeal arbiter, should distance himself from it. Could I suggest a task force? Nigel
hi! On 04/13/2012 01:33 PM, Rob Blokzijl wrote:
This is a document that is slightly different from or usual type of policy documents: it is an attempt to consolidate those policies and practices that will still be relevant after the depletion of the IPv4 free pool.
The aim is to have a consistent and complete collection of all things relevant to IPv4 for the years to come.
Read, digest, enjoy - and discuss :-)
ok, some thoughts: - formal: actually not tied to 'after the depletion of the v4 free pool' at all. - the way it's currently worded, it reads like this aims at ultimately disposing ripe. can be done, ofc, but imho that's not really desirable... - no specific 'more equal than others' cases - that's fine. - whois db as lir db - that's fine. this again calls for a refer attribute for inet*num. from the discussions going on lately, it seems there's a strong need to define the nature of ip space, i'd suggest something like this: 2½ Number Resources The number resources subject to the coordination task by RIPE, namely IP-Address-Space and AS-Number-Space, are considered a commons: they cannot be owned, everybody has equal rights to them, their distribution has to be done fair and equally according to need. furthermore, i'd suggest to also handle IPv6 in the same single document (like, simply remove the "v4" part from every occurrence of "IPv4", except where really v4 specific). point 5 actually introduces a subtle change creating a special case, so i'd suggest to change the last sentence simply into something like: "Allocations are treated identically whether they are transferred or directly allocated." regarding point 8, i don't see any justification for bullet point 4 anymore. actually i think dropping point 8 completely would do, too - ymmv. there also seems to be an interest in formalizing rir ip allocation in the face of depletion. so i guess this should be dealt with in such a single policy document, too (see my recent mail regarding this subject on this list for details). regards, Chris
This aspect of the policy regarding legacy holders needs clarification: "Leave data as it is in the RIPE Registry. The Legacy Resource Holder will not be able to add to or alter their data and will not have access to any RIPE NCC services such as reverse delegation and certification." It is likely that in response to this policy legacy holders will choose to use an alternate registrar for the services you are precluding them from using (e.g., reverse delegation and certification). In that case RIPE NCC will need to negotiate an interoperability or interconnection agreement with these service alternate providers to ensure that a globally applicable unique registration occurs. If RIPE NCC is not willing to do that, it appears to be attempting to leverage its monopoly to force legacy holders into purchase and use of their services, something that raises obvious competition policy issues. I wouldn't advise you to do down that path.
-----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg- bounces@ripe.net] On Behalf Of Rob Blokzijl Sent: Friday, April 13, 2012 7:34 AM To: address-policy-wg@ripe.net Subject: [address-policy-wg] IPv4 Maintenance Policy
Dear Colleagues,
on the agenda for the Adress Policy WG next week is a presentation of a document titled "IPv4 Maintenance Policy", attached to this mail.
This is a document that is slightly different from or usual type of policy documents: it is an attempt to consolidate those policies and practices that will still be relevant after the depletion of the IPv4 free pool.
The aim is to have a consistent and complete collection of all things relevant to IPv4 for the years to come.
Read, digest, enjoy - and discuss :-)
Best regards,
Rob Blokzijl
On 04/19/2012 04:42 PM, Milton L Mueller wrote:
"Leave data as it is in the RIPE Registry. The Legacy Resource Holder will not be able to add to or alter their data and will not have access to any RIPE NCC services such as reverse delegation and certification."
It is likely that in response to this policy legacy holders will choose to use an alternate registrar for the services you are precluding them from using (e.g., reverse delegation and certification). In that case RIPE NCC will need to negotiate an interoperability or interconnection agreement with these service alternate providers to ensure that a globally applicable unique registration occurs.
the space referred to is allocated to (or administered by if you prefer) ripe. reverses for this space are delegated to ripe (one single exception with no relevance to this subject). alternate service providers can't delegate from this space. to choose an alternate provider for reverse delegation, the ip space in question will have to be returned, and a new allocation (from the alternate reverse delegation provider) will have to be done. would work nicely: the 'legacy' is removed, the user will get a normal new allocation. everyone should be happy with such a case. all this aside: you seem to try to express the 'threat of competition'. ripe isn't a business. there is no competition. ncc coordinates for the community, that's all. in case of users where it's actually an option to choose between some rirs, it's not important to ripe whether he chooses ripe or some other rir. actually, if this user chooses a different rir, the result is less work for ncc, and more free space for ripe. on the other hand, dropping the paragraph or the whole legacy paragraph is probably best anyway.
If RIPE NCC is not willing to do that, it appears to be attempting to leverage its monopoly to force legacy holders into purchase and use of their services, something that raises obvious competition policy issues. I wouldn't advise you to do down that path.
community ip coordination isn't a business. regards, Chris
-----Original Message-----
the space referred to is allocated to (or administered by if you prefer) ripe. reverses for this space are delegated to ripe (one single
[Milton L Mueller] It wasn't allocated by RIPE. Read the definition of "legacy."
alternate service providers can't delegate from this space.
[Milton L Mueller] They don't have to delegate, the space has already been delegated to a legacy holder.
to choose an alternate provider for reverse delegation, the ip space in question will have to be returned, and a new allocation (from the alternate reverse delegation provider) will have to be done. would work nicely: the 'legacy' is removed, the user will get a normal new allocation. everyone should be happy with such a case.
[Milton L Mueller] thanks for demonstrating the distance between your worldview and reality in concrete terms.
all this aside: you seem to try to express the 'threat of competition'. ripe isn't a business. there is no competition. ncc coordinates for the community, that's all. in case of users where it's actually an option to
[Milton L Mueller] DNS wasn't a business in 1995. Then it was.
on the other hand, dropping the paragraph or the whole legacy paragraph is probably best anyway.
[Milton L Mueller] Here we may agree. Let's focus on that.
Milton, On Thu, Apr 19, 2012 at 2:54 PM, Milton L Mueller <mueller@syr.edu> wrote:
-----Original Message-----
the space referred to is allocated to (or administered by if you prefer) ripe. reverses for this space are delegated to ripe (one single
[Milton L Mueller] It wasn't allocated by RIPE. Read the definition of "legacy."
alternate service providers can't delegate from this space.
[Milton L Mueller] They don't have to delegate, the space has already been delegated to a legacy holder.
Chris is talking about the reverse delegation in the DNS. He is correct that RIPE NCC administers reverse delegation for some legacy blocks. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel
participants (9)
-
boggits -
Chris -
Gert Doering -
McTim -
Milton L Mueller -
Niall O'Reilly -
Nick Hilliard -
Nigel Titley -
Rob Blokzijl