[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PEPPERMINT] Comparison of Requirements Documents
At 15:33 -0600 7/8/08, Jean-Francois Mule wrote:
From: peppermint-bounces at ietf.org [mailto:peppermint-
bounces at ietf.org] 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 +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
_______________________________________________
PEPPERMINT mailing list
PEPPERMINT at ietf.org
https://www.ietf.org/mailman/listinfo/peppermint