[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[sig-policy] transfer discussions
Dear SIG members:
Below is a summary of discussions on the transfer proposal to date. As
discussed previously on this mailing list, we will handle the transfer
discussion as "features for decision" as opposed to "competing
proposals". Therefore, we are not posting summaries on individual
transfer proposals, but on the main points of discussion on transfer
proposals in general.
We strongly encourage you to continue discussions on the mailing list
before the Policy SIG this Thursday, 26 February 2009.
Regards,
Randy and Jian
Transfer proposals: main points of discussion
---------------------------------------------
- Minimum size, /24 or then current size
- Recipient to justify use
- Inter-RIR transfer
- NIR-APNIC transfer
- Inter-NIR transfer
- Seller must be full member of APNIC
- Seller may/may not get more space for some time period
- APNIC to maintain a public log of all transfers
Discussion statistics
---------------------
Number of posts since APNIC 26: 71
Number of people participating in discussions: 10
Summary of discussion on key features of transfer proposals
-----------------------------------------------------------
1. Minimum size: /24 or minimum allocation size in place at time
transfers are implemented:
- There's a possibilty that the APNIC minimum allocation will
become smaller as we get closer to the depletion of the IANA
and APNIC unallocated IPv4 pools.
- In favour of minimum transfer size of /24:
- Not likely to be practical to make the prefix shorter than
a /24.
- /24 is a reasonable size to ensure the smooth transfer of
addresses.
- Choice of route size isn't governed by allocation or
transfer sizes.
- In favour of minimum allocation/assignment size:
- Routing table growth is a serious problem for ISPs.
- It may not match routing reality, but it's better to
start with a shorter prefix first and make it longer if
needed.
- If the community changes its mind about the minimum
transfer size, it's not possible to make the minimum
transfer size shorter if you start with a longer prefix.
- If you define it as a /24, prefixes will be fragmented
that far for sure, including prefixes which are currently
aggregated.
2. Recipient to justify need for addresses:
- In favour of justifying use:
- It doesn't make sense to stop justification just because
the APNIC pool runs out.
- It will prevent hoarding/speculation.
- In favour of not justifying need for addresses:
- We can't expect the address management policy framework to
remain the same after the IPv4 pool runs out.
- It is contrary to transfer goals to restrict transfers.
Adding restrictions could lead to even more underground
transfers.
- It may increase the operational expenses of APNIC and the
NIRs. Members don't want to be burdened by additional fees
as a result of extra work needed by hostmasters to analyse
whether a transfer is justified.
3. Inter-RIR transfer
- There's a risk that networks in wealthier regions could strip
address space from developing regions.
- There's an acknowledgement that this could happen within
the same region as well.
- Such concerns reflect a colonialist perspective.
- Which RIR's policies apply in a transfer if there's a
difference in transfer policies in the regions involved?
4. NIR-APNIC transfer
- There is a desire by the JPNIC community to include NIRs in
the transfer policies.
5. APNIC to maintain a public log of all transfers
- Documentation would be useful for non-technical people in
authenticating a transfer.
- Such a log could help transfer recipients debug routing
issues associated with addresses "contaminated" by previous
holders who may have spammed, etc.
- It was noted that a public log cannot solve all routability
issues.
6. To take effect now or on last /8 received
- It was noted that both prop-050 and prop-067, as written,
would be implemented as soon as practicable after endorsement.
However, it is likely to take a number of months to work out
all the implementation implications.
- It was suggested that while organizations can still obtain
address resources via the current allocation process, the
community shouldn't create demand and support for transfers
which could have significant effects on the general
community. However, it was further commented that a transfer
policy should be adopted soon so procedures can be
established and ready at the time they are needed.
- It was suggested that if the implementation of a transfer
policy was delayed until around the time of exhaustion, a
black market in address transfers would increase.
- If the policy was implemented once IPv4 was exhausted, it was
questioned whether "exhausted" meant exhaustion of the APNIC
pool before or after the final /8 policy was activated (see
http://www.apnic.net/policy/add-manage-policy.html#9.10).
- It was suggested that if APNIC did not have the expertise
to develop mechanisms to ensure transfers were fair and
trustable, APNIC should:
- liaise with experts to find appropriate mechanisms
- keep the community well informed about work being done
using the expertise within their economies, or,
- provide an analysis of how transfers can work without
taking the above measures
- There was a comment that without detailed information about
how the proposed policy would be implemented, it wasn't
possible to support the proposal.
- In response, there was a comment that the need for many
other stakeholders to have time to plan for their response
to this situation, and the limited time now available,
means that the policy process now needs to be resolved
quickly in order to allow others to build upon this
framework with their own policies and actions.
- It was also suggested that APNIC could not be expected to
establish what would be considered fair and trustworthy
within the constraints of a specific economy's own laws,
customs, and governmental frameworks. It was suggested
that economy-specific issues should not hamper policy
making at the APNIC level.
Of the remaining features to be discussed in Thursday's Policy SIG,
there has not been any discussion on the mailing list since APNIC 26.
We'd appreciate some comments on the mailing list, before Thursday, on
the following issues:
7. Inter-NIR transfer
8. Seller must be a full member of APNIC
9. Seller may/may not get more space for a certain time period
