perfsonar development work

["Eric L. Boyd" <>]

Greetings,

As discussed in today's perfSONAR development meeting, we propose to 
change/refine our definition of "perfSONAR". The goal of these changes 
is to:

a) Enfranchise more (all?) ongoing perfSONAR-related efforts as 
"perfSONAR".
b) Allow us to present a coherent answer to "what is perfSONAR" to 
different communities.
c) Reflect the reality of unacknowledged, real processes in the 
perfSONAR consortium and incorporate them into the perfSONAR project.

We do NOT intend to reduce the incentive to collaborate with each other 
or work together on common projects.

Please review these changes and we will revisit the topic first thing in 
the morning, review the proposal, make changes if necessary, and jassign 
action items.

Changes:

1) There will no longer be "perfSONAR core services" or "perfSONAR 
affiliated services" or "perfSONAR unaffiliated services".

2) We define four new classes of perfSONAR-related activity

a) perfSONAR proposed services
b) perfSONAR services
c) perfSONAR clients
d) perfSONAR suites

3) PerfSONAR proposed services are defined as:

a) Conforming to the syntax (binary representation of the message) and 
semantics (business logic) of the protocol standard
   ACTION ITEM: Define the syntax (largely done via the schema).
   ACTION ITEM: Define the semantics (largely incomplete)

b) Having a base level of documentation
   ACTION ITEM: Define base level of documentation

c) Conforming to the naming scheme for services
   ACTION ITEM: Define naming scheme for services. Consider including 
developing institution, development language, service type, tool, e.g. 
DFN-PERL-MA-BWCTL service.

d) Having a non-coercive open source license.
   ACTION ITEM: Determine a non-exhaustive list of likely/preferred 
licenses (e.g. Apache, modified Berkeley, etc.)

Note that there are no requirements about language of implementation, 
installation, packaging, release management, documentation format, etc.

4) PerfSONAR services are defined as:

a) Meeting the aforementioned requirements for perfSONAR proposed services.

b) Having successfully concluded an interoperability bake-off.
   ACTION ITEM: Define when a bake-off can occur and what is considered 
"success". An interoperability bake-off occurs when there exist 2 or 
more services with a common interface and one or more services or 
clients interoperating with those services. Bake-offs can happen 
repeatedly, if there is a need. The goal of these bake-offs is to 
validate assumptions made about unspecified syntax or semantics and 
incorporate such assumptions into the protocol standard.

Note there is no suggestion that perfSONAR proposed services are of 
lesser value than perfSONAR services.

In addition, we have define a bunch of processes for the various aspects 
of these definitions, but we didn't record these very well, so I'll need 
my memory refreshed in the morning.

5) PerfSONAR clients are defined as:

 ACTION ITEM: Come up with a definition as we haven't covered this 
topic yet.

6) PerfSONAR suites are defined as:

a) A set of 1 or more proposed services, services, and clients
b) Issued by an organization (e.g. GEANT2 JRA1, Internet2, the perfSONAR 
consortium, etc.)
c) Recommended for a collection of adopters (e.g. European NRENs, LHC 
community, generic adopters, etc.)

A perfSONAR suite may have additional requirements of included services 
(e.g. a common installation process, all written in Java, etc.) Various 
perfSONAR suites may overlap or not with each other.

To reiterate, it is still in our common best interest to work towards 
common suites, but it is not a requirement.

Comments and discussion welcome.

--Eric

--
Eric Boyd
Director of Performance Architectures and Technologies
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI  48104  USA
(734)352-7032

The Fall 2006 Internet2 Member Meeting:
Because the best way to predict the future is to keep inventing it.
http://events.internet2.edu/2006/fall-mm/