Re: [ipv6-wg] 2010-06 is going to Last Call
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote:
Hello,
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010).
You can see the policy proposal here:
http://ripe.net/ripe/policies/proposals/2010-06.html
There were some clarifications during the Review Phase, but nothing indicating changes needed.
David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.)
The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
-- Shane
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06.
Perhaps it's a good idea to at least mention the title of the policy proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Just dropping a proposal number and expecting all readers to use their web browser to find out what this 1234-56 is all about does probably act as a factual barrier. I know it does for me, not being paid for following RIPE mailing lists in detail. Just a suggestion. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 1/26/11 8:28 AM, Daniel Roesen wrote:
We have not received any input so far whether you support draft policy 2010-06. Perhaps it's a good idea to at least mention the title of the policy
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Agree.
On the other hand, it took me 20 seconds to find it. For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html /jan P.S: I support this proposal as-is.
I support the proposal as-is. Regards Andreas -----Ursprungligt meddelande----- Från: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] För Jan Zorz @ go6.si Skickat: den 26 januari 2011 09:15 Till: ipv6-wg@ripe.net Ämne: Re: [ipv6-wg] Re: 2010-06 is going to Last Call On 1/26/11 8:28 AM, Daniel Roesen wrote:
We have not received any input so far whether you support draft policy 2010-06. Perhaps it's a good idea to at least mention the title of the policy
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Agree.
On the other hand, it took me 20 seconds to find it. For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html /jan P.S: I support this proposal as-is.
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft
I am new to this process.. so for me it saves more as the suggested 20 seconds :=-) G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Jan Zorz @ go6.si Sent: woensdag 26 januari 2011 9:15 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] Re: 2010-06 is going to Last Call On 1/26/11 8:28 AM, Daniel Roesen wrote: policy
2010-06. Perhaps it's a good idea to at least mention the title of the policy proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Agree.
On the other hand, it took me 20 seconds to find it. For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html /jan P.S: I support this proposal as-is.
On Wed, Jan 26, 2011 at 09:14:47AM +0100, Jan Zorz @ go6.si wrote:
On 1/26/11 8:28 AM, Daniel Roesen wrote:
We have not received any input so far whether you support draft policy 2010-06. Perhaps it's a good idea to at least mention the title of the policy
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote: proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Agree.
On the other hand, it took me 20 seconds to find it.
For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html
Under 3.0 section there is: "When needed, more specific inet6num objects are allowed to indicate a different assignment size within a certain range however only one level of more specifics is allowed." However rules put into 4.0 section allows to create multiple levels of inet6num objects with AGGREGATED-BY-LIR status. Is it ok? Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
For everyone reference and help (saving 20 seconds): http://ripe.net/ripe/policies/proposals/2010-06.html
Under 3.0 section there is: "When needed, more specific inet6num objects are allowed to indicate a different assignment size within a certain range however only one level of more specifics is allowed."
However rules put into 4.0 section allows to create multiple levels of inet6num objects with AGGREGATED-BY-LIR status. Is it ok?
In the draft document at http://ripe.net/ripe/draft-documents/ripe-new-draft2010-06.html It says under 4.0: 4.0 Functionality When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules: • The inet6num object may contain an optional attribute called "assignment-size:". • The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself. • A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or “AGGREGATED-BY-LIR”. • When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:” attribute becomes required. And this describes how the database will eventually will operate, so so it will check how many levels there are when you try and create or update an object. But maybe I don't understand your question Marco (Again strictly as proposer/co-author)
On Wed, Jan 26, 2011 at 12:55:45PM +0000, Marco Hogewoning wrote:
In the draft document at http://ripe.net/ripe/draft-documents/ripe-new-draft2010-06.html
It says under 4.0:
4.0 Functionality
When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules:
? The inet6num object may contain an optional attribute called "assignment-size:".
? The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself.
? A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or ?AGGREGATED-BY-LIR?.
? When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:? attribute becomes required.
And this describes how the database will eventually will operate, so so it will check how many levels there are when you try and create or update an object. But maybe I don't understand your question
So, according to third point I can create inet6num object with /36 size and status "AGGREGATED-BY-LIR" under my allocation, and then another inet6num object with /37 size and status "AGGREGATED-BY-LIR" under this bigger one and then another one and so on. There is nothing about two levels less specific object. But maybe I don't understand this correctly. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On Jan 26, 2011, at 4:03 PM, Piotr Strzyzewski wrote:
On Wed, Jan 26, 2011 at 12:55:45PM +0000, Marco Hogewoning wrote:
In the draft document at http://ripe.net/ripe/draft-documents/ripe-new-draft2010-06.html
It says under 4.0:
4.0 Functionality
When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules:
? The inet6num object may contain an optional attribute called "assignment-size:".
? The value of the "assignment-size:" attribute must be a longer prefix than the prefix of the object itself.
? A value of "AGGREGATED-BY-LIR" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or ?AGGREGATED-BY-LIR?.
? When an inet6num contains a "status:" value of "AGGREGATED-BY-LIR" the "assignment-size:? attribute becomes required.
And this describes how the database will eventually will operate, so so it will check how many levels there are when you try and create or update an object. But maybe I don't understand your question
So, according to third point I can create inet6num object with /36 size and status "AGGREGATED-BY-LIR" under my allocation, and then another inet6num object with /37 size and status "AGGREGATED-BY-LIR" under this bigger one and then another one and so on. There is nothing about two levels less specific object. But maybe I don't understand this correctly.
You are righrt, it seems a bit strange ,without the policy that says only one level is allowed to it next to it (it's in another document). Please also take a look at the mail from Denis Walker on how the RIPE NCC will implement this and will be checking the grandparent object as well. Grtx, Marco
On Wed, Jan 26, 2011 at 04:07:42PM +0000, Marco Hogewoning wrote:
So, according to third point I can create inet6num object with /36 size and status "AGGREGATED-BY-LIR" under my allocation, and then another inet6num object with /37 size and status "AGGREGATED-BY-LIR" under this bigger one and then another one and so on. There is nothing about two levels less specific object. But maybe I don't understand this correctly.
You are righrt, it seems a bit strange ,without the policy that says only one level is allowed to it next to it (it's in another document). Please also take a look at the mail from Denis Walker on how the RIPE NCC will implement this and will be checking the grandparent object as well.
That explains everything. I support this proposal. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
Daniel, On Wed, 2011-01-26 at 08:28 +0100, Daniel Roesen wrote:
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06.
Perhaps it's a good idea to at least mention the title of the policy proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Just dropping a proposal number and expecting all readers to use their web browser to find out what this 1234-56 is all about does probably act as a factual barrier. I know it does for me, not being paid for following RIPE mailing lists in detail.
Okay that makes sense. Looking at other announcements it seems like this is how things are normally done, and it was just an oversight on my side. Cheers, -- Shane
Some feedback: <> As an example, one would create <provider-tla>::/36 with an assignment size of /56. A simple MRTG graph over time showing the actual number of assignments or customers can then be generated from the OSS/BSS system or maybe even directly from the DHCPv6 servers involved. This would then satisfy the need to verify the addresses are used efficiently enough and the LIR meets the HD ratio required. It does so in a way to which most LIRs are already familiar and without the need to disclose to any specific information on individual End Users or the resource they hold. <> GV> Not sure why this is here in the intro... it's a valid and usefull anticipation, but I would place it somewhere else in the document as a motivation example. <>start<> 1.0 Motivation ... keep records of IPv6 address assignments ... <>end<> GV> What about using 'IPv6 subnet address assignments'? (I don't care about individual addresses in v6, but care about subnet addresses being used and the HD is calculated on that variable, not?) <>start<> 4.0 Functionality ... object may contain ... <>end<> GV>Is there a reason why it's a 'may' instead of a 'should' or 'must'? <>start<> 5.5 Registration ... End Site assignments ... <>end<> GV> What is an End-site assignment? If it's a SP doing this then I assume it is enterprise customer, however if it's an enterprise getting PI space, then what is end-site assignment? Maybe a loaded/naive question, but why not suggest anything larger then a /xx should be placed in the database? Ciao, G/ -----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Daniel Roesen Sent: woensdag 26 januari 2011 8:28 To: ipv6-wg@ripe.net Subject: [ipv6-wg] Re: 2010-06 is going to Last Call On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06.
Perhaps it's a good idea to at least mention the title of the policy proposal in the "last call" announcements so that folks can quickly check wether they might have an opinion to voice or not. Just dropping a proposal number and expecting all readers to use their web browser to find out what this 1234-56 is all about does probably act as a factual barrier. I know it does for me, not being paid for following RIPE mailing lists in detail. Just a suggestion. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Responding in my role as one of the proposers and authors of this document. Please see my comments inline: On Jan 26, 2011, at 10:17 AM, Gunter Van de Velde (gvandeve) wrote:
Some feedback:
<> As an example, one would create <provider-tla>::/36 with an assignment size of /56. A simple MRTG graph over time showing the actual number of assignments or customers can then be generated from the OSS/BSS system or maybe even directly from the DHCPv6 servers involved. This would then satisfy the need to verify the addresses are used efficiently enough and the LIR meets the HD ratio required. It does so in a way to which most LIRs are already familiar and without the need to disclose to any specific information on individual End Users or the resource they hold. <>
GV> Not sure why this is here in the intro... it's a valid and usefull anticipation, but I would place it somewhere else in the document as a motivation example.
Forgive me for asking, are you commenting on the policy proposal itself or on one of the draft documents which will be the result of this ?
<>start<> 1.0 Motivation ... keep records of IPv6 address assignments ... <>end<>
GV> What about using 'IPv6 subnet address assignments'? (I don't care about individual addresses in v6, but care about subnet addresses being used and the HD is calculated on that variable, not?)
I think the rest of the policy also simply talks about address assignments and allocations and not 'subnet assignments'
<>start<> 4.0 Functionality ... object may contain ... <>end<>
GV>Is there a reason why it's a 'may' instead of a 'should' or 'must'?
Long story. The original text had a must there, it has something todo in the way the text of the document is converted into technical requirements for the RIPE NCC database group. The formal rule is that the attribute is optional so it has to be a may as you describe it. The 'must' will be the result of a business rule at another level. This came up during the impact analysis done by the NCC so Remco and I agreed in changing it.
<>start<> 5.5 Registration ... End Site assignments ... <>end<>
GV> What is an End-site assignment? If it's a SP doing this then I assume it is enterprise customer, however if it's an enterprise getting PI space, then what is end-site assignment? Maybe a loaded/naive question, but why not suggest anything larger then a /xx should be placed in the database?
PI is not relevant here as you are not allowed to make any sub assignments within a PI assignment. The definition of an end site is given elsewhere in the document (sec 2.9, current RIPE-481) and this will not be changed. Grtx, MarcoH (proposer)
<> As an example, one would create <provider-tla>::/36 with an assignment size of /56. A simple MRTG graph over time showing the actual number of assignments or customers can then be generated from the OSS/BSS system or maybe even directly from the DHCPv6 servers involved. This would then satisfy the need to verify the addresses are used efficiently enough and the LIR meets the HD ratio required. It does so in a way to which most LIRs are already familiar and without the need to disclose to any specific information on individual End Users or the resource they hold. <>
GV> Not sure why this is here in the intro... it's a valid and usefull anticipation, but I would place it somewhere else in the document as a motivation example.
Forgive me for asking, are you commenting on the policy proposal itself or on one of the draft documents which will be the result of this ? GV> I was just surprised to see an example in the intro section... it is not that I disagree with it, however it's a strange place to see an example mentioned.
On Jan 26, 2011, at 10:38 AM, Gunter Van de Velde (gvandeve) wrote:
<> As an example, one would create <provider-tla>::/36 with an assignment size of /56. A simple MRTG graph over time showing the actual number of assignments or customers can then be generated from the OSS/BSS system or maybe even directly from the DHCPv6 servers involved. This would then satisfy the need to verify the addresses are used efficiently enough and the LIR meets the HD ratio required. It does so in a way to which most LIRs are already familiar and without the need to disclose to any specific information on individual End Users or the resource they hold. <>
GV> Not sure why this is here in the intro... it's a valid and usefull anticipation, but I would place it somewhere else in the document as a motivation example.
Forgive me for asking, are you commenting on the policy proposal itself or on one of the draft documents which will be the result of this ?
GV> I was just surprised to see an example in the intro section... it is not that I disagree with it, however it's a strange place to see an example mentioned.
It could have gone in the rationale, but then again it might be worth explaining it in the beginning. But be aware this is just the proposal, t's a form used in the process. This is not the resulting text, these are in the draft documents listed in the heading. Marco (as the proposer)
Hi, I have two brief comments: The first one concerns the form of these announcements sent to the mailing list (and this doesn't just concern this particular proposal, if I recall correctly). Is it just me that find it obnoxious that nowhere in the announcement can there be found any hint as to what is proposed? I think that the lack of inclusion of even the title of the proposal creates a needless threshold for responding to it. For the record, the title of the proposal is "Registration Requirements for IPv6 End User Assignments". The only other comment I have is that 2^10 = 1024 != 1000. :) Other than that, I can't see anything wrong with the proposal. Best regards, - Håvard ------------------------------
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
All,
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
David & Shane ---
On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote:
Hello,
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010).
You can see the policy proposal here:
http://ripe.net/ripe/policies/proposals/2010-06.html
There were some clarifications during the Review Phase, but nothing indicating changes needed.
David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.)
The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
-- Shane
Unsurprisingly, I support this proposal as-is :) Remco
-----Original Message----- From: address-policy-wg-admin@ripe.net [mailto:address-policy-wg- admin@ripe.net] On Behalf Of David Kessens Sent: woensdag 26 januari 2011 6:41 To: ipv6-wg Cc: db-wg@ripe.net; address-policy-wg@ripe.net Subject: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
All,
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e- mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
David & Shane ---
On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote:
Hello,
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010).
You can see the policy proposal here:
http://ripe.net/ripe/policies/proposals/2010-06.html
There were some clarifications during the Review Phase, but nothing indicating changes needed.
David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.)
The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
-- Shane
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
Hello IPv6 WG,
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I support this proposal Sander
On 1/26/11 12:40 AM, "David Kessens" <david.kessens@nsn.com> wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I support this proposal. Best, -M<
I support the proposal. Kind regards Allan Eising Network Engineer IP Vision A/S
All,
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
David & Shane
Hi All, On 1/26/11 6:40 AM, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I also support this proposal. Cheers, Mathieu
On Tue, Jan 25, 2011 at 22:40, David Kessens <david.kessens@nsn.com> wrote:
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
All,
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I support this policy. ~Chris
The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
David & Shane ---
On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote:
Hello,
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010).
You can see the policy proposal here:
http://ripe.net/ripe/policies/proposals/2010-06.html
There were some clarifications during the Review Phase, but nothing indicating changes needed.
David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.)
The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
-- Shane
-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
OK I support this policy Lionel HOFFMANN Direction Technique Tel: 01 39 45 42 76 Mob: 06 60 31 42 76 Email: lhoffman@bouyguestelecom.fr Adresse: 13/15 avenue du Maréchal juin 92360 MEUDON -----Message d'origine----- De : ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] De la part de Chris Grundemann Envoyé : mercredi 26 janvier 2011 16:03 À : David Kessens Cc : ipv6-wg; db-wg@ripe.net; address-policy-wg@ripe.net Objet : Re: [address-policy-wg] Re: [ipv6-wg] 2010-06 is going to Last Call On Tue, Jan 25, 2011 at 22:40, David Kessens <david.kessens@nsn.com> wrote:
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
All,
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I support this policy. ~Chris
The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
David & Shane ---
On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote:
Hello,
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010).
You can see the policy proposal here:
http://ripe.net/ripe/policies/proposals/2010-06.html
There were some clarifications during the Review Phase, but nothing indicating changes needed.
David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.)
The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
-- Shane
-- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org L'intégrité de ce message n'étant pas assurée sur internet, la société expéditrice ne peut être tenue responsable de son contenu ni de ses pièces jointes. Toute utilisation ou diffusion non autorisée est interdite. Si vous n'êtes pas destinataire de ce message, merci de le détruire et d'avertir l'expéditeur. The integrity of this message cannot be guaranteed on the Internet. The company that sent this message cannot therefore be held liable for its content nor attachments. Any unauthorized use or dissemination is prohibited. If you are not the intended recipient of this message, then please delete it and notify the sender.
On 26/01/2011 05:40, David Kessens wrote:
The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
I agree with the proposal. Nick
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal". The only one who needs the assignment size is RIPE NCC when evaluating new allocation requests or in audit. At that time, it's easy for the LIR to provide this info to NCC for HD ratio evaluation. Following the spirit of data protection, we shouldn't put (in a mandatory manner) more potentially sensitive data into public databases without a good justification for the need to have that data public. As a second reason, it allows folks running block lists to again start blocking dynamic customer IP prefixes by automatically looking up the assignment-size. Of course that makes no sense (as the /xy prefix will belong to another customer next day), but as soon as those assignment-size attributes will pop up, misguided folks _will_ start using them for broken heuristics and cause colateral damage. My opposition is solely about the assignment-size attribute being mandatory. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 1/26/11 9:36 PM, Daniel Roesen wrote:
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal".
The only one who needs the assignment size is RIPE NCC when evaluating new allocation requests or in audit. At that time, it's easy for the LIR to provide this info to NCC for HD ratio evaluation. Following the spirit of data protection, we shouldn't put (in a mandatory manner) more potentially sensitive data into public databases without a good justification for the need to have that data public.
As a second reason, it allows folks running block lists to again start blocking dynamic customer IP prefixes by automatically looking up the assignment-size. Of course that makes no sense (as the /xy prefix will belong to another customer next day), but as soon as those assignment-size attributes will pop up, misguided folks _will_ start using them for broken heuristics and cause colateral damage.
My opposition is solely about the assignment-size attribute being mandatory.
Best regards, Daniel
Hi, I agree with Daniel's arguments regarding the mandatory and visible status of the proposed new "assignment-size" attribute. Regards, Valeriu. ================================= Valeriu VRACIU Network Engineer at RoEduNet tel: +40 (232) 201003 fax: +40 (232) 201200 GSM: +40 (744) 615251 e-mail: valeriu.vraciu@roedu.net ================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1BJj0ACgkQncI+CatY9492fwCgiELB3MnMtLYpI1R/INqTgzsZ /DEAninsMzBnbJGgTVA+qfzMg2OoOTYl =JnxM -----END PGP SIGNATURE-----
Daniel, Valeriu, I don't really see why publishing an assignment size alone would allow people to run block lists. People will run those regardless, and if they don't know what size prefix a customer has, they will assume one, and error on the side of caution - i.e. always assume a /48. Misguided people won't stop being misguided because of a lack of information. I wish that was true. As for your first argument, I don't think the RIPE NCC can do a proper job with some public oversight without publishing the assignment size. For IPv4 the world is pretty straightforward, because everybody knows that the size of a customer prefix in a dynamic pool is a /32 or somewhere close to that. It's not a /16. In IPv6, it can be anything from a /64 to a /48 - pretty much at the discretion of the ISP. It should be a surprise to absolutely nobody that ISPs who hand out /48s will go through their allocations a lot quicker than others handing out /64s, and as a result will end up with more address space. A published assignment size for dynamic pools helps to explain to the rest of the world why that is. And it protects your customers from misguided people who like to make assumptions that are safe for them, not your customers. Remco
-----Original Message----- From: ipv6-wg-admin@ripe.net [mailto:ipv6-wg-admin@ripe.net] On Behalf Of Valeriu Vraciu Sent: donderdag 27 januari 2011 9:01 To: ipv6-wg@ripe.net Subject: Re: [ipv6-wg] Re: 2010-06 is going to Last Call
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 1/26/11 9:36 PM, Daniel Roesen wrote:
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached.
I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal".
The only one who needs the assignment size is RIPE NCC when evaluating new allocation requests or in audit. At that time, it's easy for the LIR to provide this info to NCC for HD ratio evaluation. Following the spirit of data protection, we shouldn't put (in a mandatory manner) more potentially sensitive data into public databases without a good justification for the need to have that data public.
As a second reason, it allows folks running block lists to again start blocking dynamic customer IP prefixes by automatically looking up the assignment-size. Of course that makes no sense (as the /xy prefix will belong to another customer next day), but as soon as those assignment-size attributes will pop up, misguided folks _will_ start using them for broken heuristics and cause colateral damage.
My opposition is solely about the assignment-size attribute being mandatory.
Best regards, Daniel
Hi, I agree with Daniel's arguments regarding the mandatory and visible status of the proposed new "assignment-size" attribute.
Regards, Valeriu.
================================= Valeriu VRACIU Network Engineer at RoEduNet tel: +40 (232) 201003 fax: +40 (232) 201200 GSM: +40 (744) 615251 e-mail: valeriu.vraciu@roedu.net ================================= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1BJj0ACgkQncI+CatY9492fwCgiELB3MnMtLYpI1R/INqTgzsZ /DEAninsMzBnbJGgTVA+qfzMg2OoOTYl =JnxM -----END PGP SIGNATURE-----
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383.
On 01/26/2011 09:36 PM, Daniel Roesen wrote:
On Tue, Jan 25, 2011 at 09:40:54PM -0800, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal".
The only one who needs the assignment size is RIPE NCC when evaluating new allocation requests or in audit. At that time, it's easy for the LIR to provide this info to NCC for HD ratio evaluation. Following the spirit of data protection, we shouldn't put (in a mandatory manner) more potentially sensitive data into public databases without a good justification for the need to have that data public.
As a second reason, it allows folks running block lists to again start blocking dynamic customer IP prefixes by automatically looking up the assignment-size. Of course that makes no sense (as the /xy prefix will belong to another customer next day), but as soon as those assignment-size attributes will pop up, misguided folks _will_ start using them for broken heuristics and cause colateral damage.
My opposition is solely about the assignment-size attribute being mandatory.
Best regards, Daniel
Daniel, I share your concerns as I had similar ones. You could always avoid using "remarks" and/or description for such published blocks. Of course, it's not bulletproof. In any case, I support the proposal regards, Yannis
On Wednesday, January 26, 2011 09:36:55 pm Daniel Roesen wrote: <snip> ...
I oppose on grounds of paragraph 2 of "Arguments Opposing the Proposal".
The only one who needs the assignment size is RIPE NCC when evaluating new allocation requests or in audit. ... </snip>
I am sure that RIPE NCC is not the only interested party for the publication of an assignment-size attribute. I think the advantages clearly outweigh the disadvantages here. I support this proposal. Regards, Kostas
On Thu, Jan 27, 2011 at 11:38:46AM +0200, Kostas Zorbadelos wrote:
I am sure that RIPE NCC is not the only interested party for the publication of an assignment-size attribute.
Interest != need. Publishing potentially sensitive data just because people are "interested" is not a good enough reason in my book of data protection principles. Next time people ask for weekly updated fill-level: attributes in PD pools so "interested" folks can "transparently" verify wether usage levels are according to the rules that NCC enforces (and obtain further business intelligence as a side effect, how convenient). Anyway, as the proposal is in Last Call, I'll rest my case. I'm still totally unconvinced that this a good idea. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 26 Jan 2011, at 05:40, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. [...]
I support this proposal. Andy
Support On 26 Jan 2011, at 20:42, "Andy Davidson" <andy@nosignal.org> wrote:
On 26 Jan 2011, at 05:40, David Kessens wrote:
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. [...]
I support this proposal.
Andy
We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. [...]
Support -- Laurent Mele Groupe INFOCLIP Directeur Technique 32 avenue Corentin Cariou 75 019 PARIS Tél : +33 (0) 1 43 18 19 20 Fax : +33 (0) 1 43 18 19 29 PGP KeyFingerPrint : 6E9D 5F72 6C21 1194 C00F E6AC 6102 CCEA BD33 731A
I support this proposal. Wolfgang ________________________________________ Von: ipv6-wg-admin@ripe.net [ipv6-wg-admin@ripe.net]" im Auftrag von "David Kessens [david.kessens@nsn.com] Gesendet: Mittwoch, 26. Januar 2011 06:40 An: ipv6-wg Cc: db-wg@ripe.net; address-policy-wg@ripe.net Betreff: Re: [ipv6-wg] 2010-06 is going to Last Call [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote:
Hello,
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010).
You can see the policy proposal here:
http://ripe.net/ripe/policies/proposals/2010-06.html
There were some clarifications during the Review Phase, but nothing indicating changes needed.
David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.)
The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
-- Shane
On Tue, 2011-01-25 at 21:40 -0800, David Kessens wrote:
support. -- Daniel Verlouw, Network Engineer BIT BV | info@bit.nl | +31 318 648688 KvK: 09090351 | GPG: 0x48ED5D99 | DV244-RIPE
+1 Regards Ragnar Anfinsen Altibox AS [ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ] All, We have not received any input so far whether you support draft policy 2010-06. While silence will in general be interpreted as consensus, we prefer to have a good number of statements of support as that will make it unequivocally clear that consensus was indeed reached. The last call period will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then. Thanks, David & Shane --- On Thu, Jan 06, 2011 at 02:20:25PM +0100, Shane Kerr wrote:
Hello,
[ Courtesy copy sent to address policy and database working groups. Please follow up on the ipv6-wg list. ]
The Review Phase for the RIPE policy proposal 2010-06 ended on 2010-12-27 (Monday, 27 December 2010).
You can see the policy proposal here:
http://ripe.net/ripe/policies/proposals/2010-06.html
There were some clarifications during the Review Phase, but nothing indicating changes needed.
David and I have decided that the proposal is ready for a Last Call. (As co-author of the proposal, Marco has recused himself from any consensus judgments.)
The last call period is four weeks, so will end 2010-02-03 (Thursday, 3 February 2011). Please e-mail any final comments to ipv6-wg@ripe.net before then.
Thanks,
-- Shane
participants (26)
-
Allan Eising -
Andreas Larsen -
Andy Davidson -
Anfinsen, Ragnar -
Chris Grundemann -
Daniel Roesen -
Daniel Verlouw -
David Freedman -
David Kessens -
Fritsche Wolfgang -
Gunter Van de Velde (gvandeve) -
Hannigan, Martin -
Havard Eidnes -
HOFFMANN, Lionel -
Jan Zorz ＠ go6.si -
Kostas Zorbadelos -
Laurent MELE -
Marco Hogewoning -
Mathieu Paonessa -
Nick Hilliard -
Piotr Strzyzewski -
Remco Van Mook -
Sander Steffann -
Shane Kerr -
Valeriu Vraciu -
Yannis Nikolopoulos