This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Gert Doering
gert at space.net
Mon Sep 30 19:31:41 CEST 2013
Hi, (no hats) On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote: > Q: How would that work? > A: We could end up with two levels of RIPE NCC membership, e.g. "full" > like we have today, and "associate". Both would be fully-blown LIRs, but > to keep the operational overhead in NCC billing/finance low, the > membership fee for these "associate" members would be charged by the NCC > to the full members who are sponsoring them (just like with PI). I'm not exactly sure what the difference between an "associate member" and today's "consumer of resources provided by a sponsoring LIR" would then be, except for the title on the contract. On the contrary, some enterprises just don't want to deal with the RIPE NCC if they can make a contract with their friendly neighbouring LIR instead... So I'm not sure it's worth abandoning the established concept of sponsoring LIR right away (especially since doing away with it would affect IPv4 PI as well...). It wouldn't make a difference anyway :-) - if we want to give people the option to take a /48 because it's big enough for them, we'd then still have "two standard sizes"... So, yes, another avenue could be "abandon /48 assignments/allocations", but *that* brings up another can of worms (what about an enterprise that has 5 locations that all have local ISP upstreams and want to do BGP multihoming? 5x /48 suits them well today, 1x /32 with someone blocking more-specifics from that because no site is announcing the /32 aggregate would not be that good). I'm repeating the "no hats" bit, just contributing to the discussion as someone who has fought IPv6 policy for a while now :-) - and this is discussion phase, so take this all as "brain dump", not as "advice from the chair". gert -- 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: 306 bytes Desc: not available URL: </ripe/mail/archives/address-policy-wg/attachments/20130930/89c8dd3e/attachment.sig>
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]