Re: [Enum] ENUM Test Specificatiobns

lconroy <lconroy@insensate.co.uk> Tue, 07 February 2006 10:43 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6QK1-0007PR-DP; Tue, 07 Feb 2006 05:43:45 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6QJv-0006uw-3n; Tue, 07 Feb 2006 05:43:43 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03199; Mon, 6 Feb 2006 20:31:23 -0500 (EST)
Received: from 213-152-49-123.dsl.eclipse.net.uk ([213.152.49.123] helo=norman.insensate.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6HvN-0007y3-IM; Mon, 06 Feb 2006 20:45:46 -0500
Received: from [127.0.0.1] (localhost [127.0.0.1]) by norman.insensate.co.uk (Postfix) with ESMTP id B35CC7BCC1; Tue, 7 Feb 2006 01:32:51 +0000 (GMT)
In-Reply-To: <134B5C86-A17B-48D5-A1FF-CB2EDF5A7696@rfc1035.com>
References: <7.0.1.0.2.20060205110918.035d3d70@verisign.com> <20060206153254.6D98B356A13@mail1-vs-brn.bigfish.com> <7.0.1.0.2.20060206133609.039bf6a8@verisign.com> <134B5C86-A17B-48D5-A1FF-CB2EDF5A7696@rfc1035.com>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <F32A524C-75F2-4EAB-B1E5-00A77645478C@insensate.co.uk>
Content-Transfer-Encoding: 7bit
From: lconroy <lconroy@insensate.co.uk>
Subject: Re: [Enum] ENUM Test Specificatiobns
Date: Tue, 07 Feb 2006 01:32:50 +0000
To: Jim Reid <jim@rfc1035.com>
X-Mailer: Apple Mail (2.746.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: enum@ietf.org, speermint@ietf.org, 'Otmar Lendl' <lendl@nic.at>, Tony Rutkowski <trutkowski@verisign.com>, henry@pulver.com
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Sender: enum-bounces@ietf.org
Errors-To: enum-bounces@ietf.org

Hi Tony, Jim, folks,
  as the other half of that particular double act, I can chime in here.

Tony - you should know better :). There was a VSGN chap at the plugtest
and he therefore has the final report, in which the tests we ran are  
listed.

I should point out that these broke everyone's implementations, but the
clueful fixed theirs during the tests. We didn't go to the South of  
France
to sun ourselves - we were stuck in a concrete dungeon, as Otmar can  
attest.
As with all real plugtests(tm), whilst Interoperation is important,  
getting
it right is better.

There was a similar issue with the first ROHC tests - everyone had  
read the
spec in the same wrong way (bit/byte order issue, as I recall), and they
all interoperated, but were all wrong. That was fixed, IIRC, during the
frantic last day of that test.

all the best,
   Lawrence

On 6 Feb 2006, at 19:11, Jim Reid wrote:
> On Feb 6, 2006, at 18:53, Tony Rutkowski wrote:
>
>> Has anyone developed ENUM test suites or data?
>
> Yes. Lawrence Conroy and I came up with some for the ETSI ENUM  
> Plugtest last summer. The infrastructure to support that -- name  
> servers and SIP server connected to a PBX -- was torn down after  
> the event. It all ran on borrowed equipment. I was also a little  
> bit naughty because the testbed used some UK drama numbers  
> (equivalents of 555 numbers in the USA) that shouldn't have been  
> delegated, let alone used for these tests.
>
> There's an action on me from the RIPE ENUM WG to try and get a semi- 
> permanent testbed established. The first thing is to get the  
> requirements documented. Contributions welcomed. Funding is even  
> more welcome. :-)
>
>> ETSI did some plug-tests some time ago, but the focus
>> seemed primarily on demonstrating interoperability.
>
> Not really. The prime focus of those tests was to find out how  
> implementations behaved under wierd or unusual inputs: lame  
> delegations, malformed NAPTR records, tel: URIs that pointed at  
> bogus or illegal numbers, truncated responses, etc, etc.
>


_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum