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

    • To: Masato Yamanishi <myamanis at gmail dot com>
    • Subject: Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG
    • From: David Hilario <d.hilario at laruscloudservice dot net>
    • Date: Fri, 1 Sep 2017 11:07:38 +0300
    • Cc: sig-policy <sig-policy at apnic dot net>
    • Delivered-to: sig-policy at mailman dot apnic dot net
    • In-reply-to: <CALcH-8nnRL2__zCBRw_BdpYbx0OGan8M6HXN-D4YQQCumB00hg at mail dot gmail dot 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>
      • 
        
        On 1 September 2017 at 10:30, Masato Yamanishi <myamanis at gmail dot com> wrote:
        > 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"?
        
        You have your own maintainer on the resources and simply manage
        everything yourself, just like if the space was directly allocated to
        you by APNIC.
        No changes in your organisation and in any of your systems on how to
        provision the address space and link it to the APNIC database.
        
        > What do you mean by "control the RPKI or reverse delegation"?
        
        All managed on your own through the normal platform issued by APNIC,
        you do not need to rely on 3rd party for the setup or management of
        these functionalities.
        
        Same as you will control the route objects creations and any more
        specific inetnum creations in the APNIC Database.
        
        > Why your customer cannot or doesn't want to ask their upstream to manage
        > RPKI or reverse delegation?
        
        Mainly internal rules, security related, many organisations prefers to
        be in charge of things where they can, and not rely on third parties,
        not everyone is outsourcing.
        
        If you rely on another LIR, you rely entirely on a third party not to
        screw up, can be as simple as a bad script,  during the whole leasing
        period.
        Or you can have a temporary transfer and the only one that can screw
        up is your own organisation or APNIC, you simply reduce the risk
        factors.
        
        > Why your customer cannot or doesn't want to ask their upstream to point NS
        > record of assigned space to their customer?
        >
        
        Same as above, to be in control, and not outsourcing to third parties
        when one can avoid it.
        
        >>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.
        >
        
        Why?
        Where would the adverse effect be to the community or the IPv4 pool in
        general from that policy proposal?
        It only offers an option to some organisation.
        
        > 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 at laruscloudservice dot 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 at laruscloudservice dot net
        >
        >