From emadaio at ripe.net Wed Sep 1 15:34:22 2010 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 01 Sep 2010 15:34:22 +0200 Subject: [ipv6-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) Message-ID: <4C7E565E.4060402@ripe.net> Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. The proposal has two purposes: to create a new policy document and to change a current one. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-06.html We encourage you to review this proposal and send your comments to before 29 September 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC From pnl at ielo.net Thu Sep 2 15:20:25 2010 From: pnl at ielo.net (Bertrand Yvain) Date: Thu, 2 Sep 2010 15:20:25 +0200 Subject: [ipv6-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <4C7E565E.4060402@ripe.net> References: <4C7E565E.4060402@ripe.net> Message-ID: <20100902132025.GL2465@nexus6.adm.ielo.net> On Wed, Sep 01, 2010 at 03:34:22PM +0200, Emilio Madaio wrote: > A new RIPE Policy Proposal has been made and is now available for > discussion. [...] > http://www.ripe.net/ripe/policies/proposals/2010-06.html In section 4.0: * The value of the "assignment-size:" attribute must be less than the size of the object's bit mask. should read: * The value of the "assignment-size:" attribute must be more than the length of the object-s bit mask. It could also be precised as "strictly more" for the equal case is trivial/useless. -- Bertrand Yvain http://www.IELO.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From marcoh at marcoh.net Thu Sep 2 15:34:22 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 2 Sep 2010 15:34:22 +0200 Subject: [ipv6-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <20100902132025.GL2465@nexus6.adm.ielo.net> References: <4C7E565E.4060402@ripe.net> <20100902132025.GL2465@nexus6.adm.ielo.net> Message-ID: <35D959D7-BAAE-4078-ABAF-3A863C1B87C1@marcoh.net> On 2 sep 2010, at 15:20, Bertrand Yvain wrote: > On Wed, Sep 01, 2010 at 03:34:22PM +0200, Emilio Madaio wrote: >> A new RIPE Policy Proposal has been made and is now available for >> discussion. > [...] >> http://www.ripe.net/ripe/policies/proposals/2010-06.html > > In section 4.0: > > * The value of the "assignment-size:" attribute must be less than the > size of the object's bit mask. > > should read: > > * The value of the "assignment-size:" attribute must be more than the > length of the object-s bit mask. > > It could also be precised as "strictly more" for the equal case is > trivial/useless. Nice one indeed will pick this up on the second revision... Groet, MarcoH From andy at nosignal.org Fri Sep 3 11:12:37 2010 From: andy at nosignal.org (Andy Davidson) Date: Fri, 3 Sep 2010 10:12:37 +0100 Subject: [ipv6-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <4C7E565E.4060402@ripe.net> References: <4C7E565E.4060402@ripe.net> Message-ID: <869326DB-05F4-4D0E-8DAC-FAD126F5D9E1@nosignal.org> On 1 Sep 2010, at 14:34, Emilio Madaio wrote: > You can find the full proposal at: > http://www.ripe.net/ripe/policies/proposals/2010-06.html Hello everyone Do we need this new status attribute ? If I have a /32, and I assign a /48 to be a dsl-pool, with which to make end-user assignments of /56, then that /48 is already assigned isn't it ? Giving a customer a /56 then makes one slice used, but it's not a sub-assignment is it ? In the way that if I mark a /24 from a /21 of v4 as a dsl-pool, then I am not implying here that there are 256 sub-assignments ? Sorry if I have missed something.. Andy From marcoh at marcoh.net Fri Sep 3 14:16:34 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 3 Sep 2010 14:16:34 +0200 Subject: [ipv6-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <869326DB-05F4-4D0E-8DAC-FAD126F5D9E1@nosignal.org> References: <4C7E565E.4060402@ripe.net> <869326DB-05F4-4D0E-8DAC-FAD126F5D9E1@nosignal.org> Message-ID: <29D91586-CCD3-41F1-B012-B1704FBFF0B0@marcoh.net> On 3 sep 2010, at 11:12, Andy Davidson wrote: > > On 1 Sep 2010, at 14:34, Emilio Madaio wrote: > >> You can find the full proposal at: >> http://www.ripe.net/ripe/policies/proposals/2010-06.html > > Hello everyone > > Do we need this new status attribute ? If I have a /32, and I assign a /48 to be a dsl-pool, with which to make end-user assignments of /56, then that /48 is already assigned isn't it ? Giving a customer a /56 then makes one slice used, but it's not a sub-assignment is it ? In the way that if I mark a /24 from a /21 of v4 as a dsl-pool, then I am not implying here that there are 256 sub-assignments ? > > Sorry if I have missed something.. The deal on the status attribute is you want to know what each customer gets invidually, so in the end you can say: I have 170 customers in this pool, which makes it for 170/256 part full So instead of keeping a list of all assignments and providing the NCC access to it, you can simply copy the system which you now have for v4. Where you are required to produce the number of connections. Groet, MarcoH From marcoh at marcoh.net Fri Sep 3 21:20:59 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 3 Sep 2010 21:20:59 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> Message-ID: Oh and could people at least cross-post ? On 3 sep 2010, at 21:13, Marco Hogewoning wrote: > > On 3 sep 2010, at 17:30, Sander Steffann wrote: > >> Hi, >> >>>> A new policy proposal, 2010-06, "Registration Requirements for IPv6 End >>>> User Assignments", was published to the IPv6 Working Group mailing list today. >>> >>> I think I like this policy, mostly. >>> >>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >> >> Allowing multiple "assignment-size:" fields might solve that. > > No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? > > The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: > > bla:://40 -> assignment size /48 > bla::1/48 -> assignment size /56 > > MarcoH > MarcoH From sander at steffann.nl Fri Sep 3 21:38:15 2010 From: sander at steffann.nl (Sander Steffann) Date: Fri, 3 Sep 2010 21:38:15 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> Message-ID: Hi Marco, > Oh and could people at least cross-post ? Sorry. Probably my fault. >>>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >>> >>> Allowing multiple "assignment-size:" fields might solve that. >> >> No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? >> >> The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: >> >> bla:://40 -> assignment size /48 >> bla::1/48 -> assignment size /56 After thinking about it, this seems to be the best solution. Sander From kpn-ip-office at kpn.com Mon Sep 6 16:06:38 2010 From: kpn-ip-office at kpn.com (kpn-ip-office at kpn.com) Date: Mon, 6 Sep 2010 16:06:38 +0200 Subject: [ipv6-wg] RE: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> Message-ID: <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> I have some questions about the proposal Question 1: Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", which according to my understanding would be more in line with the IPv4 world and the proposal states it "...is largely designed based on the current IPv4 practice..."? Besides that, ASSIGNED PA is the 'lowest status' in the IPv4. Using the term SUB-ASSIGNED PA higher in the hierarchy than ASSIGNED PA in IPv6 world might only create confusion. Question 2: Also, when putting such an inetnum object on the RIPE database, would it require approval from the RIPE NCC if the (initial) sub-'assignment' exceeds a /48 (in relation with RIPE-481 chapter 5.4.2)? Question 3: In IPv4 world (and policy document) the purpose of registration is "... to ensure uniqueness and to support network operations." (RIPE-492 4.0) I realise that this sentence is not in the RIPE-481 document, so maybe this is out of order/scope, but in creating a 'pool' possibility we explicitely choose to not register inetnum information on the End User level. Does this not make "support network operations" a lot harder? Question 4: In IPv4 world, there are also LIRs that use this idea (registering a pool of addresses from which assignments are made to a number of different End Users) . But an extra status has not been required: on approval from RIPE NCC the LIR registers an inetnum with status "ASSIGNED PA". Why would an extra status be required in IPv6 world? With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office at kpn.com +31 70 45 13398 -----Oorspronkelijk bericht----- Van: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Namens Sander Steffann Verzonden: vrijdag 3 september 2010 21:38 Aan: ipv6-wg at ripe.net CC: Marco Hogewoning; Nick Hilliard; address-policy-wg at ripe.net Working Group Onderwerp: Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list Hi Marco, > Oh and could people at least cross-post ? Sorry. Probably my fault. >>>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >>> >>> Allowing multiple "assignment-size:" fields might solve that. >> >> No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? >> >> The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: >> >> bla:://40 -> assignment size /48 >> bla::1/48 -> assignment size /56 After thinking about it, this seems to be the best solution. Sander From marcoh at marcoh.net Tue Sep 7 11:13:20 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Tue, 7 Sep 2010 11:13:20 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> Message-ID: On Sep 6, 2010, at 4:06 PM, wrote: > I have some questions about the proposal > Question 1: > Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", which according to my understanding would be more in line with the IPv4 world and the proposal states it "...is largely designed based on the current IPv4 practice..."? > Besides that, ASSIGNED PA is the 'lowest status' in the IPv4. Using the term SUB-ASSIGNED PA higher in the hierarchy than ASSIGNED PA in IPv6 world might only create confusion. It has to be unique so we can implement some basic rules on wether the assignment-size attribue is mandatory, other then that the exact naming can be anythingmwe like. I picked this becuase it makes sense to me. > Question 2: > Also, when putting such an inetnum object on the RIPE database, would it require approval from the RIPE NCC if the (initial) sub-'assignment' exceeds a /48 (in relation with RIPE-481 chapter 5.4.2)? No you shouldn't, probably as long as assignment-size > /48 > Question 3: > In IPv4 world (and policy document) the purpose of registration is "... to ensure uniqueness and to support network operations." (RIPE-492 4.0) > > I realise that this sentence is not in the RIPE-481 document, so maybe this is out of order/scope, but in creating a 'pool' possibility we explicitely choose to not register inetnum information on the End User level. Does this not make "support network operations" a lot harder? I don't think so, especially since there is no requirement to register at all at the moment. So I can't tell if it's hijack r the space is actually in use. > Question 4: > In IPv4 world, there are also LIRs that use this idea (registering a pool of addresses from which assignments are made to a number of different End Users) . But an extra status has not been required: on approval from RIPE NCC the LIR registers an inetnum with status "ASSIGNED PA". Why would an extra status be required in IPv6 world? This one I don't understand. As far as assignments to end-users, it's usually implicit to be a /32. If any other cases exisit I wonder wether they are valid at all, but I'm not an IPRA. > With kind regards, > > > ir. A.W. (Andries) Hettema > KPN IP-Office > kpn-ip-office at kpn.com > +31 70 45 13398 > > > -----Oorspronkelijk bericht----- > Van: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Namens Sander Steffann > Verzonden: vrijdag 3 september 2010 21:38 > Aan: ipv6-wg at ripe.net > CC: Marco Hogewoning; Nick Hilliard; address-policy-wg at ripe.net Working Group > Onderwerp: Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list > > Hi Marco, > >> Oh and could people at least cross-post ? > > Sorry. Probably my fault. > >>>>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >>>> >>>> Allowing multiple "assignment-size:" fields might solve that. >>> >>> No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? >>> >>> The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: >>> >>> bla:://40 -> assignment size /48 >>> bla::1/48 -> assignment size /56 > > After thinking about it, this seems to be the best solution. > Sander > From denis at ripe.net Tue Sep 7 14:08:49 2010 From: denis at ripe.net (Denis Walker) Date: Tue, 07 Sep 2010 14:08:49 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> Message-ID: <4C862B51.5060107@ripe.net> Marco Hogewoning wrote: > On Sep 6, 2010, at 4:06 PM, wrote: > > >> I have some questions about the proposal >> Question 1: >> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", which according to my understanding would be more in line with the IPv4 world and the proposal states it "...is largely designed based on the current IPv4 practice..."? >> Besides that, ASSIGNED PA is the 'lowest status' in the IPv4. Using the term SUB-ASSIGNED PA higher in the hierarchy than ASSIGNED PA in IPv6 world might only create confusion. >> > > It has to be unique so we can implement some basic rules on wether the assignment-size attribue is mandatory, other then that the exact naming can be anythingmwe like. I picked this becuase it makes sense to me. > I think the term "SUB-ASSIGNED PA" may cause some confusion in the RIPE Database. For the last 10 years or more we have been enforcing policies that imply sub assignments are not allowed. Although the term 'sub assignment' is not used in the IPv4 policies it has often been used when discussing the business logic of the RIPE Database. The term "SUB-ALLOCATED PA" may be easier to understand. It's meaning in the IPv6 world would be slightly different to the same status value in the IPv4 world. But both can be partly described as "a sub set of an allocation from which assignments are made". > >> Question 2: >> Also, when putting such an inetnum object on the RIPE database, would it require approval from the RIPE NCC if the (initial) sub-'assignment' exceeds a /48 (in relation with RIPE-481 chapter 5.4.2)? >> > > No you shouldn't, probably as long as assignment-size > /48 > > >> Question 3: >> In IPv4 world (and policy document) the purpose of registration is "... to ensure uniqueness and to support network operations." (RIPE-492 4.0) >> >> I realise that this sentence is not in the RIPE-481 document, so maybe this is out of order/scope, but in creating a 'pool' possibility we explicitely choose to not register inetnum information on the End User level. Does this not make "support network operations" a lot harder? >> > > I don't think so, especially since there is no requirement to register at all at the moment. So I can't tell if it's hijack r the space is actually in use. > Having spent many years looking at data from many LIRs in the RIPE Database I see two business models that are commonly used. One is to aggregate many individual customers into an assignment block. Create one INETNUM object with status ASSIGNED PA covering this range of addresses and reference contacts from the LIR. The other is to document every end user in the RIPE Database. Create an INETNUM object with status ASSIGNED PA for each customer, even if it is only for a single IP address, and reference a PERSON object representing the customer. This policy proposal allows both these models to be used by LIRs in the IPv6 world. The SUB-ASSIGNED PA INET6NUM object is the equivalent of the aggregated ASSIGNED PA INETNUM object. If the LIR chooses to document all their end users in the RIPE Database they can also create ASSIGNED INET6NUM objects for each end user under the SUB-ASSIGNED PA. So whatever model an LIR uses now for their IPv4 customers in the RIPE Database, they can continue to use the same model as they expand into the IPv6 world. Regards Denis Walker Business Analyst RIPE NCC Database Group > >> Question 4: >> In IPv4 world, there are also LIRs that use this idea (registering a pool of addresses from which assignments are made to a number of different End Users) . But an extra status has not been required: on approval from RIPE NCC the LIR registers an inetnum with status "ASSIGNED PA". Why would an extra status be required in IPv6 world? >> > > This one I don't understand. As far as assignments to end-users, it's usually implicit to be a /32. If any other cases exisit I wonder wether they are valid at all, but I'm not an IPRA. > > >> With kind regards, >> >> >> ir. A.W. (Andries) Hettema >> KPN IP-Office >> kpn-ip-office at kpn.com >> +31 70 45 13398 >> >> >> -----Oorspronkelijk bericht----- >> Van: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Namens Sander Steffann >> Verzonden: vrijdag 3 september 2010 21:38 >> Aan: ipv6-wg at ripe.net >> CC: Marco Hogewoning; Nick Hilliard; address-policy-wg at ripe.net Working Group >> Onderwerp: Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments): discussion in the IPv6-WG mailing list >> >> Hi Marco, >> >> >>> Oh and could people at least cross-post ? >>> >> Sorry. Probably my fault. >> >> >>>>>> The only issue I have is that it appears to mandate that all assignments makes from a SUB-ASSIGNED PA block are exactly the length specified. This means that if the ISP has policies of, say, /56 for most customers but /48 for some, while at the same time wanting to implement some form of per-PoP prefix aggregation, it means assigning multiple blocks per aggregation point, one per assignment size. >>>>>> >>>>> Allowing multiple "assignment-size:" fields might solve that. >>>>> >>>> No it won't, you have a /40 with assignment size /56 and /64 and then how to specify which customer has what. Can't we solve this by allowing more specifics ? >>>> >>>> The original thought was to just create multiple entries, one for each assignment size. But we could allow for something like: >>>> >>>> bla:://40 -> assignment size /48 >>>> bla::1/48 -> assignment size /56 >>>> >> After thinking about it, this seems to be the best solution. >> Sander >> >> > > > From kpn-ip-office at kpn.com Wed Sep 8 09:53:27 2010 From: kpn-ip-office at kpn.com (kpn-ip-office at kpn.com) Date: Wed, 8 Sep 2010 09:53:27 +0200 Subject: [ipv6-wg] RE: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> Message-ID: <81D36F4CA788E041922BF0E4F3C7C93FFC84DEA581@W2055.kpnnl.local> Marco Hogewoning wrote: >> I have some questions about the proposal >> Question 1: >> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or >>even "LIR-PARTITIONED PA", which according to my understanding would be >>more in line with the IPv4 world and the proposal states it "...is largely designed >>based on the current IPv4 practice..."? >> Besides that, ASSIGNED PA is the 'lowest status' in the IPv4. Using the term >>SUB-ASSIGNED PA higher in the hierarchy than ASSIGNED PA in IPv6 world >> might only create confusion. >It has to be unique so we can implement some basic rules on wether the >assignment-size attribue is mandatory, other then that the exact naming can be >anythingmwe like. I picked this becuase it makes sense to me. I like the response of Denis about this in his mail of 7-9-2010 14:09: "The term "SUB-ALLOCATED PA" may be easier to understand. It's meaning in the IPv6 world would be slightly different to the same status value in the IPv4 world. But both can be partly described as "a sub set of an allocation from which assignments are made"." >> Question 2: >> Also, when putting such an inetnum object on the RIPE database, would it require >> approval from the RIPE NCC if the (initial) sub-'assignment' exceeds a /48 (in >>relation with RIPE-481 chapter 5.4.2)? >No you shouldn't, probably as long as assignment-size >> /48 I think it would be wise to explicitely mention this in the proposal and new policy text, to ensure that we don't create confusion for both IPRAs and LIRs. With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office at kpn.com +31 70 45 13398 From spz at serpens.de Wed Sep 8 15:49:57 2010 From: spz at serpens.de (S.P.Zeidler) Date: Wed, 8 Sep 2010 15:49:57 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <4C862B51.5060107@ripe.net> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> Message-ID: <20100908134956.GD27544@serpens.de> Thus wrote Denis Walker (denis at ripe.net): > Marco Hogewoning wrote: > > On Sep 6, 2010, at 4:06 PM, wrote: > >> I have some questions about the proposal > >> Question 1: > >> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", [...] [...] > One is to > aggregate many individual customers into an assignment block. It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :) regards, spz From marcoh at marcoh.net Wed Sep 8 22:20:58 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 8 Sep 2010 22:20:58 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <20100908134956.GD27544@serpens.de> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> <20100908134956.GD27544@serpens.de> Message-ID: <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> On 8 sep 2010, at 15:49, S.P.Zeidler wrote: > Thus wrote Denis Walker (denis at ripe.net): > >> Marco Hogewoning wrote: >>> On Sep 6, 2010, at 4:06 PM, wrote: >>>> I have some questions about the proposal >>>> Question 1: >>>> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", [...] > > [...] > >> One is to >> aggregate many individual customers into an assignment block. > > It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? > LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :) I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document. 'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose. MarcoH From marcoh at marcoh.net Fri Sep 10 09:44:18 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 10 Sep 2010 09:44:18 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> <20100908134956.GD27544@serpens.de> <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> Message-ID: <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> On Sep 8, 2010, at 10:20 PM, Marco Hogewoning wrote: > > On 8 sep 2010, at 15:49, S.P.Zeidler wrote: > >> Thus wrote Denis Walker (denis at ripe.net): >> >>> Marco Hogewoning wrote: >>>> On Sep 6, 2010, at 4:06 PM, wrote: >>>>> I have some questions about the proposal >>>>> Question 1: >>>>> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", [...] >> >> [...] >> >>> One is to >>> aggregate many individual customers into an assignment block. >> >> It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? >> LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :) > > > I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document. > > 'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose. How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose. Grtx Marco From kpn-ip-office at kpn.com Fri Sep 10 11:23:33 2010 From: kpn-ip-office at kpn.com (kpn-ip-office at kpn.com) Date: Fri, 10 Sep 2010 11:23:33 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> <20100908134956.GD27544@serpens.de> <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> Message-ID: <81D36F4CA788E041922BF0E4F3C7C93FFC850EDFD2@W2055.kpnnl.local> password: D0llemin@ Met vriendelijke groet, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office at kpn.com +31 70 45 13398 >>>>>> Question 1: >>>>>> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED PA" or even "LIR-PARTITIONED PA", [...] >>> >>> [...] >>> >>>> One is to >>>> aggregate many individual customers into an assignment block. >>> >>> It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? >>> LIR-PARTITIONED PA would also be easily understandable, but is a mouthful. :) >> >> >> I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document. >> >> 'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose. > >How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current >ones and describes the purpose. I like it:) With kind regards, ir. A.W. (Andries) Hettema KPN IP-Office kpn-ip-office at kpn.com +31 70 45 13398 From pnl at ielo.net Fri Sep 10 11:42:41 2010 From: pnl at ielo.net (Bertrand Yvain) Date: Fri, 10 Sep 2010 11:42:41 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> References: <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> <20100908134956.GD27544@serpens.de> <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> Message-ID: <20100910094241.GW2465@nexus6.adm.ielo.net> On Fri, Sep 10, 2010 at 09:44:18AM +0200, Marco Hogewoning wrote: > How do people feel about AGGREGATED-BY-LIR ? Stays in line with the > current ones and describes the purpose. I don't really appreciate the "BY-LIR" thing as there is no requirement (that I know of) for the object to be maintained by a LIR. Section 4.0 of the draft confirms this stating that such a block can be a one level more specific of an ASSIGNED inet6num. The main idea of the draft is that assignation details are maintained out of the RIPE database. I would favor things like: - ASSIGNED-EXTERNAL - ASSIGNED-AGGREGATED - AGGREGATED-BY-ORG But none of them is really good. Is there really a need to have a new status for this kind of assignments? I fail to see any reason why ASSIGNED couldn't be used, all the semantics being carried by the assignment-size attribute. Cheers, -- Bertrand Yvain http://www.IELO.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From jan at go6.si Fri Sep 10 11:23:01 2010 From: jan at go6.si (Jan Zorz @ go6.si) Date: Fri, 10 Sep 2010 11:23:01 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> <20100908134956.GD27544@serpens.de> <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> Message-ID: <4C89F8F5.1090008@go6.si> On 10.9.10 9:44, Marco Hogewoning wrote: > How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current > ones and describes the purpose. +1 /jan From marcoh at marcoh.net Fri Sep 10 12:07:59 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 10 Sep 2010 12:07:59 +0200 Subject: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <20100910094241.GW2465@nexus6.adm.ielo.net> References: <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> <20100908134956.GD27544@serpens.de> <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> <20100910094241.GW2465@nexus6.adm.ielo.net> Message-ID: <57BA4360-A425-4CDA-BD17-CB6CA85FF868@marcoh.net> On Sep 10, 2010, at 11:42 AM, Bertrand Yvain wrote: > On Fri, Sep 10, 2010 at 09:44:18AM +0200, Marco Hogewoning wrote: >> How do people feel about AGGREGATED-BY-LIR ? Stays in line with the >> current ones and describes the purpose. > > I don't really appreciate the "BY-LIR" thing as there is no requirement > (that I know of) for the object to be maintained by a LIR. Section 4.0 > of the draft confirms this stating that such a block can be a one level > more specific of an ASSIGNED inet6num. > > The main idea of the draft is that assignation details are maintained > out of the RIPE database. > > I would favor things like: > > - ASSIGNED-EXTERNAL > - ASSIGNED-AGGREGATED > - AGGREGATED-BY-ORG > > But none of them is really good. Regarding the LIR part, as you can't make assignments from a PI block it will always be PA and therefor LIR (or SUB-ALLOCATED). Marco From andreas.larsen at ip-only.se Fri Sep 10 13:10:34 2010 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Fri, 10 Sep 2010 13:10:34 +0200 Subject: SV: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) In-Reply-To: <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> References: <4C7E6162.2040809@ripe.net> <4C810F94.4070602@inex.ie> <226489E7-1900-4EC0-8E11-A90E9AF3FC3C@steffann.nl> <87ED25D5-FD6D-4329-98C9-881A788AB56F@marcoh.net> <81D36F4CA788E041922BF0E4F3C7C93FFC84DE9C66@W2055.kpnnl.local> <4C862B51.5060107@ripe.net> <20100908134956.GD27544@serpens.de> <3715DCF2-1CA0-4CFA-BFD9-35C33DAD9A7B@marcoh.net> <20962EDF-21E8-4522-8CC7-5E8FE66BD931@marcoh.net> Message-ID: +1 // Andreas Andreas Larsen AS12552 IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se ? -----Ursprungligt meddelande----- Fr?n: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] F?r Marco Hogewoning Skickat: den 10 september 2010 09:44 Till: ipv6-wg ?mne: Re: [ipv6-wg] Re: [address-policy-wg] 2010-06 New Policy Proposal (Registration Requirements for IPv6 End User Assignments) On Sep 8, 2010, at 10:20 PM, Marco Hogewoning wrote: > > On 8 sep 2010, at 15:49, S.P.Zeidler wrote: > >> Thus wrote Denis Walker (denis at ripe.net): >> >>> Marco Hogewoning wrote: >>>> On Sep 6, 2010, at 4:06 PM, wrote: >>>>> I have some questions about the proposal Question 1: >>>>> Why was chosen for "SUB-ASSIGNED PA" and not for "SUB-ALLOCATED >>>>> PA" or even "LIR-PARTITIONED PA", [...] >> >> [...] >> >>> One is to >>> aggregate many individual customers into an assignment block. >> >> It's a rather bikeshedding issue, but maybe pick AGGREGATED PA? >> LIR-PARTITIONED PA would also be easily understandable, but is a >> mouthful. :) > > > I was about to come with the same suggestion. As said, the current one basically is just a placeholder as we needed something in the revision 1 document. > > 'AGGREGATED XX' is pretty much unique and clearly describes the whole purpose. How do people feel about AGGREGATED-BY-LIR ? Stays in line with the current ones and describes the purpose. Grtx Marco From shane at time-travellers.org Sun Sep 19 23:48:50 2010 From: shane at time-travellers.org (Shane Kerr) Date: Sun, 19 Sep 2010 14:48:50 -0700 Subject: [ipv6-wg] Call for agenda items for RIPE 61 in Rome Message-ID: <1284932930.8073.15417.camel@shane-asus-laptop> Hello, The next RIPE meeting is only 56 days away! The IPv6 working group is currently scheduled to meet on Tuesday, 2010-11-16 at 16:00. We are interested in your IPv6 presentations or discussions. All items that are IPv6-related are on-topic (including plans for IPv4 co-existence after run-out). Please send your proposals to David, Marco, or myself. See you in Rome! -- Shane