Re: [sig-policy] prop-072: Reapplication limits whentransferringaddress
I'm confusing that restricting behavior of the transfer exactly
means of refusing record the transfer.
To be clear this concern, let me clarify an situation where restrict transfer
by the policy, but transfer happened. I think that the registry can take two options:
1. Refusing record the transfer
2. Record the transfer with a flag which means prohibited transfer or activated in the future
I would like to hear which option will be appropriate or both of these does not work.
Regards,
--
Satoru Matsushima
-----Original Message-----
From: sig-policy-bounces at lists dot apnic dot net [mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Seiichi Kawamura
Sent: Friday, March 13, 2009 10:13 AM
To: John Schnizlein
Cc: sig-policy at apnic dot net
Subject: Re: [sig-policy] prop-072: Reapplication limits whentransferringaddress space
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all
> It seems to me that the most likely result of refusal of RIRs to
> register transfers is not that transfers will not happen, but that
> someone else will be found to register them if registration of who is
> authorized to use an address block is necessary.
prop-071 section 4.3 states
4.3 Recipients of transferred address space are not permitted to
transfer any portion of this address space to another
organisation for at least 24 months.
Is this a "refusal of RIRs to register transfer" also?
If you removed the "transferred" word from the clause, it would nearly equal Masato-san's proposal.
Just to be clear, I'm not trying to pick on anyone or any policy.
Just a simple question.
Seiichi
John Schnizlein wrote:
> It was not my intention to point my questions at any particular person.
>
>>> What would be the effect of a policy to refuse to record a transfer
>>> of which both the relinquishing and acquiring party agree?
>> It can prevent that remaining IPv4 address space in IANA will be
>> consumed very rapidly.
>
> It is not clear to me that refusing to record a transfer changes the
> rate of allocation from the free pool. It might be useful to write
> out explicitly the chain of implication from the refusal to the effect
> on allocation. Then we could compare that to the potential harm of
> trying to establish a system of regulation on transfers.
>
>> And it is a intention of prop-072, isn't it?.
>
> I don't think so. My reading of prop-72 is that it constrains
> allocations from the RIR's free pool rather than attempting to
> regulate the transfers. Quote from the proposal:
>
> This policy proposal seeks to supplement prop-050, "IPv4 address
> transfers", by not permitting organisations who have transferred IPv4
> address from obtaining more address space from APNIC for a period of
> 24 months after the transfer.
>
>>> Would it be good for the Internet as a whole to have this
>>> information not recorded?
>>> Or do you want some organization other than the RIR for one of the
>>> parties to provide this kind of record?
>> I'm afraid that you misunderstood my position.
>> I'm supporting prop-050, so I want to avoid such situation, of course.
>
> I am sorry if my questions appeared specific to your position.
>
> It seems to me that the most likely result of refusal of RIRs to
> register transfers is not that transfers will not happen, but that
> someone else will be found to register them if registration of who is
> authorized to use an address block is necessary.
>
>>> Policies that constrain what the RIR allocates from its pool seem to
>>> risk fewer unintended consequences than attempting to influence the
>>> behavior of other parties.
>> So, your point is "Even if we will restrict transfer of newly
>> allocated address space, somebody will transfer it immediately in
>> underground. In such case, information of such address space is not
>> recorded correctly on registry." Is it correct understanding?
>
> If I understand your description, yes. Evidence that transfers have
> already taken place prior to transfer policy - not to mention prior to
> exhaustion of the free pool(s) - has been shown here and in other
> RIR's policy discussions.
>
> More than just observing this fact, my goal is to remind people that
> the behavior we can control with these policies is that of the RIR,
> not that of other parties. Policies that attempt to control others
> are likely to have different - and worse - effects than intended.
>
> John
> * sig-policy: APNIC SIG on resource management policy *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
iD8DBQFJubM5crhTYfxyMkIRAmj/AJ9CS1n6e6AXkRoJ8J9KRX4/o0kGewCgg3WA
mHilFJxk8lKxxyBgKgqnpE0=
=dwLP
-----END PGP SIGNATURE-----
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy