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