From sander at steffann.nl Mon Feb 3 13:11:39 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 3 Feb 2014 13:11:39 +0100 Subject: [address-policy-wg] Consensus has been confirmed on 2013-03 - Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text Message-ID: <5363D402-367D-4BC2-94AF-5144CF38A65B@steffann.nl> Hello working group, The collective of all working group chairs has, according to the RIPE PDP (RIPE-500) section 2.4, confirmed that there is consensus on policy proposal 2013-03 - Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text. The Address Policy Working Group Chairs (that's Gert and myself) have asked the RIPE NCC to implement this policy change and publish the new policy documents. The RIPE Policy Development Officer (PDO, a.k.a. Marco Schmidt) will send a separate announcement when this has been done. Thank you for your patience, Your WG chairs, Sander Steffann Gert D?ring From h.lu at anytimechinese.com Tue Feb 4 12:05:02 2014 From: h.lu at anytimechinese.com (Lu Heng) Date: Tue, 4 Feb 2014 12:05:02 +0100 Subject: [address-policy-wg] address-policy-wg Digest, Vol 30, Issue 1 In-Reply-To: References: Message-ID: welcome everybody to an new era of IP management--easy,faster,and more effective:) last,hopefully leads an more accurate Ripe datebase as well. On Tue, Feb 4, 2014 at 12:00 PM, wrote: > Send address-policy-wg mailing list submissions to > address-policy-wg at ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request at ripe.net > > You can reach the person managing the list at > address-policy-wg-owner at ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Consensus has been confirmed on 2013-03 - Post Depletion > Adjustment of Procedures to Match Policy Objectives, and Clean-up > of Obsolete Policy Text (Sander Steffann) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 3 Feb 2014 13:11:39 +0100 > From: Sander Steffann > Subject: [address-policy-wg] Consensus has been confirmed on 2013-03 - > Post Depletion Adjustment of Procedures to Match Policy Objectives, > and Clean-up of Obsolete Policy Text > To: Address Policy Working Group > Message-ID: <5363D402-367D-4BC2-94AF-5144CF38A65B at steffann.nl> > Content-Type: text/plain; charset=iso-8859-1 > > Hello working group, > > The collective of all working group chairs has, according to the RIPE PDP (RIPE-500) section 2.4, confirmed that there is consensus on policy proposal 2013-03 - Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text. The Address Policy Working Group Chairs (that's Gert and myself) have asked the RIPE NCC to implement this policy change and publish the new policy documents. The RIPE Policy Development Officer (PDO, a.k.a. Marco Schmidt) will send a separate announcement when this has been done. > > Thank you for your patience, > Your WG chairs, > Sander Steffann > Gert D?ring > > > > > End of address-policy-wg Digest, Vol 30, Issue 1 > ************************************************ -- -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. From andreas.larsen at ip-only.se Tue Feb 4 14:44:45 2014 From: andreas.larsen at ip-only.se (Andreas Larsen) Date: Tue, 4 Feb 2014 14:44:45 +0100 Subject: [address-policy-wg] 2013-03: Review Phase - New Proposal Description and Impact Analysis Published In-Reply-To: <245575C6-8A06-4043-B2F9-D4221780898D@steffann.nl> References: <1384942149.9327@mobil.space.net> <20131205183121.GA54642@Space.Net> <52E7DD00.1020600@velea.eu> <245575C6-8A06-4043-B2F9-D4221780898D@steffann.nl> Message-ID: <1EFE66AA-70D5-4CD0-A35E-B2B3A8704D5B@ip-only.se> I?m to is curious about this =) Decision made ? // Andreas Med v?nlig h?lsning Andreas Larsen IP-Only Telecommunication AB| Postadress: 753 81 UPPSALA | Bes?ksadress: S:t Persgatan 6, Uppsala | Telefon: +46 (0)18 843 10 00 | Direkt: +46 (0)18 843 10 56 www.ip-only.se 28 jan 2014 kl. 12:40 skrev Sander Steffann : > Hi Elvis, > >> I see that the Last Call has ended on the 6th of January 2014. >> >> Have the WG Chairs reached a decision with 2013-03 ? > > Almost, a little more patience :) > Sander > > From sander at steffann.nl Tue Feb 4 14:48:42 2014 From: sander at steffann.nl (Sander Steffann) Date: Tue, 4 Feb 2014 14:48:42 +0100 Subject: [address-policy-wg] 2013-03: Review Phase - New Proposal Description and Impact Analysis Published In-Reply-To: <1EFE66AA-70D5-4CD0-A35E-B2B3A8704D5B@ip-only.se> References: <1384942149.9327@mobil.space.net> <20131205183121.GA54642@Space.Net> <52E7DD00.1020600@velea.eu> <245575C6-8A06-4043-B2F9-D4221780898D@steffann.nl> <1EFE66AA-70D5-4CD0-A35E-B2B3A8704D5B@ip-only.se> Message-ID: Hi, > I?m to is curious about this =) Decision made ? Yes, I sent the announcement to the list yesterday. 2013-03 will be implemented. Cheers, Sander From mschmidt at ripe.net Tue Feb 4 16:36:29 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 04 Feb 2014 16:36:29 +0100 Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text) Message-ID: Dear colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-599, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-03 The new RIPE Document is called ripe-604 and is available at: https://www.ripe.net/ripe/docs/ripe-604 The RIPE NCC has already begun preparations to implement this policy proposal, which will require updating many internal and external procedures and related tools to ensure we continue to provide efficient service. We estimate it may take up to three months to make these changes and fully implement the policy proposal. In the meantime, the current procedures will remain in effect. The RIPE NCC will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided input. Regards Marco Schmidt Policy Development Officer RIPE NCC From koalafil at gmail.com Wed Feb 5 19:57:32 2014 From: koalafil at gmail.com (Filiz Yilmaz) Date: Wed, 5 Feb 2014 19:57:32 +0100 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA Message-ID: Dear Colleagues, NRO NC is asked by the IANA Staff for a clarification on the reading of this policy, Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA, in regards to "when" the first allocations from the Recovered IPv4 pool can be made. The Council decided to check further with the communities, hence this mail. The policy document (http://www.ripe.net/ripe/docs/ripe-529) states the following: ---- 1.0 Recovered IPv4 Pool ?. When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as stated in Section 2.0 below. 2.0 Allocation of returned IPv4 address space by the IANA 1. Allocations from the IANA may begin once the pool is declared active. 2. In each "IPv4 allocation period", each RIR will receive a single ?IPv4 allocation unit? from the IANA. 3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year ... ---- While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 and 3 together talk about "allocation periods" and that they are the ?6-month period following 1 March or 1 September in each year.? In practice, if the pool is declared active on 1 January and IANA makes the first allocations immediately this would be outside of the allocation period, which begins at the start of March. So mainly the question is about the first allocations from the the Recovered IPv4 pool; a) Should they be made straight away or b) Should IANA wait and make them at the start of the next "IPv4 allocation period," the "6-month period following 1 March or 1 September. In my personal opinion I see no problems with starting straight away (option a above), and then continue the rest in the regularity of the allocation periods as stated in the policy. Would you agree or is your reading towards option b above? Please let us know of your opinions on this list until 23 February 2014. Kind regards Filiz Yilmaz as NRO NC Member from RIPE Region From elvis at velea.eu Wed Feb 5 21:11:09 2014 From: elvis at velea.eu (Elvis Velea) Date: Wed, 05 Feb 2014 21:11:09 +0100 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: Message-ID: <52F29ADD.9030204@velea.eu> Hi Filiz, everyone, Looking at your question from the perspective of a RIPE NCC member, I do not think it matters that much (or even at all). I've seen the discussion happening in the ARIN region as well, a few months ago but I do not remember what their decision was. Anyway, regarding both options, here are my comments: option a) - the IANA allocates the Recovered pool straight away Once one of the RIRs reaches less than a /9, the Recovered pool will be divided by 5 and the RIRs will each receive one fifth.. I see no impact on any operations of the RIPE NCC and I would vote for this option. option b) - the IANA waits a few months The RIR that has reached less than a /9 will probably not distribute the whole /9 in the days left before the first 'IPv4 allocation period' starts (1st of March or 1st of September) so even if the IPv4 allocation period starts on the fixed date, the operations of the RIPE NCC will not be impacted (*) * looking at the current policies in ARIN, I am unsure if ARIN could distribute their last /9 within _less than 6 months_ in that case, their operations may be impacted. Therefore, to conclude, I agree with your point, that it would make sense to start right away and not wait for the allocation period to start. cheers, elvis On 05/02/14 19:57, Filiz Yilmaz wrote: > Dear Colleagues, > > NRO NC is asked by the IANA Staff for a clarification on the reading of this policy, Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA, in regards to "when" the first allocations from the Recovered IPv4 pool can be made. > > The Council decided to check further with the communities, hence this mail. > > The policy document (http://www.ripe.net/ripe/docs/ripe-529) states the following: > > ---- > > 1.0 Recovered IPv4 Pool > > ?. > > When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as stated in Section 2.0 below. > > 2.0 Allocation of returned IPv4 address space by the IANA > > 1. Allocations from the IANA may begin once the pool is declared active. > 2. In each "IPv4 allocation period", each RIR will receive a single ?IPv4 allocation unit? from the IANA. > 3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year > > ... > ---- > > While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 and 3 together talk about "allocation periods" and that they are the ?6-month period following 1 March or 1 September in each year.? > > In practice, if the pool is declared active on 1 January and IANA makes the first allocations immediately this would be outside of the allocation period, which begins at the start of March. > > So mainly the question is about the first allocations from the the Recovered IPv4 pool; > > a) Should they be made straight away > or > b) Should IANA wait and make them at the start of the next "IPv4 allocation period," the "6-month period following 1 March or 1 September. > > > In my personal opinion I see no problems with starting straight away (option a above), and then continue the rest in the regularity of the allocation periods as stated in the policy. > > Would you agree or is your reading towards option b above? > > Please let us know of your opinions on this list until 23 February 2014. > > > Kind regards > Filiz Yilmaz > as NRO NC Member from RIPE Region > > > From leo.vegoda at icann.org Wed Feb 5 21:28:16 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 5 Feb 2014 12:28:16 -0800 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <52F29ADD.9030204@velea.eu> References: <52F29ADD.9030204@velea.eu> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19684A12372@EXVPMBX100-1.exc.icann.org> Elvis Velea wrote: [...] > option a) - the IANA allocates the Recovered pool straight away > Once one of the RIRs reaches less than a /9, the Recovered pool will be > divided by 5 and the RIRs will each receive one fifth. I should probably add that the policy requires the allocations to be "rounded down to the next CIDR (power-of-2) boundary." Consequently, it is likely that the pool would take a number of allocation periods to be fully emptied, depending on whether additional space was returned to it. Kind regards, Leo Vegoda ICANN IANA -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From scottleibrand at gmail.com Wed Feb 5 21:37:00 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 5 Feb 2014 12:37:00 -0800 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: Message-ID: I believe option A was the intent behind the global policy. There is no downside to choosing option A, but there could conceivably be a downside to option B (an RIR runs out of space, stops allocations, and then resumes when they get more from IANA). Therefore, I believe that the IANA should proceed based on option A. -Scott P.S. Yes, I am affiliated with ARIN, but also represent a RIPE member. My opinions in this case, though, are based on my evaluation of what is best for the Internet community as a whole, which seems to be the same for everyone involved. On Wed, Feb 5, 2014 at 10:57 AM, Filiz Yilmaz wrote: > Dear Colleagues, > > NRO NC is asked by the IANA Staff for a clarification on the reading of > this policy, Global Policy for post exhaustion IPv4 allocation mechanisms > by the IANA, in regards to "when" the first allocations from the Recovered > IPv4 pool can be made. > > The Council decided to check further with the communities, hence this mail. > > The policy document (http://www.ripe.net/ripe/docs/ripe-529) states the > following: > > ---- > > 1.0 Recovered IPv4 Pool > > .... > > When one of the RIRs declares it has less than a total of a /9 in its > inventory, the Recovered IPv4 pool will be declared active, and IP > addresses from the Recovered IPv4 Pool will be allocated as stated in > Section 2.0 below. > > 2.0 Allocation of returned IPv4 address space by the IANA > > 1. Allocations from the IANA may begin once the pool is declared active. > 2. In each "IPv4 allocation period", each RIR will receive a single "IPv4 > allocation unit" from the IANA. > 3. An "IPv4 allocation period" is defined as a 6-month period following 1 > March or 1 September in each year > > ... > ---- > > While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 > and 3 together talk about "allocation periods" and that they are the > "6-month period following 1 March or 1 September in each year." > > In practice, if the pool is declared active on 1 January and IANA makes > the first allocations immediately this would be outside of the allocation > period, which begins at the start of March. > > So mainly the question is about the first allocations from the the > Recovered IPv4 pool; > > a) Should they be made straight away > or > b) Should IANA wait and make them at the start of the next "IPv4 > allocation period," the "6-month period following 1 March or 1 September. > > > In my personal opinion I see no problems with starting straight away > (option a above), and then continue the rest in the regularity of the > allocation periods as stated in the policy. > > Would you agree or is your reading towards option b above? > > Please let us know of your opinions on this list until 23 February 2014. > > > Kind regards > Filiz Yilmaz > as NRO NC Member from RIPE Region > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From niall.oreilly at ucd.ie Wed Feb 5 21:51:17 2014 From: niall.oreilly at ucd.ie (Niall O'Reilly) Date: Wed, 05 Feb 2014 20:51:17 +0000 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: Message-ID: At Wed, 5 Feb 2014 19:57:32 +0100, Filiz Yilmaz wrote: > > Dear Colleagues, Please see comments in context below. > NRO NC is asked by the IANA Staff for a clarification on the reading of this policy, Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA, in regards to "when" the first allocations from the Recovered IPv4 pool can be made. > > The Council decided to check further with the communities, hence this mail. > > The policy document (http://www.ripe.net/ripe/docs/ripe-529) states the following: > > ---- > > 1.0 Recovered IPv4 Pool > > ?. > > When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as stated in Section 2.0 below. > > 2.0 Allocation of returned IPv4 address space by the IANA > > 1. Allocations from the IANA may begin once the pool is declared active. > 2. In each "IPv4 allocation period", each RIR will receive a single ?IPv4 allocation unit? from the IANA. > 3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year > > ... > ---- > > While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 and 3 together talk about "allocation periods" and that they are the ?6-month period following 1 March or 1 September in each year.? > > In practice, if the pool is declared active on 1 January and IANA makes the first allocations immediately this would be outside of the allocation period, which begins at the start of March. > > So mainly the question is about the first allocations from the the Recovered IPv4 pool; > > a) Should they be made straight away > or > b) Should IANA wait and make them at the start of the next "IPv4 allocation period," the "6-month period following 1 March or 1 September. > > > In my personal opinion I see no problems with starting straight away (option a above), and then continue the rest in the regularity of the allocation periods as stated in the policy. > > Would you agree or is your reading towards option b above? I agree with you, Filiz. Here is how I read the policy. Clause 3 makes no reference to whether the pool has already been declared active; it establishes the beginning of the current and subsequent allocation periods. Whether or not the pool has been activated, we are now (5 Feb 2014) living in an activation period which began on 1 Sep 2013 and looking forward to another which will begin on 1 Mar 2014. In clause 1, the word "once" means "as soon as". Here too, "may" simply indicates that the action is authorized in the circumstances mentioned; no complementary "or may not" option is to be inferred. Clause 4 provides that the allocation unit to be used in the allocation period during which the pool is declared active need not be calculated according to the conditions prevailing at the beginning of this allocation period, but rather according to the conditions current at the moment of activation. I hope this helps. Best regards, Niall O'Reilly From tore at fud.no Wed Feb 5 22:51:59 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 05 Feb 2014 22:51:59 +0100 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: Message-ID: <52F2B27F.9090701@fud.no> Hi Filiz, > a) Should they be made straight away > or > b) Should IANA wait and make them at the start of the next "IPv4 > allocation period," the "6-month period following 1 March or 1 > September. It makes no practical difference to the RIPE community. This is because even if we were the first region to be the first to hit the low point of a /9 of remaining inventory, which in itself is extremely improbable, there is absolutely no chance of us fully depleting that /9 in during that initial (partial) "IPv4 allocation period", even if that period ended up being 6 months - 1 day. The only real difference is whether or not our 1/5 share of the Recovered IPv4 Pool will formally reside in "IANA storage" or "RIPE NCC storage" in that period. AfriNIC and APNIC are in the same situation. In all likelihood, either ARIN or LACNIC will be the region to first hit the /9 low point, as they plan on allocating normally up until (and beyond) that /9 point. For that reason I suspect those regions prefer option A, as that might prevent them from hitting their own trigger point for implementing their respective austerity policies within the timeframe of that initial (partial) "IPv4 allocation period". If either of those regions do indeed prefer option A, then I think the collegial thing to do would be to let them have it their way. If however ARIN and LACNIC have no preference, I'd say ?whichever option makes Leo's job easier?. Tore From Robert.Guentensperger at swisscom.com Wed Feb 5 11:25:31 2014 From: Robert.Guentensperger at swisscom.com (Robert.Guentensperger at swisscom.com) Date: Wed, 5 Feb 2014 10:25:31 +0000 Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text) In-Reply-To: <5E.59.04109.39901F25@zhhdzmsp-mxin18> References: <5E.59.04109.39901F25@zhhdzmsp-mxin18> Message-ID: <14396665.321257.1391595937846.JavaMail.trustmail@ss000808> Dear all, I'm unsure now. Is ripe-583 (Provider Aggregatable (PA) Assignment Request Form) still valid? Regarding the new policy-text and the discussion before it's now unclear. At least for me. ;-) Thank you in advance for a clarification. Best regards, Robert Robert G?ntensperger Swisscom (Switzerland) Ltd. > -----Original Message----- > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- > bounces at ripe.net] On Behalf Of Marco Schmidt > Sent: Tuesday, February 04, 2014 4:36 PM > To: policy-announce at ripe.net > Cc: address-policy-wg at ripe.net > Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion > Adjustment of Procedures to Match Policy Objectives, and Clean-up of > Obsolete Policy Text) > > > Dear colleagues, > > > Consensus has been reached, and the proposal for a change to RIPE > Document ripe-599, "IPv4 Address Allocation and Assignment Policies for > the RIPE NCC Service Region", has been accepted by the RIPE community. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-03 > > The new RIPE Document is called ripe-604 and is available at: > > https://www.ripe.net/ripe/docs/ripe-604 > > > The RIPE NCC has already begun preparations to implement this policy > proposal, which will require updating many internal and external > procedures and related tools to ensure we continue to provide efficient > service. > We estimate it may take up to three months to make these changes and > fully implement the policy proposal. In the meantime, the current > procedures will remain in effect. The RIPE NCC will send another > announcement once the implementation is complete and the new procedures > are in place. > > > Thank you to everyone who provided input. > > Regards > > Marco Schmidt > Policy Development Officer > RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5262 bytes Desc: S/MIME Cryptographic Signature URL: From nick at inex.ie Thu Feb 6 10:25:55 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 06 Feb 2014 09:25:55 +0000 Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text) In-Reply-To: <14396665.321257.1391595937846.JavaMail.trustmail@ss000808> References: <5E.59.04109.39901F25@zhhdzmsp-mxin18> <14396665.321257.1391595937846.JavaMail.trustmail@ss000808> Message-ID: <52F35523.8010907@inex.ie> On 05/02/2014 10:25, Robert.Guentensperger at swisscom.com wrote: > I'm unsure now. > Is ripe-583 (Provider Aggregatable (PA) Assignment Request Form) still valid? > Regarding the new policy-text and the discussion before it's now unclear. > At least for me. ;-) I think it probably is still required. The policy announcement said: >> We estimate it may take up to three months to make these changes and >> fully implement the policy proposal. In the meantime, the current >> procedures will remain in effect. Nick From tore at fud.no Thu Feb 6 10:48:47 2014 From: tore at fud.no (Tore Anderson) Date: Thu, 06 Feb 2014 10:48:47 +0100 Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text) In-Reply-To: <52F35523.8010907@inex.ie> References: <5E.59.04109.39901F25@zhhdzmsp-mxin18> <14396665.321257.1391595937846.JavaMail.trustmail@ss000808> <52F35523.8010907@inex.ie> Message-ID: <52F35A7F.7080608@fud.no> * Nick Hilliard > I think it probably is still required. The policy announcement said: > >>> We estimate it may take up to three months to make these changes and >>> fully implement the policy proposal. In the meantime, the current >>> procedures will remain in effect. Question is, may the LIRs update their procedures right away? Or are LIRs expected to wait until the NCC has updated procedures, at which point the LIRs are permitted to follow suit? My expectation would be the former. Otherwise, publishing ripe-604 as the current policy at this point in time would just be confusing LIRs and others who might not follow policy development closely. How are they to know that they should ignore ripe-604 for now, and instead operate according to ?obsoleted? ripe-599? Tore From nick at inex.ie Thu Feb 6 11:03:39 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 06 Feb 2014 10:03:39 +0000 Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text) In-Reply-To: <52F35A7F.7080608@fud.no> References: <5E.59.04109.39901F25@zhhdzmsp-mxin18> <14396665.321257.1391595937846.JavaMail.trustmail@ss000808> <52F35523.8010907@inex.ie> <52F35A7F.7080608@fud.no> Message-ID: <52F35DFB.2020203@inex.ie> On 06/02/2014 09:48, Tore Anderson wrote: > Question is, may the LIRs update their procedures right away? that would be very good indeed. Nick From mschmidt at ripe.net Thu Feb 6 13:54:04 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 06 Feb 2014 13:54:04 +0100 Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text) In-Reply-To: <14396665.321257.1391595937846.JavaMail.trustmail@ss000808> References: <5E.59.04109.39901F25@zhhdzmsp-mxin18> <14396665.321257.1391595937846.JavaMail.trustmail@ss000808> Message-ID: <52F385EC.3000105@ripe.net> Dear colleagues, Thank you for your queries. The RIPE NCC is now applying the new policy described in the updated RIPE Document, ?IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region?. LIRs may update their processes accordingly. While the new policy now applies, there will be an implementation period as we update our own internal processes and procedures. As the new policy makes a big change to the way the RIPE NCC handles IPv4, this will mean updating our supporting software and documentation, and reviewing how we ensure correct registrations and explain our processes externally. Implementing the new policy will also mean updating the forms that LIRs send in to the RIPE NCC. This will take some time, and so for now, while the evaluation criteria are new, the processes will remain the same. The RIPE NCC will send another announcement when the implementation is complete and the new forms and procedures are in place. We hope this answers your questions. Kind regards Marco Schmidt Policy Development Officer RIPE NCC On 2/5/14 11:25 AM, Robert.Guentensperger at swisscom.com wrote: > Dear all, > > I'm unsure now. > Is ripe-583 (Provider Aggregatable (PA) Assignment Request Form) still valid? > Regarding the new policy-text and the discussion before it's now unclear. > At least for me. ;-) > > Thank you in advance for a clarification. > > Best regards, > Robert > > > Robert G?ntensperger > Swisscom (Switzerland) Ltd. > > > > >> -----Original Message----- >> From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg- >> bounces at ripe.net] On Behalf Of Marco Schmidt >> Sent: Tuesday, February 04, 2014 4:36 PM >> To: policy-announce at ripe.net >> Cc: address-policy-wg at ripe.net >> Subject: [address-policy-wg] 2013-03 Proposal Accepted (Post Depletion >> Adjustment of Procedures to Match Policy Objectives, and Clean-up of >> Obsolete Policy Text) >> >> >> Dear colleagues, >> >> >> Consensus has been reached, and the proposal for a change to RIPE >> Document ripe-599, "IPv4 Address Allocation and Assignment Policies for >> the RIPE NCC Service Region", has been accepted by the RIPE community. >> >> >> You can find the full proposal at: >> >> https://www.ripe.net/ripe/policies/proposals/2013-03 >> >> The new RIPE Document is called ripe-604 and is available at: >> >> https://www.ripe.net/ripe/docs/ripe-604 >> >> >> The RIPE NCC has already begun preparations to implement this policy >> proposal, which will require updating many internal and external >> procedures and related tools to ensure we continue to provide efficient >> service. >> We estimate it may take up to three months to make these changes and >> fully implement the policy proposal. In the meantime, the current >> procedures will remain in effect. The RIPE NCC will send another >> announcement once the implementation is complete and the new procedures >> are in place. >> >> >> Thank you to everyone who provided input. >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC From mschmidt at ripe.net Thu Feb 6 15:59:11 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 06 Feb 2014 15:59:11 +0100 Subject: [address-policy-wg] RIPE Policy Proposal 2012-07 Accepted: Effect on ripe-604 Message-ID: <52F3A33F.4060803@ripe.net> Dear colleagues, As announced on the RIPE NCC Services Working Group Mailing List, the policy proposal 2012-07, ?RIPE NCC Services to Legacy Internet Resource Holders? has reached consensus. This proposal contained a small amendment to ripe-604, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". 2012-07 replaces section 5.5 of ripe-604, currently: "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by either the RIPE NCC or the IANA." With "Any LIR is allowed to re-allocate complete or partial blocks of IPv4 address space that were previously allocated to them by the RIPE NCC or otherwise through the Regional Internet Registry System." This change was proposed to ensure that 2012-07 was in alignment with the policies described in ripe-604, ?IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region?. The new RIPE Document is ripe-606 and it is available at: https://www.ripe.net/ripe/docs/ripe-606 As an existing RIPE Document was impacted by this policy proposal, we felt it was worth notifying the Address Policy Working Group. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC From nick at inex.ie Thu Feb 6 16:03:44 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 06 Feb 2014 15:03:44 +0000 Subject: [address-policy-wg] RIPE Policy Proposal 2012-07 Accepted: Effect on ripe-604 In-Reply-To: <52F3A33F.4060803@ripe.net> References: <52F3A33F.4060803@ripe.net> Message-ID: <52F3A450.5020103@inex.ie> On 06/02/2014 14:59, Marco Schmidt wrote: > The new RIPE Document is ripe-606 and it is available at: was ripe-604 the shortest-lived policy document in the history of RIPE? Nick From leo.vegoda at icann.org Thu Feb 6 18:24:16 2014 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 6 Feb 2014 09:24:16 -0800 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: <52F2B27F.9090701@fud.no> References: <52F2B27F.9090701@fud.no> Message-ID: <5648A8908CCB564EBF46E2BC904A75B19684A123D8@EXVPMBX100-1.exc.icann.org> Hi Tore, Tore Anderson wrote: [...] > If however ARIN and LACNIC have no preference, I'd say makes Leo's job easier>. Your kind thoughts are appreciated. I do not think either option has a greater operational impact than the other. Regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5475 bytes Desc: not available URL: From sander at steffann.nl Thu Feb 6 18:36:59 2014 From: sander at steffann.nl (Sander Steffann) Date: Thu, 6 Feb 2014 18:36:59 +0100 Subject: [address-policy-wg] RIPE Policy Proposal 2012-07 Accepted: Effect on ripe-604 In-Reply-To: <52F3A450.5020103@inex.ie> References: <52F3A33F.4060803@ripe.net> <52F3A450.5020103@inex.ie> Message-ID: <6293FD0A-0737-4770-8C5A-53C8C66CB819@steffann.nl> Hi Nick, > was ripe-604 the shortest-lived policy document in the history of RIPE? I would be very surprised if it wasn't :) Cheers, Sander From sander at steffann.nl Thu Feb 6 18:36:59 2014 From: sander at steffann.nl (Sander Steffann) Date: Thu, 6 Feb 2014 18:36:59 +0100 Subject: [address-policy-wg] RIPE Policy Proposal 2012-07 Accepted: Effect on ripe-604 In-Reply-To: <52F3A450.5020103@inex.ie> References: <52F3A33F.4060803@ripe.net> <52F3A450.5020103@inex.ie> Message-ID: <6293FD0A-0737-4770-8C5A-53C8C66CB819@steffann.nl> Hi Nick, > was ripe-604 the shortest-lived policy document in the history of RIPE? I would be very surprised if it wasn't :) Cheers, Sander From pk at DENIC.DE Thu Feb 6 18:43:31 2014 From: pk at DENIC.DE (Peter Koch) Date: Thu, 6 Feb 2014 18:43:31 +0100 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: Message-ID: <20140206174331.GJ11724@x28.adm.denic.de> On Wed, Feb 05, 2014 at 07:57:32PM +0100, Filiz Yilmaz wrote: > 2.0 Allocation of returned IPv4 address space by the IANA > > 1. Allocations from the IANA may begin once the pool is declared active. > 2. In each "IPv4 allocation period", each RIR will receive a single ?IPv4 allocation unit? from the IANA. > 3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year > > ... > ---- > > While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 and 3 together talk about "allocation periods" and that they are the ?6-month period following 1 March or 1 September in each year.? > > In practice, if the pool is declared active on 1 January and IANA makes the first allocations immediately this would be outside of the allocation period, which begins at the start of March. or 1 September of the previous year, in this case. My reading is that "IPv4 allocation period[s]" run regardless of the status of the pool (active or not). > So mainly the question is about the first allocations from the the Recovered IPv4 pool; > > a) Should they be made straight away At least they "may" (as per 1. above) start immediately. Whether they ought to start immediately, i.e., whether any and all RIRs can derive a right to allocation, is a differrent issue. That becomes more interesting if the state change occurs on 27 Feb rather than 1 Jan. -Peter From nigel at titley.com Fri Feb 7 18:57:55 2014 From: nigel at titley.com (Nigel Titley) Date: Fri, 07 Feb 2014 17:57:55 +0000 Subject: [address-policy-wg] RIPE Policy Proposal 2012-07 Accepted: Effect on ripe-604 In-Reply-To: <6293FD0A-0737-4770-8C5A-53C8C66CB819@steffann.nl> References: <52F3A33F.4060803@ripe.net> <52F3A450.5020103@inex.ie> <6293FD0A-0737-4770-8C5A-53C8C66CB819@steffann.nl> Message-ID: <52F51EA3.4060504@titley.com> On 06/02/2014 17:36, Sander Steffann wrote: > Hi Nick, > >> was ripe-604 the shortest-lived policy document in the history of RIPE? > I would be very surprised if it wasn't :) > > Hmm, I feel a topic for the Secret-WG coming up Nigel From nick at inex.ie Sat Feb 22 21:58:31 2014 From: nick at inex.ie (Nick Hilliard) Date: Sat, 22 Feb 2014 20:58:31 +0000 Subject: [address-policy-wg] Post Ident / Post Brief Message-ID: <53090F77.8000303@inex.ie> As there are legal prohibitions in place which prevent german nationals (and possibly other countries) from photocopying their passports, would it be possible for the RIPE NCC to give an opinion on whether Post Ident would be acceptable as an alternative to photocopying passports / driving licenses / etc for PI address applications? Post Ident is considered to be suitable identity certification from the point of view of the german money laundering act. Nick From richih.mailinglist at gmail.com Sat Feb 22 22:18:53 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 22 Feb 2014 22:18:53 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <53090F77.8000303@inex.ie> References: <53090F77.8000303@inex.ie> Message-ID: Yes, please. Unless you are a government organ which is allowed to establish identity (police etc) you must not require copies of id. Richard Sent by mobile; excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pk at DENIC.DE Sat Feb 22 23:17:25 2014 From: pk at DENIC.DE (Peter Koch) Date: Sat, 22 Feb 2014 23:17:25 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <53090F77.8000303@inex.ie> References: <53090F77.8000303@inex.ie> Message-ID: <20140222221725.GC21395@x28.adm.denic.de> On Sat, Feb 22, 2014 at 08:58:31PM +0000, Nick Hilliard wrote: > As there are legal prohibitions in place which prevent german nationals > (and possibly other countries) from photocopying their passports, would it it prevents third parties from requesting the copy. Same result, different story. -Peter From richih.mailinglist at gmail.com Sat Feb 22 23:49:44 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Sat, 22 Feb 2014 23:49:44 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140222221725.GC21395@x28.adm.denic.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> Message-ID: They can request, but not demand. I just read the internal legal analysis of a fortune 500 this Friday. Richard Sent by mobile; excuse my brevity. On Feb 22, 2014 11:18 PM, "Peter Koch" wrote: > On Sat, Feb 22, 2014 at 08:58:31PM +0000, Nick Hilliard wrote: > > As there are legal prohibitions in place which prevent german nationals > > (and possibly other countries) from photocopying their passports, would > it > > it prevents third parties from requesting the copy. Same result, different > story. > > -Peter > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From koalafil at gmail.com Mon Feb 24 09:35:52 2014 From: koalafil at gmail.com (Filiz Yilmaz) Date: Mon, 24 Feb 2014 09:35:52 +0100 Subject: [address-policy-wg] Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA In-Reply-To: References: Message-ID: <568D9FC3-219A-466E-829E-8B25C416057B@gmail.com> Dear Colleagues, It was 23 February 2014 yesterday and so it is time to conclude this thread as announced earlier. From the responses that Peter Koch, Tore Anderson, Niall O?Reilly, Scott Leibrand and Elvis Velea had sent (and considering Leo Vegoda?s post informational), I see there is either support for Option A or people do not see much difference between the options and nobody strongly prefers Option B over A. So my understanding is that there is consensus for Option A from our region, as the reading of Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA: The first allocations from the the Recovered IPv4 pool should be made straight away as soon as the pool is declared active. I will communicate this back to the NRO NC/ASO AC. Thank you very much for your feedback. Kind regards Filiz Yilmaz as NRO NC Member from RIPE Region On 05 Feb 2014, at 19:57, Filiz Yilmaz wrote: > Dear Colleagues, > > NRO NC is asked by the IANA Staff for a clarification on the reading of this policy, Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA, in regards to "when" the first allocations from the Recovered IPv4 pool can be made. > > The Council decided to check further with the communities, hence this mail. > > The policy document (http://www.ripe.net/ripe/docs/ripe-529) states the following: > > ---- > > 1.0 Recovered IPv4 Pool > > ?. > > When one of the RIRs declares it has less than a total of a /9 in its inventory, the Recovered IPv4 pool will be declared active, and IP addresses from the Recovered IPv4 Pool will be allocated as stated in Section 2.0 below. > > 2.0 Allocation of returned IPv4 address space by the IANA > > 1. Allocations from the IANA may begin once the pool is declared active. > 2. In each "IPv4 allocation period", each RIR will receive a single ?IPv4 allocation unit? from the IANA. > 3. An "IPv4 allocation period" is defined as a 6-month period following 1 March or 1 September in each year > > ... > ---- > > While clause 1 seems to be pretty clear, it contains a "may" and clauses 2 and 3 together talk about "allocation periods" and that they are the ?6-month period following 1 March or 1 September in each year.? > > In practice, if the pool is declared active on 1 January and IANA makes the first allocations immediately this would be outside of the allocation period, which begins at the start of March. > > So mainly the question is about the first allocations from the the Recovered IPv4 pool; > > a) Should they be made straight away > or > b) Should IANA wait and make them at the start of the next "IPv4 allocation period," the "6-month period following 1 March or 1 September. > > > In my personal opinion I see no problems with starting straight away (option a above), and then continue the rest in the regularity of the allocation periods as stated in the policy. > > Would you agree or is your reading towards option b above? > > Please let us know of your opinions on this list until 23 February 2014. > > > Kind regards > Filiz Yilmaz > as NRO NC Member from RIPE Region > > From 8916 at 5800672.ru Sat Feb 22 20:31:13 2014 From: 8916 at 5800672.ru (=?koi8-r?B?6czY0SDwz8zV28vJzg==?=) Date: Sat, 22 Feb 2014 23:31:13 +0400 Subject: [address-policy-wg] ABUSE IP 176.57.210.40 planetadeneg.com Message-ID: <94091393097473@web11g.yandex.ru> Welcome to the IP 176.57.210.40 planetadeneg.com domain is the so-called HYIP project administrator who collects the money and cheating people. Please take steps to block IP 176.57.210.40 work or I will be forced to contact the police. ? ?????????, ???????? ???? ???.: 7(916)5800672 From ncc at ripe.net Mon Feb 24 13:23:48 2014 From: ncc at ripe.net (RIPE NCC) Date: Mon, 24 Feb 2014 13:23:48 +0100 Subject: [address-policy-wg] NCC#2014025644 ABUSE IP 176.57.210.40 planetadeneg.com In-Reply-To: <94091393097473@web11g.yandex.ru>; from =?ISO-8859-1?Q?=E9=CC=D8=D1?= =?ISO-8859-1?Q?=F0=CF=CC=D5=DB=CB=C9=CE?= on Sat, 22 Feb 2014 23:31:13 +0400 References: <94091393097473@web11g.yandex.ru> Message-ID: Dear Sir/Madam, You have sent us a complaint regarding network abuse. The RIPE NCC is responsible for the allocation of blocks of IP address space. The RIPE NCC is *NOT* a service provider and has no jurisdiction over, or responsibility for, how the allocated IP numbers are used. You may have been directed to the RIPE NCC because we run a publicly available database that allows users to look up the contact information for the organisations responsible for particular IP address space. Please contact the company responsible for the IP address regarding your abuse complaint: https://apps.db.ripe.net/search/query.html?searchtext=176.57.210.40&searchSubmit=search#resultsAnchor Their contact information is: abuse at timeweb.ru More information regarding network abuse is available on our website at: http://www.ripe.net/data-tools/db/faq/faq-hacking-spamming http://www.ripe.net/ripe/docs/ripe-409 http://www.ripe.net/lir-services/ncc/legal/legal-information -- If you have any questions, please feel free to contact us. Best regards, Henriette van Ingen ------------------ Customer Services RIPE NCC ============================================================ RIPE NCC Customer Satisfaction Survey ************************************* Tell us about your customer services experience by filling out the anonymous, three-question RIPE NCC customer satisfaction survey: https://www.ripe.net/contact/survey/satisfaction-cs/ ============================================================= On Sat, 22 Feb 2014 23:31:13 +0400, ???? ???????? wrote: > Welcome to the IP 176.57.210.40 planetadeneg.com domain is the so-called HYIP project administrator who collects the money and cheating people. > Please take steps to block IP 176.57.210.40 work or I will be forced to contact the police. > > ? ?????????, ???????? ???? > ???.: 7(916)5800672 From athina.fragkouli at ripe.net Tue Feb 25 16:03:40 2014 From: athina.fragkouli at ripe.net (Athina Fragkouli) Date: Tue, 25 Feb 2014 16:03:40 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> Message-ID: <530CB0CC.1080204@ripe.net> Dear Nick, all, The main goal of the RIPE NCC in this regard is to ensure that the RIPE NCC registration data is correct and up to date. For this reason, we perform due diligence checks on legal and natural persons the RIPE NCC registers Internet number resources for. For these checks, the RIPE NCC only accepts confirmation of identification that is issued by national authorities (such as the police, the notary, the municipality, etc). Postident is issued by Deutsche Post AG, a private company, so we are unable to accept it. If a natural person wants to register Internet number resources by signing a contract with either the RIPE NCC or a sponsoring LIR, the RIPE NCC accepts the following proof of identification: - National identification card or passport - Valid driving license with photo - Birth certificate issued by the relevant municipality, notary declaration proving the existence of the person, etc. These options are outlined in the RIPE NCC procedural document ?Due Diligence for the Quality of the RIPE NCC Registration Data?, which is available at: http://www.ripe.net/ripe/docs/ripe-556 We believe these options cover situations where the natural persons do not want to provide their identification card or passport. The RIPE NCC is committed to protecting all personal information in accordance with its Privacy Statement: http://www.ripe.net/lir-services/ncc/legal/ripe-ncc-privacy-statement If you have any further questions, please contact me. Kind regards, Athina Fragkouli Legal Counsel RIPE NCC On 2/22/14 11:49 PM, Richard Hartmann wrote: > They can request, but not demand. > > I just read the internal legal analysis of a fortune 500 this Friday. > > Richard > > Sent by mobile; excuse my brevity. > > On Feb 22, 2014 11:18 PM, "Peter Koch" > wrote: > > On Sat, Feb 22, 2014 at 08:58:31PM +0000, Nick Hilliard wrote: > > As there are legal prohibitions in place which prevent german > nationals > > (and possibly other countries) from photocopying their passports, > would it > > it prevents third parties from requesting the copy. Same result, > different > story. > > -Peter > From gert at space.net Tue Feb 25 19:55:58 2014 From: gert at space.net (Gert Doering) Date: Tue, 25 Feb 2014 19:55:58 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530CB0CC.1080204@ripe.net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> Message-ID: <20140225185558.GQ43641@Space.Net> Hi, On Tue, Feb 25, 2014 at 04:03:40PM +0100, Athina Fragkouli wrote: > These options are outlined in the RIPE NCC procedural document ???Due > Diligence for the Quality of the RIPE NCC Registration Data???, which is > available at: > http://www.ripe.net/ripe/docs/ripe-556 > > We believe these options cover situations where the natural persons do > not want to provide their identification card or passport. Well. Since this is procedures and not policy, we have no formal authority over this - OTOH, I think I'm not alone when I have the feeling that this exceeds the requirements of the policy by far. I can see the wish for such a strong requirements for end users that become direct access users (DAU) with the RIPE NCC, but that category was discontinued anyway. For normal end users, the policy requires "a contract with a sponsoring LIR", and I think it should be fully sufficient to leave questions of identity validation for natural persons to the LIR in question. Like "I know this person personally, I'm fine with doing business with him", that should be good enough for the NCC as well - after all, the whole idea of the "sponsoring LIR" construct is that the NCC has a trusted intermediate, and the end user does not have to deal with the NCC. Of course I can't decide anything what the NCC will do or not do, but what I *can* do is put this on the next meeting's APWG agenda, to discuss what requirements for ID validation the community mandates. The NCC should not gratiously exceed the bureaucracy demanded from it. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From richih.mailinglist at gmail.com Tue Feb 25 20:36:52 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Tue, 25 Feb 2014 20:36:52 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225185558.GQ43641@Space.Net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> Message-ID: On Tue, Feb 25, 2014 at 7:55 PM, Gert Doering wrote: > I can see the wish for such a strong requirements for end users that > become direct access users (DAU) with the RIPE NCC, but that category was > discontinued anyway. Even if there's a need for strong identification, we are left with one of three * a demand which is illegal under German law (IANAL) * a valid approach for anyone who has a driver's license * an extremely over-the-top approach which puts undue burden on people whereas even German banks are OK with Postident. Arguably, banks need a higher level of security than RIPE NCC. I fail to see why RIPE NCC is unable to survey commonly and legally accepted means of establishing identity among the member states and use those existing mechanisms. This would seem to the be the prudent approach to take. > The NCC should > not gratiously exceed the bureaucracy demanded from it. Agreed. Richard From nibbler at ccc.de Tue Feb 25 20:50:42 2014 From: nibbler at ccc.de (Michael Horn) Date: Tue, 25 Feb 2014 20:50:42 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530CB0CC.1080204@ripe.net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> Message-ID: <20140225205042.09400559@carbonium> Dear Athina, On Tue, 25 Feb 2014 16:03:40 +0100 Athina Fragkouli wrote: > police, the notary, the municipality, etc). Postident is issued by > Deutsche Post AG, a private company, so we are unable to accept it. It is not a means of identification that is issued, such as an id card, but a standardized and widely used verification process. This process is designed to accommodate national legal restrictions as concerns the copying of identification documents. The process is invoked by the entity that wishes a confirmation of identity. Upon such a request a token is provided by Deutsche Post AG to the person whose identity shall be validated. Said person hands the token and their ID to an employee of Deutsche Post AG or one of their subsidiaries in order to have the ID checked. If the ID is indeed valid and matches the credentials stated in the validation token a statement of confirmation is issued by Deutsche Post AG which sent back to the invoking entity. > If a natural person wants to register Internet number resources by > signing a contract with either the RIPE NCC or a sponsoring LIR, the > RIPE NCC accepts the following proof of identification: > - National identification card or passport ...of which you can't - by German laws - demand a copy. > - Valid driving license with photo Not every natural person is necessarily holding a drivers license. > - Birth certificate issued by the relevant municipality, notary > declaration proving the existence of the person, etc. That might work, however I fail to see the difference between a notary declaration of the existence and validity of a document and the postident-process. Granted... the German postal service (luckily?) has no notarial authority but postident is the next best thing and it is widely available. > We believe these options cover situations where the natural persons do > not want to provide their identification card or passport. It is not about not _wanting_ to provide a copy... You are simply in violation of the law if you demand a copy of an official id. The only exemption from this law is ?1 of the Geldw?schegesetz as laid out here: http://www.gesetze-im-internet.de/gwg_2008/__1.html Unless the NCC engages in banking activities (for which I fail to see even the chance of a consensus) copies of nationally issued id cards are off limits. > The RIPE NCC is committed to protecting all personal information in > accordance with its Privacy Statement: To the best of your abilities. Which is ok but does not matter here. It is not about people being concerned that their data might become unintendedly available to a wider audience due to negligence on the RIPE NCC's side, but compliance with local laws. > If you have any further questions, please contact me. dito. I hope this clarifies the nature of the issue. There are also detailed WP:de articles about this topic for further reading: http://de.wikipedia.org/wiki/Identit%C3%A4tsfeststellung http://de.wikipedia.org/wiki/Legitimationspr%C3%BCfung http://de.wikipedia.org/wiki/Postident-Verfahren TL;DR: Unless you implement verification processes such as PostIdent or demand notarized declarations of the validity of identities instead of demanding copies of IDs you are in violation of German law. Please keep us updated about changes in your verification procedures for German citizens and the status of compliance with German laws. As Gert pointed out, the process just applys to DAUs, which is a category that's going to disappear. I hope this matter will resolve itself thusly anyway. Kind regards, Michael p.s. just looked up the exact legal norms for your convenience: ?14 and ? 20 paragraph 1 Personalausweisgesetz http://www.gesetze-im-internet.de/pauswg/BJNR134610009.html original precedent at the Verwaltungsgericht Hannover, 10. Kammer, Urteil vom 28.11.2013, 10 A 5342/11: http://www.rechtsprechung.niedersachsen.de/jportal/portal/page/bsndprod.psml?doc.id=JURE140002005&st=null&showdoccase=1 summary of the case 10 A 5342/11: http://www.verwaltungsgericht-hannover.niedersachsen.de/portal/live.php?navigation_id=19421&article_id=120077&_psmand=126Legal From lists-ripe at c4inet.net Tue Feb 25 21:42:44 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 25 Feb 2014 20:42:44 +0000 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225205042.09400559@carbonium> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225205042.09400559@carbonium> Message-ID: <20140225204244.GA32400@cilantro.c4inet.net> On Tue, Feb 25, 2014 at 08:50:42PM +0100, Michael Horn wrote: >> - Birth certificate issued by the relevant municipality, notary >> declaration proving the existence of the person, etc. > >That might work, however I fail to see the difference between a notary >declaration of the existence and validity of a document and the >postident-process. Granted... the German postal service (luckily?) has >no notarial authority but postident is the next best thing and it is >widely available. Moreover, the security of a birth cert is questionable, to say the least. Birt certs are public information in many jurisdictions, for example I should be able to get a copy of anyone's birth certificate here, with little effort. My point here is that the End User is applying for IP addresses or ASNs, not a large mortgage or the nuclear launch codes. The bureaucratic effort neccessary should be *proportional* to the goal. The NCC has the authority to de-register resources anyway, should an identity prove to be fraudulent after the fact. rgds, Sascha Luck From davidm at futureinquestion.net Tue Feb 25 22:34:53 2014 From: davidm at futureinquestion.net (David Monosov) Date: Tue, 25 Feb 2014 22:34:53 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225185558.GQ43641@Space.Net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> Message-ID: <530D0C7D.5010900@futureinquestion.net> Dear address-policy-wg, Gert, On 02/25/2014 07:55 PM, Gert Doering wrote: > Hi, > > On Tue, Feb 25, 2014 at 04:03:40PM +0100, Athina Fragkouli wrote: >> These options are outlined in the RIPE NCC procedural document ???Due >> Diligence for the Quality of the RIPE NCC Registration Data???, which is >> available at: http://www.ripe.net/ripe/docs/ripe-556 >> >> We believe these options cover situations where the natural persons do >> not want to provide their identification card or passport. > > Of course I can't decide anything what the NCC will do or not do, but what > I *can* do is put this on the next meeting's APWG agenda, to discuss what > requirements for ID validation the community mandates. The NCC should not > gratiously exceed the bureaucracy demanded from it. > Please do so. A specific policy may be required to address and define the exact scope of these efforts, since current operational efforts don't seem to be aligned with the community's vision on this matter. This is an issue I've heard many battle stories about, and came across multiple times myself. There is an issue with both the excessive burden placed on individuals, as well as a related issue with pseudo-arbitrary interpretation of certain forms of business registration in some jurisdictions. Several colleagues have encountered some inconsistency in the context of d/b/a (doing business as) registration equivalents and sole proprietorships which in some instances resulted in the resources becoming successfully registered on the d/b/a trade name, while in others the NCC insisted on registering resources on the sole proprietor's own name, or a combination of both. It's outstanding that the RIPE NCC has taken it upon itself to fulfill the community's wishes as set forth in 2007-01 with utmost care and competence, but I have sincere doubts that the people who championed 2007-01 envisioned it as means of turning the NCC into a databank of personal identity documents. -- Respectfully yours, David Monosov From nick at inex.ie Tue Feb 25 22:54:00 2014 From: nick at inex.ie (Nick Hilliard) Date: Tue, 25 Feb 2014 21:54:00 +0000 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530D0C7D.5010900@futureinquestion.net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D0C7D.5010900@futureinquestion.net> Message-ID: <530D10F8.6080009@inex.ie> On 25/02/2014 21:34, David Monosov wrote: > It's outstanding that the RIPE NCC has taken it upon itself to fulfill the > community's wishes as set forth in 2007-01 with utmost care and competence, > but I have sincere doubts that the people who championed 2007-01 envisioned it > as means of turning the NCC into a databank of personal identity documents. there are two separate issues to consider, firstly that the ripe ncc has a duty to authenticate PI holders to some degree of due diligence, and secondly how this is intertwined with the much more stringent legal requirements of resource certification. I don't see any particular reason not to accept post ident (and similar authentication schemes with legal recognition in their own countries) for the purposes of assignment of resources. OTOH I could see how the ripe ncc would have trouble making a claim of certification without unambiguous formal legal authentication via e.g. photocopies of ID documents, notarised endorsements, etc. Nick From ripe-wgs.cs at schiefner.de Tue Feb 25 23:07:03 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 25 Feb 2014 23:07:03 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> Message-ID: <530D1407.7030909@schiefner.de> Dear Athina, all - On 25.02.2014 20:36, Richard Hartmann wrote: > Even if there's a need for strong identification, we are left with one of three > > * a demand which is illegal under German law (IANAL) > * a valid approach for anyone who has a driver's license > * an extremely over-the-top approach which puts undue burden on people > > whereas even German banks are OK with Postident. Arguably, banks need > a higher level of security than RIPE NCC. > > I fail to see why RIPE NCC is unable to survey commonly and legally > accepted means of establishing identity among the member states and > use those existing mechanisms. This would seem to the be the prudent > approach to take. what Richard said: what is good enough for (German) banks to e.g. open an account, should be sufficient for the NCC as well, me thinks. Best, -C. From sergey at devnull.ru Tue Feb 25 23:16:45 2014 From: sergey at devnull.ru (Sergey Myasoedov) Date: Tue, 25 Feb 2014 23:16:45 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530D1407.7030909@schiefner.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> Message-ID: Hi everybody, I can?t agree. On 25 Feb 2014, at 23:07, Carsten Schiefner wrote: > what Richard said: what is good enough for (German) banks to e.g. open an account, should be sufficient for the NCC as well, me thinks. in other words, what is good enough for transistrian/lebanese/BVI/iranian/somalian banks - should be good enough for the NCC? what data quality we are trying to achive? -- Sergey From aleheux at kobo.com Tue Feb 25 23:20:10 2014 From: aleheux at kobo.com (Alex Le Heux) Date: Tue, 25 Feb 2014 22:20:10 +0000 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530D10F8.6080009@inex.ie> Message-ID: >there are two separate issues to consider, firstly that the ripe ncc has a >duty to authenticate PI holders to some degree of due diligence, and >secondly how this is intertwined with the much more stringent legal >requirements of resource certification. Why are those requirements much more stringent? Alex From lists-ripe at c4inet.net Tue Feb 25 23:24:49 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Tue, 25 Feb 2014 22:24:49 +0000 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530D1407.7030909@schiefner.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> Message-ID: <20140225222449.GB32400@cilantro.c4inet.net> On Tue, Feb 25, 2014 at 11:07:03PM +0100, Carsten Schiefner wrote: >what Richard said: what is good enough for (German) banks to e.g. >open an account, should be sufficient for the NCC as well, me thinks. German banks accept this even though they are required by money-laundering law to verify identity and have therefore a specific exemption from the no-copy law! rgds, Sascha Luck From dr at cluenet.de Tue Feb 25 23:37:59 2014 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 25 Feb 2014 23:37:59 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225185558.GQ43641@Space.Net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> Message-ID: <20140225223759.GB16279@srv03.cluenet.de> On Tue, Feb 25, 2014 at 07:55:58PM +0100, Gert Doering wrote: > Well. Since this is procedures and not policy, we have no formal > authority over this - OTOH, I think I'm not alone when I have the feeling > that this exceeds the requirements of the policy by far. +1 > For normal end users, the policy requires "a contract with a sponsoring > LIR", and I think it should be fully sufficient to leave questions of > identity validation for natural persons to the LIR in question. Like > "I know this person personally, I'm fine with doing business with him", > that should be good enough for the NCC as well - after all, the whole > idea of the "sponsoring LIR" construct is that the NCC has a trusted > intermediate, and the end user does not have to deal with the NCC. Strong ACK. Unfortunately, as far as I can see, NCC doesn't trust the RIPE membership to vouch for their customer's identities. And as far as I'm being told, there are a good number of examples that actually fuel NCC's distrust. Nevertheless, I think the current Due Dilligence process is far overreaching. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ripe-wgs.cs at schiefner.de Tue Feb 25 23:39:24 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Tue, 25 Feb 2014 23:39:24 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> Message-ID: <530D1B9C.1040809@schiefner.de> Dear Sergey, we were specifically debating the German PostIdent procedure - which is used by (almost?) all German direct/no branch offices/online banks. But AFAIK it is not restricted to German banks, non-German banks might be using it as well. As I am not sure about this - I do not have a non-German bank as an example at hand - I have put "German" in "()". Or shorter: security and trust lies with the process and provider of a service - and not with its users and/or customers. Best, -C. On 25.02.2014 23:16, Sergey Myasoedov wrote: > I can?t agree. > > On 25 Feb 2014, at 23:07, Carsten Schiefner > wrote: > >> what Richard said: what is good enough for (German) banks to e.g. >> open an account, should be sufficient for the NCC as well, me >> thinks. > > in other words, what is good enough for > transistrian/lebanese/BVI/iranian/somalian banks - should be good > enough for the NCC? what data quality we are trying to achive? From dr at cluenet.de Tue Feb 25 23:34:29 2014 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 25 Feb 2014 23:34:29 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> Message-ID: <20140225223429.GA16279@srv03.cluenet.de> On Tue, Feb 25, 2014 at 11:16:45PM +0100, Sergey Myasoedov wrote: > > what Richard said: what is good enough for (German) banks to e.g. open an account, should be sufficient for the NCC as well, me thinks. > > in other words, what is good enough for transistrian/lebanese/BVI/ > iranian/somalian banks - should be good enough for the NCC? what > data quality we are trying to achive? As long as NCC has no way to verify wether the data on those "proof of identity" copies are actually authentic and current, there is no point in collecting all this sensitive personal data. The bad guys know how to photoshop AND make sure methods like noise distribution analysis etc. DON'T catch it. At least I try not to underestimate the blackhats. :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jim at rfc1035.com Tue Feb 25 23:49:51 2014 From: jim at rfc1035.com (Jim Reid) Date: Tue, 25 Feb 2014 22:49:51 +0000 Subject: [address-policy-wg] identity verification for individuals holding Internet number resources In-Reply-To: <530D1407.7030909@schiefner.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> Message-ID: <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> On 25 Feb 2014, at 22:07, Carsten Schiefner wrote: > what Richard said: what is good enough for (German) banks to e.g. open an account, should be sufficient for the NCC as well, me thinks. The problem with that Carsten is it doesn't scale. What's good enough to open a bank account in Germany might not be good enough to open one elsewhere. Or vice versa. It will be verging on the impossible for the NCC to keep track of all that across the NCC's service region and navigate a path through that maze which is compatible with national law across every jurisdiction. Assuming that "whatever's good enough for a bank account" is or should be the criteria to apply here seems disproportionate and unreasonable too. I'm not sure there's a justifiable case for the NCC to hold copies of passports and what have you AT ALL. Or verifying the bona fides of those documents either. It seems to me that it should be good enough for the NCC to know that some chunk of number resources were allocated to an individual called Mickey Mouse of Eurodisney and not a Donald Duck (say) at the same postal address. In other words, the NCC has a very strong certainty of knowing which resources were allocated to whom but it doesn't need to have the same degree of certainty that the resource holder is who they claim to be. IMO all that matters should be the NCC can establish which M. Mouse really is the resource holder, regardless of what names and numbers are on the official identity documents for whoever claims to be that M. Mouse, assuming such documents exist and are genuine. That would appear to be just a variation on the problem of dealing with number resources that were allocated to long-dead LIRs or others that no longer have timely, accurate database entries. PS: Apologies for using a meaningful Subject: header. From dr at cluenet.de Wed Feb 26 00:03:34 2014 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 26 Feb 2014 00:03:34 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225205042.09400559@carbonium> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225205042.09400559@carbonium> Message-ID: <20140225230334.GC16279@srv03.cluenet.de> On Tue, Feb 25, 2014 at 08:50:42PM +0100, Michael Horn wrote: > > We believe these options cover situations where the natural persons do > > not want to provide their identification card or passport. > > It is not about not _wanting_ to provide a copy... You are simply in > violation of the law if you demand a copy of an official id. NCC doesn't care about German law, otherwise it would also have to abide to german data protection laws. But a German copying his/her personal ID is certainly violating the law. BTW, this is only true for personal ID card (Personalausweis) and possibly passport, but not for e.g. driving license as far as I'm aware. > It is not about people being concerned that their data might become > unintendedly available to a wider audience due to negligence on the > RIPE NCC's side, Wrong. At least for me, it's PRIMARILY about not spreading personal sensitive data to foreign organisations and companies without a factual need for that. Given that NCC cannot authenticate the personal data anyway, there is no point in collecting it for authentication reasons in the first place. This is a fundamental data protection principle in german law (which again, NCC doesn't have to abide to as far as I understand - IANAL): Datenschutz beginnt mit Datenvermeidung (data protection starts with preventing collection of data) To illustrate my point: Just today I phoned the service desk of one of my banks to enquire about some credit card stuff. The only authentication requested from me was my account number (not really private data), my home address (public data, it's even in the RIPE DB) and my BIRTHDATE. And this is the second bank actually pulling off this stunt of using the birthdate as basically only means of caller identification. So, I really consider twice (and more) whom I give my birthdate, let alone other sensitive information. And certainly no photocopies of official ID papers. The fun thing is, NCC asks to TRUST THEM to keep sensitive personal data secure, but TRUSTS NOONE, even if multiple respected, well known members of the RIPE community in perfect standing, as well as the sponsoring LIR tell them they know the resource holder in person as well as having verified original personal ID. BTW, US companies also promise to keep your data secure and private. And then comes PATRIOT and FISA. Can't happen in NL? I wouldn't bet on that. > but compliance with local laws. That's just one aspect of it, which can be circumvented as NCC correctly pointed out. But the alternatives offered won't fulfil data protection principles or place significant (and IMHO undue) burden on the resource holder (notary declaration will btw. also include sensitive personal data like birth date I fear, I'm about to inform myself about the details now). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ripe-wgs.cs at schiefner.de Wed Feb 26 00:03:46 2014 From: ripe-wgs.cs at schiefner.de (Carsten Schiefner) Date: Wed, 26 Feb 2014 00:03:46 +0100 Subject: [address-policy-wg] identity verification for individuals holding Internet number resources In-Reply-To: <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> Message-ID: <530D2152.6080002@schiefner.de> Hi Jim, On 25.02.2014 23:49, Jim Reid wrote: > On 25 Feb 2014, at 22:07, Carsten Schiefner > wrote: > >> what Richard said: what is good enough for (German) banks to e.g. >> open an account, should be sufficient for the NCC as well, me >> thinks. > > The problem with that Carsten is it doesn't scale. What's good enough > to open a bank account in Germany might not be good enough to open > one elsewhere. Or vice versa. It will be verging on the impossible > for the NCC to keep track of all that across the NCC's service region > and navigate a path through that maze which is compatible with > national law across every jurisdiction. > > Assuming that "whatever's good enough for a bank account" is or > should be the criteria to apply here seems disproportionate and > unreasonable too. fair point. I am not advocating PostIdent as *THE* means of identification - just saying that it is even used by German banks. So it appears to be fair to assume that it meets some certain requirements. Whether it also would help serving the NCC's objectives is another question. > I'm not sure there's a justifiable case for the NCC to hold copies of > passports and what have you AT ALL. Or verifying the bona fides of > those documents either. > > It seems to me that it should be good enough for the NCC to know that > some chunk of number resources were allocated to an individual called > Mickey Mouse of Eurodisney and not a Donald Duck (say) at the same > postal address. [...] I have a certain feeling that this echos a bit the discussion we are currently having in the gTLD world when it comes to validation and verification duties of ICANN accredited registrars according to the RAA 2013. > PS: Apologies for using a meaningful Subject: header. You are forgiven! ;-b Best, -C. From davidm at futureinquestion.net Wed Feb 26 00:42:43 2014 From: davidm at futureinquestion.net (David Monosov) Date: Wed, 26 Feb 2014 00:42:43 +0100 Subject: [address-policy-wg] identity verification for individuals holding Internet number resources In-Reply-To: <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> Message-ID: <530D2A73.3030506@futureinquestion.net> Dear address-policy-wg, Jim, On 02/25/2014 11:49 PM, Jim Reid wrote: > On 25 Feb 2014, at 22:07, Carsten Schiefner wrote: > >> what Richard said: what is good enough for (German) banks to e.g. open an account, should be sufficient for the NCC as well, me thinks. > > The problem with that Carsten is it doesn't scale. What's good enough to open a bank account in Germany might not be good enough to open one elsewhere. Or vice versa. It will be verging on the impossible for the NCC to keep track of all that across the NCC's service region and navigate a path through that maze which is compatible with national law across every jurisdiction. > > Assuming that "whatever's good enough for a bank account" is or should be the criteria to apply here seems disproportionate and unreasonable too. > > I'm not sure there's a justifiable case for the NCC to hold copies of passports and what have you AT ALL. Or verifying the bona fides of those documents either. > > It seems to me that it should be good enough for the NCC to know that some chunk of number resources were allocated to an individual called Mickey Mouse of Eurodisney and not a Donald Duck (say) at the same postal address. In other words, the NCC has a very strong certainty of knowing which resources were allocated to whom but it doesn't need to have the same degree of certainty that the resource holder is who they claim to be. IMO all that matters should be the NCC can establish which M. Mouse really is the resource holder, regardless of what names and numbers are on the official identity documents for whoever claims to be that M. Mouse, assuming such documents exist and are genuine. That would appear to be just a variation on the problem of dealing with number resources that were allocated to long-dead LIRs or others that no longer have timely, accurate database entries. > > PS: Apologies for using a meaningful Subject: header. > There was a time when the last 'R' in 'RIR' stood for 'Registry', and as such the function of RIPE NCC was not profoundly different from the function of a wedding gift registry - convenient means to reduce the embarrassment of a household opening two packages containing two identical toasters when unwrapping gifts. Today, the last 'R' in 'RIR' is silent, and appears in the minds of some to have been replaced with 'A' for 'Authority'. This is an unfortunate, and I believe, largely unintended development. It appears to me from Nick's last e-mail that there is an idea circulating out there that the current operational practice is the consequence of attempting to fulfill a set of criteria which is necessary to give some legal weight to the process of resource certification, as an obvious and logical extension of the RPKI efforts. I don't see any benefit to the RIPE NCC drowning in an escalating bureaucratic horror conjured out of externally placed requirements (whether they are borrowed from the EU e-Commerce directive, or elsewhere), performing mysterious document authentication rituals for the purpose of issuing a certificate of dubious worth, but which in turn is fully compliant with some external set of legal requirements. Wearing my professional hat for a moment, I certainly am not paying LIR fees to subsidize the transition of the RIPE NCC into the next VeriSign or Thawte as a general purpose certificate authority, subject to all the environmental pressures such authorities find themselves exposed to. To me, RPKI, if done at all (and that is a big "if"), is a technical solution; The "strength" of the input, in terms of identity verification (and the operational procedures which are acceptable to that end) are to be determined ad-hoc by the community through the policy process, and strengthened or loosened as needed to meet policy goals. We need to stop and consider if RPKI, by necessity, indeed requires a transition from Internet "Registries" to Internet "Authorities", with all that entails - and if this is something we are willing to embrace. This isn't an introduction of a new service into a RIR's catalog, this is a paradigm shift. One which we need to concretely address in order to be able to hold a meaningful discussion as to which operational practices are or aren't necessary, and toward what goal. From dr at cluenet.de Wed Feb 26 00:46:15 2014 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 26 Feb 2014 00:46:15 +0100 Subject: [address-policy-wg] identity verification for individuals holding Internet number resources In-Reply-To: <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> Message-ID: <20140225234615.GA28593@srv03.cluenet.de> On Tue, Feb 25, 2014 at 10:49:51PM +0000, Jim Reid wrote: > It will be verging on the impossible for the NCC to keep track of > all that across the NCC's service region and navigate a path > through that maze which is compatible with national law across > every jurisdiction. Hey, they even manage to verify the authenticity of personal ID, passport or driving license copies submitted to them, together with the personal data and photo on them! Given the amount of service area states this is quite an achievement. I have no clue how they do it (curious mind wants to know), but it seems you're underestimating NCC. :-) BTW, NCC already does "special hacks" for certainly countries, IIRC it had to do with LIR membership in some eastern service area states. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ripe at opteamax.de Wed Feb 26 05:36:01 2014 From: ripe at opteamax.de (Opteamax GmbH) Date: Wed, 26 Feb 2014 05:36:01 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530D10F8.6080009@inex.ie> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D0C7D.5010900@futureinquestion.net> <530D10F8.6080009@inex.ie> Message-ID: <530D6F31.6010201@opteamax.de> Hi, the bigger issue I see with this change is, that there is no RIPE-area-wide common post-ident. For the German Post-Ident it is the requestor of identification who is in charge to initiate the post-ident process and who is in charge to match the token returned to the right customer. Even the name of the identified person is not necessarily given on the confirmation receipt. As I think there are at least a dozen of different identification services, each of them in the individual country "well accepted", I think that the implementation of such service would lead to a big workload for the RIPE-staff. BR Jens On 25. Februar 2014 22:54:00 MEZ, Nick Hilliard wrote: On 25/02/2014 21:34, David Monosov wrote: It's outstanding that the RIPE NCC has taken it upon itself to fulfill the community's wishes as set forth in 2007-01 with utmost care and competence, but I have sincere doubts that the people who championed 2007-01 envisioned it as means of turning the NCC into a databank of personal identity documents. there are two separate issues to consider, firstly that the ripe ncc has a duty to authenticate PI holders to some degree of due diligence, and secondly how this is intertwined with the much more stringent legal requirements of resource certification. I don't see any particular reason not to accept post ident (and similar authentication schemes with legal recognition in their own countries) for the purposes of assignment of resources. OTOH I could see how the ripe ncc would have trouble making a claim of certification without unambiguous formal legal authentication via e.g. photocopies of ID documents, notarised endorsements, etc. Nick !DSPAM:637,530d1132149033975113532! -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at opteamax.de Wed Feb 26 05:50:41 2014 From: ripe at opteamax.de (Opteamax GmbH) Date: Wed, 26 Feb 2014 05:50:41 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225230334.GC16279@srv03.cluenet.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225205042.09400559@carbonium> <20140225230334.GC16279@srv03.cluenet.de> Message-ID: <530D72A1.9050305@opteamax.de> On 26.02.2014 00:03, Daniel Roesen wrote: > The fun thing is, NCC asks to TRUST THEM to keep sensitive > personal data secure, but TRUSTS NOONE, even if multiple respected, > well known members of the RIPE community in perfect standing, as > well as the sponsoring LIR tell them they know the resource holder > in person as well as having verified original personal ID. Exactly THAT is the point. What do we have LIRs for? And why are sponsoring LIRs needed for PI if they are not trusted by RIPE-NCC? IMHO it is LIR-Task to validate the identity, and that can be done personally and without copying. BR Jens Ott -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From pk at DENIC.DE Wed Feb 26 06:42:12 2014 From: pk at DENIC.DE (Peter Koch) Date: Wed, 26 Feb 2014 06:42:12 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225222449.GB32400@cilantro.c4inet.net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> Message-ID: <20140226054212.GQ21395@x28.adm.denic.de> On Tue, Feb 25, 2014 at 10:24:49PM +0000, Sascha Luck wrote: > money-laundering law to verify identity and have therefore a specific > exemption from the no-copy law! they don't, but that's a common misreading. At most they are allowed to copy the explicit data items they are obliged to collect - with the rest covered. My question is who is procedurally required to check the identity and to collect (and keep?) the data: the LIR or the NCC. The latter might not be immediately bound by the German law on identity cards. -Peter From sp at iphh.net Wed Feb 26 07:35:32 2014 From: sp at iphh.net (Sascha E. Pollok) Date: Wed, 26 Feb 2014 07:35:32 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> Message-ID: <530D8B34.40506@iphh.net> >> what Richard said: what is good enough for (German) banks to e.g. open an account, should be sufficient for the NCC as well, me thinks. > > in other words, what is good enough for transistrian/lebanese/BVI/iranian/somalian banks - should be good enough for the NCC? what data quality we are trying to achive? I have to agree with Sergey. I have been through the hassle of getting married to a non-german. For a proof of authenticity of international documents they created the Apostille-agreement in the 1960s. It is enough for the Germans to accept e.g. a birth certificate from Mexico as valid. I could also e.g. request a registration confirmation (that shows my name, dob and home address) from the local authorities and then ask for an apostille to be glued on the document. It then shows that the document is legal and valid. But then, it is required to send by postal mail. And on top of that: not all countries joined the Apostille agreement and trust it mutually. Just because some German companies/banks have trust in PostIdent it does not mean the RIPE NCC should trust in all types of local stuff. Cheers! Sascha From dr at cluenet.de Wed Feb 26 08:25:38 2014 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 26 Feb 2014 08:25:38 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140226054212.GQ21395@x28.adm.denic.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> <20140226054212.GQ21395@x28.adm.denic.de> Message-ID: <20140226072537.GA21616@srv03.cluenet.de> On Wed, Feb 26, 2014 at 06:42:12AM +0100, Peter Koch wrote: > My question is who is procedurally required to check the identity and to > collect (and keep?) the data: the LIR or the NCC. The latter might not > be immediately bound by the German law on identity cards. Doesn't matter. It's not the one asking for a copy who is in violation of PAuswG, but the one performing the scan/copy, so the resource holder. And again, the legal problem of copying personal ID in Germany is just a distraction from the actual problem, and this that is IMHO the missing trust of NCC in the sponsoring RIPE members to perform resource holder identity verification as well as storing sensitive data for questionable reasons. As far as I read the policy, the author intended the existence of the contract between the sponsoring LIR and the end user as sufficient to prove existence and continued existence of the end user. That should be enough for NCC, according to the policy. All further direct verification of end user identity by NCC is uncalled for, by this policy. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From Woeber at CC.UniVie.ac.at Wed Feb 26 12:19:53 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 26 Feb 2014 12:19:53 +0100 Subject: [address-policy-wg] identity verification for individuals holding Internet number resources In-Reply-To: <530D2A73.3030506@futureinquestion.net> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> <530D2A73.3030506@futureinquestion.net> Message-ID: <530DCDD9.4050700@CC.UniVie.ac.at> David Monosov wrote: [...] First of all, I appreciate your thoughtful comments, as they touch on a couple of issues I'm having with RPKI (and some others)! A few comments from my end in-line. > There was a time when the last 'R' in 'RIR' stood for 'Registry', and as such > the function of RIPE NCC was not profoundly different from the function of a > wedding gift registry - convenient means to reduce the embarrassment of a > household opening two packages containing two identical toasters when unwrapping > gifts. > > Today, the last 'R' in 'RIR' is silent, and appears in the minds of some to have > been replaced with 'A' for 'Authority'. This is an unfortunate, and I believe, > largely unintended development. Well, at some point in time the AA community started to flock together, to point fingers at the NCC, for doing *too little* checking, and so on. > It appears to me from Nick's last e-mail that there is an idea circulating out > there that the current operational practice is the consequence of attempting to > fulfill a set of criteria which is necessary to give some legal weight to the > process of resource certification, as an obvious and logical extension of the > RPKI efforts. Well, yes, and in some countries (I don't know about the NL, though!) there is law which requires any organisation issuing digital certificates, or using digital sigantures for business porposes, to adhere to (rather strict) boundary conditions. > I don't see any benefit to the RIPE NCC drowning in an escalating bureaucratic > horror conjured out of externally placed requirements (whether they are borrowed > from the EU e-Commerce directive, or elsewhere), performing mysterious document > authentication rituals for the purpose of issuing a certificate of dubious > worth, but which in turn is fully compliant with some external set of legal > requirements. Unfortunately, the times where "we" could play while ignoring the legal environment has pretty much gone by :-( > Wearing my professional hat for a moment, I certainly am not paying LIR fees to > subsidize the transition of the RIPE NCC into the next VeriSign or Thawte as a > general purpose certificate authority, subject to all the environmental > pressures such authorities find themselves exposed to. This is an aspect I'd like to factor out into the separate discussion on the function (and including the credibility) of a Sponsoring LIR. IMHO there's room for improvement here. > To me, RPKI, if done at all (and that is a big "if"), is a technical solution; > The "strength" of the input, in terms of identity verification (and the > operational procedures which are acceptable to that end) are to be determined > ad-hoc by the community through the policy process, and strengthened or loosened > as needed to meet policy goals. > > We need to stop and consider if RPKI, by necessity, indeed requires a transition > from Internet "Registries" to Internet "Authorities", with all that entails - I think thre's a good reason why the "A" in CA and RA stands for "Authority". If we "just" want a CR adn a RR, then I guess we alreday do have that in place? > and if this is something we are willing to embrace. This isn't an introduction > of a new service into a RIR's catalog, this is a paradigm shift. One which we > need to concretely address in order to be able to hold a meaningful discussion > as to which operational practices are or aren't necessary, and toward what goal. Wilfried. From Woeber at CC.UniVie.ac.at Wed Feb 26 12:38:01 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 26 Feb 2014 12:38:01 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140226054212.GQ21395@x28.adm.denic.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> <20140226054212.GQ21395@x28.adm.denic.de> Message-ID: <530DD219.6010001@CC.UniVie.ac.at> A reality check and a question... I am wondering how German Citizens are dealing with the fact that *many* Hotels and other accomodation businesses *require* to take a copy of an official ID Document, in many cases due to local regulations to establish and track identity of travellers? Or is this law only applicable to German Citizens being physically present in Germany? Peter Koch wrote: > On Tue, Feb 25, 2014 at 10:24:49PM +0000, Sascha Luck wrote: > > >>money-laundering law to verify identity and have therefore a specific >>exemption from the no-copy law! > > > they don't, but that's a common misreading. At most they are allowed > to copy the explicit data items they are obliged to collect - with the rest > covered. > > My question is who is procedurally required to check the identity and to > collect (and keep?) the data: the LIR or the NCC. The latter might not > be immediately bound by the German law on identity cards. I think we are mixing two things here: - the verification of identity (leading to a binary result) - keeping the stuff in a collection, instead of destroying the input data > -Peter And lastly, just as an observation, the service area of the NCC is pretty much bigger than Germany, the EU, the EECR, or whatever formal tag to use. So, opening the door to a special mechanism in Germany[1], involving a (now) private entity, may not be a good idea to begin with; maybe not even in Germany ;-) Wilfried. [1] I presume the special recognition of Deutsche Post is a remnant of the fact that in the past it was wholly owned and controlled by the state. Is this correct? From ripe.address-policy-wg at ml.karotte.org Wed Feb 26 12:40:10 2014 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Wed, 26 Feb 2014 12:40:10 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140225223759.GB16279@srv03.cluenet.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <20140225223759.GB16279@srv03.cluenet.de> Message-ID: <20140226114010.GA25456@danton.fire-world.de> * Daniel Roesen [2014-02-25 23:39]: > > For normal end users, the policy requires "a contract with a sponsoring > > LIR", and I think it should be fully sufficient to leave questions of > > identity validation for natural persons to the LIR in question. Like > > "I know this person personally, I'm fine with doing business with him", > > that should be good enough for the NCC as well - after all, the whole > > idea of the "sponsoring LIR" construct is that the NCC has a trusted > > intermediate, and the end user does not have to deal with the NCC. > > Strong ACK. Unfortunately, as far as I can see, NCC doesn't trust the > RIPE membership to vouch for their customer's identities. And as far as > I'm being told, there are a good number of examples that actually > fuel NCC's distrust. Nevertheless, I think the current Due Dilligence > process is far overreaching. I agree with the NCC in regards of "not trusting an LIR". Becoming an LIR is easy (money wise and procedure wise) and does not imply a high value of trust for the LIR. We don't have this problem at the moment as all of our customers are companies and there is no problem with sending the company registration papers. I'm not sure if there is a good solution for all the countrys the NCC is providing service for. Still at least for Germany the NCC should find another way instead of requiring people to break the law. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From ripe.address-policy-wg at ml.karotte.org Wed Feb 26 12:43:25 2014 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Wed, 26 Feb 2014 12:43:25 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530DD219.6010001@CC.UniVie.ac.at> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> <20140226054212.GQ21395@x28.adm.denic.de> <530DD219.6010001@CC.UniVie.ac.at> Message-ID: <20140226114325.GB25456@danton.fire-world.de> * Wilfried Woeber [2014-02-26 12:39]: > A reality check and a question... > > I am wondering how German Citizens are dealing with the fact that *many* > Hotels and other accomodation businesses *require* to take a copy of an > official ID Document, in many cases due to local regulations to establish > and track identity of travellers? > > Or is this law only applicable to German Citizens being physically present > in Germany? At least in Germany you can tell them that that would be breaking the law and refuse to hand over the document. Worked for me most of the time. Outside of Germany... not so much. I suspect many people aren't even aware that they're breaking the law. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From db at rrbone.net Wed Feb 26 12:58:41 2014 From: db at rrbone.net (Dominik Bay) Date: Wed, 26 Feb 2014 12:58:41 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530DD219.6010001@CC.UniVie.ac.at> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> <20140226054212.GQ21395@x28.adm.denic.de> <530DD219.6010001@CC.UniVie.ac.at> Message-ID: <530DD6F1.1080905@rrbone.net> On 02/26/2014 12:38 PM, Wilfried Woeber wrote: > A reality check and a question... > > I am wondering how German Citizens are dealing with the fact that *many* > Hotels and other accomodation businesses *require* to take a copy of an > official ID Document, in many cases due to local regulations to establish > and track identity of travellers? If a hotel wants to copy my ID I demand them to destroy it and to only check their form against the data in my ID. On more and more occasions I have a BDSG ?5 compliant copy with me they can keep. Which is a photocopy but with data blacked out they don't need. -dominik From david.freedman at uk.clara.net Wed Feb 26 12:44:14 2014 From: david.freedman at uk.clara.net (David Freedman) Date: Wed, 26 Feb 2014 11:44:14 +0000 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140226114010.GA25456@danton.fire-world.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <20140225223759.GB16279@srv03.cluenet.de>, <20140226114010.GA25456@danton.fire-world.de> Message-ID: >I agree with the NCC in regards of "not trusting an LIR". Becoming an >LIR is easy (money wise and procedure wise) and does not imply a high >value of trust for the LIR. I'm really conflicted over this, why *don't* we trust the LIRs, after all, they are our agents, our hands and eyes in the registry. I understand there are low barriers to entry, but perhaps this is an opportunity to direct vetting efforts toward the LIR and not the End User. Dave. From ripe at opteamax.de Wed Feb 26 13:13:46 2014 From: ripe at opteamax.de (Opteamax GmbH) Date: Wed, 26 Feb 2014 13:13:46 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140226114010.GA25456@danton.fire-world.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <20140225223759.GB16279@srv03.cluenet.de> <20140226114010.GA25456@danton.fire-world.de> Message-ID: <530DDA7A.409@opteamax.de> Hi all, On 26.02.2014 12:40, Sebastian Wiesinger wrote: > I agree with the NCC in regards of "not trusting an LIR". Becoming an > LIR is easy (money wise and procedure wise) and does not imply a high > value of trust for the LIR. But then we should preferably think about how to make LIRs more trustable ... IMHO the hierarchy of internet-number-assignment is intended to make the processes more handleable ... if the RIR does not trust his LIRs, what is the RIR for? Then we'd only need one world-wide registry (so probably ICANN) and they have to validate stuff... or we think about trusting the LIR (and maybe even make a withdrawal of resources extremely expensive for the LIR if he did not fullfill his obligations) and make it easy and possible to fullfill all regional (in this case countrywise) requirements all over the RIPE region. Correct me if I'm wrong, but I understand this as the reason for having LOCAL internet registries! BR Jens -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989 From tore at fud.no Wed Feb 26 13:38:32 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 26 Feb 2014 13:38:32 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140226114010.GA25456@danton.fire-world.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <20140225223759.GB16279@srv03.cluenet.de> <20140226114010.GA25456@danton.fire-world.de> Message-ID: <530DE048.7060804@fud.no> * Sebastian Wiesinger > * Daniel Roesen [2014-02-25 23:39]: >> Strong ACK. Unfortunately, as far as I can see, NCC doesn't trust the >> RIPE membership to vouch for their customer's identities. And as far as >> I'm being told, there are a good number of examples that actually >> fuel NCC's distrust. Nevertheless, I think the current Due Dilligence >> process is far overreaching. > > I agree with the NCC in regards of "not trusting an LIR". Several NCC folks have told me that one of the things that you learn in the "welcome as an NCC employee" introduction is that the RIPE NCC is indeed an organisation based on trust in its membership and the community it serves. Which is a Good Thing; if it did not I do not quite see how it could justify its very existence. That said, I believe that if you truly do prefer to be a member of an RIR that doesn't trust you, more suitable alternatives than the NCC exist. Tore (without any informed opinion regarding German privacy laws) From stolpe at resilans.se Wed Feb 26 15:09:59 2014 From: stolpe at resilans.se (Daniel Stolpe) Date: Wed, 26 Feb 2014 15:09:59 +0100 (CET) Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530DDA7A.409@opteamax.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <20140225223759.GB16279@srv03.cluenet.de> <20140226114010.GA25456@danton.fire-world.de> <530DDA7A.409@opteamax.de> Message-ID: On Wed, 26 Feb 2014, Opteamax GmbH wrote: > Hi all, > > On 26.02.2014 12:40, Sebastian Wiesinger wrote: >> I agree with the NCC in regards of "not trusting an LIR". Becoming an >> LIR is easy (money wise and procedure wise) and does not imply a high >> value of trust for the LIR. > > But then we should preferably think about how to make LIRs more > trustable ... IMHO the hierarchy of internet-number-assignment is > intended to make the processes more handleable ... if the RIR does not > trust his LIRs, what is the RIR for? Then we'd only need one world-wide > registry (so probably ICANN) and they have to validate stuff... or we > think about trusting the LIR (and maybe even make a withdrawal of > resources extremely expensive for the LIR if he did not fullfill his > obligations) and make it easy and possible to fullfill all regional (in > this case countrywise) requirements all over the RIPE region. > > Correct me if I'm wrong, but I understand this as the reason for having > LOCAL internet registries! Absolutely. And RIPE still has about 10000 members so the NCC probably has some work to do just keeping track of the membership. I am in favour of this trust chain model. If the trust is misused, then the trust as well as resources may be revoked. 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 45 094 556741-1193 104 30 Stockholm From dr at cluenet.de Wed Feb 26 21:47:22 2014 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 26 Feb 2014 21:47:22 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140226114010.GA25456@danton.fire-world.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <20140225223759.GB16279@srv03.cluenet.de> <20140226114010.GA25456@danton.fire-world.de> Message-ID: <20140226204722.GA6012@srv03.cluenet.de> On Wed, Feb 26, 2014 at 12:40:10PM +0100, Sebastian Wiesinger wrote: > Still at least for Germany the NCC should find another way instead of > requiring people to break the law. NCC doesn't REQUIRE people to break the law. But the alternatives still violate data protection principles and/or place (IMHO) undue burden on resource holders. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From dr at cluenet.de Wed Feb 26 21:56:36 2014 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 26 Feb 2014 21:56:36 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <530DD219.6010001@CC.UniVie.ac.at> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> <20140226054212.GQ21395@x28.adm.denic.de> <530DD219.6010001@CC.UniVie.ac.at> Message-ID: <20140226205636.GB6012@srv03.cluenet.de> On Wed, Feb 26, 2014 at 12:38:01PM +0100, Wilfried Woeber wrote: > I am wondering how German Citizens are dealing with the fact that *many* > Hotels and other accomodation businesses *require* to take a copy of an > official ID Document, in many cases due to local regulations to establish > and track identity of travellers? Most Germans probably don't know that they violate the law when copying personal ID cards (not do most really care about data protection). I refuse to let people take copies of my ID card. I wasn't sent away yet in any hotel. Revenue trumps convenience (I never heard of any legislation requiring to take COPIES of ID cards... but some hotel receptions try to speed up filling out forms by just copying the ID card). > Or is this law only applicable to German Citizens being physically present > in Germany? I'm not aware of any such constraints, that would make no sense. And again: as personal ID copy is not the ONLY means NCC is "offering", it's a non-issue. Please please don't focus on this aspect, it's a non-problem. The real problem is the lack of alternatives that are compliant to data protection principles and not unduely burdensome. As some folks put it: we're not dealing with nuclear launch codes here. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From sander at steffann.nl Fri Feb 28 17:14:36 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 28 Feb 2014 17:14:36 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <62C0179F-8721-408E-AE0E-C1F2AAE69664@rfc1035.com> Message-ID: <30789BC4-3A80-43D4-860F-737FB136BC18@steffann.nl> Hi, > I'm not sure there's a justifiable case for the NCC to hold copies of passports and what have you AT ALL. Or verifying the bona fides of those documents either. Before we get lost in possible ways of determining the identity of a person let's go back to the policy text. The following text is from RIPE-452: "The intention of this policy document is to ensure that the RIPE NCC, as the intermediate manager of provider independent resource assignments to End Users, can confirm that the End User exists, continues to exist and that they continue to fulfil their obligations to comply with the original assignment conditions. This position can be ensured by the presence of either an indirect or a direct contractual link between the End User and the RIPE NCC." and "The preferred model of the RIPE community is for End Users to have contractual relationship with a sponsoring LIR instead of directly with the RIPE NCC." My personal interpretation of RIPE-452 is that an End User having a contract with a sponsoring LIR satisfies the policy. The NCC verifying that the contract is in place by asking a copy of the contract from the Sponsoring LIR seems reasonable, but the NCC requiring a copy of identification papers seems to go beyond what the policy text says. As several people have already stated the NCC cannot verify the accuracy of that copy anyway. I could make a photocopy of my sister's passport and request resources in her name, and the NCC cannot know that I don't look like the picture on the passport. Even more interesting, this example on the website of the Dutch Ministry of Internal Affairs still seems valid if you don't look too closely at the social security number :-) https://www.bprbzk.nl/Reisdocumenten/Echtheidskenmerken/Model_2011/Nederlandse_reisdocumenten/Reisdocumenten/Nationaal_paspoort/Nationaal_paspoort_binnenzijde. Or maybe this one: http://glmb1949.webs.com/Dibujo.JPG. Google knows a lot of passports :) Looking at "Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data": that directive states that personal data must be "adequate, relevant and not excessive in relation to the purposes for which they are collected and/or further processed". I think the example given above already violates the first word: 'adequate'. The NCC has no way of verifying that the copy of the ID belongs to the person requesting the resources, so the personal data is not adequate for the purpose. Only the LIR can be in the position to verify the identity of the person requesting the resources, so the NCC has no choice but to rely on the LIR to do a proper job. If the NCC cannot rely on this then maybe that part of the chain should get fixed/strengthened. The NCC having a copy of some ID only seems to provide a fake level of certainty as far as I can see... So, now, a question to the working group: as this is the address policy working group, is the current policy what we want? Should it indeed be interpreted as 'the Sponsoring LIR verifies the identity of the End User, not the NCC' or is my interpretation of the English language a bit off here? If it turns out that we do want the NCC to play an active role in verifying the identities of End Users, then we can look at how to adjust the policy to clearly state that and work together with the NCC to look for viable solutions to that problem. But I think we should first determine if there is a problem to be solved. Thanks, Sander From mueller at syr.edu Fri Feb 28 18:27:30 2014 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 28 Feb 2014 17:27:30 +0000 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: <20140226205636.GB6012@srv03.cluenet.de> References: <53090F77.8000303@inex.ie> <20140222221725.GC21395@x28.adm.denic.de> <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> <20140226054212.GQ21395@x28.adm.denic.de> <530DD219.6010001@CC.UniVie.ac.at> <20140226205636.GB6012@srv03.cluenet.de> Message-ID: -----Original Message----- > I refuse to let people take copies of my ID card. I wasn't sent > away yet in any hotel. Just FYI, I have been. In Brussels. From dr at cluenet.de Fri Feb 28 19:32:36 2014 From: dr at cluenet.de (Daniel Roesen) Date: Fri, 28 Feb 2014 19:32:36 +0100 Subject: [address-policy-wg] Post Ident / Post Brief In-Reply-To: References: <530CB0CC.1080204@ripe.net> <20140225185558.GQ43641@Space.Net> <530D1407.7030909@schiefner.de> <20140225222449.GB32400@cilantro.c4inet.net> <20140226054212.GQ21395@x28.adm.denic.de> <530DD219.6010001@CC.UniVie.ac.at> <20140226205636.GB6012@srv03.cluenet.de> Message-ID: <20140228183236.GA15040@srv03.cluenet.de> On Fri, Feb 28, 2014 at 05:27:30PM +0000, Milton L Mueller wrote: > > I refuse to let people take copies of my ID card. I wasn't sent > > away yet in any hotel. > > Just FYI, I have been. In Brussels. Let us know with whom not to make business with, thanks. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0