lowering maximum assignment window

Hello all,


	first of all, sorry for th delay in answering the messages.


	I'm totally agree with this proposal, but I have two doubts:

- the first: the assignment window is applicable to the whole organization
addressing or only to the requests? I mean, if an organization has ten C
classes, then they apply for ten ones more, have I got to take into account the
total of them, twenty C classes, to see if they are reaching to the maximum
assignment window? Or have I got to take into account only the ten C classes
they apply for in the request?

- the second: When will this proposal be made effective? And Paula, could you
tell me which is the maximum assignment window for es.rediris?


	In the other hand, I'd like to comment you something that, maybe, would
be related to this issue. I'd like to know if there is any document that say if
there is any policy to apply in case of bad use of the assigned addresses. Have
you ever had an experience in which you have to unassigned addresses to an
organization? Is there any type of revisions we could do to assure the correct
use of the assigned addresses? Maybe this organization doesn't use the total
addressing any more or they applied in the past for a quantity of addresses
that they don't use now because they have reorganized their networks.

	Which are your thoughts about this?


Thank you and regards,

Maribel Cosin.


>
> Hi all,
>
> Below is my original message with a proposal to lower the maximum
> assignment window to a /21 instead of a /19.
>
> There was much discussion about this on the lir-wg mailing list. Here
> is our final proposal that tries to take all the comments into
> consideration:
>
> All registries that currently have a /20 or /19 assignment window will
> be at a rotating interval (doing them all at once would put too much of
> a load on an already large wait queue) set to a /23 assignment window
> temporarily. They will then need to start sending a few requests to
> show that they understand the assignment policies and procedures. If
> these requests are fine, we will raise their assignment window to a
> size that matches the requests we have seen from them (therefore not
> necessarily to a /19). Hopefully this will get these registries on an
> equal footing with other LIRs. The reason we need to review the
> assignment window for all of these registries is that they started out
> with a /19 assignment window in the beginning of the RIPE NCC. Whereas
> younger registries started out with a 0 assignment window and have
> since then proven that they can handle assignents of a certain size and
> have therefore had their assignment window raised. For all of the
> younger registries we already have a procedure in place of doing random
> audits and we will continue doing this.
>
> By the way, one of the results of this discussion was that Poul-Henning
> Kamp wrote a script that checks for inconsistencies between addresses
> that are in use but are not registrered in the RIPE database. These
> statistics can be found at: http://stat.cybercity.dk/ripe/
>
> Please check this page for your own registry ID to see whether your
> registry has any inconsistencies to fix. Of course the RIPE NCC will
> also be contacting the Registries with the largest list of
> inconsistenceis as well, but we don't have the resources to
> systematically contact every registry on the list.
>




-- 
+---------------------------------------------------------------+
|   RedIRIS NIC                                                 |
|   Centro de Comunicaciones CSIC RedIRIS                       |
|   Serrano 142                 Tel:    + 34 915855150          |
|   28006  Madrid               Fax:    + 34 915855146          |
|   SPAIN                       Email:  iris-nic at rediris.es     |
+---------------------------------------------------------------+