From filiz at ripe.net Mon Feb 1 13:41:29 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 1 Feb 2010 13:41:29 +0100 Subject: [routing-wg]Re: [address-policy-wg] 32-bit AS Number status? In-Reply-To: References: <4B61C989.8010604@time-travellers.org> <0E878365-0E54-4F6B-9038-14ABDDC25EEC@ripe.net> Message-ID: <990D1D6D-509E-463A-9FCB-E6BA251CA20A@ripe.net> Hello, The presentation I have mentioned in my previous mail did not discuss a proposed change in the RIPE ASN policy. In fact, there has been no revisions on the policy document since then and it is still as follows: ---- .. # From 1 January 2009 the RIPE NCC will process applications that specifically request 16-bit AS Numbers and assign such AS Numbers as requested by the applicant. In the absence of any specific request for a 16-bit AS Number, the RIPE NCC will assign a 32-bit only AS Number. # From 1 January 2010 the RIPE NCC will cease to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers, and will operate AS Number assignments from an undifferentiated 32-bit AS Number allocation pool. ---- The question that the presentation asked was on how exactly the RIPE Community thought the RIPE NCC should be assigning ASN numbers in 2010, following the two pieces of text above and whether they saw a need to change this text. The answer was to continue the way it was done during 2009, seeing no need for a change in the policy text or in the current procedure of the RIPE NCC. The minutes of this discussion was posted to the AP WG mailing list on 13 Aug 2009. Having said that, you can still make a policy proposal if you think that the policy text and so the RIPE NCC procedure must be changed. As a side note, during this presentation, one other issue about 32 bit AS Numbers, relating to the Global ASN policy, was also discussed. This resulted in a formal global proposal and it was discussed in all regions because it required a change in the global policy. You can see the details of this proposal at http://www.ripe.net/ripe/policies/proposals/2009-07.html . RIPE Community reached consensus on this proposal back in September 2009. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC On 30 Jan 2010, at 21:21, Hank Nussbacher wrote: > On Fri, 29 Jan 2010, Filiz Yilmaz wrote: > >> Dear Shane, >> >> During RIPE 58, Daniel Karrenberg has made a presentation, titled >> "32-bit ASN Take-Up Report, Policy Adjustments Needed?". >> You can find the presentation at the archives at http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf >> >> Slide 5 of the presentation relates to your question. The RIPE NCC >> proposed that the method of assigning ASNs that was employed in >> 2009 should continue after 1 January 2010. This means that all >> assignments will be for 32-bit only ASNs by default, unless a 16- >> bit ASN is specifically requested. The AP WG agreed with this >> proposal. > > Does the RIPE NCC consider a slide in a presentation as proper > documentation for revised ASN assignment procedures? > > -Hank > >> >> You can find the records of this at: >> >> http://www.ripe.net/ripe/meetings/ripe-58/meeting-report.php >> and >> http://www.ripe.net/ripe/wg/address-policy/r58-minutes.html >> >> I hope this helps. >> >> Kind regards, >> >> Filiz Yilmaz >> Policy Development Manager >> RIPE NCC >> >> >> On 28 Jan 2010, at 18:29, Shane Kerr wrote: >> >>> All, >>> I noticed that the proposed updated AS Number policy was sent to the >>> address-policy-wg recently. >>> There is a timeline for 32-bit AS Number in both the old and new >>> versions, which says: >>> "From 1 January 2010 the RIPE NCC will cease to make any distinction >>> between 16-bit AS Numbers and 32-bit only AS Numbers, and will >>> operate >>> AS Number assignments from an undifferentiated 32-bit AS Number >>> allocation pool." >>> I'm not sure exactly what this means, but I think it is supposed >>> to mean >>> that people get 32-bit AS Numbers now. Did this happen? >>> If it didn't, why not? Do we need to change "2010" to "2011"? Is >>> it ever >>> going to happen? >>> If it did, was there any effect? I mean both from humans (angry >>> LIRs, >>> peasants marching on the castle with torches, riots in the >>> streets), or >>> on the Intertubes (ugly routing artifacts, mass reboots of boxes >>> with >>> old firmware, monitoring systems gone wild)? >>> Just wondering. :) >>> -- >>> Shane >> From mir at ripe.net Wed Feb 3 16:41:29 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 03 Feb 2010 16:41:29 +0100 Subject: [address-policy-wg] How polluted is 1/8? Message-ID: <4B699929.90409@ripe.net> [Apologies for duplicates] Dear colleagues, After 1/8 was allocated to APNIC last week, the RIPE NCC did some measurements to find out how "polluted" this block really is. See some surprising results on RIPE Labs: http://labs.ripe.net/content/pollution-18 Please also note the call for feedback at the bottom of the article. Kind Regards, Mirjam Kuehne From leo.vegoda at icann.org Thu Feb 4 20:30:04 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 4 Feb 2010 11:30:04 -0800 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies In-Reply-To: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> References: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> Message-ID: <34E8A20A-DCFA-48D7-BD94-96867C23C9CD@icann.org> On 28 Jan 2010, at 7:25, Filiz Yilmaz wrote: > Dear Colleagues, > > At the RIPE 59 Meeting in Lisbon last October, the RIPE NCC announced > that it would undertake a project to improve the language of various > RIPE policy documents, without changing their substance or meaning. > This project is aimed at improving the clarity and readability of RIPE > Documents. This is good. [...] > A draft of the first RIPE Document to be revised is now available: > "Autonomous System (AS) Number Assignment Policies and Procedures". I think the update makes the document more readable and easier to understand. In 1.0 I am uncomfortable with the reference to RFC 1771 as it was obsoleted by RFC 4271 several years ago. I think it would be helpful to refer to the most current Standards Track RFC. The new section 2.0 is useful as it separates the assignment criteria from the definition of the resource. I also like the simplicity of the new language used to describe the policy. I do not think it changes the policy in any way but I am sure that it makes the meaning clearer to people who are not familiar with the subject. In section 3.1, the document refers to RFC 2026 but this has been updated by several RFCs. It might be most useful to refer to BCP 9, which includes all the relevant and current RFCs. Also, in this section, there is an example of how the experiment proposal should be published but not the results. Arguably, the results are at least as important as the proposal and it would be helpful to remove any ambiguity and give an example of acceptable publication mechanisms. In 3.3 I think the document is saying that the network operator must renumber from the experiment ASN to a new ASN if it wants to continue using the network for commercial or other purposes after the experiment has concluded. If this is the case I think it should be spelled out in crystal clear text in this section so that there is no ambiguity. It would probably save on an argument in the case that an experiment is successful and the operator wants to commercialise it. I have a question about the meaning of the text in 5.0. It doesn't make any mention of the contract referred to in 2.0. I think it would be helpful to clarify in the text that an ASN must be returned or reclaimed in the event that a contract lapses. And if I have misunderstood then I think the reverse should be stated. Finally, while I don't object to the text in 6.0 I don't think the whole timeline needs to be included in this version of the document as we have already passed 1 January 2010. Just stating that "the RIPE NCC ceased to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers on 1 January 2010, and makes AS Number assignments from an undifferentiated 32-bit AS Number pool" would probably be sufficient. All told, a very nice job. But the ASN policy is the easiest of the main three policies. IPv4 and IPv6 will be much harder work, I am sure. Regards, Leo Vegoda From Woeber at CC.UniVie.ac.at Fri Feb 5 15:35:31 2010 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 05 Feb 2010 14:35:31 +0000 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies In-Reply-To: <34E8A20A-DCFA-48D7-BD94-96867C23C9CD@icann.org> References: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> <34E8A20A-DCFA-48D7-BD94-96867C23C9CD@icann.org> Message-ID: <4B6C2CB3.9020506@CC.UniVie.ac.at> Dear Leo, Leo Vegoda wrote: > On 28 Jan 2010, at 7:25, Filiz Yilmaz wrote: thanks for the detailed analysis and comments! Looking at the framework within this exercise is meant to happen, I have the strong opinion that the proposed changes, clarifications and additions (and some more that c|should be incorporated, as well) do not fit within the "editorial changes", "clarification of language" constraints. My feeling is that the changes should either be strictly limited to those obviously covered by the "editorial changes/clarification" headlines or we should rather take this as an opportunity to really bring this policy up-to-date. This would of course imply using the regular set of rules of the PDP, imho - which in this particular case I would certainly prefer! Then we can easily include stuff related to contracts, think about, agree and clearly state to which AS#s the formal requirement to return applies to (all? only distributed by way of NCC/LIR-chain?), and where to (NCC? original LIR? IANA for the legacy ones?).... Wilfried. >>Dear Colleagues, >> >>At the RIPE 59 Meeting in Lisbon last October, the RIPE NCC announced >>that it would undertake a project to improve the language of various >>RIPE policy documents, without changing their substance or meaning. >>This project is aimed at improving the clarity and readability of RIPE >>Documents. > > > This is good. > > [...] > > >>A draft of the first RIPE Document to be revised is now available: >>"Autonomous System (AS) Number Assignment Policies and Procedures". > > > I think the update makes the document more readable and easier to understand. > > In 1.0 I am uncomfortable with the reference to RFC 1771 as it was obsoleted by RFC 4271 several years ago. I think it would be helpful to refer to the most current Standards Track RFC. > > The new section 2.0 is useful as it separates the assignment criteria from the definition of the resource. I also like the simplicity of the new language used to describe the policy. I do not think it changes the policy in any way but I am sure that it makes the meaning clearer to people who are not familiar with the subject. > > In section 3.1, the document refers to RFC 2026 but this has been updated by several RFCs. It might be most useful to refer to BCP 9, which includes all the relevant and current RFCs. Also, in this section, there is an example of how the experiment proposal should be published but not the results. Arguably, the results are at least as important as the proposal and it would be helpful to remove any ambiguity and give an example of acceptable publication mechanisms. > > In 3.3 I think the document is saying that the network operator must renumber from the experiment ASN to a new ASN if it wants to continue using the network for commercial or other purposes after the experiment has concluded. If this is the case I think it should be spelled out in crystal clear text in this section so that there is no ambiguity. It would probably save on an argument in the case that an experiment is successful and the operator wants to commercialise it. > > I have a question about the meaning of the text in 5.0. It doesn't make any mention of the contract referred to in 2.0. I think it would be helpful to clarify in the text that an ASN must be returned or reclaimed in the event that a contract lapses. And if I have misunderstood then I think the reverse should be stated. > > Finally, while I don't object to the text in 6.0 I don't think the whole timeline needs to be included in this version of the document as we have already passed 1 January 2010. Just stating that "the RIPE NCC ceased to make any distinction between 16-bit AS Numbers and 32-bit only AS Numbers on 1 January 2010, and makes AS Number assignments from an undifferentiated 32-bit AS Number pool" would probably be sufficient. > > All told, a very nice job. But the ASN policy is the easiest of the main three policies. IPv4 and IPv6 will be much harder work, I am sure. > > Regards, > > Leo Vegoda > From Andreas at Schachtner.EU Fri Feb 5 15:55:43 2010 From: Andreas at Schachtner.EU (Andreas Schachtner) Date: Fri, 05 Feb 2010 15:55:43 +0100 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies In-Reply-To: <4B6C2CB3.9020506@CC.UniVie.ac.at> References: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> <34E8A20A-DCFA-48D7-BD94-96867C23C9CD@icann.org> <4B6C2CB3.9020506@CC.UniVie.ac.at> Message-ID: <1265381743.5452.2.camel@foopa.schachtner.eu> ... > This would of course imply using the regular set of rules of the PDP, > imho - which in this particular case I would certainly prefer! I second this. Regards, Andreas -- -- Andreas Schachtner afs Holding GmbH communication technologies & solutions http://afs-com.de/ Geschaeftsfuehrer Andreas Schachtner HRB 15448, Amtsgericht Dortmund -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From leo.vegoda at icann.org Fri Feb 5 17:25:14 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 5 Feb 2010 08:25:14 -0800 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies In-Reply-To: <4B6C2CB3.9020506@CC.UniVie.ac.at> References: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> <34E8A20A-DCFA-48D7-BD94-96867C23C9CD@icann.org> <4B6C2CB3.9020506@CC.UniVie.ac.at> Message-ID: <46B6F0D6-76BF-47E2-BA6D-A17C90CCEB8C@icann.org> Hi Wilfried, On 5 Feb 2010, at 6:35, Wilfried Woeber, UniVie/ACOnet wrote: [...] > thanks for the detailed analysis and comments! > > Looking at the framework within this exercise is meant to happen, I have > the strong opinion that the proposed changes, clarifications and additions > (and some more that c|should be incorporated, as well) do not fit within > the "editorial changes", "clarification of language" constraints. > > My feeling is that the changes should either be strictly limited to those > obviously covered by the "editorial changes/clarification" headlines or > we should rather take this as an opportunity to really bring this policy > up-to-date. I can understand the need to clarify ambiguities through the regular process if they cannot be included in this update to the document. I would request, though, that the RIPE NCC publish a statement on its web site of how it currently interprets the policy where it is not explicitly clear. Kind regards, Leo Vegoda From m.pal.kh at gmail.com Tue Feb 16 10:57:54 2010 From: m.pal.kh at gmail.com (=?windows-1256?B?4+TKz+3HyiDK0cfK7eEgzeHjIMfhx8/I7eU=?=) Date: Tue, 16 Feb 2010 11:57:54 +0200 Subject: [address-policy-wg] =?windows-1256?B?5NTR5SDK0cfK7eEgzeHt4yDH4cfPyO3l?= Message-ID: <7f1324e21002160157i3d7419fned747a1ce53c652a@mail.gmail.com> [image: ??? ???? ?????? ?????? 30] ??????? ?? ???? ?????? ??????? ?????? ??? ??????? ???? ?????? ???????? ??????? ..????? http://www.tr-7lm.com/vb/t7137.html ????? ???? ??????? ??? http://www.tr-7lm.com/vb/t7296.html ????? ???? ????????? http://www.tr-7lm.com/vb/t6757.html ???? ???? ??? ??? .. ????? ??? ??????? .. http://www.tr-7lm.com/vb/t6354.html ??? ?? ??????? ????? !! http://www.tr-7lm.com/vb/t3929.html ?????? ???? ??? http://www.tr-7lm.com/vb/t5926.html ????? ?????? ????? {? ??????????? }? ..}~ http://www.tr-7lm.com/vb/t5751.html ??????? ?????? ??? http://www.tr-7lm.com/topic/ ?????? ?????? ?????? ?????? ??????? ?????? ?????? ???????? ?????? ??? ?? ????? ??? ????? ?( ????? ???? ) http://www.tr-7lm.com/vb/t3195.html#post18396 -- ?????? ???????? ?? ??? ????????? ???? ?????? ????????? ??? almhmad+unsubscribe at googlegroups.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From filiz at ripe.net Tue Feb 16 17:16:43 2010 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 16 Feb 2010 17:16:43 +0100 Subject: [address-policy-wg] ripe-484 Republished as ripe-492 Message-ID: Dear Colleagues, During the last update of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (ripe-484), some text was overlooked. The missing text, which comes from the accepted proposal "Run Out Fairly" (2009-03), has been restored and an updated document has been published as ripe-492. You can find this document at: http://www.ripe.net/ripe/docs/ipv4-policies.html We apologise for any inconvenience. Kind regards, Filiz Yilmaz Policy Development Manager RIPE NCC From shane at time-travellers.org Tue Feb 16 21:18:38 2010 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 16 Feb 2010 21:18:38 +0100 Subject: [address-policy-wg] New Draft Document: Autonomous System (AS) Number Assignment Policies In-Reply-To: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> References: <4EB94849-8F66-43C0-9111-CEC2FA03D11D@ripe.net> Message-ID: <4B7AFD9E.3000609@time-travellers.org> Filiz, On 2010-01-28 16:25, Filiz Yilmaz wrote: > At the RIPE 59 Meeting in Lisbon last October, the RIPE NCC announced > that it would undertake a project to improve the language of various > RIPE policy documents, without changing their substance or meaning. > This project is aimed at improving the clarity and readability of RIPE > Documents. For more information, see: > > http://www.ripe.net/ripe/updated-documents/ > > A draft of the first RIPE Document to be revised is now available: > "Autonomous System (AS) Number Assignment Policies and Procedures". Oh, while I did send a mail asking about the 32-bit AS number status, I realize I didn't actually comment on the proposal. The old document was a bit weird, and the new one makes a lot more sense. -- Shane From gert at space.net Fri Feb 26 15:28:07 2010 From: gert at space.net (Gert Doering) Date: Fri, 26 Feb 2010 15:28:07 +0100 Subject: [address-policy-wg] 80% rule, based on feedback from the NCC RS department Message-ID: <20100226142807.GB56228@Space.Net> Hi APWG, one of the issues pointed out by Alex le Heugh from the RIPE NCC RS department at the last RIPE meeting was the "80% rule" for additional IPv4 allocations, which has multiple, contradictory definitions in the current address policy documents. See here: http://www.ripe.net/ripe/meetings/ripe-59/presentations/leheux-rough-edges-of-policies.pdf on page 17-21 and http://www.ripe.net/ripe/docs/ripe-484.html, section 5.3 and 5.4 The different sections of the policy text both describe the rule slightly differently. This makes it unclear how the 80% rule should be applied. Let me explain by example: - a LIR has a /16, which is at 95% utilization, and a /19 that is at 40% utilization. Over all their address space, the utilization would be 88%. - interpretation 1: "if a LIR holds multiple allocations, every *single* of them needs to be filled by 80%" would result in "the LIR will not get a new allocation, because the /19 is only at 40%" - interpretation 2: "if a LIR holds multiple allocations, the grand total of them needs to be filled by 80%" would result in "the LIR *will* get another allocation, because they have used 88%". Personally, I think that the interpretation according to 5.3 of the IPv4 address policy document ("interpretation 2") is the intention of the policy. 5.4 (sub-allocations) was added later, and has language about the 80% criteria that is misleading - this section is only concerned about sub-allocations, and "the 80% sentence" was put in there to emphasize the existing rule, not to change it (I know that from the proposer of this policy change...). Now, "just changing the text according to what the WG chair thinks" would not be the right thing - so what I think is the way forward now is to get feedback from *you*, and if there is clear guidance from the working group on resolving this ambiguity, we run a formal proposal to change the wording of the document in one way or the other. (Please don't get into sidetrack discussions on whether "80%" or "IPv4" is useful, but focus on this specific question.) thanks, and regards, Gert Doering, APWG Chair -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From gert at space.net Fri Feb 26 15:26:31 2010 From: gert at space.net (Gert Doering) Date: Fri, 26 Feb 2010 15:26:31 +0100 Subject: [address-policy-wg] followup on RIPE 59: feedback from the RS department Message-ID: <20100226142631.GA56228@Space.Net> Hi APWG, at the last RIPE meeting in Amsterdam, I asked the RIPE NCC RS department to provide feedback to us regarding the day-to-day working with our policies. We make the policies, but we don't really know how well they work (especially for the great mass of LIRs that don't participate in the policy-making process) unless we get feedback. Alex Le Heux from the RIPE NCC volunteered, and reported the top three issues that cause the most questions and discussion between RS and the LIRs requesting resources. See here for the details: http://www.ripe.net/ripe/meetings/ripe-59/presentations/leheux-rough-edges-of-policies.pdf The three issues were: - differences between IPv4 and IPv6 policy - interpretation of the AS number policy - interpretation and wording of the 80% rule At the meeting, we discussed only one of these (the interpretation of the AS number policy, see page 10-16 in the PDF), because we ran out of time - and instead of rushing all three items, the WG chairs decided to focus on one, and bring up the other two on the list. Regarding the interpretation of the AS number policy, feedback from the audience in the room (plus comments in the hallways) was quite clear - everybody who voiced their opinion argued that a LIR that can document multiple distinct routing policies is entitled to multiple AS numbers, even if it's the same organization running all of the network(s). So the Registration Services department was asked to accept multiple AS requests for the same organization if an individual unique routing policy can be documented. For details of this discussion, please see the APWG R59 minutes: http://www.ripe.net/ripe/wg/address-policy/r59-minutes.html Next steps: the WG chairs will bring up the other two items to the AWPG mailing list in the next days. We need to get feedback from the community on the intent and interpretation of the current policy, and if the result is that the current policy is not really what the community wants, get the necessary changes under way. regards, Gert Doering, APWG Chair -- Total number of prefixes smaller than registry allocations: 144438 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279