- address-policy-wg - mailman.ripe.net

Re: [address-policy-wg] address-policy-wg Digest, Vol 34, Issue 10
by Lu 10 Jun '14

10 Jun '14

+1 This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. > On 2014年6月10日, at 下午12:00, address-policy-wg-request(a)ripe.net wrote: > > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > 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: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources (Nick Hilliard) > 2. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources (Dimitri I Sidelnikov) > 3. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources > (Jens Ott - Opteamax GmbH) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 09 Jun 2014 15:40:52 +0100 > From: Nick Hilliard <nick(a)inex.ie> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher <hank(a)efes.iucc.ac.il>, Jo?o Damas > <joao(a)bondis.org>, routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <5395C774.2040403(a)inex.ie> > Content-Type: text/plain; charset=ISO-8859-1 > >> On 09/06/2014 14:53, Hank Nussbacher wrote: >> On a related matter, is it possible currently to setup my aut-num that if >> anyone adds my autnum to their import/export/as-set objects I would receive >> a notification about it? Currently the "notify" field only informs me of >> changes to the specific aut-num, not people who reference my aut-num w/o my >> permission? > > +1 > > I'd also like to see when someone includes my autnums or as-sets in their > as-sets. This has clobbered me in the past with highly unwelcome changes > to production traffic flows. > > Nick > > > > > ------------------------------ > > Message: 2 > Date: Mon, 09 Jun 2014 21:05:39 +0400 > From: Dimitri I Sidelnikov <sid(a)free.net> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <5395E963.5030005(a)free.net> > Content-Type: text/plain; charset=UTF-8 > > I support it. > > 09.06.2014 16:49, Jo?o Damas ?????: >> Dear all, >> at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects. >> >> The observed consensus during the meeting was that: >> >> - the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. >> - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; >> - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted. >> >> We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. >> We propose a 15 day comment period, ending June 24th 2014. >> >> Sander Steffann, Gert D?ring, Rob Evans, Jo?o Damas > > -- > > Kind regards, > --- > D.Sidelnikov > > > > > ------------------------------ > > Message: 3 > Date: Mon, 09 Jun 2014 16:20:54 +0200 > From: Jens Ott - Opteamax GmbH <jo(a)opteamax.de> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher <hank(a)efes.iucc.ac.il>, Jo?o Damas > <joao(a)bondis.org>, routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <3c678c23-376e-4fa7-a0fc-50f3181a4ba9(a)email.android.com> > Content-Type: text/plain; charset=UTF-8 > > > >> On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher <hank(a)efes.iucc.ac.il> wrote: >> At 14:49 09/06/2014 +0200, Jo?o Damas wrote: >>> Dear all, >>> at the recent RIPE 68 meeting there was a discussion about issues >>> concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and >>> possible modifications to the content of routing-related attributes in >> >>> RIPE Database objects, namely the routing policy attributes of autnum >> and >>> as-set objects. >>> >>> The observed consensus during the meeting was that: >>> >>> - the RIPE NCC should not to remove references to recovered ASNs from >>> import and export lines, and neither from as-set objects; routing >> policies >>> are the realm of the object owner and are not related to allocation >> data. >> >> On a related matter, is it possible currently to setup my aut-num that >> if >> anyone adds my autnum to their import/export/as-set objects I would >> receive >> a notification about it? Currently the "notify" field only informs me >> of >> changes to the specific aut-num, not people who reference my aut-num >> w/o my >> permission? >> >> If this is not feasible with the system today, would it be possible to >> add >> this feature? I'll explain the rationale: we have recently discovered >> that >> hostile aut-num's that intend to perform a BGP hijack, will add the >> victims >> aut-num to their routing policy or to their unsuspecting upstream. >> This >> policy is then picked up as legitimate and propogated. By having a >> "notify-on-policy" email address field, I would be able to quickly see >> who >> is planning on hijacking my IP ranges. >> >> Comments? >> > > I fully support your point. I also observed what you told here. Therefore we enhanced our Prefixlist-Generator doing counter-checks if an import statement also have a corresponding export - statement. Result is, that the prefixlist generation takes about 10 times longer, our caching database grew by factor eight (as we now also need to cache autnum objects of child- and grandchild-objects) ... > > So a "notify-on-policy" - how you called it - would be very appreciated! > > BR Jens >> Thanks, >> Hank >> >> >> >> >> >> !DSPAM:637,5395bdec188062364380171! > > -- > Jens Ott > Opteamax GmbH > Simrockstr. 4G > 53619 Rheinbreitbach > Tel. +49 2224 969500 > Email: jo(a)opteamax.de > > > > End of address-policy-wg Digest, Vol 34, Issue 10 > *************************************************

3 2

Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources
by João Damas 09 Jun '14

09 Jun '14

Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects. The observed consensus during the meeting was that: - the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted. We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. We propose a 15 day comment period, ending June 24th 2014. Sander Steffann, Gert Döring, Rob Evans, João Damas

7 7

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Jan Ingvoldstad 07 Jun '14

07 Jun '14

On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > https://www.ripe.net/ripe/policies/proposals/2014-05 I like this proposed policy, it is very reasonable, and seems to have addressed the overlying concerns with inter-RIR transfers. I have a comment regarding the second argument against the policy, "*The proposal will re-introduce operational needs justification, if any RIR insists on this, in order to effect certain transfers*." I don't think this is an argument against the policy itself, but it is a concern that RIPE NCC needs to address when guiding LIRs in the transfer process. In other words: yes, operational needs justification under any other RIR's "jurisdiction" is a concern, but it is not within RIPE's powers to do anything about it, other than help RIPE's LIRs make the best of it when transferring resources. -- Jan

