Subject: [PEPPERMINT] Few thoughts for tomorrow.

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 6 Dec 2007 03:36:20 -0500

Tom, Richard, et.al.

Not surprisingly, since this is in early stages, the four good docs that
exist so far (two problem statements, Newton and Schwartz, the
requirements doc, Lewis, and the data set doc Schwartz) are good and
valuable but are also disjoint in their perspectives, terminology, and
the presumed underlying architecture.  A suggestion to help rectify this
is to follow the approach applied by the SPEERMINT group, which seemed
very effective to me.  That would be the following:

1) Create a block diagram like the one in SPEERMINT that illustrated the
initial document set that will be produced (one doc per block), the
dependency flow from the first doc(s) on down.  This creates a clear
picture for everyone on the documents that will be produced in what
order and for what reason.
2) Imho the docs that we need are:
    a. Architecture Document, that creates a clear picture and
responsibilities of the logical components within the provisioning flow.
This probably should include the Registry(s), the Addressing Server
Master(s), and, optionally, the Addressing Server Slaves/Replicas.  This
document will also create a common terminology set for the logical
aspects of the architecture that can then be used in the problem
statement and the requirements doc(s).
    b. Problem Statement that defines the overall problems that
SPEERMINT must solve relative to the logical components identified in
the Architecture Document, without delving into specific data items or
solution schemes.  The Newton document was a good start at this, imho,
as it clearly laid out the high level problem statement to define an
API/protocol between the VSP and the Registry, and between the Registry
and the addressing servers.  The Schwatz document is also good,  Id does
however seem to mash the logical entity of the Registry and the ENUM
Addressing Server in together (assuming I interpreted the document
correctly).  The Schwartz document moves past the higher level Problem
Statement and directly into Data Model items that, imho, are more
appropriate for a requirements document.  But it is certainly a good
document as well.
    c. Requirements Document that defines the data elements/objects that
must provisionable (is that a word) via the interfaces identified in the
Problem Statement, the operations that must be supported for this data
elements/objects, the performance and scalability requirements, security
requirements, etc.  But it is also important that this document not
attempt to specify the solution.  I see in the current requirements
document that there is a lot of "solution" (e.g. use zone files, or use
SOAP) in there but not enough requirements details.  But it is a good
start.
    d. Also, in one of these documents we need to make sure all the
terminology is defined and kept consistent, but we may not need a
separate doc for that.
3) Lastly, in the BOF notification you asked if some can volunteer to
work on these documents.  I'm volunteering to do so.  I can be a
reviewer of all of these documents and also co-author them as necessary.

Ken

_______________________________________________
PEPPERMINT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/peppermint

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 6 Dec 2007 13:06:17 -0500

Thanks for your note. Its precisely this kind of support we need.

>  -----Original Message-----
>  From: Cartwright, Kenneth [mailto:[email-masked]]
>  Sent: Thursday, December 06, 2007 3:36 AM
>  To: [email-masked]
>  Subject: [PEPPERMINT] Few thoughts for tomorrow.
>  
>  Tom, Richard, et.al.
>

---

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 6 Dec 2007 16:05:30 -0500

My typo:

This...
b. Problem Statement that defines the overall problems that SPEERMINT
must solve
Should have read like this...
b. Problem Statement that defines the overall problems that PAPPERMINT
must solve