Subject: Re: [Policy] Fw: DMTF Release Process

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 2 Oct 2001 09:55:56 -0400

1.  In addition to Bob's  reference to the table, there is a paragraph in
section 1.4 that says:
"There are no changes to a Final Standard. All corrections to a Final
Standard must be handled as ERRATA and cause the version number of the
Standard to be updated."

Between this sentence and the table entry, I think it's pretty clear that
the policy is that final standards are immutable and permanently available
to public on the DMTF web site.  What is your interpretation for these
portions of the document?  Do you think it says something different?  And,
as Bob said, URLs are not specified in the release process.

2. Maybe you've forgotten, John, but the method we have been following for
syncronizing the DMTF and IETF documents is to take the DMTF documents to
preliminary standard while the IETF is finishing its deliberations and then
during last call and IESG deliberations we get everything synchronized.  It
is a two-phase commit process of sorts.  The normative reference will be
permanent and immutable when it neeeds to be permanent and immutable.  In
this particular case, we don't actually need a two-phase commit since there
aren't mutual dependencies, but we want to wait on committing the DMTF side
until we've had as much opportunity for feedback from the IETF as possible.

3. I don't know where you get the idea that the 2.5 Core mapping (the
normative reference here) needs another 3 months.  The "expiration" of a
minimum period is of no concern here since it is both subject to exceptions
as deemed appropriate by the DMTF ruling bodies and, more to the point in
this case, it's a minimum not a maximum.  The document can and will be made
a final standard when the IETF gets close to locking down its side of the
commit protocol.

4. I don't understand your interest in the process policy references to
implementation experience.  You're right, there is no requirement for
implementation experience in this process document; only notes to the effect
that implementation experience might cause changes during the preliminary
phase.  For the Core mapping, I know of no negative feedback from
implementation experience.

I hope this helps resolve any misunderstandings or concerns. But whether
this does or does not adequately clarify things for you, we're working with
the IESG to resolve any normative reference issues or other process concerns
that might still exist.   Let's get on with the work this group needs to do.
Do we have a draft for last call yet?  As I understand it, the authors are
still trying to iron out some things.  I, for one, would like to see
progress on those substantive issues and a draft that can enter last call.
Lee

----- Original Message -----
From: "John Strassner" <[email-masked]>
To: "Lee Rafalow" <[email-masked]>; <[email-masked]>
Sent: Saturday, September 29, 2001 12:38 PM
Subject: RE: [Policy] Fw: DMTF Release Process

> I'm confused. Your words are great, but this document doesn't match your
> words. Specifically:
>
>   - it does not say that "final standards documents are...
>     permanently available to the public on the DMTF web site".
>   - it does not specify the address of which of the DMTF web
>     sites the documents can be found
>
> Furthermore, I fail to see how this helps. Both of the referenced DMTF
> drafts are NOT final standards. The DSP0100.doc spec has no marking on it,
> other than a footer which says "This is a draft specification and subject
> to revision", which is hardly ready to be used as a normative reference.
> The DSP0123.pdf spec is marked "Preliminary", but has a date of June 5,
> 2001. This means that its minimum 3 month review period has expired. But
> in searching the web site, I couldn't find any reference saying whether
> this was approved and going to Final Standard, or needed more work.
> Finally, I was surprised that the memo you forwarded did not specify the
> web site addresses that these specs could be found at.
>
> Even more disconcerting is the fact that your immutability claim is ONLY
> covered for Final Standard. Both of the referenced documents are not Final
> Standards, and need at least another 3 months for Preliminary Review plus
> some undefined period to achieve Final Standard status. Therefore, there
> is no guarantee that these documents can in fact
> be referenced normatively. Plus, whatever happened to implementation
> experience? It is referred to, but is NOT required.
>
> After waiting for almost two months for this non-event, I now think that
> we should make the references non-normative.
>
> John
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lee Rafalow
> Sent: Thursday, September 27, 2001 11:58 AM
> To: [email-masked]
> Subject: [Policy] Fw: DMTF Release Process
>
>
>
> > For those interested, the DMTF has updated its document release policies
> to
> > facilitate IETF collaboration and enable normative references by stating
> > that: documents may be shared during development when the DMTF is
> > collaborating with other organizations; and final standards documents
> are
> > immutable and permanently available to the public on the DMTF web site.
> >
> > See http://www.dmtf.org/download/policies/releaseprocess.pdf
> >
> >
> > Lee M. Rafalow
> > Voice: 1-919-254-4455, Fax: 1-919-254-6243
> > IBM Internet Technology Management
> > IBM Corporation
> > P.O. Box 12195, BRQA/502
> > RTP, NC 27709 USA
> > Alternate email: [email-masked]
> > Personal email: [email-masked]
> >
>
>
> _______________________________________________
> Policy mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/policy
>

