[enum-wg] Italian Nameservers for 9.3.164.arpa. dead?

--On Monday, 21 January, 2008 22:52 +0100 Otmar Lendl
<lendl at nic.at> 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