|
|
|
Charlie Catlett: 08/09/2004 2:16 PM EST
|
| |
Comment: |
Mass Update
|
| |
Action: |
Update
artifact_status changed from Open to Closed
close_date changed from - to 2004-08-09 14:16:20
|
|
|
Charlie Catlett: 06/29/2004 5:39 PM EST
|
| |
Comment: |
Mass Move
|
| |
Action: |
Update
artifact_group changed from Individual Submission to <None>
assigned_to changed from 108 to 100
Category changed from Unsure to <None>
group_artifact_id changed from Submit GGF Draft to Trashcan
|
|
|
Charlie Catlett: 06/29/2004 5:37 PM EST
|
| |
Comment: |
This document will be published in the GGF Document series
as a PROPOSED RECOMMENDATION.
A Proposed Recommendation may advance to become a
RECOMMENDATION according to the process outlined in
GFD.001. (see below). Implementation and experience
with this proposed recommendation is encouraged. The
characteristics of a PROPOSED RECOMMENDATION are
also excerpted below from GFD.001.
For more information on the GGF Document Series
see: http://www.ggf.org/documents/
---- begin excerpt 1 from GFD.1 (advancing to REC) ----
3.4.2 GGF Recommendation
Once a document is published as a GFD-R-P, a 24-month
timer will begin during which period it is expected that
operational experience will be gained will mean that at
least two interoperable implementations (from different
code bases and, in the case of licensed code, from two
separate license agreements) must be demonstrated
(if appropriate). The entire protocol or specification
must be implemented in the interoperable
implementations. The GFSG will determine whether
interoperable implementations (or implementations in
software at all) are necessary or whether operational
experience can be gained in a more appropriate fashion.
A document must remain at the GFD-R-P level for a
minimum of 6 months.
Within the 24-month period that begins with publication
as a GFD-R-P, the operational experience must be
documented in the form of one or more GFD-E
documents. When the working group chairs determine
that sufficient operational experience has been
achieved and documented, they will submit a request,
along with a summary of the GFD-R-P and the
associated GFD-E documents, to the GFSG for review.
The review will focus on the operational experience as
it relates to verifying feasibility and utility of the GFD-R-P
recommendations.
---- end excerpt 1 from GFD.001 ------------
---- begin excerpt 2 from GFD.001 (defines GFD-R-P) --
A Proposed Recommendation (GFD-R-P) is analogous to a
"Proposed Standard" in the Internet Standards Process:
"A Proposed Standard specification is generally stable,
has resolved known design choices, is believed to be
well-understood, has received significant community
review, and appears to enjoy enough community
interest to be considered valuable. However, further
experience might result in a change or even retraction
of the specification before it advances.
Usually, neither implementation nor operational
experience is required for the designation of a
specification as a Proposed Standard. However, such
experience is highly desirable, and will usually
represent a strong argument in favor of a Proposed
Standard designation."
[RFC 2026, Section 4.1.1, p. 12]
---- end excerpt 2 from GFD.001 (defines GFD-R-P) --
|
| |
Action: |
Update
|
|
|
Charlie Catlett: 06/29/2004 5:30 PM EST
|
| |
Comment: |
This document will be published in the GGF Document series
as a PROPOSED RECOMMENDATION.
A Proposed Recommendation may advance to become a
RECOMMENDATION according to the process outlined in
GFD.001. (see below). Implementation and experience
with this proposed recommendation is encouraged. The
characteristics of a PROPOSED RECOMMENDATION are
also excerpted below from GFD.001.
For more information on the GGF Document Series
see: http://www.ggf.org/documents/
---- begin excerpt 1 from GFD.1 (advancing to REC) ----
3.4.2 GGF Recommendation
Once a document is published as a GFD-R-P, a 24-month timer will begin
during which period it is expected that operational experience will be gained
will mean that at least two interoperable implementations (from different code
bases and, in the case of licensed code, from two separate license
agreements) must be demonstrated (if appropriate). The entire protocol or
specification must be implemented in the interoperable implementations. The
GFSG will determine whether interoperable implementations (or
implementations in software at all) are necessary or whether operational
experience can be gained in a more appropriate fashion.
A document must remain at the GFD-R-P level for a minimum of 6 months.
Within the 24-month period that begins with publication as a GFD-R-P, the
operational experience must be documented in the form of one or more GFD-E
documents. When the working group chairs determine that sufficient
operational experience has been achieved and documented, they will submit a
request, along with a summary of the GFD-R-P and the associated GFD-E
documents, to the GFSG for review. The review will focus on the operational
experience as it relates to verifying feasibility and utility of the GFD-R-P
recommendations.
------------ end of excerpt 1 from GFD.001 ------------
------------ begin excerpt 2 from GFD.001 (definition of GFD-R-P) ----------
A Proposed Recommendation (GFD-R-P) is analogous to a
"Proposed Standard" in the Internet Standards Process:
"A Proposed Standard specification is generally stable, has resolved
known design choices, is believed to be well-understood, has received
significant community review, and appears to enjoy enough community
interest to be considered valuable. However, further experience
might result in a change or even retraction of the specification
before it advances.
Usually, neither implementation nor operational experience is
required for the designation of a specification as a Proposed
Standard. However, such experience is highly desirable, and will
usually represent a strong argument in favor of a Proposed Standard
designation." [RFC 2026, Section 4.1.1, p. 12]
|
| |
Action: |
Update
|
|
|
Charlie Catlett: 06/29/2004 5:30 PM EST
|
| |
Comment: |
This document will be published in the GGF Document series
as an INFORMATIONAL type document.
An INFORMATIONAL type document is intended to inform
the community. It is not intended to define any standard
or recommendation, nor does it necessarily represent
community consensus or endorsement.
For more information on the GGF Document Series
see: http://www.ggf.org/documents/
|
| |
Action: |
Update
|
|
|
Charlie Catlett: 06/29/2004 5:29 PM EST
|
| |
Comment: |
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/
|
| |
Action: |
Update
|
|
|
|
