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
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.
--On Wednesday, 15 November, 2006 09:05 +0000 Jim Reid <jim@rfc1035.com> 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
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 <jim@rfc1035.com> 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
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.
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 .
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.
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
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.
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
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.
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.
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
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 <jim@rfc1035.com> 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
participants (9)
-
Carsten Schiefner -
Jim Reid -
John C Klensin -
John C Klensin -
Klaus Darilion -
Michael Haberler -
Niall O'Reilly -
Peter Koch -
Stastny Richard