Re: [PEPPERMINT] Comparison of Requirements Documents

[Edward Lewis <[e-mail]>]

At 15:33 -0600 7/8/08, Jean-Francois Mule wrote:
>>  From: [e-mail] [mailto:peppermint-
>>  [e-mail]] On Behalf Of Edward Lewis
>>  Sent: Monday, June 30, 2008 1:08 PM

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

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

>The ESPP protocol requirements were modeled after the NETCONF ones (at
>least in terms of the document outline).

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

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

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

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

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.

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

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.

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

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.

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

For example, the dip requirements (and:
>>  Consolidated requires dip indications, temporal validity, number
>>  "ownership" and other ancillary data.
)

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

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.

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

All's well that ends well.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

Never confuse activity with progress.  Activity pays more.
_______________________________________________
PEPPERMINT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/peppermint