RE: Proposed "Last Call" version of draft-ietf-ops-mib-review-guidelines [ Corrected, for the 2nd time ]

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

Mike,

At IETF61 in the Bridge MIB WG meeting the issue was raised about the usage of the guidelines document for reviewing and as a guidelines for editors of documents defining MIB modules from outside of the IETF (see http://www1.ietf.org/proceedings_new/04nov/minutes/bridge.html). One of the options I had in mind was a possible section that mentions the non-IETF specifics and possible relaxation of some of the rules that would allow for the guidelines to be used in a more convenient manner by non-IETF consistencies. I apologize for raising this in a thread that tries to get this extremely useful work closer to completion, but is it too late to discuss this issue?

Thanks and Regards,

Dan



> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org]On Behalf Of C. M. Heard
> Sent: 02 January, 2005 8:38 AM
> 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
>