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 >
Text File  |  1996-06-03  |  8KB  |  247 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Minutes of the Mail and Directory Management Working Group 
  5. (madman)
  6.  
  7. Reported by Steve Kille, ISODE Consortium
  8.  
  9.  
  10. Agenda and Secretary
  11.  
  12. The draft agenda was agreed upon and Greg Vaudreuil of Octel agreed 
  13. to take minutes.
  14.  
  15.  
  16. Review of Charter
  17.  
  18. A brief review of the charter was conducted.  The charter was agreed by 
  19. the Working Group.
  20.  
  21.  
  22. Review of Modus Operandi
  23.  
  24. The mode of working proposed by the chair was agreed.  For reference, 
  25. this is:
  26.  
  27.  
  28. MADMAN Working Group Modus Operandi
  29.  
  30. Input is categorised into three areas, each to be handled 
  31. differently.  All submissions to the list will clearly separate 
  32. out input, and marked as to which category the input is 
  33. believed to belong.
  34.  
  35.  
  36. 1) Editorial changes (primarily wording clarifications and 
  37. improvements):  All of these are to be handled by the 
  38. editors.  Ned has been tracking the EMA work, and will 
  39. fold in editorial improvements, so the Working Group does 
  40. not need to be concerned with this detail.  Changes will be 
  41. revisable because of change--bars in the circulated 
  42. versions.
  43.  
  44. 2)  Minor technical: These are things such as fixes to ASN.1, 
  45. and wording changes which could have technical impact 
  46. (for example, to disambiguate something which could 
  47. have been implemented two ways).
  48.  
  49. Editors will keep a concise log of all minor technical 
  50. changes, which will be made available to the Area 
  51. Director when the work is done, and to the Working Group 
  52. from time to time and recorded in the documents.
  53.  
  54. The editors should take a view on all minor technical 
  55. proposals, and note proposed resolutions to the Working 
  56. Group.  This should enable most of these to be handled 
  57. rapidly and cleanly.
  58.  
  59. 3)  Major technical: This will typically be changes such as 
  60. adding or deleting MIB variables and traps.
  61.  
  62. Stability of the MADMAN documents is very important, and 
  63. the default position is not to make major changes.  The goal of 
  64. review of major technical changes is to:
  65.  
  66. a) ensure that we do not unnecessarily destabilise the 
  67. protocols
  68.  
  69. b) ensure that all proposals for change are given a fair 
  70. hearing
  71.  
  72. c) document rejected proposals with reasons so that this 
  73. information is available to anyone who considers 
  74. similar changes in the future
  75.  
  76. d) clearly justify all changes
  77.  
  78. Proposals for all major changes will be clearly separated and 
  79. identified so that discussion on independent changes can be 
  80. separated.
  81.  
  82. There are the following basic criteria for making major 
  83. technical changes.
  84.  
  85. 1) User requirement: There should be a clearly justified and 
  86. explained requirement for the change.  This will need to 
  87. be accepted by a significant percentage of the Working 
  88. Group as a real requirement.  The level of requirement 
  89. should be non--trivial.  We should not be introducing 
  90. things which are merely "nice to have.╙
  91.  
  92. 2) Vendor support: There should be at least three vendors 
  93. who will commit to implement the feature.  This criterion 
  94. is primarily a veto on 1 to keep sanity.  The changes 
  95. should be driven by user requirements, not by what 
  96. vendors are prepared to implement.
  97.  
  98.  
  99.  
  100. Network MIB
  101.  
  102. The only issue that was discussed was Quiescing Status
  103.  
  104. There was consensus that a new status should be added to indicate when 
  105. the application is shutting down.  There was discussion about adding a 
  106. new variable for time--to--shutdown.
  107.  
  108. The relationship with the application MIB was raised.  There is some 
  109. overlap between this and the network MIB.  There was a proposal to 
  110. make networking attributes an augmentation of the applications MIB.  
  111. The Working Group agreed that having redundant data with the 
  112. Application was OK for now and that this proposal should not be 
  113. pursued.  
  114.  
  115.  
  116. Directory MIB.
  117.  
  118. No issues were raised on this document.
  119.  
  120.  
  121. Mail MIB.
  122.  
  123. A number of issues were discussed.
  124.  
  125. 1) Administrative Messages
  126.  
  127. The Working Group discussed the need for a separate table for 
  128. administrative messages (such as directory update).  The original 
  129. intent to set up arbitrary groups was restated and will be clarified in 
  130. the new document.  There are no semantics associated with a group.  
  131. Definition of a group for any arbitrary reason can be set up provided 
  132. there is MGT station manual configuration.
  133.  
  134. 2) URL support
  135.  
  136. The Working Group discussed adding an variable to contain a URL 
  137. for the application.  It was noted that an arbitrary URL may not fit 
  138. in a SNMP packet.  The chairs took an action to coordinate with the 
  139. NM Area Director to understand how to put a URL in a MIB.
  140.  
  141. 3) Conversions
  142.  
  143. A new proposal was made to count conversions.  The current proposal 
  144. is simpler and more workable than any of the original proposals of 
  145. the last effort.  There was agreement to add two variables.  It was 
  146. noted that it may be hard to count in some implementations, 
  147. especially those which convert all messages both in and out to local 
  148. form.
  149.  
  150. 4) ID of Oldest Message
  151.  
  152. The MIB provides the time of the oldest message.  A proposal was 
  153. made to indicate the ID of that message.  The value will be added 
  154. with first cut text to describe the intent of how this value could be 
  155. used.
  156.  
  157. 5) Last Association Attempt
  158.  
  159. There was a proposal to add the time that the last attempt was 
  160. made.  There is presently no distinction between the last successful 
  161. and unsuccessful attempt.  It was agreed to add a new variable.
  162.  
  163. 6) Number of Failures 
  164.  
  165. There was a desire to make a MTA--wide count of failures.  The 
  166. intent is to poll this value to know if there is a message failure.  It 
  167. may also want per--group.  No resolution was reached.
  168.  
  169. 7) Loop Errors
  170.  
  171. A count of loop error was proposed.  Significant discussion about the 
  172. merits of enumerating each of several "important" failures followed 
  173. and the slippery slope was identified.  There was a non--specific 
  174. proposal for a more general error tracking system, possibly in the 
  175. context of the Application MIB Working Group.  It was agreed to put 
  176. this variable in the next draft pending a proposal for a general error 
  177. reporting.
  178.  
  179. 8) TRAPS
  180.  
  181. There were specific proposals for many new traps.  It was strongly 
  182. agreed that there was a need to notify an operator upon several failure 
  183. conditions.  It is not clear how to implement "reliable notifications" in 
  184. the SNMP context.  The chair took an action to get the current NM 
  185. position.  The following were discussed.
  186.  
  187. 8.1) Last failure Trap?
  188.  
  189. There was a desire for a trap indicating the reason for the last 
  190. failure and the message ID of the message that was party to 
  191. the failure.  There was no consensus except to continue the 
  192. discussion on the list.
  193.  
  194.  
  195. 8.2) MTA Failure Trap
  196.  
  197. There was a desire to reduce polling for MTA errors by using 
  198. traps.
  199.  
  200. 8.3) MSG Failure Trap
  201.  
  202. Discussion was inconclusive.
  203.  
  204. 9) Group Enhancements
  205.  
  206. There was support for extending group concepts.  The following three 
  207. items.
  208.  
  209. 9.1) Group Description
  210.  
  211. There is a need for at least a free text description of the group.
  212.  
  213. 9.2) Transient Groups
  214.  
  215. It is not clear what the rules are for transient groups.  The 
  216. Working Group discussed  and initially agreed that groups can 
  217. be added, and can't be deleted until MTA restarted.  This will 
  218. be clarified in the next draft.  
  219.  
  220. There was a proposal to permit group deletion.  This would 
  221. consist of a semantic change in the definitions to "since group 
  222. created".  To do this, it was clear that a transient group has to 
  223. have a creation time attribute to be useful.
  224.  
  225. 9.3) Hierarchical Groups
  226.  
  227. There was a lot of interest in the ability to organize groups in a 
  228. hierarchical structure.  An initial proposal will be in the next 
  229. version of the draft.  Comments solicited.
  230.  
  231.  
  232. Actions Arising
  233.  
  234. No changes are needed for the directory MIB.
  235.  
  236. Ned Freed (Editor) will update the other two documents in line 
  237. with the Working Group discussion, clearly flagging open issues.  
  238. These will then be discussed on the mailing list.
  239.  
  240. It was agreed that the level of change proposed warranted a second 
  241. Working Group meeting in Los Angeles.  It is expected that this 
  242. meeting will finalise all issues.
  243.  
  244. The level of change in the Mail MIB means that it should be re--
  245. submitted as a proposed standard.  Steve Kille will discuss 
  246. progression of the other two documents with the Area Directors.
  247.