Hi Adam,
Tks for the clarification, in my reading (may be not being native English or
cultural background), it looked like you were saying so.
However, saying "your policy proposals often have an impact different from the
stated purpose" makes it even more complex for me to understand, because never,
in any of the around 100 (never counted them, but I think is around that
number) policy proposals that I've submitted among all the RIRs and reached
consensus, I've been told that.
In fact there have been 2 policy proposals, that reached consensus, and the
implementation of the RIR created troubles, despite my original wording was
avoiding those issues:
1) ARIN: because the AC model managing the text instead of the authors, a
policy proposal with a correct wording from my side, created an explicit
"hijacking authorization" with the AC final text. I discovered it, and needed
to sumit a new proposal to correct the AC wording.
2) APNIC: the abuse-c policy included a detailed example of a procedure, to
avoid people in the helpdesk to "untrust" emails from APNIC, fall into pishing
attempts, etc. The implementation ignored that, then the membership complained
about that. I think it has been corrected.
I will be happy to heard from APNIC (or other RIRs) if any other text from any
of my policy proposals created troubles. If this is the case, the community
must know it, because we are collectively doing something wrong, and only
knowing it, will be able to take more care in the future. You don't think so?
So clearly, as any other human, I'm subjected to make errors, but up to know
nobody told me I did that with any of the policies. I really try hard to make
the text as precise as possible, and take inputs from everyone to improve it.
And no, my English is not good. I learn it myself when I'd 8 years old (48
years ago), reading computer and electronics books, as they were not available
in spanish and probably my mistakes can precisely happen because that. However,
I think one of the aspects that the RIRs staff and the community can help, in
addition to provide inputs, is precisely to have a more correct wording, since
version 1 or any policy proposal. There is no need to do that when a proposal
already reached consensus, or later on. As sooner, as better, because it will
help everybody to have a more clear understanding of the text.
Again, this is not an IPv6 transfer proposal. It is a rewording of the M&A for
each resource type (IPv4, IPv6 and ASN). In my opinion the actual wording can
be interepreted by the community as "I can't do this" because I'm not
"completely buying company A, only a division". The problem here is that the
secretariat is NOT always getting those questions. People read the policy
manual, and if they understood that something can't be done or they have doubts
on it, they just do it under the table, they don't take the risk to ask ...
I understand that there is cost with almost every policy proposal, and I
understand that the staff time need to priorize in terms of what is useful for
"most" of the membership, what is "more urgent" and so on. I've clearly stated
that I'm not asking this to be in place tomorrow or after tomorrow, but making
it part of the plans according to what is possible, makes sense. Not making it,
could bring a member with that need to enter into litigation, which may be more
expensive.
And this is true for *every* policy proposal, so I don't think we need to state
it in the policy text of each one.
I don't think making it more transparent in the proposal saying "this is not
urgent, we will like to have this policy reaching consensus but then
implemented when the secretariat can do it", is a good thing, because actually
that's already understood for all the policy proposals. And again, repeating
myself " this is true for *every* policy proposal, so I don't think we need to
state it in the policy text of each one ".
Regards,
Jordi
@jordipalet
El 3/3/21 0:41, "Adam Gosling" <em...@adamgosling.com> escribió:
Hi Jordi
Just personally. I did not mean to question your honesty or commitment to
the community. I respect and appreciate your involvement in the PDP and wish
other authors would put forward proposals I could comment on.
My observation was that your policy proposals often have an impact that is
different from your stated purpose. I believe that is the case here. Allowing
inter-RIR IPv6 transfers as an M&A request is not a barrier to transfer and has
the same technical outcome anyway.
Some community members, whose English is not as good as yours, may not
realise this.
The community has considered inter-RIR IPv6 transfers in the past and found
they were not acceptable (at that time).
All policy is a cost / benefit consideration. Your stated benefit is that
some resource holder may at some time in the future require this service and
that at the time the counterpart RIR may have a policy that allows it and may
have developed the technical ability to fulfil the request.
The cost is estimated by the Secretariat as 3 months development time.
Perhaps the Secretariat could tell us what project will be cancelled if this
proposal reaches consensus, because this development time will not be budgeted
for 2021.
Your point that the RIR's and the community should develop solutions the
community may want/need in future is quite valid. However, if that’s what you
are proposing, then make that more transparent in your proposal.
If the community demonstrates that it accepts this cost / benefit
trade-off, I’ll happily support the proposal.
Regards,
Adam
> On 1 Mar 2021, at 9:09 pm, JORDI PALET MARTINEZ
<jordi.pa...@consulintel.es> wrote:
>
> Hi Adam,
>
> I don't have the need to "disguise" any policy proposal. I'm a very
honest and transparent person, pity that you didn't noticed it, and if I
believe that IPv6 transfers outside of M&A's are required, I will submit that
policy in an open and transparent manner.
>
> I've you believe that I'm trying to cheat the community, please say so
clearly and show evidences.
>
> That said, I'm happy to work on IPv6 Inter-RIR transfers at a later
stage, but this is not the case with this proposal.
>
> The policies not always have cases that *already happened*. The policies
should be there to prevent those cases being real needs and rejected. In fact,
if they happened there may several situations:
> 1) The organizations that need that read the policy manual, understood
they can't do it, and desisted.
> 2) They asked the secretariat.
> 3) They didn't read the policy/DBs update is managed (or not updated al
all), that nobody noticed it, especially in intra-RIR situations.
>
> So the question here is, do we want to have oredered solutions for real
business situations, or we prefer to ignore them and even force them to bypass
the policies and hide the situation?
>
> If we don't have policies up-front problems, then problems became a huge
issue, delay business, even may create losses. Some folks will just ignore
policies and go ahead. We all know it. Policies have been done *always*
up-front issues happening, when those possible issues where discovred, not just
after we discover the issue. Some times we have policies too late, because
nobody discovered the issue: that's unavoidable, because we don't have the
crystal ball.
>
> I can't talk for the secretariat if there have been questions about this
previously, hopefully they can say. I know it happened in other regions.
>
> By the way, my reading of the RIPE procedures is that they don't
distinguish if you do an M&A with all the resources or part of it, they may
confirm it (I'm sure they are in the list), if that's the case, and if already
happened or there have been questions on that.
>
> Clearly the secretariat, and the same for other RIRs, should work on
developing whatever the community decides is good to have. And I think it is
much better to ensure that we have those developments in mind up-front of
having real problems, specially if they may be complex and require coordination
among different RIRs, instead of rushing when we have the problems already in
our back, right?
>
> Regards,
> Jordi
> @jordipalet
>
>
>
> El 1/3/21 3:31, "sig-policy-boun...@lists.apnic.net en nombre de
em...@adamgosling.com" <sig-policy-boun...@lists.apnic.net en nombre de
em...@adamgosling.com> escribió:
>
> Hi all,
>
> I oppose this proposal.
>
> I am not convinced of the need for it. Are there examples of when an
M&A
> request was refused that would be permitted by this policy change?
>
> This looks like an IPv6 Inter-RIR transfer proposal in disguise?
>
> I don't think the APNIC Secretariat should be required to do the
> development work to support IPv6 reverse DNS if there is no clear
> indication that other regions will support IPv6 reverse DNS fragments
in
> the future.
>
>
> Adam
>
>
>
>
> On 2021-02-01 22:25, chku wrote:
>> Dear SIG members,
>>
>> A new version of the proposal "prop-130: Modification of transfer
>> policies"
>> has been sent to the Policy SIG for review.
>>
>> It will be presented during the Open Policy Meeting at
>> APRICOT2021/APNIC 51
>> online-only conference on Wednesday, 03 February 2021.
>>
>> We invite you to review and comment on the proposal on the mailing list
>> before the meeting.
>>
>> The comment period on the mailing list before an APNIC conference is an
>> important part of the policy development process. We encourage you to
>> express your views on the proposal:
>>
>> - Do you support or oppose this proposal?
>> - Does this proposal solve a problem you are experiencing? If so,
>> tell the community about your situation.
>> - Do you see any disadvantages in this proposal?
>> - Is there anything in the proposal that is not clear?
>> - What changes could be made to this proposal to make it more
>> effective?
>>
>> Information about this proposal is available at:
>> http://www.apnic.net/policy/proposals/prop-130
>>
>> Regards,
>> Bertrand and Ching-Heng
>> APNIC Policy SIG Chairs
>>
>>
>> -------------------------------------------------------
>>
>> prop-130-v003: Modification of transfer policies
>>
>> -------------------------------------------------------
>>
>> Proposer: Jordi Palet Martnez
>> jordi.pa...@theipv6company.com
>>
>>
>> 1. Problem statement
>> --------------------
>>
>> Existing transfer policies for IPv4, IPv6 and ASN resources have some
>> differences among what is allowed and what not, if in the case of
>> intra-RIR and inter-RIR, and it is not clear if in case of merger and
>> acquisitions it is referring to a complete company, part of it, or even
>> if in case of a company reorganization or relocation, the policy is
>> supportive to that case.
>>
>> In some regions, this may not be a policy, but an administrative
>> procedure, but this may change in the future by means of a policy
>> proposal.
>>
>> In the caser of inter-RIR, the counterpart RIR need to have a
>> reciprocal
>> policy or procedure that allows it.
>>
>> Finally, there should not be differences from the APNIC perspective, on
>> the considerations of an M&A for different type of resources, because
>> there is no reason for allowing, for example, IPv4 resources to be
>> transferred, and instead IPv6 ones not. For example, an organization
>> may
>> be hosting services in a Data Center, by means of Virtual Machines and
>> moving to a different DC in another region. It is ridiculous to allow
>> to
>> keep the IPv4 addresses (so not renumber the VMs) and instead ask to
>> renumber IPv6. It is a big and unnecessary disruptive complexity.
>>
>>
>> 2. Objective of policy change
>> ------------------------------
>> To ensure that the policy text is clarified, if those cases are
>> supported by the community.
>>
>> It will also facilitate companies or business units, moving or being
>> established in other regions.
>>
>> It will minimize legal issues in case an acquisition claiming their
>> rights over the acquired company and their existing assets (resources).
>>
>>
>> 3. Situation in other regions
>> ------------------------------
>> There is a variety of support of all those cases in different regions.
>> The one more open is RIPE, followed by ARIN and LACNIC. A similar
>> policy
>> proposal is being discussed in AFRINIC.
>>
>>
>> 4. Proposed policy solution
>> ----------------------------
>> Actual Text
>> 8.4. Mergers & acquisitions
>> APNIC will process and record the transfer of IPv4 resources as the
>> result of merger or acquisition.
>>
>> 11.0. Transfer of IPv6 resources
>> APNIC will only recognize the transfer or IPv6 addresses as the result
>> of Merger & Acquisition activity. The following conditions and
>> consequences apply.
>>
>> 13.3. Mergers & acquisitions
>> APNIC will recognize the transfer of ASNs as the result of merger or
>> acquisition.
>>
>>
>> Proposed Text
>> 8.4. Mergers, acquisitions and relocations
>> APNIC will recognize the transfer of IPv4 resources resulting from a
>> partial or complete merger, acquisition, reorganization or relocation.
>>
>> In the case of inter-RIR, the counterpart RIR need to have a reciprocal
>> policy/procedure that allows it.
>>
>>
>> 11.0. Transfer of IPv6 resources
>> APNIC will recognize the transfer or IPv6 resources resulting from a
>> partial or complete merger, acquisition, reorganization or relocation.
>>
>> In the case of inter-RIR, the counterpart RIR need to have a reciprocal
>> policy/procedure that allows it.
>>
>>
>> 13.3. Mergers, acquisitions and relocations
>> APNIC will recognize the transfer of ASNs resulting from a partial or
>> complete merger, acquisition, reorganization or relocation.
>>
>> In the case of inter-RIR, the counterpart RIR need to have a reciprocal
>> policy/procedure that allows it.
>>
>>
>> 5. Advantages / Disadvantages
>> -----------------------------
>> Advantages:
>> Fulfilling the objectives above indicated and ensuring clarity on what
>> is allowed and what not.
>>
>> The proposal makes clear that this may only happen, in case of
>> Inter-RIR
>> cases, when both RIRs have a reciprocal policy.
>>
>> Minimizing possible legal issues.
>>
>>
>> Disadvantages:
>> It could be considered that it can create further disaggregation,
>> especially in IPv6, however, those cases are rare and only happening
>> from time to time, so the impact is negligible, and justified by the
>> documentation provided when the transfer is requested.
>>
>> In the Inter-RIR cases, coordination with the counter-part RIR is
>> needed, but this is already an ongoing activity because all the regions
>> (with the exception of AFRINIC), already have those mechanisms in place
>> (for both, administrative and technical aspects).
>>
>>
>> 6. Impact on resource holders
>> ------------------------------
>> None.
>>
>>
>> 7. References
>> --------------
>> RIPE NCC:
>> https://www.ripe.net/publications/docs/ripe-682
>>
>> ARIN:
>> https://www.arin.net/policy/nrpm.html#eight2
>>
>> LACNIC:
>>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-4/language/en
>>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-3/language/en
>>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-2/language/en
>> _______________________________________________
>> * sig-policy: APNIC SIG on resource management policy
>> *
>> _______________________________________________
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> https://mailman.apnic.net/mailman/listinfo/sig-policy
> * sig-policy: APNIC SIG on resource management policy
*
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be
considered a criminal offense. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited, will be considered a criminal offense, so you must reply to the
original sender to inform about this communication and delete it.
>
>
>
> * sig-policy: APNIC SIG on resource management policy
*
> _______________________________________________
> sig-policy mailing list
> sig-policy@lists.apnic.net
> https://mailman.apnic.net/mailman/listinfo/sig-policy
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be
considered a criminal offense. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited, will be considered a criminal offense, so you must reply to the
original sender to inform about this communication and delete it.
* sig-policy: APNIC SIG on resource management policy *
_______________________________________________
sig-policy mailing list
sig-policy@lists.apnic.net
https://mailman.apnic.net/mailman/listinfo/sig-policy
