Should the referenced specs be updated? (Re: [ogsa-wg] Teleconference minutes - 8 June 2005)

[Hiro Kishimoto]

Hi Tom and Dave,

I took a homework assignment of farther study on if we should update
referenced spec in BP 1.0 or not.

After due consideration with Andreas, We arrive at a conclusion.
Well, our short answer is "yes, OGSA-WG should."

Here is our long answer.

(1) We believe that our current definition of "emerging institutional
standard (EIS)" needs some work. The main distinction at the moment is
that "a specification of this status type must have an externally stable
reference to the specification." But to some extent this is already a
requirement of all specifications referenced by a profile (section 3.1).

The main distinction should be instead on whether there is a draft that
has been approved as a 'stable draft' by some process of that standards
organization; including satisfying the intellectual property
considerations of that standards body. (For example, it would be
inappropriate for an EIS to refer to a "Draft specification" with
unclear IPR.)

So, for example, an OASIS committee draft (CD) would be a EIS. (But a WD
 would not.) So would a GGF Grid Working Draft (GWD-R.P), since it has
been approved as a draft by the GFSG.

A problem with the above definition is that a GGF WG draft that has not
been submitted to the GGF Editor has no suitable status. At this moment,
we have plenty of such documents, e.g. OGSA WSRF BP 1.0, JSDL 1.0, and
RNS 1.0.

So we'd also propose adding a new "status type" something like "draft
institutional standard." Otherwise, we cannot include the above
mentioned draft specs in the OGSA Roadmap tables.

(2) We should add one more restriction to "recommendation profile
as proposed recommendation." The additional restriction would highlight
that the set of specifications in a profile should be consistent.
In other words, if a specification is referenced directly or
indirectly (transitively) by different specifications in a profile then
the same version should be referenced.

Please have a look to modifications proposal to profile definition
attached to this email.

(3) Let's assess the OGSA WSRF BP 1.0 referring specs and profiles based
on the above two criteria.

Currently the WSRF BP 1.0 refers to
a) WS-Addressing (2004-08-10)
b) WSRF 1.2 working drafts
c) WSN 1.2 working drafts
d) WS-I BP 1.1 and BSP 1.0

(a), (b), and (c) run into problems with criteria (1) and (2). For
example, the WS-Addressing reference fails criterium (1) (intellectual
property considerations since it refers to ws-policy). WSRF 1.2 refers
to a newer version of WS-Addressing so it causes an inconsistent set of
references.  (The referenced WSRF 1.2 version is also a working draft
not a committee draft.)

For (a) and (b) new versions that satisfy the proposed criteria exist.
But an appropriate draft for (c) is not available yet. (WSN spec series
1.2 refer to WS-addressing member submission dated 2004-08.)

So we should update the WSRF BP 1.0 to the following versions before
submission:

- WS-addressing 1.0, 2005-03-31.
- WSRF spec series 1.2 committee draft
- WSN spec series 1.3 committee draft (not available yet)
- WS-I BP 1.1 and BSP 1.0

Good news is WSN-TC will move 1.3 to CD early July. We only need to wait
for one or two weeks and then finalize our WSRF BP 1.0.
-- 
Hiro Kishimoto


Andreas Savva wrote:
> OGSA Teleconference - 8 June 2005
> =================================
> * WSRF Basic Profile (BP) review
> 
> ** Should the referenced specs be updated?
> 
>    The WSRF BP is referring to an old (2004), somewhat inconsistent,
>    set of specs for WS-Addressing, WSRF and WS-N. (Ref. WS-Addressing
>    discussion). A number of recent developments might offer an
>    opportunity to fix this:
>    - WS-Addressing specs (last call)
>    - The OASIS WSRF TC has a ballot closing at the end of this week
>      (Sat., June 11 (1pm Eastern)) to send out the WSRF set of
>      committee draft documents for public review
>    - The WS-N group is planning to release committee drafts of the
>      Base Notification specification (perhaps July 1) and also of
>      Topics (and maybe also brokered notification).
> 
>    So it looks like there will be an updated, consistent set of
>    documents to refer to. The problem is whether, and how, to keep the
>    deadline for submitting the document to the GGF Editor (next week)
>    and also make sure that the WSRF Basic Profile can be updated to
>    use these specs when they come out.
> 
>    At the very least the changes required to the BP would be to the
>    References, Namespaces and links to imported schemas.
>      - For the WSRF and WS-Addressing specification these are (almost)
>        known.
>      - But the WS-N ones are not completely fixed yet.
> 
>    A number of scenarios were discussed:
>    
>    1. Wait for the new versions to come out, update the BP and submit
>    2. Submit the document as-is and then put a public comment that it
>       should be updated with the new WSRF+ set of specifications when
>       they come out.
>    3. Put a comment in the document that it will be updated with the
>       new WSRF+ set of specs and submit it as-is.
> 
>    - Scenario (3) was rejected since it clearly bends the rules too
>      much.
>    - Scenario (1) is the safest one but it keeps the BP queued and
>      waiting for the updated specifications.
>    - Scenario (2) follows the GGF process---the editors/authors are
>      also encouraged to submit comments. But if there is a delay in
>      the release of the referenced specs then the BP goes through
>      as-is; or if there is a need for more changes than anticipated
>      then a second round of public comment would be required.
> 
>    The remaining issue about scenario (2) was whether we are relaxing
>    the submission rule as defined by "Profile Definition". The key
>    point is whether the current draft of the BP, referencing old
>    WS-Addressing, WSRF and WS-N drafts, qualifies for submission to
>    the GGF Editor. In other words are the references used 'stable' and
>    could the BP proceed to R-P status, potentially without any of the
>    above changes.
> 
>    It was argued that the definition of 'stable' is that
>    specifications must be at least 'committee drafts'. And that the
>    existing referenced specs, even if they are not called 'committee
>    drafts' have been through a similar process and are therefore of an
>    equivalent level. In particular, it was proposed that the new OASIS
>    type of "working draft" is equivalent to a "committee draft" since
>    there is a vote by the TC to make such documents public.
> 
>    There was no consensus, however. The preference on the call was for
>    scenario (2) and (1) in that order. The 'stable' reference rule
>    needs more clarification, however.
> 
>    Action: Hiro to follow up on the definition of 'stable' and whether
>            the specifications in question satisfy that rule.
>        
>    Also, if the group decides to go with (2) then the group has to
>    discuss and agree on what the public comment should say.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-ggf-ogsa-profile-definition-10-a.doc
Type: application/msword
Size: 191488 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-wg/attachments/20050614/10f48185/attachment.doc