[enum-wg] ENUM Tier-1 Performance/Availability

[Carsten Schiefner <enumvoipsip.cs@localhost]

Dear ENUM colleagues,

Patrik Fältström wrote on 21 Jan 2008:
> [...]
>
> That said, maybe we in this wg should finalize the document that 
> recommend a registry to "keep track of their delegation -- for example 
> via an opt-in mechanism that check the delegation"?
> Carsten, was this on your table, or do I remember wrong?
this eventually has now happened - as per Mark Dranse's email of 17 
April 2008 to the NCC Services WG list and the RIPE list:
http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2008/msg00015.html

the RIPE NCC has extended its DNSMON service to also any Tier-1 ENUM 
domain (cf. RIPE-429, attached).
Any ENUM Tier-1 registry that wishes to do so can now opt-in to have 
their delegation monitored.
The question is: shall we leave it at this stage or shall we try to take 
it further? I reckon the former from the tone of the majority of 
contributions here on this list about three months ago. OTOH, this is 
(also) an operational topic and thus (still) an appropriate item of 
discussion for this WG.
That is why we (the Co-Chairs, Niall and me) slotted in 15 min for such 
a discussion during the upcoming WG session. Please consider this email 
a "Heads Up" for voicing ideas, approaches etc. onsite as well as here 
on the list.
A way forward MIGHT be along the lines of what John wrote here:

===
Subject: Re: [enum-wg] Italian Nameservers for 9.3.164.arpa. dead?
Date: Tue, 22 Jan 2008 15:29:37 -0500
From: John C Klensin john+ietf@localhost
To: Otmar Lendl lendl@localhost, enum-wg@localhost

[...]

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.
	
[...]
===

I am hoping for fruitful discussions - and I of course also hope to see 
you next week in Berlin.
Best,

	Carsten Schiefner
	RIPE ENUM WG Co-Chair

DNS Monitoring Service for Infrastructure Domains

/ Mark Dranse, RIPE NCC /

Document ID: ripe-429
Date: 17 April 2008
Updates: ripe-342

------------------------------------------------------------------------

Since 2004, DNSMON has provided a comprehensive and independent overview
of the quality of the service provided by infrastructure-level Domain
Name System (DNS) servers. The background and history of the service can
be found in "RIPE 342" [1], which this document obsoletes.

DNSMON is built on top of the Test Traffic Monitoring (TTM) network [2],
and it uses the same probes for its measurements. Measurements are
carried out by sending normal DNS queries to monitored servers at
regular intervals. All results are available to the public.

The RIPE NCC's DNSMON measurements benefit the entire Internet community
by providing an objective and impartial global overview of TLD-level DNS
operations. As part of this service, we monitor some interesting
infrastructure domains, including the root, free of charge.

If requested by the operators, we will also configure monitoring for the
DNS servers of:

    * Any TLD (ccTLD, gTLD etc)
    * Any Tier-1 ENUM domain (for example, 1.3.e164.arpa)

Fees are charged for this service on a cost-recovery basis. Subscribers
receive additional benefits, which may change from time to time. These
are documented within the DNSMON operational service documents [3].

------------------------------------------------------------------------

[1] ftp://ftp.ripe.net/ripe/docs/ripe-342.pdf
[2] http://www.ripe.net/ttm
[3] http://dnsmon.ripe.net/