RE: [address-policy-wg] Re: [ncc-services-wg] Request Forms: updated and available on LIR Portal
Hi Christian, Sascha, You both made several points and I hope I can explain our thinking on them for you. We think these new forms represent a change in the way we provide services to LIRs so we've addressed this answer to the NCC Services WG list. We don't think they represent a change to the RIPE community's policy. This new set of forms is intended to reduce the burden on both the LIRs and the RIPE NCC. By reducing the administrative burden we hope to allow LIRs to access our services faster and improve the level of service we are able to offer. One of the ways we have attempted to reduce the burden on LIRs is by removing the Current Address Space Usage template in requests for IPv4 space. The template was fairly difficult for LIRs to complete. However, while the template has been replaced, the principle it represents - conservation - remains. That is why we ask whether the End Users has address space that can already meet the needs of this request. The situation with regard to address space that is being returned has not changed in these forms. We realise that many enterprises are not fully aware of the address space they use. To help LIR in these situations we have a Glimpse index of the database available. It can be found at: <http://www.ripe.net/db/whois-free.html> The LIR remains responsible for ensuring that assignments are justified and that address space that should be returned is returned. This remains the same. Nonetheless, LIRs must still ensure that the assignments they make are justified. That means that they need to gather appropriate justification. We introduced a template asking about the equipment being used by the End User to help us understand requests faster. We often received requests for fairly large amounts of address space for vaguely described "network devices" or "LAN segments". The information provided was not sufficient for us to evaluate the request. As such the Hostmaster would need to ask the LIR for additional information. This would delay the request. We hope that the introduction of this new template will help us evaluate requests more quickly and improve the level of service we offer you. It is possible to put "N/A" in the equipment template fields but the Hostmaster might need that information to understand your request and ask you to supply it. This would delay things for you. We understand that it may not always be possible to include useful information in this template. However, we believe that the template will have a broadly positive effect on the level of service we can offer. You asked about the requirement for a network diagram to be supplied when requesting an IPv6 allocation. There are two reasons for this. Firstly, the RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 networks is limited and we need network operators to show us how they intend to use IPv6 address space in their networks. Secondly, the current IPv6 policy does not allow stockpiling of IPv6 address space. One way of distinguishing a genuine request from one that is intended for stockpiling reasons is to request a diagram showing how the address space will be used. It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn diagram instead of sending one by e-mail. When we have more experience with IPv6 I expect we will make the diagram optional. Finally, we agree with you that many LIRs are not aware of the difference between PA and PI address space. This is unfortunate and has several roots: many LIRs have a large number of staff that change regularly. Also, many people find the difference between PA and PI rather arcane and difficult to understand. We try to address the former issue through LIR Training Courses and by making policy documents clearer to read. We've made updates to all the RIPE community's policy documents over the last few months. The IPv4 policy has been updated and a draft of the revised text is available for review by the community, now. It can be found at: <http://www.ripe.net/ripe/draft-documents/ipv4-policies.html> We have also taken a look at the wording used to distinguish between PA and PI. We would like to make the distinction more apparent to the untrained eye. We have published initial proposals on changes to the status attribute value names and are co-ordinating with APNIC on this work. We hope to make it easier for everyone to understand the status of address space. There are also a few advantages to the new forms that may not be apparent from the customer perspective but remain very important. Because the syntax-checking software at the RIPE NCC has been replaced the forms can be changed and updated more easily in the future. This means we can be more responsive to your needs than in the past. Also, providing services via the LIR Portal will let us improve the request process to make it easier and faster in the future. Thank you for your insights into these new forms. We are keen to get reactions from LIRs so that we can continue to improve and update them and the services we provide - both e-mail and web versions. regards, Dominic Spratley, Registration Services Manager RIPE NCC
Hay, On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote:
Hi Christian, Sascha,
You both made several points and I hope I can explain our thinking on them for you. We think these new forms represent a change in the way we provide services to LIRs so we've addressed this answer to the NCC Services WG list. We don't think they represent a change to the RIPE community's policy.
This new set of forms is intended to reduce the burden on both the LIRs and the RIPE NCC. By reducing the administrative burden we hope to allow LIRs to access our services faster and improve the level of service we are able to offer. [...]
of course. I want to apologize that noone noticed the _good_ changes but only the apparently "bad" ones.Though such things happen if you change something without discussing it BEFORE. I like those parts of the new form(s). Some silly or at least outdated questions have been removed, the complicated part of the Current Address Space Usage was reduced to a simple question ect. No doubt, that helps.
We introduced a template asking about the equipment being used by the End User to help us understand requests faster. We often received requests for fairly large amounts of address space for vaguely described "network devices" or "LAN segments". The information provided was not sufficient for us to evaluate the request. As such the Hostmaster would need to ask the LIR for additional information. This would delay the request. We hope that the introduction of this new template will help us evaluate requests more quickly and improve the level of service we offer you. It is possible to put "N/A" in the equipment template fields but the Hostmaster might need that information to understand your request and ask you to supply it. This would delay things for you.
That's the only thing I wanted to hear, because it's not that clear in the supporting notes. So the information is OPTIONAL, one CAN provide it IF AVAILABLE and one can speed up a request by doing so. But it is not a REQUIREMENT if the rest of the request or the additional text information is clear enough.
We understand that it may not always be possible to include useful information in this template. However, we believe that the template will have a broadly positive effect on the level of service we can offer.
Fine for me after this explaination. Probably the supporting notes should be more clear about that though. And if a customer explicitely denies detailed information about his equipment or network being revealed to RIPE, this must not be a reason for denying an Assignment either. And yes, such customers exist.
You asked about the requirement for a network diagram to be supplied when requesting an IPv6 allocation. There are two reasons for this. Firstly, the [...]
I'm going to answer this one seperately.
Finally, we agree with you that many LIRs are not aware of the difference between PA and PI address space. This is unfortunate and has several roots: many LIRs have a large number of staff that change regularly. Also, many people find the difference between PA and PI rather arcane and difficult to understand. We try to address the former issue through LIR Training Courses and by making policy documents clearer to read. We've made updates to all the RIPE community's policy documents over the last few months. The IPv4 policy has been updated and a draft of the revised text is available for review by the community, now. It can be found at:
<http://www.ripe.net/ripe/draft-documents/ipv4-policies.html>
We have also taken a look at the wording used to distinguish between PA and PI. We would like to make the distinction more apparent to the untrained eye. We have published initial proposals on changes to the status attribute value names and are co-ordinating with APNIC on this work. We hope to make it easier for everyone to understand the status of address space.
I don't think changing words does help much here. "untrained eyes" without any knowledge about what they do don't understand the differences better just by using different terms. (Actually the new words do confuse a "trained eye" in this draft :-) More focus on having the LIRs train their staff better would be of more success in general in my eyes. [...rant about unassigned but used IP-Ranges and noone doing anything about it deleted...wrong place, wrong time...]
There are also a few advantages to the new forms that may not be apparent from the customer perspective but remain very important. Because the syntax-checking software at the RIPE NCC has been replaced the forms can be changed and updated more easily in the future. This means we can be more responsive to your needs than in the past. Also, providing services via the LIR Portal will let us improve the request process to make it easier and faster in the future. Thank you for your insights into these new forms. We are keen to get reactions from LIRs so that we can continue to improve and update them and the services we provide - both e-mail and web versions.
Well, i just submitted my first ripe-283 (manually, the Web- thing didn't work right and resulted in an error after the "Address space returned?" page...), let's see what happens. The first thing i noticed is, the CIDR notation in the Address Space Usage section...sounds like a nice idea, but turns out being a bit messy. Especially if you need to count the totals manually. No fun, one can get blind from that :) I don't know how the LIR-portal thing handles it (most likely does the maths job?), but otherwise a small Tool for "addition of CIDR ranges" would be nice, not everyone got something like that at hand i think. So far, thanks for the clarifying answers. -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================
Hi!
[...] The IPv4 policy has been updated and a draft of the revised text is available for review by the community, now. It can be found at:
<http://www.ripe.net/ripe/draft-documents/ipv4-policies.html> [...]
There are also a few advantages to the new forms that may not be apparent from the customer perspective but remain very important. Because the syntax-checking software at the RIPE NCC has been replaced the forms can be changed and updated more easily in the future. This means we can be more responsive to your needs than in the past.
Maybe I did get you wrong, but I don't think that the forms can be changed "on the fly". A quote from the draft: 6.1 Documentation for Assignments [...] The RIPE NCC provides forms for gathering the required information. The information requested in the forms must be collected by the LIR. [...] Nothing wrong with this, but if we are expected to follow the wording the forms have to be stable.
Also, providing services via the LIR Portal will let us improve the request process to make it easier and faster in the future. Thank you for your insights into these new forms. We are keen to get reactions from LIRs so that we can continue to improve and update them and the services we provide - both e-mail and web versions.
Looks like RIPE NCC gets a bit too webbish for us (as in the dilbert strip http://www.gaertner.de/~schuma/not-too-webbish.gif). What about providing a new autohm in ftp://ftp.ripe.net/ripe/tools/ ? We use autohm for each assignment to meet the documentation requirement of the current policy: 5.1.1 Documentation [...] However, if a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on a current version of the IPv4 Address Space Request Form available from [...] The IPv4 policy draft makes the need for autohm even clearer: [...] This is very important when an LIR makes assignments using its AW. If a request needs to be approved by the RIPE NCC or if information is required in the event of an audit, the information must be submitted on a current version of the request form found at: [...] Most of our assignments fall into the "using its AW" category. According to ripe-170 "Pro-active Audits of LIRs with little contact" should exist. Using autohm ensures that we could provide the documentation in the required format on the fly. Regards, Joerg
Hi, On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote:
You both made several points and I hope I can explain our thinking on them for you. We think these new forms represent a change in the way we provide services to LIRs so we've addressed this answer to the NCC Services WG list. We don't think they represent a change to the RIPE community's policy.
Actually, I tend to disagree, at least for some parts. Which is why I've put the APWG list back into the CC: (sorry for duplicates). Some of the criticism voiced is that the NCC is asking questions and enforcing rules that are more strict than what the policy demands - and this is certainly relating to policy. [..]
You asked about the requirement for a network diagram to be supplied when requesting an IPv6 allocation. There are two reasons for this. Firstly, the RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 networks is limited and we need network operators to show us how they intend to use IPv6 address space in their networks.
I agree with the assessment that "more experience for the NCC is a good thing". On the other hand, many startup IPv6 deployments are extremely trivial ("one access server with 1000 DSL circuits, serving /48s to DSL end users" would certainly qualify for the policy requirements). So I don't think it's appropriate to enforce this "you send us an interesting picture, otherwise you won't get an IPv6 allocation" approach. Make it optional.
Secondly, the current IPv6 policy does not allow stockpiling of IPv6 address space. One way of distinguishing a genuine request from one that is intended for stockpiling reasons is to request a diagram showing how the address space will be used. It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn diagram instead of sending one by e-mail. When we have more experience with IPv6 I expect we will make the diagram optional.
This is "conservationism striking again", and this is BAD. The idea behind the current policy is "make IPv6 address blocks available to anybody who is asking for them" (and can reasonably claim 200 future IPv6 customers). For that, you don't *need* a fancy network, so why do you have to demonstrate it at all? What are you worrying about? Address wastage is really not a problem right now. Obstacles on the way to IPv6 deployments are a problem, and we don't want the NCC to be an obstacle. Now come and flame me :-) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 55575 (56535) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hay, On Mon, Sep 01, 2003 at 04:33:06PM +0200, Gert Doering wrote:
Hi,
On Tue, Aug 26, 2003 at 12:57:13PM +0200, Dominic Spratley wrote:
You both made several points and I hope I can explain our thinking on them for you. We think these new forms represent a change in the way we provide services to LIRs so we've addressed this answer to the NCC Services WG list. We don't think they represent a change to the RIPE community's policy.
Actually, I tend to disagree, at least for some parts. Which is why I've put the APWG list back into the CC: (sorry for duplicates).
Some of the criticism voiced is that the NCC is asking questions and enforcing rules that are more strict than what the policy demands - and this is certainly relating to policy.
Yes, in the case of the requirement of a network topolocy map, it looks like it always was part of the request form for the initial IPv6 Allocation, but never part of the policy. Just that noone complained yet.
[..]
You asked about the requirement for a network diagram to be supplied when requesting an IPv6 allocation. There are two reasons for this. Firstly, the RIPE NCC has not yet made yet 250 IPv6 allocations. Our experience with IPv6 networks is limited and we need network operators to show us how they intend to use IPv6 address space in their networks.
I agree with the assessment that "more experience for the NCC is a good thing".
On the other hand, many startup IPv6 deployments are extremely trivial ("one access server with 1000 DSL circuits, serving /48s to DSL end users" would certainly qualify for the policy requirements).
So I don't think it's appropriate to enforce this "you send us an interesting picture, otherwise you won't get an IPv6 allocation" approach. Make it optional.
Full-ACK. The main reason i came up with the idea that i can save some time and not paint a pointless map was, that it's just not in the policy. So i didn't consider it a nescessary requirement. We almost have have such a trivial setup as you mention. We're still using an IPv6 overlay network, no joint IPv4+IPv6 backbone yet due to vendor limitations, i.e. many tunnels. It's subject to change at any time anyways, there's absolutely no way to tell how the final network will look like until all vendors support IPv6 in mainline firmware releases. So where is the point in doing so? What benefit has the RIPE NCC from a map which doesn't need to be a fancy diagram and even can be a handwritten drawing as Dominic suggest? And no, "overlay network" doesn't mean it's a test setup not qualifying for production IPv6 space either. The reason for requesting a production IPv6 Allocation is, that one wants to start to actually assign /48s to endusers and make sub-allocations to downstream organisations. I also consider the "have a plan for making at least 200 /48 assignments to other organisations within two years." requirement quite dim. But since it's in the policy and i initially supported a slow-start mechanism, i have no problems with that. It's not that hard to fulfill for most early adoptors anyways, not even for my LIR :) ("Tunnels, free Tunnels, Tunnels for all! Take two - get one for free!") Though... see below.
Secondly, the current IPv6 policy does not allow stockpiling of IPv6 address space. One way of distinguishing a genuine request from one that is intended for stockpiling reasons is to request a diagram showing how the address space will be used. It doesn't have to be a a fancy diagram. It's also fine to fax a hand-drawn diagram instead of sending one by e-mail. When we have more experience with IPv6 I expect we will make the diagram optional.
This is "conservationism striking again", and this is BAD.
The idea behind the current policy is "make IPv6 address blocks available to anybody who is asking for them" (and can reasonably claim 200 future IPv6 customers). For that, you don't *need* a fancy network, so why do you have to demonstrate it at all?
What are you worrying about? Address wastage is really not a problem right now. Obstacles on the way to IPv6 deployments are a problem, and we don't want the NCC to be an obstacle. ยด
Full-ACK, again. But, even more generally speaking: Look at the current IPv4 policy discussion. It shows that more and more LIRs are very small LIRs, probably using only IP-space for themselves and very few customers. Even the initial allocation size is subject to be reduced again. What do those LIRs do if they want to start deloying IPv6? They probably can't show 200 potential /48 customers. And don't have the manpower or any interest in painting topology maps. They are cut off from IPv6 then and need to get a suballocation from another LIR? Why do they pay the full RIPE fee then? I guess the whole policy currently is a bit outdated. In my eyes it prevents IPv6 deployment. Not to a degree like the hardware/software support situation, but it adds obstacles for some organisations and they rather just don't care about IPv6, "too complicated". The main reason i supported the slow-start mechanism was, that there was no experience in first place, and for example not even the initial IPv6 Allocation size was settled. And as we know, it changed in the meantime. Currently there's still the discussion about weather to make reservations and fragment the 2001::/16 space or not, but most of the policy is quite final i think, so i'm not very positive about the need for RIPE to continue with that slow-start thing for much longer. On the other hand, just look who currently alrady got some IPv6 Allocation and how many of them are just unused. I only looked for de.* LIRs on my search for some IPv6 uplink who probably can offer IPv6 natively, but already was amazed about the results. For starters, i was quite happy that our main uplink got an IPv6 Allocation for almost a year now, just to notice that their Prefix is not in the BGP tables shortly afterwards, and there are no assignments yet. Asking our tech contacts there, the first one at least knew what IPv6 is, but then i got a "no, we don't have any IPv6 at all, not even via tunnel". Sales Department then even told me "IPv6? No, we don't even have plans for that at the moment, sorry." So, hm. Someone can tell me how they got the Allocation? Because they are a big IPv4 LIR and someone gave RIPE a high-gloss Network map which their Marketing people produce all the time? RIPE, do you really WANT to be lied to? (DISCLAIMER: I'm not accusing anyone of lying here, that's just a question as stylistic device :) ) Of course i can just comply with that and make up thousands of dial-customers who all want to have IPv6, i know that they do! And of course we have a BIIIIG IPv6 network in 2years, see my nice map? So my point is, one really should start thinking about a change. There is the idea of "One IPv6 Allocation for every LIR on request." on some mailinglists for quite a while. I'd support this now for the future (not nescessarily imemdiately).
Now come and flame me :-)
Certainly not :) -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz@baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================
participants (4)
-
Dominic Spratley -
Gert Doering -
Joerg Schumacher -
Sascha Lenz