Subject: Re: [PEPPERMINT] Comparison of Requirements Documents

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 8 Jul 2008 15:33:21 -0600

Ed,

  See inline.

Jean-Francois.

> -----Original Message-----
> From: [email-masked] [mailto:peppermint-
> [email-masked]] On Behalf Of Edward Lewis
> Sent: Monday, June 30, 2008 1:08 PM
> To: [email-masked]; [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/peppermint
_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/peppermint

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Jul 2008 11:35:36 -0700

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

"Different emphasis" refers to what is documented.  For example, ESPP 
emphasizes file operations, the consolidated has a requirement that 
emphasizes individual transactions.  Different emphasis is not 
different direction, not a conflict, but is a reflection (also) of 
what was chosen to be placed in the document.

Neither requirement documents is all encompassing at this point, 
although the ESPP document is more mature and has an implementation 
to back it.

>least in terms of the document outline).

That's not in the references of the ESPP document.

>closely, the concept of operations based on transactional records does

Section 4.2 is "File", 4.1 is "Connection" but starts "The protocol MUST
support a file-based, bulk delivery mechanism".  Not to say ESPP does 
not do interactive - I don't see it in the requirements, at least not 
highlighted.

Recall that the context here is the requirement document, not the 
protocol (document).

>I see nothing wrong with that, quite the contrary when you start to look

My experience with hard limits is in the DNS protocol, as well as the 
address space in IPv6.  In DNS there was a 512 byte limit in UDP 
message segments with no nod towards expandability until EDNS0 came 
along.  The installed base of pre-EDNS0 code made the transition 
difficult.  With IPv6, one of the things that could have made 
coexistence with IPv4 possible was to allow the address field to be 
variable length, or at least special case in a short address of 32 
bits.  Generalizing from these cases, hard limits in specs trigger 
flags in me - even if there is merit in the limit as stated.

>Can you elaborate and quote text so we (authors of ESPP) can provide

For example, the consolidated specs mention the "\1" shorthand.  (On 
the other hand, ESPP strives to not be tied to NAPTR as consolidated 
assumes.)  What is not in the ESPP requirements is any requirement 
that syntax of the updates accommodate rules/profiles/macros, call 
them what you will.  Again, let me stress - I'm not saying ESPP lacks 
this, it's just not something I saw in the document.

>with eID and oIDs, something Kent went over in a thread with Bob Walter

The reason I cited the documents I commented on was to say "this is 
what I am talking about."  I hope that the result of 'the thread you 
cite' makes it's way into the next document cycle.

>>  "ownership" and other ancillary data.
)

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

E.g., you mention that ESPP does interactive operations, not just 
file based, and that file based is for sunrise.  This wasn't made 
apparent in the requirement document.  In the Consolidated document, 
we did include more about interactive operations.

That doesn't mean one (emphasis) is better than the other.  It's just 
a measure of what is chosen to be put into words.

>>  well as being accompanied by a protocol specification), there is a need
>>  to combine the two documents.
>
>That I agree with.

All's well that ends well.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar