[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed "Last Call" version of draft-ietf-ops-mib-review-gui delines [ Corrected, for the 2nd time ]
- To: "C. M. Heard" <heard@pobox.com>, "Mreview (E-mail)" <mreview@ops.ietf.org>
- Subject: RE: Proposed "Last Call" version of draft-ietf-ops-mib-review-gui delines [ Corrected, for the 2nd time ]
- From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
- Date: Mon, 3 Jan 2005 13:39:58 +0100
Thanks Mike.
And a Happy new year and all the best for 2005 to all of you.
I propose that we take a week (so till Jan 10th) to do review among
MIB doctors. Pls do review if at all possible.
Meanwhile I will do follow up on my things (as listed by Mike below).
If all looks good next week, we'll issue a 4 week IETF Last Call.
Bert
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of C. M. Heard
> Sent: Sunday, January 02, 2005 07:38
> To: Mreview (E-mail)
> Subject: Proposed "Last Call" version of
> draft-ietf-ops-mib-review-guidelines [ Corrected, for the 2nd time ]
>
>
> [ re-sent, again, to fixdouble line-break problem in attachments ]
>
> MIB Doctors,
>
> Let me begin by wishing everyone a productive 2005. In that spirit,
> I have attached a proposed update for the MIB review guidelines
> document for your review, along with a context diff showing the
> proposed content changes. If everyone here agrees, I think this
> version would be suitable to go to IETF last call.
>
> My main objective in producing this update was to resolve lingering
> inconsistencies between draft-ietf-ops-mib-review-guidelines-03.txt
> and the updated "Instructions to RFC Authors" draft and IPR
> documents, available at ftp://ftp.rfc-editor.org/in-notes/authors/
> as draft-rfc-editor-rfc2223bis-08.txt and rfc390[78].txt,
> respectively. This has resulted in a re-organization of Section 3
> and the checklist and some relocation of other sections, but there
> have been only minimal content changes as a result of this effort.
> In order to make this clear, the the context diff that I've attached
> omits all diffs that were just a result of the document
> reorganization -- it only shows the actual changes to the content.
>
> My second objective was to fix up inadequacies that have been
> exposed as a result of actual experience in using the document. This
> resulted in two changes: I added some text stating that it's not
> necessary to have paired 32 and 64 bit counter objects (although
> that is still allowed), as requested by Joseph Dinakaran; and I
> removed the checklist item for the copyright notice on the front
> page, as requested by Dave Thaler.
>
> There were a couple of other things that people brought up that I
> did NOT fix. One was the following from request Dave Thaler:
>
> > In section 4.6.1.7 (IpAddress), it would be good to provide more
> > guidance on when it's acceptable to vary from the SHOULD.
> > (Same comment can be applied to 3291bis as well.) Specifically
> > one example is a MIB object which instruments an inherently
> > IPv4-specific thing.
>
> I did not make this change because it was not clear to me that there
> is any situation where it would be acceptable to use IpAddress in a
> new standards-track MIB module. If a consensus exists that it is
> acceptable to do so under certain circumstances, and if someone will
> supply the text saying what those circumstances are, then I will be
> happy to incorporate the change, but otherwise I'm going to leave
> things as they are.
>
> The other item was this:
>
> > -----Original Message-----
> > From: Michelle S. Cotton [mailto:cotton@icann.org]
> > Sent: Thursday, December 02, 2004 07:27
> > To: Bert Wijnen (Bert)
> > Subject: FW: Fwd: RE: Evaluation:
> > draft-ietf-ipv6-rfc2013-update-04.txt
> > to ProposedStandard
> >
> >
> > Bert,
> >
> > I think there is a follow-up question here with regards to the
> > MIB review guidelines text.
> >
> > Not sure what we need to do for the future. I believe that
> > all is OK for the document to go forward.
> >
> > Michelle
> >
> > -----Original Message-----
> > From: John Flick [mailto:john.flick@hp.com]
> > Sent: Thursday, October 28, 2004 4:36 PM
> > To: Bill Fenner
> > Cc: margaret@thingmagic.com; narten@us.ibm.com; bwijnen@lucent.com;
> > bob.hinden@nokia.com; brian@innovationslab.net; cotton@icann.org;
> > iana@iana.org
> > Subject: Re: Fwd: RE: Evaluation:
> > draft-ietf-ipv6-rfc2013-update-04.txt
> > to ProposedStandard
> >
> >
> > I agree with Bill.
> >
> > Note to Bert: The IANA Considerations text that prompted
> this question
> > from IANA was the verbatim text recommended in section 3.7.3 of the
> > MIB review guidelines. Do we need to consult with IANA to determine
> > what this text should look like so that they don't need to come back
> > and request clarification? If so, we should update the MIB review
> > guidelines to make sure that the IANA considerations lets IANA know
> > what they need to do.
> >
> > John
> >
> > Bill Fenner wrote:
> > >>Do we need to change the references for those mib-2 values
> > >>or do they remain the same?
> > >
> > >
> > > The references for {mib-2 7} and {mib-2 50} should be updated to
> > > this spec, yup. I don't think there are any other IANA actions.
> > >
> > > Bill
>
> I wrote a follow-up note to Michelle Cotton asking if any changes
> were necessary, but I didn't receive a reply, so I haven't made any
> changes. Maybe we'll get some comments in last call about this; if
> we do I guess we can resolve them at that time.
>
> I have a couple of questions regarding references. The proposed
> updates points to RFCs 3907 and 3908 even though they are still in
> AUTH48. I'm hoping that these will indeed be published by the time
> it's time to post the draft. Second, I still have two normative
> references to documents whose publication status is uncertain -- I
> refer here to rfc2223bis and rfc2737bis. Bert, can you check on the
> status of these things and do whatever nudging is appropriate to
> move them along, particularly 3907 and 3908, which have been in
> AUTH48 since early November?
>
> Regards & thanks,
>
> Mike
>