From andreev.peter at gmail.com Fri Apr 1 12:10:17 2011 From: andreev.peter at gmail.com (Peter Andreev) Date: Fri, 1 Apr 2011 14:10:17 +0400 Subject: [enum-wg] Help with enum docs Message-ID: Hello, list! I'm very new in enum and need some help in docs understanding. I can't understand following parts of rfc 3403: "Collision Avoidance: In the case where two Applications may use this Database (which is actually the case with the ENUM and URI Resolution Applications, Section 6.2), there is a chance of collision between rules where two NAPTR records appear in the same domain but they apply to more than one Application." And " * create a new zone within the domain in common that contains only NAPTR records that are appropriate for the application. E.g., all URI Resolution records would exist under urires.example.com and all ENUM records would be under enum.example.com. In the case where this is not possible due to lack of control over the upstream delegation the second method is used." Could someone provide me with examples of such collision and its resolution? Thanks in advance. -- -- AP From jim at rfc1035.com Fri Apr 1 13:19:00 2011 From: jim at rfc1035.com (Jim Reid) Date: Fri, 1 Apr 2011 12:19:00 +0100 Subject: [enum-wg] Help with enum docs In-Reply-To: References: Message-ID: On 1 Apr 2011, at 11:10, Peter Andreev wrote: > Could someone provide me with examples of such collision and its > resolution? The answer is already in the text you quoted. There may be several NAPTR records for some domain name. RFC3403 calls this a collision. An application will do a lookup for that name, get a bunch of NAPTRs back and then have to make a decision about which ones are of interest. This can entail a bit of crunching on the DNS response: regexp rewriting, chasing non-terminal NAPTRs, order and preference handling, etc. This might be painful in some cases. In others, it's just an irritant. The DNS does not provide a way of saying "please only send me the mailto: NAPTRs for this name" or "send me all the D2U NAPTRs for this name, but no E2U (ENUM) ones". So if you want application-specific responses to NAPTR lookups, you need to organise the DNS data in that way and then give the applications a priori knowledge of how you've done that. eg Skype could be told to look for an E2U skype NAPTR for you at skype.peter.example.com instead of peter.example.com and you only put such a NAPTR at that node in the name space. From andreev.peter at gmail.com Fri Apr 1 14:32:13 2011 From: andreev.peter at gmail.com (Peter Andreev) Date: Fri, 1 Apr 2011 16:32:13 +0400 Subject: [enum-wg] Help with enum docs In-Reply-To: References: Message-ID: Jim, thank you for answer. 2011/4/1 Jim Reid : > On 1 Apr 2011, at 11:10, Peter Andreev wrote: > >> Could someone provide me with examples of such collision and its >> resolution? > > The answer is already in the text you quoted. > > There may be several NAPTR records for some domain name. RFC3403 calls this > a collision. An application will do a lookup for that name, get a bunch of > NAPTRs back and then have to make a decision about which ones are of > interest. This can entail a bit of crunching on the DNS response: regexp > rewriting, chasing non-terminal NAPTRs, order and preference handling, etc. > This might be painful in some cases. In others, it's just an irritant. > > The DNS does not provide a way of saying "please only send me the mailto: > NAPTRs for this name" or "send me all the D2U NAPTRs for this name, but no > E2U (ENUM) ones". So if you want application-specific responses to NAPTR > lookups, you need to organise the DNS data in that way and then give the > applications a priori knowledge of how you've done that. eg Skype could be > told to look for an E2U skype NAPTR for you at skype.peter.example.com > instead of peter.example.com and you only put such a NAPTR at that node in > the name space. > > So, from a DNS-provider's point of view a collision may occur in case of "too greedy" NAPTR or while processing non-terminal NAPTR. And resolving of such collision is mostly application-side, not DNS. I mean search for NAPTR in another domains. Are my conclusions right? -- -- AP From jim at rfc1035.com Fri Apr 1 14:48:15 2011 From: jim at rfc1035.com (Jim Reid) Date: Fri, 1 Apr 2011 13:48:15 +0100 Subject: [enum-wg] Help with enum docs In-Reply-To: References: Message-ID: <4373AD51-425B-4D9E-AF7D-D0B11B506834@rfc1035.com> On 1 Apr 2011, at 13:32, Peter Andreev wrote: > So, from a DNS-provider's point of view a collision may occur in case > of "too greedy" NAPTR or while processing non-terminal NAPTR. > And resolving of such collision is mostly application-side, not DNS. I > mean search for NAPTR in another domains. > Are my conclusions right? Not quite. A DNS provider's job is to serve up resource records on a bunch of name servers that answer queries. They shouldn't care about what those records are. That's a concern for whoever manages the domain where those records are stored. There are many NAPTR collisions: any response that contains more than one NAPTR is a collision. What's in those NAPTRs doesn't matter. If there's more than one of them, you have a collision and this is something for the application to handle. Once upon a time ENUM people mumbled about a resolver: something that sat in between the DNS lookup code and the application and did all the NAPTR record processing: order/preference issues, NTNs, service selectors, etc. This badly named beast would be the thing that dealt with any collisions and made sure the application only got to see the NAPTRs it cared about. I'm not sure what you mean by "search for NAPTR". DNS is a lookup mechanism. It does not do search. And it does not necessarily follow that collision resolution requires further NAPTR lookups. From andreev.peter at gmail.com Fri Apr 1 16:08:13 2011 From: andreev.peter at gmail.com (Peter Andreev) Date: Fri, 1 Apr 2011 18:08:13 +0400 Subject: [enum-wg] Help with enum docs In-Reply-To: <4373AD51-425B-4D9E-AF7D-D0B11B506834@rfc1035.com> References: <4373AD51-425B-4D9E-AF7D-D0B11B506834@rfc1035.com> Message-ID: 2011/4/1 Jim Reid : > On 1 Apr 2011, at 13:32, Peter Andreev wrote: > >> So, from a DNS-provider's point of view a collision may occur in case >> of "too greedy" NAPTR or while processing non-terminal NAPTR. >> And resolving of such collision is mostly application-side, not DNS. I >> mean search for NAPTR in another domains. >> Are my conclusions right? > > Not quite. A DNS provider's job is to serve up resource records on a bunch > of name servers that answer queries. They shouldn't care about what those > records are. That's a concern for whoever manages the domain where those > records are stored. > > There are many NAPTR collisions: any response that contains more than one > NAPTR is a collision. What's in those NAPTRs doesn't matter. If there's more > than one of them, you have a collision and this is something for the > application to handle. > > Once upon a time ENUM people mumbled about a resolver: something that sat in > between the DNS lookup code and the application and did all the NAPTR record > processing: order/preference issues, NTNs, service selectors, etc. This > badly named beast would be the thing that dealt with any collisions and made > sure the application only got to see the NAPTRs it cared about. Hmm, I thought ENUM resolver is just the same as ordinary DNS caching server. What the main difference between them? > > I'm not sure what you mean by "search for NAPTR". DNS is a lookup mechanism. > It does not do search. And it does not necessarily follow that collision > resolution requires further NAPTR lookups. > -- -- AP From jim at rfc1035.com Fri Apr 1 16:36:05 2011 From: jim at rfc1035.com (Jim Reid) Date: Fri, 1 Apr 2011 15:36:05 +0100 Subject: [enum-wg] more enum resolver confusion In-Reply-To: References: <4373AD51-425B-4D9E-AF7D-D0B11B506834@rfc1035.com> Message-ID: On 1 Apr 2011, at 15:08, Peter Andreev wrote: >> Once upon a time ENUM people mumbled about a resolver: something >> that sat in >> between the DNS lookup code and the application and did all the >> NAPTR record >> processing: order/preference issues, NTNs, service selectors, etc. >> This >> badly named beast would be the thing that dealt with any collisions >> and made >> sure the application only got to see the NAPTRs it cared about. > > Hmm, I thought ENUM resolver is just the same as ordinary DNS > caching server. > What the main difference between them? I hoped that had been clearly explained in the paragraph above. Obviously not. Oh well... The (hypothetical?) ENUM resolver would be some code that spoke to a stub resolver that made DNS lookups and had an API to whatever applications wanted to avoid doing NAPTR record processing for themselves. It was/is exceptionally stupid to call this middleware thing a resolver. Because it isn't one. That unfortunate choice of terminology creates needless confusion with DNS resolution. Sigh. This so-called "resolver" is actually a NAPTR record processor/filter that sits *above* some DNS API but *below* the application. This bit of middleware does not get involved in DNS resolution, apart from maybe making more NAPTR lookups if it has to go chasing a chain of NTNs. It does not disrupt or interfere with the usual DNS model of stub resolvers talking to resolving (cacheing) name servers talking to authoritative name servers. From andreev.peter at gmail.com Sat Apr 2 11:03:34 2011 From: andreev.peter at gmail.com (Peter Andreev) Date: Sat, 2 Apr 2011 13:03:34 +0400 Subject: [enum-wg] Re: more enum resolver confusion In-Reply-To: References: <4373AD51-425B-4D9E-AF7D-D0B11B506834@rfc1035.com> Message-ID: 2011/4/1 Jim Reid : > On 1 Apr 2011, at 15:08, Peter Andreev wrote: > >>> Once upon a time ENUM people mumbled about a resolver: something that sat >>> in >>> between the DNS lookup code and the application and did all the NAPTR >>> record >>> processing: order/preference issues, NTNs, service selectors, etc. This >>> badly named beast would be the thing that dealt with any collisions and >>> made >>> sure the application only got to see the NAPTRs it cared about. >> >> Hmm, I thought ENUM resolver is just the same as ordinary DNS caching >> server. >> What the main difference between them? > > I hoped that had been clearly explained in the paragraph above. Obviously > not. Oh well... The (hypothetical?) ENUM resolver would be some code that > spoke to a stub resolver that made DNS lookups and had an API to whatever > applications wanted to avoid doing NAPTR record processing for themselves. > > It was/is exceptionally stupid to call this middleware thing a resolver. > Because it isn't one. That unfortunate choice of terminology creates > needless confusion with DNS resolution. Sigh. > > This so-called "resolver" is actually a NAPTR record processor/filter that > sits *above* some DNS API but *below* the application. This bit of > middleware does not get involved in DNS resolution, apart from maybe making > more NAPTR lookups if it has to go chasing a chain of NTNs. It does not > disrupt or interfere with the usual DNS model of stub resolvers talking to > resolving (cacheing) name servers talking to authoritative name servers. > Now I see my mistake. Jim, thank you for patience and explanation. -- -- AP From Niall.oReilly at ucd.ie Fri Apr 8 10:56:00 2011 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 08 Apr 2011 09:56:00 +0100 Subject: [enum-wg] Fwd: [enum-announce] Fw: NCC#2011034400 [RE: [ENUM request form for 351 (PT)]] Message-ID: <4D9ECDA0.3080705@ucd.ie> This will be one to watch, as FCCN has been a leading participant in NRENUM, and has created a significant customer base for ENUM in that context. Congratulations to Lino and all the team at FCCN! -------- Original Message -------- Subject: [enum-announce] Fw: NCC#2011034400 [RE: [ENUM request form for 351 (PT)]] Date: Fri, 08 Apr 2011 09:46:14 +0200 From: RIPE NCC Staff Reply-To: RIPE NCC Staff To: enum-announce at ripe.net ----- Begin forwarded message ----- Date: Wed, 6 Apr 2011 17:47:58 +0200 From: To: Subject: RE: NCC#2011034400 [ENUM request form for 351 (PT)] Message-Id: The TSB confirms that the attached request for ENUM delegation of code 351 has been authorized by the concerned national Administration and the delegation may proceed when RIPE NCC receives formal confirmation from the Director of TSB. Richard Hill ----------------------------------- Richard Hill Counsellor, ITU-T SG2 and SG3, and CWG-WCIT International Telecommunication Union Place des Nations CH-1211 Geneva 20 Switzerland tel +41 22 730 5887 FAX +41 22 730 5853 E-Mail: richard.hill at itu.int > -----Original Message----- > From: RIPE NCC Staff [mailto:enum-request at ripe.net] > Sent: Tuesday, 05 April, 2011 11:43 > To: Hill, Richard; enum-announce at ripe.ne > Subject: Fw: NCC#2011034400 [ENUM request form for 351 (PT)] > > ----- Begin forwarded message ----- > > Date: Tue, 29 Mar 2011 12:18:40 +0100 > From: Lino Santos > To: enum-request at ripe.net > Subject: NCC#2011034400 ENUM request form for 351 (PT) > Cc: gcp at enum.org.pt > Message-Id: <4D91C010.9040406 at fccn.pt> > > > Dear Sirs, > > please find enclosed the Portuguese ENUM request form. > > FCCN (Fundacao para a Computacao Cientifica Nacional) has been > appointed by ICP-ANACOM, the portuguese telecomunications regulator, > to > run as PT ENUM Tyer 1 registry. > > Please notice that the zone 1.5.3.e164.arpa is DNSSEC signed: > 1.5.3.e164.arpa. IN DS 24523 5 1 > 1BFDE09392675F75790AE4775A2F72D0464D2A49 > 1.5.3.e164.arpa. IN DS 24523 5 2 > BC46E8261D9FF200C6342F06F475CC0ED40812A5FC8BDF913F2D1118 CABB4431 > > Thanks in advance, > Lino Santos. > ENUM Request Form RIPE NCC Doc-ID: ripe-384 Date: August 2006 % ENUM Request Form % You can use this form to request ENUM delegation of an E.164 country code. % Submit the completed form to . % Please see ripe-385 for instructions on how to complete this form. #[GENERAL INFORMATION]# % % Please do not change the value of the two fields below. request-type: enum form-version: 1.0 #[REQUESTER DETAILS]# % % Please add your contact details. name: Lino Santos phone: +351218440100 fax-no: +351218472167 e-mail: lino at fccn.pt #[ORGANISATION DETAILS]# % % Which organisation is requesting the delegation? legal-organisation-name: FCCN (Fundacao para a Computacao Cientifica Nacional) organisation-location: Lisbon website: http://www.fccn.pt #[DATABASE TEMPLATE]# % % Please complete all of the fields below. domain: 1.5.3.e164.arpa descr: PT ENUM domain name org: ORG-FpaC1-RIPE admin-c: PV50 tech-c: ANG77-RIPE zone-c: ANG77-RIPE nserver: ns-enum.dns.pt nserver: ns2.dns.pt nserver: sns-pb.isc.org mnt-by: AS1930-MNT changed: hostmaster at ripe.net source: RIPE #[SUPPLEMENTAL COMMENTS]# % % Please add more information if you think it will help us understand % this request. FCCN (Fundacao para a Computacao Cientifica Nacional)has been appointed by ICP-ANACOM, the portuguese telecomunications regulator, to run as PT ENUM Tyer 1 registry. Please notice that the zone 1.5.3.e164.arpa is DNSSEC signed: 1.5.3.e164.arpa. IN DS 24523 5 1 1BFDE09392675F75790AE4775A2F72D0464D2A49 1.5.3.e164.arpa. IN DS 24523 5 2 BC46E8261D9FF200C6342F06F475CC0ED40812A5FC8BDF913F2D1118 CABB4431 #[END of REQUEST]# ------ End forwarded message ------ ------ End forwarded message ------ From Niall.oReilly at ucd.ie Tue Apr 12 12:10:32 2011 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 12 Apr 2011 11:10:32 +0100 Subject: [enum-wg] RIPE 62: Updated Draft agenda for ENUM WG session Message-ID: Dear ENUM WG colleagues and RIPE NCC Meeting Team, I am happy to send you an updated draft agenda for the ENUM WG session at RIPE 62. I've removed a mysterious "tba" item D3, and added a short news item "+351" F3. As usual, I expect we'll confirm the agenda at the start of the session; this leaves some scope for squeezing in any late proposals for items of urgent interest. I'm looking forward to seeing very many of you in Amsterdam. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM WG DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT Draft Agenda, ENUM WG at RIPE-62 14:00 Thursday, 5 May 2011, NH Grand Hotel Krasnapolsky, Amsterdam, Netherlands A: Administrivia (5 min) Welcome, Scribe, Jabberwok, Microphone etiquette, Agenda B: Finalize Minutes of ENUM-WG at RIPE 61, Rome (2 min) https://www.ripe.net/ripe/groups/wg/enum/minutes/ripe-61 C: Review Action List (3 min) ENUM-AP-61.1 - Niall O'Reilly, Carsten Schiefner and Peter Koch to clarify point from RIPE 60 minutes. ENUM-AP-61.2 - Carsten Schiefner to get more information on NRENUM. ENUM-AP-61.3 - Denesh Bhabuta to organise a panel. D: Main presentations (45 min) D1: NRENUM (Peter Szegedi, 20 min) D2: ENUM and +1800 (Pavel Tuma, 15 min) ... E: ENUM Operations E1: Tier-0 Report (Anand Buddhev, 15 min) ... F: Short News F1: enumdata.org update (Niall O'Reilly, 5 min) F2: .cz ENUM (Pavel Tuma, 10 min) F3: +351 (PT) delegation (5 min) G: Discussion on Plenary presentation: [Placeholder for 'G': nothing planned this time] X: Interaction with other working groups Y: AOB Z: Close (5 min) Summary of action items -- 15:30 Coffee -- From Niall.oReilly at ucd.ie Thu Apr 21 11:42:51 2011 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 21 Apr 2011 10:42:51 +0100 Subject: [enum-wg] RIPE 62: Updated Draft agenda for ENUM WG session Message-ID: Dear ENUM WG colleagues and RIPE NCC Meeting Team, With just over a week to go before RIPE 62, here is a freshly updated draft agenda for the ENUM WG session I'm looking forward to seeing very many of you in Amsterdam. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM WG DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT Draft Agenda, ENUM WG at RIPE-62 14:00 Thursday, 5 May 2011, NH Grand Hotel Krasnapolsky, Amsterdam, Netherlands A: Administrivia (5 min) Welcome, Scribe, Jabberwok, Microphone etiquette, Agenda B: Minutes of revious meetings B1: Finalize Minutes of ENUM-WG at RIPE 60, Prague (1 min) https://www.ripe.net/ripe/groups/wg/enum/minutes/ripe-60 B2: Finalize Minutes of ENUM-WG at RIPE 61, Rome (2 min) https://www.ripe.net/ripe/groups/wg/enum/minutes/ripe-61 C: Review Action List (2 min) ENUM-AP-61.1 - [DONE] Niall O'Reilly, Carsten Schiefner and Peter Koch to clarify point from RIPE 60 minutes. ENUM-AP-61.2 - [DONE] Carsten Schiefner to get more information on NRENUM. ENUM-AP-61.3 - [remains OPEN] Denesh Bhabuta to organise a panel. D: Main presentations (45 min) D1: NRENUM (Peter Szegedi, 20 min) D2: ENUM and +1800 (Pavel Tuma, 15 min) D3: IETF ENUM work complete (Bernie Hoeneisen, 10 min) E: ENUM Operations E1: Tier-0 Report (Wolfgang Nagele, 15 min) F: Short News F1: enumdata.org update (Niall O'Reilly, 5 min) F2: .cz ENUM (Pavel Tuma, 10 min) F3: +351 (PT) delegation (5 min) G: Discussion on Plenary presentation: [Placeholder for 'G': nothing planned this time] X: Interaction with other working groups Y: AOB Z: Close (5 min) Summary of action items -- 15:30 Coffee -- From webmaster at ripe.net Thu Apr 21 12:20:03 2011 From: webmaster at ripe.net (Alix Guillard) Date: Thu, 21 Apr 2011 12:20:03 +0200 Subject: [enum-wg] Re: [ripe.net #1018009] RIPE 62: Updated Draft agenda for ENUM WG session In-Reply-To: <4DB004D1.1030306@ripe.net> References: <4DB004D1.1030306@ripe.net> Message-ID: Hi Niall, On 21/04/2011 11:42, Niall O'Reilly wrote: > > Dear ENUM WG colleagues and RIPE NCC Meeting Team, > > With just over a week to go before RIPE 62, here is a freshly updated > draft agenda for the ENUM WG session page updated: http://ripe62.ripe.net/programme/meeting-plan/enum cheers, -- Alix Guillard RIPE NCC Webmaster - http://ripe.net/ From enumvoipsip.cs at schiefner.de Thu Apr 21 14:02:34 2011 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 21 Apr 2011 14:02:34 +0200 Subject: [enum-wg] RIPE 62: Updated Draft agenda for ENUM WG session In-Reply-To: References: Message-ID: <4DB01CDA.7060004@schiefner.de> Dear all, On 21.04.2011 11:42, Niall O'Reilly wrote: > I'm looking forward to seeing very many of you in Amsterdam. it is with deep regret that I have to tell you that I can't make it to Amsterdam this time - in particular when I look at the posted agenda for the ENUM WG session. Due to the preponement of RIPE 62 by two weeks(?) at the end of last year the meeting is now in conflict with DENIC's AGM that very week that as a board member I just have to attend. I wish you all a good RIPE 62 and in particular an interesting WG session. Best regards - and happy Easter: Carsten Schiefner Co-Chair, RIPE ENUM WG > DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT -- DRAFT > > Draft Agenda, ENUM WG at RIPE-62 > > 14:00 Thursday, 5 May 2011, > NH Grand Hotel Krasnapolsky, Amsterdam, Netherlands > > A: Administrivia (5 min) > Welcome, Scribe, Jabberwok, Microphone etiquette, Agenda > > B: Minutes of revious meetings > B1: Finalize Minutes of ENUM-WG at RIPE 60, Prague (1 min) > https://www.ripe.net/ripe/groups/wg/enum/minutes/ripe-60 > B2: Finalize Minutes of ENUM-WG at RIPE 61, Rome (2 min) > https://www.ripe.net/ripe/groups/wg/enum/minutes/ripe-61 > > C: Review Action List (2 min) > ENUM-AP-61.1 - [DONE] Niall O'Reilly, Carsten Schiefner and Peter Koch to > clarify point from RIPE 60 minutes. > ENUM-AP-61.2 - [DONE] Carsten Schiefner to get more information on NRENUM. > ENUM-AP-61.3 - [remains OPEN] Denesh Bhabuta to organise a panel. > > D: Main presentations (45 min) > D1: NRENUM (Peter Szegedi, 20 min) > D2: ENUM and +1800 (Pavel Tuma, 15 min) > D3: IETF ENUM work complete (Bernie Hoeneisen, 10 min) > > E: ENUM Operations > E1: Tier-0 Report (Wolfgang Nagele, 15 min) > > F: Short News > F1: enumdata.org update (Niall O'Reilly, 5 min) > F2: .cz ENUM (Pavel Tuma, 10 min) > F3: +351 (PT) delegation (5 min) > > G: Discussion on Plenary presentation: > [Placeholder for 'G': nothing planned this time] > > X: Interaction with other working groups > > Y: AOB > > Z: Close (5 min) > Summary of action items > > -- 15:30 Coffee -- From anandb at ripe.net Thu Apr 21 14:43:35 2011 From: anandb at ripe.net (Anand Buddhdev) Date: Thu, 21 Apr 2011 14:43:35 +0200 Subject: [enum-wg] PGP Key-Signing Party at RIPE 62 Message-ID: <4DB02677.3040504@ripe.net> Dear colleagues, During RIPE 62, we will have a PGP Key-Signing Party, on Tuesday, 3 May at 17:30 in the Seasons Room at the Krasnapolsky Hotel. If you'd like to participate, please see the following page for details on how to sign up for it: http://ripe62.ripe.net/programme/social-events/pgp-key-signing-party Regards, Anand Buddhdev RIPE NCC