two changes: One change.
i suspect (though you have not actually specified) that i now need to publish rpsl revealing my relationships,
We. Do. Not. The policy _currently_, meaning, as it is published and implemented _right now_, states: "When requesting an AS Number, the routing policy of the Autonomous System must be provided. The new unique routing policy should be defined in RPSL language, as used in the RIPE Database." This is a change from 2010, implemented by the NCC, to make the policy easier to understand. The proposed change does the following: - Add " to be visible in the GRT" after "When requesting an AS Number", because _technically_ the current policy prohibits any assignment of an ASN that is _not_ used in a GRT visible way, unless you can also provide an RPSL description of that non-visible use. - Add the sentence "Otherwise, documentation on the non-visible purpose, e.g., a reference to the assigned IXP LAN prefixes, must be provided." afterwards, to still require _some_ documentation if you, e.g., want to run an IXP. What you suspect--having to publish RPSL revealing your relationships-- is the case since 2010. That is the reason why we enter (two) ASNs when requesting an ASN. That is the reason why the NCC auto-generates some rather oversimplified RPSL from those two entries. That is the reason why there is a button saying "I want to provide a more complex routing policy in RPSL" when requesting an ASN.
and you propose to remove the requirement for multi-homing. That we do.
how does the regserv person tell from the rpsl how many asns your [singly homed] router needs? one, two, 42? are there a bunch of aut-num:s? an as-set:?
I guess the same way they do now, given that this policy is in place for roughly 15 years. With the additional simplification, that the unique routing policy now explicitly includes the announced prefixes, i.e., if you announce different prefixes and the AS is connected to a third party, that is a rather strong indication: """ - Unique external routing policy of the Autonomous System must be provided. The uniqueness of the routing policy includes the announced prefixes. - Autonomous System must peer with a third party. """
perhaps my confusion is exacerbated by your choosing to use a data description from the '90s, but want to obsolete RFC 1930. :)
See above. We are not 'choosing' this language. We are leaving it in place. And we are not obsoleting RFC1930, given we are not GROW. (Then again, THAT is also not the worst idea. Let me drop an email to that list as well.)
but whether a raspberry pi on decix can have 42 asns because it can be described in rpsl is not a hill i particulatly want to climb, let alone die on.
Yet here we are, standing atop together.
my concern is that policies be simple, clear, understandable, and easily implemented by the operator and by the regserv folk.
I can agree with that. And I can only reiterate that the language you are concerned about has been added by the NCC in 2010 to make the policy more "simple, clear, understandable, and easily implemented by the operator and by the regserv folk"; It is certainly an... interesting... way to simplify, but hey... I'm not judging. With best regards, Tobias