On Thu, Sep 03, 2015 at 02:36:12PM +0200, Erik Bais wrote:
A holding period for ASN16 is a material change in assignment
policy and should be in a separate proposal, not hidden in a (in
itself valuable) transfer policy aggregation proposal.
ASN's, it was stated in Amsterdam during the AP WG policy discussion that
leaving out transfer restrictions in the policy for ASn's was a bit too far
and it was suggested ( at the mic ) to look at almost depleted or scarce
resources to have transfer restrictions as we currently have in policy for
IPv4. By taking the wording as we have in front of us, it points out what
it means, the intention is clear ... and it will leave the policy by itself
accurate if 16 bit AS numbers have depleted .. without having to go over a
re-writing of the policy here ...
Just because it was stated at the meeting doesn't mean it
shouldn't be discussed here. I can't be the only one who wasn't
there and doesn't know what was said there.
Both IPv6 and AS numbers have in the current policy no transfer
restrictions ... I don't see a benefit to (have it) introduce
for IPv6, but after the discussion in Amsterdam in the room, a
restriction for 16-bit ASn's was desired. And that is also why
it is currently here. This is not a 180 degree change of
direction as it would make it more in line with other number
resources .. 16-bit AS is in a similar state as IPv4.. it's
gone.. get over it .. move on .. IPv6 is the new way, same as
with 32-bit ASN's.. no restrictions..
I've not even a problem with the change, in fact I didn't
register that ASNs were even transferrable until I re-read
-638 just now.
As for that, I think ASN(16) *should* be transferred
a) only together with IP resources
b) if uninterrupted routeability is required.
I'm not hung up on this though, it won't affect my non-/support
either way.
I don't think we have to re-hash all discussions as done in
Elvis his proposal, which was viewed by the community as
required and not strict enough as it didn't included M&A's..
That's not what I remember. I remember a few people shouting very
loudly and repeatedly and no discussion as it was off-topic for
that proposal. And now we don't need an actually discussion?
Mind, if yelling loudly is how you get policy made in the RIPE
community, rest assured I can yell VERY loudly. I can, in fact,
even automate the yelling if need be.
Is anything going to change based on the proposal in order to
make do a M&A. - No.
I have to, reluctantly, agree with you here but it took me a
while to find the relevant text in the NCC documentation.
I would sleep easier though if it was clearly spelled out in this
proposal that M&A are governed by ripe-648 and not by this
transfer policy. ripe-648 doesn't say this clearly either but
implies it in ss. 2.0 and 3.0
Will it remove the loophole of speculators, buying resources via
M&A and transferring those directly ? Yes. ( This is currently
possible and not in line with the original intent of the
transfer policy restrictions of the initial IPv4 transfer policy
AND the amendment to that by 2015-01.. )
It still allows someone to amass "more than their fair /22"
by buying other businesses but this is something outside the
purview of RIPE policy and should certainly remain so.
Business that have a legitimate reason for performing a M&A, can
still do so. The only restriction is that they can't re-transfer
( same as with new LIR now can't with the newly allocated /22's
... ) within 24 months.
Just for the record, it is neither up to the NCC nor the RIPE
community to decide whether a merger or an acquisition is
"legitimate".
I think that by clearly pointing it out, during the discussion
as it was not questioned during the initial reviews, it shows
that it was not the intention of hiding anything ... The fact
that people may not understand what they are reading because
they don't have the complete overview of all policy implication
changes is something that we can avoid ... It is not the
intention of misleading people or trying to hide anything.. it
is the other way around .. as I specifically pointed out to
think about something that was missed.
IMO, it's too easy to just look at it as a much needed and
necessary aggregation of transfer policy in one document
(and I hope the whole community agrees that we owe you some
beer for going through the effort)
and ignore the actual *changes* to the policies...
By clearly pointing out what certain text actually means and
creating an 'Ahh ha' reflex ... 'Is that what the result is ...
'. It means that people learned something they didn't knew
before.. or just realized something that they missed.. Just
like that you didn't knew that there are still specific usages
for IPv4 for which IP space is specifically reserved (in the
final /8) that are specifically excluded from the transfers ..
as they MUST be returned..
And, as it happens, the policy isn't actually very clear on this
(except in the specific case of an IXP getting a larger
assignment!) and may require more careful ring-fencing of the IXP
pool.
I hope I gave some additional insight in the actual changes and
my reasoning behind it and as this is a policy that will create
a general document across all resources ( hopefully for a long
time to come..) it will have some changes and I hope that the
document will reflect the intention of the community from all
discussions that we already had in the past on the topics.
Granted, but I'd prefer it in the future if such an aggregation
would not incorporate any material changes to the policies
involved (should then also pass quickly and without much debate)
and any changes would then be processed in a separate proposal.
I guess you realised this, as those changes are actually in the
rationale *against* this proposal ;)
That said, I now see no reason not to support the proposal with
the addition of the statement that M&A procedure is not affected
by this.
rgds,
Sascha Luck
