Mass Update

Mass Update

Mass Update

Mass Move

This document has been published

PDF uploaded.

This document will be published in the GGF Document series as an 
EXPERIMENTAL type document.

An EXPERIMENTAL type document is intended to provide the community with 
either (a) an experimental specification or (b) documentation of the results of 
an experiment or set of experiments.  

An experimental specification is often useful for fleshing out a protocol or other 
specification in order to gain experience prior to defining a recommendations-
track specification.

In the advancement of a specification from PROPOSED RECOMMENDATION to 
RECOMMENDATION, the EXPERIMENTAL type document is used to demonstrate 
interoperability or other results useful to determining the progress of the 
specification in terms of operational experience.

For more information on the GGF Document Series see:

        http://www.ggf.org/documents/

Dane: Last call for publication; Send note to Editor for approval as an experimental document

I can't find any non-manually intensive manner (and error prone) manner to convert to plain ascii. Reading the GGF document process, I interprete PDF 
and ascii as being equivalent in terms of preference and hence submit a PDF version.

I believe (like Appendix A) the revision dates should be removed from 
the front page by the Editor before publication. GFD's are not revised.

Since there are no graphics or tables, this document would be well
suited to ASCII text formatting as per the GFD.1 stated I-D format preference.
Can this modification be readily done by the authors or the editor's staff ?
Do the authors have strong objections ? 

Ready for publication (after those editorial changes)

New version modified to be experimental rather than recommendation.

Document has finished public comment. You may review comments made at https://forge.gridforum.org/forum/forum.php?forum_id=389. 

The following was a statement made about moving this document forward.

Von Welch 
Subject: Note to Editor: Do not advance this document[ Reply ] 
Date: 2004-04-23 
The working group is discussing changing this document to Experiemental rather  than Recommendation to avoid conflict with the IETF.

Test, please ignore

This document (in my opinion) looks ready, but needs to be reviewed by IETF CAT (or KITTEN) working group to see if there are any concerns from IETF 
community.

Document re-entered 60 day public comment period after a new version (v11) was submitted after the last public comment period. Due date: 5/3/2004.

New version of document with comments from Matt Crawford Addressed.

Von Welch making revisions to address comments made.
One resolution will result in dropping an underspecified parameter
from a pair of function calls. This will result in potential incompatabilities between the final version and implementations based on the previous 
draft.
A return of the revised document for public comment is probably appropriate.
However, since the community of implementers should be largely represented
on the discussion list, the recommended change was made at the beginning
of the comment period, and no objections have been raised, a 30 day public comment period for this cycle is probably sufficient.

Comment from Matt Crawford that needs to be addressed:

http://www-unix.gridforum.org/mail_archive/security-wg/2003/12/msg00003.html

Basically strike the protection key argument from export_cred() and import() cred since it is under specified and no champion was found.

This document seems mature and ready for GGF public comment in my opinion. There are a few questions that come to mind in 
reviewing the draft. 

Process:

This is a clear case of a GGF document extending a standard
created by another body (IETF RFC 2743,2744 in this case) and
we should consider process for such cases. These are likely to arise and not clearly undesireable. It is, in my opinion, more
desireable to minimally extend existing protocols than invent new ones from whole cloth. I believe we should propose such
extensions to the original body, and if no receptive collaboration can be created, then GGF creates a document such
as this one. I believe it appropriate for each major stage of approval in the GGF cycle the work be recommunicated to the 
original body for possible integration.

That matches my understanding of how this particular document
has progressed thus far.  Would the next major stage be at
the public comment transition or the GGF publication transition ?

Content:

The second paragraph of the introduction seems to imply a definition of 
GSI as an implementation of GSS-API (differing, presumably
only by these extensions). This seems an unusually narrow
definition of what is usually meant by GSI in Globus documentation. Perhaps this is an error and the first sentence should be reworded ?

If this IS a definition of GSI, then the distinctions of whether 
these extensions MUST be implement, SHOULD be implement
or MAY be implemented for a compliant implementation of GSI should be clarified.

The routines in section 2 do not specify behaviour for the 
various error codes -- which are to be fatal, which can/should be retried. Is this desired/needed ?

 I believe paragraph 6 in section 2.1 should begin "When option_req is equal to 1..." to parallel the preceeding paragraph.

It is not clear whether paragraphs 7&8 in section 2.1 are
intended as normative specifications for behaviours of applications using these extensions or rather descriptive
warnings of unspecified behaviours.

I believe there's a transposition of words (or some other 
grammar error) in 2nd to last paragraph of section 2.1.2.
Perhaps it should be "...MAY request a length of time for 
which the acquired credential is to be valid..."

The last paragraph of section 2.2 has a couple typos:
"...sequence of calls needed to perform..."
"...has yet to complete, the results..."

The number of "desired_object" in section 2.3.1 is 
unclear. Is this a single object being referenced (one OID)
or 1 or more objects (a sequence of OIDs) ? I suspect a typo
on the word "objects".

Typo in the first bullet of section 5.1 -- should end "policies."



Format:

Under Status of the Memo, the text "The latest version..."
should be removed or replaced with the permanent link when
the document is frozen. Who does this and how ?

Similarly, it seems that at some point soon in the process the 
change log section of the document should be removed.
These are handy sections to keep in documents during creation and edit cycles, but don't seem appropriate for intitial formal 
publication.