[PEPPERMINT] Comparison of Requirements Documents

Edward Lewis <Ed.Lewis@neustar.biz> Mon, 30 June 2008 19:08 UTC

Return-Path: <peppermint-bounces@ietf.org>
X-Original-To: peppermint-archive@optimus.ietf.org
Delivered-To: ietfarch-peppermint-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62F553A6932; Mon, 30 Jun 2008 12:08:19 -0700 (PDT)
X-Original-To: peppermint@core3.amsl.com
Delivered-To: peppermint@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4BDF3A6932; Mon, 30 Jun 2008 12:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FliUulUV7W3y; Mon, 30 Jun 2008 12:08:16 -0700 (PDT)
Received: from ogud.com (hlid.ogud.com [66.92.146.160]) by core3.amsl.com (Postfix) with ESMTP id 849433A6903; Mon, 30 Jun 2008 12:08:16 -0700 (PDT)
Received: from [10.31.200.209] (mail.md.ogud.com [10.20.30.6]) by ogud.com (8.13.1/8.13.1) with ESMTP id m5UJ8IeI068941; Mon, 30 Jun 2008 15:08:19 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Mime-Version: 1.0
Message-Id: <a06240801c48edd93a8e5@[10.31.200.209]>
Date: Mon, 30 Jun 2008 15:08:15 -0400
To: peppermint@ietf.org, drinks@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
X-Scanned-By: MIMEDefang 2.63 on 10.20.30.6
Subject: [PEPPERMINT] Comparison of Requirements Documents
X-BeenThere: peppermint@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Provisioning Extensions in Peering Registries for Multimedia INTerconnection <peppermint.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/peppermint>, <mailto:peppermint-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/peppermint>
List-Post: <mailto:peppermint@ietf.org>
List-Help: <mailto:peppermint-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/peppermint>, <mailto:peppermint-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: peppermint-bounces@ietf.org
Errors-To: peppermint-bounces@ietf.org

I've been taking a look at two requirements documents, the ESPP 
Requirements and the Consolidated Provisioning Statement.  I realize 
(or have been told) that a new set of ESPP documents is coming out, 
so I'll avoid getting into specifics.  The goal is to have a 
"Unified" (we've already used "Consolidated") requirements document 
for the WG.

BTW, the documents I'm comparing are these:
http://tools.ietf.org/html/draft-mule-peppermint-espp-requirements-00
http://tools.ietf.org/html/draft-schwartz-peppermint-consolidated-provisioning-problem-statement-00

This comparison list is not very detailed, I wanted to identify the 
topics that included in both and where the two requirements had 
different emphasis.  I don't think there is any outright 
contradiction between the two.

Both documents describe a protocol running over SOAP/XML, WDSL, TLS 
and HTTP and being easily integrated into the current provisioning 
systems.

Both recognize that there a telephone number (E164) to URI mapping 
happening, with NAPTR as a major vehicle (but not sole vehicle).

Both mention a need to make the transactions auditable, including logs.

Consolidated mentions multiple kinds of sources of data, ESPP refers 
to multiple clients.  This could be interpreted as an equivalent 
statement.

ESPP explicitly states that operation is based on files (as opposed 
to records).  (I'd question the file name requirements based on this, 
as well as a hard coded limit on the size limit.)

ESPP describes designing an efficient protocol, i.e., being able to 
apply one set of data to many numbers.  (But when I boiled the 
requirements down, I didn't see this idea - maybe it was in the 
protocol.)

ESPP has a specific data model in mind (which is being discussed in 
recent mail), and a capacity of the order of the size of the PSTN 
number range(s).

ESPP includes some protocol maintenance stuff (versioning numbers).

Consolidated has requirements on the database being addressable (any element).

Consolidated explicitly includes prefixs (for ranges) and min/max lengths.

Consolidated explicitly mentions numbers being reassigned and the 
impact of that on database entries and responses.

Consolidated requires dip indications, temporal validity, number 
"ownership" and other ancillary data.

Consolidated requires a catchall record, a \1 shorthand.

Consolidated has requirements on the transport as being end-to-end 
only (no caching) and having flow control.

It's obvious that the two teams that developed the documents had 
different emphasis on what to include in a list or requirements. 
Even with the ESPP requirements document being rather mature (as well 
as being accompanied by a protocol specification), there is a need to 
combine the two documents.  I don't believe that the result will be 
radically different from either, just more complete.


-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.ietf.org/mailman/listinfo/peppermint