Subject: Orlando meeting minutes

From: "Shawn A. Routhier" <[email-masked]>
Date: Thu, 17 Dec 98 12:25:22 -0500

I plan to submit these minutes on Monday Dec 21, comments to
me by then.

sar

	DISMAN
	Orlando, 12/7/1998
	Chair: Randy Presuhn
	Reported by: Shawn A. Routhier
	Charter: http://www.ietf.org/html.charets/disman-charter.html

The script and schedule MIBs are currently in WG last call and the
chair asks for any comments on them.  There were no comments on
the schedule MIB and it can be sent to the IESG for last call.

The script MIB includes a line that limits the object identifiers
that can be used to specify a language provider to be below 1.3.6.1.4.1
(section 4.1.3) and the description of smLaunchOwner is unclear.
After the limitation is removed and the description is clarified
(the editors understand the edits) the document will be declared to
have gone through working group last call and will be forwarded to
the IESG for last call.

Bob Stewart has been working on three documents:
notification log mib - <draft-ietf-disman-notif-log-mib-04.txt>
event mib            - <draft-ietf-disman-event-mib-05.txt>
expression mib       - <draft-ietf-disman-express-mib-05.txt>

So far there has been a lack of comments on them as well as
few people seeming to have read the current versions though
several people had read the previous versions.  Several people
volunteered to read the current versions.  Originally there were
about 6, when the chair asked about specific documents he got
10 for the notification log document, 10 for the event document and
5 for the expression document. 

There ensued a dicussion about what the working group should do with them.
The options were drop them, move them to informational or continue
on towards the standard track.  The discussion revolved around whether
it was worth the effort to start something on the standards track if
it would never get enough implementations to progress.  On the other
hand there has been some interest in the documents and many companies
won't start thinking seriously about a document until it has become
a proposed standard.  It is also pointed out that these documents describe
infrastructure and what is interesting is what can be built on top of them.
To gauge interest the chair asks for a show of hands as to who might
implement them.  4-5 people express interest in the notification log and
event mibs while only 1-2 are interested in the expression mib.
No complaints were expressed about all three continuing into the
standards track, with the AD requesting them to move faster.

Bob Stewert lead a technical discussion about several open
questions in the three mibs on which he is working.  Several
of the questions are global in scope and affect how future
MIBs might be designed.

The first question is about error handling.  Most previous MIBs
would maintain information about the last error whether or not
they sent a notification about the error.  These MIBs don't
maintain state about the last error though they do maintain a
counter of the number of traps emitted.  This can be accomplished
by defining the state objects as being notification-only and allows
the MIB designer to avoid the need for any history table type objects.
Not all traps would be good candidates for this behavior.

The ensuing discussion includes the point that this feature
would affect the code more than the MIB.  The MIB would have
a similar number of objects, but the trap-sender would not be
required to supply stable storage for those objects.  The
discussion also touches on the fact that this idea ties in well
with the notification log MIB.  The n/l MIB is a common history
mechanism and other MIBs can use it or not as necessary.
There are no objections to MIBs using this strategy, though
there could be some problems if one system doesn't accept
the notifies and the sender doesn't implement the logging mib.
This is not considered a major issue.  Using this feature
in the MIBs Bob is working on is something of an experiment
to see how well it might work.  

Part of the discussion started as a concern about the number of traps
a "notify without saving" feature might generate and expanded into a
more global discussion about throttling and trap handling capabilities.
For the "notify without saving" feature in the above MIBs throttling
may be accomplished by including an object to turn the traps off and
on and only using the traps when necessary.  A more general scheme
might allow for throttling the traps being generated by a system at
several points - when generated, when stored, when emitted etc.
Applications could perform functions such as aggregation, saving
or other processing of traps, hopefully such applications (or protocols)
would include some form of loop detection.  There seems to be general
agreement that a general throttle mechanism is useful but beyond
the scope of these MIBs, it might be a SNMPv3 type of tool.  Andy
Bierman volunteers to look into such a mechanism, one place to start
might be RFC1224 - "Techniques for Managing Asynchronously Generated Alerts".

One other note from this discussion is that these MIBs are tools,
and that while we may not get any immediate use from them we should
continue to deploy them piecemeal rather than to wait until we reach
some critical mass as that direction may result in never releasing anything.

The second question was about using names instead of integers as indexes.
There are three parts to this discussion:
1) use of names instead of integers
2) use of names that probably match the group names
3) use of appropriate names allows a hierarchy of names to be set up.
An example of (3) would be
table.entry.column.<accting>
table.entry.column.<accting_sales>
table.entry.column.<accting_purch>

A different approach for (3) would be to split the information into
two indexes, one to name the owner and one to name the objects.  This
makes the security policy more explicit and is the model used for
the script and schedule MIBs

Using a single index requires that the indexs be chosen somewhat carefully
in order to avoid accidently creating two names with the same prefix.
For example, with owners "A" and "AB" we might have
table.entry.column.*.A
table.entry.column.*.AB
if "A" creates an entry with a leading B such as "ABook"
table.entry.column.*.ABook
it becomes difficult to differentiate this from something by "AB".

This class of problems could be solved by careful use of punctuation
or by the proper addition of entries denying access to certain names
but in general the one index case is more complicated to use than the
two index case.  The working group is also against specifying a
standard style for of punctuation.

Another issue is that the single index style makes part of the
security implicit in how the indexes are constructed.  This is generally
frowned on in the security area.

The non-binding consensus is for the two index approach but to move
the discussion to the mailing list.  If we do adopt/allow the single
index approach it will require a fair amount of descriptive text to
clarify its use to the manager.

The discussion also included a more general question if this demonstrates
a problem with security such that we will need an owner string for
the first index of all mibs - or how do we tell which objects or MIBs
would require them.  One comment is that this will only occur for
certain classes of entities such as logical entities that may come and
go while other items might have security based on specific attributes.

 and that other items such as if entries will have security based
on its more "physical" attributes.  There was some disagreement about

Question three was to replace the DisplayString with the SnmpAdminString,
the consensus was to do so.

Question four was if the objects in a MIB should include the MIB
module name, in this case "disman",  as part of their names.
A majority of the people who cared prefered having the mib module name
included.  This was passed to the mailing list for further discussion.

Question five was what rule should be followed to decide if an object
of storage type be included in a table, or should all tables
have storage type objects.  This was passed off to the SNMP futures
meeting, with Bob Stewart getting the action item to bring it up there.
The specific case of these tables was passed off to the mailing list.

Question six was about changing the model for the event MIB, to have 
a simple version rather than the full expression MIB.  Currently it
only includes booleans and threshholds, a different option would be
to specify the test, operator object and operand object.  This
question was passed off to the mailing list.

There were no comments on the remote operations document -
<draft-ietf-disman-remops-mib-01.txt>.  Work will continue
and the working group will try to get it done shortly.

As the working group agrees that there really isn't a framework
to the current set of documents the chair is planning to ask the
ADs to let the framework document be dropped.

There was no discussion of interaction with other groups and
no proposed charter updates.

The working group decided to wait and see what other groups do
with the bulk transfer ideas and how the rest of the current
DISMAN work goes.  If this isn't accepted as a protocol issue
by the SNMP futures group then it probably should be absorbed
by DISMAN.