October 2014 - address-policy-wg

Re: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Gert Doering 01 Dec '14

01 Dec '14

Dear Address Policy WG, while I can understand that beaches and drinks are more attractive than policy work, we have a proposal here that needs a bit of caring - this one is in Review Phase until Friday, and has received exactly one comment yet (strong support). I could use a *bit* more feedback here... thanks, Gert Doering, Address Policy WG Chair On Thu, Jul 31, 2014 at 01:30:43PM +0200, Marco Schmidt wrote: > > Dear colleagues, > > The draft document for version 2.0 of the policy proposal 2014-04, > "Relaxing IPv6 Requirement for Receiving Space from the Final /8", > has now been published, along with an impact analysis conducted by > the RIPE NCC. > > Some of the differences from version 1.0 include: > > - Extending the fulfilment of the IPv6 requirement to include any > globally routable unicast IPv6 address block > - Related wording adjustments in the summary and rationale of the proposal > > > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-04 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-04/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg(a)ripe.net before 29 August 2014. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC > > 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

21 46

Re: [address-policy-wg] 2014-13 New Policy Proposal (Allow AS Number Transfers)
by Andreas Vogler 03 Nov '14

03 Nov '14

I support this proposal. Regards Andreas Vogler Geneon GmbH I Gutenstetter Str. 8a I 90449 Nürnberg I Entwicklungszentrum Berlin I Löwestr. 25 I 10249 Berlin I Tel.: +49 (0)911 36 78 88-21 I Fax: +49 (0)911 36 78 88-20 I Geschäftsführer: Yong-Harry Steiert I Registergericht Nürnberg HRB 17193 I USt-IdNr.: DE207317266 I E-Mail: andreas.vogler(a)geneon.de I www.geneon.de Ein Unternehmen der Willmy MediaGroup >>> www.willmy.de -----Ursprüngliche Nachricht----- Von: address-policy-wg-bounces(a)ripe.net [mailto:address-policy-wg-bounces@ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 30. Oktober 2014 15:57 An: policy-announce(a)ripe.net Cc: address-policy-wg(a)ripe.net Betreff: [address-policy-wg] 2014-13 New Policy Proposal (Allow AS Number Transfers) Dear colleagues, A proposed change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-13 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

2 1

Re: [address-policy-wg] 2014-12 New Policy Proposal (Allow IPv6 Transfers)
by Andreas Vogler 31 Oct '14

31 Oct '14

I support this proposal. Regards Andreas Vogler Geneon GmbH I Gutenstetter Str. 8a I 90449 Nürnberg I Entwicklungszentrum Berlin I Löwestr. 25 I 10249 Berlin I Tel.: +49 (0)911 36 78 88-21 I Fax: +49 (0)911 36 78 88-20 I Geschäftsführer: Yong-Harry Steiert I Registergericht Nürnberg HRB 17193 I USt-IdNr.: DE207317266 I E-Mail: andreas.vogler(a)geneon.de I www.geneon.de Ein Unternehmen der Willmy MediaGroup >>> www.willmy.de -----Ursprüngliche Nachricht----- Von: address-policy-wg-bounces(a)ripe.net [mailto:address-policy-wg-bounces@ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 30. Oktober 2014 13:43 An: policy-announce(a)ripe.net Cc: address-policy-wg(a)ripe.net Betreff: [address-policy-wg] 2014-12 New Policy Proposal (Allow IPv6 Transfers) Dear colleagues, A proposed change to RIPE Document ripe-589, "IPv6 Address Allocation and Assignment Policy" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-12 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-13 New Policy Proposal (Allow AS Number Transfers)
by Marco Schmidt 30 Oct '14

30 Oct '14

Dear colleagues, A proposed change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-13 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2014-12 New Policy Proposal (Allow IPv6 Transfers)
by Andre Keller 30 Oct '14

30 Oct '14

Hi, I fully support this proposal. Regards andré

1 0

2014-12 New Policy Proposal (Allow IPv6 Transfers)
by Marco Schmidt 30 Oct '14

30 Oct '14

Dear colleagues, A proposed change to RIPE Document ripe-589, "IPv6 Address Allocation and Assignment Policy" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-12 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2014-08 New Policy Proposal (Language Clarification in âContractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Regionâ)
by Peter Koch 24 Oct '14

24 Oct '14

On Thu, Oct 23, 2014 at 03:15:24PM +0200, Marco Schmidt wrote: > A proposed change to RIPE Document "Contractual Requirements for Provider > Independent Resource Holders in the RIPE NCC Service Region" is now available > for discussion. > https://www.ripe.net/ripe/policies/proposals/2014-08 # Any resources allocated/assigned to the RIPE NCC will be registered in the # RIPE Database. All policies set for allocating or assigning resources to # LIRs apply equally to the RIPE NCC. The RIPE NCC as a resource holder should # fulfil the same basic requirements also expected of normal LIRs, such as returning # unused resources. As an exception from normal LIRs, RIPE NCC as a resource holder # is exempted from signing any of the normal contracts required for number resource allocation/assignment. RFC 2119, as mentioned in the introduction, is not relevant to this document (see earlier mail). In this case, the change appears straightforward even if should vs must was interpreted in a natural language context. On second thought, it remains undefined what the "basic requirements" are (leaving another ambiguity) and it isn't clear whether the list of exemptions is exhaustive. As an example: is the NCC undergoing a regular or case by case audit and who is supposed to execute that? Arbiters are supposed to evaluate requests, but how would the NCC's adherence to the "basic requirements, [...] such as returning unused resources" be supervised? There's no vox populi appeal to the arbiters. But wait, we have a general community involvement in the NCC's operation and my perception was it was considered functioning. So, I'm not really convinced that an s/should/must/ would prevent the NCC from running wild if it wanted to. On the other hand, I might be looking forward to future policy proposals and further should vs must (or similar) discussions except that the PDP rarely provides the right slot for this level of detail. In other words: what's being tried to fixed here is likely to happen again. Back to 2014-08: it's either unnecessary or incomplete. -Peter PS: Obviously in this case it is prudent for the NCC as the submitter to err on the side of caution

3 5

Re: [address-policy-wg] 2014-11 New Policy Proposal (Language Clarification for “Allocating/Assigning Resources to the RIPE NCC”)
by Jan Ingvoldstad 24 Oct '14

24 Oct '14

On Thu, Oct 23, 2014 at 3:45 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "Allocating/Assigning Resources > to the RIPE NCC" is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-11 > I see where this is heading. :) I support this change as well, very sensible! -- Jan

1 0

Re: [address-policy-wg] 2014-07 New Policy Proposal (Language Clarification in “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”)
by Jan Ingvoldstad 24 Oct '14

24 Oct '14

On Thu, Oct 23, 2014 at 3:05 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "IPv4 Address Allocation and Assignment > Policies for the RIPE NCC Service Region" is now available for discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-07 > > As far as I can tell, all of these changes are sensible. I support them. -- Jan

1 0

Re: [address-policy-wg] 2014-09 New Policy Proposal (Language Clarification in “IPv6 Address Space Policy For Internet Exchange Points”)
by Nick Hilliard 24 Oct '14

24 Oct '14

On 23/10/2014 14:28, Marco Schmidt wrote: > A proposed change to RIPE Document IPv6 Address Space Policy For > Internet Exchange Points is now available for discussion. the tl;dr for my objection on this proposal is that it doesn't make much sense from the IXP point of view. The equivalent ipv4 policy notes: "This space will be used to run an IXP peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not perfect by any means, but ok (as a reference anecdata point, INEX is still using a single /24 assigned in 2004 for both peering and management, because it was hard to justify more at the time). For IPv6, it would be normal to assign a /64 per peering LAN, leaving 65535 other /64 subnets unused in the /48 assignment. For better or worse, many IXPs in the RIPE NCC service region use some of the other space in their /48 for management purposes. If this policy change goes through, then the RIPE NCC is mandating that they renumber this management into other space. The RIPE community doesn't have the authority to mandate this for existing IXPs. For future start-up IXPs, it often makes more sense to use a single prefix to provide address space for both peering and management, where management connectivity is handled by policy routing from the IXP's ASN. Maybe it might be appropriate for the IXP to use separate prefixes at the stage when an IXP has grown to the point that it attracts enough DDoS traffic directed at the IXP lan to cause trouble, but not before. Even then, this is a decision that the IXP should make: it's not the job of the RIPE community to tell the IXP how to manage their policy routing. Nick

6 6