[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 14:20
> To: 'C. M. Heard'; 'Mreview (E-mail)'
> Subject: RE: Demoting rfc2223bis to an informative reference
>
>
> Hi,
>
> If the goal is to try to break the dependency on a
> slow-to-be-finalized RFC, then I suggest a better approach would be to
> separate the document publication rules and the mib development
> guidelines - have any guidelines about publishing mib documents in the
> IETF system, e.g. mib boilerplates and mib security boilerplates and
> mib document IPR and mib document requirments for
> normative/informative references, moved into [rfc2223bis] (and
> http://www.ietf.org/ietf/1id-guidelines.txt and
> http://www.ietf.org/ID-Checklist.html) and make the mib guidelines
> document only about developing mibs, not about IETF document
> publication policies.
>
MIB document authors like to have a single place where they can find all
the things they need to do in order to get a document past AD and MIB Doctor
review. And that includea dmin/bureaucratic stuff.
> MIB Doctirs shouldn't have to waste time reviewing whether the
> boilerplate is the most current revision, and whether the IPR
> statement is the right revision, and whether normative/informative
> references have been handled properly, and whether lines are less than
> 70 characters in length, etc. That should be handled by an
> IETF-publication-review-doctors group employed by the RFC-editor or
> the IESG for that specific purpose. MIB Doctors should be asked to
> review submitted mib modules for their mib design.
>
I can agree with that, and I have no problem if MIB doctors tell me
we will only look at MIB issues, not at all the references and
idguidelines and ID-Checklist.
In fact for a lot of it we have tools like idnits and I personally have
a findref tool to check some of the referencing stuff.
> Bert, you have expressed concern about not having MIB doctors
> available for all the documents you need reviewed. If the job was
> about reviewing mib module designs rather than verifying IETF
> publication rules compliance, we might find more time to review mib
> modules for you.
>
So either way works for me. If a MIB doctor tells me
- I will review technical MIB stuff, you (AD) take care of nits and such
- I will review everyting, including nits and such.
As longs as I know, and as long as we are clear in our feedback, so that the
AD (and authors) know what to do and expect.
I continue to think that having all that checking stuff consolidated in one
place (this review guidelines) would be a good thing (but this is my
personal opinion). Certainly now that we are so close to have it finished.
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
> >
> >
> >
>
>
>