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
  • 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@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@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@psg.com> wrote:

    Sergey Myasoedov <sergey@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