Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC

    • To: David Hilario <d.hilario at laruscloudservice dot net>
    • Subject: Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG
    • From: Masato Yamanishi <myamanis at gmail dot com>
    • Date: Fri, 1 Sep 2017 00:30:56 -0700
    • Cc: sig-policy <sig-policy at apnic dot net>
    • Delivered-to: sig-policy at mailman dot apnic dot net
    • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RfhL5A2Tlo/ZV2n+6nLxrkMIZhebVH3UxubVbPiD5zU=; b=loNqAEDd66kKuF4wQWA7uZjOIGccEcv6NI8r0SV7/iG4PUIeOU/RyVoomnfv42y0Z3 QIMvU5AntlMWIH9oskIlv1RQqOCCmyY7b7pVdPr3MXA2bESq0CWq2WrAnVcSRZA4eTHv j+WW3cZPEx2xhpD+CRN5krSJ6RlGBFzSq2C55FehY6tJCsLwwl1v94j9CeaQ8FVgurCW MJGjMVXSdGRIylEWFdiuQxFadJ0JUMyE2NxiudtQJ8mL7sFxcm1D/Ajgk/T858ATnGN6 b2t05ZMuunypZxj/4zxxd+f2VUVA4Vtbm4lzLxVK/ZWeRD611Ou1cPHrxdp706IEEX7Q GQNA==
    • In-reply-to: <CANoO2f7YCweMAozop=PpxVbgkqJ1ca_Lj9EKvvXTOBDWm=eW-A@mail.gmail.com>
    • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy/>
    • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
    • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
    • List-post: <mailto:sig-policy@lists.apnic.net>
    • List-subscribe: <https://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
    • List-unsubscribe: <https://mailman.apnic.net/mailman/options/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
      • Hi David,

        Oh, I thought I had replied, but seems not.

        >Simply speaking not having the resources in MyAPNIC is equivalent as
        to not having them at all.
        >You do not have full control of the resources in the APNIC database,
        >you do not control the RPKI or reverse delegation.

        I'm afraid you just rephrased what you wrote previously, which was not clear for me. So still unclear.
        Let me ask more specifically.
        What do you mean by "full control of the resources in the APNIC database"?
        What do you mean by "control the RPKI or reverse delegation"?
        Why your customer cannot or doesn't want to ask their upstream to manage RPKI or reverse delegation?
        Why your customer cannot or doesn't want to ask their upstream to point NS record of assigned space to their customer?

        >If someone wants it to be possible, I don't see the reason to why object it?

        NO. I don't think it is enough justification nor problem statement to propose the policy, in particular for v4.

        Still, against for this proposal.

        Regards,
        Matt


        2017-08-23 21:01 GMT-07:00 David Hilario <d.hilario at laruscloudservice dot net>:
        Hi,


        On 23 August 2017 at 10:32, Masato Yamanishi <myamanis at gmail dot com> wrote:
        > Hi Proposer,
        >
        > I have same view as Mr. David Huberman.
        > From the problem statement of prop-119 which says,
        >
        >>1. Problem statement
        >>------------------------------------------------------------------------
        >>
        >>It is currently not possible for an organisation to receive a temporary
        >>transfer under the current policy framework. Some organisations do not
        >>want to have address space registered as assignments or sub-allocations,
        >>but would rather have the address space registered as "ALLOCATED PA".
        >
        >
        > or your message on Aug 17th,
        >
        >>It actually came up a few time from larger networks who tend to want
        >>that, it is a form of long term leasing for them, they want the
        >>resources into their registry out of convenience but also due to
        >>internal procedures, they for example only want to commit for a 5 year
        >>period while preparing their IPv6 and then return the space.
        >>
        >>The do not want to receive a sub-allocation or assignment, as it needs
        >>to be part of their LIR/registry for them to be able to count it into
        >>the network inventory and use the address.
        >>
        >>Some organisation have strict policies against use of external IP space.
        >
        >
        > or your another message on Aug 17th,
        >
        >>The policy came to be as we have had several large companies actually
        >>asking for such type of transfers.
        >>
        >>It is already a possibility in the RIPE region to do such transfers.
        >>
        >>It is really to cover a corner case where organisations are not able
        >>or interested in receiving the IP space in form of assignments or
        >>sub-allocations, but need them to be part of their own registry for
        >>full control of the space and only for a pre-set amount of time.
        >
        >
        > or your another message on Aug 18th,
        >
        >>If it is not registered to your LIR in your registry, you cannot send
        >>an email to helpdesk at apnic dot net as it is not your space to control in
        >>APNIC DB in the first place, but the space from your LIR that has
        >>issued the space to you, your LIR decides how to register it and which
        >>maintainers will be on it, you are not in full control.
        >>
        >>And ultimately for the ones using RPKI, it needs to be under their
        >>control to issue ROAs in MyAPNIC and not rely on any other parties for
        >>their own IP management.
        >
        >
        > I could not imagine concrete usecase or requesters of this policy as well as
        > the reason why you and/or they cannot live with current policy.
        > Rather, it sounds some kind of "nice to have" which is not enough
        > justification as the problem statement for v4 space in these days.
        >

        Simply speaking not having the resources in MyAPNIC is equivalent as
        to not having them at all.
        You do not have full control of the resources in the APNIC database,
        you do not control the RPKI or reverse delegation.

        So it is a bit more than simply "nice to have", but indeed, it would
        be nice to have.

        Being able to have full control for X amount of time would be "nice to
        have" for those who want to have it for their own organisation.

        If someone wants it to be possible, I don't see the reason to why object it?


        > Regards,
        > Masato
        >
        >
        >
        > 2017-08-22 18:47 GMT-07:00 David Hilario <d.hilario@laruscloudservice.net>:
        >>
        >> Hi,
        >>
        >> On Aug 23, 2017 1:42 AM, "David Huberman" <david.huberman at oracle dot com>
        >> wrote:
        >>
        >> Hello,
        >>
        >> I oppose this proposal as written.
        >>
        >> I do not believe this policy proposal benefits network operations.
        >>
        >>
        >> All your resources would be under your APNIC account, you are in full
        >> control for everything from Database registration, RPKI and reverse DNS.
        >>
        >> There is some advantages to network operation, it is not purely
        >> administrative.
        >>
        >> I
        >>
        >>  believe it is intended to further the goals of the policy proposer and
        >> the company he owns/works at, which exists to earn money from the sale and
        >> leasing of IP address blocks (per their website).
        >>
        >>
        >> From a business point of view, this policy came as a reaction to requests
        >> from customers, yes.
        >>
        >> Policies are there to accommodate the distribution and operation of the
        >> various parties operating in the region.
        >>
        >> Some see a benefit in having a system like this in place, attacking the
        >> policy based on our company's services is a bit odd at best.
        >>
        >> Some organization's are not willing to buy IPv4 space as a form of
        >> permanent transfer, they do not believe in IPv4 remaining the dominant
        >> protocol for the years to come but do need some IPs for some expansion and
        >> projects that they can later simply return back, other giant internet
        >> organizations with too much money don't care and are currently buying up
        >> everything on offer.
        >>
        >> This proposal would help leveling that field a bit.
        >>
        >>
        >> If the policy proposal has shed light on some deficiencies in the
        >> Membership Agreement (found at:
        >> https://www.apnic.net/about-apnic/corporate-documents/documents/membership/membership-agreement/
        >> ), then I suggest it would be helpful for the policy proposer to work with
        >> APNIC staff and/or the EC, rather than through the Policy SIG.
        >>
        >>
        >> I really don't follow your logic here.
        >>
        >>
        >> Thank you,
        >> David
        >>
        >> David Huberman | Principal Program Manager
        >> Oracle Cloud
        >> 1501 4th Ave #1800
        >> Seattle, WA 98101
        >> USA
        >>
        >>
        >> *              sig-policy:  APNIC SIG on resource management policy
        >> *
        >> _______________________________________________
        >> sig-policy mailing list
        >> sig-policy at lists dot apnic dot net
        >> https://mailman.apnic.net/mailman/listinfo/sig-policy
        >>
        >>
        >> Regards,
        >> David Hilario
        >>
        >> *              sig-policy:  APNIC SIG on resource management policy
        >> *
        >> _______________________________________________
        >> sig-policy mailing list
        >> sig-policy at lists dot apnic dot net
        >> https://mailman.apnic.net/mailman/listinfo/sig-policy
        >
        >
        David Hilario

        IP Manager

        Larus Cloud Service Limited

        p: +852 29888918  m: +359 89 764 1784
        f: +852 29888068
        a: Flat B5, 11/F, TML Tower, No.3 Hoi Shing Road, Tsuen Wan, HKSAR
        w: laruscloudservice.net
        e: d.hilario@laruscloudservice.net