On Tue, 24 Dec 1996, Bill Wagner wrote:
> 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.
Yes, that is correct.
> substantive changes intended to address perceived but not demonstrated
> deficiencies would keep the new RFC at proposed standard level. Is
> 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
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
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).