Hi,
I'd like to put another idea into this policy, as I just ran into this
issue.
But before proposing it, I want to point out that I really like the 24
month hold-period before transfer in general to reduce the effect of
"Create LIR - get /22 - sell /22 - close LIR".
Still I would like to
Purely as a point of information, I think its worth remembering that 32 bit
ASN cannot be used in currently specified BGP4 in communities, because its
a 32 bit field defined as two 16 bit halves. I believe there is work afoot
in IETF to fix this. I don't have concrete details.
Therefore there
This has come up several times before. There is support for asn32s in bgp
extended communities: you need the "Transitive Four-Octet AS-Specific
Extended Community" values from here:
http://www.iana.org/assignments/bgp-extended-communities
... and you need to hope that this is supported on your
Right. I mussed up some details. The substance remains: if you are exposed
to economics which depends on the use of communities for TE, and cannot
influence external agents you do BGP with to support extended communities,
then you may decide you need a 16bit ASN, and so they have inherent value
to
On 03/09/2015 18:09, Sascha Luck [ml] wrote:
> 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.
please don't: rfc7282 works much better.
Nick
On Wed, Sep 02, 2015 at 02:48:07PM +0100, Nick Hilliard wrote:
649 section 6.1 says:
--
This space will be used to run an IXP peering LAN; other uses are forbidden.
--
I actually read that as "This space *as assigned to this
end-user*[...]"
Does IXP space come out of a separate pool from any
On Wed, Sep 02, 2015 at 12:37:22AM +0200, Erik Bais wrote:
To clarify here ... although all types of number resources can
be transferred.. ( AS, IPv4, IPv6 ) there are some specific
resources ( like v4 for IXP usage ) are not allowed to be
transferred and MUST be returned..
On 31/08/2015 23:18, Sascha Luck [ml] wrote:
> Can't have it both ways ;p As for myself, I would like to see
> some clarification on this myself.
have cake, eat cake. As you point out, I changed my mind mid-email. It
happens.
>> asn transfer policy: added "scarce resources ... cannot be
Hi Nick,
>> You can find the full proposal at:
>>
>>https://www.ripe.net/participate/policies/proposals/2015-04
>first of all, a large thank-you for handling this policy aggregation.
Let's see if we can get it across the room :)
And thank you for the diff ... I'm a bit behind on my mail
Hi James,
> Couple of questions/comments...
> From 1.0
> Shouldn't the scope be explicit as to what is/isn't included
It states what is included ... are you missing anything specific ?
> From 2.1
> "Transfers can be on a permanent or non-permanent basis."
> How is this going to be
> You can find the full proposal at:
>
> https://www.ripe.net/participate/policies/proposals/2015-04
one more issue:
> The rules for Internet number resource transfers (including legacy
> resources) to and from the RIPE NCC service region (often referred to as
> inter-RIR transfers)
It's
On Mon, Aug 31, 2015 at 10:22:09PM +0100, Nick Hilliard wrote:
first of all, a large thank-you for handling this policy aggregation. This
will make things a lot easier for organisations to understand how RIPE
transfer policy works. Although policy reworking like this is completely
thankless,
Hi,
On Fri, Aug 14, 2015 at 11:54:04AM +0200, Marco Schmidt wrote:
A new RIPE Policy Proposal, RIPE Resource Transfer Policies has been
made and is now available for discussion.
To add a bit of info: this is the unified transfer policy Erik promised,
that is a new document that has the
Dear colleagues,
A new RIPE Policy Proposal, RIPE Resource Transfer Policies has been
made and is now available for discussion.
The goal of this proposal is to create a single document with all
relevant information regarding the transfer of Internet number resources.
You can find the full
14 matches
Mail list logo
