From denis at ripe.net Tue Apr 5 13:45:32 2011 From: denis at ripe.net (Denis Walker) Date: Tue, 05 Apr 2011 13:45:32 +0200 Subject: [ncc-services-wg] Deletion of Forward DOMAIN object data from the RIPE Database Message-ID: <4D9B00DC.5030104@ripe.net> [Apologies for duplicate emails] Dear Colleagues, The RIPE NCC announced to the mailing lists on 29 March that Forward DOMAIN object data will be deleted this week: http://www.ripe.net/ripe/maillists/archives/db-wg/2011/msg00074.html All Forward DOMAIN object data has now been deleted from the RIPE Database, except for the four top-level domain (TLD) operators who are still actively using the RIPE Database. It is not possible for any user to re-create a top-level Forward DOMAIN object in the RIPE Database. Without the TLD object, no second-level DOMAIN object creations can be authorised. When the last four TLD operators have moved their data to their own systems, we will modify the update software so it will not recognise any Forward DOMAIN objects. Regards, Denis Walker RIPE NCC Database Group From bortzmeyer at nic.fr Thu Apr 7 14:38:34 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 7 Apr 2011 14:38:34 +0200 Subject: [ncc-services-wg] Re: Deletion of Forward DOMAIN object data from the RIPE Database In-Reply-To: <4D9B00DC.5030104@ripe.net> References: <4D9B00DC.5030104@ripe.net> Message-ID: <20110407123834.GA1122@nic.fr> On Tue, Apr 05, 2011 at 01:45:32PM +0200, Denis Walker wrote a message of 21 lines which said: > The RIPE NCC announced to the mailing lists on 29 March that Forward > DOMAIN object data will be deleted this week: > http://www.ripe.net/ripe/maillists/archives/db-wg/2011/msg00074.html May I ask why "fr" is not in the list? It should have been deleted as well. % whois -h whois.ripe.net -R fr domain: fr descr: Top-level-domain for France descr: AFNIC (NIC France) descr: Domaine de Voluceau B.P. 105 descr: F-78153 Le Chesnay CEDEX, France refer: RIPE whois.nic.fr 43 admin-c: NFC1-RIPE tech-c: NFC1-RIPE zone-c: NFC1-RIPE nserver: ns1.nic.fr nserver: ns2.nic.fr nserver: ns3.nic.fr ... [Completely outdated and unmaintained] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From bortzmeyer at nic.fr Thu Apr 7 15:46:43 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 7 Apr 2011 15:46:43 +0200 Subject: [ncc-services-wg] Re: Deletion of Forward DOMAIN object data from the RIPE Database In-Reply-To: <20110407123834.GA1122@nic.fr> References: <4D9B00DC.5030104@ripe.net> <20110407123834.GA1122@nic.fr> Message-ID: <20110407134643.GA31393@nic.fr> On Thu, Apr 07, 2011 at 02:38:34PM +0200, Stephane Bortzmeyer wrote a message of 48 lines which said: > May I ask why "fr" is not in the list? It should have been deleted as > well. We just received the notification of deletion. So, apparently, Denis Walker's message was just sent too early. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: Digital signature URL: From denis at ripe.net Thu Apr 7 15:55:21 2011 From: denis at ripe.net (Denis Walker) Date: Thu, 07 Apr 2011 15:55:21 +0200 Subject: [ncc-services-wg] Re: Deletion of Forward DOMAIN object data from the RIPE Database In-Reply-To: <20110407134643.GA31393@nic.fr> References: <4D9B00DC.5030104@ripe.net> <20110407123834.GA1122@nic.fr> <20110407134643.GA31393@nic.fr> Message-ID: <4D9DC249.8090603@ripe.net> Stephane Bortzmeyer wrote: > On Thu, Apr 07, 2011 at 02:38:34PM +0200, > Stephane Bortzmeyer wrote > a message of 48 lines which said: > > >> May I ask why "fr" is not in the list? It should have been deleted as >> well. >> > > We just received the notification of deletion. So, apparently, Denis > Walker's message was just sent too early. > To be honest it was an oversight on our part. We deleted all the Forward DOMAIN objects ending in .TLD. But the TLD object itself has no '.' so they were not deleted. We have now deleted them all (except for the 4 active TLD operators). Thanks for pointing this out. Incidentally, we have also just deleted a small number of invalid reverse DOMAIN objects as well. For example objects ending in 'in-addr-arpa' with a '-' instead of a '.'. Regards Denis Walker Business Analyst RIPE NCC Database Group From Piotr.Strzyzewski at polsl.pl Thu Apr 7 15:19:26 2011 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 7 Apr 2011 15:19:26 +0200 Subject: [ncc-services-wg] Re: [db-wg] Re: Deletion of Forward DOMAIN object data from the RIPE Database In-Reply-To: <20110407123834.GA1122@nic.fr> References: <4D9B00DC.5030104@ripe.net> <20110407123834.GA1122@nic.fr> Message-ID: <20110407131926.GE658@hydra.ck.polsl.pl> On Thu, Apr 07, 2011 at 02:38:34PM +0200, Stephane Bortzmeyer wrote: > On Tue, Apr 05, 2011 at 01:45:32PM +0200, > Denis Walker wrote > a message of 21 lines which said: > > > The RIPE NCC announced to the mailing lists on 29 March that Forward > > DOMAIN object data will be deleted this week: > > http://www.ripe.net/ripe/maillists/archives/db-wg/2011/msg00074.html > > May I ask why "fr" is not in the list? It should have been deleted as > well. > > % whois -h whois.ripe.net -R fr > domain: fr > descr: Top-level-domain for France > descr: AFNIC (NIC France) > descr: Domaine de Voluceau B.P. 105 > descr: F-78153 Le Chesnay CEDEX, France > refer: RIPE whois.nic.fr 43 > admin-c: NFC1-RIPE > tech-c: NFC1-RIPE > zone-c: NFC1-RIPE > nserver: ns1.nic.fr > nserver: ns2.nic.fr > nserver: ns3.nic.fr > ... > > [Completely outdated and unmaintained] It seems that other cc-tld's are also still here. ".pl", ".de", ".cz", ".sk" just for example. Also some strange domain objects like "dnsquery" (taken from ftp DB dump): $ whois -rB -T domain dnsquery domain: dnsquery descr: Reverse delegation admin-c: RB1230-RIPE tech-c: LL271-RIPE zone-c: LL271-RIPE mnt-by: MNT-MNT changed: hostmaster at mynet.it 20050622 source: RIPE Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From mir at ripe.net Tue Apr 12 09:23:18 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 12 Apr 2011 09:23:18 +0200 Subject: [ncc-services-wg] Resource Certification Statistics Message-ID: <4DA3FDE6.7@ripe.net> Dear colleagues, We published some statistics on RIPE Labs that show the number of certificates generated since we launched the service in January 2011: http://labs.ripe.net/Members/AlexBand/resource-certification-statistics Kind Regards, Mirjam Kuehne RIPE NCC From BSanghani at relianceglobalcom.com Tue Apr 12 10:35:45 2011 From: BSanghani at relianceglobalcom.com (Bijal Sanghani) Date: Tue, 12 Apr 2011 09:35:45 +0100 Subject: [ncc-services-wg] Call For Agenda Items RIPE 62 Message-ID: <891E52B6F6F62E4F9376CAA357C17C15D9AEB95F@LON-MBX01.RGCOM.COM> Dear NCC-Services WG, RIPE 62 in Amsterdam is approaching fast and we are looking at putting the agenda together for the NCC Services WG. This is your opportunity to let the RIPE NCC know what you want from them, if you would like to suggest a presentation or raise a topic for discussion please let me know. Kind regards, Bijal Sanghani RIPE NCC Services WG Co-Chair The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Wed Apr 13 10:17:01 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 13 Apr 2011 10:17:01 +0200 Subject: [ncc-services-wg] Resource Certification Web Validator Released Message-ID: <4DA55BFD.9050401@ripe.net> Dear colleagues, The RIPE NCC released a Resource Certification Web Validator. Read more on RIPE Labs: http://labs.ripe.net/Members/AlexBand/resource-certification-web-validator-released Kind Regards, Mirjam Kuehne RIPE NCC From mir at ripe.net Thu Apr 14 12:56:20 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 14 Apr 2011 12:56:20 +0200 Subject: [ncc-services-wg] Next RIPEstat live demo on 19 April 2011 Message-ID: <4DA6D2D4.9090804@ripe.net> [apologies for duplicates] Dear colleagues, The next RIPEstat Live Demo is scheduled for Tuesday, 19 April 2011 at 11:30 - 12:00 Amsterdam time (9:30 - 10:00 UTC). Please observe the change to summer time. I hope you will join us. Details on how to join the demo session can be found on RIPE Labs: http://labs.ripe.net/Members/markd/ripestat-live-demo-4 The minutes of the last sessions and some more information about RIPEstat can be found on RIPE Labs: http://labs.ripe.net/ripestat Kind Regards, Mirjam Kuehne RIPE NCC From no-reply at ripe.net Fri Apr 15 10:08:23 2011 From: no-reply at ripe.net (Axel Pawlik) Date: Fri, 15 Apr 2011 10:08:23 +0200 Subject: [ncc-services-wg] APNIC Announces its IPv4 Address Pool Reaches Final /8 Message-ID: <4DA7FCF7.8090506@ripe.net> [Apologies for duplicate emails] Dear Colleagues, Today, Friday 15 April 2011, APNIC, the Regional Internet Registry (RIR) for the Asia Pacific region, announced that it has distributed the final IPv4 address space from its reserves of IPv4. This means that APNIC is now supplying IPv4 address space to its members from the last /8 it holds according to the guidelines in section 9.10 in "Policies for IPv4 address space management in the Asia Pacific region": http://www.apnic.net/policy/add-manage-policy This event does not affect the RIPE NCC's reserves of IPv4 address space and we will continue to distribute these resources to our members on the basis of need until we reach the last /8. According to RIPE Document ripe-509, section 5.6, once the RIPE NCC reaches the last /8 of IPv4 address space, each Local Internet Registry (LIR) can receive one /22 (1024 IPv4 addresses) upon application for IPv4 resources. In order to obtain this /22 allocation, the LIR must already have an IPv6 allocation and have a demonstrated need for address space. IPv6 - Act Now --------------- The RIPE NCC cannot predict how long its own supply of IPv4 address space will last and has worked for several years to inform all stakeholders of the urgent need to deploy IPv6. It is now imperative that all stakeholders deploy IPv6 on their networks to ensure the continuity of their online operations and the long-term growth of the Internet. For more information on IPv6 and its deployment, advice from experts and where to get training, please see: www.ipv6actnow.org Further Information -------------------- For more information on IPv4 exhaustion, please see: http://www.ripe.net/internet-coordination/ipv4-exhaustion For more information on how the RIPE NCC's last /8 will be distributed, please see: http://www.ripe.net/ripe/docs/ripe-509 For information about the amount of IPv4 address space left in the RIPE NCC's available pool of IPv4, please see the graph online at: http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph Regards, Axel Pawlik Managing Director RIPE NCC From denis at ripe.net Mon Apr 18 11:28:12 2011 From: denis at ripe.net (Denis Walker) Date: Mon, 18 Apr 2011 11:28:12 +0200 Subject: [ncc-services-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects Message-ID: <4DAC042C.1020006@ripe.net> [Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to change the process of creating and updating reverse DOMAIN objects in the RIPE Database. Because this is a proposed RIPE Database change, please direct any discussion to the RIPE Database Working Group mailing list to keep it focused in one place. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to change the dash ('-') notation in reverse DOMAIN objects Introduction ------------ Reverse delegation DOMAIN objects allow the use of a dash ('-') in the syntax. The current arrangement causes problems with DNSSEC. We propose to drop the current behaviour. We would also introduce a new syntax using the dash notation to avoid the need for manual intervention for classless delegations. Both the current and the new behaviour described in this document only apply to IPv4 delegations. Feature to be deprecated ------------------------ Currently, we allow a dash in the third octet of an IPv4 reverse delegation. So, for the address range 10.2.1.0 - 10.2.100.255, the syntax allows a reverse delegation DOMAIN object to be submitted as 1-100.2.10.in-addra.arpa. The RIPE Database update software will expand this into 100 separate objects in the database with prefixes from 1.2.10.in-addra.arpa to 100.2.10.in-addra.arpa. Apart from the prefix, all the other data in the submitted object will be duplicated in all 100 objects. To modify or delete this set of objects, the user has to process all 100 objects individually. No bulk operations are possible after the original object has been expanded in the database. This feature is not compatible with using DNSSEC. The value of the "ds-rdata:" attribute is a hash that includes the delegation. By definition, this must be different for each DOMAIN object. These different hash values for multiple objects cannot be entered by submitting a single object with the dash notation. This issue was raised by members of the DNS community, and the RIPE NCC now proposes to deprecate this update feature. Feature to be added ------------------- Classless delegations, according to RFC2317 (http://www.ietf.org/rfc/rfc2317.txt), are currently handled manually by the DNS Department at the RIPE NCC. Although the objects can be created in the RIPE Database, they will not be propagated to the zone files. The RIPE NCC proposes to allow a dash in the fourth octet of an IPv4 reverse delegation. So, for the address range 10.2.1.6 - 10.2.1.25, the syntax would allow a reverse delegation DOMAIN object to be submitted as 6-25.1.2.10.in-addra.arpa. This object would not be expanded by the RIPE Database update software into 20 separate objects, as it is with the feature described above. It would be created in the database as a single object, including the dash in the range. New DNS provisioning software would handle the new dash notation and propagate this delegation to the zone file. However, the range 0-255 is a special case and would not be allowed in the fourth octet. Modification and deletion can be performed on the single object in the database. Any change would be propagated into the zone file by the new delegation software. From randy at psg.com Mon Apr 18 11:34:16 2011 From: randy at psg.com (Randy Bush) Date: Mon, 18 Apr 2011 18:34:16 +0900 Subject: [ncc-services-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: <4DAC042C.1020006@ripe.net> References: <4DAC042C.1020006@ripe.net> Message-ID: does this not arise from some confusion. that the delegation request object allows a macro that has a dash does not mean any dns objects have a dash. so there is no actual dns problem. or am i confused as usual? randy From terry.manderson at icann.org Mon Apr 18 14:28:40 2011 From: terry.manderson at icann.org (Terry Manderson) Date: Mon, 18 Apr 2011 05:28:40 -0700 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: References: <4DAC042C.1020006@ripe.net> Message-ID: <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> It's not a DNS problem exactly. But since the macro in question can allow a RIPE db user to incorrectly duplicate DS record data for multiple zones, an unsuspecting entrant to the world of DNSSEC will have a rather awkward time. You could argue buyer beware, but off the cuff I see no general issue with trying to remove potential errors before frustration sets in. Cheers, Terry On 18/04/2011, at 7:34 PM, "Randy Bush" wrote: > does this not arise from some confusion. > > that the delegation request object allows a macro that has a dash does > not mean any dns objects have a dash. so there is no actual dns > problem. > > or am i confused as usual? > > randy > From randy at psg.com Mon Apr 18 15:04:41 2011 From: randy at psg.com (Randy Bush) Date: Mon, 18 Apr 2011 22:04:41 +0900 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> Message-ID: > It's not a DNS problem exactly. But since the macro in question can > allow a RIPE db user to incorrectly duplicate DS record data for > multiple zones, an unsuspecting entrant to the world of DNSSEC will > have a rather awkward time. You could argue buyer beware, but off the > cuff I see no general issue with trying to remove potential errors > before frustration sets in. > >> does this not arise from some confusion. >> >> that the delegation request object allows a macro that has a dash does >> not mean any dns objects have a dash. so there is no actual dns >> problem. and we should also prevent folk such as mycroft-jones from asking for dns delegation. brilliant. randy --- Q: Because it reverses the logical flow of conversation. A: Why is top posting frowned upon? From randy at psg.com Mon Apr 18 15:15:27 2011 From: randy at psg.com (Randy Bush) Date: Mon, 18 Apr 2011 22:15:27 +0900 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: <20110418131223.GT30227@Space.Net> References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> <20110418131223.GT30227@Space.Net> Message-ID: > I'm not exactly sure why we want to support > > mycroft-jones.1.0.0.2.ip6.arpa > > in the RIPE DNS tools... or maybe I am misunderstanding something now, > but this whole apparatus is to automate delegation of *reverse* zones, > and those usually don't consist of people's surnames. and the zones do not consist of 120-127.42.66.in-addr.arpa either. the hyphen syntax is a macro in a language that is not in the dns. therefor that it is not acceptable dns syntax is not relevant. randy From gert at space.net Mon Apr 18 15:21:51 2011 From: gert at space.net (Gert Doering) Date: Mon, 18 Apr 2011 15:21:51 +0200 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> <20110418131223.GT30227@Space.Net> Message-ID: <20110418132151.GU30227@Space.Net> Hi, On Mon, Apr 18, 2011 at 10:15:27PM +0900, Randy Bush wrote: > > I'm not exactly sure why we want to support > > > > mycroft-jones.1.0.0.2.ip6.arpa > > > > in the RIPE DNS tools... or maybe I am misunderstanding something now, > > but this whole apparatus is to automate delegation of *reverse* zones, > > and those usually don't consist of people's surnames. > > and the zones do not consist of 120-127.42.66.in-addr.arpa either. > > the hyphen syntax is a macro in a language that is not in the dns. therefor > that it is not acceptable dns syntax is not relevant. So what exactly would be the benefit of delegating all names from "mycroft" to "jones" with this mechanism? Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From gert at space.net Mon Apr 18 15:12:23 2011 From: gert at space.net (Gert Doering) Date: Mon, 18 Apr 2011 15:12:23 +0200 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> Message-ID: <20110418131223.GT30227@Space.Net> Hi, On Mon, Apr 18, 2011 at 10:04:41PM +0900, Randy Bush wrote: > and we should also prevent folk such as mycroft-jones from asking for > dns delegation. brilliant. I'm not exactly sure why we want to support mycroft-jones.1.0.0.2.ip6.arpa in the RIPE DNS tools... or maybe I am misunderstanding something now, but this whole apparatus is to automate delegation of *reverse* zones, and those usually don't consist of people's surnames. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From randy at psg.com Mon Apr 18 15:34:25 2011 From: randy at psg.com (Randy Bush) Date: Mon, 18 Apr 2011 22:34:25 +0900 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: <20110418132151.GU30227@Space.Net> References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> <20110418131223.GT30227@Space.Net> <20110418132151.GU30227@Space.Net> Message-ID: >>> I'm not exactly sure why we want to support >>> >>> mycroft-jones.1.0.0.2.ip6.arpa >>> >>> in the RIPE DNS tools... or maybe I am misunderstanding something now, >>> but this whole apparatus is to automate delegation of *reverse* zones, >>> and those usually don't consist of people's surnames. >> >> and the zones do not consist of 120-127.42.66.in-addr.arpa either. >> >> the hyphen syntax is a macro in a language that is not in the dns. therefor >> that it is not acceptable dns syntax is not relevant. > > So what exactly would be the benefit of delegating all names from > "mycroft" to "jones" with this mechanism? see http://en.wikipedia.org/wiki/Analogy randy From pfaltstr at cisco.com Mon Apr 18 15:57:11 2011 From: pfaltstr at cisco.com (Patrik Faltstrom (pfaltstr)) Date: Mon, 18 Apr 2011 15:57:11 +0200 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: <20110418131223.GT30227@Space.Net> References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> <20110418131223.GT30227@Space.Net> Message-ID: <569D3AB4-6960-4F1E-92BB-3C690BC66ECF@cisco.com> On 18 apr 2011, at 15:34, "Gert Doering" wrote: > those usually don't consist of people's surnames. Well, have you followed the work in zeroconf? Patrik From gert at space.net Mon Apr 18 16:40:35 2011 From: gert at space.net (Gert Doering) Date: Mon, 18 Apr 2011 16:40:35 +0200 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: <569D3AB4-6960-4F1E-92BB-3C690BC66ECF@cisco.com> References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> <20110418131223.GT30227@Space.Net> <569D3AB4-6960-4F1E-92BB-3C690BC66ECF@cisco.com> Message-ID: <20110418144035.GX30227@Space.Net> Hi, On Mon, Apr 18, 2011 at 03:57:11PM +0200, Patrik Faltstrom (pfaltstr) wrote: > On 18 apr 2011, at 15:34, "Gert Doering" wrote: > > > those usually don't consist of people's surnames. > Well, have you followed the work in zeroconf? I haven't, admittedly. Could you point me to the relevant documents? (There's *lots* of work in zeroconf) Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From pfaltstr at cisco.com Mon Apr 18 18:55:45 2011 From: pfaltstr at cisco.com (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 18 Apr 2011 18:55:45 +0200 Subject: [ncc-services-wg] Re: [dns-wg] Re: [db-wg] Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects In-Reply-To: <20110418144035.GX30227@Space.Net> References: <4DAC042C.1020006@ripe.net> <25F5DA5E-713F-4B57-9151-7E9E80F6EAFA@icann.org> <20110418131223.GT30227@Space.Net> <569D3AB4-6960-4F1E-92BB-3C690BC66ECF@cisco.com> <20110418144035.GX30227@Space.Net> Message-ID: On 18 apr 2011, at 16.40, Gert Doering wrote: > On Mon, Apr 18, 2011 at 03:57:11PM +0200, Patrik Faltstrom (pfaltstr) wrote: >> On 18 apr 2011, at 15:34, "Gert Doering" wrote: >> >>> those usually don't consist of people's surnames. >> Well, have you followed the work in zeroconf? > > I haven't, admittedly. Could you point me to the relevant documents? > > (There's *lots* of work in zeroconf) I missed a few thousand smileys...of course NOONE can follow everything in zeroconf... In short, we have things live like this: lb._dns-sd._udp.0.0.168.192.in-addr.arpa. IN PTR example.com. The result is similar to do the same queries in .local TLD (but then most of the time using mDNS). See section 11 of http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt for example. Patrik From alexb at ripe.net Tue Apr 19 17:03:52 2011 From: alexb at ripe.net (Alex Band) Date: Tue, 19 Apr 2011 17:03:52 +0200 Subject: [ncc-services-wg] =?windows-1252?Q?Analysis_of_the_=91Maximum_Length=92_Option_in_?= =?windows-1252?Q?Certification_ROAs?= Message-ID: <95653819-9696-4977-BFA1-884A5854F2F7@ripe.net> [apologies for duplicates] Dear colleagues, We just published an article on RIPE Labs on the usage of the 'Maximum Length' option in ROAs. We compared all the prefixes in the Repository which are covered by a ROA to the prefixes seen by RIS. It gives a good indication how people are using this option, and what the effects are when people base routing decisions on validation results. You can read the article here: https://labs.ripe.net/Members/AlexBand/using-the-maximum-length-option-in-roas Kind regards, Alex Band Product Manager From randy at psg.com Tue Apr 19 21:40:03 2011 From: randy at psg.com (Randy Bush) Date: Wed, 20 Apr 2011 04:40:03 +0900 Subject: [ncc-services-wg] Re: [routing-wg] Analysis of the =?UTF-8?B?4oCYTWF4aW11bSBMZW5n?= =?UTF-8?B?dGjigJk=?= Option in Certification ROAs In-Reply-To: <95653819-9696-4977-BFA1-884A5854F2F7@ripe.net> References: <95653819-9696-4977-BFA1-884A5854F2F7@ripe.net> Message-ID: hi alex, one thing that interests me which i did not see in your analysis. or maybe i just need more coffee. how many, what proportion of, bgp announcements were for prefixes longer than the allocation in the roa and were properly described by a max-len? as to your choices, i would go with 1 or 2 (make it a mandatory blank field, forcing the user to make an explicit decision). 3 and 4 are horrible. randy From denis at ripe.net Wed Apr 20 16:24:49 2011 From: denis at ripe.net (Denis Walker) Date: Wed, 20 Apr 2011 16:24:49 +0200 Subject: [ncc-services-wg] Proposal to Introduce SHA2 Passwords in the RIPE Database Message-ID: <4DAEECB1.9080203@ripe.net> [Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to introduce SHA2 passwords as an authentication method in MNTNER objects in the RIPE Database. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to Introduce SHA2 Passwords in the RIPE Database The RIPE NCC has looked at the possibility of introducing SHA2 as a password algorithm, as requested by AP61.2. >From a technical point of view this is certainly possible. There are C and Java libraries available for generating SHA2 algorithms. We can provide SHA2 as an additional password option alongside MD5. In addition we would also provide a web service to generate SHA2 passwords similar to the one provided for MD5. If the community requires MD5 to be deprecated we would suggest fixing a time period for users to update their MNTNER objects. From the start of that period no MD5 passwords can be added to a MNTNER, but existing ones will remain valid. At the end of that period the RIPE NCC can replace/remove all remaining MD5 passwords. As with the crypt-pw deprecation, we would provide an automated web service to reinstate access to a MNTNER object if you can validate against one of the original MD5 passwords. The time limits used for the crypt-pw deprecation were a 6 month period for users to update their MNTNER objects and a 3 year period to reinstate user access via the web service. From alexb at ripe.net Wed Apr 20 17:49:04 2011 From: alexb at ripe.net (Alex Band) Date: Wed, 20 Apr 2011 17:49:04 +0200 Subject: [ncc-services-wg] =?windows-1252?Q?Re=3A_=5Brouting-wg=5D_Analysis_of_the_=91Maxim?= =?windows-1252?Q?um_Length=92_Option_in_Certification_ROAs?= In-Reply-To: References: <95653819-9696-4977-BFA1-884A5854F2F7@ripe.net> Message-ID: On 19 Apr 2011, at 21:40, Randy Bush wrote: > hi alex, > > one thing that interests me which i did not see in your analysis. or > maybe i just need more coffee. > > how many, what proportion of, bgp announcements were for prefixes longer > than the allocation in the roa and were properly described by a max-len? Good question, let me look into that. Right now the analysis just focussed on the amount of prefixes that would be invalid because of incorrect usage of MaxLength, but it's quite likely a number of ROAs were created simply with /24 as MaxLength to allow for the freedom to deaggregate (or ease of use), when in reality the AS is only announcing a less specific aggregate. > as to your choices, i would go with 1 or 2 (make it a mandatory blank > field, forcing the user to make an explicit decision). 3 and 4 are > horrible. Duly noted. -A From mir at ripe.net Thu Apr 21 15:37:59 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 21 Apr 2011 15:37:59 +0200 Subject: [ncc-services-wg] On RIPE Labs: Mobile Application to access RIPE DB Message-ID: <4DB03337.4060600@ripe.net> [apologies for duplicates] Dear colleagues, The RIPE NCC is working on a mobile application to allow users to access the RIPE Database from a mobile device. Please find more information on RIPE Labs: http://labs.ripe.net/Members/sandrasi/ripe-db-mobile-application Kind Regards, Mirjam Kuehne RIPE NCC From rv at nic.dtag.de Mon Apr 25 23:26:02 2011 From: rv at nic.dtag.de (Ruediger Volk, Deutsche Telekom T-Com - TE141-P1) Date: Mon, 25 Apr 2011 23:26:02 +0200 Subject: [ncc-services-wg] Re: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region) In-Reply-To: Your message of "Tue, 12 Apr 2011 17:15:22 +0200." <20110412151523.228D96A002@postboy.ripe.net> Message-ID: <1339.1303766762@x37.NIC.DTAG.DE> Dear colleagues, > Dear Colleagues, > > Following the feedback received, the draft document for the proposal > described in 2008-08 was edited and published. > > The new impact analysis that was conducted for this proposal has also > been published. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2008-08 > > and the draft document at: > > http://www.ripe.net/ripe/policies/proposals/2008-08/draft > > We encourage you to read the draft document text and send any comments > to address-policy-wg at ripe.net before 26 April 2011. I agree to passing this policy in this (or the previous version 3.0 of 2011-02-09) form. My objection to excluding IPv6 has been taken care of (while I note that the undated NCC certification FAQ anyway tells "... certify their PA address allocations. This includes both IPv4 and IPv6 ...", and ripe-513 dated 2011-02-07 even in the title did know about PA space in IPv6 context). (my mail of Date: Thu, 24 Feb 2011 00:00:40 +0100) I'm not aware what concern or argument has been raised in order to include IPv4 "ALLOCATED UNSPECIFIED"; this inclusion seems to be opposite direction to quickly covering the most simple cases. I'd not be surprised if later on some complications with this hit. I'm NOT seeing this as a show stopper. Beyond these changes my arguments and concerns from the last revision (my mail from Date: Thu, 24 Feb 2011 00:00:40 +0100) essentially still apply - but I did NOT raise them as show stoppers then, and still regard them again as challenges for making required further progress. Looking forward to discuss required and planned activities at RIPE62. It is not easy to track what actually has changed, and a summary of changes actually would seem helpfull for discussing revised proposals; in particular I'm not sure about the 4 related documents. The only one I somewhat accidentally know that it has not changed is the CPS (that's still the one dated 2010-12-30 which is clearly different from the previous draft of 2010-11-01). Is ripe-517 (dated 2011-03-07) the same as the previously referenced draft? What about the two (undated!) terms and conditions documents? Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE From BSanghani at relianceglobalcom.com Tue Apr 26 16:23:30 2011 From: BSanghani at relianceglobalcom.com (Bijal Sanghani) Date: Tue, 26 Apr 2011 15:23:30 +0100 Subject: [ncc-services-wg] Draft Agenda - NCC Services WG RIPE 62 Message-ID: <891E52B6F6F62E4F9376CAA357C17C15D9AEBA64@LON-MBX01.RGCOM.COM> Dear All, Please see below Draft Agenda for the RIPE NCC Services Working Group - RIPE 62 16:00 Wednesday, 4 May 2011 A: Administrative Matters * Welcome * Scribe * Chat monitor * Microphone etiquette * Agenda B. RIPE NCC Update - RIPE NCC Senior Management Team (40 mins) C. Update on the 2007-1 Project - Arne Kiessling (10 mins) D. Resource Certification Update - Alex Band (15 mins) E. Update on RIPE NCC Governance Documents, Transfer Document - Athina Fragkouli (15 minutes) Z. AOB The agenda can also be found online - http://ripe62.ripe.net/programme/meeting-plan/ncc-services Kind regards, Bijal Sanghani The information contained in this e-mail message is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you should return it to the sender immediately. Please note that while we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathalie at ripe.net Thu Apr 28 06:45:02 2011 From: nathalie at ripe.net (Nathalie Trenaman) Date: Thu, 28 Apr 2011 06:45:02 +0200 Subject: [ncc-services-wg] Announcement: New IPv6 information videos available now Message-ID: <0A84DC85-CA85-4F6D-B2D0-0A8E36D21BDD@ripe.net> Dear Colleagues, The RIPE NCC is pleased to announce the launch of four new information videos on real-life IPv6 deployment experiences. The following videos are now available in the RIPE NCC's E-Learning Centre at: http://www.ripe.net/lir-services/training/e-learning/ipv6 - Jan ?or? talks about "Mobile IPv6" - Tore Anderson gives an overview on "IPv6 and Content Providers" - Nuno Viera talks about "IPv6 in Hosting Environments" - Teun Vink is interviewed about "IPv6 and ISPs" The RIPE NCC E-Learning Centre is free and available to everyone. If you have any questions about this, please contact us at . Regards, Nathalie Trenaman Trainer RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: