From lendl at nic.at Mon Nov 6 23:17:35 2006 From: lendl at nic.at (Otmar Lendl) Date: Mon, 6 Nov 2006 23:17:35 +0100 Subject: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt In-Reply-To: <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> References: <20061006070656.GJ15701@nic.at> <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> Message-ID: <20061106221735.GL20763@nic.at> [quick reply to just answer some question on open numbering plans.] On 2006/11/06 22:11, Patrik F?ltstr?m wrote: > On 6 okt 2006, at 00.06, Otmar Lendl wrote: > > >In I-ENUM, Telekom Austria (were they to take part in our trial) would > >use wildcards to direct calls to their ingress point, e.g. by > > > >6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1 at sip.telekom.at! > >*.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1 at sip.telekom.at! > > > >Which records should Telekom Austria provision under your scheme? > > If I understand you correctly, Telekom Austria is running telephony > for the number +43 1 5056416, but then you as a user of that number > can add whatever digits you want as "extensions" as the routing is > prefix based. I presume as long as the number of digits totally is > fewer than 15 :-) Correct. > Can you "port" that prefix from Telekom Austria to someone else? Yes. > Today, as you point out, there should be a zone > 6.1.4.5.0.5.1.3.4.e164.arpa in which you instead of "just" having > NAPTR records for the name of the zone, you have NAPTR for the > extensions you have. > > Example (not open numbering plan): > > 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... > 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... > 6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... > > With open numbering plan: > 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... > 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... > 3.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... > 4.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... > 5.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... Correct. This actually quite efficient as you just have to maintain a single zone for the full PBX and not one per extension. (On the other hand, this s*cks for us as the ENUM registry as we can only sell a single delegation to big corporate PBXs.) > How do you handle number portability for these numbers (that end with > 33, 34 and 35)? Can they be ported one at a time, or just the whole > block at the same time? Porting is only possible at the number level, not on the extension level. For that example, we can take +43 1 5056416 plus all existing extensions to a different operator, but we can't port out individual extensions like +43 1 5056416 33. (This is similar to the email/domain porting question that came up here at the ietf meeting just now: Domains can be "ported", and take all email addresses with them.) > Good discussion, lets continue. Indeed. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > From jaap at NLnetLabs.nl Tue Nov 7 09:57:52 2006 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 07 Nov 2006 09:57:52 +0100 Subject: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt In-Reply-To: Your message of Mon, 06 Nov 2006 13:58:21 -0800. <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> Message-ID: <200611070857.kA78vqHi081358@open.nlnetlabs.nl> On 6 okt 2006, at 00.06, Otmar Lendl wrote: > The IETF enum list seems to be broken, This is not the first time I've seen this claim. However, how this list seems to be broken is never specified. Did you checked the archives whether it really didn't make the list? What was the response of the list software when you send something that didn't make the list? When did "the list" broke? Your list maintainers want to know what is going on so they can correct this. Just repeating that the list is broken is unproductive. jaap From lendl at nic.at Wed Nov 8 00:00:13 2006 From: lendl at nic.at (Otmar Lendl) Date: Wed, 8 Nov 2006 00:00:13 +0100 Subject: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt In-Reply-To: <200611070857.kA78vqHi081358@open.nlnetlabs.nl> References: <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> <200611070857.kA78vqHi081358@open.nlnetlabs.nl> Message-ID: <20061107230013.GA6337@nic.at> On 2006/11/07 09:11, Jaap Akkerhuis wrote: > > On 6 okt 2006, at 00.06, Otmar Lendl wrote: > > The IETF enum list seems to be broken, > > Just repeating that the list is broken is unproductive. Just for the record here: This was an issue about one month ago. There was enough off-list diagnosing and communication which got the problem to be resolved. I mentioned the issue on the list only to explain why I resent mails (some people might have received some mails multiple times). /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > From patrik at frobbit.se Mon Nov 6 22:58:21 2006 From: patrik at frobbit.se (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Mon, 6 Nov 2006 13:58:21 -0800 Subject: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt In-Reply-To: <20061006070656.GJ15701@nic.at> References: <20061006070656.GJ15701@nic.at> Message-ID: <3A9ABD51-9881-4BE8-9E77-2F5AE453F32E@frobbit.se> On 6 okt 2006, at 00.06, Otmar Lendl wrote: > The IETF enum list seems to be broken, but as Paf explained > his proposal at the RIPE meeting in A'dam this week, here is > a copy of my reply: And here is my response... > On 2006/09/28 11:09, Patrik F?ltstr?m wrote: >> This document was requested to be published the other day, but >> publication seems to take some time. > > Thanks for the document, here are some question: > >> >> 1. >> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. Applicability >> Statement . . . . . . . . . . . . . . . . . . . 3 > > The formatting is a bit off (not only here, but also in the > rfc-editor repository), could you please submit a version > without unwanted line-breaks, and with page breaks? Yes, because I sent the draft inline instead of as an attachment... > Concerning this example: > >> 6.2. Different providers for services for the same E.164 >> >> An organisation have the E.164 +442079460148, but different >> organisations handle routing of calls for the number on the >> Internet >> (with the help of SIP) and traditional PSTN. More >> specifically, the >> two providers want to run DNS for the record(s) that refer to the >> services they provide. > > I think I understand the pure DNS mechanics you propose. > > What I can't see right now is how this proposal fits into the > Tier0/Tier1/ITSP/end-user scheme of actors. Where are the > zone cuts and who is operating which zone? This is the key question of course. >> The ENUM provider for the +44 country code in this case not >> only do >> delegations on the full E.164 number, but delegations on the >> service >> parameter values, as can be seen below: >> >> In this example we also include the NAPTR records that with the >> help >> of the 'D' flag refer to the URI records. We also include NAPTR >> records according to RFC 3761 [RFC3761] that give backward >> compatibility. >> >> In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.: > > Who do you propose should run that zone? A neutral party. Wherever we do the zone cut to "the user", "some service provider" or whoever, the delegation have to be made from a neutral party. Just like the management of the number portability database. >> $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. >> >> ;; NAPTR records that refer to URI records >> IN NAPTR 1 1 "D" "E2U:sip" ( ; service >> "" ; regexp >> _sip._e2u ; replacement >> ) >> >> IN NAPTR 1 1 "D" "E2U:tel" ( ;service >> "" ;regexp >> _tel._e2u ;replacement >> ) > > This record is *important* to the telco running the phone > service for this number. They won't want to live with the > possibility that users can mess up the telco internal routing. Yes, and they will unless under very specific circumstances accept the delegation FROM anyone else than a neutral party. I personally see similar issues with *ALL* services. This is why the ie164.arpa, or i.6.4.e164.arpa ideas from my point of view can not be the ONLY special delegations as "the telco" is only one of the service providers that think their service is special. I.e. I think we have one statement and a few questions to answer: Statement: Delegation must at some location in the tree be from a neutral party. Question 1: Where in the tree are we breaking out from neutral party delegation to special delegation? Question 2: When should "non-User ENUM" in reality NOT be in the e164.arpa tree? >> ;; NAPTR records for RFC 3761 compatibility >> IN NAPTR 1 1 "U" "E2U:sip" ( ;service >> "!.*!sip:+442079460148 at sipprovider.net!" ; regexp >> . ; replacement >> ) > > In the current model, this record is supposed to be hosted > on a user-controlled server. Yes. > > This puts us into a bind: > >> IN NAPTR 1 1 "U" "E2U:tel" ( ;service >> "!.*!sip:+442079460148 at sipprovider.net!" ; regexp >> . ; replacement >> ) >> >> ;; Delegations to child zones >> _sip._e2u IN NS ns1.example.net. >> _tel._e2u IN NS ns1.example.com. > > Once again, the I-ENUM records are dependent on the management of > the pure ENUM zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. You have pointed out a very good thing. We can not mix these things. That the user is responsible for the zone from which delegations are made. >> In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: >> >> >> $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. >> _sip._e2u IN URI "sip:+442079460148 at example.net" > > Shouldn't that be > > $ORIGIN _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > @ IN URI "sip:+442079460148 at example.net" > > to indicate where the zone-cut is? Maybe that is a better example? It is still "just" a syntax to make the zone content easier to read. It in reality have nothing to do with where the cut is. BUT, you suggest this is made clearer. I should say "In the zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. we have the following data". > ----------------------------- > > To summarize: > > If I were to start an ENUM deployment from scratch, this proposal > is fine > (except, see below). In this case, I'd put the IN NAPTR 1 1 "D" > records in the Tier1 zone (autocreated based on *._e2u entries) and > just delegate (optionally) the _sip._e2u subdomains to subscribers or > ITSPs. That way, the DNS infrastructure of one application can be kept > independent from the one of another application. > > The problem is the legacy 3761 support: For all the delegated domains > out there, it is not acceptable for the carriers to go to their > subscribers and asks them for a delegation of _tel._e2u. That ain't > going to fly. In order to make the transition, current ENUM users need > to provision their existing NAPTRs into the registry. That's going to > be a headache for everybody who managed to get a 3761-based system up > and running. I agree. > ----------------------------- > > The showstopper: > > And then there is the issue of open numbering plans. I can't see > how this > scheme is supposed to work in a country where PBX operators are > free to > define their own variable-length dialplan behind their pilot number. > > Consider the example of enum.at's Vienna office: > > Our pilot number is +43 1 5056416. That's a normal (i.e. not > shortened) Vienna > number. We use 2-digit extension, e.g. -33 is my phone. A common > scheme > is to use prefixes for FAX to Email services. In our case -933 is > supposed to deliver an incoming FAX to my mailbox. Our carrier > (Telekom > Austria) doesn't know or even care about these arrangements. > > In ENUM terms, right now we have a delegation for > 6.1.4.5.0.5.1.3.4.e164.arpa and simply add new extensions to our zone > file and be done with it. > > In I-ENUM, Telekom Austria (were they to take part in our trial) would > use wildcards to direct calls to their ingress point, e.g. by > > 6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1 at sip.telekom.at! > *.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1 at sip.telekom.at! > > Which records should Telekom Austria provision under your scheme? If I understand you correctly, Telekom Austria is running telephony for the number +43 1 5056416, but then you as a user of that number can add whatever digits you want as "extensions" as the routing is prefix based. I presume as long as the number of digits totally is fewer than 15 :-) Can you "port" that prefix from Telekom Austria to someone else? Today, as you point out, there should be a zone 6.1.4.5.0.5.1.3.4.e164.arpa in which you instead of "just" having NAPTR records for the name of the zone, you have NAPTR for the extensions you have. Example (not open numbering plan): 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... With open numbering plan: 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ... 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ... 3.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... 4.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... 5.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ... How do you handle number portability for these numbers (that end with 33, 34 and 35)? Can they be ported one at a time, or just the whole block at the same time? On the other hand, I see problems when the email provider want to run the DNS for the NAPTR that refer to the email services they run, and further, that the delegation should be from a neutral party? I do not have an answer to your question. I think the solution will violate many of the requirements we have. Regardless of what the solution is. Good discussion, lets continue. Patrik From klaus.mailinglists at pernau.at Wed Nov 15 09:47:43 2006 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 15 Nov 2006 09:47:43 +0100 Subject: [enum-wg] 9.3.e164.arpa down Message-ID: <455AD42F.3030402@pernau.at> Hi! The Italian ENUM name servers are down/broken. This will cause lots of trouble (long call setups) for ITSPs which perform ENUM lookups. How should we handle such situations? By RIPE (deleting the delegation), by monitoring registries and skipping ENUM lookup for certain countries? AFAIR this is not the first problem with 9.3.e164.arpa regards Klaus -- Klaus Darilion nic.at From jim at rfc1035.com Wed Nov 15 10:05:59 2006 From: jim at rfc1035.com (Jim Reid) Date: Wed, 15 Nov 2006 09:05:59 +0000 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <455AD42F.3030402@pernau.at> References: <455AD42F.3030402@pernau.at> Message-ID: <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> On Nov 15, 2006, at 08:47, Klaus Darilion wrote: > The Italian ENUM name servers are down/broken. This will cause lots > of trouble (long call setups) for ITSPs which perform ENUM lookups. > > How should we handle such situations? By RIPE (deleting the > delegation), by monitoring registries and skipping ENUM lookup for > certain countries? Klaus, this was discussed at the last RIPE meeting. What a country does with its ENUM name servers is a National Matter. This is not something that RIPE NCC should interfere with and it must NEVER pull an ENUM delegation unilaterally. A delegation under e164.arpa should only get deleted by the NCC -- not RIPE! -- if instructed to do so by the ITU or the appropriate Administration. Read the IAB instructions and ITU MoU to the NCC for details of the scope of NCC's ENUM responsibilities. What we -- for some definition of "we" -- should do in this situation is inform the Administration concerned and politely ask them to fix the problem. IMO this definition of "we" means you and the ITSPs who are having trouble. It doesn't mean RIPE NCC unless the relevant Administration has asked the NCC to monitor their ENUM delegation. > AFAIR this is not the first problem with 9.3.e164.arpa If that's the case, perhaps ITSPs should reconfigure their software until the DNS infrastructure for this domain is reliable enough. From john+ietf at jck.com Thu Nov 16 02:48:26 2006 From: john+ietf at jck.com (John C Klensin) Date: Wed, 15 Nov 2006 20:48:26 -0500 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> Message-ID: <4FA2774145CFB50C8370998C@p3.JCK.COM> --On Wednesday, 15 November, 2006 09:05 +0000 Jim Reid wrote: > On Nov 15, 2006, at 08:47, Klaus Darilion wrote: > >> The Italian ENUM name servers are down/broken. This will >> cause lots of trouble (long call setups) for ITSPs which >> perform ENUM lookups. >> >> How should we handle such situations? By RIPE (deleting the >> delegation), by monitoring registries and skipping ENUM >> lookup for certain countries? > > Klaus, this was discussed at the last RIPE meeting. What a > countrydoes with its ENUM name servers is a National Matter. > This is notsomething that RIPE NCC should interfere with and > it must NEVER pullan ENUM delegation unilaterally. A > delegation under e164.arpa shouldonly get deleted by the NCC > -- not RIPE! -- if instructed to do so bythe ITU or the > appropriate Administration. Read the IAB instructionsand ITU > MoU to the NCC for details of the scope of NCC's > ENUMresponsibilities. > > What we -- for some definition of "we" -- should do in this > situationis inform the Administration concerned and politely > ask them to fixthe problem. IMO this definition of "we" means > you and the ITSPs whoare having trouble. It doesn't mean RIPE > NCC unless the relevantAdministration has asked the NCC to > monitor their ENUM delegation. > >> AFAIR this is not the first problem with 9.3.e164.arpa > > If that's the case, perhaps ITSPs should reconfigure their > softwareuntil the DNS infrastructure for this domain is > reliable enough. of course, the other comment that could have been made here is that there is a reason for the long-standing rule that specifies that any domain have multiple servers (at least two) that do not fate-share. In other words, there are suppose to be servers that are sufficiently separated physically and in terms of network connectivity that the odds of all of them being unavailable at once are low to none. To the extent to which properly-separated and adequately independent servers would have solved or prevented this problem, the affected parties should, as Jim suggests, inform the Administration concerned and offer some appropriate advice. john From mah at inode.at Thu Nov 16 12:54:37 2006 From: mah at inode.at (Michael Haberler) Date: Thu, 16 Nov 2006 12:54:37 +0100 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <4FA2774145CFB50C8370998C@p3.JCK.COM> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> Message-ID: <455C517D.3020704@inode.at> John, I'm sorry to say, but "asking an administration politely" might be politically correct for RIPE NCC and other parties as things stand now - as an answer to an operational problem it is insufficient and bound to kill the trust of potential operators in the technology in the first place. This is part of a real time service and operators rely on it today. Hoping some administration can get their act together days later to defibrillate a broken box is while dozens of operators have stuck boxes denying service to *all* users (not just the folks calling to the country with broken nameservers) is unacceptable. And note, this particular ENUM delegee isnt even doing any service with his delegation in the first place. Yes, it has to do with current SIP server technology (thread starvation) - asynchronous DNS resolution and deadline scheduling may alleviate the problem, but no, that is not the only thing we can do except hope and pray. The other part of the story is that ENUM delegations are currently made not just for reasons of providing production service, but - let's be frank - occupying a "national resource" by some party which is not necessarily part of the Internet management culture, and intending, willing and able to provide realtime service on a 7x24 basis. What we as a community have failed to to is to attach appropriate rules and strings to that step. I believe we need to do the following: 1. trials need to be tagged so as not to interfere with production. It is unacceptable already to mix production and trial fumbling in a single tree. In the very minimum we need an automatic indication which tree is live, which tree is not serviced, and what is experimental- This could be an indicator record in the country code zone hinting on status, be it "TXT "trial", and/or a formalized tag in the RIPE DB. 2. we need to establish rules on what goes into e164.arpa which goes beyond the regulator/ITU TSB loop. IMO there is no point in activating NS delegations when the requesting organisation isnt committed to *run service*. Having some ministerial nameservers working on and off just so the administration can display territorial behaviour is a vanity affair where somebody else pays the bill. 3. "Pulling a delegation" and removing a "harm to the network" obstacle are different things. If the nameservers arent reachable, a TXT record saying "please call XXX" for details is fine. It is time we need rules - if the "administration" cant fix such problems within a reasonably time window, I have no understanding for such abstinence on the community's part. Yes, we can have SLA's - including towards governments entities which are blundering down the "Internet governance" lane (btw an excellent proof why these guys should keep out in the first place). This is very much like somebody injecting bogus BGP routes, nobody filtering them, and all hoping the bogus routes would just somehow disappear. How does the routing community deal with it? Well, clearly not abstinent. Fortunately they have more fine-grained mechanisms to deal with it, and probably we need to think about these as well. On the client side I see some requirements - going mostly towards the SER/OpenSER/Asterisk communities; here are some ideas: - I guess we need a simple country code blacklist and/or whitelist mechanism in these resolvers, so something can be done on the service side while the ministerial Windows NT 3.51 jockey searches for his lost default route. - step 2 would be to evaluate timeout errors to drive a dynamic blacklist mechanism, which could limit thread starvation. - evaluating say "TXT trial" tags at the country code level could help. -Michael John C Klensin schrieb: > --On Wednesday, 15 November, 2006 09:05 +0000 Jim Reid > wrote: > > >> On Nov 15, 2006, at 08:47, Klaus Darilion wrote: >> >> >>> The Italian ENUM name servers are down/broken. This will >>> cause lots of trouble (long call setups) for ITSPs which >>> perform ENUM lookups. >>> >>> How should we handle such situations? By RIPE (deleting the >>> delegation), by monitoring registries and skipping ENUM >>> lookup for certain countries? >>> >> Klaus, this was discussed at the last RIPE meeting. What a >> countrydoes with its ENUM name servers is a National Matter. >> This is notsomething that RIPE NCC should interfere with and >> it must NEVER pullan ENUM delegation unilaterally. A >> delegation under e164.arpa shouldonly get deleted by the NCC >> -- not RIPE! -- if instructed to do so bythe ITU or the >> appropriate Administration. Read the IAB instructionsand ITU >> MoU to the NCC for details of the scope of NCC's >> ENUMresponsibilities. >> >> What we -- for some definition of "we" -- should do in this >> situationis inform the Administration concerned and politely >> ask them to fixthe problem. IMO this definition of "we" means >> you and the ITSPs whoare having trouble. It doesn't mean RIPE >> NCC unless the relevantAdministration has asked the NCC to >> monitor their ENUM delegation. >> >> >>> AFAIR this is not the first problem with 9.3.e164.arpa >>> >> If that's the case, perhaps ITSPs should reconfigure their >> softwareuntil the DNS infrastructure for this domain is >> reliable enough. >> > > of course, the other comment that could have been made here is > that there is a reason for the long-standing rule that specifies > that any domain have multiple servers (at least two) that do not > fate-share. In other words, there are suppose to be servers > that are sufficiently separated physically and in terms of > network connectivity that the odds of all of them being > unavailable at once are low to none. > > To the extent to which properly-separated and adequately > independent servers would have solved or prevented this problem, > the affected parties should, as Jim suggests, inform the > Administration concerned and offer some appropriate advice. > > john > > > > > From jim at rfc1035.com Thu Nov 16 14:17:38 2006 From: jim at rfc1035.com (Jim Reid) Date: Thu, 16 Nov 2006 13:17:38 +0000 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <455C517D.3020704@inode.at> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> Message-ID: On Nov 16, 2006, at 11:54, Michael Haberler wrote: > I'm sorry to say, but "asking an administration politely" might be > politically correct for RIPE NCC and other parties as things stand > now - > as an answer to an operational problem it is insufficient and bound to > kill the trust of potential operators in the technology in the > first place. While that may be true, this is the world we live in. As far as the ITU is concerned, ENUM delegations have been made under interim procedures on the understanding that this was for trials, not production services. I strongly urge *everyone* to not rock the boat here. If operators are experiencing difficulties because of lame delegations or whatever, tough. That's what happens on the internet. Things break. Get over it. > This is part of a real time service and operators rely on it today. > Hoping some administration can get their act together days later to > defibrillate a broken box is while dozens of operators have stuck > boxes > denying service to *all* users (not just the folks calling to the > country with broken nameservers) is unacceptable. What you say is true Michael, but it's based on a false premise. Where are the service level guarantees and commitments that everyone using ENUM has agreed to? This is all being done on an informal best efforts basis underpinned by ad-hoc arrangements between the IAB, ITU and RIPE NCC. Operators should plan their service offerings accordingly. If someone's SIP servers can't cope with lame delegations, then that's a problem for the SIP server. It's better they get these fixed now instead of later when there could be millions of lame ENUM delegations. My guess is ~60% of .com has lame delegations so if/when ENUM gets mass public acceptance, comparable levels of DNS brokenness should be expected. SIP servers and other ENUM-aware software need to be able to deal with that. > And note, this > particular ENUM delegee isnt even doing any service with his > delegation > in the first place. Yes, it has to do with current SIP server > technology > (thread starvation) - asynchronous DNS resolution and deadline > scheduling may alleviate the problem, but no, that is not the only > thing > we can do except hope and pray. If some part of the ENUM tree is unreliable, work around it until the underlying problem gets fixed. For example by configuring the SIP servers not to do DNS lookups for that broken part of the tree. This is no different from how problems elsewhere with lame delegations sometimes get handled: eg temporarily tweak the mail server to shunt mail for lamedelegation.com off to a queue instead of doing DNS lookups in the hope of achieving SMTP delivery. And of course tell the DNS adminsitrator for that zone that their name servers are broken. > The other part of the story is that ENUM delegations are currently > made > not just for reasons of providing production service, but - let's be > frank - occupying a "national resource" by some party which is not > necessarily part of the Internet management culture, and intending, > willing and able to provide realtime service on a 7x24 basis. There are very few parts of the internet that have 24x7 monitoring. Or cast-iron service level agreements for things like DNS operations. Why project these for ENUM when they're not in place for most TLDs and huge chunks of in-addr.arpa? Which is not to say that these sorts of arrangements shouldn't be in place. That would obviously be a good thing. I'm just curious why operators appear to have expectations for stuff living under e164.arpa when they don't have those elsewhere in the DNS. Or perhaps they're just using software that doesn't cope with lame delegations as well as it could. If some operator decides that a country has just done a defensive ENUM delegation, they should take appropriate action. That might mean not doing ENUM lookups for that part of the tree for a variety of reasons: dodgy DNS service, weird NAPTR records, sparse population, whatever. That's a policy decision each operator has to make for themselves IMO. > What we as a community have failed to to is to attach appropriate > rules > and strings to that step. I believe we need to do the following: > > 1. trials need to be tagged so as not to interfere with production. True. But there is no "production" ENUM service. At least not formally. There can't be while the current arrangements for e164.arpa exist. And yes, I do know providers are selling ENUM registrations and offering services for money on top of ENUM. > 2. we need to establish rules on what goes into e164.arpa which goes > beyond the regulator/ITU TSB loop. IMO there is no point in activating > NS delegations when the requesting organisation isnt committed to > *run > service*. Having some ministerial nameservers working on and off > just so > the administration can display territorial behaviour is a vanity > affair > where somebody else pays the bill. Why not write up a draft/paper for this WG? If there was some formal document that explained to government officials how they should operate their Tier-1 name servers, that would be a big step forward: follow the advice in RFCs 2870 and 2182, don't allow servers to go lame, have some sort of external monitoring in place, etc, etc. There are no functional specifications for Tier-1 name servers, so writing these up would be a big help. At then least there would be a document that the bureaucrats could be pointed at. In other words let's try to light a candle instead of cursing the dark. > 3. "Pulling a delegation" and removing a "harm to the network" > obstacle > are different things. Klaus seemed to be suggesting the delegation for 9.3.e164.arpa should be pulled to prevent "harm to the network". For some definition of harm. Yes, lame delegations are bad. They're annoying and they create operational problems. But they're a fact of life and they'll never go away. Software just has to deal with this. For ENUM, the problem of lame delegations will get worse because there will be much more bit rot the further the DNS moves away from the clueful core to the edge of the network. So I think in addition to writing a doc that could persuade Tier 1 operators to do the Right Thing, there's a need to get software to handle lame delegations more gracefully. This could be through the sorts of things you mentioned Michael: configuration options, smarter timeout strategies and so on. From Richard.Stastny at oefeg.at Thu Nov 16 16:34:48 2006 From: Richard.Stastny at oefeg.at (Stastny Richard) Date: Thu, 16 Nov 2006 16:34:48 +0100 Subject: [enum-wg] 9.3.e164.arpa down References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> > As far as the >ITU is concerned, ENUM delegations have been made under interim >procedures on the understanding that this was for trials, not >production services. Jim, you are wrong here. The "Interim Procedures" state nowhere that they are "only for trials" >I strongly urge *everyone* to not rock the boat here. I agree we should be careful how we proceed with this issue not to awake sleeping lions, some people in ITU-T are wating for something like this to happen. OTOH, you approach to simple state that sh*t happens is also not feasable. IMO RIPE should first look what can be done and Michaels proposals should at least be taken into account Richard . From jim at rfc1035.com Thu Nov 16 18:02:43 2006 From: jim at rfc1035.com (Jim Reid) Date: Thu, 16 Nov 2006 17:02:43 +0000 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> Message-ID: <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> On Nov 16, 2006, at 15:34, Stastny Richard wrote: > Jim, you are wrong here. The "Interim Procedures" state nowhere that > they are "only for trials" I didn't say they did Richard. SG2 agreed the interim procedures on the understanding that they were for trials and not for production service. Certain ITU members would not have allowed the procedures to go through unless that condition was attached. We were both at the SG2 meeting where those procedures were adopted. Perhaps we have different recollections of that meeting? > OTOH, you approach to simple state that sh*t happens is also > not feasable. IMO RIPE should first look what can be done and > Michaels proposals should at least be taken into account I didn't say that either Richard. And I didn't discount Michael's constructive suggestions at all. The opposite in fact. If software does not behave reasonably on encountering lame delegations -- a depressingly common DNS problem -- that software needs to be fixed. Not that that implies lame delegations should be tolerated. Or that the administrators of those delegations shouldn't be contacted when these problems are found. This thread started with a complaint along the lines of "It hurts when SIP servers can't cope with lame name servers for 9.3.e164.arpa. Let's pull the delegation." [I paraphrase and exaggerate for effect.] I pointed out why this was flawed reasoning, politically and technically. I also encouraged Michael to do two things. One was to submit a draft/ paper to this WG on good DNS practices. If the WG picks up on that -- ie they get something to actually work on -- there's then a "standard" for Tier-1 operators and bureaucrats to follow. Next, if there's something that needs to be done to make SIP servers more robust to lame delegation errors, these should be written up too. That piece of work may be out of scope for the RIPE ENUM WG. Though this is for the WG to decide. From mah at inode.at Thu Nov 16 21:22:48 2006 From: mah at inode.at (Michael Haberler) Date: Thu, 16 Nov 2006 21:22:48 +0100 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> Message-ID: <455CC898.8040506@inode.at> Jim Reid schrieb: > > I also encouraged Michael to do two things. One was to submit a > draft/paper to this WG on good DNS practices. If the WG picks up on > that -- ie they get something to actually work on -- there's then a > "standard" for Tier-1 operators and bureaucrats to follow. Next, if > there's something that needs to be done to make SIP servers more > robust to lame delegation errors, these should be written up too. That > piece of work may be out of scope for the RIPE ENUM WG. Though this is > for the WG to decide. > I dont think I need to write a paper on good DNS practice because of that incident. The errors made in the case in question do not require that. I will, however, have work done on those ENUM resolvers we contribute to to have a blacklist mechanism for such "operators". All I want I demand that current best practice be obeyed on delegations, such that the following setup cannot happen: sil1:~# host -t ns 9.3.e164.arpa. 9.3.e164.arpa name server dns.istsupcti.it. 9.3.e164.arpa name server dns2.istsupcti.it. sil1:~# host dns.istsupcti.it. dns.istsupcti.it has address 62.101.92.173 sil1:~# host dns2.istsupcti.it. dns2.istsupcti.it has address 62.101.92.174 Do you note two adjacent IP adresses here? Janitor trips over wire, country gone - superb. And we are falling over here in political correctness, Get real, guys - dont tell me we cant do anything here, it's always been this way and we might be rocking some boat. We need to tell these guys to get a life, network diversity and some clue before having a delegation, and be done. You dont want the heat, you dont go into the kitchen. -Michael From john at jck.com Thu Nov 16 18:17:37 2006 From: john at jck.com (John C Klensin) Date: Thu, 16 Nov 2006 12:17:37 -0500 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> Message-ID: <431A85EE51A109047614671D@p3.JCK.COM> Michael and Jim, I generally agree with Jim's comments, but a few additional remarks below... --On Thursday, 16 November, 2006 13:17 +0000 Jim Reid wrote: > On Nov 16, 2006, at 11:54, Michael Haberler wrote: >> I'm sorry to say, but "asking an administration politely" >> might be politically correct for RIPE NCC and other parties >> as things stand now - >> as an answer to an operational problem it is insufficient and >> bound to kill the trust of potential operators in the >> technology in the first place. > > While that may be true, this is the world we live in. As far > as theITU is concerned, ENUM delegations have been made under > interimprocedures on the understanding that this was for > trials, notproduction services. > I strongly urge *everyone* to not rock the boat here. While I agree with this, and understand more than most the degree to which that ITU decision deviated from the original agreements with the IETF (had we anticipated that the ITU would still be saying "test" more than a half-dozen years later, they would not have been involved... which would have had other consequences), I don't think that distinction ultimately makes an difference. The reality is that, unless we are going to base SIP services on the same types of inter-carrier bilateral agreements that dominate interconnections in the PSTN, one needs to accept, and deal with, the nature of the Internet and the DNS. Any application that depends on the DNS must be prepared to deal with bad configurations, weak server setups, DNS servers that are not available when expected, and applications hosts that are not where the DNS says they are or that don't respond. If an application can't do that, then its users and customers will perceive it as a failure, whether the environment in which it is operating is officially a "production" or a "test" one. If someone can't keep a service --or the DNS pointers to it-- working reliably, then it isn't a service to which you (or your users) want to connect. The market pressures that should produce are the best tools we have. Conversely, if the target party doesn't care, then you either accept the fact that they don't care and move on or you figure out a way to route around them. Making them aware that they have a problem (in case they don't know) is appropriate; trying to find a way to insist that they fix it even if they don't want to is likely to be fruitless. And, ironically, if we are going to rely on bilateral agreements and SLAs instead of Internet-style robustness, then the design of ENUM as we have it today is wrong: user-ENUM does not presume that type of model and is actually somewhat hostile to it. >... >> And note, this >> particular ENUM delegee isnt even doing any service with his >> delegation in the first place. So? "Going to use the delegation to offer service" has never been part of the requirements for delegation. The delegation rules ultimately have only two requirements: that one ask, and that one be an appropriate party to do the asking. If someone accepts a delegation and then does nothing, or performs badly, that is a problem for anyone wanting to use that piece of tree, but not a problem for the Internet. And, if it is a problem for applications software trying to make a call, then that software is broken and needs to be fixed. >> What we as a community have failed to to is to attach >> appropriate rules >> and strings to that step. I believe we need to do the >> following: >> >> 1. trials need to be tagged so as not to interfere with >> production. > > True. But there is no "production" ENUM service. At least > notformally. There can't be while the current arrangements for > e164.arpaexist. And yes, I do know providers are selling ENUM > registrationsand offering services for money on top of ENUM. Well... I think the result is the same, but... There is no "production" ENUM service because the ITU has made a Recommendation that says so. If a country decides that its services are "production", than that is a national matter in which the ITU is powerless to interfere (and prohibited from trying to do so). If a country claims that its services are "production" and then offers lousy service, that is something that those who wish to connect to it need to deal with somehow. The important thing, IMO, is that, until and unless there is a way to compel someone else to offer good service (and that way has never really existed, even in the PSTN, except to the extent that there are enforceable bilateral agreements with SLA provisions), one needs to adopt mechanisms that provide ones users with appropriate levels of service, figure out whether connections are made and under what circumstances, etc. And none of that changes significantly whether the target system is "in production" or "a test". >> 2. we need to establish rules on what goes into e164.arpa >> which goes beyond the regulator/ITU TSB loop. IMO there is no >> point in activating NS delegations when the requesting >> organisation isnt committed to *run >> service*. Having some ministerial nameservers working on and >> off just so >> the administration can display territorial behaviour is a >> vanity affair >> where somebody else pays the bill. > > Why not write up a draft/paper for this WG? If there was some > formaldocument that explained to government officials how they > shouldoperate their Tier-1 name servers, that would be a big > step forward:follow the advice in RFCs 2870 and 2182, don't > allow servers to golame, have some sort of external monitoring > in place, etc, etc. Thereare no functional specifications for > Tier-1 name servers, so writingthese up would be a big help. > At then least there would be a documentthat the bureaucrats > could be pointed at. > In other words let's try to light a candle instead of cursing > the dark. Yes, absolutely. But remember that such a document would provide guidance for those who felt like listening. For those who do not, and especially for those who are determined to "prove" that ENUM and/or Internet-based telephony generally won't work (I am not assuming that Italy is in that camp), such documents won't change anything. john From jim at rfc1035.com Fri Nov 17 12:27:16 2006 From: jim at rfc1035.com (Jim Reid) Date: Fri, 17 Nov 2006 11:27:16 +0000 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <455CC898.8040506@inode.at> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> <455CC898.8040506@inode.at> Message-ID: <838EFEFC-DEB5-4DA5-860F-7F75EA7E53A8@rfc1035.com> On Nov 16, 2006, at 20:22, Michael Haberler wrote: > I dont think I need to write a paper on good DNS practice because of > that incident. The errors made in the case in question do not > require that. I'm sorry you feel that way Michael. > We need to tell these guys to get a life, network diversity and some > clue before having a delegation, and be done. Spot the contradiction. You don't want to help produce something documenting good DNS practice but you want the guys who have made mistakes to be told how to run DNS properly. I see. Ho hum. > All I want I demand that current best practice be obeyed on > delegations, I want a pony for Xmas. There is no "best practice for delegations". At least not one that's documented. And you don't want to help produce that document. Not that this document could be forced on Tier-1 operators anyway. > Get real, guys - dont tell me we cant do anything here, Nobody's saying that Michael. You rejected the invitation to help produce a document. Generating papers and drafts is the usual way of getting WGs to operate. So if you don't want to go down that path, I suggest you quietly go away. Demanding ENUM delegations obey best current practice is all very well but if you won't help define that BCP, you're not being constructive. You've already said you'll make changes to your SIP configurations. If that's the way you want to proceed, go right ahead. But please don't come back here whining about lame delegations. At least not until there's a BCP that's actually been agreed and implemented by all concerned. Like anyone else, you would of course be welcome to contribute to the production of this BCP if the WG takes on that work item. From jim at rfc1035.com Fri Nov 17 17:01:50 2006 From: jim at rfc1035.com (Jim Reid) Date: Fri, 17 Nov 2006 16:01:50 +0000 Subject: [enum-wg] Document on good Tier-1 DNS practice In-Reply-To: References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> Message-ID: <676A4728-F6F3-45C1-92EC-193D0F31C99C@rfc1035.com> On Nov 17, 2006, at 15:00, Niall O'Reilly wrote: > Of course not. Although that _is_ what Jim suggested (see above), > I'ld like > to believe he was using the phrase as a kind of shorthand, and > meant something > different, but related, and IMHO actually useful. That's *exactly* what I was suggesting. > Another "good DNS practice" document will simply not be worth the > effort. > The people who might read it know it already; those who should > _need_ to > read it won't have their radar pointing in the right direction. > > A document on "good ENUM Tier-1 practice", if it were available, > would be > something to which the RIPE NCC could _respectfully_ draw the > attention of > new (or not-yet-alerted) Tier-1 operators. Indeed. This hypothetical RIPE document might even be thrown over the wall to ITU SG2 as a contribution. From Niall.oReilly at ucd.ie Fri Nov 17 16:00:19 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Fri, 17 Nov 2006 15:00:19 +0000 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> Message-ID: On 16 Nov 2006, at 11:54, Michael Haberler wrote: > some party which is not > necessarily part of the Internet management culture On 16 Nov 2006, at 17:02, Jim Reid wrote: > I also encouraged Michael to do two things. One was to submit a > draft/paper to this WG on good DNS practices. If the WG picks up on > that -- ie they get something to actually work on -- there's then a > "standard" for Tier-1 operators and bureaucrats to follow. Next, if > there's something that needs to be done to make SIP servers more > robust to lame delegation errors, these should be written up too. > That piece of work may be out of scope for the RIPE ENUM WG. Though > this is for the WG to decide. On 16 Nov 2006, at 17:17, John C Klensin wrote: > Yes, absolutely. But remember that such a document would > provide guidance for those who felt like listening. For those > who do not, and especially for those who are determined to > "prove" that ENUM and/or Internet-based telephony generally > won't work (I am not assuming that Italy is in that camp), such > documents won't change anything. On 16 Nov 2006, at 20:22, Michael Haberler wrote: > I dont think I need to write a paper on good DNS practice because of > that incident. The errors made in the case in question do not > require that. [ WG Co-Chair hat OFF ] Of course not. Although that _is_ what Jim suggested (see above), I'ld like to believe he was using the phrase as a kind of shorthand, and meant something different, but related, and IMHO actually useful. Another "good DNS practice" document will simply not be worth the effort. The people who might read it know it already; those who should _need_ to read it won't have their radar pointing in the right direction. A document on "good ENUM Tier-1 practice", if it were available, would be something to which the RIPE NCC could _respectfully_ draw the attention of new (or not-yet-alerted) Tier-1 operators. [ WG Co-Chair hat ON ] I believe that such a document would be a useful _output_ (for a change) from the RIPE ENUM WG. Reactions? Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From pk at DENIC.DE Mon Nov 20 12:17:59 2006 From: pk at DENIC.DE (Peter Koch) Date: Mon, 20 Nov 2006 12:17:59 +0100 Subject: [enum-wg] 9.3.e164.arpa down In-Reply-To: References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> Message-ID: <20061120111759.GA28158@denics7.denic.de> On Fri, Nov 17, 2006 at 03:00:19PM +0000, Niall O'Reilly wrote: > [ WG Co-Chair hat ON ] > > I believe that such a document would be a useful _output_ (for a change) > from the RIPE ENUM WG. as an inventory of existing BCPs (BCP 16 and BCP 40 come to mind), such a document might be useful. It could be argued, though, whether the _RIPE_ enum wg is the right venue. -Peter From enumvoipsip.cs at schiefner.de Thu Nov 23 08:33:19 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 23 Nov 2006 08:33:19 +0100 Subject: [enum-wg] Document on good Tier-1 DNS practice In-Reply-To: <676A4728-F6F3-45C1-92EC-193D0F31C99C@rfc1035.com> References: <455AD42F.3030402@pernau.at> <1E963A86-1707-4ED7-8206-3270E1347BBB@rfc1035.com> <4FA2774145CFB50C8370998C@p3.JCK.COM> <455C517D.3020704@inode.at> <32755D354E6B65498C3BD9FD496C7D462C4C12@oefeg-s04.oefeg.loc> <25B8A63D-CDFB-4558-86DA-B1AD800E9307@rfc1035.com> <676A4728-F6F3-45C1-92EC-193D0F31C99C@rfc1035.com> Message-ID: <45654EBF.1070107@schiefner.de> Jim, all - Jim Reid wrote: >On Nov 17, 2006, at 15:00, Niall O'Reilly wrote: >> Of course not. Although that _is_ what Jim suggested (see above), >> I'ld like >> to believe he was using the phrase as a kind of shorthand, and meant >> something >> different, but related, and IMHO actually useful. > > That's *exactly* what I was suggesting. > >> Another "good DNS practice" document will simply not be worth the effort. >> The people who might read it know it already; those who should _need_ to >> read it won't have their radar pointing in the right direction. >> >> A document on "good ENUM Tier-1 practice", if it were available, would be >> something to which the RIPE NCC could _respectfully_ draw the >> attention of >> new (or not-yet-alerted) Tier-1 operators. > > Indeed. This hypothetical RIPE document might even be thrown over the > wall to ITU SG2 as a contribution. ... and this pretty much seems to be in line with what we were talking about at RIPE 53 under the agenda item "Quality Task Force". :-) The action item is on me to gather more input and to report back ("Ongoing work, progress will be reported at RIPE 54 or also inbetween if necessary"); cf. http://www.ripe.net/ripe/meetings/ripe-53/presentations/enu-cs-qtf.pdf . Best, -C.