[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Demoting rfc2223bis to an informative reference
Hi,
I think it is a bad idea to make a web page the normative reference.
We need to be sure MIB Doctor guidelines are consistent over time.
I don't want to do a first review of a document against one set of
guidelines and a second review of the document against a changing set
of guidelines.
We need to help authors and WGs get their documents through the
process, not keep building new roadblocks for them to overcome.
Making our guidelines dependent on "documents" that are allowed to
change without RFC republication is a wrong approach in my view.
I can accept a guideline that says a document initally published (i.e.
-00-) after the publication date of this guidelines RFC
1) MUST meet the requirements of the [rfc2223bis] RFC and
2) MUST meet the specific mib-relevant alternative requirements
speifcied in this guidleines RFC, and
3) the document and subsequent revisions SHOULD meet the updated
requirements found in http://www.ietf.org/ietf/1id-guidelines.txt and
http://www.ietf.org/ID-Checklist.html
This allows an author who starts a -00- document after the publication
of [rfc2223bis] and this guidelines RFC and before an updated
http://www.ietf.org/ietf/1id-guidelines.txt is made available to have
their document accepted as compliant to the then-current requirements.
One of the problems I have encountered in the bridge WG is that the
boilerplates changed during post-00- revisions and the editors were
required to update their documents to the new boilerplates. While
boilerplates might be nice for IETF publication reasons, they offer NO
interoperability benefit to operators and they offer NO
revenue-generation benefit to vendors; requiring vendor-sponsored
editors to waste precious manhours updating documents to moving
targets is a pure cost-sink activity. This makes it harder to get
vendors to sponsor editors. We need STABLE requirements against which
documents should be checked, not moving targets.
I disagree with trying to demote [rfc2223bis] to an informative
reference by making a web page the normative reference.
David Harrington
dbharrington@comcast.net
> -----Original Message-----
> From: owner-mreview@ops.ietf.org
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> Sent: Monday, January 10, 2005 6:44 AM
> To: Mreview (E-mail)
> Subject: Demoting rfc2223bis to an informative reference
>
> MIB Doctors:
>
> Bert has already looked over the following. If I hear no objections
> the proposed modifications will appear in the next spin.
>
> Mike
>
> ---------- Forwarded message ----------
> Date: Sun, 9 Jan 2005 15:00:47 -0800 (PST)
> From: C. M. Heard <heard@pobox.com>
> To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> Subject: Re: FW: Status of draft-rfc-editor-rfc2223bis-08.txt
>
> On Fri, 7 Jan 2005, Wijnen, Bert (Bert) wrote:
> > It looks to me, that we might be better of if we can massage
> > things such that 2223bis becomes an informative ref
>
> OK, I looked over the text again, and here is what I come up with.
> Let me know what you think.
>
> > In general, IETF standards-track specifications containing MIB
> > modules are subject to the same requirements as IETF
> standards-track
> > RFCs (see [RFC2223bis]), although there are some differences.
In
> > particular, since the version under review will be an
> Internet-Draft,
> > the notices on the front page MUST comply with the
> requirements of
> > http://www.ietf.org/ietf/1id-guidelines.txt and not with those
of
> > [RFC2223bis]. In addition, since the specification
> under review is
> > expected to be submitted to the IESG, it MUST comply with
certain
> > requirements that do not necessarily apply to RFCs; see
> > http://www.ietf.org/ID-Checklist.html for details.
>
> I think we could make the case that in this paragraph the reference
to
> 2223bis is informative ... the normative stuff in that in
> 1id-guidelines
> and ID-Checklist. At least that was my intent when I wrote it. So
I
> propose to make no change here.
>
> > Section 4 of [RFC2223bis] lists the sections that may exist in
an
> > RFC. Sections from the abstract onward may also be present in
an
> > Internet-Draft. The "body of memo" is always required,
> and in a MIB
> > document MUST contain at least the following:
>
> This reference is clearly normative, but I think we can justify
> demoting it if we also provide a pointer to ID-Checklist. So here
> is the proposed replacement text:
>
> Section 4 of [RFC2223bis] lists the sections that may exist in an
> RFC. Sections from the abstract onward may also be present in an
> Internet-Draft; see http://www.ietf.org/ID-Checklist.html. The
> "body of memo" is always required, and in a MIB document
> MUST contain
> at least the following:
>
> > 2-----------
> > Section 4.7f of [RFC2223bis] specifies the requirements for the
> > references sections. In particular, there MUST be
> separate lists of
> > normative and informative references, each in a separate
section.
> > The style SHOULD follow that of recently published RFCs.
>
> Similar considerations apply here. Proposed replacement text:
>
> Section 4.7f of [RFC2223bis] specifies the requirements for the
> references sections in an RFC;
> http://www.ietf.org/ID-Checklist.html
> imposes the same requirements on Internet-Drafts. In particular,
> there MUST be separate lists of normative and informative
> references,
> each in a separate section. The style SHOULD follow that
> of recently
> published RFCs.
>
> > 3------------
> > 2.) Abstract -- verify that the abstract does not
> contain references,
> > that it does not have a section number, and that its
> content follows
> > the guidelines in [RFC2223bis].
>
> I could replace [RFC2223bis] by
> http://www.ietf.org/ietf/1id-guidelines.txt
> since they say the same thing about abstracts. This is the
> proposed text:
>
> 2.) Abstract -- verify that the abstract does not contain
> references,
> that it does not have a section number, and that its
> content follows
> the guidelines in http://www.ietf.org/ietf/1id-guidelines.txt.
>
> I am a little bit uncomfortable about the second item in the
> list (I feel
> that I am being a little bit slippery) but if you are OK with
> this I can
> live with it too.
>
> Mike
>
>
>