Re: [address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"
From address-policy-wg-admin@ripe.net Sun Oct 5 22:15:17 2003
Dear all,
As indicated at the last working group meeting, I would very much like to se POSITIVE feedback from the WG before we make final policy:
Feedback on this document should be sent to the address-policy-wg@localhost mailing list for a period of two weeks.
This review period will end on TWO WEEKS FROM ANNOUNCEMENT.
Who can committ to read and send their comments within this timeline ?
At RIPE 46 I was one of those who raised their hands when Hans Petter asked whether anybody volunteers to comment the document if it is circulated again on the list. Please find below my comments. First of all I would like to congratulate those who made the effort of re-writing the policies document. I think they did a very good job. The restructuring seems good to me. I have some specific comments, questions, and sugestions respectively: 1. In paragraph 2.0 I suggest mentioning RFC3330 too. (It gives further details about the address space usage than RFC1918 and RFC1112.) 2. Also in paragraph 2.0, point 2 I suggest adding a new sentence, which in my view makes it easier to understand the reference to RFC2993 (I included in the quoted text my sentence using underscores instead of spaces for easier identification): "...Hosts using these addresses cannot directly be reached from the Internet. _Such_connectivity_is_enabled_by_using_the_technique_known_as_ Network_Address_Translation_(NAT)_. Private addresses restrict a network so that its hosts only have partial Internet connectivity..." (of course, the exact wording itself can be changed). 3. In paragraph 4.0, at the end of second paragraph I suggest adding: "...Registration data (range, contact information, status etc.) must be correct _at_all_times_(i.e._they_have_to_be_maintained)." 4. In paragraph 6.1. I have a question and a suggestion related to the statement: "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:" It is clear that in case of a new request that needs to be approved, information must be submitted on the current form. The question I have is related to the audit of a prior assignment: does the LIR have to produce the documentation in the _current_ version of the form? I would think that producing the documentation on the form used _at_the_time_of the assignment would be acceptable. If so, it may be good to slightly rephrase the above to reflect this. 5. I have the impression that the AW applied to an End User network (paragraph 7.0) is not clear enough, so I suggest adding a couple of new words: "An AW can be applied to an End User network once per 12-month period. This means an LIR can make more than one assignment to an End User _in_any_such_12_months'_period, but the total amount of address space cannot be larger than the LIR's AW. An LIR's AW is considered unused on the anniversary of the first (?!? I would think _last_) assignment to the End User._After_the_exhaustion_of_the_AW, the LIR may only assign additional addresses to the same End User after approval from the RIPE NCC. (In one of the sentences above I have the impression that first should be changed to last - did I misunderstood something?) 6. In the first paragraph of 9.0 I suggest repeating "or sub-allocated" in order to avoid any possible mis-interpretation (i.e. that sub-allocations do not necessarily have to be returned): "LIRs are allocated PA address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned _or_sub-allocated_ by the previous service provider will have to be returned and the network renumbered." 7. I have a question regarding the value "NOT-SET" of the status attribute (paragraph 9.0). The document states that _new_ objects cannot be created with this attribute. I would expect the database to also reject updates that have such an attribute. Is this the way the database behaves? If yes, it may be useful to mention this here ( I suggest something like: "Objects cannot be created or updated with this value".) That is all for now. I hope you will find these useful. Best regards, Janos
Hi,
Feedback on this document should be sent to the address-policy-wg@localhost mailing list for a period of two weeks.
In paragraph 3 of section 5.0, we have " If an LIR is planning to exchange or transfer address space it needs to contact the RIPE NCC so that the changes can be properly registered. Please note that the LIR always remains responsible for the entire allocation it receives from the RIPE NCC. " Should the second sentence have at the end "until the allocation has been officially transferred to another LIR with the authorisation of the RIPE NCC" ? Since I would have thought that after an LIR has transferred an allocation to another LIR, then it no longer needs to remain responsible for it. Section 5.4 ends with "LIRs not wishing to lose address space in this way should ensure that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator." I recommend that it be emphasised that it is the LIR's responsibility to do this, not RIPE NCC's. By the time we reach section 7.0, the Assignment Window has been mentioned many times; I recommend we move this section to somewhere earlier in the document. Near the end of section 7.0, training is mentioned. RIPE NCC's own training courses, with associated URL, could also be mentioned here. In the last paragraph of section 9.0 we have "If an LIR has an End User that requires PI address space they should refer the End User to an appropriate registry. " Does this mean that if an ISP, who is an LIR, is approached by a customer who says they require PI space, that the LIR should simply give the RIPE NCC URLs and email addresses to the customer, so they can send the request themselves to RIPE NCC? Or can the LIR send the request, on behalf of the customer, to the RIPE NCC? Otherwise, the document looks good to me! :-) Best regards, Emma
Hi, Thanks for contributing to the review of the document. I think the suggested text can help improve the clarity of the document. I have a couple of comments on specific questions, too, though. Janos Zsako <zsako@banknet.net> wrote: [...]
4. In paragraph 6.1. I have a question and a suggestion related to the statement:
"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:"
It is clear that in case of a new request that needs to be approved, information must be submitted on the current form. The question I have is related to the audit of a prior assignment: does the LIR have to produce the documentation in the _current_ version of the form? I would think that producing the documentation on the form used _at_the_time_of the assignment would be acceptable. If so, it may be good to slightly rephrase the above to reflect this.
You're right. We'll update the phrasing.
5. I have the impression that the AW applied to an End User network (paragraph 7.0) is not clear enough, so I suggest adding a couple of new words:
"An AW can be applied to an End User network once per 12-month period. This means an LIR can make more than one assignment to an End User _in_any_such_12_months'_period, but the total amount of address space
I think this should be added to improve clarity but...
cannot be larger than the LIR's AW. An LIR's AW is considered unused on the anniversary of the first (?!? I would think _last_) assignment to the End User._After_the_exhaustion_of_the_AW, the LIR may only assign additional addresses to the same End User after approval from the RIPE NCC.
(In one of the sentences above I have the impression that first should be changed to last - did I misunderstood something?)
... I think the ambiguity in the wording here reflects the ambiguity in the policy. We could update the wording to use the word "last" but that would make the policy more strict than it is at the moment. At some point it would be useful to review and rationalise the current AW policy. It is fairly complicated to document and so fairly documented to use. It would be good (after publishing this updated document, I hope) to take a new look at this part of the policy. [...]
7. I have a question regarding the value "NOT-SET" of the status attribute (paragraph 9.0). The document states that _new_ objects cannot be created with this attribute. I would expect the database to also reject updates that have such an attribute. Is this the way the database behaves? If yes, it may be useful to mention this here ( I suggest something like: "Objects cannot be created or updated with this value".)
I think I ought to give a little explanation of a problem we were had noticed and why we suggested introducing this new status attribute value. When the status attribute was introduced it wasn't automatically added to all objects. At a later date it was made mandatory for inetnum objects. This meant that it was not possible to update an inetnum object without adding a status attribute. The result of this is that people that wanted to update contact information and didn't know (or care) about the status attribute were unable to do so. Net result: poorer quality information. For this reason, we would explicitly prefer to allow objects with this value to be updated on the principle that half a loaf is better than no bread. Emma Apted <emma.apted@psineteurope.com> wrote: [good stuff]
In the last paragraph of section 9.0 we have "If an LIR has an End User that requires PI address space they should refer the End User to an appropriate registry. " Does this mean that if an ISP, who is an LIR, is approached by a customer who says they require PI space, that the LIR should simply give the RIPE NCC URLs and email addresses to the customer, so they can send the request themselves to RIPE NCC? Or can the LIR send the request, on behalf of the customer, to the RIPE NCC?
In cases like this LIRs can send us requests for PI assignments for their customers. Currently, the RIPE NCC doesn't provide registration services directly to End Users. Best regards, -- leo vegoda RIPE NCC Registration Services Manager
Dear Leo, Thank you for your reply and for your explanations. I am afraid I still do not understand something about the AW (and I have a comment below).
5. I have the impression that the AW applied to an End User network (paragraph 7.0) is not clear enough, so I suggest adding a couple of new words:
"An AW can be applied to an End User network once per 12-month period. This means an LIR can make more than one assignment to an End User _in_any_such_12_months'_period, but the total amount of address space
I think this should be added to improve clarity but...
cannot be larger than the LIR's AW. An LIR's AW is considered unused on the anniversary of the first (?!? I would think _last_) assignment to the End User._After_the_exhaustion_of_the_AW, the LIR may only assign additional addresses to the same End User after approval from the RIPE NCC.
(In one of the sentences above I have the impression that first should be changed to last - did I misunderstood something?)
... I think the ambiguity in the wording here reflects the ambiguity in the policy. We could update the wording to use the word "last" but that would make the policy more strict than it is at the moment. At some point it would be useful to review and rationalise the current AW policy. It is fairly complicated to document and so fairly documented to use. It would be good (after publishing this updated document, I hope) to take a new look at this part of the policy.
I quote below the relevant part of RIPE-234: " 5.2.5.2 Assignment Window for End User Assignments An LIR can apply their Assignment Window to an End User network only once in any 12-month period. This means that if an LIR makes more than one assignment to an organisation, the total amount of address space assigned with their AW in any twelve month period may not exceed the LIR's AW size. The LIR may only assign additional addresses to the same organisation after approval from the RIPE NCC. " In my view, this means that I may for example assign an AW worth of address space to the End User on 1 January of every year (assuming that I make no further assignments during the year). I also understand that the AW is unused at a moment in time, if at that moment I am allowed to assign an AW worth of address space (to that particular End User). In the above example, let's assume that I started assigning address space to the End User on 1 January 2000. The last time I have therefore assigned to them was 1 January 2003. If I read the text of the Draft, this means that my AW (with respect to that End User) is UNUSED, as it has to be considered unused starting 1 January 2001 (the anniversary of the FIRST assignement). My undertsanding is that it should read "LAST", therefore the AW would have to be considered unused starting 1 January 2004. Did I misunderstand something?
Emma Apted <emma.apted@psineteurope.com> wrote:
...
In cases like this LIRs can send us requests for PI assignments for their customers. Currently, the RIPE NCC doesn't provide registration services directly to End Users.
My understanding so far was that there are LIRs that have PI allocations, so they can assign PI space to there customers, and there are LIRs who do not have such an allocation. These latter are, however, able to support End Users in getting PI address space by sending these requests to the RIPE NCC (on behalf of the End User, i.e. the End User would not have to, and should not contact the RIPE NCC directly). I agree with Emma that what you state above (and what I hope I have detailed further correctly) is not obvious form the document. It may be a good idea to add some text that clarifies this... Thanks and regards, Janos
Hi, Janos Zsako <zsako@banknet.net> wrote: [...]
"An AW can be applied to an End User network once per 12-month period. This means an LIR can make more than one assignment to an End User _in_any_such_12_months'_period, but the total amount of address space I think this should be added to improve clarity but...
cannot be larger than the LIR's AW. An LIR's AW is considered unused on the anniversary of the first (?!? I would think _last_) assignment to the End User._After_the_exhaustion_of_the_AW, the LIR may only assign additional addresses to the same End User after approval from the RIPE NCC.
(In one of the sentences above I have the impression that first should be changed to last - did I misunderstood something?) ... I think the ambiguity in the wording here reflects the ambiguity in the policy. We could update the wording to use the word "last" but that would make the policy more strict than it is at the moment. At some point it would be useful to review and rationalise the current AW policy. It is fairly complicated to document and so fairly documented to use. It would be good (after publishing this updated document, I hope) to take a new look at this part of the policy.
I quote below the relevant part of RIPE-234:
" 5.2.5.2 Assignment Window for End User Assignments
An LIR can apply their Assignment Window to an End User network only once in any 12-month period. This means that if an LIR makes more than one assignment to an organisation, the total amount of address space assigned with their AW in any twelve month period may not exceed the LIR's AW size. The LIR may only assign additional addresses to the same organisation after approval from the RIPE NCC. "
In my view, this means that I may for example assign an AW worth of address space to the End User on 1 January of every year (assuming that I make no further assignments during the year).
I also understand that the AW is unused at a moment in time, if at that moment I am allowed to assign an AW worth of address space (to that particular End User).
In the above example, let's assume that I started assigning address space to the End User on 1 January 2000. The last time I have therefore assigned to them was 1 January 2003. If I read the text of the Draft, this means that my AW (with respect to that End User) is UNUSED, as it has to be considered unused starting 1 January 2001 (the anniversary of the FIRST assignement). My undertsanding is that it should read "LAST", therefore the AW would have to be considered unused starting 1 January 2004.
Did I misunderstand something?
I think we may have been saying the same thing in different ways. The AW is refreshed on the anniversary of the first assignment. However, the way we look at it is that assignments following the first assignment are subtracted from the 'refreshing' and they have their own anniversaries. For example, if I had a /21 AW and made a /23 assignment to a customer on 1 January 2003 I would have a /22 and a /23 left from my AW for that customer for the rest of the year. If I assigned the same customer another /23 on 1 April, 1 July and 1 October my AW (for that organisation) would return to /23 on 1 January 2004. It would not return to /21 because there were three subsequent assignments each of which has an anniversary. If there's agreement that this is correct then we can update the text for the policy document to something clearer. [...]
My understanding so far was that there are LIRs that have PI allocations, so they can assign PI space to there customers, and there are LIRs who do not have such an allocation. These latter are, however, able to support End Users in getting PI address space by sending these requests to the RIPE NCC (on behalf of the End User, i.e. the End User would not have to, and should not contact the RIPE NCC directly).
I agree with Emma that what you state above (and what I hope I have detailed further correctly) is not obvious form the document. It may be a good idea to add some text that clarifies this...
Your text here is probably clearer than what was originally written. I think we should use it for the new policy document. Regards, -- leo vegoda RIPE NCC Registration Services Manager
participants (3)
-
Emma Apted -
Janos Zsako -
leo vegoda