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

[Emma Apted <]

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