From mschmidt at ripe.net Mon Jun 2 15:05:24 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 02 Jun 2014 15:05:24 +0200 Subject: [address-policy-wg] 2014-03 Draft Document and Impact Analysis will be produced (Remove Multihoming Requirement for AS Number Assignments) Message-ID: 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 From mschmidt at ripe.net Tue Jun 3 15:13:44 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 03 Jun 2014 15:13:44 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: 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 before 2 July 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Tue Jun 3 15:33:52 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 03 Jun 2014 15:33:52 +0200 Subject: [address-policy-wg] 2012-02 Policy Proposal Withdrawn (Policy for Inter-RIR transfers of IPv4 address space) Message-ID: 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 From frettled at gmail.com Thu Jun 5 10:28:37 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 5 Jun 2014 10:28:37 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at v4escrow.net Thu Jun 5 12:36:28 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Thu, 05 Jun 2014 12:36:28 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <5390482C.50400@v4escrow.net> Hi, I also like the new proposed text. It addresses all of the concerns I had with the previous one and this time it is very clean and simple. +1 from me. cheers, elvis On 05/06/14 10:28, Jan Ingvoldstad wrote: > On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt > 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 -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From scottleibrand at gmail.com Thu Jun 5 19:30:39 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 5 Jun 2014 10:30:39 -0700 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <5390482C.50400@v4escrow.net> References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> Message-ID: 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. Scott (speaking only for myself) > On Jun 5, 2014, at 3:36 AM, Elvis Daniel Velea wrote: > > Hi, > > I also like the new proposed text. It addresses all of the concerns I had with the previous one and this time it is very clean and simple. > > +1 from me. > > cheers, > elvis > >> On 05/06/14 10:28, Jan Ingvoldstad wrote: >> On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt 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 > > > -- > > Elvis Daniel Velea > > Chief Business Analyst > > Email: elvis at V4Escrow.net > US Phone: +1 (702) 475 5914 > EU Phone: +3 (161) 458 1914 > Recognised IPv4 Broker/Facilitator in: > > <1.png> > This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Thu Jun 5 19:37:34 2014 From: sander at steffann.nl (Sander Steffann) Date: Thu, 5 Jun 2014 19:37:34 +0200 Subject: [address-policy-wg] [sig-policy] RIPE Policy Text for Inter-RIR Transfers - 2014-05 In-Reply-To: <47B781F0-97A4-4358-9ADA-3BE3D92D182B@arin.net> References: <47B781F0-97A4-4358-9ADA-3BE3D92D182B@arin.net> Message-ID: Hi John, Op 5 jun. 2014, om 16:54 heeft John Curran het volgende geschreven: > On Jun 5, 2014, at 7:24 AM, Skeeve Stevens 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 From frettled at gmail.com Thu Jun 5 23:25:53 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Thu, 5 Jun 2014 23:25:53 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> Message-ID: On Thu, Jun 5, 2014 at 7:30 PM, Scott Leibrand 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? -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Fri Jun 6 00:58:11 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 5 Jun 2014 15:58:11 -0700 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> Message-ID: On Thu, Jun 5, 2014 at 2:25 PM, Jan Ingvoldstad wrote: > On Thu, Jun 5, 2014 at 7:30 PM, Scott Leibrand > 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandrabrown at ipv4marketgroup.com Fri Jun 6 03:34:11 2014 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Thu, 05 Jun 2014 18:34:11 -0700 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: <20140605183411.ec289651d84890fcbef5f195936e1217.9c491aa989.wbe@email17.secureserver.net> On Thu, Jun 5, 2014 at 2:25 PM, Jan Ingvoldstad wrote: > On Thu, Jun 5, 2014 at 7:30 PM, Scott Leibrand > 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 _________________ From gert at space.net Fri Jun 6 11:44:23 2014 From: gert at space.net (Gert Doering) Date: Fri, 6 Jun 2014 11:44:23 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> Message-ID: <20140606094423.GW46558@Space.Net> Hi, On Thu, Jun 05, 2014 at 03:58:11PM -0700, Scott Leibrand wrote: > 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." All RIPE members are LIRs. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From scottleibrand at gmail.com Fri Jun 6 12:03:43 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 6 Jun 2014 03:03:43 -0700 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <20140606094423.GW46558@Space.Net> References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> <20140606094423.GW46558@Space.Net> Message-ID: > On Jun 6, 2014, at 2:44 AM, Gert Doering wrote: > > Hi, > >> On Thu, Jun 05, 2014 at 03:58:11PM -0700, Scott Leibrand wrote: >> 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." > > All RIPE members are LIRs. Oh, good point. We actually end up with the same problem with the word "member" that occurs with the word "LIR". End user organizations in other regions can receive address space via transfer without being members. This text would exclude them from inter-RIR transfers from the RIPE region. Maybe "to another LIR in the RIPE region, or an organization in the service region of another RIR that allows transfers"? -Scott From gert at space.net Fri Jun 6 13:34:24 2014 From: gert at space.net (Gert Doering) Date: Fri, 6 Jun 2014 13:34:24 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <20140606094423.GW46558@Space.Net> References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> <20140606094423.GW46558@Space.Net> Message-ID: <20140606113424.GA9984@Space.Net> Hi, On Fri, Jun 06, 2014 at 11:44:23AM +0200, Gert Doering wrote: > All RIPE members are LIRs. RIPE *NCC* members, to be precise. "RIPE" is "the community", and all of us are members of the RIPE community :-) - so while it was clear from the context what I was trying to say, it was still technically wrong. Sorry for that. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ripe-wgs.cs at schiefner.de Sat Jun 7 11:33:26 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Sat, 07 Jun 2014 11:33:26 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> Message-ID: <5392DC66.8080901@schiefner.de> Just as a heads-up: On 06.06.2014 00:58, Scott Leibrand wrote: > [...] 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. Given the support that 2014-01 has seen so far, you may want to think this paragraph without its second sentence; cf. items e) & f) of https://www.ripe.net/ripe/policies/proposals/2014-01 - and see whether it still makes sense to you. Cheers, -C. From nigel at titley.com Sat Jun 7 11:52:06 2014 From: nigel at titley.com (Nigel Titley) Date: Sat, 07 Jun 2014 10:52:06 +0100 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: <5392E0C6.3020208@titley.com> 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 > 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 From randy at psg.com Sat Jun 7 18:44:20 2014 From: randy at psg.com (Randy Bush) Date: Sat, 07 Jun 2014 09:44:20 -0700 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <20140606113424.GA9984@Space.Net> References: <538dca68.646bb40a.6f23.56c8SMTPIN_ADDED_MISSING@mx.google.com> <5390482C.50400@v4escrow.net> <20140606094423.GW46558@Space.Net> <20140606113424.GA9984@Space.Net> Message-ID: > "RIPE" is "the community", and all of us are members of the RIPE > community :-) we have always been at war with eastasia From joao at bondis.org Mon Jun 9 14:49:33 2014 From: joao at bondis.org (=?iso-8859-1?Q?Jo=E3o_Damas?=) Date: Mon, 9 Jun 2014 14:49:33 +0200 Subject: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources Message-ID: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at inex.ie Mon Jun 9 15:04:08 2014 From: nick at inex.ie (Nick Hilliard) Date: Mon, 09 Jun 2014 14:04:08 +0100 Subject: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> References: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> Message-ID: <5395B0C8.9040603@inex.ie> On 09/06/2014 13:49, Jo?o Damas wrote: > 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. wfm. Nick From job at instituut.net Mon Jun 9 15:09:15 2014 From: job at instituut.net (Job Snijders) Date: Mon, 9 Jun 2014 15:09:15 +0200 Subject: [address-policy-wg] [routing-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> References: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> Message-ID: <20140609130915.GH54930@Eleanor.local> On Mon, Jun 09, 2014 at 02:49:33PM +0200, Jo?o Damas wrote: > 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. I like it. Kind regards, Job From marty at akamai.com Mon Jun 9 15:50:24 2014 From: marty at akamai.com (Hannigan, Martin) Date: Mon, 9 Jun 2014 09:50:24 -0400 Subject: [address-policy-wg] [routing-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <20140609130915.GH54930@Eleanor.local> References: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> <20140609130915.GH54930@Eleanor.local> Message-ID: <60A7591A-C6E9-4183-933C-2203988629AE@akamai.com> On Jun 9, 2014, at 9:09 AM, Job Snijders wrote: > On Mon, Jun 09, 2014 at 02:49:33PM +0200, Jo?o Damas wrote: >> 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. > > Same, this works. Best, -M< -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hank at efes.iucc.ac.il Mon Jun 9 15:53:15 2014 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 09 Jun 2014 16:53:15 +0300 Subject: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> Message-ID: <5.1.1.6.2.20140609164216.053c3e98@efes.iucc.ac.il> 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? Thanks, Hank From ripe at opteamax.de Mon Jun 9 16:23:03 2014 From: ripe at opteamax.de (Opteamax RIPE-Team) Date: Mon, 09 Jun 2014 16:23:03 +0200 Subject: [address-policy-wg] Fwd: Re: Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <3c678c23-376e-4fa7-a0fc-50f3181a4ba9@email.android.com> References: <3c678c23-376e-4fa7-a0fc-50f3181a4ba9@email.android.com> Message-ID: -------- Urspr?ngliche Nachricht -------- Von: Jens Ott - Opteamax GmbH Gesendet: 9. Juni 2014 16:20:54 MESZ An: Hank Nussbacher , "Jo?o Damas" , routing-wg at ripe.net, address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher 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 at opteamax.de -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Mon Jun 9 16:40:52 2014 From: nick at inex.ie (Nick Hilliard) Date: Mon, 09 Jun 2014 15:40:52 +0100 Subject: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <5.1.1.6.2.20140609164216.053c3e98@efes.iucc.ac.il> References: <5.1.1.6.2.20140609164216.053c3e98@efes.iucc.ac.il> Message-ID: <5395C774.2040403@inex.ie> 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 From sid at free.net Mon Jun 9 19:05:39 2014 From: sid at free.net (Dimitri I Sidelnikov) Date: Mon, 09 Jun 2014 21:05:39 +0400 Subject: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> References: <3975E1C4-48AF-4B32-A835-9BC601177A91@bondis.org> Message-ID: <5395E963.5030005@free.net> 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 From jo at opteamax.de Mon Jun 9 16:20:54 2014 From: jo at opteamax.de (Jens Ott - Opteamax GmbH) Date: Mon, 09 Jun 2014 16:20:54 +0200 Subject: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources In-Reply-To: <5.1.1.6.2.20140609164216.053c3e98@efes.iucc.ac.il> References: <5.1.1.6.2.20140609164216.053c3e98@efes.iucc.ac.il> Message-ID: <3c678c23-376e-4fa7-a0fc-50f3181a4ba9@email.android.com> On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher 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 at opteamax.de From h.lu at anytimechinese.com Tue Jun 10 12:51:29 2014 From: h.lu at anytimechinese.com (Lu) Date: Tue, 10 Jun 2014 12:51:29 +0200 Subject: [address-policy-wg] address-policy-wg Digest, Vol 34, Issue 10 In-Reply-To: References: Message-ID: +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 at ripe.net wrote: > > Send address-policy-wg mailing list submissions to > address-policy-wg at 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 at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at 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 > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher , Jo?o Damas > , routing-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: <5395C774.2040403 at 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 > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: routing-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: <5395E963.5030005 at 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 > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher , Jo?o Damas > , routing-wg at ripe.net, address-policy-wg at ripe.net > Message-ID: <3c678c23-376e-4fa7-a0fc-50f3181a4ba9 at email.android.com> > Content-Type: text/plain; charset=UTF-8 > > > >> On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher 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 at opteamax.de > > > > End of address-policy-wg Digest, Vol 34, Issue 10 > ************************************************* From sander at steffann.nl Tue Jun 10 21:18:16 2014 From: sander at steffann.nl (Sander Steffann) Date: Tue, 10 Jun 2014 22:18:16 +0300 Subject: [address-policy-wg] address-policy-wg Digest, Vol 34, Issue 10 In-Reply-To: References: Message-ID: <61738BD9-7CC4-46C4-8865-0BCD62812A2A@steffann.nl> Hi Lu, > 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. Euhm, you do realise you're sending this message to a mailing list that is publicly archived etc, right? ;) RIPE working group mailing lists do not support 'protected from disclosure'. Cheers, Sander From h.lu at anytimechinese.com Tue Jun 10 21:22:33 2014 From: h.lu at anytimechinese.com (Lu Heng) Date: Tue, 10 Jun 2014 22:22:33 +0300 Subject: [address-policy-wg] address-policy-wg Digest, Vol 34, Issue 10 In-Reply-To: <61738BD9-7CC4-46C4-8865-0BCD62812A2A@steffann.nl> References: <61738BD9-7CC4-46C4-8865-0BCD62812A2A@steffann.nl> Message-ID: Sorry...it was an automatic thing added to my Email...and in fact it was the short version...my lawyer insist everyone else in the company even put a much longer version:) Have no idea what this thing meant for though. Will take note and delete it next time I publish something in mailing list, thanks for the advice:) On Tue, Jun 10, 2014 at 10:18 PM, Sander Steffann wrote: > Hi Lu, > >> 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. > > Euhm, you do realise you're sending this message to a mailing list that is publicly archived etc, right? ;) RIPE working group mailing lists do not support 'protected from disclosure'. > > Cheers, > Sander > From sander at steffann.nl Mon Jun 16 11:29:29 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 16 Jun 2014 11:29:29 +0200 Subject: [address-policy-wg] Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4) Message-ID: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> Dear working group, The working group chairs have decided to send policy proposal 2014-01, Abandoning the Minimum Allocation Size for IPv4, to Last Call. During the discussion phase there was already general support for this policy proposal. Some people asked for the minimum size of sub-allocations too be included in this policy proposal as well. This was done in version 2 of the proposal text. After going to the review phase the feedback was all positive, with 8 people explicitly stating their support: - Tore Anderson - Jan Ingvoldstad - Piotr Strzyzewski - Sascha Luck - Jens Ott - George Giannousopoulos - Andreas Larsen - Sebastian Wiesinger The announcement of the start of the review phase was sent out on the 15th of May, and all messages indicating support came in immediately after. Since then the mailing list has been quiet about 2014-01, which we see as a sign of consensus. The formal Last Call announcement will be sent to the appropriate lists by our incredibly helpful PDO, Marco Schmidt. Cheers, Gert and Sander Your APWG chairs From elvis at v4escrow.net Mon Jun 16 11:55:10 2014 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Mon, 16 Jun 2014 11:55:10 +0200 Subject: [address-policy-wg] Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> References: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> Message-ID: <539EBEFE.3050600@v4escrow.net> Hi, you have my support as well. cheers, elvis On 16/06/14 11:29, Sander Steffann wrote: > Dear working group, > > The working group chairs have decided to send policy proposal 2014-01, Abandoning the Minimum Allocation Size for IPv4, to Last Call. > > During the discussion phase there was already general support for this policy proposal. Some people asked for the minimum size of sub-allocations too be included in this policy proposal as well. This was done in version 2 of the proposal text. > > After going to the review phase the feedback was all positive, with 8 people explicitly stating their support: > - Tore Anderson > - Jan Ingvoldstad > - Piotr Strzyzewski > - Sascha Luck > - Jens Ott > - George Giannousopoulos > - Andreas Larsen > - Sebastian Wiesinger > > The announcement of the start of the review phase was sent out on the 15th of May, and all messages indicating support came in immediately after. Since then the mailing list has been quiet about 2014-01, which we see as a sign of consensus. > > The formal Last Call announcement will be sent to the appropriate lists by our incredibly helpful PDO, Marco Schmidt. > > Cheers, > Gert and Sander > Your APWG chairs > > -- Elvis Daniel Velea Chief Business Analyst Email: elvis at V4Escrow.net US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: From mschmidt at ripe.net Mon Jun 16 14:43:33 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 16 Jun 2014 14:43:33 +0200 Subject: [address-policy-wg] 2014-01 Last Call for Comments (Abandoning the Minimum Allocation Size for IPv4) Message-ID: Dear colleagues, The proposal described in 2014-01, "Abandoning the Minimum Allocation Size for IPv4", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 15 July 2014 and must be supported by an explanation. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-01 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 15 July 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From ebais at a2b-internet.com Mon Jun 16 17:33:33 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 16 Jun 2014 17:33:33 +0200 Subject: [address-policy-wg] Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> References: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> Message-ID: <009a01cf8978$5b91b3f0$12b51bd0$@a2b-internet.com> Support +1 -----Oorspronkelijk bericht----- Van: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Namens Sander Steffann Verzonden: maandag 16 juni 2014 11:29 Aan: address-policy-wg at ripe.net Working Group Onderwerp: [address-policy-wg] Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4) Dear working group, The working group chairs have decided to send policy proposal 2014-01, Abandoning the Minimum Allocation Size for IPv4, to Last Call. During the discussion phase there was already general support for this policy proposal. Some people asked for the minimum size of sub-allocations too be included in this policy proposal as well. This was done in version 2 of the proposal text. After going to the review phase the feedback was all positive, with 8 people explicitly stating their support: - Tore Anderson - Jan Ingvoldstad - Piotr Strzyzewski - Sascha Luck - Jens Ott - George Giannousopoulos - Andreas Larsen - Sebastian Wiesinger The announcement of the start of the review phase was sent out on the 15th of May, and all messages indicating support came in immediately after. Since then the mailing list has been quiet about 2014-01, which we see as a sign of consensus. The formal Last Call announcement will be sent to the appropriate lists by our incredibly helpful PDO, Marco Schmidt. Cheers, Gert and Sander Your APWG chairs From zsako at iszt.hu Tue Jun 17 09:20:28 2014 From: zsako at iszt.hu (Janos Zsako) Date: Tue, 17 Jun 2014 09:20:28 +0200 Subject: [address-policy-wg] Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> References: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> Message-ID: <539FEC3C.3060707@iszt.hu> Dear all, > After going to the review phase the feedback was all positive, with 8 people explicitly stating their support: > - Tore Anderson > - Jan Ingvoldstad > - Piotr Strzyzewski > - Sascha Luck > - Jens Ott > - George Giannousopoulos > - Andreas Larsen > - Sebastian Wiesinger I had supported the proposal in the initial discussion phase, but have not stated again my support in the review phase, so I do it now: +1. Best regards, Janos > The announcement of the start of the review phase was sent out on the 15th of May, and all messages indicating support came in immediately after. Since then the mailing list has been quiet about 2014-01, which we see as a sign of consensus. > > The formal Last Call announcement will be sent to the appropriate lists by our incredibly helpful PDO, Marco Schmidt. > > Cheers, > Gert and Sander > Your APWG chairs From stolpe at resilans.se Tue Jun 17 15:09:25 2014 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 17 Jun 2014 15:09:25 +0200 (CEST) Subject: [address-policy-wg] Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4) In-Reply-To: <009a01cf8978$5b91b3f0$12b51bd0$@a2b-internet.com> References: <5E5D16E4-E894-4783-AFC6-09D357F7B5B3@steffann.nl> <009a01cf8978$5b91b3f0$12b51bd0$@a2b-internet.com> Message-ID: +1. On Mon, 16 Jun 2014, Erik Bais wrote: > Support +1 > > -----Oorspronkelijk bericht----- > Van: address-policy-wg-bounces at ripe.net > [mailto:address-policy-wg-bounces at ripe.net] Namens Sander Steffann > Verzonden: maandag 16 juni 2014 11:29 > Aan: address-policy-wg at ripe.net Working Group > Onderwerp: [address-policy-wg] Going to last call: 2014-01 (Abandoning the > Minimum Allocation Size for IPv4) > > Dear working group, > > The working group chairs have decided to send policy proposal 2014-01, > Abandoning the Minimum Allocation Size for IPv4, to Last Call. > > During the discussion phase there was already general support for this > policy proposal. Some people asked for the minimum size of sub-allocations > too be included in this policy proposal as well. This was done in version 2 > of the proposal text. > > After going to the review phase the feedback was all positive, with 8 people > explicitly stating their support: > - Tore Anderson > - Jan Ingvoldstad > - Piotr Strzyzewski > - Sascha Luck > - Jens Ott > - George Giannousopoulos > - Andreas Larsen > - Sebastian Wiesinger > > The announcement of the start of the review phase was sent out on the 15th > of May, and all messages indicating support came in immediately after. Since > then the mailing list has been quiet about 2014-01, which we see as a sign > of consensus. > > The formal Last Call announcement will be sent to the appropriate lists by > our incredibly helpful PDO, Marco Schmidt. > > Cheers, > Gert and Sander > Your APWG chairs > > > > Cheers, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From dr at cluenet.de Mon Jun 23 03:21:10 2014 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 23 Jun 2014 03:21:10 +0200 Subject: [address-policy-wg] why-pi question still in request form after 2011-02 acceptance? Message-ID: <20140623012110.GA12731@srv03.cluenet.de> Hi, could someone explain the rationale that the "why-pi" question is still in the IPv6 PI request form? Given that since acceptance and implementation of 2011-02 there are no special requirements attached to IPv6 PI anymore (other than the bureaucracy), I see absolutely no point in having people explain "why PA address space cannot be used for this assignment". The obvious, totally acceptable yet completely superfluous answer would be "because PA is not provider independent". I'd suggest to simply remove this "why-pi" question from the request form and supporting notes. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From randy at psg.com Mon Jun 23 03:40:28 2014 From: randy at psg.com (Randy Bush) Date: Mon, 23 Jun 2014 10:40:28 +0900 Subject: [address-policy-wg] why-pi question still in request form after 2011-02 acceptance? In-Reply-To: <20140623012110.GA12731@srv03.cluenet.de> References: <20140623012110.GA12731@srv03.cluenet.de> Message-ID: > The obvious, totally acceptable yet completely superfluous answer > would be "because PA is not provider independent". cost might also be a factor :) randy From tore at fud.no Mon Jun 23 11:00:38 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 23 Jun 2014 11:00:38 +0200 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: <53A7ECB6.60108@fud.no> * Marco Schmidt > We encourage you to review this proposal and send your comments to > before 2 July 2014. I like it, overall. Clearly there are a few who are interested in engaging in inter-RIR transfers, and if we can facilitate for this without imposing any cost or burden on those who are not interested, I can see no reason to not do this. With regards to the proposals second argument against (regarding the re-introduction of "need" if another RIR insists), I do not consider that to be problematic at all, as it would be a burden that would be borne in its entirety by the entity voluntarily taking part in a transfer involving a "needy" RIR. I have some comments/suggested improvements though: 1) I concur with other posters that the use of ?LIR? should be avoided. However, I'd also like to add that suggested replacement ?organisation? could potentially also be problematic, as a resource holder could be a natural person rather than an organisation. It would be preferable to avoid getting in a situation where non-organsation resource holders would be prevented from engaging in inter-RIR transfers even though the resource-specific policy would allow for that. Therefore I would suggest using even more general language, such as ?resource holder?/?resource holder to be? or ?entity?. 2) The proposal seeks to add the following paragraphs to ripe-606 section 5.5: ?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 from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR.? These additions seem completely redundant to me, as the new policy document says pretty much the same thing in sections 2.0 and 3.0. (Also, ?fulfill? is incorrectly spelled.) 3) Also in ripe-606 section 5.5 the proposal seeks to add the following: ?If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources.? This statement seems out of place to me: * ripe-606 does not apply to legacy resources, a fact which is implied by the new paragraph as well. The statement therefore voids itself. * Even if disregarding the above, ripe-606 only covers IPv4. Legacy resources also include ASNs. So if the resource is to be transferred is a legacy ASN, this transfer would be regulated by a piece of policy text located in the non-legacy IPv4 policy....which would to me be a completely nonsensical outcome. IMHO, the only sensible place to locate a statement that essentially says "legacy resources are governed by the legacy policy" is in, you guessed it, the legacy policy itself (ripe-605). We're in luck, because it already does just that. :-) So in summary, all of the additions 2014-05 seeks to do in ripe-605 seem redundant or out of place to me, accomplishing no actual policy change beyond adding bloat. Am I missing something? If not, I'd much rather prefer that ripe-605 is left alone by 2014-05. Tore From sandrabrown at ipv4marketgroup.com Mon Jun 23 15:02:43 2014 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Mon, 23 Jun 2014 06:02:43 -0700 Subject: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: <20140623060243.ec289651d84890fcbef5f195936e1217.161ac2a47c.wbe@email17.secureserver.net> Tore, Thanks for your feedback. See below for comments. From: Tore Anderson Subject: Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) To: address-policy-wg at ripe.net Message-ID: <53A7ECB6.60108 at fud.no> Content-Type: text/plain; charset=ISO-8859-1 I like it, overall. Clearly there are a few who are interested in engaging in inter-RIR transfers, and if we can facilitate for this without imposing any cost or burden on those who are not interested, I can see no reason to not do this. With regards to the proposals second argument against (regarding the re-introduction of "need" if another RIR insists), I do not consider that to be problematic at all, as it would be a burden that would be borne in its entirety by the entity voluntarily taking part in a transfer involving a "needy" RIR. I have some comments/suggested improvements though: 1) I concur with other posters that the use of ?LIR? should be avoided. However, I'd also like to add that suggested replacement ?organisation? could potentially also be problematic, as a resource holder could be a natural person rather than an organisation. It would be preferable to avoid getting in a situation where non-organsation resource holders would be prevented from engaging in inter-RIR transfers even though the resource-specific policy would allow for that. Therefore I would suggest using even more general language, such as ?resource holder?/?resource holder to be? or ?entity?. **** I think this is a very good point, thanks. Sandra 2) The proposal seeks to add the following paragraphs to ripe-606 section 5.5: ?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 from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR.? These additions seem completely redundant to me, as the new policy document says pretty much the same thing in sections 2.0 and 3.0. (Also, ?fulfill? is incorrectly spelled.) *** Thanks for pointing out this redundancy issue. *** Let me look into it with Marco and the Chairs, as to whether we *** would add the text or were making a statement of fact. *** Agree on spelling of fulfill. Thanks. Sandra 3) Also in ripe-606 section 5.5 the proposal seeks to add the following: ?If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources.? This statement seems out of place to me: * ripe-606 does not apply to legacy resources, a fact which is implied by the new paragraph as well. The statement therefore voids itself. * Even if disregarding the above, ripe-606 only covers IPv4. Legacy resources also include ASNs. So if the resource is to be transferred is a legacy ASN, this transfer would be regulated by a piece of policy text located in the non-legacy IPv4 policy....which would to me be a completely nonsensical outcome. IMHO, the only sensible place to locate a statement that essentially says "legacy resources are governed by the legacy policy" is in, you guessed it, the legacy policy itself (ripe-605). We're in luck, because it already does just that. :-) *** I am not sure we will add that statement to the policy or if it is *** just a statement of fact: that legacy policy will apply, as you say. *** Let me check with Marco, as what you say makes total sense to *** me. Sandra So in summary, all of the additions 2014-05 seeks to do in ripe-605 seem redundant or out of place to me, accomplishing no actual policy change beyond adding bloat. Am I missing something? If not, I'd much rather prefer that ripe-605 is left alone by 2014-05. *** Yes the intention is not to add bloat but perhaps to re-confirm what *** is already there. Thanks a ton for your feedback, and of course for *** your support for the intent. *** Sandra Tore End of address-policy-wg Digest, Vol 34, Issue 15 ************************************************* From andrea at ripe.net Thu Jun 26 15:18:10 2014 From: andrea at ripe.net (Andrea Cima) Date: Thu, 26 Jun 2014 15:18:10 +0200 Subject: [address-policy-wg] why-pi question still in request form after 2011-02 acceptance? In-Reply-To: <20140623012110.GA12731@srv03.cluenet.de> References: <20140623012110.GA12731@srv03.cluenet.de> Message-ID: <53AC1D92.2070409@ripe.net> Hi Daniel, Thanks for your feedback. You are correct, the answer to the question 'why PI' doesn?t have any impact on the outcome of the request, as there are no special (other than contractual ones) requirements linked to IPv6 PI. At the same time, the answers to the question 'why PI? are currently being used to understand the user?s request, especially when this is for multiple /48?s, or when a user requests a PI assignment while actually needing an allocation. We?re in the process of reviewing our request forms and answering this field will be made optional in the LIR Portal. I hope this clarifies. Best regards, Andrea Cima RIPE NCC On 23/6/14 03:21, Daniel Roesen wrote: > Hi, > > could someone explain the rationale that the "why-pi" question is still > in the IPv6 PI request form? Given that since acceptance and > implementation of 2011-02 there are no special requirements attached > to IPv6 PI anymore (other than the bureaucracy), I see absolutely no > point in having people explain "why PA address space cannot be used for > this assignment". The obvious, totally acceptable yet completely > superfluous answer would be "because PA is not provider independent". > > I'd suggest to simply remove this "why-pi" question from the request > form and supporting notes. :-) > > Best regards, > Daniel >