Subject: PWG> Re: PMP> The Goal is Draft Standard

From: [email-masked] (Bill Wagner)
Date: Tue, 24 Dec 1996 10:52:51 -0500

Chris,
     
     Thank you for your statement and 'call to arms'. Although it is quite 
     clear, the interpretation of the first dictate might stand a bit of 
     elaboration as we decide how to proceed. Specifically:
     
     "(1)  The revised draft must include a list of the 
     substantive changes to RFC1759 and the justification for 
     each change (the changes *must* be for clarification and 
     correction, they *cannot* be new features)."

     I take this to mean that every substantive change (including each 
     additional object) must 'fix' something that the documented 
     implementation experiences show as being broken. Presumably, 
     substantive changes intended to address perceived but not demonstrated 
     deficiencies would keep the new RFC at proposed standard level. Is 
     this a correct assessment?
     
     Seasons greetings to the PWG.
     
     Bill Wagner, DPI

---

From: Chris Wellens <[email-masked]>
Date: Sat, 28 Dec 1996 14:12:12 -0800 (PST)

On Tue, 24 Dec 1996, Bill Wagner wrote:

[stuff deleted]

>      implementation experiences show as being broken. 

Yes, that is correct.

>      this a correct assessment?

Actually, it is worse than that.  If there are substantive 
changes, then the group has two choices:  (1)  start over as 
a new Proposed Standard, and restart the clock, meaning get 
re-published, get implementation experience, etc. (2) let RFC
1759 go forward as is with only the clarification and 
correction changes, and role the new substantive changes 
into something like the Printer MIB 2 and start that process 
going.

This is a little subtle, and I am taking what you wrote 
literally.  Basically there's no way to have RFC 1759 
include the substantive changes and stay as is.  Currently 
the document that does include the substantive changes is 
the XXXX document and that is an "internet-draft", and 
considered a "work in progress" and is not on the standards 
track.  Whereas, RFC 1759 is already beyond that because it 
is on the bottom rung of the Standards track as a Proposed 
Standard.

What I would really hope we could do is put together
very compelling arguments for the substantive changes
explaining why they are really "corrections".  For any
that we just could not justify this way, we could put
them in the Appendix to the RFC as optional recommendations 
for implementations (Lloyd and I learned about this at the
class for new WG chairs).