Re: [address-policy-wg] address-policy-wg Digest, Vol 28, Issue 1
Hey guys: http://www.ripe.net/ripe/policies/proposals/2013-03 under b. Arguments opposing the proposal, point 3, there is following link, in which is not working. http://www.ripe.net/mail/archives/address-policy-wg/2012-October/007258.html Mind someone check it and help to fix it? On Fri, Dec 6, 2013 at 2:15 PM, <address-policy-wg-request@ripe.net> wrote:
Send address-policy-wg mailing list submissions to address-policy-wg@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@ripe.net
You can reach the person managing the list at address-policy-wg-owner@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: Announcing address resources (Sebastian Wiesinger) 2. ripe-589 question (Raimundas Tuminauskas) 3. Re: ripe-589 question (Sander Steffann) 4. 2013-06 Policy Proposal Withdrawn (PA/PI Unification IPv6 Address Space) (Marco Schmidt) 5. Re: 2013-03: Review Phase - New Proposal Description and Impact Analysis Published (Gert Doering) 6. Re: 2013-03: Review Phase - New Proposal Description and Impact Analysis Published (Richard Hartmann) 7. 2013-03 Last Call for Comments (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text) (Marco Schmidt)
----------------------------------------------------------------------
Message: 1 Date: Mon, 25 Nov 2013 09:48:24 +0100 From: Sebastian Wiesinger <ripe.address-policy-wg@ml.karotte.org> Subject: Re: [address-policy-wg] Announcing address resources To: address-policy-wg@ripe.net Message-ID: <20131125084824.GA25194@danton.fire-world.de> Content-Type: text/plain; charset=us-ascii
* Nick Hilliard <nick@inex.ie> [2013-11-21 22:36]:
Apropos of, oh I don't know, the weather or the phase of the moon or something, could someone point me to the RIPE policy which says that if you're assigned address resources from the RIPE NCC, that they cannot be announced from outside the RIPE NCC service region?
Hi,
the way I understood it is that the LIR company has to be in the RIPE region but where you announce your prefixes is your decision. I requested an AS&PA explicitly for announcement in asia without any problems.
Regards
Sebastian
-- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant
------------------------------
Message: 2 Date: Fri, 29 Nov 2013 05:57:33 +0200 From: Raimundas Tuminauskas <raimis@litnet.lt> Subject: [address-policy-wg] ripe-589 question To: address-policy-wg@ripe.net Message-ID: <20131129055733.18765g0w8kjb0hog@pastas.litnet.lt> Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Dear all,
We've ran into internal conflict assigning IPv6 address space. Anyone caring to provide independent view on this would be much appreciated.
Problem: LITNET (org: ORG-LA11-RIPE) has been comprised of two ASNs 2847 and 5479. Current IPv6 allocation is /29 (inet6num: 2001:778::/29). Current policy is to assign /32 per AS. Proposed new policy is to assign /30 per AS.
Arguments for new policy: - RIPE-589 3.4 (Aggregation) and 3.8 (Conflict of goals)
Arguments for current policy: - Two routes will be announced anyway. Different AS_PATH and routing policies, no aggregation. - /32 is 1200+ /64s per head of population of the country. Should be enough for any local AS for foreseeable future. Revise assignment planning if not. - The same address space allocation will be preserved for future AS if any current end-user (university) would require independent routing policies. - We will not get any wider allocation. Next address range (if it will happen) will be far off from 2001:778
I'm not in favor of wasting a long-term resource like IPv6 and rather deviate from the policy, but maybe I'm missing a point here somewhere ? TIA
sincerely, Raimundas Tuminauskas KTU ITD / LITNET NOC Studentu 48a, Kaunas 51367, Lithuania phone: +370 37300033 fax: +370 37300643 email: raimis@litnet.lt
------------------------------
Message: 3 Date: Fri, 29 Nov 2013 07:32:40 +0100 From: Sander Steffann <sander@steffann.nl> Subject: Re: [address-policy-wg] ripe-589 question To: Raimundas Tuminauskas <raimis@litnet.lt> Cc: "address-policy-wg@ripe.net Working Group" <address-policy-wg@ripe.net> Message-ID: <F664CA6C-673C-4CCE-A184-F351521F5649@steffann.nl> Content-Type: text/plain; charset=us-ascii
Hi,
We've ran into internal conflict assigning IPv6 address space. Anyone caring to provide independent view on this would be much appreciated.
Problem: LITNET (org: ORG-LA11-RIPE) has been comprised of two ASNs 2847 and 5479. Current IPv6 allocation is /29 (inet6num: 2001:778::/29). Current policy is to assign /32 per AS. Proposed new policy is to assign /30 per AS.
Arguments for new policy: - RIPE-589 3.4 (Aggregation) and 3.8 (Conflict of goals)
Arguments for current policy: - Two routes will be announced anyway. Different AS_PATH and routing policies, no aggregation. - /32 is 1200+ /64s per head of population of the country. Should be enough for any local AS for foreseeable future. Revise assignment planning if not.
I wouldn't count separate /64s as that will give you a distorted number. Count using the assignment size you are using, which I assume is a /48 per customer/university/research-institution/etc. That gives you a maximum of 65536 per /32. In a country with a population of 3 million that is probably enough to number all your customers :-)
- The same address space allocation will be preserved for future AS if any current end-user (university) would require independent routing policies. - We will not get any wider allocation. Next address range (if it will happen) will be far off from 2001:778
So why don't you announce 2001:778::/32 from one AS and 2001:77c::/32 from the other? If you need more space in one AS then you can grow to a /31 or /30, and if you don't need to grow them then you might, if at some point in the future you need a separate routing policy, announce the remaining space from a separate AS.
I'm not in favor of wasting a long-term resource like IPv6 and rather deviate from the policy, but maybe I'm missing a point here somewhere ?
Well, you can get the /29, and nobody else is going to get it, so you might as well make the best use of it. I just asked the NCC to expand my /32 to a /29. I use the first /32 for a LISP-based ISP setup, and I'm going to use one or more separate /32s for training purposes for ISPs. The nice thing about IPv6 is that we can always get enough space for what we need (within limits of course ;-)
Cheers, Sander
------------------------------
Message: 4 Date: Tue, 03 Dec 2013 15:07:24 +0100 From: "Marco Schmidt" <mschmidt@ripe.net> Subject: [address-policy-wg] 2013-06 Policy Proposal Withdrawn (PA/PI Unification IPv6 Address Space) To: policy-announce@ripe.net Cc: address-policy-wg@ripe.net Message-ID: <mailman.469.1386335706.3566.address-policy-wg@ripe.net>
Dear colleagues,
The proposal 2013-06, "PA/PI Unification IPv6 Address Space" has been withdrawn.
It is now archived and can be found at:
https://www.ripe.net/ripe/policies/proposals/2013-06
Reason for withdrawal: During the Discussion Phase it became clear that the RIPE community did not see the need for such a complex change. As a result, the proposers decided to withdraw the proposal.
Regards
Marco Schmidt Policy Development Office RIPE NCC
------------------------------
Message: 5 Date: Thu, 5 Dec 2013 19:31:21 +0100 From: Gert Doering <gert@space.net> Subject: Re: [address-policy-wg] 2013-03: Review Phase - New Proposal Description and Impact Analysis Published To: address-policy-wg@ripe.net Message-ID: <20131205183121.GA54642@Space.Net> Content-Type: text/plain; charset="iso-8859-1"
Dear AP WG,
On Wed, Nov 20, 2013 at 11:01:24AM +0100, Marco Schmidt wrote: [..]
We encourage you to read the proposal and the impact analysis and send any comments to <address-policy-wg@ripe.net> before 5 December 2013.
the review phase for 2013-03 has ended today. No comments were received, thus I consider all opinions expressed in the previous review phase to be unchanged (as announced, given that the policy *text* has not changed at all) - that is, 32 persons expressing support of the proposal, 3 persons opposing it.
Given the amount of support, and the nature of the opposition, the WG chairs have decided that we have reached rough consensus. We think that all counterarguments brought up by the opposers have been fully answered - this might not be sufficient to convince the opposers to change their mind, but given sufficient support otherwise, it's good enough to move forward.
This is what we'll do now -> move 2013-03 to Last Call. Marco will send the formal announcement for that later today or tomorrow.
For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what the chairs based their decision on.
If you disagree with our interpretation of what has been said, and the conclusion we have drawn from it, please let us know.
Gert Doering, Address Policy WG Chair
support: Mikael Abrahamsson Randy Bush Daniel Stolpe Dimitri I Sidelnikov Andy Davidson Sascha Luck Jan Zorz Bengt G?rd?n Raluca Andreea Gogiou Roger J?rgensen Richard Hartmann (strong sentiments that this is the last round) Andreas Larsen Jan Ingvoldstad (strong sentiments that this is the last round) Elvis Daniel Velea Nigel Titley (seconding Richard's sentiments) Gerry Demaret Sebastian Wiesinger Lu Heng Sonderegger Olaf Ian Johannesen Fredrik Widell Alexey Ivanov Sandra Brown Donal Cunningham Tassos Chatzithomaoglou Mike Burns George Giannousopoulos Ragnar Anfinsen Milton L Mueller Ronny Boesger Dominik Bay Lutz Donnerhacke
support, based on changes to the external PR regarding 2013-03, and some future PDP tasks for the chairs and the community Malcolm Hutty (see <52406426.8080405@linx.net> for details)
neutral (mailing to the thread, but not expressing support/opposition): CJ Aronson Nick Hilliard Hans Petter Holen John Curran
opposing: McTim "I don't think shifting to a market based allocation/assignment system is good stewardship. In addition there are multiple issues listed in the Impact Analysis that cause me great concern. The primary issue there is incompatibility with other regional transfer policies."
considered to be completely answered by the chairs, on the basis that 2013-03 does not introduce a transfer market, documenting the goal to assign to end users was introduced in v3 of the proposal, and incompatibilities with other regions' transfer policies can be amended by adding appropriate checks to our cross-RIR-policy-to-be, if the community ever expresses enough interest to make one (which currently does not seem to be the case).
Also, most other issues raised in the IA have been addressed by v4 of the proposal, which changed the title and rationale to send a less controversial message to external parties. So we consider this to be addressed as well.
Filiz Yilmaz would support if criteria for allocation would be amended to include "LIR must demonstrate its need for the IPv4 address space"
This was carefully listened to, and discussed with NCC RS to see what the impact would be. NCC RS stated that the addition of this sentence would not change their interpretation of the policy, given that all the LIR can do to demonstrate it's need is the willingness to make an assignment from it - and that is already there.
Based on this and based on the significant number of people asking for the proposal to go forward and not do another round of textual change and impact analysis, the chairs decided to consider this point answered, and go forward.
Sylvain Vallerot main issue seems to be that this proposal would bring LIR admins under pressure from unreasonable customer demands and that could create very problematic situations inside the LIR, without being able to point to RIR policies to back not giving out addresses.
considered to be answered by the proposer, as there is pressure inside all LIRs anyway, and even with the old formalism in place, a LIR might very well run into the same situation of having to deny addresses to some of it's customer as there are just not enough left anymore to give all of them what they ask for.
David Farmer initially "-1"'ing, then clarifying this to be more on the discussion between Sylvain and Tore, and explicitely stating neutrality on the proposal itself -- 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
* Lu Heng
http://www.ripe.net/mail/archives/address-policy-wg/2012-October/007258.html
Mind someone check it and help to fix it?
Hi Lu, The correct link is: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258... (The NCC has probably reorganised its website at some point, causing the original link to break.) Tore
Hi Tore: Thanks, I knew it as I have followed the whole discussion process. Just to point it out an invalid link:) On Mon, Dec 9, 2013 at 4:23 PM, Tore Anderson <tore@fud.no> wrote:
* Lu Heng
http://www.ripe.net/mail/archives/address-policy-wg/2012-October/007258.html
Mind someone check it and help to fix it?
Hi Lu,
The correct link is: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258...
(The NCC has probably reorganised its website at some point, causing the original link to break.)
Tore
-- -- Kind regards. 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.
Hi,
http://www.ripe.net/mail/archives/address-policy-wg/2012-October/007258.html
Mind someone check it and help to fix it?
Hi Lu,
The correct link is: http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258...
I think a formal request to the PDO is in order here: can the NCC please make sure that links to mailing list archives are never broken? There are too many external references to them. Besides, a redirect from 'mail/archives/address-policy-wg' to 'ripe/mail/archives/address-policy-wg' shouldn't be that hard to implement ;-) Cheers, Sander APWG co-chair
On 09/12/2013 22:20, Sander Steffann wrote:
can the NCC please make sure that links to mailing list archives are never broken? There are too many external references to them
reality check: "never" is a long time and the ripe web site is labyrinthine. Creating a requirement never to break URLs sounds like a great idea until you realise how much work is required to implement it, and how restrictive it can become. It's usually better to depend on an up-to-date search mechanism. just sayin'. Nick
Hi, Op 9 dec. 2013, om 23:54 heeft Nick Hilliard <nick@inex.ie> het volgende geschreven:
On 09/12/2013 22:20, Sander Steffann wrote:
can the NCC please make sure that links to mailing list archives are never broken? There are too many external references to them
reality check: "never" is a long time and the ripe web site is labyrinthine.
True
Creating a requirement never to break URLs sounds like a great idea until you realise how much work is required to implement it, and how restrictive it can become. It's usually better to depend on an up-to-date search mechanism.
I prefer URLs to crucial stuff like mailing list archives and RIPE documents to be stable. Of course, _never_ may be the wrong requirement, but breaking such URLs should be done consciously, if/when it happens. In this case it seems to be a different mistake anyway, but this is a good thing to keep in mind for the future :-) Cheers! Sander
* Sander Steffann
I think a formal request to the PDO is in order here: can the NCC please make sure that links to mailing list archives are never broken? There are too many external references to them. Besides, a redirect from 'mail/archives/address-policy-wg' to 'ripe/mail/archives/address-policy-wg' shouldn't be that hard to implement ;-)
On closer look, it's not the mailing list archive that changed, it's the way it's being linked to from the proposal's page: ?version=1: <a class="external-link" href="http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258..." target="_self" title="">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html</a> ?version=2: <a class="external-link" href="../../../mail/archives/address-policy-wg/2012-October/007258.html" target="_self" title="">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html</a> ?version=3: <a href="../../../../mail/archives/address-policy-wg/2012-October/007258.html">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html</a> Somehow a few extraneous ".."s sneaked in the href of v2 and v3.... (?version=4 seems fixed now and uses an absolute URL. Thanks to whoever did that!) Tore
Hi, Op 9 dec. 2013, om 23:59 heeft Tore Anderson <tore@fud.no> het volgende geschreven:
On closer look, it's not the mailing list archive that changed, it's the way it's being linked to from the proposal's page:
?version=1: <a class="external-link" href="http://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258..." target="_self" title="">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html</a> ?version=2: <a class="external-link" href="../../../mail/archives/address-policy-wg/2012-October/007258.html" target="_self" title="">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html</a> ?version=3: <a href="../../../../mail/archives/address-policy-wg/2012-October/007258.html">https://www.ripe.net/ripe/mail/archives/address-policy-wg/2012-October/007258.html</a>
Somehow a few extraneous ".."s sneaked in the href of v2 and v3....
Even more funny: why show the absolute URL in the text but make the actual href relative?
(?version=4 seems fixed now and uses an absolute URL. Thanks to whoever did that!)
Which seems the right thing to do :-) Anyway, it seems this is just a broken link and not a URL change, so all is well. Request to PDO: please fix the links in versions 2 and 3 and make them absolute, just to keep the history correct when someone wants to evaluate the process in the future. Thanks all! Sander
participants (4)
-
Lu Heng
-
Nick Hilliard
-
Sander Steffann
-
Tore Anderson