2010-10 New Policy Proposal (Adding reference to sponsoring LIR in inetnum, inet6num and aut-num objects)
Dear Colleagues, A proposed change to RIPE Document ripe-452,"Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2010-10.html We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 10 December 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Emilio Madaio wrote:
Dear Colleagues,
A proposed change to RIPE Document ripe-452,"Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region", is now available for discussion.
You can find the full proposal at:
http://ripe.net/ripe/policies/proposals/2010-10.html
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 10 December 2010.
Regards
Emilio Madaio Policy Development Officer RIPE NCC
Can anybody explain why they feel this should not be done for allocation objects (i.e PA) as well? I think this is completely crazy that we dont have this already and would love to know what kind of misconceived ideas about privacy may have gone into excluding this data in the first place. Dave.
- -- David Freedman Group Network Engineering david.freedman@uk.clara.net Tel +44 (0) 20 7685 8000 Claranet Group 21 Southampton Row London - WC1B 5HA - UK http://www.claranet.com Company Registration: 3152737 - Place of registration: England All the information contained within this electronic message from Claranet Ltd is covered by the disclaimer at http://www.claranet.co.uk/disclaimer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzdONgACgkQtFWeqpgEZrLpTACgunEAjVbsHVf8A/uv64MXaBYs G2AAoKfA47vazLJdJ5g4yfX4VDf+LrHr =kG5I -----END PGP SIGNATURE-----
On Fri, Nov 12, 2010 at 12:53:47PM +0000, David Freedman wrote:
Can anybody explain why they feel this should not be done for allocation objects (i.e PA) as well? I think this is completely crazy that we dont
Because those kind of thata are already in the database. Allocations goes directly to LIRs, PA assignments are always under PA allocations.
have this already and would love to know what kind of misconceived ideas about privacy may have gone into excluding this data in the first place.
Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
On 12 November 2010 12:47, Emilio Madaio <emadaio@ripe.net> wrote:
You can find the full proposal at:
http://ripe.net/ripe/policies/proposals/2010-10.html
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 10 December 2010.
Initial thoughts... So what happens to 'orphaned' resources? Are RIPE NCC the 'sponsoring' LIR in this circumstance? Does the NCC have the resources to deal with the increased level of avuse complaints that may be targeted at them with this change? Who would be responsible for maintaining the relationship, the sponsoring LIR or the End user? Does this have an implication for mnt objects? I can see the logic but I think that this has the potential to cause more problems than it solves J -- James Blessing 07989 039 476
On Fri, Nov 12, 2010 at 12:57:16PM +0000, James Blessing wrote:
On 12 November 2010 12:47, Emilio Madaio <emadaio@ripe.net> wrote:
You can find the full proposal at:
http://ripe.net/ripe/policies/proposals/2010-10.html
We encourage you to review this proposal and send your comments to <anti-abuse-wg@ripe.net> before 10 December 2010.
Initial thoughts...
So what happens to 'orphaned' resources? Are RIPE NCC the 'sponsoring' LIR in this circumstance?
If you think in terms of business logic, then answer is: the same as right now. If you think in terms of db logic, then answer is: special object.
Does the NCC have the resources to deal with the increased level of avuse complaints that may be targeted at them with this change?
In my opinion, there will be no problem. Orphaned resource is temporary situation.
Who would be responsible for maintaining the relationship, the sponsoring LIR or the End user? Does this have an implication for mnt objects?
LIR. But to be honest - proposed new prototypes would make this easier, and move this responsibility to automatic robot. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
* James Blessing:
So what happens to 'orphaned' resources? Are RIPE NCC the 'sponsoring' LIR in this circumstance?
If the end user has got a direct contract with RIPE NCC, RIPE NCC should be listed. If the resource is truly orphaned, it should be recovered and eventually reused.
Does the NCC have the resources to deal with the increased level of avuse complaints that may be targeted at them with this change?
I suppose the yearly fee for the direct end-user contract would still cover these costs. If not, the fee could be adjusted.
Who would be responsible for maintaining the relationship, the sponsoring LIR or the End user?
The field makes only sense if it is maintained by RIPE NCC and cannot be edited directly by LIRs nor end users. RIPE NCC could import the appropriate subset of its billing database into the WHOIS database, as far as I understand it.
Does this have an implication for mnt objects?
I don't think so. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Fri, Nov 12, 2010 at 13:47, Emilio Madaio <emadaio@ripe.net> wrote:
Makes sense to me. As an aside, could the RIPE provide an additional diff view of those proposals? Hunting for changes and making sure you didn't miss a potentially crucial word is not that much fun and I suspect most of us end up pasting the text into vimdiff or similar, anyway. Richard
Richard Hartmann wrote:
On Fri, Nov 12, 2010 at 13:47, Emilio Madaio<emadaio@ripe.net> wrote:
Makes sense to me.
As an aside, could the RIPE provide an additional diff view of those proposals? Hunting for changes and making sure you didn't miss a potentially crucial word is not that much fun and I suspect most of us end up pasting the text into vimdiff or similar, anyway.
The only real difference I found was: Notice that the link between resource holder and either LIR or RIPE NCC will be published in the RIPE Database Kind regards, Frank
Richard
-- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
Richard Hartmann wrote:
On Fri, Nov 12, 2010 at 13:47, Emilio Madaio<emadaio@ripe.net> wrote:
Makes sense to me.
As an aside, could the RIPE provide an additional diff view of those proposals? Hunting for changes and making sure you didn't miss a potentially crucial word is not that much fun and I suspect most of us end up pasting the text into vimdiff or similar, anyway.
The only real difference I found was: Notice that the link between resource holder and either LIR or RIPE NCC will be published in the RIPE Database Kind regards, Frank
Richard
-- Mit freundlichen Gruessen, -- PHADE Software - PowerWeb http://www.powerweb.de Inh. Dipl.-Inform. Frank Gadegast mailto:frank@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ====================================================================== Public PGP Key available for frank@powerweb.de
On Fri, Nov 12, 2010 at 14:33, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Notice that the link between resource holder and either LIR or RIPE NCC will be published in the RIPE Database
Yes, I know. Yet, you a) still need to find all the small changes in case they are important after all b) a diff view gives you that in an instant. Richard
* Emilio Madaio:
I support this proposal, seems reasonable to me. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
participants (9)
-
David Freedman -
Emilio Madaio -
Florian Weimer -
Frank Gadegast -
Frank Gadegast -
James Blessing -
Piotr Strzyzewski -
Richard Hartmann -
Richard Hartmann