RE: guidelines section 3.6 (security considerations)

["Harrington, David" <dbh@enterasys.com>]

Hi,

I agree items 1 and 2 could be pout into the mib-security guidelines. I think it would be a good place for this.

I think item #3 and the fourth item (#5 - whoops!) could also be documented there, and the reviewer guidelines could recommend checking for these points.

The fifth item (#4) would require a separate document to define the approach and the syntax.

dbh

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: Thursday, February 06, 2003 1:51 PM
> To: Mreview (E-mail)
> Subject: RE: guidelines section 3.6 (security considerations)
> 
> 
> On Thu, 6 Feb 2003, Harrington, David wrote:
> > As representative of a vendor trying to write mibs and also to
> > tie the sensitivity of mib objects to VACM views, I would like
> > to see something more useful from the IETF than requiring mib
> > writers to provide a list of objects in a security
> > considerations section.
> > 
> > I think we should:
> > 1) develop quick guidelines for categorizing security sensitivity,
> > 2) develop quick guidelines for categorizing network 
> stability sensitivity,
> > 3) have writers describe sensitivity in the mibs proper,
> > 5) recommend a mib organization strategy to make mibs
> >    security-control-friendly, and
> > 4) have writers categorize objects in a standardized 
> machine-readable
> >    format.
> 
> Be aware that I can't do all these things.  If indeed all this
> information needs to go in the guidelines document, then we will
> need another volunteer to draft most the text.  Please understand
> that I'm not trying to be uncooperative by saying this;  the problem
> is that I'm just not qualified to do such a task.  I lack the
> knowledge of security issues (and of the workings of VACM) that
> would be needed to do a competent job.
> 
> Once concern that I have about putting all of this stuff into the
> guidelines document is that it would dramatically increase the scope
> of the project.  I have avoided discussing general MIB design issues
> such as those covered in <draft-ietf-snmpconf-bcp-12.txt> precisely
> to limit the scope.  Some of the things you are suggesting seem to
> be issues of that nature, and maybe it would be better to have a
> separate document to deal with them.  There is of course a middle
> ground, e.g., items (1) and (2) are not that big and could probably
> be included without too much pain, although the right place for them
> might be in http://www.ops.ietf.org/mib-security
> 
> //cmh
> 
> 
> 
>