Subject: RE: reminder: disman docs for "proposed"

From: Randy Presuhn <[email-masked]>
Date: Fri, 7 Jul 2000 15:56:43 -0700 (PDT)

Hi -

> Message-Id: <[email-masked]>
> Date: Mon, 03 Jul 2000 12:07:12 -0700
> To: Randy Presuhn <[email-masked]>, [email-masked],
>         [email-masked]
> From: "Ramanathan R. Kavasseri" <[email-masked]>
> Subject: RE: reminder: disman docs for "proposed"
> Cc: [email-masked]
> In-Reply-To: <[email-masked]>
> List-Id: IETF disman Working Group mailing list <[email-masked]>
> 
> 
> At 12:09 PM 6/8/00 -0700, Randy Presuhn wrote:
> >
> >Hi -
> >
> >> Message-ID: 
> ><[email-masked]>
> >> From: "Wijnen, Bert (Bert)" <[email-masked]>
> >> To: [email-masked], Randy Presuhn <[email-masked]>
> >> Cc: [email-masked]
> >> Subject: RE: reminder: disman docs for "proposed"
> >> Date: Thu, 8 Jun 2000 13:46:07 +0200 
> >> List-Id: IETF disman Working Group mailing list <[email-masked]>
> >...
> >> Before I do the IETF Last Call, I would indeed want to see
> >> the SMIv2 errors fixed. Other typo fixes can go along with
> >> them, but they can also be done at a later time.
> >> I would also prefer to fix SMI compile warnings if possible.
> >...
> >
> >This is fine with me.  In addition to the fixes Frank has
> >identified (which are fine with me), here are the other typos
> >and potential IETF last-call issues that I've become aware of:
> >
> 
> [...snipped out other items which I've done already...]
> 
> >technical issue, discussed at WG meetings but not reflected
> >in document:
> >18) draft-ietf-disman-notif-log-mib-16.txt> pages 4/5
> >    Heirarchically structured log names have been repeatedly
> >    shown to have subtle pitfalls.  The approach the draft
> >    recommends can produce surprises when the first subid of
> >    the second index looks like punctuation, etc.  For example,
> >    with { nlmLogName, nlmLogIndex, nlmLogVariableIndex
> >    }, nlmLogIndex could have the same value as "-", and
> >    nlmLogVariableIndex could match a particular subgroup
> >    name, thus (inappropriately) granting access
> 
> Alas, Pittsburgh will be the first time I attend a disman WG meeting :-(
> So I'm unaware of what was the agreed upon change. Can someone
> send the proposed change to me?

I suggest the following change:

old: The Notification Log MIB has the notion of a "named log."  By using
old: hierarchically structured log names and view-based access control
old: [RFC2575] a network administrator can provide different access for
old: different users.  When an application creates a named log the security
old: credentials of the creator stay associated with that log.
old: 
old: Hierarchically structured names encode groupings of names within the
old: name string, starting from the left so that they work well with
old: instance-level, view-based access control [RFC2575], for example:
old: 
old: ops   ops-admin   ops-oper   ops-oper-senior   ops-oper-junior
old: 
old: Network security managers designing such a naming policy SHOULD use
old: punctuation (as in the example) to avoid the problem of a lower level
old: name inadvertently running together with the next higher level name.

new: The Notification Log MIB has the notion of a "named log."
new: By using log names and view-based access control [RFC2575]
new: a network administrator can provide different access for
new: different users.  When an application creates a named log
new: the security credentials of the creator stay associated with
new: that log.

> >editorial omission:
> >21)  draft-ietf-disman-notif-log-mib-16.txt> page 24: what
> >     is the condition for notificationLogDateGroup?
> 
> [*] Couldn't follow what was wrong here?
...

The current DESCRIPTION is vacuous.  It doesn't say what the
condition is.  The current text says "Conditionally mandatory
notification log data."  Lacking a statement of what the
condition is, this definition is worthless.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Mon, 10 Jul 2000 10:02:29 -0700

>condition is, this definition is worthless.

I've changed the DESCRIPTION as shown below, to include the condition...

notificationLogDateGroup OBJECT-GROUP
	OBJECTS {
		nlmLogDateAndTime
	}
	STATUS current
	DESCRIPTION
		"Conditionally mandatory notification log data.
		This group is mandatory on systems that keep wall
		clock date and time and should not be implemented
		on systems that do not have a wall clock date."
	::= { notificationLogMIBGroups 4 }

Thanks for the speedy response,

Ram