[enum-wg] 9.3.e164.arpa down

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 at 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