[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Demoting rfc2223bis to an informative reference
Inline
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of David B Harrington
> Sent: Monday, January 10, 2005 13:55
> To: 'C. M. Heard'; 'Mreview (E-mail)'
> Subject: 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 sort of agree in principle. But pratice shows that too much things
do change over time, and so those need to be taken into account.
In fact, I believe we have even changed some of our technical MIB opinions
over the last 2 years since we have been discussing these guidelines.
We DO live in a changing world. That is life.
> 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.
If the authors turn around a new rev quickly then normally that will
not happen. Some authors take years to finis a MIB document, and I
can sort of guarantee you that the rules/guidelines/requirements/prcoedures
(or at least some of that set) will change.
> 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.
>
You know... if doc authors/editors use the xml2rfc tools, then 90% of the
changing-stuff is taken care of automagically and they would not have to worry,
and we would not have to keep "nit-picking" on those things.
I think it would be betetr to try and get everyone converted to that tool.
>
> 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.
>
Oh well...
Bert
> 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
> >
> >
> >
>
>
>