Subject: Re: Request Last Call - draft-ietf-disman-notif-log-mib-09.txt

From: Randy Presuhn <[email-masked]>
Date: Tue, 2 Feb 1999 10:14:36 -0800 (PST)

Hi - 

> Date: Tue, 02 Feb 1999 09:15:31 -0500
> To: Distributed Management WG <[email-masked]>
> From: Bob Stewart <[email-masked]>
> Subject: Request Last Call - draft-ietf-disman-notif-log-mib-09.txt
...
> I request that you begin working group last call on the Notification Log
> MIB and terminate discussion except for serious bugs.
> 
> We're never going to ship this work at this rate.

As long as there are significant problems, we'll have to continut
to cycle.  There's a real disconnect between the level of interest
expressed in the WG meeting and the activity on the list.  I'm tired of
this stuff too, but it makes no sense to say we're done with something
that has only been reviewed by a very small number of people.  If there
were some indications that anyone else (other than Juergen, who has been
most conscientious about this) has read the draft, I'd feel much better.

> I have sent the latest (typo) corrections to Internet Drafts.  I did not
> send it here on purpose.
...

So I'll have to wait for it to appear there.  If it looks ok, then, as
promised, we can do WG last call.

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Feb 1999 12:08:45 -0500

> most conscientious about this) has read the draft, I'd feel much better.

Ok, I have read the latest draft (09), and I think it has improved
alot since the last one I read.  I.e. the text describes the inteded
behaviour much better now.

However, I do have a few comments (I'm not afraid of that little
puppy!)

o  The example in sect. 3.3 lists entries in nlmConfigLogTable:

     nlmConfigLogFilterName."links"      = "link-status"
   
   etc.

   Since the index is not IMPLIED, it should be:

     nlmConfigLogFilterName.5."links"      = "link-status"
   
   etc.

   [Unless the index was supposed to be IMPLIED...]

o  The description of nlmConfigLogEntry says:

        Depending on the entry's storage type
        entries may be supplied by the system or created and deleted by
        applications using nlmConfigLogEntryStatus.

   I don't understand what this means.  E.g. how can a non-existing
   entry's storageType have influence on it's creation?  Or do you
   simply mean that it might not be possible to create/delete an entry
   with storage type 'persistent'?

o  nlmConfigLogFilterName

   I have the same concerns as Juergen:

juergen> I am concerned about the last sentence. I think it implies that I
juergen> can only use this MIB if I also have an implementation of the
juergen> snmpNotifyFilterTable. What about changing the semantics so that a 
juergen> zero-length value implies that no filtering is to be done? This
juergen> would allow a simple implementation of this MIB which does not do
juergen> filtering at all.

bob> Implication correct.  I put the default as it is on purpose.  I don't want
bob> an incomplete, inexplicit entry to open the floodgate of notification
bob> logging.  I want it to default to closed.

   First of all - an implementation of this MIB requires an
   implementation of snmpNotifyFilterTable, is this correct?

   I think this is bad.  However, I agree with you that the default
   should not be to log everything.  But this could be accomplished by
   deleting the DEFVAL, thus forcing a manager to provide a value.

   So I suggest that a zero length string means "no filter", and that
   the DEFVAL is removed.  

   Access control still applies.

o  In the description of nlmLogTable, there is a typo: "nmLogTime".

o  nlmLogTime / nlmLogDateAndTime

   Wouldn't it make sense to allow an implementation that implements
   nlmLogDateAndTime to not instantiate nlmLogTime?   In this way,
   these implementations wouldn't have to reset the nlmLogTime to 0
   when the system reboots.

o  nlmConfigGlobalAgeOut

   Shouldn't implementations be allowed to restrict this object to
   read-only?  (I.e. add this to the module compliance)

   In an implementation that configures log space to each log, it
   doesn't make sense to have to remove objects based on their
   timestamp.  In this case, I'd like to set the nlmConfigGlobalAgeOut
   to 0, and make it read-only.

   [Also, why isn't there an age out object per log?]

/martin

---

From: Bob Stewart <[email-masked]>
Date: Fri, 12 Feb 1999 15:14:27 -0500

>behaviour much better now.

At least there's been some progress.

>   [Unless the index was supposed to be IMPLIED...]

Right.  The index was IMPLIED and I changed it.  I'll fix the example.

>   with storage type 'persistent'?

That's what I'm getting at.  The storage type indicates whether the system
is providing an entry you can't change.  I can imagine implementations with
preconfigured logs and in severely limited systems not anything else.  I
want this to be usable in a broad range of systems, from those that can
only do a little for vital information to those that are major waystations
for notification traffic.

>   implementation of snmpNotifyFilterTable, is this correct?

Yes, but it could be a real cheap one.  If you don't want to supply any
filtering options you could supply a read-only snmpNotifyFilterTable with
just the entry needed to allow the notifications you're willing to log.

>   deleting the DEFVAL, thus forcing a manager to provide a value.

The DEFVAL is a strong statement that having filtering default to logging
everything is dangerous.  Given the filter table strategy I described
above, I'd rather leave the log MIB as is.

>o  In the description of nlmLogTable, there is a typo: "nmLogTime".

OK.

>   these implementations wouldn't have to reset the nlmLogTime to 0

I'd rather keep the minimum capability always present so minimum
applications can depend on and use it.

>   to 0, and make it read-only.

Those seem to me like separate issues.  Actually the flexibility I might
give to refuse changes or certain values for timeout would be to allow a
system to insist that it's going to timeout and toss entries, to protect
its resources.

>   [Also, why isn't there an age out object per log?]

The MIB has enough stuff in it so that I'd prefer not to add yet more
features until we have some experience.  Adding a per log timeout could be
done later.

	Bob