Guidelines for other SDOs

["David B Harrington" <ietfdbh@comcast.net>]

Hi,

One reason why I think it is worthwhile to provide some guidelines for
other organizations is to make our own team more aware of our
"customer" requirements. Some current and future MIB Doctors may not
have experience dealing with multiple SDOs (I know I wasn't) and the
perspective is slightly different. it would be good to make sure that
future guidelines (and mib reviews) be cognizant of some of those
differences, and mib reviews done for other organizations be
relatively consistent regardless of reviewer.

I do believe that other organizations (SDOs and vendors, etc.) need to
write their own guidelines to codify their specific needs, but for the
syntax and design issues, and for some document reasons (such as
security considerations), it would be good if they were allowed to
benefit from our experience. Putting some of our experience into these
guidelines could help them do a better, more interoperable, job.

dbh

> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org] On Behalf Of David B Harrington
> Sent: Monday, January 03, 2005 5:58 PM
> To: 'C. M. Heard'; 'Mreview (E-mail)'
> Subject: RE: Proposed changes to Section 3 of 
> draft-ietf-ops-mib-review-guidelines
> 
> Hi Mike,
> 
> Comments inline.
> 
> dbh
> 
> > -----Original Message-----
> > From: C. M. Heard [mailto:heard@pobox.com] 
> > Sent: Monday, January 03, 2005 4:07 PM
> > To: Mreview (E-mail)
> > Subject: Re: Proposed changes to Section 3 of 
> > draft-ietf-ops-mib-review-guidelines
> > 
> > On Mon, 3 Jan 2005, David B Harrington wrote:
> > > These guidelines would benefit from being written so they can be
> > > applied by other organizations, including other SDOs and vendors
> > > that develop their own MIB modules.
> > 
> > [ detailed proposals snipped ]
> > 
> > David, these are interesting proposals, and thanks for including a
> > detailed list of proposed changes.  I do have my misgivings about
> > trying to write MIB document guidelines for other organizations --
> > as you probably inferred from my earlier response to Dan, I think
> > that is a job for those other organizations -- but I am willing to
> > live with whatever the consensus is.  At this point I'd like to
hear
> > what other people have to say, so I'll keep my comments brief.
> 
> There are certain things we recommend for IETF MIB modules that
would
> also make sense for non-IETF documents for MIB implementation
reasons.
> We ran into some of these doing IEEE MIBs (such as needing US-ASCII
> versions, waiting on the assigment of OIDs, etc).
> In some cases, we would not want to recommend doing things the IETF
> way.
> 
> > 
> > First:  all of Section 4.3 and all but the first paragraph of
> > Section 4.5 are IETF-specific, and so (I think) are items 1-9 of
the
> > checklist in Appendix A.  It would be helpful, if we are going to
> > generalize the document in the way that you propose, to have some
> > text for whatever updates are needed to those sections.
> 
> To get the ball rolling, I only provided proposed text for section
3.
> It would be my intention that proposed text for other sections would
> also be provided.
> 
> > 
> > Also, regarding this:
> > 
> > > RFC 3907 is referenced, but does not appear to exist yet.
> > > 
> > > For non-IETF documents, it would be good to advise other 
> > organizations
> > > to consider the importance of allowing organizations to make
> copies,
> > > with restrictions, for management purposes. 
> > > I suspect that is what is discussed in RFC 3907. 
> > 
> > RFCs 3907 and 3908 will, when published, replace RFCs 3667 and
3668
> > respectively.  The are currently in AUTH48 review.  The actual
> > differences between 3667 and 3668 are some small differences in
> > wording.  If you want to see the current "proof" documents they
> > are in ftp://ftp.rfc-editor.org/in-notes/authors/.
> 
> I could see that 3907 was planned, since 3906 etc. were available.
> We should probably wait until it becomes available before
referencing
> it.
> Presumably it will be finalized before this document is.
> 
> I believe copyright/IP stuff for MIB documents should be looser than
> some copyrights/IP to allow for importing documents into derivative
> forms, and we should just mention this to other organizations, where
> they might not think about that at first.
> 
> > 
> > Thanks,
> > 
> > Mike
> > 
> > 
> 
> 
> 
>