[ncc-services-wg] 2012-08 Publication of Sponsoring LIR for Independent Number Resources Moved to Last Call

Daniel,
thank you for the discussion.

> For PA space, I'm able to locate LIR responsible for each particular
> assignment almost without exception. I just like similar option for PI
> addresses. This information is hidden.

Sponsoring LIR is not responsible for the PI assignment at all, so we should not talk about 'similar option'. The goal of sponsoring is to provide to customer (PI owner) with a RIPE-452-compliant contract. There is often no connectivity service provided. Even more, sponsoring LIR normally is not controlling the database objects related to PI.

> PI address space wasn't designed for this kind of "privacy". Why should
> be there any difference between end-user of PA and end-user of PI
> address in terms of responsible LIR publication? You didn't provided
> clear ansver for that.

I am not talking about privacy. The requirement of transparency is present in RIPE-452:
…
A clear statement that the resources will return by default to the RIPE NCC if
The resource holder cannot be contacted
So in case when PI holder does not wish to answer to your mails, you can not do anything, and even if you know that nl.example is in contractual relationship with the 'PI Owner Ltd' - you still can not require the answer from the PI holder.

> I then can ask RIPE NCC, why on particular PI IP isn't this information
> available. But I don't have to contact RIPE NCC in case of any problem
> with PI end-user, if I have such information available - I can simply
> contact LIR directly, in case of direct End User contact failure. It's
> normal RIR-LIR-EndUser hiearchy. It works for PA for years, and there's
> no reason not to have similar hiearchy publicly reachable for PI.

As 2012-08 does not have an obligation for sponsoring LIR to be a mail-broker between the whole world and PI holders - this proposal seems useless and harmful to me.

--
Sergey



On Oct 16, 2013, at 2:51 PM, Daniel Suchy <danny at danysek.cz> wrote:

> Hello,
> 
> On 10/16/2013 12:34 PM, Sergey Myasoedov wrote:
>> exactly, all this administrativia is in our mind. PI objects have no privileges in comparing with PA, nothing is hidden. We don't need to know who is collecting the payments for LIR sponsoring. As well as we don't need to know who exactly signed the contract or what is a birthdate of PI owner's CEO.
> For PA space, I'm able to locate LIR responsible for each particular
> assignment almost without exception. I just like similar option for PI
> addresses. This information is hidden.
> 
> PI address space wasn't designed for this kind of "privacy". Why should
> be there any difference between end-user of PA and end-user of PI
> address in terms of responsible LIR publication? You didn't provided
> clear ansver for that.
> 
> For PA end-users, contract is always clear "who is collecting the
> payments" (and this is majority of addresses managed by RIPE). And
> still, in ripe-592, PI existence is still declared mainly for
> *multihoming* purposes - just for technical reasons. PI existence was
> *never* declared for privacy you're requesting. If some LIRs assigned PI
> just because there're less informations traceable (and it seems you
> did), that was wrong understanding of PI space. That's my oppinion.
> 
>> RIPE-452 condition check is performing by the RIPE NCC and I am satisfied with this. The good thing is that NCC decided on obligatory publication of PI holder name. That is enough, I believe.
>> 
>> 2007-01 is not yet completely implemented, there are some PIs without the sponsoring LIR remains. Let the NCC work on this.
> That's no reason for hiding this information for PI space, where this
> information is available. As mentioned above.
> 
> I then can ask RIPE NCC, why on particular PI IP isn't this information
> available. But I don't have to contact RIPE NCC in case of any problem
> with PI end-user, if I have such information available - I can simply
> contact LIR directly, in case of direct End User contact failure. It's
> normal RIR-LIR-EndUser hiearchy. It works for PA for years, and there's
> no reason not to have similar hiearchy publicly reachable for PI.
> 
> With regards,
> Daniel
> 
>> 
>> --
>> Sergey
>> 
>> On Oct 16, 2013, at 12:34 PM, Daniel Suchy <danny at danysek.cz> wrote:
>> 
>>> IP address space is a technical ressource in general. Difference between
>>> PI and PA is just administrative, assigned IP address will always work
>>> independently on it's status.
>>> 
>>> For PA address space, financial-related informations ale published
>>> already (should be, by policy), there's no real reason to hide similar
>>> informations for PI address space. By publishing sponsoring LIR, only
>>> existence of relationship between LIR and End-User is visible. It's not
>>> about detailed contract content (financial aspects).
>>> 
>>> Members of RIPE also should be able to verify, if ripe-452 policy is
>>> implemented properly by RIPE NCC. Publication of sponsoring LIR provides
>>> this option. There should not be some "dark" IP spaces, where we'll not
>>> able to found responsible LIR.
>>> 
>>> Policies aren't developed on GM. There's no reason to postpone this
>>> until GM. This proposal brings more transparency and it was discussed
>>> properly within WG.
>>> 
>>> With regards,
>>> Daniel
>>> 
>>> On 10/16/2013 11:01 AM, Sergey Myasoedov wrote:
>>>> Randy,
>>>> you are right and I am not trying to decide whether we do have consensus as I am not a chair of WG. 
>>>> 
>>>> Kurtis,
>>>> Please consider my message as a comment to a proposal. I already posted my thoughts before, and I hope the reason of objection is clear. Let's postpone the implementation of proposal until next GM (or until the board decides not to put this question to GM agenda).
>>>> 
>>>> 
>>>> --
>>>> Sergey
>>>> 
>>>> 
>>>> On Oct 16, 2013, at 11:52 AM, Randy Bush <randy at psg.com> wrote:
>>>> 
>>>>> Sergey Myasoedov <sergey at devnull.ru>,
>>>>>>> as for me, there is no clear consensus.
>>>>> 
>>>>> Kurtis:
>>>>>> you can appeal this decision if you believe we have acted in error.
>>>>>> However, I would like to point out that consensus does not mean
>>>>>> universal agreement, and I still believe there is a consensus for this
>>>>>> proposal in the WG.
>>>>> 
>>>>> perhaps sergey would find draft-resnick-on-consensus-05.txt helpful
>>>>> 
>>>>> consensus != unanimity
>>>>> 
>>>>> randy
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/ncc-services-wg/attachments/20131016/009e913b/attachment.html>