Re: [PEPPERMINT] Comparison of Requirements Documents

Ed,

  See inline.

Jean-Francois.

> -----Original Message-----
> From: peppermint-bounces@ietf.org [mailto:peppermint-
> bounces@ietf.org] On Behalf Of Edward Lewis
> Sent: Monday, June 30, 2008 1:08 PM
> To: peppermint@ietf.org; drinks@ietf.org
> Subject: [PEPPERMINT] Comparison of Requirements Documents
> 
> 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.

I'm not sure what you meant by "different emphasis".  

> Both documents describe a protocol running over SOAP/XML, WDSL, TLS
> and HTTP and being easily integrated into the current provisioning
> systems.
The ESPP protocol requirements were modeled after the NETCONF ones (at
least in terms of the document outline).

> 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

No.  It should be possible to use a file-based mechanism to provision a
large amount of data for sunrise use cases.  If you look at ESPP
closely, the concept of operations based on transactional records does
exist.

> this,
> as well as a hard coded limit on the size limit.)
Implementations prevail.  We came to the conclusion that to be testable,
those requirements better be bound in terms of how big of a file sent
via SCP a server must be able to accept and process.  It also gives an
indication to sysadmins and operators for where they should not go in
file sizes.  The idea is to split the files into multiples after a
certain limit.
I see nothing wrong with that, quite the contrary when you start to look
at code.

> 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.)
Can you elaborate and quote text so we (authors of ESPP) can provide
more context.

> 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).

Again, the purpose of those things is just to give a number to give
implementers an idea of the scale and performance requirements.

> 
> ESPP includes some protocol maintenance stuff (versioning numbers).
> 
> Consolidated has requirements on the database being addressable
> (any element).
ESPP goes into details about how each object in the DB is identified
with eID and oIDs, something Kent went over in a thread with Bob Walter
some time ago.

> Consolidated explicitly includes prefixs (for ranges) and min/max
> lengths.
ESPP has TN ranges and LRNs which we agreed should be changed to prefix
to make it more generally applicable.

> Consolidated explicitly mentions numbers being reassigned and the
> impact of that on database entries and responses.
What is the requirement on the protocol here (as opposed to the
operational aspects of number reassignments)?

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

Based on the above, this is not obvious to me.

> 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.  
That I agree with.

> 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
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT@ietf.org
https://www.ietf.org/mailman/listinfo/peppermint