perfsonar development work

[Jason Zurawski <>]

All;

> I think this is a good step forward. All the pieces are there. My
> major concern is with some of the organization. I think too much is
> devoted to schema (rnc) concerns, and not enough to protocol. And, the
> lines between base/extension/service information is not so clear in
> many cases. I think it will take some real work to make this clear.
>
> This would probably be a good topic for the next full pS developers
> meeting (whenever that will be).
>
> [I apologize for not having time to give more substantive suggestions
> right now. Jason and I were just talking. Perhaps we can make a more
> substantial contribution to defining this after our MDM releases are
> ready?]

Here is our repository where we are storing the beginnings of the
protocol documents we discussed in Berkeley:

http://anonsvn.internet2.edu/svn/perfSONAR-PS/branches/merge/doc/protocol/

Also see service documents:

http://anonsvn.internet2.edu/svn/perfSONAR-PS/branches/merge/doc/service/

These are written in docbook format and are fairly complete from the
syntax/semantic end of things (to be true protocol documents they will
more than likely need some sections regarding state transitions, etc). 
The only missing part currently (although in progress) is the role of
the 'profile' documents in relation to the protocol and the service
documentation, this is what Jeff alluded to at the top. 

My opinion is that the syntax and semantic portions need to live in the
same document, and shouldn't be separate documents (syntax is really
nothing without the underlying meaning).  The 'profile' documents should
essentially reference whichever 'protocol' they are using and talk about
the things that are extended (i.e. In the case of the RRD MA it would
reference the MA protocol and talk about the specific metadata/data/key
structures used), or things that are omitted.  A deeper understanding of
the state transitions can be given here than in the 'protocol' work as
well.  This sort of mirrors the current roles of the
interface/functional documents and places them into one unit, which
should be much easier to grasp than the current split.

Comments are welcome, it is still a (very large) work in progress.

-jason


>> Hi,
>>
>> you can find in attachment a document which identifies the different
>> documents that one can need.
>>
>> The goal of this document is to provide a “framework” of documents
>> (specifications, documentation) for perfSONAR and to identify the
>> information required so that we can have a stable
>> documentation/specification documentation structure.
>>
>> The document aims at identifying
>> 1.    the different technical documents (specifications) that the
>> developers needs to have to implement inter-actions between the
>> services.
>> 2.    the documentation that are provided for each service (e.g. for
>> the GUI developers to inter-act with a particular implementation of a
>> message or protocol).
>> 3.    the process involved (e.g. to extend a schema, etc)
>>
>> For each type of documents, a high level description of the document
>> content or the multiple document that need to be produced is provided.
>>
>>
>> I do strongly encourage you to read the document and
>> - comment it
>> - add the information you think is necessary to be in a document
>> - raise question and points regarding the content of the document or
>> their structuration of the documents.
>>
>> The document and your comment will be used for a dedicated session in
>> Rome.
>>
>> Thank you very much in advance.
>>
>> Best regards,
>


-- 

Jason Zurawski, Network Software Engineer
Internet2

office: [+1-202-331-5354]
mobile: [+1-734-846-2900]
fax:    [+1-202-872-6648]

Turn innovation into recognition:
Submit for the Internet2 IDEA Awards
http://www.internet2.edu/idea/