Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05667; 4 Oct 94 12:07 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa05663; 4 Oct 94 12:07 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa10481; 4 Oct 94 12:06 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVE2BY24GIRI1CY@INNOSOFT.COM>; Tue, 04 Oct 1994 08:13:24 -0700 (PDT) Received: from dw3f.ess.harris.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVE29JSF4IRI0Z9@INNOSOFT.COM>; Tue, 04 Oct 1994 08:13:20 -0700 (PDT) Received: from isdlink1.ess.harris.com (isdlink1 [130.41.0.28]) by dw3f.ess.harris.com (8.6.9/mdb(940610)) with SMTP id LAA19918 for ; Tue, 4 Oct 1994 11:14:54 -0400 Received: from cc:Mail by isdlink1.ess.harris.com id AA781294395; Tue, 04 Oct 94 11:12:42 est Date: Tue, 04 Oct 1994 11:12:42 -0500 (est) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: GBEST01 Subject: Re[2]: Recommendations of the TSC To: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9409047812.AA781294395@isdlink1.ess.harris.com> Content-transfer-encoding: 7BIT > > This is unfortunately (or furtunately) not entirely accurate, but > > it appears to be real close. One of the situations with which we > > are dealing is that when a messaging administrator is > > attempting to monitor MTAs that exist in a multi-vendor > > environment, it would prove extremely useful if each MTA > > reported on a consistent set of statistics. > > I totally disagree. Not only is this not useful, it is major disservice. > MTAs are monitored for different reasons. Different MTAs are monitored for > different reasons. Having only one way to configure and monitor an MTA > dramatically limits the utility of the MIB. We are working with a multi-vendor system. We prefer the "generic management tool" as is currently described in the MADMAN MIBs. The mtaGroupTable should be left open so that vendors and system integrators have the flexibility to meet each customer's management requirements. This flexibility is also important because it eases the transition from proprietary MIBs to MADMAN. For example, a vendor looking for a way to transition from ISODE to MADMAN could use the mtaGroupTable as a structure that could accommodate the information currently provided in the queuedMtaTable. This may be important to that vendor because it preserves most of the work that was previously done to support the queuedMtaTable objects The TSC did a good thing by bringing this topic up for discussion. The mtaGroupTable should be singled out for comment by the EMA because it is a powerful tool that should not be overlooked. The current definition of groups supports any interpretation that a vendor, customer, or system integrator feels is important, including the specific interpretation that the TSC attendees felt was important. I would like to see the EMA endorse the current group definition and to encourage use of the groups as a general management tool. They could provide an additional service by tracking and reporting the various uses of the mtaGroupTable by industry. George Best Harris Corp. - ISD   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10382; 4 Oct 94 17:06 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10378; 4 Oct 94 17:06 EDT Received: from [192.160.253.66] by CNRI.Reston.VA.US id aa28048; 4 Oct 94 17:06 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3LU5DSIRI1CY@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:47 -0700 (PDT) Received: from dw3f.ess.harris.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3FE1V4IRI3IW@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:43 -0700 (PDT) Received: from isdlink1.ess.harris.com (isdlink1 [130.41.0.28]) by dw3f.ess.harris.com (8.6.9/mdb(940610)) with SMTP id QAA23508; Tue, 4 Oct 1994 16:30:55 -0400 Received: from cc:Mail by isdlink1.ess.harris.com id AA781313355; Tue, 04 Oct 94 16:25:30 est Date: Tue, 04 Oct 1994 16:25:30 -0500 (est) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: GBEST01 Subject: What is "MADMAN compliance"? To: ietf-madman@innosoft.com, gjones@gateway.mitre.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9409047813.AA781313355@isdlink1.ess.harris.com> Content-transfer-encoding: 7BIT Subject: Re: Re[2]: Recommendations of the TSC Author: gjones@gateway.mitre.org at smtp Date: 10/4/94 11:42 AM Mr. Harris, Can we add new information, if only on an experimantal basis, to the MADMAN MIB while still remaining "MADMAN-compliant" ? Would you recommend creating new tables, or adding variables to the existing tables ? Gordon Jones MITRE ______________________________ Reply Separator ______________________ Gordon - Just to clarify, I wasn't advocating extensions to the MADMAN MIB as a method of resolving the mtaGroupTable issue. You did raise an interesting issue with respect to "MADMAN-compliance". Namely, what is a sufficient implementation that allows a vendor to be MADMAN-compliant. My opinion is as follows: From an MTS vendor's perspective, focusing the mtaGroupTable on MTA-to-MTA pairings results in a well-defined mission statement for software developers. The proposed interpretation would allow MTS vendors to engineer in a specific capability and then advertise "MADMAN-compliance". From a system perspective the focused definition translates into limitations. This would be another part of the trade-off that Steve Kille mentioned. If we define "MADMAN-compliance" with respect to a specific interpretation of the mtaGroupTable, we still run the risk that that definition will not meet the requirements of a given customer and we then have to update the official definition of the mtaGroupTable to ensure that the solution is "MADMAN-compliant". If the interpretation of the mtaGroupTable is left as it currently is, vendors can respond quickly to the demands of the market place (at least with respect to the concept of groups) and still be "MADMAN-compliant". George Best Harris Corp. - ISD   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11075; 4 Oct 94 18:25 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa11070; 4 Oct 94 18:25 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa01882; 4 Oct 94 18:24 EDT Return-path: gjones@gateway.mitre.org Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVRURQ9Q8IRI1CY@INNOSOFT.COM>; Tue, 04 Oct 1994 14:48:58 -0700 (PDT) Received: from mwunix.mitre.org by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVRUMDDA8IRHWLT@INNOSOFT.COM>; Tue, 04 Oct 1994 14:48:53 -0700 (PDT) Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id RAA23974; Tue, 4 Oct 1994 17:48:30 -0400 Received: from terra.mitre.org by gateway.mitre.org (4.1/SMI-4.1) id AA11861; Tue, 4 Oct 94 17:45:22 EDT Received: by terra.mitre.org (4.1/SMI-4.1) id AA14096; Tue, 4 Oct 94 17:44:43 EDT Date: Tue, 04 Oct 1994 17:44:41 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gjones@gateway.mitre.org Subject: MADMAN "compliance" and Other Issues To: GBEST01@isdlink1.ess.harris.com Cc: gjones@terra.mitre.org, tsc-l@ema.org, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9410042144.AA14096@terra.mitre.org> Content-transfer-encoding: 7BIT Mr. Best (sorry for calling you Mr. Harris - this is the result of too many tasks and too little time): Thank you for taking an interest in this topic. Since we are already addressing multiple issues, let me clarify myself on each of them: I. On the definition of MTA group The EMA document needs to state that a particular aspect of the group abstraction has been selected for implementation, and state what that aspect is in precise terms. It should not attempt to redefine what a group is, especially in a way such that it constrains the concept so as to make it unusable by an existing or prospective implementation, including those resulting from the EMA agreement itself. Mr. Kille's idea of conducting a joint meeting between EMA and MADMAN is the right one. Since the EMA group is active and MADMAN is presently dormant, perhaps one of our meetings would be an acceptable venue. II. On MADMAN Compliance Let me use an example. Can a vendor add some vendor-specific variables to the end of the MtaGroupEntry without affecting the "view" of the MtaGroupEntry as seen by other vendor implementations ? Would other implementations that did not deviate from the exact RFC1566 definition of MADMAN encounter difficulties when interoperating with with the extended version ? Politically, the extended version is not compliant, but technically my gut instinct tells me that one may run experiments with an extended version as the basic capability described in MADMAN remains deployed. Gordon Jones MITRE ------- Forwarded Message Received: from mwunix.mitre.org by gateway.mitre.org (4.1/SMI-4.1) id AA11511; Tue, 4 Oct 94 16:28:35 EDT Errors-To: ~ned+madman-errors@SIGURD.INNOSOFT.COM Return-Path: ~ned+madman-errors@SIGURD.INNOSOFT.COM Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mwunix.mitre.org (8.6.4/8.6.4) with ESMTP id QAA15520; Tue, 4 Oct 1994 16:31:31 -0400 Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3LU5DSIRI1CY@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:47 -0700 (PDT) Received: from dw3f.ess.harris.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3FE1V4IRI3IW@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:43 -0700 (PDT) Received: from isdlink1.ess.harris.com (isdlink1 [130.41.0.28]) by dw3f.ess.harris.com (8.6.9/mdb(940610)) with SMTP id QAA23508; Tue, 4 Oct 1994 16:30:55 -0400 Received: from cc:Mail by isdlink1.ess.harris.com id AA781313355; Tue, 04 Oct 94 16:25:30 est Date: Tue, 04 Oct 1994 16:25:30 -0500 (est) From: GBEST01 Subject: What is "MADMAN compliance"? To: ietf-madman@INNOSOFT.COM, gjones@gateway.mitre.org Errors-To: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-Id: <9409047813.AA781313355@isdlink1.ess.harris.com> Content-Transfer-Encoding: 7BIT Subject: Re: Re[2]: Recommendations of the TSC Author: gjones@gateway.mitre.org at smtp Date: 10/4/94 11:42 AM Mr. Harris, Can we add new information, if only on an experimantal basis, to the MADMAN MIB while still remaining "MADMAN-compliant" ? Would you recommend creating new tables, or adding variables to the existing tables ? Gordon Jones MITRE ______________________________ Reply Separator ______________________ Gordon - Just to clarify, I wasn't advocating extensions to the MADMAN MIB as a method of resolving the mtaGroupTable issue. You did raise an interesting issue with respect to "MADMAN-compliance". Namely, what is a sufficient implementation that allows a vendor to be MADMAN-compliant. My opinion is as follows: From an MTS vendor's perspective, focusing the mtaGroupTable on MTA-to-MTA pairings results in a well-defined mission statement for software developers. The proposed interpretation would allow MTS vendors to engineer in a specific capability and then advertise "MADMAN-compliance". From a system perspective the focused definition translates into limitations. This would be another part of the trade-off that Steve Kille mentioned. If we define "MADMAN-compliance" with respect to a specific interpretation of the mtaGroupTable, we still run the risk that that definition will not meet the requirements of a given customer and we then have to update the official definition of the mtaGroupTable to ensure that the solution is "MADMAN-compliant". If the interpretation of the mtaGroupTable is left as it currently is, vendors can respond quickly to the demands of the market place (at least with respect to the concept of groups) and still be "MADMAN-compliant". George Best Harris Corp. - ISD ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02225; 5 Oct 94 8:46 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02221; 5 Oct 94 8:46 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa23124; 5 Oct 94 8:46 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWM6IWVU8IRHJY4@INNOSOFT.COM>; Wed, 05 Oct 1994 05:16:39 -0700 (PDT) Received: from dw3f.ess.harris.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWM6FCSJ4IRHT9C@INNOSOFT.COM>; Wed, 05 Oct 1994 05:16:35 -0700 (PDT) Received: from isdlink1.ess.harris.com (isdlink1 [130.41.0.28]) by dw3f.ess.harris.com (8.6.9/mdb(940610)) with SMTP id IAA26243; Wed, 5 Oct 1994 08:18:06 -0400 Received: from cc:Mail by isdlink1.ess.harris.com id AA781370184; Wed, 05 Oct 94 08:15:24 est Date: Wed, 05 Oct 1994 08:15:24 -0500 (est) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: GBEST01 Subject: Re: MADMAN "compliance" and Other Issues To: gjones@terra.mitre.org, ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9409057813.AA781370184@isdlink1.ess.harris.com> Content-transfer-encoding: 7BIT Gordon - Adding objects "at the end" of a table or MIB would affect GETNEXT operations by returning OIDs that a management application may not be expecting. This may or may not be a problem, it all depends on the management application and how it is being used. I would think that this approach would not be "MADMAN-compliant". In my opinion, the place for early experimentation is under private enterprise branches. For example, one could configure the entire MIB branch with the experimental extensions under a private enterprise number so that it may be evaluated prior to initiating contact with the IETF to propose extending the MIBs. Has there been a precedent established with the network management MIBs? George ______________________________ Reply Separator _________________________________ Subject: MADMAN "compliance" and Other Issues Author: gjones@gateway.mitre.org at smtp Date: 10/4/94 5:48 PM Mr. Best (sorry for calling you Mr. Harris - this is the result of too many tasks and too little time): Thank you for taking an interest in this topic. Since we are already addressing multiple issues, let me clarify myself on each of them: I. On the definition of MTA group The EMA document needs to state that a particular aspect of the group abstraction has been selected for implementation, and state what that aspect is in precise terms. It should not attempt to redefine what a group is, especially in a way such that it constrains the concept so as to make it unusable by an existing or prospective implementation, including those resulting from the EMA agreement itself. Mr. Kille's idea of conducting a joint meeting between EMA and MADMAN is the right one. Since the EMA group is active and MADMAN is presently dormant, perhaps one of our meetings would be an acceptable venue. II. On MADMAN Compliance Let me use an example. Can a vendor add some vendor-specific variables to the end of the MtaGroupEntry without affecting the "view" of the MtaGroupEntry as seen by other vendor implementations ? Would other implementations that did not deviate from the exact RFC1566 definition of MADMAN encounter difficulties when interoperating with with the extended version ? Politically, the extended version is not compliant, but technically my gut instinct tells me that one may run experiments with an extended version as the basic capability described in MADMAN remains deployed. Gordon Jones MITRE ------- Forwarded Message Received: from mwunix.mitre.org by gateway.mitre.org (4.1/SMI-4.1) id AA11511; Tue, 4 Oct 94 16:28:35 EDT Errors-To: ~ned+madman-errors@SIGURD.INNOSOFT.COM Return-Path: ~ned+madman-errors@SIGURD.INNOSOFT.COM Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mwunix.mitre.org (8.6.4/8.6.4) with ESMTP id QAA15520; Tue, 4 Oct 1994 16:31:31 -0400 Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3LU5DSIRI1CY@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:47 -0700 (PDT) Received: from dw3f.ess.harris.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3FE1V4IRI3IW@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:43 -0700 (PDT) Received: from isdlink1.ess.harris.com (isdlink1 [130.41.0.28]) by dw3f.ess.harris.com (8.6.9/mdb(940610)) with SMTP id QAA23508; Tue, 4 Oct 1994 16:30:55 -0400 Received: from cc:Mail by isdlink1.ess.harris.com id AA781313355; Tue, 04 Oct 94 16:25:30 est Date: Tue, 04 Oct 1994 16:25:30 -0500 (est) From: GBEST01 Subject: What is "MADMAN compliance"? To: ietf-madman@INNOSOFT.COM, gjones@gateway.mitre.org Errors-To: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-Id: <9409047813.AA781313355@isdlink1.ess.harris.com> Content-Transfer-Encoding: 7BIT Subject: Re: Re[2]: Recommendations of the TSC Author: gjones@gateway.mitre.org at smtp Date: 10/4/94 11:42 AM Mr. Harris, Can we add new information, if only on an experimantal basis, to the MADMAN MIB while still remaining "MADMAN-compliant" ? Would you recommend creating new tables, or adding variables to the existing tables ? Gordon Jones MITRE ______________________________ Reply Separator ______________________ Gordon - Just to clarify, I wasn't advocating extensions to the MADMAN MIB as a method of resolving the mtaGroupTable issue. You did raise an interesting issue with respect to "MADMAN-compliance". Namely, what is a sufficient implementation that allows a vendor to be MADMAN-compliant. My opinion is as follows: From an MTS vendor's perspective, focusing the mtaGroupTable on MTA-to-MTA pairings results in a well-defined mission statement for software developers. The proposed interpretation would allow MTS vendors to engineer in a specific capability and then advertise "MADMAN-compliance". From a system perspective the focused definition translates into limitations. This would be another part of the trade-off that Steve Kille mentioned. If we define "MADMAN-compliance" with respect to a specific interpretation of the mtaGroupTable, we still run the risk that that definition will not meet the requirements of a given customer and we then have to update the official definition of the mtaGroupTable to ensure that the solution is "MADMAN-compliant". If the interpretation of the mtaGroupTable is left as it currently is, vendors can respond quickly to the demands of the market place (at least with respect to the concept of groups) and still be "MADMAN-compliant". George Best Harris Corp. - ISD ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02711; 5 Oct 94 9:26 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02707; 5 Oct 94 9:26 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa01790; 5 Oct 94 9:26 EDT Return-path: gjones@gateway.mitre.org Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWNJHLFLSIRI35H@INNOSOFT.COM>; Wed, 05 Oct 1994 05:56:07 -0700 (PDT) Received: from mwunix.mitre.org by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWNJEH7A8IRI4QH@INNOSOFT.COM>; Wed, 05 Oct 1994 05:56:03 -0700 (PDT) Received: from gateway.mitre.org (gateway.mitre.org [128.29.31.10]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id IAA07022; Wed, 5 Oct 1994 08:55:55 -0400 Received: from terra.mitre.org by gateway.mitre.org (4.1/SMI-4.1) id AA14776; Wed, 5 Oct 94 08:52:48 EDT Received: by terra.mitre.org (4.1/SMI-4.1) id AA15163; Wed, 5 Oct 94 08:52:08 EDT Date: Wed, 05 Oct 1994 08:52:06 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: gjones@gateway.mitre.org Subject: Re: MADMAN "compliance" To: GBEST01@isdlink1.ess.harris.com Cc: gjones@terra.mitre.org, ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9410051252.AA15163@terra.mitre.org> Content-transfer-encoding: 7BIT George, This is precisely the reason for my inquiry. If the GETNETXT operation returns extra "stuff" this makes an extended version non-compliant. You are saying that, even if an application specifies a list of variables and OIDs in the GET operation, a successive GETNEXT operation will return a superset of those variables, if those variables are not the only variables in a row of the table being accessed ? Gordon ------- Forwarded Message Received: from mwunix.mitre.org by terra.mitre.org (4.1/SMI-4.1) id AA15109; Wed, 5 Oct 94 08:12:45 EDT Return-Path: GBEST01@isdlink1.ess.harris.com Received: from dw3f.ess.harris.com (dw3f.ess.harris.com [130.41.9.242]) by mwunix.mitre.org (8.6.4/8.6.4) with ESMTP id IAA29126 for ; Wed, 5 Oct 1994 08:16:24 -0400 Received: from isdlink1.ess.harris.com (isdlink1 [130.41.0.28]) by dw3f.ess.harris.com (8.6.9/mdb(940610)) with SMTP id IAA26243; Wed, 5 Oct 1994 08:18:06 -0400 Received: from cc:Mail by isdlink1.ess.harris.com id AA781370184; Wed, 05 Oct 94 08:15:24 est Date: Wed, 05 Oct 94 08:15:24 est From: "GBEST01" Message-Id: <9409057813.AA781370184@isdlink1.ess.harris.com> To: gjones@terra.mitre.org, ietf-madman@innosoft.com, tsc-l@ema.org Subject: Re: MADMAN "compliance" and Other Issues Gordon - Adding objects "at the end" of a table or MIB would affect GETNEXT operations by returning OIDs that a management application may not be expecting. This may or may not be a problem, it all depends on the management application and how it is being used. I would think that this approach would not be "MADMAN-compliant". In my opinion, the place for early experimentation is under private enterprise branches. For example, one could configure the entire MIB branch with the experimental extensions under a private enterprise number so that it may be evaluated prior to initiating contact with the IETF to propose extending the MIBs. Has there been a precedent established with the network management MIBs? George ______________________________ Reply Separator _________________________________ Subject: MADMAN "compliance" and Other Issues Author: gjones@gateway.mitre.org at smtp Date: 10/4/94 5:48 PM Mr. Best (sorry for calling you Mr. Harris - this is the result of too many tasks and too little time): Thank you for taking an interest in this topic. Since we are already addressing multiple issues, let me clarify myself on each of them: I. On the definition of MTA group The EMA document needs to state that a particular aspect of the group abstraction has been selected for implementation, and state what that aspect is in precise terms. It should not attempt to redefine what a group is, especially in a way such that it constrains the concept so as to make it unusable by an existing or prospective implementation, including those resulting from the EMA agreement itself. Mr. Kille's idea of conducting a joint meeting between EMA and MADMAN is the right one. Since the EMA group is active and MADMAN is presently dormant, perhaps one of our meetings would be an acceptable venue. II. On MADMAN Compliance Let me use an example. Can a vendor add some vendor-specific variables to the end of the MtaGroupEntry without affecting the "view" of the MtaGroupEntry as seen by other vendor implementations ? Would other implementations that did not deviate from the exact RFC1566 definition of MADMAN encounter difficulties when interoperating with with the extended version ? Politically, the extended version is not compliant, but technically my gut instinct tells me that one may run experiments with an extended version as the basic capability described in MADMAN remains deployed. Gordon Jones MITRE - ------- Forwarded Message Received: from mwunix.mitre.org by gateway.mitre.org (4.1/SMI-4.1) id AA11511; Tue, 4 Oct 94 16:28:35 EDT Errors-To: ~ned+madman-errors@SIGURD.INNOSOFT.COM Return-Path: ~ned+madman-errors@SIGURD.INNOSOFT.COM Received: from THOR.INNOSOFT.COM (THOR.INNOSOFT.COM [192.160.253.66]) by mwunix.mitre.org (8.6.4/8.6.4) with ESMTP id QAA15520; Tue, 4 Oct 1994 16:31:31 - -0400 Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3LU5DSIRI1CY@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:47 -0700 (PDT) Received: from dw3f.ess.harris.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHVP3FE1V4IRI3IW@INNOSOFT.COM>; Tue, 04 Oct 1994 13:29:43 -0700 (PDT) Received: from isdlink1.ess.harris.com (isdlink1 [130.41.0.28]) by dw3f.ess.harris.com (8.6.9/mdb(940610)) with SMTP id QAA23508; Tue, 4 Oct 1994 16:30:55 -0400 Received: from cc:Mail by isdlink1.ess.harris.com id AA781313355; Tue, 04 Oct 94 16:25:30 est Date: Tue, 04 Oct 1994 16:25:30 -0500 (est) From: GBEST01 Subject: What is "MADMAN compliance"? To: ietf-madman@INNOSOFT.COM, gjones@gateway.mitre.org Errors-To: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-Id: <9409047813.AA781313355@isdlink1.ess.harris.com> Content-Transfer-Encoding: 7BIT Subject: Re: Re[2]: Recommendations of the TSC Author: gjones@gateway.mitre.org at smtp Date: 10/4/94 11:42 AM Mr. Harris, Can we add new information, if only on an experimantal basis, to the MADMAN MIB while still remaining "MADMAN-compliant" ? Would you recommend creating new tables, or adding variables to the existing tables ? Gordon Jones MITRE ______________________________ Reply Separator ______________________ Gordon - Just to clarify, I wasn't advocating extensions to the MADMAN MIB as a method of resolving the mtaGroupTable issue. You did raise an interesting issue with respect to "MADMAN-compliance". Namely, what is a sufficient implementation that allows a vendor to be MADMAN-compliant. My opinion is as follows: From an MTS vendor's perspective, focusing the mtaGroupTable on MTA-to-MTA pairings results in a well-defined mission statement for software developers. The proposed interpretation would allow MTS vendors to engineer in a specific capability and then advertise "MADMAN-compliance". From a system perspective the focused definition translates into limitations. This would be another part of the trade-off that Steve Kille mentioned. If we define "MADMAN-compliance" with respect to a specific interpretation of the mtaGroupTable, we still run the risk that that definition will not meet the requirements of a given customer and we then have to update the official definition of the mtaGroupTable to ensure that the solution is "MADMAN-compliant". If the interpretation of the mtaGroupTable is left as it currently is, vendors can respond quickly to the demands of the market place (at least with respect to the concept of groups) and still be "MADMAN-compliant". George Best Harris Corp. - ISD - ------- End of Forwarded Message ------- End of Forwarded Message   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01779; 5 Oct 94 18:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01775; 5 Oct 94 18:11 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa21346; 5 Oct 94 15:48 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWZPLQAPSIRI35H@INNOSOFT.COM>; Wed, 05 Oct 1994 11:44:40 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWTYUFTF4IRI4B6@INNOSOFT.COM>; Wed, 05 Oct 1994 11:44:34 -0700 (PDT) Date: Wed, 05 Oct 1994 11:38:44 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MADMAN "compliance" and Other Issues In-reply-to: Your message dated "Wed, 05 Oct 1994 08:15:24 -0500 (est)" <9409057813.AA781370184@isdlink1.ess.harris.com> To: GBEST01 Cc: gjones@terra.mitre.org, ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <01HHWZPK73UEIRI4B6@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > Adding objects "at the end" of a table or MIB would affect GETNEXT > operations by returning OIDs that a management application may not be > expecting. This may or may not be a problem, it all depends on the > management application and how it is being used. I would think that > this approach would not be "MADMAN-compliant". Exactly! > In my opinion, the place for early experimentation is under private > enterprise branches. For example, one could configure the entire MIB > branch with the experimental extensions under a private enterprise > number so that it may be evaluated prior to initiating contact with > the IETF to propose extending the MIBs. It is important to note that there are two ways to do this. One is to take the MADMAN MIB and simply modify it, putting it under some separate branch in the tree. This works and is easy, but then cannot realistically be brought into alignment with the original MIB without a lot of work. I believe a better way to do this is to define a separate MIB that references the earlier MIB, with tables containing only the additional variables. This not only is automatically aligned with the original MIB, it also forces you to think about how variables should be grouped into tables and how mandatory support for a given variable should be. Speaking from experience, this evaluation is the hard part. Inventing variables is trivial. Figuring out how they should be handled is not, and forces you to come to grips with the actual utility of proposed variable in each case. > Has there been a precedent established with the network management > MIBs? This sort of thing is done all the time with various MIBs. The core tables contain only the variables that are universally important and can be universally supported. Take special note of the latter -- it will be the criteria under which additions to the core MIB will be judged in the long run. Making the core MIB unimplementable on low-end MTAs is not an acceptable outcome. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01791; 5 Oct 94 18:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01787; 5 Oct 94 18:11 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa21541; 5 Oct 94 15:57 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWZCPZ2K0IRI35H@INNOSOFT.COM>; Wed, 05 Oct 1994 11:34:17 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHWTYUFTF4IRI4B6@INNOSOFT.COM>; Wed, 05 Oct 1994 11:34:11 -0700 (PDT) Date: Wed, 05 Oct 1994 11:05:03 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MADMAN "compliance" and Other Issues In-reply-to: Your message dated "Tue, 04 Oct 1994 17:44:41 -0400" <9410042144.AA14096@terra.mitre.org> To: gjones@gateway.mitre.org Cc: GBEST01@isdlink1.ess.harris.com, gjones@terra.mitre.org, tsc-l@ema.org, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <01HHWZCO6PTGIRI4B6@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > I. On the definition of MTA group > The EMA document needs to state that a particular aspect of > the group abstraction has been selected for implementation, > and state what that aspect is in precise terms. It should not > attempt to redefine what a group is, especially in a way such > that it constrains the concept so as to make it unusable by > an existing or prospective implementation, including those > resulting from the EMA agreement itself. This position is quite acceptable. I happen to think it is a truly terrible idea that will result in the EMA's recommendation in this area being entirely useless in practice, but that's just my opinion. I have no procedural objection to it. > Mr. Kille's idea of conducting a joint meeting between EMA > and MADMAN is the right one. Since the EMA group is active and > MADMAN is presently dormant, perhaps one of our meetings would > be an acceptable venue. Joint meetings are fine and are done all the time, but there are procedural issues that have to be dealt with before such meetings can properly accounted for as part of the IETF process. This is something that will have to be coordinated with both the IESG management and applications area directors, since MADMAN spans both areas. The application director to contact is probably John Klensin (klensin@infoods.mit.edu) and the management area director is Marshall Rose (mrose@dbc.mtview.ca.us). I believe John Klesin is in fact in the DC area these days, and as such it would probably make all kinds of sense to see if he can attend at least part of the EMA meeting next week. I stand ready and willing to facilitate this in any way I can -- I will be there the entire week myself. Honesty compells me to add the following warning, however: I am not at all optimistic that anything along these lines will happen. I have advised various EMA people on many separate occasions occasions of their urgent need to liase with appropriate IESG members and directors, and to the best of my knowledge nothing has ever been done about this. There seems to be some feeling there that I speak for the IETF and even the IESG, and that my unwillingness to agree to various EMA proposals that would be binding on the IETF in some way constitutes an IETF rejection of said proposals. The simple fact is I do NOT speak for the IETF in any capacity. I'm a member of the application area directorate and that's it. This essentially means that when the applications area directors want an opinion about some piece of work they can direct me to read the thing and give them an opinion. If they choose to run with that opinion in some form they can, or they can choose to ignore it. It is their choice and I have no say in it. I have absolutely no authority to set policy of any sort, especially not in venue matters, where I lack both authority and competence! > II. On MADMAN Compliance > Let me use an example. Can a vendor add some vendor-specific > variables to the end of the MtaGroupEntry without affecting > the "view" of the MtaGroupEntry as seen by other vendor > implementations ? No. This would effectively add new variables that would be visible to various SNMP primitives (GET-NEXT and GET-BULK). It is therefore not permissible to do this. What *is* permissible is to have another table, perferably in another MIB rooted under a separate OID, organized with the same group index, that contains the additional variables. You can have as many of these as you want, of course, and you may want to think about how to organize your variables into sets that make sense to implement together. A table for conversion operations, for example, might be a good thing to have. > Would other implementations that did not > deviate from the exact RFC1566 definition of MADMAN encounter > difficulties when interoperating with with the extended version ? Yes they would. However, it is not necessary in practice to do anything like this. It is philosophically at odds with the design of SNMP itself. The mechanism of using a separate table that's correlated with the original set of tables is the proper way to extend the set of variables that can be monitored. It is my understanding that the whole area of how extensions are accomplished in SNMP has always been a hotly debated topic. The present mechanism of optional tables in MIBs and conformance criteria reflects a compromise between those who wanted the ability to extend willy-nilly and damn the costs and those who don't want to allow any extension at all. > Politically, the extended version is not compliant, but technically > my gut instinct tells me that one may run experiments with an > extended version as the basic capability described in MADMAN > remains deployed. Expermentation is fine, of course -- nobody can control it even if they wanted to. But by and large the SNMP community now seems to view this specific way of doing business as an unnecessary breach of proper management style. And I would venture to guess that any concrete proposal built along these lines would be rejected by the Management Area Director out of hand. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01795; 5 Oct 94 18:11 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id ab01787; 5 Oct 94 18:11 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa21547; 5 Oct 94 15:58 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX17DIT9SIRI35H@INNOSOFT.COM>; Wed, 05 Oct 1994 12:27:15 -0700 (PDT) Received: from lightning.synoptics.com by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX16JYRWWIRI6IC@INNOSOFT.COM>; Wed, 05 Oct 1994 12:27:08 -0700 (PDT) Received: from SynOptics.COM ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA01428; Wed, 5 Oct 94 12:25:17 PDT Received: from immer (immer.synoptics.com) by SynOptics.COM (4.1/SMI-4.1) id AA24241; Wed, 5 Oct 94 12:23:19 PDT Received: by immer (4.1/2.0N) id AA09478; Wed, 5 Oct 94 12:22:56 PDT Date: Wed, 05 Oct 1994 12:22:56 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Dave Perkins Subject: Re: MADMAN "compliance" and Other Issues To: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9410051922.AA09478@immer> Content-transfer-encoding: 7BIT Guys, On the question of how to add objects to MIBs, here are some guidelines: 1) Only IETF-WGs can modify IETF MIBs. If you want to experiment with extending a MIB, you must do this in another OID address space that you control (and in another MIB module). 2) SNMP MIBs are designed to be extended. Application writters must not assume that only specific objects are in a MIB. 3) SNMPv1 agents must return "noSuch" errors for objects that they haven't implemented or for instances that don't exist. (And they must return the new errors/values in SNMPv2.) Application writters must be aware of this and must gracefully react to SNMP responses that may return errors on GET/SET and "skip over" objects on GETNEXT. 4) The "normal" way that tables are read is a row at a time with SNMPv1/v2 using GETNEXT, and multiple rows in a request with SNMPv2 using GETBULK. The reading of the table ends when the requests returns object-types different from the request. What these object-types are are doesn't matter, only that they are different from the object-types that were requested. If an IETF WG adds more columns to the table or adds objects between the table and the original lexi-next object, this should not effect the application. Hope this helps. It seemed like the discussion was getting tangled up due to lack of understanding of SNMP. /dave perkins, synoptics, 408-764-1516   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01990; 5 Oct 94 18:22 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01986; 5 Oct 94 18:22 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa25091; 5 Oct 94 18:22 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX5E8NL5SIRI35H@INNOSOFT.COM>; Wed, 05 Oct 1994 14:27:18 -0700 (PDT) Received: from SIGURD.INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX5E742PCIRHJXW@INNOSOFT.COM>; Wed, 05 Oct 1994 14:27:12 -0700 (PDT) Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #2001) id <01HHX0ZM3UB48ZDZDI@SIGURD.INNOSOFT.COM>; Wed, 05 Oct 1994 14:27:04 -0700 (PDT) Date: Wed, 05 Oct 1994 14:16:54 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MADMAN "compliance" and Other Issues In-reply-to: Your message dated "Wed, 05 Oct 1994 12:22:56 -0700 (PDT)" <9410051922.AA09478@immer> To: Dave Perkins Cc: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <01HHX5E0X6W08ZDZDI@SIGURD.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > 3) SNMPv1 agents must return "noSuch" errors for objects > that they haven't implemented or for instances that > don't exist. (And they must return the new errors/values > in SNMPv2.) Application writters must be aware of this > and must gracefully react to SNMP responses that may > return errors on GET/SET and "skip over" objects on > GETNEXT. Interesting. I stand corrected on this point. > 4) The "normal" way that tables are read is a row at > a time with SNMPv1/v2 using GETNEXT, and multiple > rows in a request with SNMPv2 using GETBULK. The > reading of the table ends when the requests returns > object-types different from the request. What these > object-types are are doesn't matter, only that they > are different from the object-types that were requested. > If an IETF WG adds more columns to the table or > adds objects between the table and the original lexi-next > object, this should not effect the application. Hmm. Well, my understanding is that if a table is implemented at all it must be implemented in its entirety by an agent. Is this incorrect? Can an implementation elect to skip columns it does not support any time it so chooses? I don't think I made this clear in my original response, but my primary concern here has nothing to do with the technical innards of SNMP. It is quite clear that the SNMP operators themselves can easily deal with missing information, and I was not aware that management stations are required to handle this gracefully. The real issue is that the additions will necessarily be things that cannot be implemented in some environments we have to be able to support with MADMAN (there are already reports that the current MIB requires too much) and therefore it is not permissible to put these things into the existing tables. My understanding here is that the way around this is to create new tables for this purpose and use the conformance mechanisms in SNMPv2 to specify what is mandatory and what is optional. I derived most of this understanding by looking at existing MIBs, many of which have chosen to implement along these lines. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02402; 5 Oct 94 18:47 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa02398; 5 Oct 94 18:47 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa25725; 5 Oct 94 18:47 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX75RGAAOIRHJXT@INNOSOFT.COM>; Wed, 05 Oct 1994 15:17:45 -0700 (PDT) Received: from ppp.dbc.mtview.ca.us by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX75FTVLSIRHK4Z@INNOSOFT.COM>; Wed, 05 Oct 1994 15:17:38 -0700 (PDT) Received: from dbc.mtview.ca.us by dbc.mtview.ca.us (5.65/3.1.090690) id AA21696; Wed, 5 Oct 94 15:07:27 -0700 Date: Wed, 05 Oct 1994 15:07:21 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Marshall Rose Subject: Re: MADMAN "compliance" and Other Issues In-reply-to: Your message of "Wed, 05 Oct 1994 11:05:03 PDT." <01HHWZCO6PTGIRI4B6@INNOSOFT.COM> To: Ned Freed Cc: gjones@gateway.mitre.org, GBEST01@isdlink1.ess.harris.com, gjones@terra.mitre.org, tsc-l@ema.org, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <21692.781394841@dbc.mtview.ca.us> Content-id: <21690.781394840.1@dbc.mtview.ca.us> MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT Form: mrose.iesg Please note the From: line. I am having considerable difficulty understanding what the problem is. So, here is a summary of the relevant rules: The IESG is solely empowered to declare documents as "Internet standards". These documents are published in the "RFC" archival series. Normally these RFCs are iteratively produced by IETF working groups and published as "Internet-Drafts". When a WG reaches consensus on a document, the relevant Area Director performs a technical and process review and then makes a recommendation to the IESG as to the status of the document. The IESG then decides the level of standardization status (if any) that is assigned to the document when it is published as an RFC. Documents that contain MIB modules are usually "rooted" under one of three different arcs: mib2 -- if the MIB module is on the standards-track experimental -- if the MIB module is currently being developed by a WG prior to IESG review enterprise -- otherwise (e.g., when some third-party wants to define a MIB module) If someone wants to define "extensions" to a document on the standards-track, then they get their own enterprise number from the IANA and define their own MIB module. This MIB module should *not* duplicate the objects in the standards-track document, rather it should augment them. The SNMPv2 framework provides mechanisms (e.g., the AUGMENTS clause, so one can define extensions to an existing table). So, if organization XYZ wants to define some extensions to a standards-track MIB, they get themselves an enterprise OID and define their own MIB module using the mechanisms provided in the SNMPv2 framework. In addition, to definining new objects, groups may define additional "conformance" requirements using the macros provided by the SNMPv2 framework. Finally, with respect to liasion between the IETF and other groups. There is no such thing. If individuals wish to participate in IETF WGs, they may do so, as individuals (we do not recognize representatives of any kind, either from governments, companies, or consortia). Similarly, if people who participate in IETF WGs wish to attend meetings of other groups, they are free to do so, however, they do not represent either the IETF or the Internet community... /mtr (IETF Area Director for Network Management) ps: Ned I think you mis-spoke when you stated that "how extensions are accomplished in SNMP has always been a hotly debated topic." There has never been any controvesry. The rules are quite clear on the matter. What has been the subject of discussion is how agents should behave when they are asked for information on things they don't know about. It turns out that the rules are quite clear on that matter as well; however, some agent implementors seem to feel that they can implement SNMP without actually reading the relevant RFCs.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03434; 5 Oct 94 21:00 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03430; 5 Oct 94 21:00 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa27913; 5 Oct 94 21:00 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX9XJKK00IRI0JO@INNOSOFT.COM>; Wed, 05 Oct 1994 16:37:25 -0700 (PDT) Received: from comm.Tandem.COM (comm.cpd.tandem.com) by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHX9XFBRF4IRHZRL@INNOSOFT.COM>; Wed, 05 Oct 1994 16:37:18 -0700 (PDT) Received: by comm.Tandem.COM (4.12/4.5) id AA32057; 5 Oct 94 16:36:34 -0700 Date: Wed, 05 Oct 1994 15:06:00 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: LEBECK_SUE@tandem.com Subject: Re: MADMAN "compliance" and Other Issues To: ned@innosoft.com, s.kille@isode.com Cc: gbest01@isdlink1.ess.harris.com, gjones@terra.mitre.org, ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <199410051636.AA32057@comm.Tandem.COM> Content-transfer-encoding: 7BIT Ned, Steve, all -- Please see the attached. I created these 2 cents during snippets of opportunity today... only to find that since then lots more mail has come thru on this topic:-) The new mails tell me the following: 1. The general approach of extending MADMAN in function-oriented ways, where a new table is defined to address a given (optional) function, is a fairly non-controversial way to proceed. 2.Perhaps it is technically possible to extend the MADMAN tables in small ways, prior to moving from "Draft Standard" to "Standard in ways that won't break current MADMAN-based applications. (It's coolness or un-coolness depends on the perspective of who you are talking to.) In any case, such explorations and any joint meetings should be initiated with the appropriate IESG area directors (John Klensin and Marshall Rose); I'll send them a note under separate cover. Best, Sue ------------ TEXT ATTACHMENT -------- SENT 10-05-94 FROM LEBECK_SUE >> Adding objects "at the end" of a table or MIB would affect GETNEXT >> operations by returning OIDs that a management application may not be >> expecting. This may or may not be a problem, it all depends on the >> management application and how it is being used. I would think that >> this approach would not be "MADMAN-compliant". > >Exactly! > Right. The only way to add to the base MADMAN tables would be if small changes would be entertained during the process of moving from "Draft Standard" to "Standard". Is this an explorable path? > In my opinion, the place for early experimentation is under private >> enterprise branches. For example, one could configure the entire MIB >> branch with the experimental extensions under a private enterprise >> number so that it may be evaluated prior to initiating contact with >> the IETF to propose extending the MIBs. > >It is important to note that there are two ways to do this. One is to take the >MADMAN MIB and simply modify it, putting it under some separate branch in the >tree. This works and is easy, but then cannot realistically be brought into >alignment with the original MIB without a lot of work. > >I believe a better way to do this is to define a separate MIB that references >the earlier MIB, with tables containing only the additional variables. This no >only is automatically aligned with the original MIB, it also forces you to >think about how variables should be grouped into tables and how mandatory >support for a given variable should be. Speaking from experience, this >evaluation is the hard part. Inventing variables is trivial. Figuring out >how they should be handled is not, and forces you to come to grips with the >actual utility of proposed variable in each case. > I agree with your proposed "better way". This approach has the potential to work nicely, particularly if a group of variables is proposed to address a particular purpose. For example, some EMA-discussed additions were motivated by a desire to have more performance monitoring information. So, for example, an optional "performance monitoring table" might be added to focus on this need, and back-point appropriately into the MADMAN tables. Support for this table wouldn't be required for MADMAN compliance (but may or may not be required for compliance to the EMA specification.) EMA references to MADMAN would remain references to "vanilla" MADMAN. If, however, only one or two additional attributes are identified as important additions, new table adds are probably overkill. Again, I'm interested in whether there is expected to be any room to make changes to MADMAN between "Draft Standard" and "Standard" status, and under what conditions such changes would be entertained. >>> Has there been a precedent established with the network management >>> MIBs? > > This sort of thing is done all the time with various MIBs. The core tables > contain only the variables that are universally important and can be > universally supported. Take special note of the latter -- it will be the > > criteria under which additions to the core MIB will be judged in the long run > Making the core MIB unimplementable on low-end MTAs is not an acceptable > outcome. I could not agree more! Best, Sue   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03506; 6 Oct 94 9:28 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa03502; 6 Oct 94 9:28 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa04444; 6 Oct 94 9:28 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHXVXBPCCWIRI5WC@INNOSOFT.COM>; Thu, 06 Oct 1994 03:07:10 -0700 (PDT) Received: from trane.uninett.no by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHXVX6SS9CIRI6IB@INNOSOFT.COM>; Thu, 06 Oct 1994 03:07:01 -0700 (PDT) Received: by trane.uninett.no with UUCP id AA04774 (5.67b/IDA-1.5 for ietf-madman@INNOSOFT.COM); Thu, 6 Oct 1994 11:06:41 +0100 Received: from localhost (hta@localhost) by dale.uninett.no (8.6.9/8.6.9) with SMTP id TAA02695; Wed, 5 Oct 1994 19:14:21 +0100 Date: Wed, 05 Oct 1994 19:14:21 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Harald.T.Alvestrand@uninett.no Subject: Re: Re[2]: Recommendations of the TSC In-reply-to: Your message of "Tue, 04 Oct 1994 11:12:42 MET." <9409047812.AA781294395@isdlink1.ess.harris.com> X-Orig-Sender: hta@dale.uninett.no To: GBEST01 Cc: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <199410051814.TAA02695@dale.uninett.no> Content-transfer-encoding: 7BIT X-Authentication-Warning: dale.uninett.no: Host localhost didn't use HELO protocol As I remember the MADMAN discussions, the focus was on writing a MIB that is implementable on a large number of MTAs. Given the fact that there is NO consensus between MTA implementors on how messages are divided up into groups before sending (for ex. Sendmail keeps them in ONE group, while PP has two levels of subgroups, the lowest of which is dynamically created and destroyed), there was consensus that we had to leave the semantics of the division of messages into groups as an implementation issue. We all know that this limits the usefulness; if MTA A is down, you cannot ask MTAs B and C how many messages are queued there for A, since they may not group on this property of the message, or one might and one might not; but it was the approach that it was possible to gain consensus for. I don't think anyone in the MADMAN group ever thought that the MADMAN document, as it stands, is the final and definitive answer to how MTAs should be monitored; defining new tables, perhaps with the exact same properties as the Group table entries, but with a defined meaning applied to the division into groups, might be a Good Thing; but such tables could not be made mandatory for all implementations. Have fun! Harald A   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09671; 6 Oct 94 15:37 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09667; 6 Oct 94 15:37 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa15536; 6 Oct 94 15:37 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHYDNPKSM8IRHJXT@INNOSOFT.COM>; Thu, 06 Oct 1994 11:34:49 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHY7Q4CVDSIRI4B6@INNOSOFT.COM>; Thu, 06 Oct 1994 11:34:41 -0700 (PDT) Date: Thu, 06 Oct 1994 11:26:25 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MADMAN "compliance" and Other Issues In-reply-to: Your message dated "Wed, 05 Oct 1994 15:06:00 -0700" <199410051636.AA32057@comm.Tandem.COM> To: LEBECK_SUE@tandem.com Cc: ned@innosoft.com, s.kille@isode.com, gbest01@isdlink1.ess.harris.com, gjones@terra.mitre.org, ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <01HHYDNNMLLUIRI4B6@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > Please see the attached. I created these 2 cents during snippets > of opportunity today... only to find that since then lots more mail > has come thru on this topic:-) The new mails tell me the following: > 1. The general approach of extending MADMAN in function-oriented > ways, where a new table is defined to address a given (optional) > function, is a fairly non-controversial way to proceed. Absolutely. This is the approach I've been recommending. > 2.Perhaps it is technically possible to extend the MADMAN tables > in small ways, prior to moving from "Draft Standard" to "Standard > in ways that won't break current MADMAN-based applications. > (It's coolness or un-coolness depends on the perspective of who > you are talking to.) Breaking existing applications is just one of the issues. There are at least two others: (1) Additions to a specification more or less require a reset to proposed standard status, and the process starts all over again. Exceptions might be made when the addition is ***REALLY*** small, quite isolated, and can be shown to have no significant impact, but in practice any addition worth having won't meet these criteria. This is not necessarily a good thing or a bad thing either -- it will likely upset some people while others will be indifferent to it. The tradeoff is, of course, between getting a desirable new feature and adding more time before the standard is finalized. (2) Additions have to measure up against what a lowest-common-demoninator MTA can implement. Requiring variables that cannot be implemented in all of the common MTAs on the Internet is not acceptable. This being said, let me also say that I have no objection to the addition of demonstrably useful variables to the base tables that meet the criteria of (2). Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa09683; 6 Oct 94 15:37 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa09679; 6 Oct 94 15:37 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa15541; 6 Oct 94 15:37 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHYE6SXFSWIRHJXT@INNOSOFT.COM>; Thu, 06 Oct 1994 11:49:27 -0700 (PDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HHY7Q4CVDSIRI4B6@INNOSOFT.COM>; Thu, 06 Oct 1994 11:49:18 -0700 (PDT) Date: Thu, 06 Oct 1994 11:36:19 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MADMAN "compliance" and Other Issues In-reply-to: Your message dated "Wed, 05 Oct 1994 15:07:21 -0700" <21692.781394841@dbc.mtview.ca.us> To: Marshall Rose Cc: Ned Freed , gjones@gateway.mitre.org, GBEST01@isdlink1.ess.harris.com, gjones@terra.mitre.org, tsc-l@ema.org, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <01HHYE6QWAPGIRI4B6@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT > Finally, with respect to liasion between the IETF and other groups. > There is no such thing. If individuals wish to participate in IETF > WGs, they may do so, as individuals (we do not recognize > representatives of any kind, either from governments, companies, or > consortia). Similarly, if people who participate in IETF WGs wish to > attend meetings of other groups, they are free to do so, however, they > do not represent either the IETF or the Internet community... This is all quite correct as far as it goes, but really isn't what I meant at all. The issue as I understand it in the case of the TSC work is more one of the possibility of joint or overlapping meetings. And IETF working groups can and do have meetings in other venues. The reason this is permissible is a consequence of face-to-face IETF meetings having no real status anyway -- the true design work and decisions and consensus reaching are done on the various WG mailing lists. However, setting these things up does require some measure of coordination for announcements and minutes and whatnot. This is the liason I referred to. There are also other EMA activities that are in urgent need of coordination with the IETF, but that's another discussion for another day. > ps: Ned I think you mis-spoke when you stated that "how extensions are > accomplished in SNMP has always been a hotly debated topic." There has > never been any controvesry. The rules are quite clear on the matter. > What has been the subject of discussion is how agents should behave > when they are asked for information on things they don't know about. > It turns out that the rules are quite clear on that matter as well; > however, some agent implementors seem to feel that they can implement > SNMP without actually reading the relevant RFCs. Sorry I was unclear. I was specifically referring to an instance of the latter: The issues that arise when there are variables that an agent has no way of implementing. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08839; 7 Oct 94 19:38 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08835; 7 Oct 94 19:38 EDT Received: from [192.160.253.66] by CNRI.Reston.VA.US id aa19503; 7 Oct 94 19:38 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HI01STSY4WIRHW0F@INNOSOFT.COM>; Fri, 07 Oct 1994 16:16:53 -0700 (PDT) Received: from SIGURD.INNOSOFT.COM by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HI01SSHAA8IRIANO@INNOSOFT.COM>; Fri, 07 Oct 1994 16:16:49 -0700 (PDT) Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.4-0 #2001) id <01HHZUV0P6MO8ZE3XX@SIGURD.INNOSOFT.COM>; Fri, 07 Oct 1994 16:16:18 -0700 (PDT) Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: Re: MADMAN "compliance" and Other Issues In-reply-to: Your message dated "Fri, 07 Oct 1994 13:03:00 -0700" <199410071548.AA8505@comm.Tandem.COM> To: LEBECK_SUE@tandem.com Cc: gbest01@isdlink1.ess.harris.com, gjones@terra.mitre.org, ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <01HI01S4X6P08ZE3XX@SIGURD.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > The fact that, if a change is made to a Proposed Standard, it has to > be re-issued in "proposed" form for another cycle before becoming > "standard" was not previously appreciated by me. I understand the > conservatism this produces. Always keep in mind that just because it resets things is no reason not to add things we really need. It just makes the wall somewhat higher, not unscalable. Ned   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa08867; 7 Oct 94 19:42 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa08863; 7 Oct 94 19:42 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa19554; 7 Oct 94 19:42 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HI00UZUQLCIRHWTC@INNOSOFT.COM>; Fri, 07 Oct 1994 15:49:39 -0700 (PDT) Received: from comm.Tandem.COM (comm.cpd.tandem.com) by INNOSOFT.COM (PMDF V4.3-11 #2001) id <01HI00UV2JPSIRIAFG@INNOSOFT.COM>; Fri, 07 Oct 1994 15:49:32 -0700 (PDT) Received: by comm.Tandem.COM (4.12/4.5) id AA8505; 7 Oct 94 15:48:50 -0700 Date: Fri, 07 Oct 1994 13:03:00 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: LEBECK_SUE@tandem.com Subject: Re: MADMAN "compliance" and Other Issues To: ned@innosoft.com Cc: gbest01@isdlink1.ess.harris.com, gjones@terra.mitre.org, s.kille@isode.com, ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <199410071548.AA8505@comm.Tandem.COM> Content-transfer-encoding: 7BIT Ned -- The fact that, if a change is made to a Proposed Standard, it has to be re-issued in "proposed" form for another cycle before becoming "standard" was not previously appreciated by me. I understand the conservatism this produces. Your proposed criteria are useful ones, and will be helpful to our work next week. Best, Sue   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14567; 26 Oct 94 18:39 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa14563; 26 Oct 94 18:39 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa21478; 26 Oct 94 18:39 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-12 #2001) id <01HIQIM37JUO9VUQRM@INNOSOFT.COM>; Wed, 26 Oct 1994 14:58:27 -0700 (PDT) Received: from blinky.ccmail.com (ccmail.COM) by INNOSOFT.COM (PMDF V4.3-12 #2001) id <01HIQILXSQXC9VUS6P@INNOSOFT.COM>; Wed, 26 Oct 1994 14:58:19 -0700 (PDT) Received: from smtpgate.ccmail.com by blinky.ccmail.com (4.1/SMI-4.1) id AA23372; Wed, 26 Oct 94 14:59:19 PDT Received: from cc:Mail by smtpgate.ccmail.com id AA783208571; Wed, 26 Oct 94 14:53:08 pst Date: Wed, 26 Oct 1994 14:53:08 -0800 (pst) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: eowens@ccmail.com Subject: Comments on RFC 1565/1566 To: ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <9409267832.AA783208571@smtpgate.ccmail.com> Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID tBRBw+eneOy6vz28bg7tcQ)" Content-transfer-encoding: 7BIT --Boundary (ID tBRBw+eneOy6vz28bg7tcQ) Content-type: TEXT/PLAIN Folks, A further reading of RFC 1565 and 1566 I would like to propose changes to 1566. In RFC 1565 those data elements having to do with time are of the SYNTAX TimeStamp. (applUptime, applLastChange, applLastInboundActivity, applLastOutboundActivity and assocDuration). By specifying a timeStamp the RFC allows for rather non-intelligent agents to insert/remember just the value of sysUpTime when a particular activity occurs. It is up to the management work station to calculate such things as duration and excessive delay. In RFC 1566 those data elements having to do with time are of the SYNTAX TimeInterval. (mtaGroupOldestMessageStored, mtaGroupLastInboundActivity, mtaGroupLastOutboundActivity and mtaGroupScheduledRetry). In this case, the agent must be prepared, when a request is made for this information, to calculate the elapsed time since an event occured (to do this it is assumed that the actual sysUpTime of the event is stored somewhere but the returned value is the difference between that time and the current sysUpTime). In the case of mtaGroupScheduledRetry this is extremely problematic. I recommend that the above mentioned elements in RFC 1566 be changed to SYNTAX TimeStamp and that the DESCRIPTION be reworded to reflect this similar to the wording in RFC 1565. Regards, Ed Owens eowens@ccmail.com --Boundary (ID tBRBw+eneOy6vz28bg7tcQ)--   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa04132; 27 Oct 94 10:37 EDT Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa04128; 27 Oct 94 10:37 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa07625; 27 Oct 94 10:37 EDT Received: from REPROCESS-DAEMON by INNOSOFT.COM (PMDF V4.3-13 #2001) id <01HIRH3MAYXS9VUS1T@INNOSOFT.COM>; Thu, 27 Oct 1994 07:26:05 -0700 (PDT) Received: from domen.uninett.no by INNOSOFT.COM (PMDF V4.3-13 #2001) id <01HIRH3JCWGW9VUOUH@INNOSOFT.COM>; Thu, 27 Oct 1994 07:26:01 -0700 (PDT) Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <29197-0@domen.uninett.no>; Thu, 27 Oct 1994 15:25:43 +0100 Received: from localhost (hta@localhost) by dale.uninett.no (8.6.9/8.6.9) with SMTP id PAA02422; Thu, 27 Oct 1994 15:25:39 +0100 Date: Thu, 27 Oct 1994 15:25:37 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Harald.T.Alvestrand@uninett.no Subject: Re: Comments on RFC 1565/1566 In-reply-to: Your message of "Wed, 26 Oct 1994 14:53:08 MET." <9409267832.AA783208571@smtpgate.ccmail.com> X-Orig-Sender: hta@dale.uninett.no To: eowens@ccmail.com Cc: ietf-madman@innosoft.com, tsc-l@ema.org Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Message-id: <199410271425.PAA02422@dale.uninett.no> X-Mailer: exmh version 1.5phi 9/15/94 Content-transfer-encoding: 7BIT X-Authentication-Warning: dale.uninett.no: Host localhost didn't use HELO protocol Re use of TimeStamp vs TimeInterval: As far as I remember the group's deliberations, the difference was done deliberately. - It is sensible to think that an MTA will have activity, therefore the cases where applLastInboundActivity is before the current SysUpTime will be exceedingly rare, and probably not worth special coding. - There will be *lots* of cases where the MTA will go down, come up, and still have old messages in the queue, so mtaGroupOldestMessageStored can easily refer to a time before the current sysUpTime. I once raised this (with the opposite change in mind), and got a brief discourse from Marshall Rose on the philosophy of times in SNMP. Harald A