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.