_______________________________________________
Policy mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/policy

---

From: "John Strassner" <[email-masked]>
Date: Tue, 2 Oct 2001 11:40:24 -0600

Please see inline.

John

-----Original Message-----
From: Lee Rafalow [mailto:[email-masked]]
Sent: Tuesday, October 02, 2001 7:56 AM
To: [email-masked]; [email-masked]
Subject: Re: [Policy] Fw: DMTF Release Process

<js>
The point that I made was that neither DMTF document IS a Final Standard.
This means that either one can change. So how does this help in making it
a normative reference?
</js>

<js>
I agree that it's clear that Final Standards are immutable. The point is
that neither DMTF document is a Final Standard.
</js>

2. Maybe you've forgotten, John, but the method we have been following for
syncronizing the DMTF and IETF documents is to take the DMTF documents to
preliminary standard while the IETF is finishing its deliberations and
then during last call and IESG deliberations we get everything
synchronized.

<js>
Lee, maybe you forgot that your entire argument is based on the DMTF
document being a Final Standard...
</js>

It is a two-phase commit process of sorts.  The normative reference will
be permanent and immutable when it neeeds to be permanent and immutable.

<js>
What you're saying is that the DMTF is free to modify a document while the
IETF version is in Last Call, and that it won't get to Final Standard
before the IETF version is an RFC. Please tell me how that makes an
acceptable normative reference.
</js>

In this particular case, we don't actually need a two-phase commit since
there aren't mutual dependencies, but we want to wait on committing the
DMTF side until we've had as much opportunity for feedback from the IETF
as possible.

<js>
Of course there are dependencies - the IETF classes are derived from DMTF
classes. If you're so sure that those DMTF classes won't change, why
aren't the DMTF documents Final Standards NOW?
</js>

3. I don't know where you get the idea that the 2.5 Core mapping (the
normative reference here) needs another 3 months.  The "expiration" of a
minimum period is of no concern here since it is both subject to
exceptions as deemed appropriate by the DMTF ruling bodies and, more to
the point in this case, it's a minimum not a maximum.  The document can
and will be made a final standard when the IETF gets close to locking down
its side of the commit protocol.

<js>
Maybe you should reread the process document you sent.

The Core Mapping document has a Status of Preliminary (NOT FINAL STANDARD)
and a date of June 5, 2001. The Process document you sent says, and I
quote: "The Preliminary phase should not be less than three (3)
months unless clear implementation experience justifies this...After the
initial three (3) months, the Technical Committee will review status and
implementation activity, and decide whether or not to extend Preliminary
status on a monthly basis, for a maximum of three (3) months for a total
of six (6) months. At the end of six (6) months, the Technical Committee
can recommend withdrawal of a Preliminary Standard, if there is no
interest in implementation from the industry. In order to reach Final
Standard, all outstanding CRs against the Preliminary Standard must be
resolved."

The minimum three month period expired 5 September, almost one month ago.
There is NO documentation ANYWHERE in a publically accessible DMTF web
site that says that the status has been extended. It's obvious that the
DMTF's own process is NOT being followed here.

And yes, this is relevant because in order to be a normative reference, we
need to be assured that the contents of the document won't change.
</js>

4. I don't understand your interest in the process policy references to
implementation experience.  You're right, there is no requirement for
implementation experience in this process document; only notes to the
effect that implementation experience might cause changes during the
preliminary phase.  For the Core mapping, I know of no negative feedback
from implementation experience.

I hope this helps resolve any misunderstandings or concerns. But whether
this does or does not adequately clarify things for you, we're working
with the IESG to resolve any normative reference issues or other process
concerns that might still exist.

<js>
No, it doesn't. I'm currently editing PCLS, and the LDAP feedback was to
remove normative references. I'm trying to build a compromise but so far,
I have not seen any reliable proof that the referenced documents are
stable and won't change.
</js>

Let's get on with the work this group needs to do.
Do we have a draft for last call yet?  As I understand it, the authors are
still trying to iron out some things.  I, for one, would like to see
progress on those substantive issues and a draft that can enter last call.

<js>
And one of those things is normative references. I can't finish the
document until we sort out what to do with normative references.
</js>

Lee