[address-policy-wg] Revised Draft Document for review: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region"

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 at 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 at 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