... 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.
<sigh> 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