6 9

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Nigel Titley 07 Jun '14

07 Jun '14

On 03/06/14 14:13, Marco Schmidt wrote: > Dear colleagues, > > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-05 > > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 2 July 2014. > > Speaking as myself and myself only. Much as I disliked the woolly language of its predecessor I think this version is crisp and clean. Once the already mentioned nits about LIR/Member/Organisation/Stonecutter are sorted out, and with a possible fix to 2014-01, as mentioned by Carsten, I think this would be a good addition to RIPE region policy. Nigel

1 0

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by sandrabrown＠ipv4marketgroup.com 06 Jun '14

06 Jun '14

On Thu, Jun 5, 2014 at 2:25 PM, Jan Ingvoldstad <frettled(a)gmail.com> wrote: > On Thu, Jun 5, 2014 at 7:30 PM, Scott Leibrand <scottleibrand(a)gmail.com> > wrote: > >> Overall, this policy looks good to me. However, I believe there is one >> problem with the text. The language regarding recipients in other regions >> requires that the recipient be an LIR. However, the transfer policies of >> the other regions do not make any such distinction. Therefore, I believe it >> would be more appropriate to use the word organization instead of LIR when >> referring to recipients in other regions. >> > > That's a fair point. > > -When Internet number resources are transferred to another RIR, the RIPE > NCC will work with the destination RIR to allow the transfer to the > receiving LIR. > +When Internet number resources are transferred to another RIR, the RIPE > NCC will work with the destination RIR to allow the transfer to the > receiving organization. > > Like that? > Yes. ________________________ I am in agreement with Scott and Jan on this revision..."LIR" becomes "receiving organization". Thank you to you both. - Sandra Also: -Address space may only be re-allocated to another LIR that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. +Address space may only be re-allocated to another organization that is a member of an RIR that allows transfers. The block that is to be re-allocated must not be smaller than the minimum allocation block size at the time of re-allocation. However, that may have implications for intra-RIR transfers, so you might need to separate out the two cases if you don't want to imply that non-LIR organizations can receive transfers in the RIPE region. Maybe something like "to another LIR in the RIPE region, or an organization that is a member of an RIR that allows transfers." -Scott _______________ Replacing "LIR" with "organization" should also be ok within the context of RIPE Transfer Policy. - Sandra _________________

1 0

Re: [address-policy-wg] [sig-policy] RIPE Policy Text for Inter-RIR Transfers - 2014-05
by Sander Steffann 05 Jun '14

05 Jun '14

Hi John, Op 5 jun. 2014, om 16:54 heeft John Curran <jcurran(a)arin.net> het volgende geschreven: > On Jun 5, 2014, at 7:24 AM, Skeeve Stevens <skeeve(a)eintellegonetworks.com> wrote: > >> Here is the policy text being proposed in RIPE for Inter-RIR Transfers - 2014-05 >> >> https://www.ripe.net/ripe/policies/proposals/2014-05 I think this policy should be discussed on the RIPE address policy mailing list. Feedback in other places does not have much effect ;) CC'ing APWG now. > From the proposed policy text (with labels added for reference) - > > (a) > When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. > > (b) > When Internet number resources are transferred from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR. > > (c) > If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources. > > The intent of the above text may not be clear with respect to resources coming from > another region (b) which are presently "legacy" resources in that region, i.e. it might > be possible to reasonable argue that the policy intent is (b) or (c) for that case. When receiving resources from another region then (b) will always apply. At a minimum the RIRs have to work together to keep the databases consistent. If the originating RIR tells the RIPE NCC that those resources are legacy resources then the receiver can choose to have them treated as legacy resources in the RIPE region as well. But the policy does not allow conversion in the other direction. If ARIN would tell the RIPE NCC that the resources are *not* legacy resources (not ever, or not anymore) then they can not not be treated as legacy after transfer. > (Not a comment in favor or opposition to the proposed policy; just seeking clarity so > that implementation, if it were adopted, has solid alignment with the policy intent.) Thanks. Please continue the discussion on the RIPE APWG list ;) Cheers! Sander

1 0

2012-02 Policy Proposal Withdrawn (Policy for Inter-RIR transfers of IPv4 address space)
by Marco Schmidt 03 Jun '14

03 Jun '14

Dear colleagues, The proposal 2012-02, "Policy for Inter-RIR transfers of IPv4 address space" has been withdrawn. It is now archived and can be found at: https://www.ripe.net/ripe/policies/proposals/2012-02 Reason for withdrawal: The proposer of 2012-02 proposed 2014-05, a new inter-RIR transfer policy. 2014-05 focuses on being aligned with internal resource transfers as well as being more cohesive with the policies of other RIRs. As a consequence, the proposer decided to withdraw 2012-02. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Marco Schmidt 03 Jun '14

03 Jun '14

Dear colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-05 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 2 July 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-03 Draft Document and Impact Analysis will be produced (Remove Multihoming Requirement for AS Number Assignments)
by Marco Schmidt 02 Jun '14

02 Jun '14

Dear colleagues, The discussion period for the proposal described in 2014-03, "Remove Multihoming Requirement for AS Number Assignments" has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-03 Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-02 Draft Document and Impact Analysis will be produced (Allow IPv4 PI transfer)
by Marco Schmidt 30 May '14

30 May '14

Dear colleagues, The discussion period for the proposal described in 2014-02, "Allow IPv4 PI transfer" has ended. A draft document and the RIPE NCC Impact Analysis will now be prepared for review. We will publish the documents shortly and we will make an announcement. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-02 Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0