Ekkomagicboy.senju
---------- Forwarded message ---------
Từ: <[email protected]>
Date: 4:53 Th 5, 30 thg 10, 2025
Subject: address-policy-wg Digest, Vol 161, Issue 9
To: <[email protected]>
Send address-policy-wg mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of address-policy-wg digest..."
Today's Topics:
1. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying
the non-transferability of legacy status
(Randy Bush)
2. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying
the non-transferability of legacy status
(Marco Schmidt)
3. Re: Early Feedback Requested on Upcoming Policy Proposal: Clarifying
the non-transferability of legacy status
(Max Emig)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Oct 2025 18:05:53 -0700
From: Randy Bush <[email protected]>
Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming
Policy Proposal: Clarifying the non-transferability of legacy status
To: "Wade, Clara" <[email protected]>
Cc: RIPE address policy WG <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
hi clara
as usual, i am a bit confused; yes, a low bar. have sympathy; you have
been doing this *far* longer than i.
CSTFR sez:
> it takes staff an average of 75 minutes to process each intra-RIR
> transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six
> hours for a legacy transfer between parties with contractual
> relationships with the RIPE NCC
looking at table 7, i think we're comparing "RIPE NCC Region Transfers"
with "Legacy Updates," whatever the heck they are. i suspect that they
are not inter-member transfers of legacy space. as you were on the
CSTF, so i hope you remember what these numbers actually measure and
could please whack me with a clue bat.
Clara:
> legacy status, regardless of whether there is a contractual
> relationship or not, need to undergo a more stringent diligence
> process for transfers that puts additional burden on the NCC
i naïvely assume that the extra diligence of provenance is incurred once
when the space is first registered, e.g. when the holder becomes a
member or it is acquired by a member. and that cost would be a one time
cost. from then on, why is it not just space with a different paint
job?
if member A transfers legacy space to member B why the heck would it
take significantly more effort than if A transfers non-legacy space to
B? can someone from the registry comment?
similarly if A transfers legacy space to B as non-legacy, does it
really require less effort than if B receives it as legacy space?
randy, trying to understand what problems we really need to solve
------------------------------
Message: 2
Date: Wed, 29 Oct 2025 14:16:34 +0100
From: Marco Schmidt <[email protected]>
Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming
Policy Proposal: Clarifying the non-transferability of legacy status
To: Randy Bush <[email protected]>, "Wade, Clara" <[email protected]>
Cc: RIPE address policy WG <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hello Martin, Randy, all
Please allow me to provide a bit more context regarding the processing
times shown in the report of the Charging Scheme Task Force.
First, these figures are averages based on samples and experience in
Registration Services. Actual cases may be completed faster, or
sometimes significantly slower.
Second, the four categories mentioned in the Charging Scheme Task Force
report cover a range of scenarios, and this grouping creates some
cluster effects that can be confusing.
For example, policy transfers of PI resources within the RIPE NCC region
can involve:
- two members,
- a member and a non-member
- two non-members.
Transfers between two members are usually below the average of 75
minutes, while those involving non-members usually take a bit longer,
especially when the receiving party is new to the RIPE NCC and
additional checks are required.
The Legacy Updates group is similar. Randy is correct, updates of legacy
resources under contract between two existing members are typically far
below the 360-minute average, but they represent only a small portion of
this group. The longer processing times mainly occur when a new contract
must be signed with the RIPE NCC or a sponsoring member, or when only
one party has a contractual relationship. In particular, cases where the
offering party has no contract (while the receiving party has or will
have one) can take significantly longer, as the RIPE NCC must perform
extensive due-diligence checks before the Legacy update can be completed.
I hope this clarifies.
Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC
On 29/10/2025 02:05, Randy Bush wrote:
> hi clara
>
> as usual, i am a bit confused; yes, a low bar. have sympathy; you have
> been doing this *far* longer than i.
>
> CSTFR sez:
>> it takes staff an average of 75 minutes to process each intra-RIR
>> transfer ticket, 200 minutes for an inter-RIR or M&A transfer, six
>> hours for a legacy transfer between parties with contractual
>> relationships with the RIPE NCC
> looking at table 7, i think we're comparing "RIPE NCC Region Transfers"
> with "Legacy Updates," whatever the heck they are. i suspect that they
> are not inter-member transfers of legacy space. as you were on the
> CSTF, so i hope you remember what these numbers actually measure and
> could please whack me with a clue bat.
>
> Clara:
>> legacy status, regardless of whether there is a contractual
>> relationship or not, need to undergo a more stringent diligence
>> process for transfers that puts additional burden on the NCC
> i naïvely assume that the extra diligence of provenance is incurred once
> when the space is first registered, e.g. when the holder becomes a
> member or it is acquired by a member. and that cost would be a one time
> cost. from then on, why is it not just space with a different paint
> job?
>
> if member A transfers legacy space to member B why the heck would it
> take significantly more effort than if A transfers non-legacy space to
> B? can someone from the registry comment?
>
> similarly if A transfers legacy space to B as non-legacy, does it
> really require less effort than if B receives it as legacy space?
>
> randy, trying to understand what problems we really need to solve
> -----
> To unsubscribe from this mailing list or change your subscription
options, please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with
the email matching your subscription before you can change your settings.
> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
------------------------------
Message: 3
Date: Wed, 29 Oct 2025 22:53:21 +0100
From: "Max Emig" <[email protected]>
Subject: [address-policy-wg] Re: Early Feedback Requested on Upcoming
Policy Proposal: Clarifying the non-transferability of legacy status
To: Wade, Clara <[email protected]>
Cc: [email protected] <[email protected]>,
[email protected] <[email protected]>
Message-ID: <[email protected]>
Content-Type: multipart/alternative; boundary="----=_=-_OpenGroupware_
org_NGMime-66-1761774801.073449-1------"
Good evening all,
I oppose this policy proposal as it may lead to an increase on out-of-date
data and less RPKI adoption.
However, I would support adding a fee or another disincentive for keeping
legacy status.
Thanks
Max
On 27 October, 2025 17:12 CET, "Wade, Clara via address-policy-wg" <
[email protected]> wrote:
Hello everyone,
Following the suggestion of the RIPE NCC, we are seeking early feedback on
an upcoming policy proposal we currently have in draft status.
As mentioned last week after the Registration Services update from Marco at
the AP-WG session - Peter Hessler and I, members of the now concluded
Charging Scheme Task Force, are drafting a policy proposal to clarify the
non-transferability of legacy status to address the issues of increasing
overhead for the RIPE NCC, increasing market speculation around a scarce
resource and its impact on the adoption of best practices like RPKI. Our
proposal will modify these existing policies:
* “RIPE Resource Transfer Policies” (RIPE-807) with additional
clarifications in the Transfer Restrictions section and the Inter-RIR
policy section. M&A/org restructuring transfers will be explicitly excluded.
* “RIPE NCC Services to Legacy Internet Resource Holders” (RIPE-639) with
modifications to remove the language implying new holders can keep legacy
status after transfer.
For background, legacy status was meant to indicate when an Internet
resource had been directly assigned to the holder by IANA, before the RIRs
were established. As such, ARIN, LACNIC and AFRINIC policies dictate that
IPv4 legacy resources will no longer be regarded as legacy resources after
a policy transfer takes place (excluding M&A transfers). RIPE is the only
RIR that currently allows the recipient of a legacy transfer the ability to
inherit the legacy status that was assigned to the original holder by IANA.
This is currently being used as a loophole by certain actors to opt out of
having a contractual relationship with the RIPE NCC in order to circumvent:
* RIPE registration services fees.
* The 24-month transfer lock that was introduced by this working group to
prevent flipping of scarce resources.
* Needs-based inter-RIR transfer policy utilization requirements in the
case of transfers from another RIR to a recipient of a legacy resource
transfer in the RIPE region.
Following the publication of the Report of the RIPE NCC Charging Scheme
Task Force, the membership learned that the RIPE NCC currently needs to
dedicate a 0.5FTE to process legacy transfers. There are currently around
2,400 legacy resources held by 1,600 holders with no contractual
relationship with the RIPE NCC (neither direct nor via a sponsor). That is
around 40M IPs total or 5% of RIPE IPv4 space. In the last four years, NCC
staff have processed between 370-280 legacy transfers per year, of which
roughly a third do not involve a party with a contractual relationship with
the NCC. Legacy transfers are more labor-intensive than other transfer
types because the due diligence process requires the Registration Services
team to manually source and verify pertaining documentation without the
benefits of the automated processes for standard allocations. Legacy
transfers take an average seven working hours to process when neither party
has a contractual relationship with the NCC (around a third of legacy
transfers), and six working hours to process when the parties have a
contractual relationship with the NCC. If resources lost their legacy
status after a transfer, these would then become standard allocations and
staff could leverage enhanced compliance checks and automated processes to
facilitate any future updates/transfers. These just take 1-3 working hours
to process instead. Given that the task force was deemed out of scope for a
policy change to address this gap, this is being brought to the attention
of the Address Policy Working Group for action.
If there are any concerns, questions or considerations you would like to
bring up before we submit this proposal for discussion in the next week or
two, we would really appreciate hearing from you so we can address these
and/or incorporate them.
Thanks in advance,
Clara Wade
-------------- next part --------------
A message part incompatible with plain text digests has been removed ...
Name: not available
Type: text/html
Size: 9180 bytes
Desc: not available
------------------------------
Subject: Digest Footer
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with
the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
------------------------------
End of address-policy-wg Digest, Vol 161, Issue 9
*************************************************
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
