home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
madman
/
madman-minutes-95dec.txt
< prev
next >
Wrap
Text File
|
1996-06-03
|
8KB
|
247 lines
CURRENT MEETING REPORT
Minutes of the Mail and Directory Management Working Group
(madman)
Reported by Steve Kille, ISODE Consortium
Agenda and Secretary
The draft agenda was agreed upon and Greg Vaudreuil of Octel agreed
to take minutes.
Review of Charter
A brief review of the charter was conducted. The charter was agreed by
the Working Group.
Review of Modus Operandi
The mode of working proposed by the chair was agreed. For reference,
this is:
MADMAN Working Group Modus Operandi
Input is categorised into three areas, each to be handled
differently. All submissions to the list will clearly separate
out input, and marked as to which category the input is
believed to belong.
1) Editorial changes (primarily wording clarifications and
improvements): All of these are to be handled by the
editors. Ned has been tracking the EMA work, and will
fold in editorial improvements, so the Working Group does
not need to be concerned with this detail. Changes will be
revisable because of change--bars in the circulated
versions.
2) Minor technical: These are things such as fixes to ASN.1,
and wording changes which could have technical impact
(for example, to disambiguate something which could
have been implemented two ways).
Editors will keep a concise log of all minor technical
changes, which will be made available to the Area
Director when the work is done, and to the Working Group
from time to time and recorded in the documents.
The editors should take a view on all minor technical
proposals, and note proposed resolutions to the Working
Group. This should enable most of these to be handled
rapidly and cleanly.
3) Major technical: This will typically be changes such as
adding or deleting MIB variables and traps.
Stability of the MADMAN documents is very important, and
the default position is not to make major changes. The goal of
review of major technical changes is to:
a) ensure that we do not unnecessarily destabilise the
protocols
b) ensure that all proposals for change are given a fair
hearing
c) document rejected proposals with reasons so that this
information is available to anyone who considers
similar changes in the future
d) clearly justify all changes
Proposals for all major changes will be clearly separated and
identified so that discussion on independent changes can be
separated.
There are the following basic criteria for making major
technical changes.
1) User requirement: There should be a clearly justified and
explained requirement for the change. This will need to
be accepted by a significant percentage of the Working
Group as a real requirement. The level of requirement
should be non--trivial. We should not be introducing
things which are merely "nice to have.╙
2) Vendor support: There should be at least three vendors
who will commit to implement the feature. This criterion
is primarily a veto on 1 to keep sanity. The changes
should be driven by user requirements, not by what
vendors are prepared to implement.
Network MIB
The only issue that was discussed was Quiescing Status
There was consensus that a new status should be added to indicate when
the application is shutting down. There was discussion about adding a
new variable for time--to--shutdown.
The relationship with the application MIB was raised. There is some
overlap between this and the network MIB. There was a proposal to
make networking attributes an augmentation of the applications MIB.
The Working Group agreed that having redundant data with the
Application was OK for now and that this proposal should not be
pursued.
Directory MIB.
No issues were raised on this document.
Mail MIB.
A number of issues were discussed.
1) Administrative Messages
The Working Group discussed the need for a separate table for
administrative messages (such as directory update). The original
intent to set up arbitrary groups was restated and will be clarified in
the new document. There are no semantics associated with a group.
Definition of a group for any arbitrary reason can be set up provided
there is MGT station manual configuration.
2) URL support
The Working Group discussed adding an variable to contain a URL
for the application. It was noted that an arbitrary URL may not fit
in a SNMP packet. The chairs took an action to coordinate with the
NM Area Director to understand how to put a URL in a MIB.
3) Conversions
A new proposal was made to count conversions. The current proposal
is simpler and more workable than any of the original proposals of
the last effort. There was agreement to add two variables. It was
noted that it may be hard to count in some implementations,
especially those which convert all messages both in and out to local
form.
4) ID of Oldest Message
The MIB provides the time of the oldest message. A proposal was
made to indicate the ID of that message. The value will be added
with first cut text to describe the intent of how this value could be
used.
5) Last Association Attempt
There was a proposal to add the time that the last attempt was
made. There is presently no distinction between the last successful
and unsuccessful attempt. It was agreed to add a new variable.
6) Number of Failures
There was a desire to make a MTA--wide count of failures. The
intent is to poll this value to know if there is a message failure. It
may also want per--group. No resolution was reached.
7) Loop Errors
A count of loop error was proposed. Significant discussion about the
merits of enumerating each of several "important" failures followed
and the slippery slope was identified. There was a non--specific
proposal for a more general error tracking system, possibly in the
context of the Application MIB Working Group. It was agreed to put
this variable in the next draft pending a proposal for a general error
reporting.
8) TRAPS
There were specific proposals for many new traps. It was strongly
agreed that there was a need to notify an operator upon several failure
conditions. It is not clear how to implement "reliable notifications" in
the SNMP context. The chair took an action to get the current NM
position. The following were discussed.
8.1) Last failure Trap?
There was a desire for a trap indicating the reason for the last
failure and the message ID of the message that was party to
the failure. There was no consensus except to continue the
discussion on the list.
8.2) MTA Failure Trap
There was a desire to reduce polling for MTA errors by using
traps.
8.3) MSG Failure Trap
Discussion was inconclusive.
9) Group Enhancements
There was support for extending group concepts. The following three
items.
9.1) Group Description
There is a need for at least a free text description of the group.
9.2) Transient Groups
It is not clear what the rules are for transient groups. The
Working Group discussed and initially agreed that groups can
be added, and can't be deleted until MTA restarted. This will
be clarified in the next draft.
There was a proposal to permit group deletion. This would
consist of a semantic change in the definitions to "since group
created". To do this, it was clear that a transient group has to
have a creation time attribute to be useful.
9.3) Hierarchical Groups
There was a lot of interest in the ability to organize groups in a
hierarchical structure. An initial proposal will be in the next
version of the draft. Comments solicited.
Actions Arising
No changes are needed for the directory MIB.
Ned Freed (Editor) will update the other two documents in line
with the Working Group discussion, clearly flagging open issues.
These will then be discussed on the mailing list.
It was agreed that the level of change proposed warranted a second
Working Group meeting in Los Angeles. It is expected that this
meeting will finalise all issues.
The level of change in the Mail MIB means that it should be re--
submitted as a proposed standard. Steve Kille will discuss
progression of the other two documents with the Area Directors.