Hi,
"The first ASN remains exempt from any criteria now or in the future"
This is the approach i prefer.
However, the evaluation of subsequent ASNs can consider if the "first ASN"
is/was in use or not, but this shouldn't affect the first ASN's
assignment itself.
Cheers,
Carlos
On Wed, 28 May 2025, Marco Schmidt wrote:
Dear colleagues,
As the discussion phase for this policy proposal continues for one more week,
and in agreement with the authors, I would like to invite
further input on a specific point that has been discussed previously.
The proposal aims to strike a balance by allowing straightforward access to a
first ASN while also helping to prevent unnecessary
requests for additional ASNs without valid technical justification. Currently,
the draft policy states that the first ASN can be
assigned without justification, while additional ASNs would depend on the
fulfilment of criteria and up-to-date documentation for
existing ASNs.
This raises a question: if no justification is required for the first ASN, how
should it be considered when evaluating subsequent
requests?
In preparation for the RIPE NCC?s upcoming impact analysis (if the proposer and
WG co-chairs would decide to move the proposal to the next
phase) and potentially to help the authors for a new version, we would welcome
your views on this matter. There are at least two
possible approaches:
- The first ASN remains exempt from any criteria now or in the future, or
- The first ASN is evaluated retrospectively, for example once an additional
ASN request is made.
Thanks in advance for your input.
Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC
On 21/05/2025 08:57, Rinse Kloek wrote:
Hi,
Agree with Nick. I support this proposal to make first ASN assignment easier to
LIR end end-user.
Also agree that the new policy text could be more general and not too
operational specific.
"any additional ASN must be justified and actively used,"
Rinse
On 20-5-2025 14:24, Nick Hilliard wrote:
Angela Dall'Ara wrote on 06/05/2025 12:50:
We encourage you to review this proposal and send your comments to
[email protected] before 4 June 2025.
The overall aims look ok, but the proposed policy is (in my opinion) too
prescriptive about operational details.
As a general comment about policy creation, policy should aim towards
stating principles about what-should-be-done,
and for the most part should leave the details of how-to-do-it to the
procedure manual. There's a bunch of reasons for
this, not least being able to deal with procedural abuse, bearing in mind
that the implementation time for plugging
policy holes is measured in double-digit months or years.
Zooming out, the policy is:
- first ASN: on request
- subsequent ASNs: stated need
Can I suggest something based on the following text:
2.0 Assignment Criteria
LIRs and End Users may be issued a first Autonomous System Number
(ASN) upon request.
LIRs and End Users may be issued an additional ASN or ASNs if the
LIR or End User can provide documented justification for the unique
external routing policy for the ASN application. The uniqueness of
the routing policy includes the announced prefixes. The LIRs or End
Users must demonstrate fulfillment of the criteria for which the
application was approved within six months of the ASN being
assigned.
The RIPE NCC will assign the AS Number directly to the End User
upon a request properly submitted to the
RIPE NCC, either directly or through a sponsoring LIR. Autonomous
System Numbers may not be sub-assigned.
AS Number assignments are subject to the policies described in the
RIPE NCC document entitled ?Contractual
Requirements for Provider Independent Resource Holders in the RIPE
NCC Service Region."
NB: prohibition on sub-assignment now made explicit.
Nick
-----
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/
-----
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 you
r settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-----
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/
