[ncc-services-wg] Destruction of trust

Dear Rogier and Sander,

Sorry for the late reply, however holiday period started on our side. 

As you point out, ripe-453 is a RIPE Policy that requires a contractual agreement between End Users of Provider Independent address and the RIPE NCC, either through a sponsoring LIR or directly with the RIPE NCC.

The legacy address space project that the RIPE NCC is engaged in lies completely outside the scope of that policy. For the legacy address space project, the RIPE NCC requires a different contract between the legacy address space holder and a sponsoring LIR. This contract establishes that both parties agree on the correctness of the information provided by the legacy address space holder. This contract should not be the one used for ripe-453.

Regards,
Andrew


On Jul 19, 2012, at 5:39 PM, Rogier Spoor wrote:

> Dear Andrew,
> 
> Thank you for explaining that apparently there is a communication issue.
> 
> Sander Steffann raised an important issue in his email:
> --
> But more importantly: RIPE-452 is a result of policy proposal 2007-01,
> and that proposal explicitly excluded ERX resource holders from being
> required to sign such a contract. Quoting from 2007-01
> (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This
> proposal does not cover number resources marked in the RIPE database as
> Early Registration (ERX) or NOT-SET.  It also does not cover number
> resources listed in the RIPE database which were assigned by InterNIC or
> assigned or allocated by other Regional Internet Registries."
> --
> 
> Unfortunately you haven't responded to this issue yet. Can you please
> elaborate on this issue?
> 
> regards,
> Rogier
> 
> On 7/19/12 5:03 PM, Andrew de la Haye wrote:
>> Dear colleagues,
>> 
>> In Phase 3 of its legacy space project, the RIPE NCC is sending emails
>> to contact legacy address space holders who are not RIPE NCC members and
>> who hold a /16 or more.
>> 
>> In the emails we are sending, all three options, including the option to
>> register legacy address space with a sponsoring LIR, are presented to
>> the organisations. However, in the case of contact with three
>> organisations, an email was mistakenly sent that did not mention the
>> option to use a sponsoring LIR.
>> 
>> We regret this mistake and apologise sincerely for the confusion and any
>> distress this might have caused.
>> 
>> We are contacting the organisations concerned to ensure that the correct
>> message is delivered and that they are aware of all options available to
>> them.
>> 
>> The RIPE NCC understands that "freezing" registry entries would be
>> counterproductive and would not help its goal of ensuring registry
>> correctness. The RIPE NCC has no intention of freezing registry entries
>> for legacy resource holders.
>> 
>> Also, the RIPE NCC would like to assure legacy address space holders
>> that it has no intention of withdrawing reverse DNS services for legacy
>> address space holders.
>> 
>> The certification of address space, however, is available only to RIPE
>> NCC members.
>> 
>> Thank you for raising the issue and for giving us the opportunity to
>> clarify these matters. As Marcus has pointed out, the information
>> concerning the project is available on our legacy webpages:
>> http://www.ripe.net/lir-services/resource-management/legacy-space
>> 
>> We will update the documentation concerning the project in the coming
>> days to accurately reflect the situation.
>> 
>> Again, we apologise for the error and ask that you contact us at
>> <legacy at ripe.net> if you have any questions or concerns. Or let us know
>> via discussion on the list.
>> 
>> Best regards,
>> 
>> Andrew de la Haye
>> Chief Operations Officer
>> RIPE NCC
>> 
>> On 7/19/12 4:11 PM, Sander Steffann wrote:
>>> Hi,
>>> 
>>> Giving some background information related to address policy:
>>> 
>>>> If I've understood correctly, both option a) and b) above involve in
>>>> effect abolishment of historical grants and contractual submission
>>>> to all current and future RIR address policies and procedures which
>>>> are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting
>>>> what is relevant.  No grandfather clauses, acknowledgement of
>>>> historical rights or explicit limitations anywhere in sight, and no
>>>> option to amend the template contract imposed by the RIPE NCC.
>>> 
>>> The template is defined in RIPE-452:
>>> 
>>>> ---
>>>> The details of any such contracts are outside the scope of this
>>>> document.  However, at the minimum, all contracts should include:
>>>> 
>>>> • Notice that the LIR is responsible for liaising with the resource
>>>> holder to keep registration records up-to-date
>>>> • Notice that the resource holder is obliged to provide up-to-date
>>>> registration data to the LIR and that some or all of this
>>>> registration data will be published in the RIPE WHOIS Database
>>>> • Notice that none of the provider independent resources may be
>>>> sub-assigned to a third party
>>>> • Notice that the resource holder is obliged to pay an annual fee to
>>>> the LIR for the resources
>>>> • A clear statement that the resources will return by default to the
>>>> RIPE NCC if
>>>>    • The resource holder cannot be contacted
>>>>    • The annual fee to the LIR is not paid
>>>> • A clear statement that the use of resources is subject to RIPE
>>>> policies as published on the RIPE web site and which may be amended
>>>> from time to time
>>>> ---
>>> 
>>> The first two requirements are what is important according to the
>>> activity plan ("The goal of these activities will be to bring ERX and
>>> legacy space registration records up to the same standards of accuracy
>>> as address space distributed by the RIPE NCC since 1992."), and I
>>> don't think anybody objects to that.
>>> 
>>> The next point about sub-assignments is a problem. Current legacy
>>> holders don't have any restrictions on what they can or can not do
>>> with their address space. This would suddenly limit what legacy
>>> holders are allowed to do, and possibly even make their existing
>>> network setup break the contract.
>>> 
>>> The next two points about paying the bills and the addresses returning
>>> to the RIPE NCC if the bills are not paid also change the rights of
>>> the legacy holder. When they don't sign the contract their records in
>>> the database are frozen and the RIPE NCC "cannot guarantee the
>>> continuation of reverse DNS". If they sign the contract and then not
>>> pay the bill they lose all rights to the address space....
>>> 
>>> The last point is the most obvious problem for legacy holders. Now the
>>> legacy holder is subject to no policy at all, and after signing such a
>>> contract they are suddenly subject to all current and future RIPE
>>> policies. I fully understand that legacy holders don't want to sign
>>> such a contract.
>>> 
>>> But more importantly: RIPE-452 is a result of policy proposal 2007-01,
>>> and that proposal explicitly excluded ERX resource holders from being
>>> required to sign such a contract. Quoting from 2007-01
>>> (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This
>>> proposal does not cover number resources marked in the RIPE database
>>> as Early Registration (ERX) or NOT-SET.  It also does not cover number
>>> resources listed in the RIPE database which were assigned by InterNIC
>>> or assigned or allocated by other Regional Internet Registries."
>>> 
>>> So, following the acceptance of 2007-01 by the community: if the RIPE
>>> NCC requires legacy holders to sign such a contract (contract with
>>> sponsoring LIR) they are doing something which directly contradicts an
>>> accepted RIPE policy... If any legacy holder already signed such a
>>> contract I strongly feel that they should either be given the option
>>> to void the contract, or the contract should be declared void
>>> automatically.
>>> 
>>> - Sander
>>> 
>>> 
>> 
> 
> 
>