From enumvoipsip.cs at schiefner.de Wed Jan 9 18:11:18 2008 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 09 Jan 2008 18:11:18 +0100 Subject: [enum-wg] Save the date: German ENUM day on 18 April 2008 Message-ID: <47850036.2080906@schiefner.de> Dear ENUM colleagues - first of all, a happy new year to all of you! Secondly, you may want to earmark the 18 April of your calendar: DENIC, Germany's ENUM registry for 9.4.e164.arpa, will hold its 10th ENUM Day on that Friday. There is no agenda yet, I'll send another email as soon as it will become available. Best regards, Carsten Schiefner From enumvoipsip.cs at schiefner.de Wed Jan 9 18:31:23 2008 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 09 Jan 2008 18:31:23 +0100 Subject: [enum-wg] Delegation of +255/5.5.2.e164.arpa completed Message-ID: <478504EB.8080402@schiefner.de> Dear colleagues, the ENUM delegation request for 5.5.2.e164.arpa - +255 is Tanzania's E.164 CC - was confirmed by ITU-T TSB on 8 Jan 2008. As per the same day, 5.5.2.e164.arpa is delegated to nic.co.tz. [41.222.56.189] ns1.satwise.com. [83.170.73.2] 5.5.2.e164.arpa becomes the 45th ENUM delegation. Furthermore, Tanzania is the first African country that receives an ENUM delegation - by this, ENUM has become truly global: there are delegations in place for countries on all five continents now. Welcome, Tanzania ! :-) Best regards, Carsten Schiefner (RIPE ENUM WG Co-Chair) From anandb at ripe.net Thu Jan 17 15:56:22 2008 From: anandb at ripe.net (Anand Buddhdev) Date: Thu, 17 Jan 2008 15:56:22 +0100 Subject: [enum-wg] Name "ripe" in the e164.arpa zone Message-ID: <200801171556.22356.anandb@ripe.net> Dear Colleagues, A question has been raised on why the resource record "ripe.e164.arpa" exists in the e164.arpa zone. Our DNS provisioning tools, which read the information held in objects in the RIPE Database and generate the appropriate DNS zone files, create this extra name "ripe" in the zone for the benefit of the other Regional Internet Registries (RIRs). The provisioning system generates zone files mainly for the in-addr.arpa zones, and some address ranges from one /8 allocation are actually allocated to other registries. So each registry generates "zonelets" that are transferred to the majority RIR of a particular /8. The tools that transfer these zonelets rely on this extra piece of information in the TXT record for consistency checks. Similarly, AfriNIC, ARIN and APNIC also generate zones for their /8 allocations with records named "afrinic", "arin" and "apnic". The e164.arpa zone does not really need this "ripe" record in it, since it is not shared among the registries in any way. However, because the e164.arpa zone is generated automatically from the RIPE Database by the same tools, it automatically receives this extra name. Currently, there is no way to stop the zone receiving this extra entry. But it has no negative effect on the zone or on ENUM operations. Regards, -- Anand Buddhdev DNS Services Manager RIPE NCC From jim at rfc1035.com Thu Jan 17 16:55:04 2008 From: jim at rfc1035.com (Jim Reid) Date: Thu, 17 Jan 2008 15:55:04 +0000 Subject: [enum-wg] Name "ripe" in the e164.arpa zone In-Reply-To: <200801171556.22356.anandb@ripe.net> References: <200801171556.22356.anandb@ripe.net> Message-ID: <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> On Jan 17, 2008, at 14:56, Anand Buddhdev wrote: > The tools that transfer these zonelets rely on this extra piece of > information in the TXT record for consistency checks. Similarly, > AfriNIC, ARIN and APNIC also generate zones for their /8 allocations > with records named "afrinic", "arin" and "apnic". > > The e164.arpa zone does not really need this "ripe" record in it, > since > it is not shared among the registries in any way. However, because the > e164.arpa zone is generated automatically from the RIPE Database by > the > same tools, it automatically receives this extra name. Currently, > there > is no way to stop the zone receiving this extra entry. But it has no > negative effect on the zone or on ENUM operations. Hmmm. This smells like a bug. Why are the DNS provisioning tools for e164.arpa generating data that isn't needed and inserting that data into the DNS? I wonder what will happen if the ITU one day decides that "ripe.e164.arpa" should be delegated to someone.... From brett at blacksunsystems.co.uk Thu Jan 17 19:50:55 2008 From: brett at blacksunsystems.co.uk (brett) Date: Thu, 17 Jan 2008 19:50:55 +0100 Subject: [enum-wg] Name "ripe" in the e164.arpa zone Message-ID: <43BBF1BCE4348E438657C3EA440CCE121255@dc-exch.blacksun.localnet> > -----Original Message----- > From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf Of > Jim Reid > Sent: Thursday, January 17, 2008 3:55 PM > To: Anand Buddhdev > Cc: enum-wg at ripe.net > Subject: Re: [enum-wg] Name "ripe" in the e164.arpa zone > > On Jan 17, 2008, at 14:56, Anand Buddhdev wrote: > > > The tools that transfer these zonelets rely on this extra piece of > > information in the TXT record for consistency checks. Similarly, > > AfriNIC, ARIN and APNIC also generate zones for their /8 allocations > > with records named "afrinic", "arin" and "apnic". > > > > The e164.arpa zone does not really need this "ripe" record in it, > > since > > it is not shared among the registries in any way. However, because the > > e164.arpa zone is generated automatically from the RIPE Database by > > the > > same tools, it automatically receives this extra name. Currently, > > there > > is no way to stop the zone receiving this extra entry. But it has no > > negative effect on the zone or on ENUM operations. > > Hmmm. This smells like a bug. Why are the DNS provisioning tools for > e164.arpa generating data that isn't needed and inserting that data > into the DNS? Hmmm don't think I would define it as a bug as it is I believe intended behaviour. > I wonder what will happen if the ITU one day decides > that "ripe.e164.arpa" should be delegated to someone.... Don't think this would cause a problem would it, as this is only a TXT record I think it could quite happily co-exist with some NS records. I do take your point though Jim and I'm sure if the community members feel strongly enough the NCC would consider looking into how difficult it would be to remove this record from the e164.arpa zone Brett (Speaking as a NON NCC person) From info at streamservice.nl Thu Jan 17 19:44:53 2008 From: info at streamservice.nl (Stream Service || Mark Scholten) Date: Thu, 17 Jan 2008 19:44:53 +0100 Subject: [enum-wg] Name "ripe" in the e164.arpa zone In-Reply-To: <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> References: <200801171556.22356.anandb@ripe.net> <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> Message-ID: <90E5B9C70301474D9466FCEB15C392B3@laptopmark> At the moment ripe.e164.arpa is needed they will made a fix for it, making a fix before that moment isn't needed if you ask me. With kind regards, Met vriendelijke groet, Mark Scholten Stream Service Web: http://www.streamservice.nl/ E-mail: mark at streamservice.nl NOC: http://www.mynoc.eu/ NOC e-mail: noc at streamservice.nl Tel.: +31 (0)642 40 86 02 KVK: 08141074 BTW: NL104278274B01 ----- Original Message ----- From: "Jim Reid" To: "Anand Buddhdev" Cc: Sent: Thursday, January 17, 2008 4:55 PM Subject: Re: [enum-wg] Name "ripe" in the e164.arpa zone On Jan 17, 2008, at 14:56, Anand Buddhdev wrote: > The tools that transfer these zonelets rely on this extra piece of > information in the TXT record for consistency checks. Similarly, > AfriNIC, ARIN and APNIC also generate zones for their /8 allocations > with records named "afrinic", "arin" and "apnic". > > The e164.arpa zone does not really need this "ripe" record in it, > since > it is not shared among the registries in any way. However, because the > e164.arpa zone is generated automatically from the RIPE Database by > the > same tools, it automatically receives this extra name. Currently, > there > is no way to stop the zone receiving this extra entry. But it has no > negative effect on the zone or on ENUM operations. Hmmm. This smells like a bug. Why are the DNS provisioning tools for e164.arpa generating data that isn't needed and inserting that data into the DNS? I wonder what will happen if the ITU one day decides that "ripe.e164.arpa" should be delegated to someone.... From john+ietf at jck.com Fri Jan 18 01:06:47 2008 From: john+ietf at jck.com (John C Klensin) Date: Thu, 17 Jan 2008 19:06:47 -0500 Subject: [enum-wg] Name "ripe" in the e164.arpa zone In-Reply-To: <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> References: <200801171556.22356.anandb@ripe.net> <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> Message-ID: --On Thursday, 17 January, 2008 15:55 +0000 Jim Reid wrote: > > Hmmm. This smells like a bug. Why are the DNS provisioning > tools for e164.arpa generating data that isn't needed and > inserting that data into the DNS? I wonder what will happen if > the ITU one day decides that "ripe.e164.arpa" should be > delegated to someone.... If they did, I trust RIPE NCC would reject the request/ decision and do so loudly because (i) the authorizing documents only authorize RIPE NCC to install delegations for numeric zones associated with E.164 codes and (ii) since requests for delegations are not permitted to originate with the ITU but only with parties who want to operate such zones, such a "decision" on the part of the ITU would be invalid on its face. So "what would happen" is nothing, plus or minus a small dust-up on the way to "nothing". john From Marco.Davids at sidn.nl Fri Jan 18 13:43:10 2008 From: Marco.Davids at sidn.nl (Marco Davids) Date: Fri, 18 Jan 2008 13:43:10 +0100 Subject: [enum-wg] Name "ripe" in the e164.arpa zone Message-ID: > > The tools that transfer these zonelets rely on this extra piece of > > information in the TXT record for consistency checks. > Hmmm. This smells like a bug. Why are the DNS provisioning tools for > e164.arpa generating data that isn't needed and inserting that data > into the DNS? What else is new? Look for 'VRSN-END-OF-ZONE-MARKER-DUMMY-RECORD' in . http://en.wikipedia.org/wiki/Vrsn-end-of-zone-marker-dummy-record.root There is one in the .arpa zone as well: http://www.robert.net/ccTLD/ARPA/ (okay I agree, this domain name is a little bit longer than just 'ripe') -- Marco From paf at cisco.com Sun Jan 20 11:39:14 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sun, 20 Jan 2008 11:39:14 +0100 Subject: [enum-wg] Name "ripe" in the e164.arpa zone In-Reply-To: <43BBF1BCE4348E438657C3EA440CCE121255@dc-exch.blacksun.localnet> References: <43BBF1BCE4348E438657C3EA440CCE121255@dc-exch.blacksun.localnet> Message-ID: <1D7733CD-3B4E-433C-BF08-871A92D5A6C6@cisco.com> On 17 jan 2008, at 19.50, brett wrote: >> I wonder what will happen if the ITU one day decides >> that "ripe.e164.arpa" should be delegated to someone.... > > Don't think this would cause a problem would it, as this is only a TXT > record I think it could quite happily co-exist with some NS records. No, as it in that case should reside in the child zone, and not parent zone. That said, I am on the same side as John and others regarding this issue. Patrik From Ed.Lewis at neustar.biz Sun Jan 20 15:08:01 2008 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Sun, 20 Jan 2008 09:08:01 -0500 Subject: [enum-wg] Name "ripe" in the e164.arpa zone In-Reply-To: <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> References: <200801171556.22356.anandb@ripe.net> <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> Message-ID: >Hmmm. This smells like a bug. Yes but there are bigger bugs in the world to deal with. I advocate allowing the operators decide when and if they want to get rid of it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From lendl at nic.at Sun Jan 20 22:49:04 2008 From: lendl at nic.at (Otmar Lendl) Date: Sun, 20 Jan 2008 22:49:04 +0100 Subject: [enum-wg] Name "ripe" in the e164.arpa zone In-Reply-To: References: <200801171556.22356.anandb@ripe.net> <2B7803E0-6E0C-42A6-ACDB-4E845CE39FF5@rfc1035.com> Message-ID: <20080120214903.GA24253@nic.at> On 2008/01/20 15:01, Edward Lewis wrote: > > >Hmmm. This smells like a bug. > > Yes but there are bigger bugs in the world to deal with. > > I advocate allowing the operators decide when and if they want to get > rid of it. Same here. I'm confident that RIPE NCC will find a solution if this ever becomes an issue. Right now, I don't see the need to waste more time and electrons on this. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg From bhoeneis at switch.ch Mon Jan 21 17:06:53 2008 From: bhoeneis at switch.ch (Bernie Hoeneisen) Date: Mon, 21 Jan 2008 17:06:53 +0100 (CET) Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? Message-ID: Hi! One again the nameservers for 9.3.164.arpa. are currently not reachable, at least not from AS 559. My SIP / ENUM users run into timeouts....:-( Anybody else diagnosing the same with the Italien ENUM nameservers? What is the solution space to prevent this unfortunate situation in future? cheers, Bernie From jim at rfc1035.com Mon Jan 21 17:41:26 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 21 Jan 2008 16:41:26 +0000 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: References: Message-ID: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> On Jan 21, 2008, at 16:06, Bernie Hoeneisen wrote: > One again the nameservers for 9.3.164.arpa. are currently not > reachable > > Anybody else diagnosing the same with the Italien ENUM nameservers? Yup: shaun% dig @62.101.92.173 9.3.e164.arpa soa ;; reply from unexpected source: 89.97.171.129#23, expected 62.101.92.173#53 ;; reply from unexpected source: 89.97.171.129#23, expected 62.101.92.173#53 shaun% dig @62.101.92.174 9.3.e164.arpa soa ;; reply from unexpected source: 89.97.171.129#1, expected 62.101.92.174#53 ;; reply from unexpected source: 89.97.171.129#1, expected 62.101.92.174#53 > What is the solution space to prevent this unfortunate situation in > future? Same as it's always been Bernie. The Tier 1 registry for +39 should beef up its DNS infrastructure, for example by buying DNS service from a reliable hosting provider. It is particularly disappointing that the 9.3.e164.arpa zone seems to delegated to just two name servers that live on the same subnet. RFC2182 advised against this 11 years ago. From bhoeneis at switch.ch Mon Jan 21 17:55:57 2008 From: bhoeneis at switch.ch (Bernie Hoeneisen) Date: Mon, 21 Jan 2008 17:55:57 +0100 (CET) Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> Message-ID: Hi Jim Thanks for confirming this. On Mon, 21 Jan 2008, Jim Reid wrote: > Same as it's always been Bernie. The Tier 1 registry for +39 should beef up > its DNS infrastructure, for example by buying DNS service from a reliable > hosting provider. Would Ripe have the possibility to (temporarly) remove the delegation, if such situations occur? Unfortunately, it happens quite often with Italy....:-( > It is particularly disappointing that the 9.3.e164.arpa zone seems to > delegated to just two name servers that live on the same subnet. RFC2182 > advised against this 11 years ago. Could it even be that these two IP addresses point to the same (physical) host? (Both IPs report at the same time nameserver down, but hosts up.) cheers, Bernie From info at streamservice.nl Mon Jan 21 18:15:50 2008 From: info at streamservice.nl (Stream Service || Mark Scholten) Date: Mon, 21 Jan 2008 18:15:50 +0100 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> Message-ID: Hi Bernie, It is possible that there is only 1 physical host. Also the best thing is to have nameservers in different subnets and different networks (where possible even different buildings). I don't know the RFC numbers. 2 nameservers are enough if they are on different locations and different networks and different subnets however. With kind regards, Met vriendelijke groet, Mark Scholten Stream Service Web: http://www.streamservice.nl/ E-mail: mark at streamservice.nl NOC: http://www.mynoc.eu/ NOC e-mail: noc at streamservice.nl Tel.: +31 (0)642 40 86 02 KVK: 08141074 BTW: NL104278274B01 ----- Original Message ----- From: "Bernie Hoeneisen" To: "Jim Reid" Cc: "RIPE ENUM WG" Sent: Monday, January 21, 2008 5:55 PM Subject: Re: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? Hi Jim Thanks for confirming this. On Mon, 21 Jan 2008, Jim Reid wrote: > Same as it's always been Bernie. The Tier 1 registry for +39 should beef > up > its DNS infrastructure, for example by buying DNS service from a reliable > hosting provider. Would Ripe have the possibility to (temporarly) remove the delegation, if such situations occur? Unfortunately, it happens quite often with Italy....:-( > It is particularly disappointing that the 9.3.e164.arpa zone seems to > delegated to just two name servers that live on the same subnet. RFC2182 > advised against this 11 years ago. Could it even be that these two IP addresses point to the same (physical) host? (Both IPs report at the same time nameserver down, but hosts up.) cheers, Bernie From john+ietf at jck.com Mon Jan 21 18:25:42 2008 From: john+ietf at jck.com (John C Klensin) Date: Mon, 21 Jan 2008 12:25:42 -0500 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> Message-ID: <284FD6197EBAE4239EB41EF7@p3.JCK.COM> --On Monday, 21 January, 2008 17:55 +0100 Bernie Hoeneisen wrote: > On Mon, 21 Jan 2008, Jim Reid wrote: > >> Same as it's always been Bernie. The Tier 1 registry for +39 >> should beef up its DNS infrastructure, for example by buying >> DNS service from a reliable hosting provider. > > Would Ripe have the possibility to (temporarly) remove the > delegation, if such situations occur? Unfortunately, it > happens quite often with Italy....:-( > >> It is particularly disappointing that the 9.3.e164.arpa zone >> seems to delegated to just two name servers that live on the >> same subnet. RFC2182 advised against this 11 years ago. Hi. Under principles that go back much longer than even RFC 2182 (as does the principle of separated name servers -- 2182 just reaffirmed an old principle and stated it more clearly), a registry should be able to remove a zone if it is consistently poorly administered. Given the circumstances of e164.arpa, I think actually doing that would require a discussion between RIPE NCC and the IAB. But I see no reason why it should not be possible to reach consensus on a mechanism for notifying a Tier 1 registry that, if they do not manage to establish servers that do not fate-share, the zone delegation will be removed until they develop and implement a plan. john From jim at rfc1035.com Mon Jan 21 20:14:08 2008 From: jim at rfc1035.com (Jim Reid) Date: Mon, 21 Jan 2008 19:14:08 +0000 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> Message-ID: <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> On Jan 21, 2008, at 16:55, Bernie Hoeneisen wrote: > Would Ripe have the possibility to (temporarly) remove the > delegation, if such situations occur? Personally speaking, I think this a very bad idea. It makes some sort of sense from a technical and operational perspective. But it's the start of a very slippery slope. Who gets to decide what criteria justify pulling a delegation? And why only for e164.arpa? IIUC, the RIRs don't yank the delegations for reverse zones that have broken DNS. And IANA doesn't do this for TLDs that have lame delegations or dead name servers. I also think it's extremely unwise to involve the NCC in any sort of subjective or qualitative decisions about the contents of e164.arpa. This touches on prickly topics like National Sovereignty that are best avoided. IMO the NCC should stick to the remit that's documented in the exchanges of letters between IAB, ITU and the NCC. In other words, it pretty much just does what the ITU asks them to do. :-) As John says, a mechanism could be developed to notify a Tier-1 registry (and ITU?) about a broken ENUM delegation. But this is probably a discussion for the Powers That Be. It wouldn't hurt I suppose for this WG to suggest a suitable mechanism. Any volunteers? BTW, does anyone ask Verisign to pull the plug on lamedelegation.com (say) because its broken delegation is causing operational problems for their mail server? If not, why is a different approach necessary in e164.arpa for ENUM-aware SIP servers? From john+ietf at jck.com Mon Jan 21 20:37:12 2008 From: john+ietf at jck.com (John C Klensin) Date: Mon, 21 Jan 2008 14:37:12 -0500 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> Message-ID: <45BB6A47A6DF4FCEC98508ED@p3.JCK.COM> --On Monday, 21 January, 2008 19:14 +0000 Jim Reid wrote: >... > BTW, does anyone ask Verisign to pull the plug on > lamedelegation.com (say) because its broken delegation is > causing operational problems for their mail server? If not, > why is a different approach necessary in e164.arpa for > ENUM-aware SIP servers? Jim, While I'm not sure that pulling delegations in e164.arpa is a good idea -- I'm merely suggesting that it is feasible if the community wants it-- I don't think the above analogy applies at all. If someone goes to a registrar and registers a label to be placed in COM, no assertion at all is being made (any more) about what that label points to (or doesn't). The assumption is that, if the label lasts long enough, the registrant will pay some token amount of money, but that is about it. The other assumption is that there is nothing sparce, in the technical sense, about the namespace. You can probably remember when the NIC would threaten to pull delegations for sufficient misbehavior, but those days are long past. By contrast, e164.arpa was rather carefully constructed on the theory that the namespace was highly restricted and tied to some very specific concepts and rules. There was a recent thread about labels in the zone that didn't represent E.164 codes. Whether those that represent an administrative convenience are worth the trouble it would take to eliminate them remains a question, but there is no question that they are invalid as the zone is formally designed and specified. The whole purpose of having e164.arpa involved having a validated set of operators whose validation included national signoff about appropriateness and involved that in order that users and systems could trust (modulo the issues that DNSSEC is supposed to address) what they found in that zone. Put differently, the registrants in e164.arpa are there because they are validated and authorized, while a registrant in COM is there because they promise to put a few currency-units on the table. It seems to me that the same things that drive a "validated and authorized" model into e164.arpa could be used to justify a somewhat stronger set of rules to protect the user base than has generally been the expectation for ICANN-delegated gTLDs. For many of the same reasons, I could imagine IAB and RIPE NCC imposing a _requirement_ for signed zones on Tier 1 delegates from e164.arpa, making schedules in conjunction with some consensus among the Tier 1 registries, and holding those registries to those schedules. Again, whether there is consensus for doing any of these things, and whether they are a good idea, are separate issues. But analogies with what a registry does or does not do in a gTLD don't help illuminate the issues, IMO. john From lendl at nic.at Mon Jan 21 22:52:29 2008 From: lendl at nic.at (Otmar Lendl) Date: Mon, 21 Jan 2008 22:52:29 +0100 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> Message-ID: <20080121215229.GA25198@nic.at> On 2008/01/21 20:01, Jim Reid wrote: > On Jan 21, 2008, at 16:55, Bernie Hoeneisen wrote: > > >Would Ripe have the possibility to (temporarly) remove the > >delegation, if such situations occur? > > Personally speaking, I think this a very bad idea. I'm very reluctant to go that route, too. > As John says, a mechanism could be developed to notify a Tier-1 > registry (and ITU?) about a broken ENUM delegation. But this is > probably a discussion for the Powers That Be. It wouldn't hurt I > suppose for this WG to suggest a suitable mechanism. Any volunteers? >From the top of my head, I'd go for a procedure something like this:: * RIPE NCC monitors the nameservers it delegates to. * If serious troubles are spotted, RIPE NCC will notify the Tier1 registry using the email addresses listed as contacts. * If the communication attempts are not answered or the addresses bounce, then RIPE NCC will notify ITU about this fact. * ITU should then basically redo the verification step, asking the local authorities whether the delegation is ok (incl. giving the option for an update to the contact info). If the answer is yes, keep the delegation, if no, instruct RIPE to yank it. * If the Tier1 operators answer, but don't manage to fix the?r nameservers within a longer interval, then also invoke the ITU as above. ---- ?MHO active monitoring and alerts on troubles should be trivial to set up. No special NCC magic dust is needed for that at all, basically anybody could do that. There is no private data involved. Making sure that the contact information is valid should also a no-brainer. In this case, most other registries reserve the right to yank the delegation, so there are precedents here. But in this case, redoing the ITU loop is IMHO the best way to balance national sovereignty with some semblance of "we care for the DNS quality under e164.arpa". /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg From richard at shockey.us Mon Jan 21 20:40:00 2008 From: richard at shockey.us (Richard Shockey) Date: Mon, 21 Jan 2008 14:40:00 -0500 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> Message-ID: <027c01c85c65$6a78e7e0$3f6ab7a0$@us> In line > -----Original Message----- > From: enum-wg-admin at ripe.net [mailto:enum-wg-admin at ripe.net] On Behalf > Of Jim Reid > Sent: Monday, January 21, 2008 2:14 PM > To: Bernie Hoeneisen > Cc: RIPE ENUM WG > Subject: Re: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? > > On Jan 21, 2008, at 16:55, Bernie Hoeneisen wrote: > > > Would Ripe have the possibility to (temporarly) remove the > > delegation, if such situations occur? > > Personally speaking, I think this a very bad idea. It makes some sort > of sense from a technical and operational perspective. But it's the > start of a very slippery slope. Who gets to decide what criteria > justify pulling a delegation? And why only for e164.arpa? IIUC, the > RIRs don't yank the delegations for reverse zones that have broken > DNS. And IANA doesn't do this for TLDs that have lame delegations or > dead name servers. > > I also think it's extremely unwise to involve the NCC in any sort of > subjective or qualitative decisions about the contents of e164.arpa. > This touches on prickly topics like National Sovereignty that are > best avoided. IMO the NCC should stick to the remit that's documented > in the exchanges of letters between IAB, ITU and the NCC. In other > words, it pretty much just does what the ITU asks them to do. :-) I agree completely ... we've been there - done that. Even thinking of opening up that can of worms means someone gets to camp in Geneva for the duration and it isn't going to be me. There will be enough problems/issues when the Infrastructure ENUM documents arrive in Geneva shortly. It is my understanding that that an appropriate liaison statement on the Infrastructure ENUM documents from the IAB to ITU SG-2 is due before IETF Philadelphia. > > As John says, a mechanism could be developed to notify a Tier-1 > registry (and ITU?) about a broken ENUM delegation. But this is > probably a discussion for the Powers That Be. It wouldn't hurt I > suppose for this WG to suggest a suitable mechanism. Any volunteers? I think the bigger question is, given the lack of economic progress and viability in e164.arpa deployments, does anyone care? > > BTW, does anyone ask Verisign to pull the plug on lamedelegation.com > (say) because its broken delegation is causing operational problems > for their mail server? If not, why is a different approach necessary > in e164.arpa for ENUM-aware SIP servers? From paf at cisco.com Tue Jan 22 08:29:15 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Tue, 22 Jan 2008 08:29:15 +0100 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> Message-ID: <981269A8-93E5-4AB8-8698-0E767305498B@cisco.com> On 21 jan 2008, at 20.14, Jim Reid wrote: > As John says, a mechanism could be developed to notify a Tier-1 > registry (and ITU?) about a broken ENUM delegation. But this is > probably a discussion for the Powers That Be. It wouldn't hurt I > suppose for this WG to suggest a suitable mechanism. Any volunteers? So far the consensus I have seen has been that this "watch" mechanism easily can be an opt-in system where the registry ask someone to notify them. Someone that do the tests the registry think is appropriate. But, as John hinted at, management in e164.arpa is highly sensitive (as we all know) and also ITU-T is involved (not only RIPE NCC and IAB). There is an entity responsible for +39, and that entity has requested/approved a delegation. They are the ones that should keep track off the delegation in cooperation with the DNS operator THEY have chosen. If the DNS operator do not do their job, some clauses hopefully exists in some contract we do not know about that have some clauses that can be used in situations like these. Clauses that in many causes are not used without discussions in court, and possibly civil court cases when people are suing each other. I think neither RIPE NCC, nor ITU and definitely not ENUM wg of RIPE want to be part of such discussions. That said, maybe we in this wg should finalize the document that recommend a registry to "keep track of their delegation -- for example via an opt-in mechanism that check the delegation"? Carsten, was this on your table, or do I remember wrong? Patrik P.S. If the delegation is only to two IP addresses, in the same subnet (which we all know is poor management) what is the chance they would have done the opt-in? Slim, but still not _OUR_ problem. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From bernie.hoeneisen at switch.ch Mon Jan 21 17:05:16 2008 From: bernie.hoeneisen at switch.ch (Bernie Hoeneisen) Date: Mon, 21 Jan 2008 17:05:16 +0100 (CET) Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? Message-ID: Hi! One again the nameservers for 9.3.164.arpa. are currently not reachable, at least not from AS 559. My SIP / ENUM users run into timeouts....:-( Anybody else diagnosing the same with the Italien ENUM nameservers? What is the solution space to prevent this unfortunate situation in future? cheers, Bernie From alexander.mayrhofer at nic.at Mon Jan 21 17:49:46 2008 From: alexander.mayrhofer at nic.at (Alexander Mayrhofer) Date: Mon, 21 Jan 2008 17:49:46 +0100 Subject: AW: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: References: Message-ID: <8BC845943058D844ABFC73D2220D466507112798@nics-mail.sbg.nic.at> > > One again the nameservers for 9.3.164.arpa. are currently not > reachable, at least not from AS 559. My SIP / ENUM users run > into timeouts....:-( > > Anybody else diagnosing the same with the Italien ENUM nameservers? > What is the solution space to prevent this unfortunate > situation in future? Same here. It's a pity that there seem no processes for it ... at least not that i know about. Maybe complaining with the italian regulator so that they talk to the DNS operator... oh, or maybe that wouldn't help too much ... :-/ Does RIPE have an informal channel to the Italians to fix this? Alex From lendl at nic.at Tue Jan 22 17:08:53 2008 From: lendl at nic.at (Otmar Lendl) Date: Tue, 22 Jan 2008 17:08:53 +0100 Subject: I-ENUM status (was: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead?) In-Reply-To: <027c01c85c65$6a78e7e0$3f6ab7a0$@us> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> <027c01c85c65$6a78e7e0$3f6ab7a0$@us> Message-ID: <20080122160852.GA26106@nic.at> On 2008/01/21 20:01, Richard Shockey wrote: > > I agree completely ... we've been there - done that. Even thinking of > opening up that can of worms means someone gets to camp in Geneva for the > duration and it isn't going to be me. There will be enough problems/issues > when the Infrastructure ENUM documents arrive in Geneva shortly. Btw, what is holding up these documents? They've been in the "AD Evaluation::AD Followup" state since Vancouver. /ol -- // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg From john+ietf at jck.com Tue Jan 22 21:29:37 2008 From: john+ietf at jck.com (John C Klensin) Date: Tue, 22 Jan 2008 15:29:37 -0500 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <20080121215229.GA25198@nic.at> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> <20080121215229.GA25198@nic.at> Message-ID: <7E975598D3AD9E88F837D86B@p3.JCK.COM> --On Monday, 21 January, 2008 22:52 +0100 Otmar Lendl wrote: >... > From the top of my head, I'd go for a procedure something like > this:: Otmar, First, if you haven't read Patrik's note yet, please do so first. He and I are in complete agreement, I think. The first stages of getting one of these problems straightened out are to notice the problem, remind the registrant, and then notify whomever requested the delegation. All of that is the fairly ordinary behavior of a registry that is behaving responsibly. And, as others have pointed out, it can be done simply by RIPE NCC sending out a note offering to do these checks as a service, turning things into opt-in. I don't think that requires any approval from anyone. Two observations inline... > * If the communication attempts are not answered or the > addresses bounce, then RIPE NCC will notify ITU about this > fact. > > * ITU should then basically redo the verification step, asking > the local authorities whether the delegation is ok (incl. > giving the option for an update to the contact info). First, remember that RIPE NCC is formally responsible to the IAB for e164.arpa, not to ITU-T. It is not clear that RIPE NCC can ask ITU to review a delegation without authority to do so from the IAB and agreement from the ITU to receive such a request and act on it. Of course, as soon as anyone starts asking ITU-T questions that are not covered exactly by the current procedures, the risks of falling into the trap that Richard Shockley warns about are also very large. We can decide what questions we would like to ask and what actions we would like to request, but only they can decide what questions they are willing to answer and how they are going to interpret them. As Richard says "been there - done that"... and some of us will carry the scars for life. > If the answer is yes, keep the delegation, if no, instruct > RIPE to yank it. > > * If the Tier1 operators answer, but don't manage to fix the?r > nameservers within a longer interval, then also invoke the > ITU as above. But remember that ITU-T is, traditionally (and appropriately) extremely reluctant to give answers to questions that involve a Member State without explicit instructions from the Member State. The original ENUM agreement was written in terms of timeouts that would permit registrations if the Member State did not respond. In practice, ITU-T modified that agreement to create a "nothing happens until the country affirmatively responds" situation by issuing objections to any action for which they did not have such a response. If those precedents are followed, there will never be a "no" answer unless a country is inclined to make a formal announcement that it has lost interest in and wishes to abandon its ENUM delegation. Instead, one could reasonably expect ITU-T to ping the country and ask for confirmation for an update (or for server updates) but then to wait, very patiently and for a very long time if necessary, for an answer. What to do here, if anything, is entirely up to this group, RIPE NCC, and the IAB although, if it involves asking ITU-T to adopt any procedures that are not now in place, I wouldn't hold my breath waiting for them to agree, nor would I predict that they would agree to whatever was asked of them without putting their stamp on it. I would give the following advice if anyone asked me: (1) It is fine to encourage RIPE NCC to make periodic checks of server configuration and accessibility. If the results of those checks are not satisfactory, the delegated party should be notified and ask to fix things. (2) If the delegated party does not respond, it would be fine for RIPE NCC to notify the entity that requested and/or signed off on the delegation and make sure they are aware of the problem and its implications to accessibility and usability of the domain they requested. We have that contact information; using it doesn't need to involve the ITU. (3) Before contemplating any steps beyond that, carefully consider the question of who is being harmed. Bernie, no matter how much your users are being inconvenienced, the real harm is being done to their correspondents in Italy. As Richard points out, ENUM has not been the universal "one single tree in which to look" success we had hoped for and any infrastructure approach will make things worse. Given that, one has to be prepared today for other trees anyway. Perhaps, if the delegated administrators for Slobbovia can't run a domain and/or won't accept suggestions for external secondaries, it is time to route around the problem rather than trying to figure out how to punish them. One such workaround would be to establish enum-slobbovia-workaround.net (or elsewhere) and start accepting free registrations in it by anyone who thinks that they are being hurt. It may be that would send a clear message that the choices are between running the domain better and facing "competition" over which the national telcom entities can not exert any control. That might be enough to get things fixed. If not, it might provide a plausible alternative. Ultimately, if a country-approved entity decides that it doesn't want to offer good DNS service (ENUM or otherwise), energy is probably better put into workarounds than into trying to figure how to punish them or to force them to behave better. john From Niall.oReilly at ucd.ie Tue Jan 22 22:38:07 2008 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 22 Jan 2008 21:38:07 +0000 Subject: [enum-wg] Draft ENUM WG Minutes from RIPE 55 Message-ID: Dear ENUM-WG participants, Draft minutes of the ENUM WG session at RIPE 55 are now available at http://www.ripe.net/ripe/wg/enum/minutes/r55-minutes.html. Please send any corrections to the WG mailing list, to arrive no later than 12:00 UTC on Friday, 8 February next. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From richard at shockey.us Wed Jan 23 03:16:42 2008 From: richard at shockey.us (Richard Shockey) Date: Tue, 22 Jan 2008 21:16:42 -0500 Subject: I-ENUM status (was: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead?) In-Reply-To: <20080122160852.GA26106@nic.at> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> <027c01c85c65$6a78e7e0$3f6ab7a0$@us> <20080122160852.GA26106@nic.at> Message-ID: <0ce101c85d66$0379cb20$0a6d6160$@us> > -----Original Message----- > From: Otmar Lendl [mailto:lendl at labs.nic.at] On Behalf Of Otmar Lendl > Sent: Tuesday, January 22, 2008 11:09 AM > To: Richard Shockey > Cc: 'RIPE ENUM WG' > Subject: I-ENUM status (was: [enum-wg] Italian Nameservers for > 9.3.164.arpa. dead?) > > On 2008/01/21 20:01, Richard Shockey wrote: > > > > I agree completely ... we've been there - done that. Even thinking > of > > opening up that can of worms means someone gets to camp in Geneva > for the > > duration and it isn't going to be me. There will be enough > problems/issues > > when the Infrastructure ENUM documents arrive in Geneva shortly. > > Btw, what is holding up these documents? They've been in the > "AD Evaluation::AD Followup" state since Vancouver. You are asking me to explain what goes on in the minds of the IESG? I'm just middle management. :-) There were certainly some technical issues that had to be resolved and the IESG did need to formally present a report to the IAB on what the issues have been. It is my understanding that those issues have been resolved and that an appropriate liaison statement to the ITU-T is being prepared at this time. > > /ol > -- > // Otmar Lendl , T: +43 1 5056416 - 33, F: - 933 > // nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H > // http://www.nic.at/ LG Salzburg, FN 172568b, Sitz: Salzburg From richard at shockey.us Wed Jan 23 03:22:41 2008 From: richard at shockey.us (Richard Shockey) Date: Tue, 22 Jan 2008 21:22:41 -0500 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <7E975598D3AD9E88F837D86B@p3.JCK.COM> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> <20080121215229.GA25198@nic.at> <7E975598D3AD9E88F837D86B@p3.JCK.COM> Message-ID: <0ce201c85d66$d689c6a0$839d53e0$@us> > > >... > > From the top of my head, I'd go for a procedure something like > > this:: > > Otmar, > > First, if you haven't read Patrik's note yet, please do so > first. He and I are in complete agreement, I think. John we are all in agreement here. The first > stages of getting one of these problems straightened out are to > notice the problem, remind the registrant, and then notify > whomever requested the delegation. All of that is the fairly > ordinary behavior of a registry that is behaving responsibly. > And, as others have pointed out, it can be done simply by RIPE > NCC sending out a note offering to do these checks as a service, > turning things into opt-in. I don't think that requires any > approval from anyone. Exactly. > > Two observations inline... > > > * If the communication attempts are not answered or the > > addresses bounce, then RIPE NCC will notify ITU about this > > fact. > > > > * ITU should then basically redo the verification step, asking > > the local authorities whether the delegation is ok (incl. > > giving the option for an update to the contact info). > > First, remember that RIPE NCC is formally responsible to the IAB > for e164.arpa, not to ITU-T. It is not clear that RIPE NCC can > ask ITU to review a delegation without authority to do so from > the IAB and agreement from the ITU to receive such a request and > act on it. > > Of course, as soon as anyone starts asking ITU-T questions that > are not covered exactly by the current procedures, the risks of > falling into the trap that Richard Shockley warns about are also > very large. We can decide what questions we would like to ask > and what actions we would like to request, but only they can > decide what questions they are willing to answer and how they > are going to interpret them. As Richard says "been there - > done that"... and some of us will carry the scars for life. This is one of those issues where "let sleeping dogs lie". > > > If the answer is yes, keep the delegation, if no, instruct > > RIPE to yank it. > > > > * If the Tier1 operators answer, but don't manage to fix the?r > > nameservers within a longer interval, then also invoke the > > ITU as above. > > But remember that ITU-T is, traditionally (and appropriately) > extremely reluctant to give answers to questions that involve a > Member State without explicit instructions from the Member > State. The original ENUM agreement was written in terms of > timeouts that would permit registrations if the Member State did > not respond. In practice, ITU-T modified that agreement to > create a "nothing happens until the country affirmatively > responds" situation by issuing objections to any action for > which they did not have such a response. Exactly > > If those precedents are followed, there will never be a "no" > answer unless a country is inclined to make a formal > announcement that it has lost interest in and wishes to abandon > its ENUM delegation. Instead, one could reasonably expect ITU-T > to ping the country and ask for confirmation for an update (or > for server updates) but then to wait, very patiently and for a > very long time if necessary, for an answer. > > What to do here, if anything, is entirely up to this group, RIPE > NCC, and the IAB although, if it involves asking ITU-T to adopt > any procedures that are not now in place, I wouldn't hold my > breath waiting for them to agree, nor would I predict that they > would agree to whatever was asked of them without putting their > stamp on it. I would give the following advice if anyone asked > me: > > (1) It is fine to encourage RIPE NCC to make periodic > checks of server configuration and accessibility. If > the results of those checks are not satisfactory, the > delegated party should be notified and ask to fix things. > > (2) If the delegated party does not respond, it would be > fine for RIPE NCC to notify the entity that requested > and/or signed off on the delegation and make sure they > are aware of the problem and its implications to > accessibility and usability of the domain they > requested. We have that contact information; using it > doesn't need to involve the ITU. > > (3) Before contemplating any steps beyond that, > carefully consider the question of who is being harmed. > Bernie, no matter how much your users are being > inconvenienced, the real harm is being done to their > correspondents in Italy. As Richard points out, ENUM > has not been the universal "one single tree in which to > look" success we had hoped for and any infrastructure > approach will make things worse. Given that, one has to > be prepared today for other trees anyway. Perhaps, if > the delegated administrators for Slobbovia can't run a > domain and/or won't accept suggestions for external > secondaries, it is time to route around the problem > rather than trying to figure out how to punish them. > One such workaround would be to establish > enum-slobbovia-workaround.net (or elsewhere) and start > accepting free registrations in it by anyone who thinks > that they are being hurt. It may be that would send a > clear message that the choices are between running the > domain better and facing "competition" over which the > national telcom entities can not exert any control. > That might be enough to get things fixed. If not, it > might provide a plausible alternative. > > Ultimately, if a country-approved entity decides that it doesn't > want to offer good DNS service (ENUM or otherwise), energy is > probably better put into workarounds than into trying to figure > how to punish them or to force them to behave better. Right and if you want real problems ICANN will probably want to stick their nose into all of this and that is the LAST thing anyone wants. IAB or ITU. > > john From bhoeneis at switch.ch Wed Jan 23 11:40:21 2008 From: bhoeneis at switch.ch (Bernie Hoeneisen) Date: Wed, 23 Jan 2008 11:40:21 +0100 (CET) Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: <7E975598D3AD9E88F837D86B@p3.JCK.COM> References: <64C80683-F323-4F99-A630-3CE43857AFDA@rfc1035.com> <687871A2-E4A2-42FB-B8B4-77D1BE12D62B@rfc1035.com> <20080121215229.GA25198@nic.at> <7E975598D3AD9E88F837D86B@p3.JCK.COM> Message-ID: Hi John et al. I agree with most of your statements. Comments inline. On Tue, 22 Jan 2008, John C Klensin wrote: > (3) Before contemplating any steps beyond that, > carefully consider the question of who is being harmed. > Bernie, no matter how much your users are being > inconvenienced, the real harm is being done to their > correspondents in Italy. As far as I know 9.3.e164.arpa has never been populated and so far there has been no intension to actually establish an ENUM service within 9.3.e164.arpa. (Therefore, my collegues in Italy from the Research and Education community are using the nrenum.net tree as an interim solution until an ENUM service in 9.3.e164.arpa. becomes available). Thus, the only ones suffering from this particular problem are the calling users (due to timeouts). > it is time to route around the problem Usually I tackle problems at the source... But you are right, in this case it is worth considering a workaround e.g. modify some software or configuration, to prevent queries for 9.3.e164.arpa. at all. > rather than trying to figure out how to punish them. If my assumptions stated above are correct, I don't see any punishment in case the delegation for 9.3.e164.arpa. would be removed. (However, I see the point that removing a zone is a rather problematic and slippery way to address this issue.) cheers, Bernie From marco.sommani at iit.cnr.it Wed Jan 23 13:25:06 2008 From: marco.sommani at iit.cnr.it (Marco Sommani) Date: Wed, 23 Jan 2008 13:25:06 +0100 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: Message-ID: What Bernie is saying is correct: whatever RIPE does with the Italian delegation, there will be no negative consequences for ENUM users. This morning I have found that the two Italian DNS servers are still up and alive. The problem is that their name is no longer dns.istsupcti.it and dns2.istsupcti.it, as indicated in the delegation, but dns.isticom.it and dns2.isticom.it. If you send a query about 9.3.e164.arpa directly to one of those two servers, you get the correct answer. I do not know why they decided to change their domain name, as the name of the institution is still "Istituto Superiore delle Comunicazioni e delle Tecnologie dell'Informazione", as it used to be. Anyway, the domain istsupcti.it is dead: even www.istsupcti.it is not responding anymore, whereas www.isticom.it does. A further problem is due to the fact that the contact person that is mentioned in the RIPE database, Luisa Franchina, left the Ministry of Communications more than one year ago. This being said, I do not know what is the right procedure to follow in these cases. Maybe RIPE should ask the ITU the permission to change appropriately the domain names in the DNS delegations? Marco On 23-01-2008 11:40, "Bernie Hoeneisen" wrote: > Hi John et al. > > I agree with most of your statements. Comments inline. > > On Tue, 22 Jan 2008, John C Klensin wrote: > >> (3) Before contemplating any steps beyond that, >> carefully consider the question of who is being harmed. >> Bernie, no matter how much your users are being >> inconvenienced, the real harm is being done to their >> correspondents in Italy. > > As far as I know 9.3.e164.arpa has never been populated and so far there > has been no intension to actually establish an ENUM service within > 9.3.e164.arpa. (Therefore, my collegues in Italy from the Research and > Education community are using the nrenum.net tree as an interim solution > until an ENUM service in 9.3.e164.arpa. becomes available). > > Thus, the only ones suffering from this particular problem are the calling > users (due to timeouts). > >> it is time to route around the problem > > Usually I tackle problems at the source... > > But you are right, in this case it is worth considering a workaround e.g. > modify some software or configuration, to prevent queries for > 9.3.e164.arpa. at all. > >> rather than trying to figure out how to punish them. > > If my assumptions stated above are correct, I don't see any punishment > in case the delegation for 9.3.e164.arpa. would be removed. > (However, I see the point that removing a zone is a rather > problematic and slippery way to address this issue.) > > > cheers, > Bernie > ----------------------------------------------- Marco Sommani Consiglio Nazionale delle Ricerche Istituto di Informatica e Telematica Via Giuseppe Moruzzi 1 56124 Pisa - Italia work: +390503153815 (PSTN and nrenum.net) mobile: +393487981019 (PSTN and e164.org) fax: +390503153273 sip:marco.sommani at iit.cnr.it mailto:marco.sommani at iit.cnr.it From paf at cisco.com Wed Jan 23 14:45:23 2008 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Wed, 23 Jan 2008 14:45:23 +0100 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: References: Message-ID: <62DEAFEB-0140-4FBC-9536-1EE3632FD29C@cisco.com> On 23 jan 2008, at 13.25, Marco Sommani wrote: > This being said, I do not know what is the right procedure to follow > in > these cases. Maybe RIPE should ask the ITU the permission to change > appropriately the domain names in the DNS delegations? The organisation responsible for the zone 9.3.e164.arpa is to ask RIPE NCC to change the delegation accordingly (or withdraw the delegation). If you want to help initiating this event personally, you should contact them, i.e. the responsible organisation. Not RIPE NCC. Patrik -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From jaap at NLnetLabs.nl Wed Jan 23 14:50:18 2008 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 23 Jan 2008 14:50:18 +0100 Subject: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead? In-Reply-To: Your message of Wed, 23 Jan 2008 13:25:06 +0100. Message-ID: <200801231350.m0NDoI5v006731@bartok.nlnetlabs.nl> Suggestions from the bad idea fairy: Anyway, the domain istsupcti.it is dead: even www.istsupcti.it is not responding anymore, whereas www.isticom.it does. According to http://www.nic.it/cgi-bin/Whois/whois-eng.cgi, the domain still exists. That is it didn, what one you could do is to register the domain istsupcti.it. Then you can take over the delegation. The domain expires 2008-09-20, so after that date it is free game. jaap