cutting the tie with rfc2223bis

["C. M. Heard" <heard@pobox.com>]

On Tue, 8 Jun 2004, Wijnen, Bert (Bert) wrote:
> I think it would be better if we could write our text such that
> 2223bis is NOT normative. I am not very confident that that doc
> will come out as an RFC anytime soon. It has been promised too
> many times already.
...
> So we should not make ourselves dependent on 2223bis. Or so is
> my personal (actaully pretty strong) opinion.

I suppose that we could try to cut the tie with 2223bis, but before
we do so there are a few things I would like to point out.

From the very beginning Section 3, "General Documentation
Guidelines" has relied very heavily on 2223bis.  The reason I did
that was because I thought that we wanted our draft documents to be
as close as possible to the final published form as described in
2223bis, in order to make the publication process go more smoothly.  
I think we still want to do that, and for that reason I see a great
deal of value in having our review guidelines closely aligned with
the requirements for published RFCs.

In order to eliminate 2223bis as a normative reference it will be
necessary to do a fair amount of rework on Section 3.  If the
consensus is that we need to do that, then I am willing to do the
work;  however, it will take some time.

I know that Bert would like to get the document into last call as
soon as possible, but I would rather not push something out the door
before it is ready.  As things now stand, it is becoming clear to me
that we are not nearly as close to being finished as I thought we
were.  When we issued the -02 version of the guidelines document in
August the only open issue listed was that the document needed to be
aligned with the (then forthcoming) IPR documents, and I expected
that to be easy.  Unfortunately, I was wrong.  Not only has it
turned out to be more of a hassle than expected to integrate the IPR
changes -- and I don't mean just for us, witness the discussions on
the WG Chairs list and the fact the there are still references to
RFC 2026 in http://www.ietf.org/ietf/1id-guidelines.txt) -- but also
we had new requirements imposed by ID-Checklist.  Having to rework
Section 3 to eliminate 2223bis as a normative reference will be yet
another step back.

I also have to say that even if we had well-polished text today, I
would still expect that it would take some time for both the
reviewers and the authors to adjust to the changes.  Without having
some "running code" experience, I am not at all sure that it would
be wise to push this document into last call at this time.

Rather than pushing for a "final" version that is not likely to be
quite right owing to the time pressures, I think it might be better
to concentrate on releasing the changes that _have_ to be made to
bring the MIB review guidelines into compliance with current
policies.  We can then get some "running code" experience while we
are hashing out the rest of the changes.

Mike