From mir at ripe.net Fri Feb 1 15:00:54 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 01 Feb 2013 15:00:54 +0100 Subject: [ncc-services-wg] New on RIPE Labs: 1, 000th /22 Allocated from Last /8 Message-ID: <510BCA96.8010009@ripe.net> [apologies for duplicates] Dear colleagues, We allocated the 1,000th /22 from the last /8. Please read more on RIPE Labs: https://labs.ripe.net/Members/ingrid/1000-slash-22s-allocated-from-last-slash-8 Kind regards, Mirjam Kuehne RIPE NCC From randy at psg.com Sun Feb 3 05:14:07 2013 From: randy at psg.com (Randy Bush) Date: Sun, 03 Feb 2013 13:14:07 +0900 Subject: [ncc-services-wg] discussion phase for RIPE policy proposal 2012-07 Message-ID: in case anyone wondered, i support this proposal. and, as iij is now a ripe member, i no longer feel constrained from speaking on policy, so watch out! :) randu From nick at netability.ie Sun Feb 3 23:57:41 2013 From: nick at netability.ie (Nick Hilliard) Date: Sun, 03 Feb 2013 22:57:41 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5101381D.90600@ripe.net> References: <5101381D.90600@ripe.net> Message-ID: <510EEB65.908@netability.ie> On 24/01/2013 13:33, Emilio Madaio wrote: > The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy > Internet Resource Holders", has been revised based on the community > feedback received on the mailing list. We have published the new > version (version 2.0) today. As a result a new Discussion Phase is set > for the proposal. ok, I'll bite. in general, this is a vast improvement on v1.0 and I think it could feasibly form the basis of a working policy, but there are still some shortcomings and omissions which need to be dealt with. LRH == legacy resource holder minor nits: - 1.0 introduction: some legacy resources were assigned by the InterNIC after the creation of the RIPE NCC, so it is incorrect to define LRHs as those who "were granted internet resources before the creation of the RIPE NCC". A similar comment applies to the definition given in 1.1. - section 3.0: contractual requirements: I don't understand why there is a suggested contractual requirement to acknowledge that the terms and conditions of the original assignment are outside the scope of the new contractual arrangement, unless (straw man) someone can provide a copy of those T&Cs. I.e. this is probably unenforceable. I dunno. Looks odd to me. - 4.0: "in cast the situation corresponds to section 2.5 above" - perhaps the authors may have omitted section 2.6? larger grievances: - I don't believe that there is a requirement for section 2.4. Disregarding that the RIPE NCC has ended the possibility of directly assigned resources for general PI holders (which I think has direct relevance to this), I don't accept that a legacy resource holder couldn't find one out of the current 8800 RIPE NCC members that wouldn't be appropriate for a sponsorship contract. - section 2.5: you can't be serious? "due to specific enduring or temporary circumstances"?? This is a carte-blanche for any LRH to ignore this policy until the heat death of the universe. - there is probably a requirement for the LRHs to provide some form of formal identification about who they are and why they have a claim on the resources they claim to hold. For sure, the RIPE NCC cannot certify resources without a reasonable level of due diligence. - the proposed policy does not touch on the subject of transfer of resources to third parties. I think this should be dealt with, and that the RIPE NCC should be required to accept any transfer of resources to third parties. - I'd like to see a requirement for publication of sponsorship details. - the proposed policy does not touch on the subject of deregistration. I believe that it is important to deal with this, as otherwise the RIPE community has no mechanism for garbage collection of resources. The alternative is for the RIPE community to believe that the current set of LHRs will continue to exist until the fall of civilisation and that in this period, they will continue to be the canonical holders of the relevant resources. Not credible. As a subset of this issue, the following sub-issues arise: - there are no terms to deal with what the RIPE NCC should do with the resources in the situation where they are deregistered via whatever mechanism. I would suggest the IANA free pool. - there are no terms to deal with the eventuality that a LRH might want to voluntarily deregister the resources. - there are no terms to deal with the eventuality that all LRHs will eventually cease to exist, whether through bankruptcy, being forgotten, death, winding up, petition, etc. - the root contention with this policy still remains: what happens to those organisations who decline to pay a registration payment and who decline to sign any contract? This policy proposal fails to establish a quid pro quo in this situation. The RIPE NCC does not operate on a zero cost basis, and it is only fair that those who depend on its registration services be required to pay for this. I can understand that many LRHs will have an idealogical objection to this but as King Lear said, "nothing will come of nothing". suggestions: - the RIPE NCC understands PA & PI address blocks. Would it be sensible from a service atomicity/equivalence point of view to suggest that LRHs who are RIPE NCC members receive exactly the same services as PA address holders (after due diligence on identity performed), and that LRH resources handled by sponsoring LIR be provided with the same services as PI address space? - ASNs are the same for everyone, so it would probably be useful to declare that any LRH ASN will receive the same service level as any RIPE NCC-assigned ASN (obviously given suitable contractual link between resource holder and the RIPE NCC). Nick From global-ipcoordinator at atos.net Mon Feb 4 08:44:08 2013 From: global-ipcoordinator at atos.net (Global-IPcoordinator) Date: Mon, 4 Feb 2013 07:44:08 +0000 Subject: [ncc-services-wg] Policy Proposal Message-ID: <72D5630D51F0B94EAFA2F85B12B6D5AD64B211C0@AOWNLEX020.europe.nl.intra> I support https://www.ripe.net/ripe/policies/proposals/2012-07 [cid:image005.png at 01CC4B6F.1519FEE0] Atos Global IP Coordinator Global-IPCoordinator at atos.net [cid:image006.png at 01CC4B6F.1519FEE0] Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld is middels verzending via internet, kan Atos Nederland B.V. niet aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons inspannen een virusvrij netwerk te hanteren, geven wij geen enkele garantie dat dit bericht virusvrij is, noch aanvaarden wij enige aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten waaronder Atos Nederland B.V. goederen en/of diensten levert zijn met uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos Nederland B.V. van toepassing. Deze worden u op aanvraag direct kosteloos toegezonden. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Nederland B.V. group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request. Atos Nederland B.V. / Utrecht KvK Utrecht 30132762 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 853 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 2.jpg Type: image/jpeg Size: 1933 bytes Desc: Picture (Device Independent Bitmap) 2.jpg URL: From Hans.Schulpen at atos.net Mon Feb 4 08:41:50 2013 From: Hans.Schulpen at atos.net (Schulpen, Hans) Date: Mon, 4 Feb 2013 07:41:50 +0000 Subject: [ncc-services-wg] RIPE NCC Services to Legacy Internet Resource Holders Message-ID: <72D5630D51F0B94EAFA2F85B12B6D5AD64B211AD@AOWNLEX020.europe.nl.intra> I support https://www.ripe.net/ripe/policies/proposals/2012-07 [cid:image005.png at 01CC4B6F.1519FEE0] Hans Schulpen IPAM Architect +31 (0)6-30190459 Hans.Schulpen at atos.net Flightforum 3000 5657 EW Eindhoven the Netherlands http://nl.atos.net/ [cid:image006.png at 01CC4B6F.1519FEE0] Dit bericht is vertrouwelijk en kan geheime informatie bevatten enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is bestemd, verzoeken wij u dit onmiddellijk aan ons te melden en het bericht te vernietigen. Aangezien de integriteit van het bericht niet veilig gesteld is middels verzending via internet, kan Atos Nederland B.V. niet aansprakelijk worden gehouden voor de inhoud daarvan. Hoewel wij ons inspannen een virusvrij netwerk te hanteren, geven wij geen enkele garantie dat dit bericht virusvrij is, noch aanvaarden wij enige aansprakelijkheid voor de mogelijke aanwezigheid van een virus in dit bericht. Op al onze rechtsverhoudingen, aanbiedingen en overeenkomsten waaronder Atos Nederland B.V. goederen en/of diensten levert zijn met uitsluiting van alle andere voorwaarden de Leveringsvoorwaarden van Atos Nederland B.V. van toepassing. Deze worden u op aanvraag direct kosteloos toegezonden. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Nederland B.V. group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. On all offers and agreements under which Atos Nederland B.V. supplies goods and/or services of whatever nature, the Terms of Delivery from Atos Nederland B.V. exclusively apply. The Terms of Delivery shall be promptly submitted to you on your request. Atos Nederland B.V. / Utrecht KvK Utrecht 30132762 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 853 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 2.jpg Type: image/jpeg Size: 1933 bytes Desc: Picture (Device Independent Bitmap) 2.jpg URL: From hank at efes.iucc.ac.il Mon Feb 4 10:02:46 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 04 Feb 2013 11:02:46 +0200 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510EEB65.908@netability.ie> References: <5101381D.90600@ripe.net> <5101381D.90600@ripe.net> Message-ID: <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> At 22:57 03/02/2013 +0000, Nick Hilliard wrote: >On 24/01/2013 13:33, Emilio Madaio wrote: > > The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy > > Internet Resource Holders", has been revised based on the community > > feedback received on the mailing list. We have published the new > > version (version 2.0) today. As a result a new Discussion Phase is set > > for the proposal. > >ok, I'll bite. > >in general, this is a vast improvement on v1.0 and I think it could >feasibly form the basis of a working policy, but there are still some >shortcomings and omissions which need to be dealt with. Which we will. We are trying to create a policy/framework to regulate NCC services in regards to LRH - which does not exist today. The question everyone needs to answer is "is what has so far been sent better than no policy?" Do you support the general direction we are going in, ignoring the nits which can easily be fixed? As one of the authors, I'll restate that I think this policy far exceeds the lack of policy that currently exists. Regards, Hank >LRH == legacy resource holder > >minor nits: > >- 1.0 introduction: some legacy resources were assigned by the InterNIC >after the creation of the RIPE NCC, so it is incorrect to define LRHs as >those who "were granted internet resources before the creation of the RIPE >NCC". A similar comment applies to the definition given in 1.1. > >- section 3.0: contractual requirements: I don't understand why there is a >suggested contractual requirement to acknowledge that the terms and >conditions of the original assignment are outside the scope of the new >contractual arrangement, unless (straw man) someone can provide a copy of >those T&Cs. I.e. this is probably unenforceable. I dunno. Looks odd to me. > >- 4.0: "in cast the situation corresponds to section 2.5 above" - perhaps >the authors may have omitted section 2.6? > >larger grievances: > >- I don't believe that there is a requirement for section 2.4. >Disregarding that the RIPE NCC has ended the possibility of directly >assigned resources for general PI holders (which I think has direct >relevance to this), I don't accept that a legacy resource holder couldn't >find one out of the current 8800 RIPE NCC members that wouldn't be >appropriate for a sponsorship contract. > >- section 2.5: you can't be serious? "due to specific enduring or >temporary circumstances"?? This is a carte-blanche for any LRH to ignore >this policy until the heat death of the universe. > >- there is probably a requirement for the LRHs to provide some form of >formal identification about who they are and why they have a claim on the >resources they claim to hold. For sure, the RIPE NCC cannot certify >resources without a reasonable level of due diligence. > >- the proposed policy does not touch on the subject of transfer of >resources to third parties. I think this should be dealt with, and that >the RIPE NCC should be required to accept any transfer of resources to >third parties. > >- I'd like to see a requirement for publication of sponsorship details. > >- the proposed policy does not touch on the subject of deregistration. I >believe that it is important to deal with this, as otherwise the RIPE >community has no mechanism for garbage collection of resources. The >alternative is for the RIPE community to believe that the current set of >LHRs will continue to exist until the fall of civilisation and that in this >period, they will continue to be the canonical holders of the relevant >resources. Not credible. > >As a subset of this issue, the following sub-issues arise: > > - there are no terms to deal with what the RIPE NCC should do > with the >resources in the situation where they are deregistered via whatever >mechanism. I would suggest the IANA free pool. > > - there are no terms to deal with the eventuality that a LRH > might want to >voluntarily deregister the resources. > > - there are no terms to deal with the eventuality that all LRHs will >eventually cease to exist, whether through bankruptcy, being forgotten, >death, winding up, petition, etc. > >- the root contention with this policy still remains: what happens to >those organisations who decline to pay a registration payment and who >decline to sign any contract? This policy proposal fails to establish a >quid pro quo in this situation. The RIPE NCC does not operate on a zero >cost basis, and it is only fair that those who depend on its registration >services be required to pay for this. I can understand that many LRHs will >have an idealogical objection to this but as King Lear said, "nothing will >come of nothing". > >suggestions: > >- the RIPE NCC understands PA & PI address blocks. Would it be sensible >from a service atomicity/equivalence point of view to suggest that LRHs who >are RIPE NCC members receive exactly the same services as PA address >holders (after due diligence on identity performed), and that LRH resources >handled by sponsoring LIR be provided with the same services as PI address >space? > >- ASNs are the same for everyone, so it would probably be useful to declare >that any LRH ASN will receive the same service level as any RIPE >NCC-assigned ASN (obviously given suitable contractual link between >resource holder and the RIPE NCC). > >Nick From nick at netability.ie Mon Feb 4 11:51:25 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 04 Feb 2013 10:51:25 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> References: <5101381D.90600@ripe.net> <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> Message-ID: <510F92AD.6070003@netability.ie> On 04/02/2013 09:02, Hank Nussbacher wrote: > Which we will. We are trying to create a policy/framework to regulate NCC > services in regards to LRH - which does not exist today. > > The question everyone needs to answer is "is what has so far been sent > better than no policy?" Do you support the general direction we are going > in, ignoring the nits which can easily be fixed? The general direction is great and I think this update to the proposal is a huge improvement on v1.0, but do not support the policy proposal as it stands because it still has critical problems. The most important of these problems is a discussion / decision about what to do with registration services for legacy resource holders / legacy resources who do not engage with the RIPE NCC. There are other serious problems with the proposal too, and a couple of nits which are easily fixable. Nick From Robert.Sleigh at ee.co.uk Mon Feb 4 12:11:34 2013 From: Robert.Sleigh at ee.co.uk (Sleigh, Robert) Date: Mon, 4 Feb 2013 11:11:34 -0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5101381D.90600@ripe.net> References: <5101381D.90600@ripe.net> Message-ID: <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> Hi This proposal seems to me to provide a reasonable balance between legacy holders existing rights and the community's wish to improve the accuracy of registration data. It provides for several options relating to the engagement between the legacy holders and RIPE, in recognition of the wide range of organisations who are legacy holders. I therefore support this proposal Regards Bob 07958 318592 Life's for sharing... and what I like to share the most is a smile -----Original Message----- From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Emilio Madaio Sent: 24 January 2013 13:33 To: ncc-services-wg at ripe.net Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) Dear Colleagues, The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders", has been revised based on the community feedback received on the mailing list. We have published the new version (version 2.0) today. As a result a new Discussion Phase is set for the proposal. Highlights of the changes: -general rearrangement of the proposal sections -overall rewording of the whole policy proposal text -new Rationale section You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-07 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC NOTICE AND DISCLAIMER This e-mail (including any attachments) is intended for the above-named person(s). If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose. We may monitor all incoming and outgoing emails in line with current legislation. We have taken steps to ensure that this email and attachments are free from any virus, but it remains your responsibility to ensure that viruses do not adversely affect you. Everything Everywhere Limited Registered in England and Wales Company Registered Number: 02382161 Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW From sander at steffann.nl Mon Feb 4 12:22:06 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2013 12:22:06 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> Message-ID: Hi Robert, > This proposal seems to me to provide a reasonable balance between legacy > holders existing rights and the community's wish to improve the accuracy > of registration data. > > It provides for several options relating to the engagement between the > legacy holders and RIPE, in recognition of the wide range of > organisations who are legacy holders. That was our aim when writing the text :-) > I therefore support this proposal Thanks, Sander From nick at netability.ie Mon Feb 4 12:38:04 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 04 Feb 2013 11:38:04 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> Message-ID: <510F9D9C.7040100@netability.ie> On 04/02/2013 11:11, Sleigh, Robert wrote: > It provides for several options relating to the engagement between the > legacy holders and RIPE, in recognition of the wide range of > organisations who are legacy holders. It also provides multiple options for LRHs to completely ignore the RIPE NCC forever. I don't believe that this constitutes good stewardship of resource registration on the part of the RIPE NCC. Nick From sander at steffann.nl Mon Feb 4 12:59:08 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 4 Feb 2013 12:59:08 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510F9D9C.7040100@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> Message-ID: Hi Nick, >> It provides for several options relating to the engagement between the >> legacy holders and RIPE, in recognition of the wide range of >> organisations who are legacy holders. > > It also provides multiple options for LRHs to completely ignore the RIPE > NCC forever. I don't believe that this constitutes good stewardship of > resource registration on the part of the RIPE NCC. I think the point here is that the RIPE NCC wasn't involved in the original resource registration in the first place. I think it's (legally?) not possible to force legacy holders to work with the RIPE NCC because they got their address space before the RIPE NCC even existed and/or started to register resources with no strings attached, and I don't think you can expect the RIPE NCC to maintain good stewardship for resources that they don't have strings on... (probably not good English, but I hope you understand what I mean ;-) This proposal tries to bring the legacy resource holders and the RIPE NCC together under mutually acceptable conditions to create a situation of good stewardship as far as possible. It won't be perfect. Address space got given away without any conditions attached at the beginning of the internet, and now we have to deal with that. Thanks, Sander From stolpe at resilans.se Mon Feb 4 13:12:43 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 4 Feb 2013 13:12:43 +0100 (CET) Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510EEB65.908@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> Message-ID: On Sun, 3 Feb 2013, Nick Hilliard wrote: > On 24/01/2013 13:33, Emilio Madaio wrote: >> The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy >> Internet Resource Holders", has been revised based on the community >> feedback received on the mailing list. We have published the new >> version (version 2.0) today. As a result a new Discussion Phase is set >> for the proposal. > > ok, I'll bite. > > in general, this is a vast improvement on v1.0 and I think it could > feasibly form the basis of a working policy, but there are still some > shortcomings and omissions which need to be dealt with. In general yes. Well done so far. > LRH == legacy resource holder > > minor nits: > > - 1.0 introduction: some legacy resources were assigned by the InterNIC > after the creation of the RIPE NCC, so it is incorrect to define LRHs as > those who "were granted internet resources before the creation of the RIPE > NCC". A similar comment applies to the definition given in 1.1. Might seem minor but the definition certainly has to be correct. > - section 3.0: contractual requirements: I don't understand why there is a > suggested contractual requirement to acknowledge that the terms and > conditions of the original assignment are outside the scope of the new > contractual arrangement, unless (straw man) someone can provide a copy of > those T&Cs. I.e. this is probably unenforceable. I dunno. Looks odd to me. > > - 4.0: "in cast the situation corresponds to section 2.5 above" - perhaps > the authors may have omitted section 2.6? > > larger grievances: > > - I don't believe that there is a requirement for section 2.4. > Disregarding that the RIPE NCC has ended the possibility of directly > assigned resources for general PI holders (which I think has direct > relevance to this), I don't accept that a legacy resource holder couldn't > find one out of the current 8800 RIPE NCC members that wouldn't be > appropriate for a sponsorship contract. It does sound odd that when we are going away from the direct relation between the RIPE NCC and end users we are suggesting new relationships of the same kind. Find an LIR or become one. That should be enough. > - section 2.5: you can't be serious? "due to specific enduring or > temporary circumstances"?? This is a carte-blanche for any LRH to ignore > this policy until the heat death of the universe. I feel a bit lost here. What circumstances are we talking about? > - there is probably a requirement for the LRHs to provide some form of > formal identification about who they are and why they have a claim on the > resources they claim to hold. For sure, the RIPE NCC cannot certify > resources without a reasonable level of due diligence. This is usually the biggest obstacle in my experience. We regularly help LRH:s with these matters and I think there should be clearer definitions of the paper work needed for identification. We are often talking about events 15-20 years back and since many LRH:s are large corporate groups they have often changed names and structure a few times since and now they have no idea what documentation to provide to prove they are acually the same entity. > - the proposed policy does not touch on the subject of transfer of > resources to third parties. I think this should be dealt with, and that > the RIPE NCC should be required to accept any transfer of resources to > third parties. > > - I'd like to see a requirement for publication of sponsorship details. > > - the proposed policy does not touch on the subject of deregistration. I > believe that it is important to deal with this, as otherwise the RIPE > community has no mechanism for garbage collection of resources. The > alternative is for the RIPE community to believe that the current set of > LHRs will continue to exist until the fall of civilisation and that in this > period, they will continue to be the canonical holders of the relevant > resources. Not credible. > > As a subset of this issue, the following sub-issues arise: > > - there are no terms to deal with what the RIPE NCC should do with the > resources in the situation where they are deregistered via whatever > mechanism. I would suggest the IANA free pool. > > - there are no terms to deal with the eventuality that a LRH might want to > voluntarily deregister the resources. > > - there are no terms to deal with the eventuality that all LRHs will > eventually cease to exist, whether through bankruptcy, being forgotten, > death, winding up, petition, etc. > > - the root contention with this policy still remains: what happens to > those organisations who decline to pay a registration payment and who > decline to sign any contract? This policy proposal fails to establish a > quid pro quo in this situation. The RIPE NCC does not operate on a zero > cost basis, and it is only fair that those who depend on its registration > services be required to pay for this. I can understand that many LRHs will > have an idealogical objection to this but as King Lear said, "nothing will > come of nothing". > > suggestions: > > - the RIPE NCC understands PA & PI address blocks. Would it be sensible > from a service atomicity/equivalence point of view to suggest that LRHs who > are RIPE NCC members receive exactly the same services as PA address > holders (after due diligence on identity performed), and that LRH resources > handled by sponsoring LIR be provided with the same services as PI address > space? > > - ASNs are the same for everyone, so it would probably be useful to declare > that any LRH ASN will receive the same service level as any RIPE > NCC-assigned ASN (obviously given suitable contractual link between > resource holder and the RIPE NCC). > > Nick On the whole, very well put Nick. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From nick at netability.ie Mon Feb 4 13:21:15 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 04 Feb 2013 12:21:15 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> Message-ID: <510FA7BB.2020803@netability.ie> On 04/02/2013 11:59, Sander Steffann wrote: > I think the point here is that the RIPE NCC wasn't involved in the > original resource registration in the first place. Correct. As Daniel pointed out some months ago, the issue is solely related to the provision of registration services, not policy surrounding what you can do with the resources[1]. The RIPE NCC is constituted to provide registration services for the RIPE database and has a duty to ensure accuracy and good stewardship of the contents of the database. It is not a charity and according to RIPE NCC statements, ongoing database management is not free. The LRHs have received free, stable and high quality registration services for over 20 years and I am happy for them that this has happened. But I don't believe that it is inappropriate to ask them to pay for registration services in future (or have them covered by options 2.1 / 2.2 in the proposal); otherwise the RIPE NCC members are committing to providing registration services for nonmembers for free in perpetuity. There is no quid-pro-quo in this sort of relationship. I don't see any basis upon which to attempt to impose RIPE resource management policy on legacy resources, but payment for services received is fundamental. Nick -- [1] with the exception of dealing with the situation of what happens when the LRH ceases to exist or if they decide to voluntarily rescind any claim on the resources. From jim at rfc1035.com Mon Feb 4 13:28:42 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 4 Feb 2013 12:28:42 +0000 Subject: [ncc-services-wg] Finalising 2012-07 In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> Message-ID: <857254FB-FF6C-4917-A1B9-BC4363AD10B9@rfc1035.com> On 4 Feb 2013, at 11:59, Sander Steffann wrote: > This proposal tries to bring the legacy resource holders and the RIPE NCC together under mutually acceptable conditions to create a situation of good stewardship as far as possible. It won't be perfect. Address space got given away without any conditions attached at the beginning of the internet, and now we have to deal with that. +1 IMO the revised proposal is the least-worst pragmatic way of dealing with the issue. It's doubtful anything better could be developed or that a quest for perfection would be successful some time before IPv6 runs out. Let's fact it: some legacy holders will want to bring their resources inside the NCC tent and others won't or can't. No amount of debate here will change that. The latest version of 2012-07 deserves support. We should also remember if 20120-7 gets passed and then turns out to have been a mistake, it can be fixed later. Our policy making process should be responsive to the needs of the community and the prevailing circumstances. From jim at rfc1035.com Mon Feb 4 14:47:07 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 4 Feb 2013 13:47:07 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <510FA7BB.2020803@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> Message-ID: On 4 Feb 2013, at 12:21, Nick Hilliard wrote: > but payment for services received is fundamental. Nick, I agree with the general principle that everybody using NCC services should pay their fair share. However IMO it would be best to apply a bit of compromise and pragmatism in this case. The "core" service for legacy holders is maintaining the database objects for those resources. The supporting infrastructure for that -- database systems, DNS/whois servers, LIR portal, etc -- already exist. So the incremental cost to the NCC of making that platform available to legacy holders should be very low. It may well cost the NCC more to bill legacy holders for a few Euro each time they change a reverse DNS delegation or update a contact object. I'd be very uneasy about introducing measures (ie fees) which discourage legacy holders to keep their registration data up to date. After all what's *really* more important here, a complete (ish) registration database that can be relied upon or some accountancy paperwork? On-going care and maintenance of the registration database is the NCC's prime reason to exist. IMO, that means the NCC has inherited the overheads of proving that for the legacy holders in its service region and is stuck with that. It's simply the cost of doing business and the NCC just has to suck it up. Sorry. I'm sure the NCC staff and board will keep an eye on the actual costs of providing registration services "for free" to legacy holders if 2012-07 is passed. If those costs turn out to be a burden, we should trust The Management to bring this to the attention of the WGs and the NCC membership. So let's get on with adopting 2012-07. The policy can always be reviewed in light of actual experience. Personally, I disagree with the definition of Registry Services in 2012-07. IMO it should not include certification of registration data. [If legacy holders want that, they should become NCC members as far as I'm concerned.] After all, resource certification was not a service which existed when the legacy holders originally got their resources. So the services they get "for free" now should be the same as the services they got for free from the InterNIC. However I go along with the definition in 2012-07 as a compromise in order to help arrive at a consensus policy. I hope you can compromise too. BTW, there's a lot of irony on my part here. I don't represent an LIR or legacy holder. There's a fair bit hypocrisy too because I'm a strong advocate of the NCC not doing stuff "for free". And now I'm another non-member suggesting how NCC members' money gets spent. So shoot me... PS: apologies for using a meaningful Subject: header. :-) From niall.oreilly at ucd.ie Mon Feb 4 14:42:55 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Mon, 4 Feb 2013 13:42:55 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510EEB65.908@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> Message-ID: <051AC5C5-E78B-4942-93A2-3095BBA933F3@ucd.ie> Nick, On 3 Feb 2013, at 22:57, Nick Hilliard wrote: > ok, I'll bite. Thanks for engaging so thoroughly! Apart from nits which I expect will be dealt with in due course, and points which are outside what I believe we (the co-authors) see as the scope of this proposal, I understand the following 2 points as your main ones. > - I don't believe that there is a requirement for section 2.4. > [...] I don't accept that a legacy resource holder couldn't > find one out of the current 8800 RIPE NCC members that wouldn't be > appropriate for a sponsorship contract. I see that as a guess. I hope you're right. If you are, keeping the section appears to be harmless; otherwise, it seems to be needed to fill an unfortunate gap. > - section 2.5: you can't be serious? "due to specific enduring or > temporary circumstances"?? This is a carte-blanche for any LRH to ignore > this policy until the heat death of the universe. I believe that appropriate checks and balances are available. I expect that any LRH apparently claiming _undue_ special accommodation under this section would be likely to draw an uncooperative reaction from the RIPE NCC. Personally (I mean, representing the position neither of my employer nor of any of the co-authors of the proposal), I would find this quite reasonable. At such a stage, an aggrieved LRH acting in good faith would have recourse to the process of section 5.0. ATB /Niall From nick at netability.ie Mon Feb 4 15:18:33 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 04 Feb 2013 14:18:33 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <051AC5C5-E78B-4942-93A2-3095BBA933F3@ucd.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <051AC5C5-E78B-4942-93A2-3095BBA933F3@ucd.ie> Message-ID: <510FC339.8050907@netability.ie> On 04/02/2013 13:42, Niall O'Reilly wrote: > and points which are outside what I believe we (the co-authors) see > as the scope of this proposal If you're going to propose a policy which gives carte blanche to LRHs never to pay a penny for all eternity in return for reliable registration services, then please provide appropriate justification. Nick From ms at uakom.sk Mon Feb 4 15:36:14 2013 From: ms at uakom.sk (Martin Stanislav) Date: Mon, 4 Feb 2013 15:36:14 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> Message-ID: <20130204143614.GA8673@moon.uakom.sk> On Mon, Feb 04, 2013 at 01:12:43PM +0100, Daniel Stolpe wrote: > >in general, this is a vast improvement on v1.0 and I think it could > >feasibly form the basis of a working policy, but there are still some > >shortcomings and omissions which need to be dealt with. > > In general yes. Well done so far. Agree. > >LRH == legacy resource holder > > > >minor nits: > > > >- 1.0 introduction: some legacy resources were assigned by the InterNIC > >after the creation of the RIPE NCC, so it is incorrect to define LRHs as > >those who "were granted internet resources before the creation of the RIPE > >NCC". A similar comment applies to the definition given in 1.1. > > Might seem minor but the definition certainly has to be correct. OK, 1.0 introduction wording can be improved a bit. But, the definition in 1.1: -- Legacy Internet Resource: Any Internet Resource granted before the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries became operational. -- seems to mimic a definition of "Early registration" in ripe-581: https://www.ripe.net/ripe/docs/ripe-581/ ... 1.2 Early registration: IPv4 address space assigned or allocated before the establishment of the Regional Internet Registries (RIRs)." This ripe-581 definition of an early registration probably implicitly assumes a time point of establishing a RIR in the respective region an IPv4 address space was allocated/assigned through. Back to the proposed 1.1 wording, IMO the current system of hierarchical distribution is unlikely to be considered operational before InterNIC ceased to exist and ARIN became operational. > >larger grievances: > > > >- I don't believe that there is a requirement for section 2.4. > >Disregarding that the RIPE NCC has ended the possibility of directly > >assigned resources for general PI holders (which I think has direct > >relevance to this), I don't accept that a legacy resource holder couldn't > >find one out of the current 8800 RIPE NCC members that wouldn't be > >appropriate for a sponsorship contract. > > It does sound odd that when we are going away from the direct relation > between the RIPE NCC and end users we are suggesting new relationships of > the same kind. > > Find an LIR or become one. That should be enough. Are you also suggesting that RIPE NCC should stop providing a PI holder (a non-member) with a possibility to become a Direct Assignment User via signing a direct contract with NCC (ripe-518)? > >- section 2.5: you can't be serious? "due to specific enduring or > >temporary circumstances"?? This is a carte-blanche for any LRH to ignore > >this policy until the heat death of the universe. > > I feel a bit lost here. What circumstances are we talking about? Just thinking out loudly. Perhaps, a disputed resource holder identification or existence? That's a case when a second paragraph in the section 2.5 is to become applicable. > >- there is probably a requirement for the LRHs to provide some form of > >formal identification about who they are and why they have a claim on the > >resources they claim to hold. For sure, the RIPE NCC cannot certify > >resources without a reasonable level of due diligence. > > This is usually the biggest obstacle in my experience. We regularly help > LRH:s with these matters and I think there should be clearer definitions > of the paper work needed for identification. We are often talking about > events 15-20 years back and since many LRH:s are large corporate groups > they have often changed names and structure a few times since and now they > have no idea what documentation to provide to prove they are acually the > same entity. Maybe RIPE NCC can help here, since mergers, takeovers and cease to exist situations do happen with LIRs or PI holders as well. And RIPE NCC is likely to have some experience in this area. Though, there are differences complicating the matter a bit. No initial relationship between the RIPE NCC and a LRH and a rather long time span. Have some of the related issues been sorted out during the ERX project? I support the proposed policy 2012-07 as it is. Sure, the text can be improved and I'm likely to restate the support in such case. Martin From Woeber at CC.UniVie.ac.at Mon Feb 4 15:26:03 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 04 Feb 2013 15:26:03 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> Message-ID: <510FC4FB.5060108@CC.UniVie.ac.at> Daniel Stolpe wrote: > > On Sun, 3 Feb 2013, Nick Hilliard wrote: > >> On 24/01/2013 13:33, Emilio Madaio wrote: >> >>> The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy >>> Internet Resource Holders", has been revised based on the community >>> feedback received on the mailing list. We have published the new >>> version (version 2.0) today. As a result a new Discussion Phase is set >>> for the proposal. >> >> >> ok, I'll bite. >> >> in general, this is a vast improvement on v1.0 and I think it could >> feasibly form the basis of a working policy, but there are still some >> shortcomings and omissions which need to be dealt with. > > > In general yes. Well done so far. > >> LRH == legacy resource holder >> >> minor nits: >> >> - 1.0 introduction: some legacy resources were assigned by the InterNIC >> after the creation of the RIPE NCC, so it is incorrect to define LRHs as >> those who "were granted internet resources before the creation of the >> RIPE >> NCC". A similar comment applies to the definition given in 1.1. > > > Might seem minor but the definition certainly has to be correct. True. I propose to turn the logic around, i.e. resources not obtained by way of an RIR, because the initial set of 3 RIRs were not born on the same date :-) Incidentally, the RIPE NCC was the first one to exist. >> - section 3.0: contractual requirements: I don't understand why there >> is a >> suggested contractual requirement to acknowledge that the terms and >> conditions of the original assignment are outside the scope of the new >> contractual arrangement, unless (straw man) someone can provide a copy of >> those T&Cs. I.e. this is probably unenforceable. I dunno. Looks odd >> to me. >> >> - 4.0: "in cast the situation corresponds to section 2.5 above" - perhaps >> the authors may have omitted section 2.6? >> >> larger grievances: >> >> - I don't believe that there is a requirement for section 2.4. >> Disregarding that the RIPE NCC has ended the possibility of directly >> assigned resources for general PI holders (which I think has direct >> relevance to this), I don't accept that a legacy resource holder couldn't >> find one out of the current 8800 RIPE NCC members that wouldn't be >> appropriate for a sponsorship contract. Well, the LRHs are a mixed crowd out there, and some will indeed have (legal and logistical) problems to sign a contract with an LIR (or the NCC) > It does sound odd that when we are going away from the direct relation > between the RIPE NCC and end users we are suggesting new relationships > of the same kind. > > Find an LIR or become one. That should be enough. Yes, in the vast majority of cases, but we may be faced with a few deadlock cases. Thus I do support the escape path. >> - section 2.5: you can't be serious? "due to specific enduring or >> temporary circumstances"?? This is a carte-blanche for any LRH to ignore >> this policy until the heat death of the universe. Yes, in this version. But let us take the initial steps into the right direction asap and then have a look at where we got, and how quickly. > I feel a bit lost here. What circumstances are we talking about? > >> - there is probably a requirement for the LRHs to provide some form of >> formal identification about who they are and why they have a claim on the >> resources they claim to hold. For sure, the RIPE NCC cannot certify >> resources without a reasonable level of due diligence. Yes, although in reality, the -technically- most credible proof of existence and identity is to look at the connectivity and use for those resources. We are trying to roll back transactions that happened 20+ years ago. Back then, the "documentation" and/or "proof of existence" were a phone call, an email over a set of protocols that didn't even use IP(v4) yet,... :-) > This is usually the biggest obstacle in my experience. We regularly help > LRH:s with these matters and I think there should be clearer definitions > of the paper work needed for identification. We are often talking about > events 15-20 years back and since many LRH:s are large corporate groups > they have often changed names and structure a few times since and now > they have no idea what documentation to provide to prove they are > acually the same entity. The NCC will need a good deal of flexibility and accept different types of "indications", rather than a complete trail of legal paperwork. In some cases it simply will not exist. >> - the proposed policy does not touch on the subject of transfer of >> resources to third parties. I think this should be dealt with, and that >> the RIPE NCC should be required to accept any transfer of resources to >> third parties. >> >> - I'd like to see a requirement for publication of sponsorship details. This seems like a good idea, and iirc is dicussed already under a different headline. >> - the proposed policy does not touch on the subject of deregistration. I >> believe that it is important to deal with this, as otherwise the RIPE >> community has no mechanism for garbage collection of resources. The >> alternative is for the RIPE community to believe that the current set of >> LHRs will continue to exist until the fall of civilisation and that in >> this >> period, they will continue to be the canonical holders of the relevant >> resources. Not credible. >> >> As a subset of this issue, the following sub-issues arise: >> >> - there are no terms to deal with what the RIPE NCC should do with >> the >> resources in the situation where they are deregistered via whatever >> mechanism. I would suggest the IANA free pool. >> >> - there are no terms to deal with the eventuality that a LRH might >> want to >> voluntarily deregister the resources. >> >> - there are no terms to deal with the eventuality that all LRHs will >> eventually cease to exist, whether through bankruptcy, being forgotten, >> death, winding up, petition, etc. >> >> - the root contention with this policy still remains: what happens to >> those organisations who decline to pay a registration payment and who >> decline to sign any contract? This policy proposal fails to establish a >> quid pro quo in this situation. The RIPE NCC does not operate on a zero >> cost basis, and it is only fair that those who depend on its registration >> services be required to pay for this. I can understand that many LRHs >> will >> have an idealogical objection to this but as King Lear said, "nothing >> will >> come of nothing". >> >> suggestions: >> >> - the RIPE NCC understands PA & PI address blocks. Would it be sensible >> from a service atomicity/equivalence point of view to suggest that >> LRHs who >> are RIPE NCC members receive exactly the same services as PA address >> holders (after due diligence on identity performed), and that LRH >> resources >> handled by sponsoring LIR be provided with the same services as PI >> address >> space? >> >> - ASNs are the same for everyone, so it would probably be useful to >> declare >> that any LRH ASN will receive the same service level as any RIPE >> NCC-assigned ASN (obviously given suitable contractual link between >> resource holder and the RIPE NCC). >> >> Nick > > > > On the whole, very well put Nick. > > > Best Regards, > > Daniel Stolpe [ Wearing my hats as LIR manager and employeein the IT department of a University which is itself an LHR ]: While there are still minor improvements to make, I support the proposal. I'd also like to suggest to deal with the management of deregistered or voluntarily returned resources form a higher vantage point, rather than within the framework of a/this special purpose policy. Best regards, Wilfried. From pk at DENIC.DE Mon Feb 4 14:52:14 2013 From: pk at DENIC.DE (Peter Koch) Date: Mon, 4 Feb 2013 14:52:14 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510FA7BB.2020803@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> Message-ID: <20130204135214.GB16212@x28.adm.denic.de> On Mon, Feb 04, 2013 at 12:21:15PM +0000, Nick Hilliard wrote: > I don't see any basis upon which to attempt to impose RIPE resource > management policy on legacy resources, but payment for services received is > fundamental. I'm not sure I can recognize the difference between the two. Unless the NCC or anybody else can demonstrate caveats attached to the early assignments and still given the continuation of the service as implied action, how do you think any group decision could tangibly bring an entity under the umbrella of the PDP that had an implied contract before that time? What is the net gain expected compared to the legal and financial risk? -Peter (as always, expressing his personal opinion) From niall.oreilly at ucd.ie Mon Feb 4 15:53:56 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Mon, 4 Feb 2013 14:53:56 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510FC339.8050907@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <051AC5C5-E78B-4942-93A2-3095BBA933F3@ucd.ie> <510FC339.8050907@netability.ie> Message-ID: <33BF8BD4-E72F-4B36-B1CF-7BF2AE60E833@ucd.ie> On 4 Feb 2013, at 14:18, Nick Hilliard wrote: > If you're going to propose a policy which gives carte blanche to LRHs never > to pay a penny for all eternity in return for reliable registration > services I don't believe I am. You seem to be making a different reading of the proposal from the one I'm making. I've tried to address your objections to the proposed sections 2.4 and 2.5. Have I misunderstood what you meant? Have I perhaps left your "carte blanche" interpretation un-addressed because I've assumed it was derived from section 2.5? Is there something else I'm missing? ATB /Niall From kleefass at belwue.de Mon Feb 4 15:46:36 2013 From: kleefass at belwue.de (Tim Kleefass) Date: Mon, 04 Feb 2013 15:46:36 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> Message-ID: <510FC9CC.8080109@belwue.de> On 04.02.2013 12:11 PM, Sleigh, Robert wrote: > This proposal seems to me to provide a reasonable balance between legacy > holders existing rights and the community's wish to improve the accuracy > of registration data. > > It provides for several options relating to the engagement between the > legacy holders and RIPE, in recognition of the wide range of > organisations who are legacy holders. > > I therefore support this proposal I support this proposal, too. Thanks to Niall et. all. for their work! Regards, Tim From nick at netability.ie Mon Feb 4 16:21:51 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 04 Feb 2013 15:21:51 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <33BF8BD4-E72F-4B36-B1CF-7BF2AE60E833@ucd.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <051AC5C5-E78B-4942-93A2-3095BBA933F3@ucd.ie> <510FC339.8050907@netability.ie> <33BF8BD4-E72F-4B36-B1CF-7BF2AE60E833@ucd.ie> Message-ID: <510FD20F.7020902@netability.ie> On 04/02/2013 14:53, Niall O'Reilly wrote: > You seem to be making a different reading of the proposal from > the one I'm making. my reading of the proposal is that if a LRH wants to engage with the RIPE NCC for registrations services either directly or via a LIR or within existing / new LIR capacity, they can do so. However, section 2.5 carves out an exception for organisations who feel that they are unable to sign a contract for whatever reason, and 2.6 carves out an exception for a broad category of organisations ranging from those who no longer exist to those who have no interest in engaging with the RIPE NCC and decline to answer their phone or reply to emails. This exception appears to entitle these resource holders to continued service on a permanent basis. As an aside to this, the proposed policy and several other people have asserted that there is category of organisations who would be unable to sign a contract for ip registration services either directly or via a sponsoring LIR. Could you elaborate on some concrete examples of this? I'm finding it difficult to understand how the set of organisations who registered IP addresses in the years before 1992 are different from the set of organisations which registered IP addresses via the RIPE NCC such that it's not possible for the former to engage in contractual relationships which seem to be completely standard for the latter. Nick From sid at free.net Mon Feb 4 16:23:42 2013 From: sid at free.net (Dimitri I Sidelnikov) Date: Mon, 4 Feb 2013 19:23:42 +0400 Subject: [ncc-services-wg] RIPE NCC Services to Legacy Internet Resource Holders Message-ID: <9141B3A8C1E443D1AE5C3122C214A1B3@noc.free.net> Hello! I'd like to express my support to https://www.ripe.net/ripe/policies/proposals/2012-07. Regards, --- D.Sidelnikov From hank at efes.iucc.ac.il Mon Feb 4 17:49:00 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 04 Feb 2013 18:49:00 +0200 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510FD20F.7020902@netability.ie> References: <33BF8BD4-E72F-4B36-B1CF-7BF2AE60E833@ucd.ie> <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <051AC5C5-E78B-4942-93A2-3095BBA933F3@ucd.ie> <510FC339.8050907@netability.ie> <33BF8BD4-E72F-4B36-B1CF-7BF2AE60E833@ucd.ie> Message-ID: <5.1.1.6.2.20130204184129.009643f0@efes.iucc.ac.il> At 15:21 04/02/2013 +0000, Nick Hilliard wrote: >On 04/02/2013 14:53, Niall O'Reilly wrote: > > You seem to be making a different reading of the proposal from > > the one I'm making. > >my reading of the proposal is that if a LRH wants to engage with the RIPE >NCC for registrations services either directly or via a LIR or within >existing / new LIR capacity, they can do so. > >However, section 2.5 carves out an exception for organisations who feel >that they are unable to sign a contract for whatever reason, 2.5 states "However, notwithstanding the preceding paragraph, the RIPE NCC may refuse to provide any specific registry service for which particular technical requirements apply, which the Resource Holder is unable to meet." So my reading is that for 2.5 - RIPE NCC can refuse any registry service. >and 2.6 carves >out an exception for a broad category of organisations ranging from those >who no longer exist to those who have no interest in engaging with the RIPE >NCC and decline to answer their phone or reply to emails. and 2.6 states "In such a case, the RIPE NCC will continue to provide those registry services which are already being provided in respect of the Legacy Internet Resource or Resources involved, and may update the related entries in the RIPE Database from time to time to correspond to current actual situation." What do you propose to do for an organization that got IPs in 1990, routes those IPs (meaning they are in use) and doesn't respond to any RIPE NCC email, letter or phone call? To me the options are: a) RIPE NCC just deallocates and deletes the allocated blocks b) RIPE NCC does nothing and does exactly what it does today I do not think RIPE NCC has a legal basis to do (a). That leaves (b). If you can find a better alternative please state it since it would be a welcome option. -Hank >This exception appears to entitle these resource holders to continued >service on a permanent basis. > >As an aside to this, the proposed policy and several other people have >asserted that there is category of organisations who would be unable to >sign a contract for ip registration services either directly or via a >sponsoring LIR. Could you elaborate on some concrete examples of this? >I'm finding it difficult to understand how the set of organisations who >registered IP addresses in the years before 1992 are different from the set >of organisations which registered IP addresses via the RIPE NCC such that >it's not possible for the former to engage in contractual relationships >which seem to be completely standard for the latter. > >Nick From brian.nisbet at heanet.ie Mon Feb 4 18:17:42 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Mon, 04 Feb 2013 17:17:42 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5101381D.90600@ripe.net> References: <5101381D.90600@ripe.net> Message-ID: <510FED36.3080002@heanet.ie> Emilio Madaio wrote the following on 24/01/2013 13:33: > Dear Colleagues, > > The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy > Internet Resource Holders", has been revised based on the community > feedback received on the mailing list. We have published the new > version (version 2.0) today. As a result a new Discussion Phase is set > for the proposal. I like others, do not find this policy proposal to be perfect, but I do think it is a more than acceptable compromise. I think that there are caveats on sections 2.5 & 2.6 that will cover the danger of abuse, but I look forward to Nick telling me that he told us all so as we share a pint during the heat death of universe, the NCC long ago having been destroyed financially by the burden of LHRs. :) All jests aside and not ignoring Nick's points, but finding the text acceptable, I would like to note my support for this proposal. Brian From mansaxel at besserwisser.org Mon Feb 4 23:12:12 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Mon, 4 Feb 2013 23:12:12 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> Message-ID: <20130204221212.GB21183@besserwisser.org> Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 Date: Mon, Feb 04, 2013 at 01:47:07PM +0000 Quoting Jim Reid (jim at rfc1035.com): > On 4 Feb 2013, at 12:21, Nick Hilliard wrote: > > > but payment for services received is fundamental. > > Nick, I agree with the general principle that everybody using NCC services should pay their fair share. However IMO it would be best to apply a bit of compromise and pragmatism in this case. > > The "core" service for legacy holders is maintaining the database objects for those resources. The supporting infrastructure for that -- database systems, DNS/whois servers, LIR portal, etc -- already exist. So the incremental cost to the NCC of making that platform available to legacy holders should be very low. It may well cost the NCC more to bill legacy holders for a few Euro each time they change a reverse DNS delegation or update a contact object. I'd be very uneasy about introducing measures (ie fees) which discourage legacy holders to keep their registration data up to date. After all what's *really* more important here, a complete (ish) registration database that can be relied upon or some accountancy paperwork? I represent a LRH in this context. We do have a LIR relation, are being good netizens, and do pay for services related to some services and resources. (ASN, v6 /48, a couple swampspace PI C-nets). But, our LIR has no hand in us having a B net. We simply have it, and we treat it like any other resource, except that the loan is a little more permanent. The point is, I do not think we're that unique. A lot of the legacy holders have some LIR relationship as it is. Or are LIRen. The "completely estranged LRH holder organisation" is not that common, I believe. Wasting electrons on this corner case is not fruitful. Nor is it going to be the cornucopia feeding hostmasters great paychecks and getting fees on RIPE services slashed. > On-going care and maintenance of the registration database is the NCC's prime reason to exist. IMO, that means the NCC has inherited the overheads of proving that for the legacy holders in its service region and is stuck with that. It's simply the cost of doing business and the NCC just has to suck it up. Sorry. I'd go even further than that and say that the value of the NCC database as a routing registry or "abuse tool" or whatever it is used for is _directly_related_ to it being as complete as possible. It ought to be a major goal of any RIR to achieve total coverage of used resources. It is IMNSHO so important for the perception of the registry that it is complete that forcing resources out because the holder won't pay probably has severe career- limiting consequences. And I believe that the NCC basically has understood this, even if the accounting department is annoyed and wants Ordnung. > I'm sure the NCC staff and board will keep an eye on the actual costs of providing registration services "for free" to legacy holders if 2012-07 is passed. If those costs turn out to be a burden, we should trust The Management to bring this to the attention of the WGs and the NCC membership. So let's get on with adopting 2012-07. The policy can always be reviewed in light of actual experience. Indeed. As probably can be derived from above, I support the policy proposal as it stands. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Oh, I get it!! "The BEACH goes on", huh, SONNY?? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From randy at psg.com Tue Feb 5 08:55:38 2013 From: randy at psg.com (Randy Bush) Date: Tue, 05 Feb 2013 16:55:38 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510F92AD.6070003@netability.ie> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> Message-ID: > The general direction is great and I think this update to the proposal > is a huge improvement on v1.0, but do not support the policy proposal > as it stands because it still has critical problems. The most > important of these problems is a discussion / decision about what to > do with registration services for legacy resource holders / legacy > resources who do not engage with the RIPE NCC. There are other > serious problems with the proposal too, and a couple of nits which are > easily fixable. nick, do you happen to have constructive ideas or text for the issues you raise? < personal opinion > if they are unresponsive or do not wishfees to engage, i am torn between the need for the best whois and dns data we can publish and being pretty cold. this, of course, assumes that we make it non-onerous for them to engage. > It also provides multiple options for LRHs to completely ignore the > RIPE NCC forever. I don't believe that this constitutes good > stewardship of resource registration on the part of the RIPE NCC. unfortunately, that is the status quo. and we kind of have a historical obligation to allow them to ignore the ncc. but perhaps a carrot, as opposed to a stick, can significantly improve this. > I don't believe that there is a requirement for section 2.4. [...] I > don't accept that a legacy resource holder couldn't find one out of > the current 8800 RIPE NCC members that wouldn't be appropriate for a > sponsorship contract. there are lrhs who, for organizational reasons, can not sign under an lir. and they also do not wish to give up rights to the lh implied by existing lir contracts, or to pay rental for integers for which the rir has never been the landlord. the alternatives you suggest have existed for some time. no one was attracted. as an engineer, i try to judge by the results. 2.4 is meant to be a reasonable compromise, good data, a real relationship, and small fees for services actually provided. --- i think sander said it well: > This proposal tries to bring the legacy resource holders and the RIPE > NCC together under mutually acceptable conditions to create a > situation of good stewardship as far as possible. It won't be perfect. > Address space got given away without any conditions attached at the > beginning of the internet, and now we have to deal with that. suggestions on how to better achieve these goals would be greatly appreciated of course. randy From Woeber at CC.UniVie.ac.at Tue Feb 5 13:47:38 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 05 Feb 2013 13:47:38 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> Message-ID: <5110FF6A.8010605@CC.UniVie.ac.at> Randy Bush wrote: [...] >>It also provides multiple options for LRHs to completely ignore the >>RIPE NCC forever. I don't believe that this constitutes good >>stewardship of resource registration on the part of the RIPE NCC. > > > unfortunately, that is the status quo. and we kind of have a historical > obligation to allow them to ignore the ncc. but perhaps a carrot, as > opposed to a stick, can significantly improve this. Indeed. Coming back after stating my general support yesterday, to one of the individual issues that may benefit from changes: I don't remember who already pointed fingers at the ROA service (thanks!), but we - eventually - may have a pretty convincing carrot by offering the "Certification of these data;" (which I read as being ROA and future friends) only to LHRs that have established a formal relationship and are paying for the service according to 2.1 ... 2.4. Certification is a service that has been developed recently by the RIRs, so IMO there is no legacy "right" here. This would apply for the cases described in 2.5 and certainly 2.6. [...] > --- > > i think sander said it well: +1 Wilfried >>This proposal tries to bring the legacy resource holders and the RIPE >>NCC together under mutually acceptable conditions to create a >>situation of good stewardship as far as possible. It won't be perfect. >>Address space got given away without any conditions attached at the >>beginning of the internet, and now we have to deal with that. > > > suggestions on how to better achieve these goals would be greatly > appreciated of course. > > randy From randy at psg.com Tue Feb 5 15:00:53 2013 From: randy at psg.com (Randy Bush) Date: Tue, 05 Feb 2013 23:00:53 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5110FF6A.8010605@CC.UniVie.ac.at> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> Message-ID: > Coming back after stating my general support yesterday, to one of the > individual issues that may benefit from changes: > > I don't remember who already pointed fingers at the ROA service > (thanks!), but we - eventually - may have a pretty convincing carrot > by offering the "Certification of these data;" (which I read as being > ROA and future friends) only to LHRs that have established a formal > relationship and are paying for the service according to 2.1 ... 2.4. > > Certification is a service that has been developed recently by the > RIRs, so IMO there is no legacy "right" here. This would apply for the > cases described in 2.5 and certainly 2.6. < as one of the proposers > this carrot is not accidental. your first paragraph would seem to indicate that you would prefer to dilute this encouragement to form a formal relationship? am i misreading? randy From Woeber at CC.UniVie.ac.at Tue Feb 5 15:23:53 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 05 Feb 2013 15:23:53 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> Message-ID: <511115F9.6090105@CC.UniVie.ac.at> Randy Bush wrote: >>Coming back after stating my general support yesterday, to one of the >>individual issues that may benefit from changes: >> >>I don't remember who already pointed fingers at the ROA service >>(thanks!), but we - eventually - may have a pretty convincing carrot >>by offering the "Certification of these data;" (which I read as being >>ROA and future friends) only to LHRs that have established a formal >>relationship and are paying for the service according to 2.1 ... 2.4. >> >>Certification is a service that has been developed recently by the >>RIRs, so IMO there is no legacy "right" here. This would apply for the >>cases described in 2.5 and certainly 2.6. > > > < as one of the proposers > > > this carrot is not accidental. your first paragraph would seem to > indicate that you would prefer to dilute this encouragement to form > a formal relationship? am i misreading? Yes, I think so :-( Trying again: in 1.1., there's a taxative list of services that includes Cerification, while 2.6 states: "In such a case, the RIPE NCC will *continue to provide those registry services which are already being provided* in respect of the Legacy Internet Resource or Resources involved, and may update the related entries in the RIPE Database from time to time to correspond to current actual situation." I read that as including Certification per the list in 1.1, or am *I* misrading here? > randy Wilfried From randy at psg.com Tue Feb 5 15:30:28 2013 From: randy at psg.com (Randy Bush) Date: Tue, 05 Feb 2013 23:30:28 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <511115F9.6090105@CC.UniVie.ac.at> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> <511115F9.6090105@CC.UniVie.ac.at> Message-ID: > in 1.1., there's a taxative list of services that includes Cerification, > > while 2.6 states: > "In such a case, the RIPE NCC will *continue to provide those registry services > which are already being provided* in respect of the Legacy Internet Resource or > Resources involved, and may update the related entries in the RIPE Database > from time to time to correspond to current actual situation." > > I read that as including Certification per the list in 1.1, > or am *I* misrading here? that was not the intent the sentence of 2.6 you quote would seem to refer to services NOW being provided to lrhs, which do not include certification. but any tweaks to wording to make things clearer greatly appreciated, i am sure. randy From nick at netability.ie Tue Feb 5 16:16:04 2013 From: nick at netability.ie (Nick Hilliard) Date: Tue, 05 Feb 2013 15:16:04 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> <511115F9.6090105@CC.UniVie.ac.at> Message-ID: <51112234.5090701@netability.ie> On 05/02/2013 14:30, Randy Bush wrote: >> I read that as including Certification per the list in 1.1, >> or am *I* misrading here? > > that was not the intent fwiw, i found this quite ambiguous too. It took several careful scans over the doc to figure out the intention. Some wordsmithing here would be quite beneficial. Nick From randy at psg.com Tue Feb 5 16:22:35 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 00:22:35 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <51112234.5090701@netability.ie> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> <511115F9.6090105@CC.UniVie.ac.at> <51112234.5090701@netability.ie> Message-ID: >> that was not the intent > > fwiw, i found this quite ambiguous too. It took several careful scans > over the doc to figure out the intention. Some wordsmithing here > would be quite beneficial. sure. if you confused you and wilfried, then it's a problem for sure. in the infamous words of vince perriello, send code :) in the absence of contribution, i am sure someone far more diligent than i is tracking and hacking. is sure hope so. randy From niall.oreilly at ucd.ie Tue Feb 5 16:24:22 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 5 Feb 2013 15:24:22 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> <511115F9.6090105@CC.UniVie.ac.at> Message-ID: <2B9D6D7C-FD5C-4066-82B7-A81CAEAA83C1@ucd.ie> On 5 Feb 2013, at 14:30, Randy Bush wrote: > that was not the intent > > the sentence of 2.6 you quote would seem to refer to services NOW being > provided to lrhs, which do not include certification. +1 This is intended to ensure operational continuity per service/resource pair, not to create back-door access either to new services or to current services not already provided for a specific resource. An informal summary of the subsections in section 2 might read 2.1 .. 2.3: business as usual; 2.4: new business process for when "usual" doesn't fit a specific case; 2.5: exceptional accommodation for hard cases; 2.6: do no harm. > but any tweaks to wording to make things clearer greatly appreciated, i > am sure. Absolutely, and especially from anyone who sees a divergence between what is in the proposal and what I've offered as a summary above. /Niall From niall.oreilly at ucd.ie Tue Feb 5 16:46:36 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Tue, 5 Feb 2013 15:46:36 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <51112234.5090701@netability.ie> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> <511115F9.6090105@CC.UniVie.ac.at> <51112234.5090701@netability.ie> Message-ID: <00E2D13A-57C7-4E5E-898D-DC3351ABD23A@ucd.ie> On 5 Feb 2013, at 15:16, Nick Hilliard wrote: > fwiw, i found this quite ambiguous too. It took several careful scans over > the doc to figure out the intention. Some wordsmithing here would be quite > beneficial. Version 1 attracted criticism for (among other things!) mixing policy and motivation. I took the message that the policy itself should be as bare as possible, and that the motivation belonged in the discussion on this list. I brought this message to the process of drafting version 2, and pushed the "less is more" notion to the other co-authors. If I've taken this idea further than necessary, I'm sorry. /Niall From Woeber at CC.UniVie.ac.at Tue Feb 5 16:57:29 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Tue, 05 Feb 2013 16:57:29 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5110FF6A.8010605@CC.UniVie.ac.at> <511115F9.6090105@CC.UniVie.ac.at> <51112234.5090701@netability.ie> Message-ID: <51112BE9.7040303@CC.UniVie.ac.at> Randy Bush wrote: >>>that was not the intent >> >>fwiw, i found this quite ambiguous too. It took several careful scans >>over the doc to figure out the intention. Some wordsmithing here >>would be quite beneficial. > > > sure. if you confused you and wilfried, then it's a problem for sure. > > in the infamous words of vince perriello, send code :) How about: " *Registry Services:* Services provided by the RIPE NCC in its capacity as a Regional Internet Registry, including the following traditional registry services, like ? Maintenance of data relating to Internet Resources by the NCC in their Internet Resource registry; ? Access to these data for update by or on behalf of the respective holder; ? Public availability of registration data; ? Delegation of reverse DNS to the registered DNS servers. and such additional or new services as may be identified from time to time as registry services, e.g. ? Certification of these data " Then, in Section 2.0 add to the first paragraph: " In these cases the RIPE NCC provides the full set of services to the LRH as technically or organisationally applicable. " Then in Secction 2.0 add to the second paragraph: " ....below in section 2.5, and the set of services is limited to traditional services. On a case by case bIechnically feasable and in the interest of both parties as well as the [RIPE|Internet] community. " Then in Section 2.0 add to the third paragraph: " The RIPE NCC will continue to provide the traditional services only, and only as long as this policy is in effect. " I know that the last part is redundant, as every policy can be changed in the future, but it may send the message that any LRH would be better off to Do The Right Thing[TM] *now*? Feel free to omit :-) > in the absence of contribution, i am sure someone far more diligent than > i is tracking and hacking. is sure hope so. > > randy Wilfried. From lists-ripe at c4inet.net Tue Feb 5 21:42:13 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 5 Feb 2013 20:42:13 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510EEB65.908@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> Message-ID: <20130205204213.GA72122@cilantro.c4inet.net> On Sun, Feb 03, 2013 at 10:57:41PM +0000, Nick Hilliard wrote: >On 24/01/2013 13:33, Emilio Madaio wrote: >> The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy >> Internet Resource Holders", has been revised based on the community >> feedback received on the mailing list. We have published the new >> version (version 2.0) today. As a result a new Discussion Phase is set >> for the proposal. >- section 2.5: you can't be serious? "due to specific enduring or >temporary circumstances"?? This is a carte-blanche for any LRH to ignore >this policy until the heat death of the universe. Why wouldn't they? RIPE is not a government that can tax things that used to be free or make policy and charge fees for resources they do not own. IMO any LRH who wants to ignore this (and other) policies until the death of the universe is entirely justified in doing so. >- there is probably a requirement for the LRHs to provide some form of >formal identification about who they are and why they have a claim on the >resources they claim to hold. For sure, the RIPE NCC cannot certify >resources without a reasonable level of due diligence. I should be very careful in proposing this in policy. Judging on past record, this will be implemented as an onerous pile of bureaucratic misery. Hardly likely to entice a LRH to engage with the NCC. > >- the proposed policy does not touch on the subject of transfer of >resources to third parties. I think this should be dealt with, and that >the RIPE NCC should be required to accept any transfer of resources to >third parties. Is that a requirement that the NCC *accepts* the transfer or a requirement that the NCC has approval on thoise transfers? >- I'd like to see a requirement for publication of sponsorship details. I will strenuously oppose any policy including such a requirement. I've exhaustively detailed my reasons for that in the 2012-08 thread. >- the proposed policy does not touch on the subject of deregistration. I >believe that it is important to deal with this, as otherwise the RIPE >community has no mechanism for garbage collection of resources. The >alternative is for the RIPE community to believe that the current set of >LHRs will continue to exist until the fall of civilisation and that in this >period, they will continue to be the canonical holders of the relevant >resources. Not credible. IMO, back to the IANA pool whence they came. IANA can sort out allocation to RIRs as needed. >- the root contention with this policy still remains: what happens to >those organisations who decline to pay a registration payment and who >decline to sign any contract? This policy proposal fails to establish a >quid pro quo in this situation. The RIPE NCC does not operate on a zero >cost basis, and it is only fair that those who depend on its registration >services be required to pay for this. I can understand that many LRHs will >have an idealogical objection to this but as King Lear said, "nothing will >come of nothing". Lear misunderstood his daughter greatly when he said that, if I remember my Shakespeare correctly. IMO, quality-of-records overrides here and while a LRH might not care about their space being correctly registered (and hence refuse to pay for it), others in the community may have other ideas. >holders (after due diligence on identity performed), and that LRH resources >handled by sponsoring LIR be provided with the same services as PI address >space? With the NCC as ultimate mntner? Don't think so. Overall, the policy is still best summarised as: "It's a trap!" Well, as long as the LRHs enter said trap voluntarily, fine with me. So, I'd expect to see basic reg services to continue if a LRH does not engage, for whatever reason. I'm sure the community sees the quality of the db as the overriding goal too and I don't think absorbing this relatively small amount of extra effort will overtax the NCC. cheers, Sascha Luck From randy at psg.com Wed Feb 6 00:33:04 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 08:33:04 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <510EEB65.908@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> Message-ID: mornin' nick, btw, the approach of hiding behind an lir is somewhat interesting. for an r&e institution, such a janet or nordunet member, the reliability of the information about the end user may be strong enough to allow the ncc to be comfortable. in the non-r&e space, it would seem to be just creating more of the same problem we have with PI space. 'hiding' behind an lir would be too much hiding and not enough lir. as you can see, most of the authors of 2012-7 are r&e folk, and much of the legacy resources holdings in the region are r&e. randy From nick at netability.ie Wed Feb 6 01:00:18 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 00:00:18 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <20130205204213.GA72122@cilantro.c4inet.net> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> Message-ID: <51119D12.7040609@netability.ie> On 05/02/2013 20:42, Sascha Luck wrote: > On Sun, Feb 03, 2013 at 10:57:41PM +0000, Nick Hilliard wrote: >> - section 2.5: you can't be serious? "due to specific enduring or >> temporary circumstances"?? This is a carte-blanche for any LRH to ignore >> this policy until the heat death of the universe. > > Why wouldn't they? RIPE is not a government that can tax things that > used to be free or make policy and charge fees for resources they do not > own. IMO any LRH who wants to ignore this (and other) policies until > the death of the universe is entirely justified in doing so. If they want to ignore this policy, then they should go ahead and ignore it - until the heat death of the universe. I have no problem with that. The point is that running a registry costs money: > http://www.ripe.net/lir-services/ncc/gm/september-2012/documents/draft-ripe-ncc-activity-plan-and-budget-2013 The figures aren't particularly important in this context, but there are costs and they are not insubstantial. Given that there are tangible ongoing costs associated with running the registry, it's not unreasonable to expect that all resource registrants contribute to the running of this service through one mechanism or other. To be clear, I fully support sections 2.1 to 2.3 in the proposal and have no problem with e.g. LIRs which are legacy holders discharging any obligation of this form via their regular membership fees. My concerns relate to the relatively small number of organisations who feel that because they have not been asked to pay registry service fees since the resources were registered over 20 years ago, that the RIPE NCC is therefore obliged to provide ongoing registration services to them in perpetuity. I don't believe that this is a reasonable position to take because this position is all take and no give. >> - there is probably a requirement for the LRHs to provide some form of >> formal identification about who they are and why they have a claim on the >> resources they claim to hold. For sure, the RIPE NCC cannot certify >> resources without a reasonable level of due diligence. > > I should be very careful in proposing this in policy. Judging on past > record, this will be implemented as an onerous pile of bureaucratic > misery. Hardly likely to entice a LRH to engage with the NCC. If you have alternative proposals for resource certification which don't involve some form of due diligence, I'd be mightily interested to hear them :-) > Is that a requirement that the NCC *accepts* the transfer or a > requirement that the NCC has approval on thoise transfers? to be defined. I agree with someone else's comments (can't remember who - Wilfried maybe?) that this is probably best dealt with separately. Best get this proposal dealt with first and then deal with other issues scu > Overall, the policy is still best summarised as: "It's a trap!" Well, as No need to be scary-conspiratorial here. I'm not sure if you've noticed, but the holders of the address space are working towards a situation with the organisation which they own, which will benefit everyone in the long run. Oh wait, I left my tin hat off for a moment and the government mind control machine took over, zomg!! :-) Nick From randy at psg.com Wed Feb 6 01:17:27 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 09:17:27 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <51119D12.7040609@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> Message-ID: aha! i just re-read 2.4 and think i see your problem and agree with it. 2.4 Option to engage directly with the RIPE NCC A Legacy Internet Resource Holder whose circumstances match those described in section 2.3 above, but cannot find a Sponsoring LIR with which a mutually satisfactory contract of the kind mentioned in that section, may opt to enter a non-member service contract with the RIPE NCC for the purposes of registering the Legacy Resources involved, subject to the conditions defined in Section 3 below. i lost a small intra-author discussion in which i asked it to be explicit that small fee for ncc services would be paid (but not for rental of integers). would that make you happier with 2.4? randy From nick at netability.ie Wed Feb 6 01:44:09 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 00:44:09 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> Message-ID: <5111A759.6090707@netability.ie> On 06/02/2013 00:17, Randy Bush wrote: > i lost a small intra-author discussion in which i asked it to be > explicit that small fee for ncc services would be paid (but not for > rental of integers). would that make you happier with 2.4? sorta, but it's a little more subtle than that. The issue isn't payment but how the payment should be made. We're all agreed that any talk of renting integers is silly now that the standard charging mechanism put an end to that (which makes lots of things much simpler actually). A services fee is appropriate, imo, but I believe that this would be better handled via a sponsoring LIR for the same reasons that apply to 2007-01. When 2007-01 became policy, the RIPE NCC originally provided a mechanism for a direct relationship and I'll be brutally honest in saying that I was horrified when they jacked that price up to the same as the membership fee, while keeping the sponsored fee at ?50 - this wasn't what I intended at all when writing the policy; nor was it explicitly precluded by the policy. In retrospect it actually worked rather well. The RIPE NCC is a registry, not a registrar, and it would not benefit anyone for them to turn into a billing operation with a small registry arm on the side - or to compete with their members for registrar services. It also seems that there aren't big roadblocks to PI end users getting LIR sponsorship contracts in place - there are plenty of LIRs knocking around and they're all on the same footing. This allowed the RIPE NCC to dispense with the direct relationship arrangement for 2013 onwards (even though I note that they didn't ask or receive RIPE community support for a policy proposal to back this change), which has reduced the number of contract templates they need to deal with by one. This will reduce their paperwork, costs and overhead and there is inherent virtue in simplifying the bureaucracy involved. So from this context, I just don't see the need for 2.4. It's not that I have a major objection to it - it's simply that we have a precedent to show that it's not just unnecessary, but that it will increase the cost of implementation of this policy. We could go down this road again, but we've been there and done that and found it to be, well, slightly pointless. I'm happy that we don't need to go down the road again, but it's not a huge issue one way or another. Nick From nick at netability.ie Wed Feb 6 01:57:57 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 00:57:57 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> Message-ID: <5111AA95.2060806@netability.ie> On 05/02/2013 23:33, Randy Bush wrote: > mornin' nick, > > btw, the approach of hiding behind an lir is somewhat interesting. > > for an r&e institution, such a janet or nordunet member, the reliability > of the information about the end user may be strong enough to allow the > ncc to be comfortable. > > in the non-r&e space, it would seem to be just creating more of the same > problem we have with PI space. 'hiding' behind an lir would be too much > hiding and not enough lir. actually if there were some non-discriminatory way of doing this, I wouldn't be averse to the idea - this is a helpful side-effect of the new level-field charging mechanism. Problem is, however much the R&E organisations tend to be decent, honest and upstanding members of the Internet community, I don't see how it would be feasible to implement this without being unfair to the non R&E resource holders. Level playing fields are important as a policy goal. > as you can see, most of the authors of 2012-7 are r&e folk, and much of > the legacy resources holdings in the region are r&e. Most of the legacy resources still in use are R&E, but a substantial chunk of the squatted / abandoned space was never R&E to start with. The issues that I have with the current proposal relate to how it will handle these problem address blocks. Nick From randy at psg.com Wed Feb 6 02:00:03 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 10:00:03 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5111A759.6090707@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> Message-ID: > We're all agreed that any talk of renting integers is silly now that the > standard charging mechanism put an end to that (which makes lots of things > much simpler actually). A services fee is appropriate, imo, but I believe > that this would be better handled via a sponsoring LIR for the same reasons > that apply to 2007-01. see my other message on sponsoring lirs o not appropriate for a large number of non-r&r lrhs. tell it to the brit gov with their /8, or many industrials with /16s, etc o it just increases the same non-contact problem we have with PI > When 2007-01 became policy, the RIPE NCC originally provided a mechanism > for a direct relationship and I'll be brutally honest in saying that I was > horrified when they jacked that price up to the same as the membership > fee let's be sure not to let that one happen again > there aren't big roadblocks to PI end users getting LIR sponsorship > contracts in place but we do not know the real identity of those hiding behind lirs. would you want to certify them? randy From nick at netability.ie Wed Feb 6 02:14:02 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 01:14:02 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> Message-ID: <5111AE5A.4080906@netability.ie> On 06/02/2013 01:00, Randy Bush wrote: > but we do not know the real identity of those hiding behind lirs. would > you want to certify them? Where the identity of the holder is clear, and there are contractual links in place, yadda yadda due diligence, then yes. I think maybe it would be good to deal with the certification issue in a separate policy, because it's difficult. Nick From nick at netability.ie Wed Feb 6 02:31:28 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 01:31:28 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> Message-ID: <5111B270.7040605@netability.ie> On 05/02/2013 07:55, Randy Bush wrote: > if they are unresponsive or do not wishfees to engage, i am torn between the > need for the best whois and dns data we can publish and being pretty > cold. honestly, me too - despite all the noise I have made. There are options ranging from the fundamentally destructive (remove the registration data) to free services forever for everything that the RIPE NCC offers. > unfortunately, that is the status quo. and we kind of have a historical > obligation to allow them to ignore the ncc. but perhaps a carrot, as > opposed to a stick, can significantly improve this. Here are some ideas for what could happen if a LRH wasn't engaging (in no particular order): Removal of registration as a short term prospect: no-one is seriously in favour of this. It's unnecessarily destructive and will not entice anyone to engage with the RIPE NCC. Removal of some registration data as a short term prospect: e.g. drop DNS server entries. Again, I think this is unnecessarily aggressive. Time limited amnesty: free registration for X period of time if you engage within Y period. Or some other carrot. Free-for-all-time-for-everyone: as irresponsible as short-term deregistration. Inconvenience: locking of registration data for LRHs who decline to engage. I.e. the data still remains, but you cannot update the details, particularly the nameservers. This is a inconvenience whose severity depends on how necessary good quality IP address services are to the user. Locking could be hard-locking (i.e. autorefusal) or moderated (requests get forwarded to IPRAs). The latter is probably more sensible. Removal of registration as a long term prospect: this will be necessary. There is undoubtedly a pile of ERX address space which is either squatted or abandoned. As a long term objective, I think that there is some duty of stewardship that makes de-registration of data a requirement. Maybe we don't need to deal with it in 2012-07, but it is inevitable on a 20-50 year basis. Nick From randy at psg.com Wed Feb 6 02:33:04 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 10:33:04 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5111AE5A.4080906@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> <5111AE5A.4080906@netability.ie> Message-ID: > I think maybe it would be good to deal with the certification issue in > a separate policy, because it's difficult. definitely! we need more corner-case policies :) randy From randy at psg.com Wed Feb 6 02:43:55 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 10:43:55 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5111B270.7040605@netability.ie> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5111B270.7040605@netability.ie> Message-ID: > Here are some ideas for what could happen if a LRH wasn't engaging (in > no particular order): > > Removal of registration as a short term prospect: no-one is seriously > in favour of this. It's unnecessarily destructive and will not entice > anyone to engage with the RIPE NCC. and is antithetical to the principal reason for the ncc's existence > Removal of some registration data as a short term prospect: e.g. drop > DNS server entries. Again, I think this is unnecessarily aggressive. and harms the rest of us, not the unresponsive entity. > Time limited amnesty: free registration for X period of time if you > engage within Y period. Or some other carrot. > > Free-for-all-time-for-everyone: as irresponsible as short-term > deregistration. this is the status quo and kinda what we are socially and technically committed to. we don't like it. the previously listed sticks are not really what we should be doing. so the proposal seeks carrots. i am quite open to alternative suggestions of tasty parsnips or rutabagas. > Inconvenience: locking of registration data for LRHs who decline to > engage. I.e. the data still remains, but you cannot update the > details, particularly the nameservers. again, contrary to our primary mission, accurate data. > Removal of registration as a long term prospect: this will be > necessary. very hard procedurally and legally. > There is undoubtedly a pile of ERX address space which is either > squatted or abandoned. rigourously prove it such that it will stand up when we get our asses sued off. benefit::risk very very low. > As a long term objective, I think that there is some duty of > stewardship that makes de-registration of data a requirement. Maybe > we don't need to deal with it in 2012-07, but it is inevitable on a > 20-50 year basis. i think the costs of vigilatism are far more than the possible benefits. and 20-50 years from now, we will all be running in 10/8 anyway, or is it 100.64/10? randy From ms at uakom.sk Wed Feb 6 04:06:17 2013 From: ms at uakom.sk (Martin Stanislav) Date: Wed, 6 Feb 2013 04:06:17 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5111A759.6090707@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> Message-ID: <20130206030617.GA7206@moon.uakom.sk> On Wed, Feb 06, 2013 at 12:44:09AM +0000, Nick Hilliard wrote: > This allowed the RIPE NCC to dispense with the direct relationship > arrangement for 2013 onwards (even though I note that they didn't ask or > receive RIPE community support for a policy proposal to back this change), > which has reduced the number of contract templates they need to deal with > by one. Thanks for reminding. I've missed to recall this change in the direct relationship arrangement as well as the fact ripe-518 is updated by ripe-569 to reflect it. Mea culpa. The policy ripe-452 (final 2007-01 proposal) doesn't elaborate on the means of establishing a direct contractual link between the End User and the RIPE NCC. Thus no obligation for RIPE NCC to ask or receive RIPE community support for a change in the policy aspect implementation. My appologies to Nick and Daniel. Martin From hank at efes.iucc.ac.il Wed Feb 6 06:51:52 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 06 Feb 2013 07:51:52 +0200 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <51119D12.7040609@netability.ie> References: <20130205204213.GA72122@cilantro.c4inet.net> <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> Message-ID: <5.1.1.6.2.20130206074328.05292118@efes.iucc.ac.il> At 00:00 06/02/2013 +0000, Nick Hilliard wrote: >My concerns relate to the relatively small number of organisations who feel >that because they have not been asked to pay registry service fees since >the resources were registered over 20 years ago, that the RIPE NCC is >therefore obliged to provide ongoing registration services to them in >perpetuity. I don't believe that this is a reasonable position to take >because this position is all take and no give. So we agree we are talking about corner cases. Can you specify what you mean by "registry services"? Here is how I see it. Suppose we have 100 corner cases and they each own a /19. They have an auto-num, route and inetnum objects which is controlled by a mntner object. They send in an email to auto-dbm at ripe.net to update some phone number or email in order to keep the whois data uptodate. In my opinion, this is the only registry service they need and these 100 corner cases should be allowed to continue to do so. If they need something that requires human intervention - "anything", which can include a lost MD5 password for their mntner, then, at that point the RIPE NCC can state "pay membership dues in order for us to continue". -Hank From hank at efes.iucc.ac.il Wed Feb 6 06:55:13 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 06 Feb 2013 07:55:13 +0200 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5111B270.7040605@netability.ie> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> Message-ID: <5.1.1.6.2.20130206075156.0074f090@efes.iucc.ac.il> At 01:31 06/02/2013 +0000, Nick Hilliard wrote: >Removal of registration as a long term prospect: this will be necessary. >There is undoubtedly a pile of ERX address space which is either squatted >or abandoned. As a long term objective, I think that there is some duty of >stewardship that makes de-registration of data a requirement. Maybe we >don't need to deal with it in 2012-07, but it is inevitable on a 20-50 year >basis. I agree. If the inetnum or autnum is unused and not routed for the past 5 years, and all attempts at contact via email to the data listed in whois, then by all means, initiate some sort of squatting/abandoned project. But this has nothing to do with LRH, but should be a RIR policy. -Hank From randy at psg.com Wed Feb 6 07:34:09 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 15:34:09 +0900 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5.1.1.6.2.20130206074328.05292118@efes.iucc.ac.il> References: <20130205204213.GA72122@cilantro.c4inet.net> <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <51119D12.7040609@netability.ie> <5.1.1.6.2.20130206074328.05292118@efes.iucc.ac.il> Message-ID: > Suppose we have 100 corner cases and they each own a /19. They have an > auto-num, route and inetnum objects which is controlled by a mntner > object. They send in an email to auto-dbm at ripe.net to update some phone > number or email in order to keep the whois data uptodate. In my opinion, > this is the only registry service they need and these 100 corner cases > should be allowed to continue to do so. If they need something that > requires human intervention - "anything", which can include a lost MD5 > password for their mntner, then, at that point the RIPE NCC can state "pay > membership dues in order for us to continue". s/memebrship dues/fees for the services/ randy From hank at efes.iucc.ac.il Wed Feb 6 07:51:58 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 06 Feb 2013 08:51:58 +0200 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5.1.1.6.2.20130206074328.05292118@efes.iucc.ac.il> <20130205204213.GA72122@cilantro.c4inet.net> <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <51119D12.7040609@netability.ie> <5.1.1.6.2.20130206074328.05292118@efes.iucc.ac.il> Message-ID: <5.1.1.6.2.20130206085150.0074aed8@efes.iucc.ac.il> At 15:34 06/02/2013 +0900, Randy Bush wrote: > > Suppose we have 100 corner cases and they each own a /19. They have an > > auto-num, route and inetnum objects which is controlled by a mntner > > object. They send in an email to auto-dbm at ripe.net to update some phone > > number or email in order to keep the whois data uptodate. In my opinion, > > this is the only registry service they need and these 100 corner cases > > should be allowed to continue to do so. If they need something that > > requires human intervention - "anything", which can include a lost MD5 > > password for their mntner, then, at that point the RIPE NCC can state "pay > > membership dues in order for us to continue". > >s/memebrship dues/fees for the services/ Fine. -Hank >randy From mir at ripe.net Wed Feb 6 12:08:32 2013 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 06 Feb 2013 12:08:32 +0100 Subject: [ncc-services-wg] New on RIPE Labs: Country Specific Graphs in RIPEstat Message-ID: <511239B0.6010505@ripe.net> [apologies for duplicates] Dear colleagues, We developed additional functionality in RIPEstat that shows various datasets by country. A new widget called Country Routing Statistics is now available, along with the ability to compare the situation in different countries side by side. Please find more details on RIPE Labs: https://labs.ripe.net/Members/cteusche/country-specific-graphs-in-ripestat Kind regards, Mirjam Kuehne RIPE NCC From lists-ripe at c4inet.net Wed Feb 6 12:15:45 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 6 Feb 2013 11:15:45 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <51119D12.7040609@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> Message-ID: <20130206111545.GA74731@cilantro.c4inet.net> On Wed, Feb 06, 2013 at 12:00:18AM +0000, Nick Hilliard wrote: >If they want to ignore this policy, then they should go ahead and ignore it >- until the heat death of the universe. I have no problem with that. > >The point is that running a registry costs money: >The figures aren't particularly important in this context, but there are >costs and they are not insubstantial. I don't think that the cost of providing basic, mostly automated, services is in any way high enough to make compromising the registry data an option. IMO, after we've seen where it leads to, the mindset of "nothing must ever be free and everything must be bought and paid for" has proven to be disingenous. Let those few LRHs that DNW to engage with RIRs have those services pro bono the database. >If you have alternative proposals for resource certification which don't >involve some form of due diligence, I'd be mightily interested to hear them :-) Bin it with extreme prejudice (at least in the form where the RIRs control the certificates). >No need to be scary-conspiratorial here. I'm not sure if you've noticed, >but the holders of the address space are working towards a situation with >the organisation which they own, which will benefit everyone in the long >run. Oh wait, I left my tin hat off for a moment and the government mind >control machine took over, zomg!! :-) I'm happy with almost anything that does not involve a LRH being forced to give up any rights to their resources hitherto enjoyed. (I don't hold any LR, nor am I likely to ever do; this is a matter of principle to me) cheers, Sascha From gert at space.net Wed Feb 6 13:58:29 2013 From: gert at space.net (Gert Doering) Date: Wed, 6 Feb 2013 13:58:29 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5.1.1.6.2.20130206074328.05292118@efes.iucc.ac.il> References: <20130205204213.GA72122@cilantro.c4inet.net> <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <5.1.1.6.2.20130206074328.05292118@efes.iucc.ac.il> Message-ID: <20130206125829.GU51699@Space.Net> Hi, On Wed, Feb 06, 2013 at 07:51:52AM +0200, Hank Nussbacher wrote: > Suppose we have 100 corner cases and they each own a /19. They have an > auto-num, route and inetnum objects which is controlled by a mntner > object. They send in an email to auto-dbm at ripe.net to update some phone > number or email in order to keep the whois data uptodate. In my opinion, > this is the only registry service they need and these 100 corner cases > should be allowed to continue to do so. If they need something that > requires human intervention - "anything", which can include a lost MD5 > password for their mntner, then, at that point the RIPE NCC can state "pay > membership dues in order for us to continue". Works for me. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From nick at netability.ie Wed Feb 6 15:11:40 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 14:11:40 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> <5111AE5A.4080906@netability.ie> Message-ID: <5112649C.6050105@netability.ie> On 06/02/2013 01:33, Randy Bush wrote: >> I think maybe it would be good to deal with the certification issue in >> a separate policy, because it's difficult. > > definitely! we need more corner-case policies :) If there isn't a policy to deal with this, de-facto due diligence policies will need be created by the registration services department to handle certification requirements for ERX users. So which do you want: - the community (including ERX users) to work out a set of guidelines for how to handle certification when the original documents are lost, or - the RIPE NCC RS department to invent something which works for them after being told, "uuh, you guys just go off and handle that and don't bother us too much with the details" - followed by some handwaving? KISS means keeping it as simple as possible, but no simpler. Nick From nick at netability.ie Wed Feb 6 15:30:38 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 14:30:38 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <20130204221212.GB21183@besserwisser.org> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> Message-ID: <5112690E.6000701@netability.ie> On 04/02/2013 22:12, M?ns Nilsson wrote: > The "completely estranged LRH holder organisation" is not that common, I > believe. Wasting electrons on this corner case is not fruitful. Problem is, I'm not sure it's a corner case; nor am I sure that the squatters are corner cases, nor the abandoned address blocks. Has the RIPE NCC done any preliminary analysis of the ERX space in terms of: - rough consistency of link between inetnum: owner and mntner - when was the last time the resources were updated - potential LIR association - whether prefix is visible in dfz I realise that this is very ill-specified. This might be useful in quantifying how much effort it would be worth expending in what you and Hank refer to as "corner cases", but which I would feel were more common. Nick From mbox.dns-dhcp at daimler.com Wed Feb 6 14:30:37 2013 From: mbox.dns-dhcp at daimler.com (mbox.dns-dhcp at daimler.com) Date: Wed, 06 Feb 2013 13:30:37 +0000 Subject: [ncc-services-wg] Support for policy 2012-07 Message-ID: Hi! We support https://www.ripe.net/ripe/policies/proposals/2012-07 as we have two legacy networks which should be handled via this policy. Mit freundlichen Gr??en / Kind regards Bernd Casimir (RegID de.daimler) ITI/GN CoC DNS/DHCP HPC 096/M406 e-Mail: mailto:MBOX.DNS-DHCP at Daimler.com Fax: +49 (0) 711/17-790-65858 Daimler AG Sitz und Registergericht/Domicile and Court of Registry: Stuttgart HRB-Nr./Commercial Register No. 19360 Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Manfred Bischoff Vorstand/Board of Management: Dieter Zetsche (Vorsitzender/Chairman), Wolfgang Bernhard, Christine Hohmann-Dennhardt, Wilfried Porth, Andreas Renschler, Hubertus Troska, Bodo Uebber, Thomas Weber If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Wed Feb 6 17:21:24 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 06 Feb 2013 17:21:24 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5.1.1.6.2.20130206075156.0074f090@efes.iucc.ac.il> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5.1.1.6.2.20130206075156.0074f090@efes.iucc.ac.il> Message-ID: <51128304.1070804@CC.UniVie.ac.at> Hank Nussbacher wrote: > At 01:31 06/02/2013 +0000, Nick Hilliard wrote: > >> Removal of registration as a long term prospect: this will be necessary. >> There is undoubtedly a pile of ERX address space which is either squatted >> or abandoned. As a long term objective, I think that there is some >> duty of >> stewardship that makes de-registration of data a requirement. Maybe we >> don't need to deal with it in 2012-07, but it is inevitable on a 20-50 >> year >> basis. > > > I agree. If the inetnum or autnum is unused In principle I agree, but I fail to see why this is a special case for LRHs? IMO this is outside the discussion of a policy for offering and administering registration *services* provided by the RIPE NCC. > and not routed How would you, the NCC or actually anyone, "prove", that an address block is "not routed" (or in use)? We had that a couple of times already, it is a non-starter to begin with. > for the past > 5 years, and all attempts at contact via email There has been a good reason, why the email attribute has been optional :-) IMHO, nowhere in Internet-Policy and -Operations Land a requiement does exist or has ever existed to operate globally accessible port 25 services (or more modern versions thereof) in order to obtain address blocks or AS numbers for use in an IP-based (inter)network . OT - but maybe worth noting: the same expectation that such an obligation exists seems to be held by some parties in the abuse-management discussions... > to the data listed in > whois, then by all means, initiate some sort of squatting/abandoned > project. As a (future) project, yes, with proper authorisation from the membership which has to foot the bill, and after reasonable assessment of cost vs. merits ;-) > But this has nothing to do with LRH, but should be a RIR policy. Yes to part 1 and maybe to part 2. > -Hank Wilfried From Woeber at CC.UniVie.ac.at Wed Feb 6 17:36:08 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 06 Feb 2013 17:36:08 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5111B270.7040605@netability.ie> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5111B270.7040605@netability.ie> Message-ID: <51128678.8020903@CC.UniVie.ac.at> Nick Hilliard wrote: > On 05/02/2013 07:55, Randy Bush wrote: [...] > Removal of some registration data as a short term prospect: e.g. drop DNS > server entries. Again, I think this is unnecessarily aggressive. Not only "unnecessarily aggressive" but potentially destructive to the RIR system. There's an organisation out there, which tried to go down that road, a while ago, with ccTLDs as targeted victims. It became pretty noisy, pretty quickly, and would have had a major impact on the administration of the root zone... I definitely know, that there are parties out there, which would be more than happy to get their feet into the pool and to offer such services to LRHs for free, at least for a loooong time. I fear that such a move would break quite some stuff that we got to enjoy and would like to perserve for the future of the numbers registries. > Time limited amnesty: free registration for X period of time if you engage > within Y period. Or some other carrot. > > Free-for-all-time-for-everyone: as irresponsible as short-term deregistration. I am not sure that this statement would hold. You semm to be ignoring that many of those LRHs (early adopters and developers) were spending quite a big amount of money to start and to develop the IPv4-based Internet. The same one that quite a few of us take for granted these days and making money with ;-) Thus I do not consider continuation of providing a (proportionally really cheep) service for them as "irresponsible". Actually this same service has been offered for more than 20 years and the community didn't scream :-) Wilfried From nick at netability.ie Wed Feb 6 18:51:38 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 17:51:38 +0000 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <51128678.8020903@CC.UniVie.ac.at> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5111B270.7040605@netability.ie> <51128678.8020903@CC.UniVie.ac.at> Message-ID: <5112982A.8090406@netability.ie> On 06/02/2013 16:36, Wilfried Woeber wrote: > Nick Hilliard wrote: >> Removal of some registration data as a short term prospect: e.g. drop DNS >> server entries. Again, I think this is unnecessarily aggressive. > > Not only "unnecessarily aggressive" but potentially destructive to the RIR > system. Then we agree that this shouldn't be done. Good! Nick From pk at DENIC.DE Wed Feb 6 19:48:19 2013 From: pk at DENIC.DE (Peter Koch) Date: Wed, 6 Feb 2013 19:48:19 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <51128678.8020903@CC.UniVie.ac.at> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5111B270.7040605@netability.ie> <51128678.8020903@CC.UniVie.ac.at> Message-ID: <20130206184819.GI1320@x28.adm.denic.de> On Wed, Feb 06, 2013 at 05:36:08PM +0100, Wilfried Woeber wrote: > Thus I do not consider continuation of providing a (proportionally really > cheep) service for them as "irresponsible". Actually this same service has > been offered for more than 20 years and the community didn't scream :-) +1 While I would support the spirit that any resource holder is encouraged to contribute, I do not see this policy making body in a position to retroactively force an "LRH" under any (new) policy. The NCC, when founded, was well aware of "LRHs" when it accepted its mission, thus inheriting the duties of contractual (express or implied) delivery towards those "LRHs". -Peter (not really an LRH) From mansaxel at besserwisser.org Wed Feb 6 21:33:26 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Wed, 6 Feb 2013 21:33:26 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <5112690E.6000701@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> Message-ID: <20130206203326.GB21612@besserwisser.org> Subject: Re: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 Date: Wed, Feb 06, 2013 at 02:30:38PM +0000 Quoting Nick Hilliard (nick at netability.ie): > On 04/02/2013 22:12, M?ns Nilsson wrote: > > The "completely estranged LRH holder organisation" is not that common, I > > believe. Wasting electrons on this corner case is not fruitful. > > Problem is, I'm not sure it's a corner case; nor am I sure that the > squatters are corner cases, nor the abandoned address blocks. > > Has the RIPE NCC done any preliminary analysis of the ERX space in terms of: > > - rough consistency of link between inetnum: owner and mntner > - when was the last time the resources were updated > - potential LIR association > - whether prefix is visible in dfz > > I realise that this is very ill-specified. > > This might be useful in quantifying how much effort it would be worth > expending in what you and Hank refer to as "corner cases", but which I > would feel were more common. It's been mentioned (and with good backing I believe, I've seen it from the inside) that a lot of old assignments are to RE networks. Most of these are reasonably well maintained. My own limited knowledge of commercial entities having assignments points to similar data. Mostly. (both I and my wife work at corporations with ERX blocks -- my block has a current maintainer and a route object, her block has ERX info which still is correct, at least points to the right company) My belief thus is, that most of these entries are good enough that they serve a purpose. Some of them are excellent. A better picture can probably be had by some more dedicated data-mining. I am quite upset with a heavy-handed policy being crafted to force every possible net into a rigid form. Yes, I've argued that the RIR database needs to be complete. And it is in fact so important that estranging (which heavy policies will lead to, I'm afraid) is detrimental. This has excellent prior art, btw: All participants agree that there should be some sort of registration of the networks taking part in the European IP net. This way any problems that may occur can be signaled to the responsible person. It was stressed that this registration activity is just a matter of keeping the registry up to date: in no way it should constitute some sort of authority. A 'whois' style of information service was suggested as a useful tool to access registry information. (Action: Anders Hillbo) (from the minutes of RIPE meeting #1, as read from: http://www.ripe.net/ripe/meetings/ripe-meetings/ripe-1) Ultimately, the NCC and the other RIRen have no actual power over early registrations/allocations. They can at most humbly request that holders register their allocations in the most suitable RIR. And a RIR should encourage and welcome this. If the holder, and the holder only, feels that a closer relation to a given RIR would be proper (and I can think of a lot of good, valid reasons for this) then there might surface a need for a more formal relationship. (with the RIR or one of the LIRen) With this in place, there might be good reason for associating costs or contractual obligations with this value-add service. But the initial allocation is IMNSHO untouchable and is not to form the base for such a scheme. I support the policy proposal as it stands. Having said that, minor changes as discussed here on the list are probably useful. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Thank god!! ... It's HENNY YOUNGMAN!! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From nick at netability.ie Thu Feb 7 00:39:55 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 06 Feb 2013 23:39:55 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <20130206203326.GB21612@besserwisser.org> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <20130206203326.GB21612@besserwisser.org> Message-ID: <5112E9CB.9090102@netability.ie> On 06/02/2013 20:33, M?ns Nilsson wrote: > It's been mentioned (and with good backing I believe, I've > seen it from the inside) that a lot of old assignments are to RE > networks. Most of these are reasonably well maintained. My own limited > knowledge of commercial entities having assignments points to similar > data. Mostly. (both I and my wife work at corporations with ERX blocks > -- my block has a current maintainer and a route object, her block has > ERX info which still is correct, at least points to the right company) I'm sure the early academic community assignments are generally accurate and well maintained, which is unsurprising given the stability of the institutions which hold them. And I don't doubt their good faith for a moment. Having said that, I also know that some blocks which I registered for my (commercial) employer at the time via InterNIC have somehow ended up in the possession of one of the local LIRs in IE. Other address blocks that I've browsed through look defunct; others look decidedly squatted. There seems to be quite a mixed bag. > My belief thus is, that most of these entries are good enough that they serve > a purpose. Some of them are excellent. A better picture can probably be > had by some more dedicated data-mining. Some visibility into the data quality would be very useful at this stage, because from a policy point of view, it would helpful to know whether we are tilting at windmills or trying to fix a problem which is worth fixing. My suspicion veers towards the latter; the opinion of many other people appears to be the former. > I am quite upset with a heavy-handed policy being crafted to force every > possible net into a rigid form. Yes, I've argued that the RIR database > needs to be complete. And it is in fact so important that estranging > (which heavy policies will lead to, I'm afraid) is detrimental. I can understand why. As I said, I don't doubt your good faith - or the good faith of anyone else who's contributed to this discussion. But there is a real mess there and undoubtedly there will be people and organisations less well intentioned than you who will attempt to abuse the situation to benefit themselves at the cost of everyone else. What I'm trying to do here is tease out whether it's possible get a balance between the two. > Ultimately, the NCC and the other RIRen have no actual power over > early registrations/allocations. Nobody disputes this, but the RIPE NCC as de-facto registrar has a duty of good stewardship to these addresses, just as ERX holders have an expectation of good service. Coming to an agreement on where each side stands is something that will benefit everyone. Nick From randy at psg.com Thu Feb 7 03:01:25 2013 From: randy at psg.com (Randy Bush) Date: Wed, 06 Feb 2013 18:01:25 -0800 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <20130206184819.GI1320@x28.adm.denic.de> References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5111B270.7040605@netability.ie> <51128678.8020903@CC.UniVie.ac.at> <20130206184819.GI1320@x28.adm.denic.de> Message-ID: let's take the upside. i would suggest that there is a non-trivial number of lrhs who would be happy to form a more formal bond with the ncc to ensure their data are correct, and quite willing to pay a modest fee for the services currently provided for free. they just don't want to come under address policies and rights reduction of ncc membership. hence section 2.4. i would further suggest that 2.4 is a way to do reasonable certification of PI holders. randy From andrea at ripe.net Thu Feb 7 10:49:01 2013 From: andrea at ripe.net (Andrea Cima) Date: Thu, 07 Feb 2013 10:49:01 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <20130204143614.GA8673@moon.uakom.sk> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130204143614.GA8673@moon.uakom.sk> Message-ID: <5113788D.7090507@ripe.net> Dear Martin, On 2/4/13 3:36 PM, Martin Stanislav wrote: > Just thinking out loudly. Perhaps, a disputed resource holder > identification or existence? That's a case when a second paragraph in > the section 2.5 is to become applicable. >>> - there is probably a requirement for the LRHs to provide some form of >>> formal identification about who they are and why they have a claim on the >>> resources they claim to hold. For sure, the RIPE NCC cannot certify >>> resources without a reasonable level of due diligence. >> This is usually the biggest obstacle in my experience. We regularly help >> LRH:s with these matters and I think there should be clearer definitions >> of the paper work needed for identification. We are often talking about >> events 15-20 years back and since many LRH:s are large corporate groups >> they have often changed names and structure a few times since and now they >> have no idea what documentation to provide to prove they are acually the >> same entity. > Maybe RIPE NCC can help here, since mergers, takeovers and cease to exist > situations do happen with LIRs or PI holders as well. And RIPE NCC is likely > to have some experience in this area. Though, there are differences > complicating the matter a bit. No initial relationship between the RIPE NCC > and a LRH and a rather long time span. Have some of the related issues > been sorted out during the ERX project? Proof of holdership was not part of the ERX project in the RIPE NCC service region. The main focus has been the RIR database records transfer. For more information, please see the outcome of the ERX Task Force effort: http://www.ripe.net/ripe/mail/archives/db-wg/2002-October/002026.html http://www.ripe.net/ripe/mail/archives/erx-tf/2002/ In other RIR regions, evaluating proof of holdership and formalising the relationship between the address space holder and the RIR has been a follow-up of the ERX project: http://www.apnic.net/policy/historical-resource-policies https://www.arin.net/resources/legacy/index.html We have however built some experience reviewing proof of holdership of legacy resources over time. 84 organisations have asked the RIPE NCC to add their legacy resources to an LIR. As mentioned in this email thread, some cases have been straightforward while other cases have required in-depth research and review of documentation. Best regards, Andrea Cima RIPE NCC > I support the proposed policy 2012-07 as it is. Sure, the text can > be improved and I'm likely to restate the support in such case. > > Martin > > > From philipp.kern at kit.edu Thu Feb 7 10:45:40 2013 From: philipp.kern at kit.edu (Philipp Kern) Date: Thu, 7 Feb 2013 10:45:40 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <5.1.1.6.2.20130204105756.02004280@efes.iucc.ac.il> <510F92AD.6070003@netability.ie> <5111B270.7040605@netability.ie> <51128678.8020903@CC.UniVie.ac.at> <20130206184819.GI1320@x28.adm.denic.de> Message-ID: <20130207094540.GB8339@spike.0x539.de> Randy, am Wed, Feb 06, 2013 at 06:01:25PM -0800 hast du folgendes geschrieben: > i would suggest that there is a non-trivial number of lrhs who would be > happy to form a more formal bond with the ncc to ensure their data are > correct, and quite willing to pay a modest fee for the services > currently provided for free. they just don't want to come under address > policies and rights reduction of ncc membership. I think the biggest fear that we have when registering our legacy resources with RIPE is, that the billing scheme might change considerably, counting our legacy assignments in full. We're a LIR already, too. But that's what Sascha called the "trap", I guess. On the other hand I think many people agree that address policies do not apply to legacy resources. Putting this into a policy makes sense to me, even though I'm aware that future generations of policy makers might change it again. ;-) Kind regards Philipp Kern From randy at psg.com Thu Feb 7 12:27:14 2013 From: randy at psg.com (Randy Bush) Date: Thu, 07 Feb 2013 03:27:14 -0800 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5112649C.6050105@netability.ie> References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> <5111AE5A.4080906@netability.ie> <5112649C.6050105@netability.ie> Message-ID: >>> I think maybe it would be good to deal with the certification issue >>> in a separate policy, because it's difficult. >> definitely! we need more corner-case policies :) > If there isn't a policy to deal with this, de-facto due diligence > policies will need be created by the registration services department > to handle certification requirements for ERX users. well, to me, it's not a policy per se, but a requirement and a process. and it applies both to bringing legacy and pi in from the cold. i am more concerned with the requirements, what makes us comfortable in establishing that a claimant indeed is the legitimate holder of some resource(s). you seem to be more focused on making sure the process of meeting those requirements is not onerous. i think both are quite legitimate concerns. Andrea's statement on this is interesting: We have however built some experience reviewing proof of holdership of legacy resources over time. 84 organisations have asked the RIPE NCC to add their legacy resources to an LIR. As mentioned in this email thread, some cases have been straightforward while other cases have required in-depth research and review of documentation. one has to wonder what criteria and methods the ncc uses. randy From mansaxel at besserwisser.org Fri Feb 8 10:58:08 2013 From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson) Date: Fri, 8 Feb 2013 10:58:08 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> <5111AE5A.4080906@netability.ie> <5112649C.6050105@netability.ie> Message-ID: <20130208095808.GE21612@besserwisser.org> Subject: Re: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) Date: Thu, Feb 07, 2013 at 03:27:14AM -0800 Quoting Randy Bush (randy at psg.com): > one has to wonder what criteria and methods the ncc uses. A common example is "If you can produce an electricity invoice addressed to the company, it is a piece in the puzzle. But the street address must match." That last requirement is interesting when the organisation, as has been the case with my last two employers, /does not have a street address/, but instead has a postcode uniquely allocated to it: Royal Institute of Technology 100 44 Stockholm Sweden ..and Sveriges Radio 105 10 Stockholm Sweden Yes, mail is delivered perfectly fine to those addresses. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... or were you driving the PONTIAC that HONKED at me in MIAMI last Tuesday? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From tore at fud.no Fri Feb 8 11:19:42 2013 From: tore at fud.no (Tore Anderson) Date: Fri, 08 Feb 2013 11:19:42 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <5101381D.90600@ripe.net> References: <5101381D.90600@ripe.net> Message-ID: <5114D13E.6010707@fud.no> * Emilio Madaio > https://www.ripe.net/ripe/policies/proposals/2012-07 > > > We encourage you to review this policy proposal and send your comments > to . I support this policy proposal. I can, in principle, understand the objection that this proposal will permit LRHs to ?ride for free?, but in practise, I do not consider this a problem. I'm of the opinion that the marginal cost of continuing to provide gratis registry services to some LRHs is likely insignificant, and does not really cause any significant difference to the membership fee. I'm sure that the Impact Analysis will correct me if I'm wrong. Best regards, -- Tore Anderson RIPE NCC member. Not a LRH. From shane at time-travellers.org Fri Feb 8 12:53:45 2013 From: shane at time-travellers.org (Shane Kerr) Date: Fri, 8 Feb 2013 12:53:45 +0100 Subject: [ncc-services-wg] Something for the RIPE NCC to consider? Message-ID: <20130208125345.54f94e5f@shane-desktop> All, I've mentioned something like a "RIPE NCC transparency report" a few times: https://www.eff.org/deeplinks/2013/01/its-time-transparency-reports-become-new-normal Cheers, -- Shane From philipp.kern at kit.edu Sat Feb 9 13:47:26 2013 From: philipp.kern at kit.edu (Philipp Kern) Date: Sat, 9 Feb 2013 13:47:26 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: <20130208095808.GE21612@besserwisser.org> References: <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> <5111AE5A.4080906@netability.ie> <5112649C.6050105@netability.ie> <20130208095808.GE21612@besserwisser.org> Message-ID: <20130209124726.GA11683@spike.0x539.de> M?ns, am Fri, Feb 08, 2013 at 10:58:08AM +0100 hast du folgendes geschrieben: > > one has to wonder what criteria and methods the ncc uses. > A common example is "If you can produce an electricity invoice addressed > to the company, it is a piece in the puzzle. But the street address must > match." > > That last requirement is interesting when the organisation, as has been > the case with my last two employers, /does not have a street address/, > but instead has a postcode uniquely allocated to it: same here. But I'd still assume that such an invoice has a point of delivery mentioned that includes the street address. Kind regards Philipp Kern -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From jaska at kivela.net Fri Feb 8 21:46:06 2013 From: jaska at kivela.net (=?ISO-8859-15?Q?Jaska_Kivel=E4?=) Date: Fri, 08 Feb 2013 22:46:06 +0200 Subject: [ncc-services-wg] Proposal 2012-07 Message-ID: <5115640E.8050502@kivela.net> As the holder of inetnum: 192.26.111.0 - 192.26.111.255 netname: TTEK-NET we state our support for https://www.ripe.net/ripe/policies/proposals/2012-07 Thank you. -jk -- Jaska Kivel? jaska at kivela.net Katistentie 61 +358-40-5762988 FIN-13250 H?MEENLINNA http://www.kivela.net/jaska/ Finland From Woeber at CC.UniVie.ac.at Mon Feb 11 10:46:33 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 11 Feb 2013 10:46:33 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <5112690E.6000701@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> Message-ID: <5118BDF9.1050709@CC.UniVie.ac.at> Nick Hilliard wrote: [...] > Has the RIPE NCC done any preliminary analysis of the ERX space in terms of: > > - rough consistency of link between inetnum: owner and mntner > - when was the last time the resources were updated > - potential LIR association > - whether prefix is visible in dfz > > I realise that this is very ill-specified. just as an aside - and not symmetric in giving us reliable data: like *not* seeing it somewhere in a/the DFZ is *not* a firm indication that a block is not used, the frequency of updates to the objects in the DB is not necessarily conclusive either. Like for the university, which our NREN team left to move to a different one, some 15 years ago, the addresses are still the same, the people in this shop's NOC are still the same (for just a few years :-) ). > This might be useful in quantifying how much effort it would be worth > expending in what you and Hank refer to as "corner cases", but which I > would feel were more common. Yes, if and when the NCC happens to have that information "almost for free", just to round out the picture. > Nick Wilfried From andrea at ripe.net Mon Feb 11 14:42:26 2013 From: andrea at ripe.net (Andrea Cima) Date: Mon, 11 Feb 2013 14:42:26 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) In-Reply-To: References: <5101381D.90600@ripe.net> <510EEB65.908@netability.ie> <20130205204213.GA72122@cilantro.c4inet.net> <51119D12.7040609@netability.ie> <5111A759.6090707@netability.ie> <5111AE5A.4080906@netability.ie> <5112649C.6050105@netability.ie> Message-ID: <5118F542.9040302@ripe.net> Dear Randy, On 2/7/13 12:27 PM, Randy Bush wrote: >>>> I think maybe it would be good to deal with the certification issue >>>> in a separate policy, because it's difficult. >>> definitely! we need more corner-case policies :) >> If there isn't a policy to deal with this, de-facto due diligence >> policies will need be created by the registration services department >> to handle certification requirements for ERX users. > well, to me, it's not a policy per se, but a requirement and a process. > and it applies both to bringing legacy and pi in from the cold. i am > more concerned with the requirements, what makes us comfortable in > establishing that a claimant indeed is the legitimate holder of some > resource(s). you seem to be more focused on making sure the process of > meeting those requirements is not onerous. i think both are quite > legitimate concerns. > > Andrea's statement on this is interesting: > > We have however built some experience reviewing proof of holdership > of legacy resources over time. 84 organisations have asked the RIPE > NCC to add their legacy resources to an LIR. As mentioned in this > email thread, some cases have been straightforward while other cases > have required in-depth research and review of documentation. > > one has to wonder what criteria and methods the ncc uses. Our experience has shown us that each case is unique and can require very different approaches to establish beyond doubt who is the legitimate holder of the resources. We start by checking to see if we have relevant information internally. This can take the form of internal database information, InterNIC documentation or communication from that period (faxes, letters, etc.). We then look at the corporate paper trail. This involves tracking companies that in many cases have changed name, merged with other companies, been acquired or simply closed down. In some cases there is quite a lot of information available and in others very little. In many cases, the available information turns out to be disputed or incorrect. All of this means that this is usually a time-consuming and resource-intensive process. Best regards, Andrea Cima RIPE NCC > randy > > From ripencc-management at ripe.net Mon Feb 11 14:59:09 2013 From: ripencc-management at ripe.net (Axel Pawlik) Date: Mon, 11 Feb 2013 14:59:09 +0100 Subject: [ncc-services-wg] [news] RPKI and PI End Users Proposal - Feedback Requested References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> Message-ID: <50B634E7-1E14-4F45-A7FF-F3952B3ABE93@ripe.net> [Apologies for duplicate emails] Dear colleagues, Since the launch of the RIPE NCC resource certification (RPKI) system on 1 January 2011, more than 1,300 RIPE NCC members have requested a resource certificate. Together, they have created statements about BGP routing for over 3,000 prefixes, covering more than five /8 blocks. Currently, this system is only applicable to Provider Aggregatable (PA) address space held by RIPE NCC members. The functionality that we most commonly receive requests for is to make address space held by Provider Independent (PI) End Users eligible for certification. During the RIPE 65 Meeting in Amsterdam, there were discussions on this and the RIPE NCC Executive Board extensively deliberated the issue. Based on these discussions, the Executive Board now submits this proposal for consideration and discussion to you, the RIPE NCC membership and the RIPE community. One of the most important considerations when issuing a resource certificate is that it be given to the legitimate holder of the address space. This is fundamental to the reliability and trustworthiness of the system and to the goal of making our registry as robust as possible. To ensure that the resource certificate retains its authoritative value over time, it is important that the RIPE NCC periodically verifies the association between the resource and its holder. With our members, this is a straightforward process because we have direct contact with them at least once a year. Under current RIPE Policy, PI End Users who are not RIPE NCC members must have a contractual agreement with a sponsoring LIR (as detailed in ripe-452). Periodic verification of the resource holder could be handled by the sponsoring LIR. Also note that the RIPE NCC cannot enter into any contractual agreement with PI End Users, other than the "RIPE NCC Standard Service Agreement" (ripe-435). Therefore, the Executive Board proposes that PI End Users in the RIPE NCC service region who want to certify their resources be given both of the following two options: 1. Sign an agreement with their sponsoring LIR (a RIPE NCC member) to have the resources certified by the RIPE NCC via the sponsoring LIR. In this case, the sponsoring LIR would be responsible for periodically verifying that the PI End User is the legitimate holder of the resources. However, the RIPE NCC will in all cases be responsible for issuing the resource certificate and providing access to the RPKI management interface. Therefore, PI End Users should, at all times, be able to change from one sponsoring LIR to another while still retaining the same certificate for the resources that they hold. The cost associated with this option lies in building a framework in the LIR Portal to facilitate the process, some administrative overhead, and the additional burden on the RPKI infrastructure, that would not be funded by the direct beneficiary of the resource certification service. These costs would come out of the general RIPE NCC budget and would therefore be funded by all RIPE NCC members, however it is unlikely that this would have any direct impact on future membership fees. Alternatively a PI End User may choose to: 2. Become a RIPE NCC member, pay the full annual membership fee and receive a certificate directly through the RIPE NCC. The Executive Board feels that offering both of these options will result in relatively little impact on membership fees while offering all PI End Users the opportunity to certify their Internet number resources without being forced to become a member of the RIPE NCC. For the sake of completeness, we also present a third scenario discussed by the Executive Board that would involve giving PI End Users that have received resources through a sponsoring LIR the option to deal directly with the RIPE NCC without becoming a RIPE NCC member or needing to make contact with their sponsoring LIR. They could do this by authenticating the relevant INETNUM object using their MNTNER, and supplying additional information directly to the RIPE NCC (company registration papers, business address details, contact email, etc.) on a periodic basis (probably every 12-18 months). This option would not entail any fee or contractual agreement for the PI End User. However the Executive Board does not see this as a viable option, as the amount of resources required to check the necessary supporting documentation and other administrative overheads would be too large a financial burden on the RIPE NCC membership. The lack of a periodically-renewed contractual relationship with the PI End User, while providing them this service, may also cause complications. *IMPORTANT* Your opinions and feedback on this proposal are vital in shaping a resource certification system that best suits your needs. We encourage you to discuss this matter on the RIPE NCC members-discuss mailing list. Following approximately six weeks of discussion (ending on 30 March 2013), the Executive Board will consider feedback from the list and propose options on moving forward on this matter which will be properly communicated. Kind regards, Axel Pawlik Managing Director RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Mon Feb 11 15:59:33 2013 From: randy at psg.com (Randy Bush) Date: Mon, 11 Feb 2013 06:59:33 -0800 Subject: [ncc-services-wg] [news] RPKI and PI End Users Proposal - Feedback Requested In-Reply-To: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> Message-ID: other issues aside (am busy hacking) this seems to omit the equivalent of option 2.4 in 2012-07, to quote 2.4 Option to engage directly with the RIPE NCC A Legacy Internet Resource Holder whose circumstances match those described in section 2.3 above, but cannot find a Sponsoring LIR with which a mutually satisfactory contract of the kind mentioned in that section, may opt to enter a non-member service contract with the RIPE NCC for the purposes of registering the Legacy Resources involved, subject to the conditions defined in Section 3 below. randy From nick at netability.ie Mon Feb 11 16:03:13 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 11 Feb 2013 15:03:13 +0000 Subject: [ncc-services-wg] [ncc-announce] [news] RPKI and PI End Users Proposal - Feedback Requested In-Reply-To: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> Message-ID: <51190831.2020802@netability.ie> On 11/02/2013 13:55, Axel Pawlik wrote: > The functionality that we most commonly receive requests for is to make > address space held by Provider Independent (PI) End Users eligible for > certification. During the RIPE 65 Meeting in Amsterdam, there were > discussions on this and the RIPE NCC Executive Board extensively > deliberated the issue. Based on these discussions, the Executive Board > now submits this proposal for consideration and discussion to you, the > RIPE NCC membership and the RIPE community. If I'm reading this correctly, the board has already decided to provide RPKI services to PI address holders without a RIPE community policy proposal or a RIPE NCC membership vote, and this email is just soliciting opinions on the terms of this decision. Could I respectfully suggest that the board put this proposal through the normal channels for policy development, i.e. the PDP. Nick From lists-ripe at c4inet.net Mon Feb 11 16:07:32 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 11 Feb 2013 15:07:32 +0000 Subject: [ncc-services-wg] [ncc-announce] [news] RPKI and PI End Users Proposal - Feedback Requested In-Reply-To: <51190831.2020802@netability.ie> References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> <51190831.2020802@netability.ie> Message-ID: <20130211150732.GA96424@cilantro.c4inet.net> On Mon, Feb 11, 2013 at 03:03:13PM +0000, Nick Hilliard wrote: >Could I respectfully suggest that the board put this proposal through >the normal channels for policy development, i.e. the PDP. I thought the decision at the time was that the provision of rpki services was independent of, rsp. not subject to, policy? Notwithstanding, I think the board may be well advised to put this up for vote at the upcoming GM... cheers, Sascha From nick at netability.ie Mon Feb 11 18:37:12 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 11 Feb 2013 17:37:12 +0000 Subject: [ncc-services-wg] [ncc-announce] [news] RPKI and PI End Users Proposal - Feedback Requested In-Reply-To: <20130211150732.GA96424@cilantro.c4inet.net> References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> <51190831.2020802@netability.ie> <20130211150732.GA96424@cilantro.c4inet.net> Message-ID: <51192C48.3030303@netability.ie> On 11/02/2013 15:07, Sascha Luck wrote: > I thought the decision at the time was that the provision of rpki > services was independent of, rsp. not subject to, policy? The RIPE NCC originally provided RPKI services under the terms of the Certification Task Force; these terms were explicitly outlined in the text of the ill-fated 2008-08, which stated in the explanation part: > Once a policy for resources held by LIRs has been discussed and the > community has agreed on guidelines, then the CA-TF will consider more > complicated scenarios, such as PI address space and ERX and legacy > address space. This phased development is also inline with the technical > implementation of the system, as certificates for LIR resource holders > are the first real cases for the certification system. Certification of > other resources will be implemented later on. While the proposal failed to achieve consensus, this sentence did specify the terms of reference for the RIPE NCC's engagement for providing RPKI services at the time and it was clear that it excluded PI / ERX address blocks. There were two proposals at the November 2011 General Meeting to change the RIPE NCC's mandate: Option A was to instruct the board to drop RPKI completely and Option B was to continue RPKI development, but without ROAs. Neither proposal received enough support to be adopted, so the board assumed a mandate to continue with the existing arrangements: > If neither resolution is adopted, the RIPE NCC will continue the current > Certification/RPKI activities of the association. (http://www.ripe.net/lir-services/ncc/gm/november-2011/agenda) My reading of this is that if the board wants to proceed with RPKI for PI holders - and later, ERX holders - it will need a mandate from the RIPE Community and probably also the RIPE NCC membership. Nick From lists-ripe at c4inet.net Wed Feb 13 13:04:41 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 13 Feb 2013 12:04:41 +0000 Subject: [ncc-services-wg] [address-policy-wg] 2012-05 Proposal Accepted - Request for Clarification In-Reply-To: References: Message-ID: <20130213120441.GA5418@cilantro.c4inet.net> Hi, On Tue, Feb 12, 2013 at 03:55:30PM +0100, Emilio Madaio wrote: >The updated RIPE document is ripe-577 and is available at: > >https://www.ripe.net/ripe/docs/ripe-577 ripe-577 contains, in S5.5 the sentence: "Re-allocated blocks will be signed to establish the current allocation owner." What does this refer to? Does this mean these blocks will *mandatorily* be signed with a RPKI certificate and, if yes, how does that square with the NCC's stated policy that RPKI certs will always be voluntary? Regards, Sascha Luck From alexb at ripe.net Wed Feb 13 15:48:49 2013 From: alexb at ripe.net (Alex Band) Date: Wed, 13 Feb 2013 15:48:49 +0100 Subject: [ncc-services-wg] IPv4 Transfer Listing Service: Streamlining Resource Transfers Message-ID: Dear colleagues, Over a year ago, the RIPE NCC introduced the IPv4 Transfer Listing Service, aimed at streamlining the resource transfer process: https://www.ripe.net/lir-services/resource-management/listing When the service was launched, it gave RIPE NCC members the ability to list the IPv4 address space they held and were looking to transfer. In November, we announced that RIPE NCC members would soon be able to use the service to list IPv4 transfers they would like to receive, and we are happy to confirm that this feature has now been added. Members can indicate their desired prefix size, whether the transfer is to be permanent or temporary, and any other details they wish to disclose. Only RIPE NCC members can view the details in the LIR Portal. In addition, the RIPE NCC has published a section with information relating to IPv4 transfers on our website. This will be updated as-needed to reflect any changes to RIPE Policies or procedures: https://www.ripe.net/lir-services/resource-management/ipv4-transfers For those interested in transfers, there are currently two policy proposals from the RIPE community in the PDP that are being discussed in the RIPE Address Policy Working Group: - 2012-02, Policy for Inter-RIR Transfers of IPv4 Address Space - 2012-03, Intra-RIR Transfer Policy Proposal If you have any questions, please do not hesitate to contact us. Kind regards Alex Band Product Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From rogerj at gmail.com Wed Feb 13 20:51:44 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Wed, 13 Feb 2013 20:51:44 +0100 Subject: [ncc-services-wg] [address-policy-wg] 2012-05 Proposal Accepted - Request for Clarification In-Reply-To: <20130213120441.GA5418@cilantro.c4inet.net> References: <20130213120441.GA5418@cilantro.c4inet.net> Message-ID: On Wed, Feb 13, 2013 at 1:04 PM, Sascha Luck wrote: > Hi, > > On Tue, Feb 12, 2013 at 03:55:30PM +0100, Emilio Madaio wrote: > >> The updated RIPE document is ripe-577 and is available at: >> >> https://www.ripe.net/ripe/docs/ripe-577 > > > ripe-577 contains, in S5.5 the sentence: > > "Re-allocated blocks will be signed to establish the current allocation > owner." > > What does this refer to? Does this mean these blocks will *mandatorily* > be signed with a RPKI certificate and, if yes, how does that square with > the NCC's stated policy that RPKI certs will always be voluntary? I really hope that's a type or forgotten connection somehow. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From lists-ripe at c4inet.net Wed Feb 13 21:07:22 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Wed, 13 Feb 2013 20:07:22 +0000 Subject: [ncc-services-wg] [address-policy-wg] 2012-05 Request for Clarification In-Reply-To: References: <20130213120441.GA5418@cilantro.c4inet.net> Message-ID: <20130213200722.GA6735@cilantro.c4inet.net> On Wed, Feb 13, 2013 at 08:51:44PM +0100, Roger J?rgensen wrote: >I really hope that's a type or forgotten connection somehow. That's quite possible, it came in in 2007 and pre-dates the rpki roll-out... cheers, Sascha From niall.oreilly at ucd.ie Thu Feb 14 11:59:34 2013 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Thu, 14 Feb 2013 10:59:34 +0000 Subject: [ncc-services-wg] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: References: Message-ID: On 17 Oct 2012, at 20:11, Randy Bush wrote: > this one seems a no brainer to me. it's just part of proper and open > documentation of registration and allocation, the ncc's primary job. > > as far as the lir not wanting to be known to have sponsored a pi site, > if the lir is ashamed of doing something, maybe they should not have > done it. i just don't get this stuff. > > correct and open documentation is the ncc's primary job. Although I've let the closing date of the Discussion Phase slip by, I hope it's not too late to say that this seems a no-brainer to me too, that I agree with Randy's remark about the NCC's "primary job", and that I hope the proposer will decide to advance this proposal to the Review Phase. /Niall From tore at fud.no Thu Feb 14 15:19:27 2013 From: tore at fud.no (Tore Anderson) Date: Thu, 14 Feb 2013 15:19:27 +0100 Subject: [ncc-services-wg] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: References: Message-ID: <511CF26F.2090204@fud.no> * Niall O'Reilly > On 17 Oct 2012, at 20:11, Randy Bush wrote: > >> this one seems a no brainer to me. it's just part of proper and open >> documentation of registration and allocation, the ncc's primary job. >> >> as far as the lir not wanting to be known to have sponsored a pi site, >> if the lir is ashamed of doing something, maybe they should not have >> done it. i just don't get this stuff. >> >> correct and open documentation is the ncc's primary job. > > Although I've let the closing date of the Discussion Phase slip by, > I hope it's not too late to say that this seems a no-brainer to me too, > that I agree with Randy's remark about the NCC's "primary job", and > that I hope the proposer will decide to advance this proposal to the > Review Phase. What Randy and Niall said. Support. -- Tore Anderson From rogerj at gmail.com Thu Feb 14 21:42:38 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Thu, 14 Feb 2013 21:42:38 +0100 Subject: [ncc-services-wg] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: References: Message-ID: On 17 Oct 2012, at 20:11, Randy Bush wrote: > this one seems a no brainer to me. it's just part of proper and open > documentation of registration and allocation, the ncc's primary job. > > as far as the lir not wanting to be known to have sponsored a pi site, > if the lir is ashamed of doing something, maybe they should not have > done it. i just don't get this stuff. > > correct and open documentation is the ncc's primary job. I'm surprised this hasn't been fixed before, supported. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From maildanrl at gmail.com Thu Feb 14 23:48:14 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Thu, 14 Feb 2013 23:48:14 +0100 Subject: [ncc-services-wg] [ncc-announce] [news] RPKI and PI End Users Proposal - Feedback Requested In-Reply-To: <51192C48.3030303@netability.ie> References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> <51190831.2020802@netability.ie> <20130211150732.GA96424@cilantro.c4inet.net> <51192C48.3030303@netability.ie> Message-ID: Hi all, as a PI ressource holder, I appreciate that the board is taken action. Option 1 is probably the easiest way for PI ressource holders to take part in RPKI. Option 2 does not seem new to me?! However, the more members the better, i guess. Thanks for trying to solve the PI-RPKI issue! Dan -- Dan Luedtke http://www.danrl.de From brian.nisbet at heanet.ie Fri Feb 15 12:38:36 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Fri, 15 Feb 2013 11:38:36 +0000 Subject: [ncc-services-wg] Fwd: [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: References: Message-ID: <511E1E3C.5060808@heanet.ie> Good people of the NCC Services WG, The following policy '2013-01 Openness about Policy Violations' started it's trip through the PDP yesterday. While the discussions on this proposal will take place in the Anti-Abuse working group, I just wanted to make sure this WG was aware as there are obvious implications for NCC processes & procedures. Brian Co-Chair, RIPE AA-WG -------- Original Message -------- Subject: [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) Date: Thu, 14 Feb 2013 15:05:23 +0100 From: Emilio Madaio Reply-To: anti-abuse-wg at ripe.net To: policy-announce at ripe.net CC: anti-abuse-wg at ripe.net Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-01 We encourage you to review this proposal and send your comments to before 14 March 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC From emadaio at ripe.net Fri Feb 15 13:51:11 2013 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 15 Feb 2013 13:51:11 +0100 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) Message-ID: Dear Colleagues, The Discussion Period for the proposal 2012-08, "Publication of Sponsoring LIR for Independent Number Resources", has been extended until 1 March 2013. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-08 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From lists-ripe at c4inet.net Fri Feb 15 16:51:08 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 15 Feb 2013 15:51:08 +0000 Subject: [ncc-services-wg] Fwd: [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <511E1E3C.5060808@heanet.ie> References: <511E1E3C.5060808@heanet.ie> Message-ID: <20130215155108.GA14735@cilantro.c4inet.net> On Fri, Feb 15, 2013 at 11:38:36AM +0000, Brian Nisbet wrote: >The following policy '2013-01 Openness about Policy Violations' >started it's trip through the PDP yesterday. While the discussions on >this proposal will take place in the Anti-Abuse working group, I just >wanted to make sure this WG was aware as there are obvious >implications for NCC processes & procedures. Utterly and completely unacceptable. The proposal, in its current form, is akin to the police publishing every complaint they receive, with full details of the subject of the complaint, whether justified or not. I also note that is "The identity of the submitter, if the submitter indicated that it can be made public;" No such protection is afforded the subject of the complaint. This proposal is nothing but a denunciant's charter, the legality of which is doubtful (NCC Legal please to comment). The idea that publishing these reports makes abuse of the reporting system less likely - where the attack *is* the publishing of these reports - is laughable. I therefore register my vehement opposition and, indeed, protest against this proposal in its current form. As a possible compromise, I could accept the publication of reports where the NCC has found that a violation was indeed committed. Regards, Sascha Luck From sander at steffann.nl Fri Feb 15 22:23:38 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 15 Feb 2013 22:23:38 +0100 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <20130215155108.GA14735@cilantro.c4inet.net> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> Message-ID: <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> Hi Sascha, > Utterly and completely unacceptable. The proposal, in its current form, is akin to the police publishing every complaint they receive, with full details of the subject of the complaint, whether justified or not. I also note that is "The identity of the submitter, if the submitter indicated that it can be made public;" No such protection is afforded the subject of the complaint. Fair point. But would you really give any value to an anonymous report that is marked as closed,no-violation? > This proposal is nothing but a denunciant's charter, the legality of which is doubtful (NCC Legal please to comment). The idea that publishing these reports makes abuse of the reporting system less likely - where the attack *is* the publishing of these reports - is laughable. > > I therefore register my vehement opposition and, indeed, protest against this proposal in its current form. As a possible compromise, I could accept the publication of reports where the NCC has found that a violation was indeed committed. Publishing nothing at all would not be acceptable to me. Letting the RIPE NCC do some 'spam filtering' before publishing anything would not be a problem, but waiting until the complaint is completely resolved would not make the process more visible. A big problem I have with reporting something to the police is that you never see if action has been taken, and that gives the feeling that reporting is useless, even when it is not. I want to change that. How about initially only publishing: - Date submitted; - The resources the report is about; - The identity of the submitter, if the submitter indicated that it can be made public; - The current state. The exact content of the report is not the most important part to me. Then (for example) if someone was then sending in bogus complaints about my IPv4 allocation the only published information would be: - 2013-04-01 - 37.77.56.0/21 - Anonymous submitter - closed,no-violation Not that exciting... Cheers, Sander From lists-ripe at c4inet.net Fri Feb 15 23:38:43 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Fri, 15 Feb 2013 22:38:43 +0000 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> Message-ID: <20130215223843.GA15924@cilantro.c4inet.net> Hi Sander, On Fri, Feb 15, 2013 at 10:23:38PM +0100, Sander Steffann wrote: >Fair point. But would you really give any value to an anonymous report >that is marked as closed,no-violation? I might not, others might - or draw inferences from the fact that there are complaints and the number thereof. Even if they are marked as closed/no violation. >Publishing nothing at all would not be acceptable to me. Letting the >RIPE NCC do some 'spam filtering' before publishing anything would not >be a problem, but waiting until the complaint is completely resolved >would not make the process more visible. A big problem I have with >reporting something to the police is that you never see if action has >been taken, and that gives the feeling that reporting is useless, even >when it is not. I want to change that. It is like that for a reason - which is "in dubio pro reo" or "innocent until proven guilty" The police will (in most places) only publish anything if they arrest or charge anyone, and *never* the identity "a male, aged 34 was arrested". Everything else would be considered libel/slander here and media have been sued, and been sentenced to pay large sums of money, for disclosing stuff ike that. How would you feel if the cops published lists like: -Sander Stefann -complaint for kiddiepr0n -anonymous submitter -being investigated ? That sort of stuff sticks and never goes away even if it is subsequently found to be bullshit. >How about initially only publishing: - Date submitted; - The resources >the report is about; - The identity of the submitter, if the submitter >indicated that it can be made public; - The current state. Nope, no way, not unless a violation is determined - akin to being found guilty in a court of law. Also, the identity of the submitter MUST be published even in this case. No anonymity for snitches, the Stasi wasn't *that* long ago >Not that exciting... It'll be exciting when the membership fees go up to pay for the libel convictions the NCC will have to pay for... cheers, Sascha From sander at steffann.nl Sat Feb 16 13:47:45 2013 From: sander at steffann.nl (Sander Steffann) Date: Sat, 16 Feb 2013 13:47:45 +0100 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <20130215223843.GA15924@cilantro.c4inet.net> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> Message-ID: Hi Sascha, > How would you feel if the cops published lists like: > > -Sander Stefann > -complaint for kiddiepr0n > -anonymous submitter > -being investigated ? > > That sort of stuff sticks and never goes away even if it is subsequently > found to be bullshit. Sorry, but you are pulling this whole discussion out of context and proportion. > Nope, no way, not unless a violation is determined - akin to being found > guilty in a court of law. > > Also, the identity of the submitter MUST be published even in this case. > No anonymity for snitches, the Stasi wasn't *that* long ago Ok, and this even more so. I am ending this thread right now. Sander From jorgen at hovland.cx Sat Feb 16 15:14:33 2013 From: jorgen at hovland.cx (Jørgen Hovland) Date: 16 Feb 2013 14:14:33 +0000 (GMT) Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal(Openness about Policy Violations) Message-ID: <511f94494b2c86fad70021d06255.jorgen@hovland.cx> An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Sat Feb 16 22:57:20 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Sat, 16 Feb 2013 22:57:20 +0100 Subject: [ncc-services-wg] [news] RPKI and PI End Users Proposal - Feedback Requested In-Reply-To: <50B634E7-1E14-4F45-A7FF-F3952B3ABE93@ripe.net> References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> <50B634E7-1E14-4F45-A7FF-F3952B3ABE93@ripe.net> Message-ID: <002001ce0c90$985208a0$c8f619e0$@a2b-internet.com> Hi, As I read the email the question in the email is to provide feedback. How the feedback from the community is used is something that is a different matter. Getting feedback doesn?t mean that a decision is made. > 1. Sign an agreement with their sponsoring LIR (a RIPE NCC member) to > have the resources certified by the RIPE NCC via the sponsoring LIR. In > this case, the sponsoring LIR would be responsible for periodically > verifying that the PI End User is the legitimate holder of the > resources. No questions there ? However, the RIPE NCC will in all cases be responsible for issuing the resource certificate and providing access to the RPKI management interface. Therefore, PI End Users should, at all times, be able to change from one sponsoring LIR to another while still retaining the same certificate for the resources that they hold. I agree that PI End Users should be able to change sponsoring LIR, however the new Sponsoring LIR will have to go through the paperwork. What I would rather see, is that the ROA is re-setup instead of migrated. I?m not exactly sure why, but to me that would be a cleaner way of dealing with moving from sponsoring LIR to another. ? The cost associated with this option lies in building a framework in the LIR Portal to facilitate the process, some administrative overhead, and the additional burden on the RPKI infrastructure, that would not be funded by the direct beneficiary of the resource certification service. These costs would come out of the general RIPE NCC budget and would therefore be funded by all RIPE NCC members, however it is unlikely that this would have any direct impact on future membership fees. It might be good to get some kind of budget for this, before we make assumptions if this would have an impact on the future fees. That might also provide some insight if the current fee for PI resources are covering the fees or if there is change needed. As PI space has a cost (also in the current charging scheme), it should be looked at if the cost for this, can be covered by the PI resource fees, not increasing the member fees. ? Alternatively a PI End User may choose to: 2. Become a RIPE NCC member, pay the full annual membership fee and receive a certificate directly through the RIPE NCC. The Executive Board feels that offering both of these options will result in relatively little impact on membership fees while offering all PI End Users the opportunity to certify their Internet number resources without being forced to become a member of the RIPE NCC. No questions on the option becoming a member, that should always be an option ? For the sake of completeness, we also present a third scenario discussed by the Executive Board that would involve giving PI End Users that have received resources through a sponsoring LIR the option to deal directly with the RIPE NCC without becoming a RIPE NCC member or needing to make contact with their sponsoring LIR. They could do this by authenticating the relevant INETNUM object using their MNTNER, and supplying additional information directly to the RIPE NCC (company registration papers, business address details, contact email, etc.) on a periodic basis (probably every 12-18 months). This option would not entail any fee or contractual agreement for the PI End User. However the Executive Board does not see this as a viable option, as the amount of resources required to check the necessary supporting documentation and other administrative overheads would be too large a financial burden on the RIPE NCC membership. The lack of a periodically-renewed contractual relationship with the PI End User, while providing them this service, may also cause complications. I agree that this might not be the best option. I would prefer to have the End-User deal with the Sponsoring LIR (or RIPE in case it is a Direct End-User) But it should be discussed with the community if there should be a method for a PI End-User to deal directly with the RIPE NCC (via an online process). I don?t think that the Exec Board should dismiss that option upfront. Also, it should be looked into if there will be an additional charge for the PI Certification process Will PI space holders see the value for themselves if there is a choice of paying and getting their resource certified. There is clearly more work involved for all parties. If the process is approved, it might be best to not have a separate cost for the certification process, but rather check if the current cost of PI resources need to be looked at when this is going to included. On the topic how and where this should be discussed and more importantly where that should be decided, is something for a new thread imho. Regards, Erik Bais -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Sat Feb 16 23:44:24 2013 From: sander at steffann.nl (Sander Steffann) Date: Sat, 16 Feb 2013 23:44:24 +0100 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> Message-ID: Hi all, >> Nope, no way, not unless a violation is determined - akin to being found >> guilty in a court of law. >> >> Also, the identity of the submitter MUST be published even in this case. >> No anonymity for snitches, the Stasi wasn't *that* long ago > > Ok, and this even more so. I am ending this thread right now. Ok, that was probably too strong. I do want this discussion to take place. I wrote this first version of the policy proposal for maximum openness. And I see the potential risks with openly publishing complaints. I want the community to determine where the limits are in regard to publishing complaints etc. I didn't really expect everyone to agree to the current text. But I did not expect such language and comparisons on this list, and it shocked me. As one of the proposers I ask you to please participate in a constructive discussion here to see what is possible and desirable and what is not. Thank you, Sander From brian.nisbet at heanet.ie Sun Feb 17 17:23:50 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Sun, 17 Feb 2013 16:23:50 +0000 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <20130215223843.GA15924@cilantro.c4inet.net> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> Message-ID: <51210416.3040706@heanet.ie> Sascha, On 15/02/2013 22:38, Sascha Luck wrote: > > How would you feel if the cops published lists like: > > -Sander Stefann > > That sort of stuff sticks and never goes away even if it is subsequently > found to be bullshit. You are making your point quite clearly, there is no need to make comparisons like that, especially, as we all know, things have a way of being taken out of context and hanging around the Internet forever. > > Also, the identity of the submitter MUST be published even in this case. > No anonymity for snitches, the Stasi wasn't *that* long ago Equally, let's not make leaps like this either. Make your objections in a sensible, logical way, which I'm sure you're capable of doing, please. Brian Co-Chair, AA-WG From randy at psg.com Sun Feb 17 20:00:37 2013 From: randy at psg.com (Randy Bush) Date: Mon, 18 Feb 2013 04:00:37 +0900 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <51210416.3040706@heanet.ie> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> <51210416.3040706@heanet.ie> Message-ID: this proposal was alarmingly ill-advised. castigating sascha for being alarming does little except bring it to a personal level. randy From brian.nisbet at heanet.ie Sun Feb 17 21:13:49 2013 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Sun, 17 Feb 2013 20:13:49 +0000 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> <51210416.3040706@heanet.ie> Message-ID: <512139FD.3030504@heanet.ie> On 17/02/2013 19:00, Randy Bush wrote: > this proposal was alarmingly ill-advised. castigating sascha for being > alarming does little except bring it to a personal level. I felt this had already been brought to a personal level. I was asking that reasonable arguments, of which I'm quite sure Sascha has many, be used, rather than things that a lot of people would feel went a little far. My intent is to discuss the proposal, not the proposers. Let us assume the best of intentions on all parts and leave it at that? Brian From lists-ripe at c4inet.net Sun Feb 17 22:23:58 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sun, 17 Feb 2013 21:23:58 +0000 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <51210416.3040706@heanet.ie> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> <51210416.3040706@heanet.ie> Message-ID: <20130217212358.GA24726@cilantro.c4inet.net> Hi Brian, On Sun, Feb 17, 2013 at 04:23:50PM +0000, Brian Nisbet wrote: >>That sort of stuff sticks and never goes away even if it is subsequently >>found to be bullshit. > >You are making your point quite clearly, there is no need to make >comparisons like that, especially, as we all know, things have a way >of being taken out of context and hanging around the Internet >forever. which was part of the point I'm making. Making accusations - which complaints about policy violations essentially are - public is asking for them to be tried in the court of public opinion. cheers, Sascha Luck From lists-ripe at c4inet.net Sun Feb 17 22:33:02 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sun, 17 Feb 2013 21:33:02 +0000 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> Message-ID: <20130217213302.GB24726@cilantro.c4inet.net> Hi Sander, On Sat, Feb 16, 2013 at 11:44:24PM +0100, Sander Steffann wrote: >I didn't really expect everyone to agree to the current text. But I did >not expect such language and comparisons on this list, and it shocked >me. As one of the proposers I ask you to please participate in a >constructive discussion here to see what is possible and desirable and >what is not. if you were under the impression I was attacking you personally, I apologize, that was not my intent. I am quite alarmed by the proposal though, and I don't think my comparisons are that off either, considering the area of resource management having become a lot more competitive, as opposed to, co-operative since ipv4 depletion. as for what is possible, I've thought more on it and have formend the opinion that the only thing out of it, I could accept, is publication of the fects if a complaint was upheld *and* resources removed for cause. The reason being that RIPE policy is often ambiguous and contradictory, so a policy violation might simply be the result of a mis-interpretation, difference of opinion or bureaucratic slip-up. Dragging that into the court of public opinion serves nobody, except perhaps a malicious complainant. cheers, Sascha Luck > >Thank you, Sander > From sander at steffann.nl Mon Feb 18 07:55:22 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 18 Feb 2013 07:55:22 +0100 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <20130217213302.GB24726@cilantro.c4inet.net> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> <20130217213302.GB24726@cilantro.c4inet.net> Message-ID: Hi Sascha, >> I didn't really expect everyone to agree to the current text. But I did >> not expect such language and comparisons on this list, and it shocked >> me. As one of the proposers I ask you to please participate in a >> constructive discussion here to see what is possible and desirable and >> what is not. > > if you were under the impression I was attacking you personally, I > apologize, that was not my intent. [...] Thanks. Let's start focussing on the proposal again :-) > as for what is possible, I've thought more on it and have formend the > opinion that the only thing out of it, I could accept, is publication > of the fects if a complaint was upheld *and* resources removed for > cause. Your comment is still focused on one aspect of the draft text, but you haven't responded yet to any alternatives I proposed. The last one was the one I sent on Saturday: I want to suggest the following direction for this proposal: Change section 1 (1. Transparency on reported policy violations) to: - RIPE NCC publishes statistics on complaints/reports (number of complaints in each state: new, under investigation, etc) - RIPE NCC provides a way for the complainer and resource holder to see the progress, keeping the currently existing privacy options And leave section 2 (2. Transparency on reclaimed resources) as it currently is. I haven't seen any objections to that part yet. Please focus on this suggestion now. It is obvious that we are never getting consensus on the 'old' text :-) Thanks, Sander From rfg at tristatelogic.com Sun Feb 17 23:57:03 2013 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 17 Feb 2013 14:57:03 -0800 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <512139FD.3030504@heanet.ie> Message-ID: <19210.1361141823@server1.tristatelogic.com> I just wanted to comment briefly on the proposal now under consideration. I would have interjected quite a lot of follow-up comments on all of the comments that have been made here so far about this, but I've been tied up on other critical projects for the past several days. I don't want anybody to get the idea that I don't care about the proposal at hand. I do, passionately, but I have rather a different take on it, I think, than what I've seen expressed by others so far. The point has been made that publishing (or re-publishing) baseless accusations is un-good. There probably won't be a lot of disagreement on that general point. But more generally I think it has to be recognized that when it comes to the dispersal of information... accurate or otherwise... the Internet is, and is likely to remain, very much the Wild Wild West, and in the final analysis, there is not all that much that can be done about most of the baseless slander that occurs on the Internet every day. I'll just cite two cases in point. The first is ripped from recent headlines: http://www.usatoday.com/story/news/nation/2013/02/06/go-daddy-sued-over-revenge-porn-site/1897695/ The general opinion among legal experts... with which I concur... is that under current U.S. law GoDaddy, despite having itself hosted a web site featuring "revenge" nude photos of ex-girlfriends, is not in any way liable for that. The ladies who have been offended by the web site in question may indeed have suffered deep anguish, but they will need to seek redress for those grievances elsewhere. Second, I remember clearly that quite a number of years ago now I par- ticipated, along with countless others, in a USENET newsgroup called news.admin.net-abuse.email. Back at that time, one of the most colorful and unambiguously demented denizens of that newsgroup was a fellow going by the name of "Dr. Grubor". So anyway, long story short, Dr. Grubor, publically and in the neswgroup, called me a paedophile. Of course, there was no basis whatsoever for his accusation, and I was understandably outraged. I was preparing to initiate legal action over Dr. Grubor's outrageous slander, and would probably have done so if I had not realized, in sort order, that Dr. Grubor had already accused about 80% of the other newsgroup participants of being paedophiles, before he even got around to calling me one. Given this reality, and that fact that Dr. Grubor's only remaining shreads of credibility were with the small handful of other seriously ill newsgroup participants, in the end I thought better of wasting my time and money pursuing legal damages against a nutcase that no one of any importance took seriously anyway. All the above having been said, there are just two simple points I want to make. First, as illustrated by the above two anecdotes, it isn't really prag- matically possible, here in the "information age", to stop people from spreading hurtful material and/or bald faced lies about one, or about one's company. Second, whereas I agree completely that there should exist, somewhere, an unfiltered uncensored place where people can post what they know, or even what they believe they know about various Internet number resources (and by implication, about the entities to which those have been assigned) I am not persuaded that either RIPE or any other RiR either could be or should be either the sponsors or the adminitsrators of any such web site. Rather, I am coming around to the opinion that this kind of function necessarily must be performed by, and must be under the control of some- one or something that is distinctly _not_ connected, financially or otherwise, to any of the RiRs, to IANA, to ICANN, or to the U.S. Department of Commerce (from which, the authority and the responsibility of all of thes other entities ultimately devolves). I think that this whole discussion (and the proposal at hand) came up, at least in part, because not everyone believes that RIPE is actively policing the resources it is the ultimate steward of, without either fear or favor. Additionally, the completely lack of transparancy with respect to such policing certainly contributes mightily to fostering that exact viewpoint. However I doubt that asking, demaning, or directing RIPE itself to be more transparent about these matters is likely to provide an actual solution to the perceived credibility gap. A reference to foxes and henhouses may be appropriate here. If, at the direction of the membership, RIPE NCC began publishing _some_ information, would anyone ever feel 100% confident that they were publishing _all_ relevant infor- mation? I wouldn't, but then I am suspicious by nature. Separately, there is indeed a legal liability issue inherent in this whole idea that cannot just be swept under the carpet. I rather doubt that there is much in the way of a constituency, within the RIPE membership, that is eager for RIPE NCC to go around wlly-nilly, sticking its neck into the proverbial legal noose by publishing, or re-publishing potentially actionable defamations. Defending the indefensible, perhaps at considerable financial cost, is not something I see as being on either RIPE's or RIPE NCC's agenda anytime soon. Journalism, for better or worse, is just not within the fundamental purpose of these organizations, and I think that it will be hard to find many RIPE member organizations who are eager to have their annual fees increased in order to support a high-priced legal defense team. For the reasons given above, at the present moment I believe that it must necessarily fall to some outside and unrelated person, entity, or organization to publish, without fear or favor, negative information about Internet number resources and the parties to whom those have been assigned. I am currently contemplating whether or not I myself want to be that publisher. So far, I am not favorably disposed to getting involved. The problem is that quite a lot of work would be involved, I think, in order to do a proper job, and I actually had a number of other things that I wanted to do this lifetime. Maybe if I could find two or three willing and able volunteers to help in the construction and deployment of a simple web site... Regards, rfg From pk at DENIC.DE Mon Feb 18 13:32:03 2013 From: pk at DENIC.DE (Peter Koch) Date: Mon, 18 Feb 2013 13:32:03 +0100 Subject: [ncc-services-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> <20130217213302.GB24726@cilantro.c4inet.net> Message-ID: <20130218123203.GP27968@x28.adm.denic.de> Sander, all, On Mon, Feb 18, 2013 at 07:55:22AM +0100, Sander Steffann wrote: > Thanks. Let's start focussing on the proposal again :-) for the record, so that there's not only one voice against, I share Sascha's concerns. The proposal fails to assess the risk of 'sticking rumor' and also fails to explain what the exact goal is (actually, there might be two radically orthogonal ones) and why the proposed measures would support that goal. > Your comment is still focused on one aspect of the draft text, but you haven't responded yet to any alternatives I proposed. The last one was the one I sent on Saturday: > > I want to suggest the following direction for this proposal: > Change section 1 (1. Transparency on reported policy violations) to: > - RIPE NCC publishes statistics on complaints/reports (number of complaints in each state: new, under investigation, etc) > - RIPE NCC provides a way for the complainer and resource holder to see the progress, keeping the currently existing privacy options > > And leave section 2 (2. Transparency on reclaimed resources) as it currently is. I haven't seen any objections to that part yet. > > Please focus on this suggestion now. It is obvious that we are never getting consensus on the 'old' text :-) I see two motivations in the PP: 1) alleged or perceived intransparency on 'complaint' handling at the NCC As curious as I might be myself, I fail to see why a complainant would deserve deeper insight into the state of investigation than anybody else or why this should happen in public. As an NCC oversight issue, a summary that will not identify any particular case, should be sufficient if it included start, end and duration. 2) "stopping abuse of these shared public resources" This really concerns me, but maybe by even only doubting I have already committed the abuse? We can surely discuss violations of allocation/assignment policies, especially the obtainment of resources by wilful submisison of wrong, forged or falsified information, but this is much different from any judgement about the use of tehse resources once they have been compliantly acquired. The NCC is not in the business of the latter. -Peter From Johannes.Kornfellner at parlament.gv.at Mon Feb 18 14:53:58 2013 From: Johannes.Kornfellner at parlament.gv.at (Kornfellner Johannes, Ing.) Date: Mon, 18 Feb 2013 14:53:58 +0100 Subject: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) Message-ID: <423BD80F5ED95C4AADDC1DB9E29C90121E1B9CBF0B@pdexst2.parlinkom.gv.at> Hello, this proposal (https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-January/001972.html) seems to provide a good balance between the legacy resource holders' existing rights and community's wish for accurate registration data. It provides several options for a direct or indirect contractual relationship between a Legacy Internet Resource Holder and the RIPE NCC. I think that this crucial to cover the different needs of the different legacy resource holders. I therefore support this proposal. Best Regards, Ing. Johannes Kornfellner Parlamentsdirektion A1.5 EDV / Systemgruppe [file:///C:\Users\jk\AppData\Roaming\Microsoft\Signatures\CorporateDesign.jpg] A-1017 Wien - Parlament Tel. +43 1 401 10-2822 Mob. +43 676 8900 2822 Fax +43 1 401 10-2848 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists-ripe at c4inet.net Mon Feb 18 15:27:33 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 18 Feb 2013 14:27:33 +0000 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> <20130217213302.GB24726@cilantro.c4inet.net> Message-ID: <20130218142733.GA29670@cilantro.c4inet.net> On Mon, Feb 18, 2013 at 07:55:22AM +0100, Sander Steffann wrote: >I want to suggest the following direction for this proposal: Change >section 1 (1. Transparency on reported policy violations) to: - RIPE >NCC publishes statistics on complaints/reports (number of complaints in >each state: new, under investigation, etc) No issue with anonymised statistics. Actually I thought this was done already - might have been a presentation at one of the meetings I remember... > - RIPE NCC provides a way >for the complainer and resource holder to see the progress, keeping the >currently existing privacy options possibly, I'll have to think on this some more. >And leave section 2 (2. Transparency on reclaimed resources) as it >currently is. I haven't seen any objections to that part yet. "policy violation" is likely to catch some honest mistakes or changed circumstances. I'd be in favour of publishing this only if the resources were reclaimed because of a conscious act (fraudulent registration, falsified (as opposed to merely incorrect) information) cheers, Sascha Luck From sander at steffann.nl Mon Feb 18 15:53:32 2013 From: sander at steffann.nl (Sander Steffann) Date: Mon, 18 Feb 2013 15:53:32 +0100 Subject: [ncc-services-wg] [anti-abuse-wg] 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: <20130218142733.GA29670@cilantro.c4inet.net> References: <511E1E3C.5060808@heanet.ie> <20130215155108.GA14735@cilantro.c4inet.net> <2867B0B4-0EED-4031-9EDC-59C57169FCD9@steffann.nl> <20130215223843.GA15924@cilantro.c4inet.net> <20130217213302.GB24726@cilantro.c4inet.net> <20130218142733.GA29670@cilantro.c4inet.net> Message-ID: Hi Sascha, > "policy violation" is likely to catch some honest mistakes or changed > circumstances. I'd be in favour of publishing this only if the resources > were reclaimed because of a conscious act (fraudulent registration, > falsified (as opposed to merely incorrect) information) The file lists recources returned to the NCC, so the file only lists policy violations if they lead to reclaiming the address space. (It only lists returned resources, and it will only mention a policy violation if that is the reason behind reclaiming them) I think it already matches what you say. If not: please explain what you want to see changed. Cheers, Sander From hamed at skydsl.ir Mon Feb 18 17:55:44 2013 From: hamed at skydsl.ir (Hamed Shafaghi) Date: Mon, 18 Feb 2013 20:25:44 +0330 Subject: [ncc-services-wg] [news] RPKI and PI End Users Proposal - Feedback Requested In-Reply-To: <002001ce0c90$985208a0$c8f619e0$@a2b-internet.com> References: <856266A8-169E-4E62-99DF-7583CEC547E3@ripe.net> <50B634E7-1E14-4F45-A7FF-F3952B3ABE93@ripe.net> <002001ce0c90$985208a0$c8f619e0$@a2b-internet.com> Message-ID: Hi WG We are LIR and we have several active contracts with our customers for sponsoring PI. Because I think PI End User must requests a resource certificate through their sponsoring LIR I think option 1 is good and our customers request will be compatible with this option. *1. Sign an agreement with their sponsoring LIR (a RIPE NCC member) to* *have the resources certified by the RIPE NCC via the sponsoring LIR. In* *this case, the sponsoring LIR would be responsible for periodically* *verifying that the PI End User is the legitimate holder of the* *resources. However, the RIPE NCC will in all cases be responsible for* *issuing the resource certificate and providing access to the RPKI* *management interface. Therefore, PI End Users should, at all times, be* *able to change from one sponsoring LIR to another while still retaining* *the same certificate for the resources that they hold.* * * Regards Hamed Shafaghi -------------- next part -------------- An HTML attachment was scrubbed... URL: From maildanrl at gmail.com Tue Feb 19 17:47:57 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Tue, 19 Feb 2013 17:47:57 +0100 Subject: [ncc-services-wg] [anti-abuse-wg] WG: 2013-01 New Policy Proposal (Openness about Policy Violations) In-Reply-To: References: Message-ID: Hi all, (citing from the proposal) > The RIPE NCC will handle all such reports and update the state accordingly. What I miss, is a state like 'closed, violation took place, ressource not (yet) returned' Otherwise it looks like the whole "returning" comes down to listing the ressource in the 'returned'-file. What happens if the ressource holder is "guilty" but does not want to return the ressources? Does returning mean, we all stop peering/announcing/whatever with the listed ressources? How can we re-allocate the ressources, when someone still uses it (against the ruling of RIPE NCC)? These questions are more technically, because I haven't understood fully how the whole process is meant to work. For the sake of transparency, I'd like to see - Date submitted; - The resources the report is about; - A short summary from RIPE NCC (2-3 lines) [not the initial report] published for alle reports that have the state 'closed,resources-returned'. Furthermore, if the ressource holder agrees, we should publish 'closed,no violation', 'closed,out of scope', 'closed,resolved by holder' reports, too. Just to make sure that subsequent reports will not report the same issue again and again. Best regards Dan -- Dan Luedtke http://www.danrl.de From chrisb at ripe.net Wed Feb 20 15:43:27 2013 From: chrisb at ripe.net (Chris Buckridge) Date: Wed, 20 Feb 2013 15:43:27 +0100 Subject: [ncc-services-wg] Internet Governance and the RIPE NCC: The Year Ahead Message-ID: <4206C49B-9966-4753-8948-0E7C70A21EFE@ripe.net> Dear colleagues, We have just published an article on RIPE Labs that details some of the major Internet governance-related discussions currently taking place, as well as the RIPE NCC's priorities and activities in this area for the coming year. We encourage you to read the article and comment, either on RIPE Labs or on this mailing list. Feedback from the RIPE NCC membership and RIPE community is vital in shaping the RIPE NCC's position and strategy in relation to these issues. We also welcome any suggestions on how to improve the RIPE NCC's engagement with the public sector and other Internet stakeholders in your country or region. You can read the article in full at: https://labs.ripe.net/Members/chrisb/internet-governance-and-the-ripe-ncc-the-year-ahead Best regards, Chris Buckridge External Relations Officer, RIPE NCC From mihael.dimec at arnes.si Wed Feb 20 15:20:10 2013 From: mihael.dimec at arnes.si (Mihael Dimec) Date: Wed, 20 Feb 2013 15:20:10 +0100 Subject: [ncc-services-wg] Support for proposal 2012-07 Message-ID: <5124DB9A.9040703@arnes.si> I support https://www.ripe.net/ripe/policies/proposals/2012-07 Best regards, Mihael Dimec From ripencc-management at ripe.net Thu Feb 21 10:25:48 2013 From: ripencc-management at ripe.net (Andrew de la Haye) Date: Thu, 21 Feb 2013 10:25:48 +0100 Subject: [ncc-services-wg] Policy update request on certification of transferred IPv4 allocations Message-ID: [Apologies for duplicate emails] Dear colleagues, Based on recent discussions on the RIPE Address Policy WG mailing list, the RIPE NCC is now seeking policy related action from the RIPE community with regards to clear guidelines on how it should proceed with certifying transferred IPv4 allocations. It has recently come to our notice, via two of the policy authors, that the original intention (in 2007) of the sentence "Re-allocated blocks will be signed to establish the current allocation owner" was that the transferred block *must* be signed *after* the transfer in order to completely establish holdership. This sentence can be found under section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" here: http://www.ripe.net/ripe/docs/ripe-582#Transfers-of-Allocations Because the RIPE community provided guidance saying that certification should be an opt-in system, the RIPE NCC built an RPKI Certification system based on this opt-in notion, therefore it is not currently possible for the RIPE NCC to issue certificates without the resource holder initiating the process. Therefore, the RIPE NCC's interpretation and implementation of this specific sentence has been: Registration Services verifies and reflects the change in holdership of the re-allocated blocks by updating the database objects and internal records following the transfer. Any certificates that had been attached to these number resources before the transfer automatically become invalid/revoked due to the holdership change. The transfer recipient can then request a new certificate for the address space and the RIPE NCC will proceed to sign these resources to establish the current allocation holder. Therefore, the RIPE NCC does not make certification of any resources mandatory. As the sentence in section 5.5 of "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is open to interpretation, the RIPE NCC is seeking representative(s) from the RIPE community to submit an update to ripe-582 that will replace this sentence with more accurate and appropriate wording or perhaps remove it completely. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.freedman at uk.clara.net Thu Feb 21 10:55:54 2013 From: david.freedman at uk.clara.net (David Freedman) Date: Thu, 21 Feb 2013 09:55:54 +0000 Subject: [ncc-services-wg] Support for proposal 2012-07 Message-ID: +1, support Dave. From andrea at ripe.net Thu Feb 21 12:11:33 2013 From: andrea at ripe.net (Andrea Cima) Date: Thu, 21 Feb 2013 12:11:33 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <5112690E.6000701@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> Message-ID: <512600E5.6030706@ripe.net> Hi Nick, All, On 2/6/13 3:30 PM, Nick Hilliard wrote: > On 04/02/2013 22:12, M?ns Nilsson wrote: >> The "completely estranged LRH holder organisation" is not that common, I >> believe. Wasting electrons on this corner case is not fruitful. > Problem is, I'm not sure it's a corner case; nor am I sure that the > squatters are corner cases, nor the abandoned address blocks. > > Has the RIPE NCC done any preliminary analysis of the ERX space in terms of: > > - rough consistency of link between inetnum: owner and mntner > - when was the last time the resources were updated - According to the initial ERX transfer list, 339 inetnum objects have been deleted. This may however mean that more specific objects have been created by the maintainer. - 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These objects were registered in the RIPE DB before the ERX transfer took place, and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the RIPE NCC locked all objects referencing it. As these objects are still locked, no one is currently managing this data. - 851 inetnum objects have the ERX auto-generated maintainer (in the form ERX-NET-138-81-MNT) as mnt-by. The holders 'may' have been given the password and are 'able' to manage this data, but may or may not have done so. Others were not given the password and are not managing the data. Without deeper analysis we can't separate these groups. - 764 inetnum objects have replaced the ERX aut-generated maintainer (in the form ERX-NET-138-81-MNT) with a different maintainer. This is a clear indication they have taken control of this data since the transfer. - 1835 inetnum objects have the following line removed (which was added during the ERX project) 'remarks: **** INFORMATION FROM ARIN/RIPE OBJECT ****' This is an indication they have taken control of this data since the transfer. - 141 inetnum comply with none of the above. The inetnum objects contain no RIPE-NCC-LOCKED-MNT maintainer and never contained an auto-generated maintainer, and still contain the ERX remarks lines. Without deeper analysis we cannot say anything about this group. I hope this provides you with enough information to quantify the effort. If more information is needed we can do a deeper analysis of the numbers above. > - potential LIR association To identify potential LIRs we looked at the ASes which were seen originating prefixes from the ERX space in RIS in the last week. Out of the 4050 ERX blocks, we found 1498 cases where (partly) matching prefixes have an origin AS which can be associated an LIR. In total 775 unique ASNs were found: - 89 of the 775 AS numbers are registered with an RIR other than the RIPE NCC - 109 of the 775 AS numbers have been transferred to the RIPE region during the ERX project but are not associated to an LIR - 577 of the 775 AS numbers are associated (directly or via sponsoring) to 365 unique LIRs > - whether prefix is visible in dfz Of the 4,050 entries we found, 1,673 IP ranges are currently not in RIS (not visible in the routing tables) - they have not been seen for at least one week. This includes more specific IP ranges than the ones registered. I hope this helps. Best regards, Andrea Cima RIPE NCC > I realise that this is very ill-specified. > > This might be useful in quantifying how much effort it would be worth > expending in what you and Hank refer to as "corner cases", but which I > would feel were more common. > > Nick > > > From nick at netability.ie Fri Feb 22 19:19:29 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 22 Feb 2013 18:19:29 +0000 Subject: [ncc-services-wg] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) Message-ID: <5127B6B1.8060905@netability.ie> > Although I've let the closing date of the Discussion Phase slip by, > I hope it's not too late to say that this seems a no-brainer to me too, > that I agree with Randy's remark about the NCC's "primary job", and > that I hope the proposer will decide to advance this proposal to the > Review Phase. Yep, that is the intention. The mike is open until next Friday March 1 and hopefully at that stage there will be enough support to move forward with this proposal. Nick From nick at netability.ie Sat Feb 23 01:13:01 2013 From: nick at netability.ie (Nick Hilliard) Date: Sat, 23 Feb 2013 00:13:01 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512600E5.6030706@ripe.net> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> Message-ID: <5128098D.9050102@netability.ie> On 21/02/2013 11:11, Andrea Cima wrote: > - According to the initial ERX transfer list, 339 inetnum objects have been > deleted. This may however mean that more specific objects have been created > by the maintainer. > > - 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These > objects were registered in the RIPE DB before the ERX transfer took place, > and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the > RIPE NCC locked all objects referencing it. As these objects are still > locked, no one is currently managing this data. > > - 851 inetnum objects have the ERX auto-generated maintainer (in the form > ERX-NET-138-81-MNT) as mnt-by. The holders 'may' have been given the > password and are 'able' to manage this data, but may or may not have done > so. Others were not given the password and are not managing the data. > Without deeper analysis we can't separate these groups. Interesting. So at the moment, it looks like between 30%-40% (i.e. from (393+851)/4050 to (339+393+851)/4050) of the ERX address space is arguably abandoned from the point of view of RIPE-DB maintainership - although obviously not necessarily from other points of view. This would lend some support to my speculation that there was a substantial quantity of address space in the dead / lost category, and that it may be a good idea to take this into account in the policy formation. I tried playing around with a local copy of ripe.db.inetnum.gz earlier, but couldn't reproduce these numbers because some (many?) of the status: lines in the public DB are wrong. Do you have the raw data here? I.e. a canonical list of the ERX inetnums, and which category out of the 6 mentioned above that each falls into? Nick From randy at psg.com Sat Feb 23 02:13:12 2013 From: randy at psg.com (Randy Bush) Date: Sat, 23 Feb 2013 10:13:12 +0900 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <5128098D.9050102@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> Message-ID: >> - 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These >> objects were registered in the RIPE DB before the ERX transfer took place, >> and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the >> RIPE NCC locked all objects referencing it. As these objects are still >> locked, no one is currently managing this data. possibly because they are correct and do not need change. we have no way of knowing. >> - 851 inetnum objects have the ERX auto-generated maintainer (in the form >> ERX-NET-138-81-MNT) as mnt-by. The holders 'may' have been given the >> password and are 'able' to manage this data, but may or may not have done >> so. Others were not given the password and are not managing the data. >> Without deeper analysis we can't separate these groups. again, the owners may be quite happy with the data as they are. > Interesting. So at the moment, it looks like between 30%-40% (i.e. from > (393+851)/4050 to (339+393+851)/4050) of the ERX address space is arguably > abandoned from a measurement point of view 'arguably' may be the most important word in that sentence unfortunately we have never come up with a method to classify space rigorously. hard problem. and i am not optimistic. look at the recent noise about the uk gov /8 that looked unmaintained. randy From lists-ripe at c4inet.net Sat Feb 23 16:48:29 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Sat, 23 Feb 2013 15:48:29 +0000 Subject: [ncc-services-wg] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <5127B6B1.8060905@netability.ie> References: <5127B6B1.8060905@netability.ie> Message-ID: <20130223154828.GA61492@cilantro.c4inet.net> On Fri, Feb 22, 2013 at 06:19:29PM +0000, Nick Hilliard wrote: >Yep, that is the intention. The mike is open until next Friday March 1 and >hopefully at that stage there will be enough support to move forward with >this proposal. I'm still against it, for the same reason, viz. that it creates an appearance of responsibility of the sponsoring LIR for the independent resource that does not exist. Replies on the list have strengthened my view that this is indeed seen this way , even by people who should know that the responsibility of the LIR does not extend beyond handling paperwork for the NCC, thus my point is essentially valid. Regards, Sascha Luck From nick at netability.ie Sat Feb 23 18:43:45 2013 From: nick at netability.ie (Nick Hilliard) Date: Sat, 23 Feb 2013 17:43:45 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> Message-ID: <5128FFD1.7030601@netability.ie> On 23/02/2013 01:13, Randy Bush wrote: > again, the owners may be quite happy with the data as they are. yep. >> Interesting. So at the moment, it looks like between 30%-40% (i.e. from >> (393+851)/4050 to (339+393+851)/4050) of the ERX address space is arguably >> abandoned > > from a measurement point of view 'arguably' may be the most important > word in that sentence what I said was: "it looks like between 30%-40% of the ERX address space is arguably abandoned from the point of view of RIPE-DB maintainership - although obviously not necessarily from other points of view". I'm certainly not saying that the address space is unused. > unfortunately we have never come up with a method to classify space > rigorously. hard problem. and i am not optimistic. look at the recent > noise about the uk gov /8 that looked unmaintained. it was reasonably well known that this /8 was used internally within the UK's public sector networks. The only surprising thing about that noise was that it happened at all, but I guess we all have a special love for public display of moral outrage when it comes to bureaucracies. I agree that classification is difficult, but I'd like to play around with the data and see whether it throws up anything interesting. Nick From job.snijders at atrato.com Sat Feb 23 13:41:40 2013 From: job.snijders at atrato.com (Job Snijders) Date: Sat, 23 Feb 2013 13:41:40 +0100 Subject: [ncc-services-wg] 2012-08 New Policy Proposal (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <5127B6B1.8060905@netability.ie> References: <5127B6B1.8060905@netability.ie> Message-ID: <3BB0FD59-8921-4FEF-9114-B3FE195B134D@atrato.com> Hi, On Feb 22, 2013, at 7:19 PM, Nick Hilliard wrote: >> Although I've let the closing date of the Discussion Phase slip by, >> I hope it's not too late to say that this seems a no-brainer to me too, >> that I agree with Randy's remark about the NCC's "primary job", and >> that I hope the proposer will decide to advance this proposal to the >> Review Phase. > > Yep, that is the intention. The mike is open until next Friday March 1 and > hopefully at that stage there will be enough support to move forward with > this proposal. I like this proposal. As a user of independent resources I see clear advantages. Kind regards, Job From stolpe at resilans.se Mon Feb 25 10:56:39 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Feb 2013 10:56:39 +0100 (CET) Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> Message-ID: On Sat, 23 Feb 2013, Randy Bush wrote: >>> - 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These >>> objects were registered in the RIPE DB before the ERX transfer took place, >>> and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the >>> RIPE NCC locked all objects referencing it. As these objects are still >>> locked, no one is currently managing this data. > > possibly because they are correct and do not need change. we have no > way of knowing. Yes. And when the owners want an update they may be locked in the process och showing that they are in fact the right owners. We have a customer, a large corporate group that everybody in my country knows about and I would even say most people would agree that the original owner of a /16 is now part of this group and ask no further questions but what documentation is there now from a merger in 2000? Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From nick at netability.ie Mon Feb 25 11:16:14 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 25 Feb 2013 10:16:14 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> Message-ID: <512B39EE.1060800@netability.ie> On 25/02/2013 09:56, Daniel Stolpe wrote: > Yes. And when the owners want an update they may be locked in the process > och showing that they are in fact the right owners. We have a customer, a > large corporate group that everybody in my country knows about and I would > even say most people would agree that the original owner of a /16 is now > part of this group and ask no further questions but what documentation is > there now from a merger in 2000? Probably lots if they were large enough to get a /16. The flip side of this argument could be taken as: this holder's interest in maintaining their /16 (i.e. probably infrastructure which is very important to their business) is so small that in a period of 13 years, they couldn't be bothered spending a couple of hours updating the registry details for it. Leaving things for so long in a situation like this is likely to cause difficulties, but registrants have a duty of care to their infrastructure. I appreciate that this causes classification difficulties. Nick From gert at space.net Mon Feb 25 11:21:05 2013 From: gert at space.net (Gert Doering) Date: Mon, 25 Feb 2013 11:21:05 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B39EE.1060800@netability.ie> References: <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> Message-ID: <20130225102105.GF51699@Space.Net> Hi, On Mon, Feb 25, 2013 at 10:16:14AM +0000, Nick Hilliard wrote: > The flip side of this argument could be taken as: this holder's interest in > maintaining their /16 (i.e. probably infrastructure which is very important > to their business) is so small that in a period of 13 years, they couldn't > be bothered spending a couple of hours updating the registry details for it. If everything works, why would they need to even think about it? Like: still using the same AS to announce it, still using the same set of nameservers - so there was never a need to update anything due to "things not working on the technical side", so I can see why no updates have ever done... Our /16 PA allocation is from 1996, and all the updates on the inetnum: are hostmaster at ripe.net in 2002, 2004 and 2010 - and I'd bet all but one of these have been automated due to RIPE DB structural changes. The route: object is unchanged since 2002, since *there have not been any changes*. So I'm not sure why a PI /16 holder would have more need for updates, if nothing changed... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From nick at netability.ie Mon Feb 25 11:28:30 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 25 Feb 2013 10:28:30 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <20130225102105.GF51699@Space.Net> References: <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> <20130225102105.GF51699@Space.Net> Message-ID: <512B3CCE.40801@netability.ie> On 25/02/2013 10:21, Gert Doering wrote: > If everything works, why would they need to even think about it? e.g. to provide a credible means of rescue in the case of registry hijacking? A /16 isn't a ?9.99 kettle which you can easily replace down in the local hardware shop. > So I'm not sure why a PI /16 holder would have more need for updates, > if nothing changed... The whole point is that something has changed in the situation that Daniel referred to: the legal name of the resource holder. Nick From gert at space.net Mon Feb 25 11:34:45 2013 From: gert at space.net (Gert Doering) Date: Mon, 25 Feb 2013 11:34:45 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B3CCE.40801@netability.ie> References: <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> <20130225102105.GF51699@Space.Net> <512B3CCE.40801@netability.ie> Message-ID: <20130225103445.GG51699@Space.Net> Hi, On Mon, Feb 25, 2013 at 10:28:30AM +0000, Nick Hilliard wrote: > On 25/02/2013 10:21, Gert Doering wrote: > > If everything works, why would they need to even think about it? > > e.g. to provide a credible means of rescue in the case of registry > hijacking? A /16 isn't a ?9.99 kettle which you can easily replace down in > the local hardware shop. > > > So I'm not sure why a PI /16 holder would have more need for updates, > > if nothing changed... > > The whole point is that something has changed in the situation that Daniel > referred to: the legal name of the resource holder. Sure. But still, "if it all works, why would they even remember that the RIPE NCC exists"? The human brain works like that... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (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: From hank at efes.iucc.ac.il Mon Feb 25 11:48:16 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 25 Feb 2013 12:48:16 +0200 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> Message-ID: <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> At 10:56 25/02/2013 +0100, Daniel Stolpe wrote: >Yes. And when the owners want an update they may be locked in the process >och showing that they are in fact the right owners. We have a customer, a >large corporate group that everybody in my country knows about and I would >even say most people would agree that the original owner of a /16 is now >part of this group and ask no further questions but what documentation is >there now from a merger in 2000? Exactly because of the complexity, the NCC should require payment for registration services to handle the request. -Hank From jim at rfc1035.com Mon Feb 25 12:20:35 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 25 Feb 2013 11:20:35 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> Message-ID: On 25 Feb 2013, at 10:48, Hank Nussbacher wrote: > Exactly because of the complexity, the NCC should require payment for registration services to handle the request. I'm not so sure. In principle, yes of course everyone should pay. OTOH, the costs of generating these bills might not be worth the effort in some cases. It could also put an extra (excessive?) load on the NCC's finance and legal people -- changes to finance systems and bookkeeping, new invoice/payment tracking procedures, T&C's for these transactions, etc, etc. Setting up all of that just so a phone number in an LRH contact object could be changed (say) that might well be overkill. My preference would be for the NCC to provide the same services to LRHs that they got from the old Internic under the same terms and conditions: ie "for free". IMO, that's just part of the cost of doing business for an RIR. For any other services -- for instance getting an RPKI cert or adding a DNSSEC key for reverse DNS -- an LRH should pay. Ideally, they would do that by becoming an LIR or going through a sponsoring LIR. That way there would be no need to change the NCC's existing finance systems and processes. If this is not acceptable, then we need to be careful that whatever cost recovery mechanisms get proposed do not impose unwelcome overheads on the NCC. I wish we could get some hard data about this now instead of waiting until the proposal gets to the impact assessment stage. For instance, how many of these LRH transactions are expected each year, what sort of financial systems and processes will be needed to handle them, what will these cost. I fear we could be proposing something that grows into a cumbersome bureaucracy that needs a small army of beancounters to manage it. It would be nice if we could reach consensus on something that is workable before going to impact assessment and then finding the proposal is impractical because of the load/costs it imposes on the NCC. From jim at rfc1035.com Mon Feb 25 12:35:30 2013 From: jim at rfc1035.com (Jim Reid) Date: Mon, 25 Feb 2013 11:35:30 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B39EE.1060800@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> Message-ID: <3700DADB-0D51-4501-87FE-E3B3BA5C1740@rfc1035.com> On 25 Feb 2013, at 10:16, Nick Hilliard wrote: > Leaving things for so long in a situation like this is likely to cause > difficulties, but registrants have a duty of care to their infrastructure. True enough. Though it depends on how "duty of care" is defined. Engagement with an RIR may well not matter for an LRH. If their intranet works just fine thank you very much and isn't reachable from the Internet anyway, what would be the appropriate duty of care from such an LRH's perspective? Problems would most likely arise whenever they eventually do have to engage with their RIR, just like you said Nick. And if they don't need to engage... I would not be at all surprised if some LRHs are unaware that they have those resources* or that this could entail maintenance of entries in RIR database(s). [*They may well be using those IP addresses but have difficulty providing the paperwork which shows how they got them or who is/was responsible for that.] The internal paper trail for the space could well be flimsy or non-existent. It may rely on (lost) institutional memories. But provided everything "just works", why would such an LRH bother or need to care? From nick at netability.ie Mon Feb 25 12:43:49 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 25 Feb 2013 11:43:49 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <3700DADB-0D51-4501-87FE-E3B3BA5C1740@rfc1035.com> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> <3700DADB-0D51-4501-87FE-E3B3BA5C1740@rfc1035.com> Message-ID: <512B4E75.2080004@netability.ie> On 25/02/2013 11:35, Jim Reid wrote: > But provided everything "just works", why would such an LRH bother or need to care? My car "just works" until it burns enough oil that the engine seizes up. Just saying... Nick From stolpe at resilans.se Mon Feb 25 12:55:14 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Feb 2013 12:55:14 +0100 (CET) Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B39EE.1060800@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> Message-ID: On Mon, 25 Feb 2013, Nick Hilliard wrote: > On 25/02/2013 09:56, Daniel Stolpe wrote: >> Yes. And when the owners want an update they may be locked in the process >> och showing that they are in fact the right owners. We have a customer, a >> large corporate group that everybody in my country knows about and I would >> even say most people would agree that the original owner of a /16 is now >> part of this group and ask no further questions but what documentation is >> there now from a merger in 2000? > > Probably lots if they were large enough to get a /16. Of course their is documentation somewhere. But for a technician to get hold of exactly the right paper provning that the entity formerly known as A is now a part of the entity B might not be an easy task. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From stolpe at resilans.se Mon Feb 25 12:57:48 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Feb 2013 12:57:48 +0100 (CET) Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <20130225102105.GF51699@Space.Net> References: <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> <20130225102105.GF51699@Space.Net> Message-ID: On Mon, 25 Feb 2013, Gert Doering wrote: > Hi, > > On Mon, Feb 25, 2013 at 10:16:14AM +0000, Nick Hilliard wrote: >> The flip side of this argument could be taken as: this holder's interest in >> maintaining their /16 (i.e. probably infrastructure which is very important >> to their business) is so small that in a period of 13 years, they couldn't >> be bothered spending a couple of hours updating the registry details for it. > > If everything works, why would they need to even think about it? > > Like: still using the same AS to announce it, still using the same set > of nameservers - so there was never a need to update anything due to > "things not working on the technical side", so I can see why no updates > have ever done... You are on the right path here. The sudden need for updates was caues by a request to change name servers. And it's not 13 years. They got the /16 in 1990. :-) > Our /16 PA allocation is from 1996, and all the updates on the inetnum: > are hostmaster at ripe.net in 2002, 2004 and 2010 - and I'd bet all but one > of these have been automated due to RIPE DB structural changes. The route: > object is unchanged since 2002, since *there have not been any changes*. > > So I'm not sure why a PI /16 holder would have more need for updates, > if nothing changed... Exactly. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From gert at space.net Mon Feb 25 13:14:41 2013 From: gert at space.net (Gert Doering) Date: Mon, 25 Feb 2013 13:14:41 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B4E75.2080004@netability.ie> References: <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> <3700DADB-0D51-4501-87FE-E3B3BA5C1740@rfc1035.com> <512B4E75.2080004@netability.ie> Message-ID: <20130225121441.GJ51699@Space.Net> Hi, On Mon, Feb 25, 2013 at 11:43:49AM +0000, Nick Hilliard wrote: > On 25/02/2013 11:35, Jim Reid wrote: > > But provided everything "just works", why would such an LRH bother or need to care? > > My car "just works" until it burns enough oil that the engine seizes up. So where's the red light "hey, you need to update your resources at the RIPE NCC"? The car has that (... and reasonably recent cars don't use up that much oil anyway, so regular maintenance cycles *do* take care of that). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From kranjbar at ripe.net Mon Feb 25 13:27:29 2013 From: kranjbar at ripe.net (Kaveh Ranjbar) Date: Mon, 25 Feb 2013 13:27:29 +0100 Subject: [ncc-services-wg] Redevelopment of the RIPE Database software is complete Message-ID: <609E8F1F-18FE-4CD9-8CBA-A43EEE4A31BF@ripe.net> Dear Colleagues, We have finished the re-development of the RIPE Database software. All the RIPE Database operations are now handeled by our new system. For more information, please see the announcement sent earlier to the RIPE Database Working Group mailing list (http://www.ripe.net/ripe/mail/archives/db-wg/2013-February/004011.html). Kind Regards, Kaveh Ranjbar, RIPE NCC Database Group Manager. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pk at DENIC.DE Mon Feb 25 14:29:38 2013 From: pk at DENIC.DE (Peter Koch) Date: Mon, 25 Feb 2013 14:29:38 +0100 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: References: Message-ID: <20130225132938.GS27968@x28.adm.denic.de> > The Discussion Period for the proposal 2012-08, "Publication of > Sponsoring LIR for Independent Number Resources", has been extended > until 1 March 2013. the proposal lists three supporting arguments: > This mechanism provides a simple means for End Users to identify with which > sponsoring organisation they have a contractual link, in the case this > information is unknown to the End User. This appears overly artificial to me: why would an End User not know who they contracted with and why is a public listing of this information the appropriate cure? I do not buy this argument. > This policy simplifies the mechanism for verification and co-ordination > between sponsoring organisations when an End User wishes to transfer > resources from one sponsoring organisation to another. This is a derivative of the first argument, even though it does not state the nature of the envisioned 'verification and co-ordination'. It is the End User's job to make available, where necessary, the supporting documentation. I do not buy this argument. > Publishing this information provides an additional means for tackling > abuse issues on the Internet. So, "if all else fails", we claim it will help fighting "abuse"? What is the underlying expectation here? Is a 'sponsoring LIR' in any way responsible for traffic generated (or sunk) at the 'sponsored' address space? I cannot buy this argument. Since the proposal does not list any valid supporting argument, I am opposed. -Peter From stolpe at resilans.se Mon Feb 25 14:56:53 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Feb 2013 14:56:53 +0100 (CET) Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <20130225132938.GS27968@x28.adm.denic.de> References: <20130225132938.GS27968@x28.adm.denic.de> Message-ID: On Mon, 25 Feb 2013, Peter Koch wrote: >> The Discussion Period for the proposal 2012-08, "Publication of >> Sponsoring LIR for Independent Number Resources", has been extended >> until 1 March 2013. > > the proposal lists three supporting arguments: > >> This mechanism provides a simple means for End Users to identify with which >> sponsoring organisation they have a contractual link, in the case this >> information is unknown to the End User. > > This appears overly artificial to me: why would an End User not know who > they contracted with and why is a public listing of this information the > appropriate cure? I do not buy this argument. Well, you seem to be missing the point here. It is by no means artificial. We see it quite often. And the answer is that the sponsorships is rather an entry in some hidden RIPE db than a contract. When an end user is asked "Do you have a sponsoring LIR for this resource and if so, who is it?", the answer is usuallu "We have no idea". And the only way to be certain is to send an email to the RIPE hostmasters. >> This policy simplifies the mechanism for verification and co-ordination >> between sponsoring organisations when an End User wishes to transfer >> resources from one sponsoring organisation to another. > > This is a derivative of the first argument, even though it does not state > the nature of the envisioned 'verification and co-ordination'. It is the > End User's job to make available, where necessary, the supporting > documentation. I do not buy this argument. Let's say you do have the documents in the first situation. How do you know they are still valid? Yes, we used to be sponsor for this resource but how do we know that in RIPE:s point of view, we still are? >> Publishing this information provides an additional means for tackling >> abuse issues on the Internet. > > So, "if all else fails", we claim it will help fighting "abuse"? > What is the underlying expectation here? Is a 'sponsoring LIR' in any > way responsible for traffic generated (or sunk) at the 'sponsored' > address space? I cannot buy this argument. > > Since the proposal does not list any valid supporting argument, I am opposed. > > -Peter I am in favour. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From training at ripe.net Mon Feb 25 15:20:54 2013 From: training at ripe.net (Training Mailbox) Date: Mon, 25 Feb 2013 15:20:54 +0100 Subject: [ncc-services-wg] [training] RIPE NCC Training Courses April-June 2013 In-Reply-To: <512B70D4.8070203@ripe.net> References: <512B70D4.8070203@ripe.net> Message-ID: <512B7346.3080306@ripe.net> Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Sarajevo, Leeds, Dubai, Berlin, Amsterdam, Warsaw, Vaduz, St. Petersburg, Marseilles, Madrid, Budapest, Helsinki. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - Database Training Course (new) - IPv6 for LIRs Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From ebais at a2b-internet.com Mon Feb 25 15:24:37 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 25 Feb 2013 15:24:37 +0100 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <20130225132938.GS27968@x28.adm.denic.de> References: <20130225132938.GS27968@x28.adm.denic.de> Message-ID: <003b01ce1363$d73296f0$8597c4d0$@a2b-internet.com> Peter makes some very good points here. If the End User doesn't know who their Sponsoring LIR is, there is nothing keeping them from transferring the resource to another LIR. You would be surprised how may LIR's are sponsoring PI space without any contract or charge to their customers of 8 years ago ... and those LIR's still keep paying the bill to RIPE. Last year I cleaned up an LIR of 25+ PI resources of former customers. If the LIR themselves is unaware of the situation or simply don't care and the customer never receives any invoice for resources. Who are we to decide to publish this information. The last argument, that it would make abuse easier ... /sigh. Being a sponsoring LIR has nothing to do with abuse management. Being an LIR has nothing to do with having a network or route packets. Being / running an LIR doesn't mean you have your own network .. nor does it say that you are an ISP .. or a hoster. You are running a resource registration office. Yes we register PI space for end-users, even if they are not consuming our network services. We charge end-users for that service, we provide RIPE with all the required paperwork and handle the PI request, but if someone is routing some "bad" packets on the IP's we registered for them in the past, why would it help abuse if someone knows who registered the PI space in the first place? It is not that we can put a null-route for the IP's or 'drop the BGP announcement' as they are not in our network. Perhaps the name 'Sponsoring LIR' is a bit tricky as it might give the impression it is for free. But registration of resources (PI space, AS numbers etc) is just like any other kind of registration services, it takes time to provide the service and we charge for the time. So, perhaps a bit longer story than what Peter said, but the result it the same. Not in favor for this policy. Regards, Erik Bais A2B Internet From nick at netability.ie Mon Feb 25 15:41:00 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 25 Feb 2013 14:41:00 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B76A8.2010704@ripe.net> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B76A8.2010704@ripe.net> Message-ID: <512B77FC.2040205@netability.ie> On 25/02/2013 14:35, Andrea Cima wrote: > We have the following information publicly available. However, this does > not include data on transfers that occurred before the ERX project took > place, or IP ranges transferred by the RIPE NCC to other RIRs. > > http://www.ripe.net/lir-services/resource-management/erx/completed-transfers This is missing all of the assignments for 192/8, 198/8 and 196/8. Nick From ebais at a2b-internet.com Mon Feb 25 15:48:11 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Mon, 25 Feb 2013 15:48:11 +0100 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: References: <20130225132938.GS27968@x28.adm.denic.de> Message-ID: <003d01ce1367$22707e40$67517ac0$@a2b-internet.com> Hi Daniel, > We see it quite often. And the answer is that the sponsorships is rather an entry in some hidden RIPE db than a contract. When an end user is asked "Do you have a sponsoring LIR for this resource and if so, who is it?", the answer is usuallu " > We have no idea". And the only way to be certain is to send an email to the RIPE hostmasters. If you don't know, check the LIR Portal to see the registered PI spaces you hold there. For the customer, there is no requirement (if they really don't know.. ) and not get an invoice from some LIR, so it is very easy to just transfer the resources to another LIR and that way you are both sure ... > Let's say you do have the documents in the first situation. How do you know they are still valid? Yes, we used to be sponsor for this resource but how do we know that in RIPE:s point of view, we still are? Again, check the LIR portal for the registered PI resources under your LIR account. If there are company changes for the registered resources, inform the RIPE NCC that that is the case, send them the old info and the new info and if needed you will be requested additional paperwork of information. Typically, it is a 10 minute fix for a contact or address change. That is what it means to be a LIR, too many people see being an LIR as a way to get resources for themselves. We have customers that we provide RIPE Administration services for, they are an LIR themselves, but stay away from the actual administration or registration part. If an End-Customer wants a more formal registration service instead of a 'sponsoring LIR, could you do me a favor' kind of service, you should transfer the resources of that customer to your LIR within a blink of an eye ... Don't you think ? Publishing the information who the registration LIR is, doesn't fix the fact that information might not be correct. Go through the process of a PI transfer as an actual LIR and then decide if this is still something that is required. Regards, Erik Bais From lists-ripe at c4inet.net Mon Feb 25 15:59:29 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 25 Feb 2013 14:59:29 +0000 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: References: <20130225132938.GS27968@x28.adm.denic.de> Message-ID: <20130225145929.GA68790@cilantro.c4inet.net> Hi Daniel, On Mon, Feb 25, 2013 at 02:56:53PM +0100, Daniel Stolpe wrote: >contract. When an end user is asked "Do you have a sponsoring LIR for >this resource and if so, who is it?", the answer is usuallu "We have >no idea". And the only way to be certain is to send an email to the >RIPE hostmasters. So send them an email. >Let's say you do have the documents in the first situation. How do >you know they are still valid? Yes, we used to be sponsor for this >resource but how do we know that in RIPE:s point of view, we still >are? It'll be in your LIRportal account under "Independent resources". And a 50 Euro item on your bill (although, IIRC, that isn't broken down by resource) cheers, Sascha Luck From andrea at ripe.net Mon Feb 25 15:35:20 2013 From: andrea at ripe.net (Andrea Cima) Date: Mon, 25 Feb 2013 15:35:20 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <5128098D.9050102@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> Message-ID: <512B76A8.2010704@ripe.net> Hi Nick, On 2/23/13 1:13 AM, Nick Hilliard wrote: > On 21/02/2013 11:11, Andrea Cima wrote: >> - According to the initial ERX transfer list, 339 inetnum objects have been >> deleted. This may however mean that more specific objects have been created >> by the maintainer. >> >> - 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These >> objects were registered in the RIPE DB before the ERX transfer took place, >> and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the >> RIPE NCC locked all objects referencing it. As these objects are still >> locked, no one is currently managing this data. >> >> - 851 inetnum objects have the ERX auto-generated maintainer (in the form >> ERX-NET-138-81-MNT) as mnt-by. The holders 'may' have been given the >> password and are 'able' to manage this data, but may or may not have done >> so. Others were not given the password and are not managing the data. >> Without deeper analysis we can't separate these groups. > Interesting. So at the moment, it looks like between 30%-40% (i.e. from > (393+851)/4050 to (339+393+851)/4050) of the ERX address space is arguably > abandoned from the point of view of RIPE-DB maintainership - although > obviously not necessarily from other points of view. This would lend some > support to my speculation that there was a substantial quantity of address > space in the dead / lost category, and that it may be a good idea to take > this into account in the policy formation. > > I tried playing around with a local copy of ripe.db.inetnum.gz earlier, but > couldn't reproduce these numbers because some (many?) of the status: lines > in the public DB are wrong. These may have been changed over time. > Do you have the raw data here? I.e. a canonical list of the ERX inetnums, > and which category out of the 6 mentioned above that each falls into? We have the following information publicly available. However, this does not include data on transfers that occurred before the ERX project took place, or IP ranges transferred by the RIPE NCC to other RIRs. http://www.ripe.net/lir-services/resource-management/erx/completed-transfers Best regards, Andrea Cima RIPE NCC > Nick > From andrea at ripe.net Mon Feb 25 16:06:37 2013 From: andrea at ripe.net (Andrea Cima) Date: Mon, 25 Feb 2013 16:06:37 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B77FC.2040205@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B76A8.2010704@ripe.net> <512B77FC.2040205@netability.ie> Message-ID: <512B7DFD.8070309@ripe.net> On 2/25/13 3:41 PM, Nick Hilliard wrote: > On 25/02/2013 14:35, Andrea Cima wrote: >> We have the following information publicly available. However, this does >> not include data on transfers that occurred before the ERX project took >> place, or IP ranges transferred by the RIPE NCC to other RIRs. >> >> http://www.ripe.net/lir-services/resource-management/erx/completed-transfers > This is missing all of the assignments for 192/8, 198/8 and 196/8. You are correct. These are listed here: ftp://ftp.ripe.net/erx/ I will get the webpages updated with the 192/8, 198/8 and 196/8 information. Regards, Andrea Cima RIPE NCC > Nick > From nick at netability.ie Mon Feb 25 16:08:55 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 25 Feb 2013 15:08:55 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B7DFD.8070309@ripe.net> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B76A8.2010704@ripe.net> <512B77FC.2040205@netability.ie> <512B7DFD.8070309@ripe.net> Message-ID: <512B7E87.8070008@netability.ie> On 25/02/2013 15:06, Andrea Cima wrote: > You are correct. These are listed here: > ftp://ftp.ripe.net/erx/ > > I will get the webpages updated with the 192/8, 198/8 and 196/8 information. actually, would the converse be possible? I.e. that ftp://ftp.ripe.net/erx/ could contain the transferred blocks for the other /8s? Nick From stolpe at resilans.se Mon Feb 25 16:12:32 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 25 Feb 2013 16:12:32 +0100 (CET) Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <003d01ce1367$22707e40$67517ac0$@a2b-internet.com> References: <20130225132938.GS27968@x28.adm.denic.de> <003d01ce1367$22707e40$67517ac0$@a2b-internet.com> Message-ID: On Mon, 25 Feb 2013, Erik Bais wrote: > Hi Daniel, > >> We see it quite often. And the answer is that the sponsorships is rather > an entry in some hidden RIPE db than a contract. When an end user is asked > "Do you have a sponsoring LIR for this resource and if so, who is it?", the > answer is usuallu " >> We have no idea". And the only way to be certain is to send an email to > the RIPE hostmasters. > > If you don't know, check the LIR Portal to see the registered PI spaces you > hold there. Well, not if it's legacy space, apparently. But it is an improvement that at least RIPE space is visable there now. As far as I can recall that wat not the case not very long ago. If you could really see everything via the LIR portal, then I agree the need for publication would be much smaller. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From nick at netability.ie Mon Feb 25 16:18:44 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 25 Feb 2013 15:18:44 +0000 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <003b01ce1363$d73296f0$8597c4d0$@a2b-internet.com> References: <20130225132938.GS27968@x28.adm.denic.de> <003b01ce1363$d73296f0$8597c4d0$@a2b-internet.com> Message-ID: <512B80D4.3060604@netability.ie> Peter, Erik, The main reason for this policy proposal is to ensure transparency throughout the RIR-LIR-End User chain - one of the core principles of the RIPE community. It's a core principle because transparency creates the conditions where trust can arise, and the RIPE community requires trust to function. Conversely, lack of transparency creates an environment where people are left wondering, and this engenders mistrust. We need trust because we are asking a bureaucracy (the RIPE NCC) to manage a monopoly (number resources), and we know from overwhelming third party experience that enforcement of transparency is one of the only ways to ensure that a bureaucracy a) maintains the trust of its constituents and b) is forced and is seen to act in a way which is consistent with its own principals. We have very good transparency on what address space is assigned or allocated to whom (all of which provides information on existing contractual relationships) and the RIPE community agrees that this is a good thing. Not only do we have it, but we also agree as a community that this is valuable enough that we ask the RIPE NCC to conduct periodic audits to ensure that the data is accurate - without which the transparency would be useless. We already have the precedent to tell us that transparency is the right thing to do as a policy objective because we implicitly have this information for every other resource allocation type. This policy is an acknowledgement of this position. Nick From lists-ripe at c4inet.net Mon Feb 25 17:13:20 2013 From: lists-ripe at c4inet.net (Sascha Luck) Date: Mon, 25 Feb 2013 16:13:20 +0000 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <512B80D4.3060604@netability.ie> References: <20130225132938.GS27968@x28.adm.denic.de> <003b01ce1363$d73296f0$8597c4d0$@a2b-internet.com> <512B80D4.3060604@netability.ie> Message-ID: <20130225161320.GB68790@cilantro.c4inet.net> Hi Nick, On Mon, Feb 25, 2013 at 03:18:44PM +0000, Nick Hilliard wrote: >We need trust because we are asking a bureaucracy (the RIPE NCC) to >manage a monopoly (number resources), and we know from overwhelming >third party experience that enforcement of transparency is one of the >only ways to ensure that a bureaucracy a) maintains the trust of its >constituents and b) is forced and is seen to act in a way which is >consistent with its own principals. Other recent proposals have also implied a need for more oversight of the NCC. I don't know whether this is an indication that the community no longer trusts the NCC but, as a member, I emphatically do not want "oversight" by anyone who can operate a browser or whois client. >We have very good transparency on what address space is assigned or >allocated to whom (all of which provides information on existing >contractual relationships) and the RIPE community agrees that this is a >good thing. I, for one, do *not* agree with any right to privacy or anonymity being sacrificed on the high altar of "Transparency". I would even propose a roll-back of much of the existing open access to registration data, and be it only in the way that those seeking access must be known to the NCC as the data holder. That is, however, a discussion for a different day. rgds, Sascha Luck From nick at netability.ie Mon Feb 25 17:38:25 2013 From: nick at netability.ie (Nick Hilliard) Date: Mon, 25 Feb 2013 16:38:25 +0000 Subject: [ncc-services-wg] 2012-08 Discussion Period extended until 1 March 2013 (Publication of Sponsoring LIR for Independent Number Resources) In-Reply-To: <20130225161320.GB68790@cilantro.c4inet.net> References: <20130225132938.GS27968@x28.adm.denic.de> <003b01ce1363$d73296f0$8597c4d0$@a2b-internet.com> <512B80D4.3060604@netability.ie> <20130225161320.GB68790@cilantro.c4inet.net> Message-ID: <512B9381.7000206@netability.ie> On 25/02/2013 16:13, Sascha Luck wrote: > sacrificed on the high altar of "Transparency". I would even propose a > roll-back of much of the existing open access to registration data, and > be it only in the way that those seeking access must be known to the NCC > as the data holder. Sorry to hear this. Let's agree to disagree then. Nick From stolpe at resilans.se Tue Feb 26 17:16:41 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Tue, 26 Feb 2013 17:16:41 +0100 (CET) Subject: [ncc-services-wg] NCC staff representation at RIPE meetings Message-ID: Hi everbody, I'm not quite sure where to raise this issue but here might be somewhere to start. I noticed a couple of RIPE meetings ago that the NCC staff representaion seemed smaller than usual and when talking to those attending they said that they had hear it did not look good with all these people around. Well, my opinion is that RIPE meetings is about the only time to meet the staff in person, which is a good reason to attend. And also, if I have to pay for this number of staff, the RIPE meetings is a chance to actually see them at work. If it "does not look good", then maybe we should consider staff numbers all together. I realise there are travel expenses etc. but it would be interesting to see some figures. I doubt it comes anywhere near i.e. the Atlas project to have a couple more staff around. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From gert at space.net Tue Feb 26 17:23:47 2013 From: gert at space.net (Gert Doering) Date: Tue, 26 Feb 2013 17:23:47 +0100 Subject: [ncc-services-wg] NCC staff representation at RIPE meetings In-Reply-To: References: Message-ID: <20130226162347.GX51699@Space.Net> Hi, On Tue, Feb 26, 2013 at 05:16:41PM +0100, Daniel Stolpe wrote: > Well, my opinion is that RIPE meetings is about the only time to meet the > staff in person, which is a good reason to attend. And also, if I have to > pay for this number of staff, the RIPE meetings is a chance to actually > see them at work. If it "does not look good", then maybe we should > consider staff numbers all together. Strongly seconded. I do also consider it one of the major benefits of a RIPE meeting to meet RIPE NCC staff in person, and to actually know who I'm talking to, next time I'm in a mail exchange with hostmaster at ripe.net... Also it helps the NCC staff to get a feeling for "real life" to be able to talk to people over coffee. Gert Doering -- RIPE member since many years -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From nigel.titley at easynet.com Tue Feb 26 17:28:35 2013 From: nigel.titley at easynet.com (Nigel Titley) Date: Tue, 26 Feb 2013 16:28:35 +0000 Subject: [ncc-services-wg] NCC staff representation at RIPE meetings In-Reply-To: <20130226162347.GX51699@Space.Net> References: <20130226162347.GX51699@Space.Net> Message-ID: Where it's Amsterdam, I'm wholly in agreement. The marginal cost of additional staff is minimal. However, we've had complaints (just vague coffee-break things, nothing formal) about too many RIPE NCC staff at RIPE meetings. As Gert knows, trying to satisfy everyone isn't possible and we try to balance the "keep the staff to a minimum" and "let's have lots of staff there" points of view. If we get the feeling that people want more staff at the meetings then we can ask the NCC to send more staff. It's your organisation, after all. Nigel -----Original Message----- From: ncc-services-wg-bounces at ripe.net [mailto:ncc-services-wg-bounces at ripe.net] On Behalf Of Gert Doering Sent: 26 February 2013 16:24 To: Daniel Stolpe Cc: ncc-services-wg at ripe.net Subject: Re: [ncc-services-wg] NCC staff representation at RIPE meetings Hi, On Tue, Feb 26, 2013 at 05:16:41PM +0100, Daniel Stolpe wrote: > Well, my opinion is that RIPE meetings is about the only time to meet > the staff in person, which is a good reason to attend. And also, if I > have to pay for this number of staff, the RIPE meetings is a chance to > actually see them at work. If it "does not look good", then maybe we > should consider staff numbers all together. Strongly seconded. I do also consider it one of the major benefits of a RIPE meeting to meet RIPE NCC staff in person, and to actually know who I'm talking to, next time I'm in a mail exchange with hostmaster at ripe.net... Also it helps the NCC staff to get a feeling for "real life" to be able to talk to people over coffee. Gert Doering -- RIPE member since many years -- 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 (89) 32356-444 USt-IdNr.: DE813185279 From andrea at ripe.net Wed Feb 27 13:32:04 2013 From: andrea at ripe.net (Andrea Cima) Date: Wed, 27 Feb 2013 13:32:04 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512B7E87.8070008@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B76A8.2010704@ripe.net> <512B77FC.2040205@netability.ie> <512B7DFD.8070309@ripe.net> <512B7E87.8070008@netability.ie> Message-ID: <512DFCC4.6050500@ripe.net> Hi Nick, On 2/25/13 4:08 PM, Nick Hilliard wrote: > On 25/02/2013 15:06, Andrea Cima wrote: >> You are correct. These are listed here: >> ftp://ftp.ripe.net/erx/ >> >> I will get the webpages updated with the 192/8, 198/8 and 196/8 information. > actually, would the converse be possible? I.e. that > ftp://ftp.ripe.net/erx/ could contain the transferred blocks for the other /8s? That is possible. We will be able to implement this change next week. Best regards, Andrea Cima RIPE NCC > Nick > > From Woeber at CC.UniVie.ac.at Wed Feb 27 14:57:13 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 27 Feb 2013 14:57:13 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <512B39EE.1060800@netability.ie> Message-ID: <512E10B9.2060607@CC.UniVie.ac.at> Daniel Stolpe wrote: > > On Mon, 25 Feb 2013, Nick Hilliard wrote: > >> On 25/02/2013 09:56, Daniel Stolpe wrote: >> >>> Yes. And when the owners want an update they may be locked in the >>> process >>> och showing that they are in fact the right owners. We have a >>> customer, a >>> large corporate group that everybody in my country knows about and I >>> would >>> even say most people would agree that the original owner of a /16 is now >>> part of this group and ask no further questions but what >>> documentation is >>> there now from a merger in 2000? >> >> >> Probably lots if they were large enough to get a /16. > > > Of course their is documentation somewhere. Not necessarily. In the "old days" quite a bit of networking and address distribution was done over the phone, on fax or by using non-IP-based eMail. One such example /16: status: ASSIGNED PI changed: porten at mvs.gmd.de 19900816 That's the date when it was possible(!) to register in the RIPE DB. The address block itself was obtained in the context of an IBM-related research project. Does anyone expect the current holder and user to still have a "paper trail"? Wilfried > But for a technician to get > hold of exactly the right paper provning that the entity formerly known > as A is now a part of the entity B might not be an easy task. > > Regards, > > Daniel Stolpe > > _________________________________________________________________________________ > > Daniel Stolpe Tel: 08 - 688 11 81 > stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 > http://www.resilans.se/ > Box 13 054 556741-1193 > 103 02 Stockholm From Woeber at CC.UniVie.ac.at Wed Feb 27 15:04:31 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 27 Feb 2013 15:04:31 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> Message-ID: <512E126F.3020804@CC.UniVie.ac.at> Hank Nussbacher wrote: > At 10:56 25/02/2013 +0100, Daniel Stolpe wrote: > > > >> Yes. And when the owners want an update they may be locked in the >> process och showing that they are in fact the right owners. We have a >> customer, a large corporate group that everybody in my country knows >> about and I would even say most people would agree that the original >> owner of a /16 is now part of this group and ask no further questions >> but what documentation is there now from a merger in 2000? > > > Exactly because of the complexity, the NCC should require payment for > registration services to handle the request. Reality check, please. I cannot relate to complex business mergers and such, but in our environment, the perceived "complexity" is home-grown from the wrong end. Because we try to attack it from a central point of view, instead of making use of the existing "hierarchy" and operational knowledge. > -Hank For a sizeable chunk of such addresses the management of "proof" of holdership is easy: the holders have been in existence (and using IP numbers) since decades, have been conneted to a common infrastructure (a network and an LIR) and still do exist. So, unless someone in Amsterdam wants to see "paper", the whole thing is easy and cheap: the sponsoring LIR confirms the existence of the org and the connectivity to e.g. the NREN. Full stop. Pretty simple + cheap :-) Wilfried. From nick at netability.ie Wed Feb 27 15:12:04 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 27 Feb 2013 14:12:04 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512E126F.3020804@CC.UniVie.ac.at> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> <512E126F.3020804@CC.UniVie.ac.at> Message-ID: <512E1434.9060804@netability.ie> On 27/02/2013 14:04, Wilfried Woeber wrote: > do exist. So, unless someone in Amsterdam wants to see "paper", the whole thing > is easy and cheap: the sponsoring LIR confirms the existence of the org and the > connectivity to e.g. the NREN. Full stop. Pretty simple + cheap :-) so will this be enough to satisfy legal due diligence? I'm asking, btw - I don't know what the answer is. Nick From nick at netability.ie Wed Feb 27 15:12:57 2013 From: nick at netability.ie (Nick Hilliard) Date: Wed, 27 Feb 2013 14:12:57 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512E1434.9060804@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> <512E126F.3020804@CC.UniVie.ac.at> <512E1434.9060804@netability.ie> Message-ID: <512E1469.10105@netability.ie> On 27/02/2013 14:12, Nick Hilliard wrote: > so will this be enough to satisfy legal due diligence ... for e.g. certification. Nick From Woeber at CC.UniVie.ac.at Wed Feb 27 15:27:36 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 27 Feb 2013 15:27:36 +0100 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512E1469.10105@netability.ie> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> <512E126F.3020804@CC.UniVie.ac.at> <512E1434.9060804@netability.ie> <512E1469.10105@netability.ie> Message-ID: <512E17D8.1030407@CC.UniVie.ac.at> Nick Hilliard wrote: > On 27/02/2013 14:12, Nick Hilliard wrote: > >>so will this be enough to satisfy legal due diligence > > > ... for e.g. certification. If we take a step back and try to model the tree/mesh of responsibility on the operational reality, and install a structure with CA and RA(s), then, imho, YES. > Nick But the question regarding "legal due diligence" may be asked the other way 'round, too: we've got a holder and user of a resource, and someone (an RIR) questions the rightfulness (is this an engl. word?), then wouldn't it be "fair" for that party to come up with the "documentation", from a legal pov? I know that this is sort of "funny", from an abuse/security perspective. But, what I want to achieve and argue for, is to decouple the registration service from the operational (ab)use aspects. The Registry does have a clear mandate for the former, but not really for the latter. Wilfried. From stolpe at resilans.se Wed Feb 27 15:36:01 2013 From: stolpe at resilans.se (Daniel Stolpe) Date: Wed, 27 Feb 2013 15:36:01 +0100 (CET) Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512E17D8.1030407@CC.UniVie.ac.at> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> <512E126F.3020804@CC.UniVie.ac.at> <512E1434.9060804@netability.ie> <512E1469.10105@netability.ie> <512E17D8.1030407@CC.UniVie.ac.at> Message-ID: On Wed, 27 Feb 2013, Wilfried Woeber wrote: > Nick Hilliard wrote: >> On 27/02/2013 14:12, Nick Hilliard wrote: >> >>> so will this be enough to satisfy legal due diligence >> >> >> ... for e.g. certification. > > If we take a step back and try to model the tree/mesh of responsibility on > the operational reality, and install a structure with CA and RA(s), then, > imho, YES. > >> Nick > > But the question regarding "legal due diligence" may be asked the other way > 'round, too: we've got a holder and user of a resource, and someone (an RIR) > questions the rightfulness (is this an engl. word?), then wouldn't it be > "fair" for that party to come up with the "documentation", from a legal pov? > > I know that this is sort of "funny", from an abuse/security perspective. But, > what I want to achieve and argue for, is to decouple the registration service > from the operational (ab)use aspects. > > The Registry does have a clear mandate for the former, but not really for the > latter. > > Wilfried. Well put Wilfried. I agree. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm From nick at foobar.org Wed Feb 27 15:29:08 2013 From: nick at foobar.org (Nick Hilliard) Date: Wed, 27 Feb 2013 14:29:08 +0000 Subject: [ncc-services-wg] legacy holders paying for registration services and 2012-07v2 In-Reply-To: <512E17D8.1030407@CC.UniVie.ac.at> References: <5101381D.90600@ripe.net> <7589326DC369BE4EAACEB3A2EB92F8E311B7FEAF@HATMSG025.TMOUSERSUK.AD.T-MOBILE.CO.UK> <510F9D9C.7040100@netability.ie> <510FA7BB.2020803@netability.ie> <20130204221212.GB21183@besserwisser.org> <5112690E.6000701@netability.ie> <512600E5.6030706@ripe.net> <5128098D.9050102@netability.ie> <5.1.1.6.2.20130225124658.003b55e0@efes.iucc.ac.il> <512E126F.3020804@CC.UniVie.ac.at> <512E1434.9060804@netability.ie> <512E1469.10105@netability.ie> <512E17D8.1030407@CC.UniVie.ac.at> Message-ID: <512E1834.3090704@foobar.org> On 27/02/2013 14:27, Wilfried Woeber wrote: > But the question regarding "legal due diligence" may be asked the other way > 'round, too: we've got a holder and user of a resource, and someone (an RIR) > questions the rightfulness (is this an engl. word?), then wouldn't it be > "fair" for that party to come up with the "documentation", from a legal pov? I don't know the answer to these questions. Probably the RIPE NCC will need to get a legal opinion on this, which might happen in the review stage of the PDP. Nick From bengan at bag.org Wed Feb 27 16:47:11 2013 From: bengan at bag.org (=?ISO-8859-1?Q?Bengt_G=F6rd=E9n?=) Date: Wed, 27 Feb 2013 16:47:11 +0100 Subject: [ncc-services-wg] NCC staff representation at RIPE meetings In-Reply-To: References: <20130226162347.GX51699@Space.Net> Message-ID: <512E2A7F.3090309@bag.org> 2013-02-26 17:28, Nigel Titley skrev: > Where it's Amsterdam, I'm wholly in agreement. The marginal cost of additional staff is minimal. > > However, we've had complaints (just vague coffee-break things, nothing formal) about too many RIPE NCC staff at RIPE meetings. As Gert knows, trying to satisfy everyone isn't possible and we try to balance the "keep the staff to a minimum" and "let's have lots of staff there" points of view. If we get the feeling that people want more staff at the meetings then we can ask the NCC to send more staff. It's your organisation, after all. And to add to the general feeling that there are too few staff at the meetings. I have seen over the last RIPE meetings NCC staff who are so busy that they do not have time for a pint of Guinness in the evening. And that ladies and gentlemen is NOT good. There's always time for a pint of Guinness. /bengan From sm at resistor.net Wed Feb 27 20:09:24 2013 From: sm at resistor.net (SM) Date: Wed, 27 Feb 2013 11:09:24 -0800 Subject: [ncc-services-wg] EU Council regulations Message-ID: <6.2.5.6.2.20130227110246.0b324ab0@elandnews.com> Hello, Is there a list of EU Council regulations that are applicable for RIPE NCC services? Regards, -sm From athina.fragkouli at ripe.net Thu Feb 28 15:03:18 2013 From: athina.fragkouli at ripe.net (Athina Fragkouli) Date: Thu, 28 Feb 2013 15:03:18 +0100 Subject: [ncc-services-wg] EU Council regulations In-Reply-To: <512F0B1A.3010704@ripe.net> References: <512F0B1A.3010704@ripe.net> Message-ID: <512F63A6.1060405@ripe.net> Dear SM, While there is no list of Regulations that apply specifically to RIPE NCC services, the EU does provide summaries of EU legislation in a number of subject areas: http://europa.eu/legislation_summaries/index_en.htm I hope this helps. Please let me know if you need more information. Regards, Athina Fragkouli RIPE NCC -------- Original Message -------- Subject: [ncc-services-wg] EU Council regulations Date: Wed, 27 Feb 2013 11:09:24 -0800 From: SM To: ncc-services-wg at ripe.net Hello, Is there a list of EU Council regulations that are applicable for RIPE NCC services? Regards, -sm From sm at resistor.net Thu Feb 28 18:28:37 2013 From: sm at resistor.net (SM) Date: Thu, 28 Feb 2013 09:28:37 -0800 Subject: [ncc-services-wg] EU Council regulations In-Reply-To: <512F63A6.1060405@ripe.net> References: <512F0B1A.3010704@ripe.net> <512F63A6.1060405@ripe.net> Message-ID: <6.2.5.6.2.20130228083200.0b8df5d8@resistor.net> Hi Athina, At 06:03 28-02-2013, Athina Fragkouli wrote: >While there is no list of Regulations that apply specifically to RIPE >NCC services, the EU does provide summaries of EU legislation in a >number of subject areas: >http://europa.eu/legislation_summaries/index_en.htm I read that RIPE NCC is taking appropriate measures to cease business relations with three RIPE NCC members which appeared on an EU list. Thank you for the information. Regards, -sm