From entmib-admin@ietf.org Sun Dec 7 12:00:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27595 for ; Sun, 7 Dec 2003 12:00:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT2GK-0001ry-Pj; Sun, 07 Dec 2003 12:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT2Fy-0001rF-Aq for entmib@optimus.ietf.org; Sun, 07 Dec 2003 11:59:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27560 for ; Sun, 7 Dec 2003 11:59:27 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT2Fw-0002p1-00 for entmib@ietf.org; Sun, 07 Dec 2003 11:59:40 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AT2Fw-0002oy-00 for entmib@ietf.org; Sun, 07 Dec 2003 11:59:40 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB7GxdV08576 for ; Sun, 7 Dec 2003 18:59:39 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 7 Dec 2003 18:59:38 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 7 Dec 2003 08:59:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Dec 2003 11:59:36 -0500 Message-ID: Thread-Topic: DRAFT Entity MIB Minutes for IETF 58 Thread-Index: AcO84351bTc2wsq6Sd6KI+xslnLqMA== To: X-OriginalArrivalTime: 07 Dec 2003 16:59:37.0798 (UTC) FILETIME=[7F6D6660:01C3BCE3] Content-Transfer-Encoding: quoted-printable Subject: [Entmib] DRAFT Entity MIB Minutes for IETF 58 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi All, I have attached the draft minutes from our meeting at IETF 58. Please let me know if you notice any mistakes or omissions. The minutes include action items for several of us. Please follow up on your action items, or let me know if you will not be able to do so. I would also like to confirm the consensus that we reached within the room on the following points: - We will deprecate the Alias Mapping Table so that the Entity MIB can advance to Draft Standard. - Future extensions to the Entity MIB should be handled as separate MIBs that augment the Entity MIB. - The Entity State MIB is currently too complex and should be simplified. If any of you have thoughts that you'd like to share regarding the above items, please feel free to discuss them on the list. Thanks, Margaret --- Entity MIB WG [entmib] Minutes Wednesday, November 12, 2003 IETF 58, Minneapolis, MN, USA =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIR: =20 Margaret Wasserman AGENDA: Entity MIB -- Andy Bierman (15 min) - Status of move to Draft Standard - How to handle future extensions? Entity State MIB -- David Perkins? (15 min) - Status and Open Issues TCIF Proposal -- Margaret for Kaj Tesink (10 min) - Discussion of potential new work SUMMARY: The Entity MIB is nearly ready for advancement to Draft Standard, but we do not have two implementations of the Alias Mapping Table. A decision was made to deprecate the Alias Mapping Table and advance=20 the Entity MIB to DS. We also discussed how to handle future extensions to the Entity MIB and concluded that they should be handled as separate MIBs that augment the Entity MIB. The Entity State MIB was not updated between the Vienna and Minneapolis meetings, and status was unclear as the editor was not present. There did seem to be interest in the room to continue this work. We also had consensus within the room that the current MIB is too complex and should be simplified. However, Margaret and Bert agreed that we would remove this MIB from the Entity MIB charter if no progress is exhibited before the end of December. There was interest in the room regarding the TCIF proposal and some constructive suggestions were made to improve it. Margaret will ask Kaj Tesink to publish the proposal as an I-D. However, this group will not be permitted to take on a new work item unless/until it shows progress on the work items it already has (see above). ACTION ITEMS: Margaret Publish meeting minutes=20 Andy Update Entity MIB to deprecate Alias Mapping Table Margaret Talk to Sharon about status of Entity State MIB Sharon Update Entity State MIB by end of December? (not = present) Dave P. Send suggestion to list for generalized TCIF objects Margaret Ask Kaj Tesink to submit individual I-D for TCIF Margaret/Bert Determine status of Entity State MIB at end of December DISCUSSION NOTES: Entity MIB =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Alias Mapping Table - not enough implementations reported. Do we deprecate now or wait for more reports? RFC2737 has been out for years, and it has been implemented, but we don't have reports. Will deprecate - Bert can add dire warning to IETF last call. Extensions should be done through AUGMENTS, etc. so the base document can advance.=20 Entity State MIB =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Status unknown. No new data about open issues. Discussion that this is a complex mib that is costly to implement. Do we have consensus on what we want contained in this mib? This started out adding one column and balooned. DanR - this got more complex than originally wanted it to be. It is not remaining true to the ITU standard. This was just supposed to be a uniform place to be to determine whether the LED should be red, yellow, or green. The Entity mib only gives you inventory; this was supposed to give you basic health of the device. Does anybody argue that we need the level of complexity that is in this mib? Sense of the room is that the MIB should be simplified, but key players are not represented. Take it to the list whether to eliminate, simplify, or complete this mib.=20 The editing has not been as timely as needed. Margaret to check with Sharon about whether she still wants to edit thid document. Bert, Margaret - if we don't have an updated document with known issue resolutions documented by the end of December then the document may be removed from the charter. TCIF Proposal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCIF proposal for new objects for T1M1.3 and other standards. Two needed objects, sparse augmentation, read-write so data can be plugged in after the manufacture. Sense of the room is to have a supplemental mib rather than modifying base document. Agreed it would be good to standardize mfr date.=20 Discussion of CLIE code. CLIE code costs money, so object should be optional. Recommendation to add two columns - one to identify industry segment code type and the code. Entity MIB already tells you what it is, so is this duplication? The telco segment uses CLIE codes,=20 Sense of the room - make a type/pair for this. Dave Perkins will send a couple objects to the list for consideration. Still under consideration whether this work should be undertaken by the ENTMIB WG (not in current charter). Will ask for individual submissions; Margaret will wordsmith the request to keep it properly constrained while allowing room for additional proposed objects. Bert - I don't like talking about new proposals when the existing proposals are not being completed.=20 Margaret: Kaj can submit an individual draft, and if the Entmib finishes its work, then it may consider adopting.=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Sun Dec 7 12:00:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27610 for ; Sun, 7 Dec 2003 12:00:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT2GN-0001sE-3z for entmib-archive@odin.ietf.org; Sun, 07 Dec 2003 12:00:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7H07qR007196 for entmib-archive@odin.ietf.org; Sun, 7 Dec 2003 12:00:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT2GK-0001ry-Pj; Sun, 07 Dec 2003 12:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AT2Fy-0001rF-Aq for entmib@optimus.ietf.org; Sun, 07 Dec 2003 11:59:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27560 for ; Sun, 7 Dec 2003 11:59:27 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AT2Fw-0002p1-00 for entmib@ietf.org; Sun, 07 Dec 2003 11:59:40 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AT2Fw-0002oy-00 for entmib@ietf.org; Sun, 07 Dec 2003 11:59:40 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB7GxdV08576 for ; Sun, 7 Dec 2003 18:59:39 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 7 Dec 2003 18:59:38 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 7 Dec 2003 08:59:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 7 Dec 2003 11:59:36 -0500 Message-ID: Thread-Topic: DRAFT Entity MIB Minutes for IETF 58 Thread-Index: AcO84351bTc2wsq6Sd6KI+xslnLqMA== To: X-OriginalArrivalTime: 07 Dec 2003 16:59:37.0798 (UTC) FILETIME=[7F6D6660:01C3BCE3] Content-Transfer-Encoding: quoted-printable Subject: [Entmib] DRAFT Entity MIB Minutes for IETF 58 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi All, I have attached the draft minutes from our meeting at IETF 58. Please let me know if you notice any mistakes or omissions. The minutes include action items for several of us. Please follow up on your action items, or let me know if you will not be able to do so. I would also like to confirm the consensus that we reached within the room on the following points: - We will deprecate the Alias Mapping Table so that the Entity MIB can advance to Draft Standard. - Future extensions to the Entity MIB should be handled as separate MIBs that augment the Entity MIB. - The Entity State MIB is currently too complex and should be simplified. If any of you have thoughts that you'd like to share regarding the above items, please feel free to discuss them on the list. Thanks, Margaret --- Entity MIB WG [entmib] Minutes Wednesday, November 12, 2003 IETF 58, Minneapolis, MN, USA =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D CHAIR: =20 Margaret Wasserman AGENDA: Entity MIB -- Andy Bierman (15 min) - Status of move to Draft Standard - How to handle future extensions? Entity State MIB -- David Perkins? (15 min) - Status and Open Issues TCIF Proposal -- Margaret for Kaj Tesink (10 min) - Discussion of potential new work SUMMARY: The Entity MIB is nearly ready for advancement to Draft Standard, but we do not have two implementations of the Alias Mapping Table. A decision was made to deprecate the Alias Mapping Table and advance=20 the Entity MIB to DS. We also discussed how to handle future extensions to the Entity MIB and concluded that they should be handled as separate MIBs that augment the Entity MIB. The Entity State MIB was not updated between the Vienna and Minneapolis meetings, and status was unclear as the editor was not present. There did seem to be interest in the room to continue this work. We also had consensus within the room that the current MIB is too complex and should be simplified. However, Margaret and Bert agreed that we would remove this MIB from the Entity MIB charter if no progress is exhibited before the end of December. There was interest in the room regarding the TCIF proposal and some constructive suggestions were made to improve it. Margaret will ask Kaj Tesink to publish the proposal as an I-D. However, this group will not be permitted to take on a new work item unless/until it shows progress on the work items it already has (see above). ACTION ITEMS: Margaret Publish meeting minutes=20 Andy Update Entity MIB to deprecate Alias Mapping Table Margaret Talk to Sharon about status of Entity State MIB Sharon Update Entity State MIB by end of December? (not = present) Dave P. Send suggestion to list for generalized TCIF objects Margaret Ask Kaj Tesink to submit individual I-D for TCIF Margaret/Bert Determine status of Entity State MIB at end of December DISCUSSION NOTES: Entity MIB =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Alias Mapping Table - not enough implementations reported. Do we deprecate now or wait for more reports? RFC2737 has been out for years, and it has been implemented, but we don't have reports. Will deprecate - Bert can add dire warning to IETF last call. Extensions should be done through AUGMENTS, etc. so the base document can advance.=20 Entity State MIB =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Status unknown. No new data about open issues. Discussion that this is a complex mib that is costly to implement. Do we have consensus on what we want contained in this mib? This started out adding one column and balooned. DanR - this got more complex than originally wanted it to be. It is not remaining true to the ITU standard. This was just supposed to be a uniform place to be to determine whether the LED should be red, yellow, or green. The Entity mib only gives you inventory; this was supposed to give you basic health of the device. Does anybody argue that we need the level of complexity that is in this mib? Sense of the room is that the MIB should be simplified, but key players are not represented. Take it to the list whether to eliminate, simplify, or complete this mib.=20 The editing has not been as timely as needed. Margaret to check with Sharon about whether she still wants to edit thid document. Bert, Margaret - if we don't have an updated document with known issue resolutions documented by the end of December then the document may be removed from the charter. TCIF Proposal =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TCIF proposal for new objects for T1M1.3 and other standards. Two needed objects, sparse augmentation, read-write so data can be plugged in after the manufacture. Sense of the room is to have a supplemental mib rather than modifying base document. Agreed it would be good to standardize mfr date.=20 Discussion of CLIE code. CLIE code costs money, so object should be optional. Recommendation to add two columns - one to identify industry segment code type and the code. Entity MIB already tells you what it is, so is this duplication? The telco segment uses CLIE codes,=20 Sense of the room - make a type/pair for this. Dave Perkins will send a couple objects to the list for consideration. Still under consideration whether this work should be undertaken by the ENTMIB WG (not in current charter). Will ask for individual submissions; Margaret will wordsmith the request to keep it properly constrained while allowing room for additional proposed objects. Bert - I don't like talking about new proposals when the existing proposals are not being completed.=20 Margaret: Kaj can submit an individual draft, and if the Entmib finishes its work, then it may consider adopting.=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Dec 8 08:25:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08535 for ; Mon, 8 Dec 2003 08:25:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLNl-0005pj-AV; Mon, 08 Dec 2003 08:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLN3-0005p9-UH for entmib@optimus.ietf.org; Mon, 08 Dec 2003 08:24:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08504 for ; Mon, 8 Dec 2003 08:24:02 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLN2-0003F0-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:24:16 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ATLN2-0003Ep-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:24:16 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB8DOEv18774 for ; Mon, 8 Dec 2003 15:24:14 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Dec 2003 15:24:14 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 8 Dec 2003 05:24:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Dec 2003 08:24:11 -0500 Message-ID: Thread-Topic: Confirmming Meeting Consensus Thread-Index: AcO9jpEquPVlbGf3QYC51RyjV0p76A== To: X-OriginalArrivalTime: 08 Dec 2003 13:24:13.0255 (UTC) FILETIME=[92366570:01C3BD8E] Content-Transfer-Encoding: quoted-printable Subject: [Entmib] Confirmming Meeting Consensus Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi All, During the meeting in Minneapolis, there was agreement in the room on a few points, an dI'd like to confirm that consensus on the mailing list. In particular, we reached agreement at the meeting on the following points: - We will deprecate the Alias Mapping Table so that the Entity MIB can advance to Draft Standard. =20 - Future extensions to the Entity MIB should be handled as separate MIBs that augment the Entity MIB. =20 - The Entity State MIB is currently too complex and should be simplified. Please feel free to express your opinion on any of these points on the mailing list. Thanks, Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Dec 8 08:25:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08550 for ; Mon, 8 Dec 2003 08:25:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLNn-0005qf-Qb for entmib-archive@odin.ietf.org; Mon, 08 Dec 2003 08:25:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8DP3qP022443 for entmib-archive@odin.ietf.org; Mon, 8 Dec 2003 08:25:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLNl-0005pj-AV; Mon, 08 Dec 2003 08:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLN3-0005p9-UH for entmib@optimus.ietf.org; Mon, 08 Dec 2003 08:24:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08504 for ; Mon, 8 Dec 2003 08:24:02 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLN2-0003F0-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:24:16 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ATLN2-0003Ep-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:24:16 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB8DOEv18774 for ; Mon, 8 Dec 2003 15:24:14 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 8 Dec 2003 15:24:14 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 8 Dec 2003 05:24:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Dec 2003 08:24:11 -0500 Message-ID: Thread-Topic: Confirmming Meeting Consensus Thread-Index: AcO9jpEquPVlbGf3QYC51RyjV0p76A== To: X-OriginalArrivalTime: 08 Dec 2003 13:24:13.0255 (UTC) FILETIME=[92366570:01C3BD8E] Content-Transfer-Encoding: quoted-printable Subject: [Entmib] Confirmming Meeting Consensus Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi All, During the meeting in Minneapolis, there was agreement in the room on a few points, an dI'd like to confirm that consensus on the mailing list. In particular, we reached agreement at the meeting on the following points: - We will deprecate the Alias Mapping Table so that the Entity MIB can advance to Draft Standard. =20 - Future extensions to the Entity MIB should be handled as separate MIBs that augment the Entity MIB. =20 - The Entity State MIB is currently too complex and should be simplified. Please feel free to express your opinion on any of these points on the mailing list. Thanks, Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Dec 8 08:45:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09205 for ; Mon, 8 Dec 2003 08:45:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLh8-0006lq-P9; Mon, 08 Dec 2003 08:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLgD-0006kh-3x for entmib@optimus.ietf.org; Mon, 08 Dec 2003 08:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09182 for ; Mon, 8 Dec 2003 08:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLgB-0003oN-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:44:03 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATLgB-0003nQ-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:44:03 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 2C67E7C800; Mon, 8 Dec 2003 14:43:32 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 57BB1483AD; Mon, 8 Dec 2003 14:43:31 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id F2D9981C8; Mon, 8 Dec 2003 14:43:30 +0100 (CET) Date: Mon, 8 Dec 2003 14:43:30 +0100 From: Juergen Schoenwaelder To: Margaret.Wasserman@nokia.com Cc: entmib@ietf.org Subject: Re: [Entmib] Confirmming Meeting Consensus Message-ID: <20031208134330.GA2631@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Margaret.Wasserman@nokia.com, entmib@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com wrote: > > During the meeting in Minneapolis, there was agreement > in the room on a few points, an dI'd like to confirm > that consensus on the mailing list. > > In particular, we reached agreement at the meeting on > the following points: > > - We will deprecate the Alias Mapping Table so that the Entity > MIB can advance to Draft Standard. Well, this is what it takes... > - Future extensions to the Entity MIB should be handled as > separate MIBs that augment the Entity MIB. Not sure how useful such a blanket statement is. > - The Entity State MIB is currently too complex and should be > simplified. I like to know what precisely people find too complex before subscribing to such a blanket statement. Can someone please explain (and perhaps suggest what precisely needs to be removed)? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Dec 8 08:45:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09216 for ; Mon, 8 Dec 2003 08:45:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLh9-0006mI-43 for entmib-archive@odin.ietf.org; Mon, 08 Dec 2003 08:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Dj3Yg026041 for entmib-archive@odin.ietf.org; Mon, 8 Dec 2003 08:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLh8-0006lq-P9; Mon, 08 Dec 2003 08:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLgD-0006kh-3x for entmib@optimus.ietf.org; Mon, 08 Dec 2003 08:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09182 for ; Mon, 8 Dec 2003 08:43:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLgB-0003oN-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:44:03 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATLgB-0003nQ-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:44:03 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 2C67E7C800; Mon, 8 Dec 2003 14:43:32 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 57BB1483AD; Mon, 8 Dec 2003 14:43:31 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id F2D9981C8; Mon, 8 Dec 2003 14:43:30 +0100 (CET) Date: Mon, 8 Dec 2003 14:43:30 +0100 From: Juergen Schoenwaelder To: Margaret.Wasserman@nokia.com Cc: entmib@ietf.org Subject: Re: [Entmib] Confirmming Meeting Consensus Message-ID: <20031208134330.GA2631@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Margaret.Wasserman@nokia.com, entmib@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com wrote: > > During the meeting in Minneapolis, there was agreement > in the room on a few points, an dI'd like to confirm > that consensus on the mailing list. > > In particular, we reached agreement at the meeting on > the following points: > > - We will deprecate the Alias Mapping Table so that the Entity > MIB can advance to Draft Standard. Well, this is what it takes... > - Future extensions to the Entity MIB should be handled as > separate MIBs that augment the Entity MIB. Not sure how useful such a blanket statement is. > - The Entity State MIB is currently too complex and should be > simplified. I like to know what precisely people find too complex before subscribing to such a blanket statement. Can someone please explain (and perhaps suggest what precisely needs to be removed)? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Dec 8 08:52:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09426 for ; Mon, 8 Dec 2003 08:52:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLns-0006tx-TK; Mon, 08 Dec 2003 08:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLn8-0006ta-DM for entmib@optimus.ietf.org; Mon, 08 Dec 2003 08:51:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09385 for ; Mon, 8 Dec 2003 08:50:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLn6-00040T-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:51:12 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ATLn6-00040Q-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:51:12 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB8DmOGa025081 for ; Mon, 8 Dec 2003 08:48:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB8DmJGa024888 for ; Mon, 8 Dec 2003 08:48:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Mon, 8 Dec 2003 15:51:04 +0200 Message-ID: Thread-Topic: Confirmming Meeting Consensus Thread-Index: AcO9jpEquPVlbGf3QYC51RyjV0p76AAAwUqg From: "Romascanu, Dan (Dan)" To: , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > During the meeting in Minneapolis, there was agreement > in the room on a few points, an dI'd like to confirm > that consensus on the mailing list. >=20 > In particular, we reached agreement at the meeting on > the following points: >=20 > - We will deprecate the Alias Mapping Table so that the Entity > MIB can advance to Draft Standard. > =20 > - Future extensions to the Entity MIB should be handled as > separate MIBs that augment the Entity MIB. >=20 OK with the two above. =20 > - The Entity State MIB is currently too complex and should be > simplified. As the editor of the document was absent from the meeting I suggest that = we hear her opinion. It is my impression that she is working to update = the document, based on concrete comments received before the Vienna = IETF. As far as I remember, the opinions in the meeting (including mine) = were not necessarily addressing specific aspects of the perceived = complexity, but rather mentioned the fact that the MIB design went far = away from the original one column extension of the entPhisical table. To = be useful, comments should be more specific, and address the = Internet-Draft version that is out there.=20 >=20 > Please feel free to express your opinion on any of these > points on the mailing list. >=20 > Thanks, > Margaret >=20 Regards, Dan >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Dec 8 08:52:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09429 for ; Mon, 8 Dec 2003 08:52:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLnt-0006uP-1n for entmib-archive@odin.ietf.org; Mon, 08 Dec 2003 08:52:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Dq1k5026539 for entmib-archive@odin.ietf.org; Mon, 8 Dec 2003 08:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLns-0006tx-TK; Mon, 08 Dec 2003 08:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATLn8-0006ta-DM for entmib@optimus.ietf.org; Mon, 08 Dec 2003 08:51:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09385 for ; Mon, 8 Dec 2003 08:50:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATLn6-00040T-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:51:12 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ATLn6-00040Q-00 for entmib@ietf.org; Mon, 08 Dec 2003 08:51:12 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB8DmOGa025081 for ; Mon, 8 Dec 2003 08:48:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB8DmJGa024888 for ; Mon, 8 Dec 2003 08:48:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Mon, 8 Dec 2003 15:51:04 +0200 Message-ID: Thread-Topic: Confirmming Meeting Consensus Thread-Index: AcO9jpEquPVlbGf3QYC51RyjV0p76AAAwUqg From: "Romascanu, Dan (Dan)" To: , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >=20 > During the meeting in Minneapolis, there was agreement > in the room on a few points, an dI'd like to confirm > that consensus on the mailing list. >=20 > In particular, we reached agreement at the meeting on > the following points: >=20 > - We will deprecate the Alias Mapping Table so that the Entity > MIB can advance to Draft Standard. > =20 > - Future extensions to the Entity MIB should be handled as > separate MIBs that augment the Entity MIB. >=20 OK with the two above. =20 > - The Entity State MIB is currently too complex and should be > simplified. As the editor of the document was absent from the meeting I suggest that = we hear her opinion. It is my impression that she is working to update = the document, based on concrete comments received before the Vienna = IETF. As far as I remember, the opinions in the meeting (including mine) = were not necessarily addressing specific aspects of the perceived = complexity, but rather mentioned the fact that the MIB design went far = away from the original one column extension of the entPhisical table. To = be useful, comments should be more specific, and address the = Internet-Draft version that is out there.=20 >=20 > Please feel free to express your opinion on any of these > points on the mailing list. >=20 > Thanks, > Margaret >=20 Regards, Dan >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Dec 8 09:27:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10411 for ; Mon, 8 Dec 2003 09:27:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMLl-00089A-1T; Mon, 08 Dec 2003 09:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATML3-00088D-I0 for entmib@optimus.ietf.org; Mon, 08 Dec 2003 09:26:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10379 for ; Mon, 8 Dec 2003 09:26:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATML1-0004lr-00 for entmib@ietf.org; Mon, 08 Dec 2003 09:26:15 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ATML1-0004ki-00 for entmib@ietf.org; Mon, 08 Dec 2003 09:26:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB8EPcW16700 for ; Mon, 8 Dec 2003 09:25:38 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 09:25:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409805A06@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Mon, 8 Dec 2003 09:25:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Yes, unfortunate I wasn't able to make it to the Minneapolis meeting for this discussion. I am currently working on, as Dan has indicated, processing the comments I received as a result of working group last call on the MIB and should have an update out in a few weeks. It would have been out sooner but I wanted to focus my efforts in getting the Alarm MIB progressed. The MIB is currently only 6 objects and two notifications. I believe the perceived complexity comes from the fact that some people are not yet sure how to apply some of the states to some of the physical types. I tried to solve this by adding a bunch of text to the document which I now think made the problem worse so I have proposed removing this in favour of more concise object descriptions. I don't think the plan was really ever to just add one MIB object. As a minimum you would always need administrative and operational. As per usual, we are trying to provide solutions for people with varying requirements. The people in the meeting in Minneapolis apparently felt there were too many states but many of the people I talk to feel that some of the other OSI states that we opted not to include in the MIB are useful and should be added. This of course could be solved by limiting the list of mandatory objects but providing the additional states for implementations that require this additional information. Another thing people are having some difficulty in getting their heads around is that this state model is different than that used for interfaces status. Some have called this the 'IETF State Model', but when I looked into it I didn't find it that universally deployed throughout the various IETF MIBs to call it that. It's a decent enough model, but too simplistic at times. For example, since operational state follows administrative state, I have no way to tell whether something is going to be operational when I administratively enable it other than to try it and then see if it fails. I can certainly appreciate the concern that some people have in this area, so in response to issue #77, I suggested the following two options, but have received no replies: "Hmmm. The problem is then that there are two different ways to interpret the state of the entity by reading the same values for those three objects. I'd suggest one of the following then 1) Always force people to use the states as described. Then even if the internal state model is as you described, the externally visible behaviour would be as described in section 2.2. 2) Support two behaviours for oper state and provide a type object to tell you which one is being used. These would be INTEGER { operIndependentAdmin, operFollowsAdmin (2) }. I'm not sure about this approach, but I suspect it would make some people happy." I will continue to progress the list of issues as can be seen in http://rt.psp.com and await further discussion on this within the list. Sharon _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Dec 8 09:27:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10413 for ; Mon, 8 Dec 2003 09:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMLl-00089c-Th for entmib-archive@odin.ietf.org; Mon, 08 Dec 2003 09:27:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8ER1Yq031331 for entmib-archive@odin.ietf.org; Mon, 8 Dec 2003 09:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATMLl-00089A-1T; Mon, 08 Dec 2003 09:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATML3-00088D-I0 for entmib@optimus.ietf.org; Mon, 08 Dec 2003 09:26:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10379 for ; Mon, 8 Dec 2003 09:26:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATML1-0004lr-00 for entmib@ietf.org; Mon, 08 Dec 2003 09:26:15 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1ATML1-0004ki-00 for entmib@ietf.org; Mon, 08 Dec 2003 09:26:15 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB8EPcW16700 for ; Mon, 8 Dec 2003 09:25:38 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 09:25:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409805A06@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Mon, 8 Dec 2003 09:25:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Yes, unfortunate I wasn't able to make it to the Minneapolis meeting for this discussion. I am currently working on, as Dan has indicated, processing the comments I received as a result of working group last call on the MIB and should have an update out in a few weeks. It would have been out sooner but I wanted to focus my efforts in getting the Alarm MIB progressed. The MIB is currently only 6 objects and two notifications. I believe the perceived complexity comes from the fact that some people are not yet sure how to apply some of the states to some of the physical types. I tried to solve this by adding a bunch of text to the document which I now think made the problem worse so I have proposed removing this in favour of more concise object descriptions. I don't think the plan was really ever to just add one MIB object. As a minimum you would always need administrative and operational. As per usual, we are trying to provide solutions for people with varying requirements. The people in the meeting in Minneapolis apparently felt there were too many states but many of the people I talk to feel that some of the other OSI states that we opted not to include in the MIB are useful and should be added. This of course could be solved by limiting the list of mandatory objects but providing the additional states for implementations that require this additional information. Another thing people are having some difficulty in getting their heads around is that this state model is different than that used for interfaces status. Some have called this the 'IETF State Model', but when I looked into it I didn't find it that universally deployed throughout the various IETF MIBs to call it that. It's a decent enough model, but too simplistic at times. For example, since operational state follows administrative state, I have no way to tell whether something is going to be operational when I administratively enable it other than to try it and then see if it fails. I can certainly appreciate the concern that some people have in this area, so in response to issue #77, I suggested the following two options, but have received no replies: "Hmmm. The problem is then that there are two different ways to interpret the state of the entity by reading the same values for those three objects. I'd suggest one of the following then 1) Always force people to use the states as described. Then even if the internal state model is as you described, the externally visible behaviour would be as described in section 2.2. 2) Support two behaviours for oper state and provide a type object to tell you which one is being used. These would be INTEGER { operIndependentAdmin, operFollowsAdmin (2) }. I'm not sure about this approach, but I suspect it would make some people happy." I will continue to progress the list of issues as can be seen in http://rt.psp.com and await further discussion on this within the list. Sharon _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Mon Dec 8 17:38:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08046 for ; Mon, 8 Dec 2003 17:38:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATU0u-0000rJ-RW; Mon, 08 Dec 2003 17:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATU01-0000fn-QN for entmib@optimus.ietf.org; Mon, 08 Dec 2003 17:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08022 for ; Mon, 8 Dec 2003 17:36:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTzz-0007ld-00 for entmib@ietf.org; Mon, 08 Dec 2003 17:37:03 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ATTzy-0007ke-00 for entmib@ietf.org; Mon, 08 Dec 2003 17:37:02 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2003 14:38:21 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB8MaUBN020169; Mon, 8 Dec 2003 14:36:30 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA20073; Mon, 8 Dec 2003 14:36:29 -0800 (PST) From: Keith McCloghrie Message-Id: <200312082236.OAA20073@cisco.com> Subject: Re: [Entmib] Confirmming Meeting Consensus To: j.schoenwaelder@iu-bremen.de Date: Mon, 8 Dec 2003 14:36:29 -0800 (PST) Cc: Margaret.Wasserman@nokia.com, entmib@ietf.org In-Reply-To: <20031208134330.GA2631@iu-bremen.de> from "Juergen Schoenwaelder" at Dec 08, 2003 02:43:30 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > - We will deprecate the Alias Mapping Table so that the Entity > > MIB can advance to Draft Standard. > > Well, this is what it takes... It would be better to deprecate only the entity2Compliance statement, and leave the objects and group with "current" status. Specifically, create a new entity3Compliance which is the same as entity2Compliance except for having the "GROUP entityMappingGroup" removed. This would make implementation of the Alias Mapping Table the equivalent of a "MAY". There are many other RFCs which are at DRAFT STANDARD Status which contain MAYs. I find it very difficult to believe that a check was made that all of their MAYs were implemented before they were permitted to become DRAFT. For example, to take a recent example, "MAY" appears more than 80 times in RFC 3550; was it checked that every one of those 80 has been implemented ?? Keith. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Mon Dec 8 17:38:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08062 for ; Mon, 8 Dec 2003 17:38:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATU0v-0000rp-PU for entmib-archive@odin.ietf.org; Mon, 08 Dec 2003 17:38:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Mc1Ki003320 for entmib-archive@odin.ietf.org; Mon, 8 Dec 2003 17:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATU0u-0000rJ-RW; Mon, 08 Dec 2003 17:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATU01-0000fn-QN for entmib@optimus.ietf.org; Mon, 08 Dec 2003 17:37:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08022 for ; Mon, 8 Dec 2003 17:36:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATTzz-0007ld-00 for entmib@ietf.org; Mon, 08 Dec 2003 17:37:03 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ATTzy-0007ke-00 for entmib@ietf.org; Mon, 08 Dec 2003 17:37:02 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Dec 2003 14:38:21 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB8MaUBN020169; Mon, 8 Dec 2003 14:36:30 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA20073; Mon, 8 Dec 2003 14:36:29 -0800 (PST) From: Keith McCloghrie Message-Id: <200312082236.OAA20073@cisco.com> Subject: Re: [Entmib] Confirmming Meeting Consensus To: j.schoenwaelder@iu-bremen.de Date: Mon, 8 Dec 2003 14:36:29 -0800 (PST) Cc: Margaret.Wasserman@nokia.com, entmib@ietf.org In-Reply-To: <20031208134330.GA2631@iu-bremen.de> from "Juergen Schoenwaelder" at Dec 08, 2003 02:43:30 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > - We will deprecate the Alias Mapping Table so that the Entity > > MIB can advance to Draft Standard. > > Well, this is what it takes... It would be better to deprecate only the entity2Compliance statement, and leave the objects and group with "current" status. Specifically, create a new entity3Compliance which is the same as entity2Compliance except for having the "GROUP entityMappingGroup" removed. This would make implementation of the Alias Mapping Table the equivalent of a "MAY". There are many other RFCs which are at DRAFT STANDARD Status which contain MAYs. I find it very difficult to believe that a check was made that all of their MAYs were implemented before they were permitted to become DRAFT. For example, to take a recent example, "MAY" appears more than 80 times in RFC 3550; was it checked that every one of those 80 has been implemented ?? Keith. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Dec 9 04:17:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19088 for ; Tue, 9 Dec 2003 04:17:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdzJ-0004sL-Q6; Tue, 09 Dec 2003 04:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdyO-0004om-VQ for entmib@optimus.ietf.org; Tue, 09 Dec 2003 04:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19053 for ; Tue, 9 Dec 2003 04:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATdyM-0004FS-00 for entmib@ietf.org; Tue, 09 Dec 2003 04:16:02 -0500 Received: from sea2-dav30.sea2.hotmail.com ([207.68.164.87] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ATdyL-0004F6-00 for entmib@ietf.org; Tue, 09 Dec 2003 04:16:01 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Dec 2003 01:15:32 -0800 Received: from 210.118.108.254 by sea2-dav30.sea2.hotmail.com with DAV; Tue, 09 Dec 2003 09:15:32 +0000 X-Originating-IP: [210.118.108.254] X-Originating-Email: [madanapalli@hotmail.com] X-Sender: madanapalli@hotmail.com From: "Syam Madanapalli" To: References: <20031208134330.GA2631@iu-bremen.de> Subject: Re: [Entmib] Confirmming Meeting Consensus Date: Tue, 9 Dec 2003 14:44:10 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 09 Dec 2003 09:15:32.0561 (UTC) FILETIME=[FF32EC10:01C3BE34] Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am wondering if the following draft brings any interest for the Entity State MIB. State Model for IPv6 Interfaces http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt But this state model is only for IPv6 Interfaces whereas Entity State MIB covers every thing. Thank you, Syam ----- Original Message ----- From: "Juergen Schoenwaelder" To: Cc: Sent: Monday, December 08, 2003 7:13 PM Subject: Re: [Entmib] Confirmming Meeting Consensus > On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com wrote: > > > > During the meeting in Minneapolis, there was agreement > > in the room on a few points, an dI'd like to confirm > > that consensus on the mailing list. > > > > In particular, we reached agreement at the meeting on > > the following points: > > > > - We will deprecate the Alias Mapping Table so that the Entity > > MIB can advance to Draft Standard. > > Well, this is what it takes... > > > - Future extensions to the Entity MIB should be handled as > > separate MIBs that augment the Entity MIB. > > Not sure how useful such a blanket statement is. > > > - The Entity State MIB is currently too complex and should be > > simplified. > > I like to know what precisely people find too complex before subscribing > to such a blanket statement. Can someone please explain (and perhaps > suggest what precisely needs to be removed)? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Dec 9 05:05:55 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19089 for ; Tue, 9 Dec 2003 04:17:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdzN-0004sn-3f for entmib-archive@odin.ietf.org; Tue, 09 Dec 2003 04:17:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB99H476018755 for entmib-archive@odin.ietf.org; Tue, 9 Dec 2003 04:17:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdzJ-0004sL-Q6; Tue, 09 Dec 2003 04:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATdyO-0004om-VQ for entmib@optimus.ietf.org; Tue, 09 Dec 2003 04:16:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19053 for ; Tue, 9 Dec 2003 04:15:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATdyM-0004FS-00 for entmib@ietf.org; Tue, 09 Dec 2003 04:16:02 -0500 Received: from sea2-dav30.sea2.hotmail.com ([207.68.164.87] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ATdyL-0004F6-00 for entmib@ietf.org; Tue, 09 Dec 2003 04:16:01 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Dec 2003 01:15:32 -0800 Received: from 210.118.108.254 by sea2-dav30.sea2.hotmail.com with DAV; Tue, 09 Dec 2003 09:15:32 +0000 X-Originating-IP: [210.118.108.254] X-Originating-Email: [madanapalli@hotmail.com] X-Sender: madanapalli@hotmail.com From: "Syam Madanapalli" To: References: <20031208134330.GA2631@iu-bremen.de> Subject: Re: [Entmib] Confirmming Meeting Consensus Date: Tue, 9 Dec 2003 14:44:10 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 09 Dec 2003 09:15:32.0561 (UTC) FILETIME=[FF32EC10:01C3BE34] Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I am wondering if the following draft brings any interest for the Entity State MIB. State Model for IPv6 Interfaces http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt But this state model is only for IPv6 Interfaces whereas Entity State MIB covers every thing. Thank you, Syam ----- Original Message ----- From: "Juergen Schoenwaelder" To: Cc: Sent: Monday, December 08, 2003 7:13 PM Subject: Re: [Entmib] Confirmming Meeting Consensus > On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com wrote: > > > > During the meeting in Minneapolis, there was agreement > > in the room on a few points, an dI'd like to confirm > > that consensus on the mailing list. > > > > In particular, we reached agreement at the meeting on > > the following points: > > > > - We will deprecate the Alias Mapping Table so that the Entity > > MIB can advance to Draft Standard. > > Well, this is what it takes... > > > - Future extensions to the Entity MIB should be handled as > > separate MIBs that augment the Entity MIB. > > Not sure how useful such a blanket statement is. > > > - The Entity State MIB is currently too complex and should be > > simplified. > > I like to know what precisely people find too complex before subscribing > to such a blanket statement. Can someone please explain (and perhaps > suggest what precisely needs to be removed)? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Dec 9 05:10:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20405 for ; Tue, 9 Dec 2003 05:10:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeoc-00076l-DA; Tue, 09 Dec 2003 05:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeoV-00076O-Ad for entmib@optimus.ietf.org; Tue, 09 Dec 2003 05:09:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20385 for ; Tue, 9 Dec 2003 05:09:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATeoR-0004nE-00 for entmib@ietf.org; Tue, 09 Dec 2003 05:09:51 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATeoR-0004ms-00 for entmib@ietf.org; Tue, 09 Dec 2003 05:09:51 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 23F5A81E1B; Tue, 9 Dec 2003 11:08:54 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.46.146]) by merkur.iu-bremen.de (Postfix) with ESMTP id 7B28081E11; Tue, 9 Dec 2003 11:08:53 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id B587A81C8; Tue, 9 Dec 2003 11:08:52 +0100 (CET) Date: Tue, 9 Dec 2003 11:08:52 +0100 From: Juergen Schoenwaelder To: entmib@ietf.org Subject: Re: [Entmib] Confirmming Meeting Consensus Message-ID: <20031209100852.GA758@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: entmib@ietf.org References: <20031208134330.GA2631@iu-bremen.de> <200312082236.OAA20073@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312082236.OAA20073@cisco.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Mon, Dec 08, 2003 at 02:36:29PM -0800, Keith McCloghrie wrote: > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > It would be better to deprecate only the entity2Compliance statement, > and leave the objects and group with "current" status. Specifically, > create a new entity3Compliance which is the same as entity2Compliance > except for having the "GROUP entityMappingGroup" removed. This would > make implementation of the Alias Mapping Table the equivalent of a > "MAY". Interesting proposal. Anyway, how many implementation reports did we get for these objects? None or just one and we need two? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Dec 9 05:10:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20422 for ; Tue, 9 Dec 2003 05:10:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeog-00077Y-8R for entmib-archive@odin.ietf.org; Tue, 09 Dec 2003 05:10:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9AA5xW027339 for entmib-archive@odin.ietf.org; Tue, 9 Dec 2003 05:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeoc-00076l-DA; Tue, 09 Dec 2003 05:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATeoV-00076O-Ad for entmib@optimus.ietf.org; Tue, 09 Dec 2003 05:09:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20385 for ; Tue, 9 Dec 2003 05:09:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATeoR-0004nE-00 for entmib@ietf.org; Tue, 09 Dec 2003 05:09:51 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1ATeoR-0004ms-00 for entmib@ietf.org; Tue, 09 Dec 2003 05:09:51 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 23F5A81E1B; Tue, 9 Dec 2003 11:08:54 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.46.146]) by merkur.iu-bremen.de (Postfix) with ESMTP id 7B28081E11; Tue, 9 Dec 2003 11:08:53 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id B587A81C8; Tue, 9 Dec 2003 11:08:52 +0100 (CET) Date: Tue, 9 Dec 2003 11:08:52 +0100 From: Juergen Schoenwaelder To: entmib@ietf.org Subject: Re: [Entmib] Confirmming Meeting Consensus Message-ID: <20031209100852.GA758@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: entmib@ietf.org References: <20031208134330.GA2631@iu-bremen.de> <200312082236.OAA20073@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312082236.OAA20073@cisco.com> User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , On Mon, Dec 08, 2003 at 02:36:29PM -0800, Keith McCloghrie wrote: > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > It would be better to deprecate only the entity2Compliance statement, > and leave the objects and group with "current" status. Specifically, > create a new entity3Compliance which is the same as entity2Compliance > except for having the "GROUP entityMappingGroup" removed. This would > make implementation of the Alias Mapping Table the equivalent of a > "MAY". Interesting proposal. Anyway, how many implementation reports did we get for these objects? None or just one and we need two? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Dec 9 08:08:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24715 for ; Tue, 9 Dec 2003 08:08:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AThar-0004Yr-5B; Tue, 09 Dec 2003 08:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATha4-0004Ll-6u for entmib@optimus.ietf.org; Tue, 09 Dec 2003 08:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24685 for ; Tue, 9 Dec 2003 08:06:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATha3-0006td-00 for entmib@ietf.org; Tue, 09 Dec 2003 08:07:11 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ATha2-0006tZ-00 for entmib@ietf.org; Tue, 09 Dec 2003 08:07:10 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB9D6VFo029196 for ; Tue, 9 Dec 2003 08:06:31 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB9D6TFo029175 for ; Tue, 9 Dec 2003 08:06:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Tue, 9 Dec 2003 15:07:07 +0200 Message-ID: Thread-Topic: [Entmib] Confirmming Meeting Consensus Thread-Index: AcO+NUH9R8p/gXTOSWynup8t0sa3swAH9FHw From: "Romascanu, Dan (Dan)" To: "Syam Madanapalli" , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Syam, Can you clarify what is IPv6-specific in the state model proposed by the = Internet-Draft that you are referring to? Thanks and Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Syam Madanapalli > Sent: 09 December, 2003 11:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > I am wondering if the following draft brings any interest > for the Entity State MIB. >=20 > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt >=20 > But this state model is only for IPv6 Interfaces whereas=20 > Entity State MIB > covers every thing. >=20 > Thank you, > Syam >=20 >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > > On Mon, Dec 08, 2003 at 08:24:11AM -0500,=20 > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex=20 > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Dec 9 08:08:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24730 for ; Tue, 9 Dec 2003 08:08:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AThas-0004ZW-Ck for entmib-archive@odin.ietf.org; Tue, 09 Dec 2003 08:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9D82Yv017566 for entmib-archive@odin.ietf.org; Tue, 9 Dec 2003 08:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AThar-0004Yr-5B; Tue, 09 Dec 2003 08:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATha4-0004Ll-6u for entmib@optimus.ietf.org; Tue, 09 Dec 2003 08:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24685 for ; Tue, 9 Dec 2003 08:06:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATha3-0006td-00 for entmib@ietf.org; Tue, 09 Dec 2003 08:07:11 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ATha2-0006tZ-00 for entmib@ietf.org; Tue, 09 Dec 2003 08:07:10 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB9D6VFo029196 for ; Tue, 9 Dec 2003 08:06:31 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hB9D6TFo029175 for ; Tue, 9 Dec 2003 08:06:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Tue, 9 Dec 2003 15:07:07 +0200 Message-ID: Thread-Topic: [Entmib] Confirmming Meeting Consensus Thread-Index: AcO+NUH9R8p/gXTOSWynup8t0sa3swAH9FHw From: "Romascanu, Dan (Dan)" To: "Syam Madanapalli" , Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Syam, Can you clarify what is IPv6-specific in the state model proposed by the = Internet-Draft that you are referring to? Thanks and Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On=20 > Behalf Of Syam Madanapalli > Sent: 09 December, 2003 11:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > I am wondering if the following draft brings any interest > for the Entity State MIB. >=20 > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt >=20 > But this state model is only for IPv6 Interfaces whereas=20 > Entity State MIB > covers every thing. >=20 > Thank you, > Syam >=20 >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > > On Mon, Dec 08, 2003 at 08:24:11AM -0500,=20 > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex=20 > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Dec 9 11:24:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02294 for ; Tue, 9 Dec 2003 11:24:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkeY-00044h-EK; Tue, 09 Dec 2003 11:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkeC-000443-T1 for entmib@optimus.ietf.org; Tue, 09 Dec 2003 11:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02243 for ; Tue, 9 Dec 2003 11:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkeB-0002Ts-00 for entmib@ietf.org; Tue, 09 Dec 2003 11:23:39 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkeB-0002TP-00 for entmib@ietf.org; Tue, 09 Dec 2003 11:23:39 -0500 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id hB9GNXi01557; Tue, 9 Dec 2003 08:23:33 -0800 Date: Tue, 9 Dec 2003 08:23:32 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Syam Madanapalli cc: entmib@ietf.org Subject: Re: [Entmib] A state model.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , HI, I find the document specified below troubling. The many reasons inlcude: 1) there is already a well known state model for interfaces, which is specified in the IF MIB module. a) The document does not specify why the IF state model should be replaced (or augmented) with another model. b) The document does not compare it's states and transitions those from the IF state model 2) the state model in the document is primarily based on that found in X.731, but is not the same. a) the connection between the two models needs to be explained. b) the terminology used is that from the "TELCO" industry sector and not from the Internet DATACOM industry sector 3) The state model doesn't support redundancy (and thus, is not sufficiently general to be used for physical (and logical) components that support redundancy) 4) In many components, it can not be determined if the component is "operational", when it is administratively disabled. Finally, it was sort of strange that the security section specified a reference to SNMPv1 when the document is a model and does not contain SNMP object nor notification definitions. On Tue, 9 Dec 2003, Syam Madanapalli wrote: > I am wondering if the following draft brings any interest > for the Entity State MIB. > > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > But this state model is only for IPv6 Interfaces whereas Entity State MIB > covers every thing. > > Thank you, > Syam > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Dec 9 11:24:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02297 for ; Tue, 9 Dec 2003 11:24:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkeY-00044w-L9 for entmib-archive@odin.ietf.org; Tue, 09 Dec 2003 11:24:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9GO2TZ015674 for entmib-archive@odin.ietf.org; Tue, 9 Dec 2003 11:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkeY-00044h-EK; Tue, 09 Dec 2003 11:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATkeC-000443-T1 for entmib@optimus.ietf.org; Tue, 09 Dec 2003 11:23:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02243 for ; Tue, 9 Dec 2003 11:23:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkeB-0002Ts-00 for entmib@ietf.org; Tue, 09 Dec 2003 11:23:39 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATkeB-0002TP-00 for entmib@ietf.org; Tue, 09 Dec 2003 11:23:39 -0500 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id hB9GNXi01557; Tue, 9 Dec 2003 08:23:33 -0800 Date: Tue, 9 Dec 2003 08:23:32 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Syam Madanapalli cc: entmib@ietf.org Subject: Re: [Entmib] A state model.... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , HI, I find the document specified below troubling. The many reasons inlcude: 1) there is already a well known state model for interfaces, which is specified in the IF MIB module. a) The document does not specify why the IF state model should be replaced (or augmented) with another model. b) The document does not compare it's states and transitions those from the IF state model 2) the state model in the document is primarily based on that found in X.731, but is not the same. a) the connection between the two models needs to be explained. b) the terminology used is that from the "TELCO" industry sector and not from the Internet DATACOM industry sector 3) The state model doesn't support redundancy (and thus, is not sufficiently general to be used for physical (and logical) components that support redundancy) 4) In many components, it can not be determined if the component is "operational", when it is administratively disabled. Finally, it was sort of strange that the security section specified a reference to SNMPv1 when the document is a model and does not contain SNMP object nor notification definitions. On Tue, 9 Dec 2003, Syam Madanapalli wrote: > I am wondering if the following draft brings any interest > for the Entity State MIB. > > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > But this state model is only for IPv6 Interfaces whereas Entity State MIB > covers every thing. > > Thank you, > Syam > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 10 00:45:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03194 for ; Wed, 10 Dec 2003 00:45:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATx9h-00028l-Ow; Wed, 10 Dec 2003 00:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATx8r-00027y-7O for entmib@optimus.ietf.org; Wed, 10 Dec 2003 00:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03170 for ; Wed, 10 Dec 2003 00:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATx8o-0003JH-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:44:06 -0500 Received: from sea2-dav16.sea2.hotmail.com ([207.68.164.120] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ATx8n-0003IU-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:44:06 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Dec 2003 21:43:36 -0800 Received: from 210.118.108.254 by sea2-dav16.sea2.hotmail.com with DAV; Wed, 10 Dec 2003 05:43:36 +0000 X-Originating-IP: [210.118.108.254] X-Originating-Email: [madanapalli@hotmail.com] X-Sender: madanapalli@hotmail.com From: "Syam Madanapalli" To: "Romascanu, Dan \(Dan\)" , References: Subject: Re: [Entmib] Confirmming Meeting Consensus Date: Wed, 10 Dec 2003 11:12:05 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 10 Dec 2003 05:43:36.0781 (UTC) FILETIME=[8E6A9FD0:01C3BEE0] Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The state qualifiers are IPv6 specific. However this model can be used for other enitities with different qualifiers. Thank you, Syam Syam, Can you clarify what is IPv6-specific in the state model proposed by the Internet-Draft that you are referring to? Thanks and Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On > Behalf Of Syam Madanapalli > Sent: 09 December, 2003 11:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > I am wondering if the following draft brings any interest > for the Entity State MIB. > > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > But this state model is only for IPv6 Interfaces whereas > Entity State MIB > covers every thing. > > Thank you, > Syam > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 10 00:45:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03204 for ; Wed, 10 Dec 2003 00:45:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATx9j-00029O-0d for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 00:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA5j2ZR008248 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 00:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATx9h-00028l-Ow; Wed, 10 Dec 2003 00:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATx8r-00027y-7O for entmib@optimus.ietf.org; Wed, 10 Dec 2003 00:44:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03170 for ; Wed, 10 Dec 2003 00:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATx8o-0003JH-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:44:06 -0500 Received: from sea2-dav16.sea2.hotmail.com ([207.68.164.120] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ATx8n-0003IU-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:44:06 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Dec 2003 21:43:36 -0800 Received: from 210.118.108.254 by sea2-dav16.sea2.hotmail.com with DAV; Wed, 10 Dec 2003 05:43:36 +0000 X-Originating-IP: [210.118.108.254] X-Originating-Email: [madanapalli@hotmail.com] X-Sender: madanapalli@hotmail.com From: "Syam Madanapalli" To: "Romascanu, Dan \(Dan\)" , References: Subject: Re: [Entmib] Confirmming Meeting Consensus Date: Wed, 10 Dec 2003 11:12:05 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 10 Dec 2003 05:43:36.0781 (UTC) FILETIME=[8E6A9FD0:01C3BEE0] Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The state qualifiers are IPv6 specific. However this model can be used for other enitities with different qualifiers. Thank you, Syam Syam, Can you clarify what is IPv6-specific in the state model proposed by the Internet-Draft that you are referring to? Thanks and Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On > Behalf Of Syam Madanapalli > Sent: 09 December, 2003 11:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > I am wondering if the following draft brings any interest > for the Entity State MIB. > > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > But this state model is only for IPv6 Interfaces whereas > Entity State MIB > covers every thing. > > Thank you, > Syam > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 10 01:00:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03490 for ; Wed, 10 Dec 2003 01:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATxOF-0002Tl-4q; Wed, 10 Dec 2003 01:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATxNl-0002Sx-Q0 for entmib@optimus.ietf.org; Wed, 10 Dec 2003 00:59:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03432 for ; Wed, 10 Dec 2003 00:59:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATxNi-0003dU-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:59:31 -0500 Received: from sea2-dav19.sea2.hotmail.com ([207.68.164.123] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ATxNi-0003ce-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:59:30 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Dec 2003 21:59:00 -0800 Received: from 210.118.108.254 by sea2-dav19.sea2.hotmail.com with DAV; Wed, 10 Dec 2003 05:58:59 +0000 X-Originating-IP: [210.118.108.254] X-Originating-Email: [madanapalli@hotmail.com] X-Sender: madanapalli@hotmail.com From: "Syam Madanapalli" To: "David T. Perkins" Cc: References: Subject: Re: [Entmib] A state model.... Date: Wed, 10 Dec 2003 11:27:36 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 10 Dec 2003 05:59:00.0088 (UTC) FILETIME=[B4C01780:01C3BEE2] Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > HI, > > I find the document specified below troubling. > The many reasons inlcude: > 1) there is already a well known state model for interfaces, > which is specified in the IF MIB module. > a) The document does not specify why the IF state model > should be replaced (or augmented) with another model. IF state model does not provide the flexibility in defining the states. When ifOperStatus is down, we do not why it is down. For example in IPv6, the DAD may fail, there is no way to specify this in the state info. > b) The document does not compare it's states and > transitions those from the IF state model Yep, this document is definitely not complete. The reason behind in publishing the draft in this form is to see if this approach is useful for defining the states. After confirming the usefulness we can complete the draft. > 2) the state model in the document is primarily based > on that found in X.731, but is not the same. True > a) the connection between the two models needs > to be explained. > b) the terminology used is that from the "TELCO" industry > sector and not from the Internet DATACOM industry sector True. But if the concept of State representation is useful we can define this with Datacom terminology. > 3) The state model doesn't support redundancy (and thus, is > not sufficiently general to be used for physical > (and logical) components that support redundancy) The current draft does not support this. > 4) In many components, it can not be determined if the > component is "operational", when it is administratively > disabled. What if an entity is Operational and it is locked by the administrator? > > Finally, it was sort of strange that the security section specified > a reference to SNMPv1 when the document is a model and does not > contain SNMP object nor notification definitions. As I mentioned earlier the draft is not complete by itself. This can be done if the approach is useful. > > On Tue, 9 Dec 2003, Syam Madanapalli wrote: > > I am wondering if the following draft brings any interest > > for the Entity State MIB. > > > > State Model for IPv6 Interfaces > > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > > > But this state model is only for IPv6 Interfaces whereas Entity State MIB > > covers every thing. > > > > Thank you, > > Syam > > > > > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: > > Cc: > > Sent: Monday, December 08, 2003 7:13 PM > > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com > > wrote: > > > > > > > > During the meeting in Minneapolis, there was agreement > > > > in the room on a few points, an dI'd like to confirm > > > > that consensus on the mailing list. > > > > > > > > In particular, we reached agreement at the meeting on > > > > the following points: > > > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > > MIB can advance to Draft Standard. > > > > > > Well, this is what it takes... > > > > > > > - Future extensions to the Entity MIB should be handled as > > > > separate MIBs that augment the Entity MIB. > > > > > > Not sure how useful such a blanket statement is. > > > > > > > - The Entity State MIB is currently too complex and should be > > > > simplified. > > > > > > I like to know what precisely people find too complex before subscribing > > > to such a blanket statement. Can someone please explain (and perhaps > > > suggest what precisely needs to be removed)? > > > > > > /js > > > > > > -- > regards, > /david t. perkins > > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 10 01:46:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03492 for ; Wed, 10 Dec 2003 01:00:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATxOH-0002Um-51 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 01:00:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA6043T009579 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 01:00:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATxOF-0002Tl-4q; Wed, 10 Dec 2003 01:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATxNl-0002Sx-Q0 for entmib@optimus.ietf.org; Wed, 10 Dec 2003 00:59:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03432 for ; Wed, 10 Dec 2003 00:59:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATxNi-0003dU-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:59:31 -0500 Received: from sea2-dav19.sea2.hotmail.com ([207.68.164.123] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1ATxNi-0003ce-00 for entmib@ietf.org; Wed, 10 Dec 2003 00:59:30 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 9 Dec 2003 21:59:00 -0800 Received: from 210.118.108.254 by sea2-dav19.sea2.hotmail.com with DAV; Wed, 10 Dec 2003 05:58:59 +0000 X-Originating-IP: [210.118.108.254] X-Originating-Email: [madanapalli@hotmail.com] X-Sender: madanapalli@hotmail.com From: "Syam Madanapalli" To: "David T. Perkins" Cc: References: Subject: Re: [Entmib] A state model.... Date: Wed, 10 Dec 2003 11:27:36 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 10 Dec 2003 05:59:00.0088 (UTC) FILETIME=[B4C01780:01C3BEE2] Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > HI, > > I find the document specified below troubling. > The many reasons inlcude: > 1) there is already a well known state model for interfaces, > which is specified in the IF MIB module. > a) The document does not specify why the IF state model > should be replaced (or augmented) with another model. IF state model does not provide the flexibility in defining the states. When ifOperStatus is down, we do not why it is down. For example in IPv6, the DAD may fail, there is no way to specify this in the state info. > b) The document does not compare it's states and > transitions those from the IF state model Yep, this document is definitely not complete. The reason behind in publishing the draft in this form is to see if this approach is useful for defining the states. After confirming the usefulness we can complete the draft. > 2) the state model in the document is primarily based > on that found in X.731, but is not the same. True > a) the connection between the two models needs > to be explained. > b) the terminology used is that from the "TELCO" industry > sector and not from the Internet DATACOM industry sector True. But if the concept of State representation is useful we can define this with Datacom terminology. > 3) The state model doesn't support redundancy (and thus, is > not sufficiently general to be used for physical > (and logical) components that support redundancy) The current draft does not support this. > 4) In many components, it can not be determined if the > component is "operational", when it is administratively > disabled. What if an entity is Operational and it is locked by the administrator? > > Finally, it was sort of strange that the security section specified > a reference to SNMPv1 when the document is a model and does not > contain SNMP object nor notification definitions. As I mentioned earlier the draft is not complete by itself. This can be done if the approach is useful. > > On Tue, 9 Dec 2003, Syam Madanapalli wrote: > > I am wondering if the following draft brings any interest > > for the Entity State MIB. > > > > State Model for IPv6 Interfaces > > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > > > But this state model is only for IPv6 Interfaces whereas Entity State MIB > > covers every thing. > > > > Thank you, > > Syam > > > > > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: > > Cc: > > Sent: Monday, December 08, 2003 7:13 PM > > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, Margaret.Wasserman@nokia.com > > wrote: > > > > > > > > During the meeting in Minneapolis, there was agreement > > > > in the room on a few points, an dI'd like to confirm > > > > that consensus on the mailing list. > > > > > > > > In particular, we reached agreement at the meeting on > > > > the following points: > > > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > > MIB can advance to Draft Standard. > > > > > > Well, this is what it takes... > > > > > > > - Future extensions to the Entity MIB should be handled as > > > > separate MIBs that augment the Entity MIB. > > > > > > Not sure how useful such a blanket statement is. > > > > > > > - The Entity State MIB is currently too complex and should be > > > > simplified. > > > > > > I like to know what precisely people find too complex before subscribing > > > to such a blanket statement. Can someone please explain (and perhaps > > > suggest what precisely needs to be removed)? > > > > > > /js > > > > > > -- > regards, > /david t. perkins > > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 10 02:05:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10045 for ; Wed, 10 Dec 2003 02:05:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATyP9-0004HJ-Fz for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 02:05:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA753e5016432 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 02:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATyP6-0004Gr-Uz; Wed, 10 Dec 2003 02:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATyP2-0004GT-W1 for entmib@optimus.ietf.org; Wed, 10 Dec 2003 02:04:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09401 for ; Wed, 10 Dec 2003 02:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATyOz-0004Ov-00 for entmib@ietf.org; Wed, 10 Dec 2003 02:04:53 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ATyOy-0004Or-00 for entmib@ietf.org; Wed, 10 Dec 2003 02:04:52 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBA721Ga005735 for ; Wed, 10 Dec 2003 02:02:01 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBA71wGa005717 for ; Wed, 10 Dec 2003 02:01:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] A state model.... Date: Wed, 10 Dec 2003 09:04:46 +0200 Message-ID: Thread-Topic: [Entmib] A state model.... Thread-Index: AcO+4t+U92LJKMnyRtOA+Qlrrx4hxgACAwTA From: "Romascanu, Dan (Dan)" To: "Syam Madanapalli" , "David T. Perkins" Cc: Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Syam, >=20 > > > > Finally, it was sort of strange that the security section specified > > a reference to SNMPv1 when the document is a model and does not > > contain SNMP object nor notification definitions. >=20 > As I mentioned earlier the draft is not complete by itself.=20 > This can be done > if the approach is useful. I think that the point that David is raising is why bother to include an = SNMP-related text in the security section, while the draft does not = contain any SNMP MIB objects definition.=20 However, this is a minor editorial issue, relative to the modeling = problems raised by David. I share his concern that this draft goes into = a divergent direction relative to the existing interface state model = defined by the Interfaces MIB. I am wondering whether you have looked at = that model and considered adding the eventual missing pieces, instead of = creating an alternate one.=20 Regards, Dan _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 10 02:05:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10031 for ; Wed, 10 Dec 2003 02:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATyP6-0004Gr-Uz; Wed, 10 Dec 2003 02:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATyP2-0004GT-W1 for entmib@optimus.ietf.org; Wed, 10 Dec 2003 02:04:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09401 for ; Wed, 10 Dec 2003 02:04:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATyOz-0004Ov-00 for entmib@ietf.org; Wed, 10 Dec 2003 02:04:53 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1ATyOy-0004Or-00 for entmib@ietf.org; Wed, 10 Dec 2003 02:04:52 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBA721Ga005735 for ; Wed, 10 Dec 2003 02:02:01 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id hBA71wGa005717 for ; Wed, 10 Dec 2003 02:01:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] A state model.... Date: Wed, 10 Dec 2003 09:04:46 +0200 Message-ID: Thread-Topic: [Entmib] A state model.... Thread-Index: AcO+4t+U92LJKMnyRtOA+Qlrrx4hxgACAwTA From: "Romascanu, Dan (Dan)" To: "Syam Madanapalli" , "David T. Perkins" Cc: Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Syam, >=20 > > > > Finally, it was sort of strange that the security section specified > > a reference to SNMPv1 when the document is a model and does not > > contain SNMP object nor notification definitions. >=20 > As I mentioned earlier the draft is not complete by itself.=20 > This can be done > if the approach is useful. I think that the point that David is raising is why bother to include an = SNMP-related text in the security section, while the draft does not = contain any SNMP MIB objects definition.=20 However, this is a minor editorial issue, relative to the modeling = problems raised by David. I share his concern that this draft goes into = a divergent direction relative to the existing interface state model = defined by the Interfaces MIB. I am wondering whether you have looked at = that model and considered adding the eventual missing pieces, instead of = creating an alternate one.=20 Regards, Dan _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 10 08:45:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11670 for ; Wed, 10 Dec 2003 08:45:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU4eI-0002sg-LT for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 08:45:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBADj6Cg011067 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 08:45:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU4eD-0002s4-Qa; Wed, 10 Dec 2003 08:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU4dK-0002rT-AQ for entmib@optimus.ietf.org; Wed, 10 Dec 2003 08:44:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11646 for ; Wed, 10 Dec 2003 08:44:03 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU4dI-0002Br-00 for entmib@ietf.org; Wed, 10 Dec 2003 08:44:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AU4dI-0002Bn-00 for entmib@ietf.org; Wed, 10 Dec 2003 08:44:04 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBADi3Q16692 for ; Wed, 10 Dec 2003 15:44:03 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 15:44:02 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 05:44:01 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Wed, 10 Dec 2003 08:44:00 -0500 Message-ID: Thread-Topic: [Entmib] Confirmming Meeting Consensus Thread-Index: AcO+NUTpzYfaIIICRhi+fDF770INAgA7F2oA To: , X-OriginalArrivalTime: 10 Dec 2003 13:44:01.0716 (UTC) FILETIME=[AB6AA740:01C3BF23] Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Syam, I am sorry, but defining a state model for IPv6 interfaces is not within the charter of the Entity MIB WG. We are working on state/status only as it applies to augmenting the Entity MIB with a "health indicator" regarding the status of each defined entity. As Dave Perkins pointed out, there is already a state model=20 for IP interfaces defined in the IF MIB. If you believe that we should update that model, I would suggest that you discuss your ideas on the IETF MIBs list (mibs@ops.ietf.org), and see if there is sufficient community interest to pursue this work. Margaret > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > ext Syam Madanapalli > Sent: Tuesday, December 09, 2003 4:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > I am wondering if the following draft brings any interest > for the Entity State MIB. >=20 > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt >=20 > But this state model is only for IPv6 Interfaces whereas=20 > Entity State MIB > covers every thing. >=20 > Thank you, > Syam >=20 >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > > On Mon, Dec 08, 2003 at 08:24:11AM -0500,=20 > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex=20 > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 10 09:31:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11668 for ; Wed, 10 Dec 2003 08:45:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU4eD-0002s4-Qa; Wed, 10 Dec 2003 08:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU4dK-0002rT-AQ for entmib@optimus.ietf.org; Wed, 10 Dec 2003 08:44:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11646 for ; Wed, 10 Dec 2003 08:44:03 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU4dI-0002Br-00 for entmib@ietf.org; Wed, 10 Dec 2003 08:44:05 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AU4dI-0002Bn-00 for entmib@ietf.org; Wed, 10 Dec 2003 08:44:04 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBADi3Q16692 for ; Wed, 10 Dec 2003 15:44:03 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 15:44:02 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 05:44:01 -0800 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Entmib] Confirmming Meeting Consensus Date: Wed, 10 Dec 2003 08:44:00 -0500 Message-ID: Thread-Topic: [Entmib] Confirmming Meeting Consensus Thread-Index: AcO+NUTpzYfaIIICRhi+fDF770INAgA7F2oA To: , X-OriginalArrivalTime: 10 Dec 2003 13:44:01.0716 (UTC) FILETIME=[AB6AA740:01C3BF23] Content-Transfer-Encoding: quoted-printable Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Syam, I am sorry, but defining a state model for IPv6 interfaces is not within the charter of the Entity MIB WG. We are working on state/status only as it applies to augmenting the Entity MIB with a "health indicator" regarding the status of each defined entity. As Dave Perkins pointed out, there is already a state model=20 for IP interfaces defined in the IF MIB. If you believe that we should update that model, I would suggest that you discuss your ideas on the IETF MIBs list (mibs@ops.ietf.org), and see if there is sufficient community interest to pursue this work. Margaret > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > ext Syam Madanapalli > Sent: Tuesday, December 09, 2003 4:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > I am wondering if the following draft brings any interest > for the Entity State MIB. >=20 > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt >=20 > But this state model is only for IPv6 Interfaces whereas=20 > Entity State MIB > covers every thing. >=20 > Thank you, > Syam >=20 >=20 > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus >=20 >=20 > > On Mon, Dec 08, 2003 at 08:24:11AM -0500,=20 > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex=20 > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > >=20 > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib >=20 _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 10 10:40:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17128 for ; Wed, 10 Dec 2003 10:40:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU6RY-0007qp-Ab; Wed, 10 Dec 2003 10:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU6RS-0007q0-Rl for entmib@optimus.ietf.org; Wed, 10 Dec 2003 10:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17050 for ; Wed, 10 Dec 2003 10:39:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU6RQ-0004EW-00 for entmib@ietf.org; Wed, 10 Dec 2003 10:39:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AU6RP-0004ES-00 for entmib@ietf.org; Wed, 10 Dec 2003 10:39:56 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Dec 2003 07:41:30 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBAFdIAt021227; Wed, 10 Dec 2003 07:39:19 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA03271; Wed, 10 Dec 2003 07:39:18 -0800 (PST) From: Keith McCloghrie Message-Id: <200312101539.HAA03271@cisco.com> Subject: Re: [Entmib] A state model.... To: madanapalli@hotmail.com (Syam Madanapalli) Date: Wed, 10 Dec 2003 07:39:18 -0800 (PST) Cc: dperkins@dsperkins.com (David T. Perkins), entmib@ietf.org In-Reply-To: from "Syam Madanapalli" at Dec 10, 2003 11:27:36 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > a) The document does not specify why the IF state model > > should be replaced (or augmented) with another model. > > IF state model does not provide the flexibility in defining the states. > When ifOperStatus is down, we do not why it is down. For example > in IPv6, the DAD may fail, there is no way to specify this in the state > info. On the contrary, the IF state model provides plenty of flexibility. Each different type of media has its own failure conditions which are specified in media-specific extensions. So, if you want to define IPv6-specific failures, then you need to define an IPv6-specific extension. Keith. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 10 10:40:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17129 for ; Wed, 10 Dec 2003 10:40:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU6RZ-0007rH-9w for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 10:40:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAFe581030190 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 10:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU6RY-0007qp-Ab; Wed, 10 Dec 2003 10:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU6RS-0007q0-Rl for entmib@optimus.ietf.org; Wed, 10 Dec 2003 10:39:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17050 for ; Wed, 10 Dec 2003 10:39:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU6RQ-0004EW-00 for entmib@ietf.org; Wed, 10 Dec 2003 10:39:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AU6RP-0004ES-00 for entmib@ietf.org; Wed, 10 Dec 2003 10:39:56 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Dec 2003 07:41:30 +0000 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBAFdIAt021227; Wed, 10 Dec 2003 07:39:19 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id HAA03271; Wed, 10 Dec 2003 07:39:18 -0800 (PST) From: Keith McCloghrie Message-Id: <200312101539.HAA03271@cisco.com> Subject: Re: [Entmib] A state model.... To: madanapalli@hotmail.com (Syam Madanapalli) Date: Wed, 10 Dec 2003 07:39:18 -0800 (PST) Cc: dperkins@dsperkins.com (David T. Perkins), entmib@ietf.org In-Reply-To: from "Syam Madanapalli" at Dec 10, 2003 11:27:36 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > a) The document does not specify why the IF state model > > should be replaced (or augmented) with another model. > > IF state model does not provide the flexibility in defining the states. > When ifOperStatus is down, we do not why it is down. For example > in IPv6, the DAD may fail, there is no way to specify this in the state > info. On the contrary, the IF state model provides plenty of flexibility. Each different type of media has its own failure conditions which are specified in media-specific extensions. So, if you want to define IPv6-specific failures, then you need to define an IPv6-specific extension. Keith. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 10 23:49:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04938 for ; Wed, 10 Dec 2003 23:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIl3-00005k-Ql; Wed, 10 Dec 2003 23:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIkX-00005D-KI for entmib@optimus.ietf.org; Wed, 10 Dec 2003 23:48:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04927 for ; Wed, 10 Dec 2003 23:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUIkU-0002eS-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:48:26 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AUIkU-0002dn-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:48:26 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HPP00901RZQHB@mailout2.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:47:50 +0900 (KST) Received: from ep_ms13_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00HB1RZQ6U@mailout2.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:47:50 +0900 (KST) Received: from ep_spt01 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00M3DRZQUN@ms13.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:47:50 +0900 (KST) Content-return: prohibited Date: Thu, 11 Dec 2003 04:47:53 +0000 (GMT) From: Syam Madanpalli Subject: Re :RE: [Entmib] A state model.... X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPKENUTyk/TWFuYWdlcg==?= To: "Romascanu, Dan (Dan) " Cc: Syam Madanapalli , "David T. Perkins " , "entmib@ietf.org " Reply-to: syam@samsung.com Message-id: <4201682.1071118069933.JavaMail.weblogic@ep_app04> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20031211044749867@syam X-MTR: 20031211044749867@syam X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello Dan ------- Original Message ------- Sender : Romascanu, Dan (Dan) Date : Dec 10, 2003 16:04 Title : RE: [Entmib] A state model.... Syam, > > > > > Finally, it was sort of strange that the security section specified > > a reference to SNMPv1 when the document is a model and does not > > contain SNMP object nor notification definitions. > > As I mentioned earlier the draft is not complete by itself. > This can be done > if the approach is useful. I think that the point that David is raising is why bother to include an SNMP-related text in the security section, while the draft does not contain any SNMP MIB objects definition. However, this is a minor editorial issue, relative to the modeling problems raised by David. I share his concern that this draft goes into a divergent direction relative to the existing interface state model defined by the Interfaces MIB. I am wondering whether you have looked at that model and considered adding the eventual missing pieces, instead of creating an alternate one. --> When we were implementing IPv6 protocol stack, we felt that the IF State Model is not sufficient for IPv6 Interfaces to reflect all error condition. I did not give a thought to add missing pieces in IF State Model rather than defining the new State Model. Probably it is a good idea to think in this direction. Regards, Dan _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 10 23:49:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04953 for ; Wed, 10 Dec 2003 23:49:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIl4-00005w-6K for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 23:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB4n2rk000363 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 23:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIl3-00005k-Ql; Wed, 10 Dec 2003 23:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUIkX-00005D-KI for entmib@optimus.ietf.org; Wed, 10 Dec 2003 23:48:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04927 for ; Wed, 10 Dec 2003 23:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUIkU-0002eS-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:48:26 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AUIkU-0002dn-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:48:26 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HPP00901RZQHB@mailout2.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:47:50 +0900 (KST) Received: from ep_ms13_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00HB1RZQ6U@mailout2.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:47:50 +0900 (KST) Received: from ep_spt01 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00M3DRZQUN@ms13.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:47:50 +0900 (KST) Content-return: prohibited Date: Thu, 11 Dec 2003 04:47:53 +0000 (GMT) From: Syam Madanpalli Subject: Re :RE: [Entmib] A state model.... X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPKENUTyk/TWFuYWdlcg==?= To: "Romascanu, Dan (Dan) " Cc: Syam Madanapalli , "David T. Perkins " , "entmib@ietf.org " Reply-to: syam@samsung.com Message-id: <4201682.1071118069933.JavaMail.weblogic@ep_app04> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20031211044749867@syam X-MTR: 20031211044749867@syam X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello Dan ------- Original Message ------- Sender : Romascanu, Dan (Dan) Date : Dec 10, 2003 16:04 Title : RE: [Entmib] A state model.... Syam, > > > > > Finally, it was sort of strange that the security section specified > > a reference to SNMPv1 when the document is a model and does not > > contain SNMP object nor notification definitions. > > As I mentioned earlier the draft is not complete by itself. > This can be done > if the approach is useful. I think that the point that David is raising is why bother to include an SNMP-related text in the security section, while the draft does not contain any SNMP MIB objects definition. However, this is a minor editorial issue, relative to the modeling problems raised by David. I share his concern that this draft goes into a divergent direction relative to the existing interface state model defined by the Interfaces MIB. I am wondering whether you have looked at that model and considered adding the eventual missing pieces, instead of creating an alternate one. --> When we were implementing IPv6 protocol stack, we felt that the IF State Model is not sufficient for IPv6 Interfaces to reflect all error condition. I did not give a thought to add missing pieces in IF State Model rather than defining the new State Model. Probably it is a good idea to think in this direction. Regards, Dan _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 10 23:58:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05157 for ; Wed, 10 Dec 2003 23:58:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUItk-0000Gz-Oz; Wed, 10 Dec 2003 23:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUItG-0000Gl-Hs for entmib@optimus.ietf.org; Wed, 10 Dec 2003 23:57:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05142 for ; Wed, 10 Dec 2003 23:57:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUItD-0002ne-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:57:27 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AUItC-0002nD-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:57:26 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HPP00705SEWRH@mailout3.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:56:56 +0900 (KST) Received: from ep_ms13_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00I82SEVAR@mailout3.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:56:55 +0900 (KST) Received: from ep_spt01 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00HU1SEVU8@ms13.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:56:55 +0900 (KST) Content-return: prohibited Date: Thu, 11 Dec 2003 04:56:58 +0000 (GMT) From: Syam Madanpalli Subject: Re :RE: [Entmib] Confirmming Meeting Consensus X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPKENUTyk/TWFuYWdlcg==?= To: "Margaret.Wasserman@nokia.com " Cc: "entmib@ietf.org " Reply-to: syam@samsung.com Message-id: <2847341.1071118614388.JavaMail.weblogic@ep_app04> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20031211045654382@syam X-MTR: 20031211045654382@syam X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello Margaret, I will do this. Thank you for the information. Syam ------- Original Message ------- Sender : Margaret.Wasserman@nokia.com Date : Dec 10, 2003 22:44 Title : RE: [Entmib] Confirmming Meeting Consensus Hi Syam, I am sorry, but defining a state model for IPv6 interfaces is not within the charter of the Entity MIB WG. We are working on state/status only as it applies to augmenting the Entity MIB with a "health indicator" regarding the status of each defined entity. As Dave Perkins pointed out, there is already a state model for IP interfaces defined in the IF MIB. If you believe that we should update that model, I would suggest that you discuss your ideas on the IETF MIBs list (mibs@ops.ietf.org), and see if there is sufficient community interest to pursue this work. Margaret > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > ext Syam Madanapalli > Sent: Tuesday, December 09, 2003 4:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > I am wondering if the following draft brings any interest > for the Entity State MIB. > > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > But this state model is only for IPv6 Interfaces whereas > Entity State MIB > covers every thing. > > Thank you, > Syam > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 10 23:58:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05171 for ; Wed, 10 Dec 2003 23:58:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUItk-0000HR-VB for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 23:58:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB4w0gQ001064 for entmib-archive@odin.ietf.org; Wed, 10 Dec 2003 23:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUItk-0000Gz-Oz; Wed, 10 Dec 2003 23:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUItG-0000Gl-Hs for entmib@optimus.ietf.org; Wed, 10 Dec 2003 23:57:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05142 for ; Wed, 10 Dec 2003 23:57:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUItD-0002ne-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:57:27 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AUItC-0002nD-00 for entmib@ietf.org; Wed, 10 Dec 2003 23:57:26 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HPP00705SEWRH@mailout3.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:56:56 +0900 (KST) Received: from ep_ms13_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00I82SEVAR@mailout3.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:56:55 +0900 (KST) Received: from ep_spt01 (ms13.samsung.com [203.254.225.109]) by ms13.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HPP00HU1SEVU8@ms13.samsung.com> for entmib@ietf.org; Thu, 11 Dec 2003 13:56:55 +0900 (KST) Content-return: prohibited Date: Thu, 11 Dec 2003 04:56:58 +0000 (GMT) From: Syam Madanpalli Subject: Re :RE: [Entmib] Confirmming Meeting Consensus X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9TSVNPKENUTyk/TWFuYWdlcg==?= To: "Margaret.Wasserman@nokia.com " Cc: "entmib@ietf.org " Reply-to: syam@samsung.com Message-id: <2847341.1071118614388.JavaMail.weblogic@ep_app04> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20031211045654382@syam X-MTR: 20031211045654382@syam X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hello Margaret, I will do this. Thank you for the information. Syam ------- Original Message ------- Sender : Margaret.Wasserman@nokia.com Date : Dec 10, 2003 22:44 Title : RE: [Entmib] Confirmming Meeting Consensus Hi Syam, I am sorry, but defining a state model for IPv6 interfaces is not within the charter of the Entity MIB WG. We are working on state/status only as it applies to augmenting the Entity MIB with a "health indicator" regarding the status of each defined entity. As Dave Perkins pointed out, there is already a state model for IP interfaces defined in the IF MIB. If you believe that we should update that model, I would suggest that you discuss your ideas on the IETF MIBs list (mibs@ops.ietf.org), and see if there is sufficient community interest to pursue this work. Margaret > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > ext Syam Madanapalli > Sent: Tuesday, December 09, 2003 4:14 AM > To: entmib@ietf.org > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > I am wondering if the following draft brings any interest > for the Entity State MIB. > > State Model for IPv6 Interfaces > http://www.ietf.org/internet-drafts/draft-syam-ipv6-state-model-00.txt > > But this state model is only for IPv6 Interfaces whereas > Entity State MIB > covers every thing. > > Thank you, > Syam > > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: > Cc: > Sent: Monday, December 08, 2003 7:13 PM > Subject: Re: [Entmib] Confirmming Meeting Consensus > > > > On Mon, Dec 08, 2003 at 08:24:11AM -0500, > Margaret.Wasserman@nokia.com > wrote: > > > > > > During the meeting in Minneapolis, there was agreement > > > in the room on a few points, an dI'd like to confirm > > > that consensus on the mailing list. > > > > > > In particular, we reached agreement at the meeting on > > > the following points: > > > > > > - We will deprecate the Alias Mapping Table so that the Entity > > > MIB can advance to Draft Standard. > > > > Well, this is what it takes... > > > > > - Future extensions to the Entity MIB should be handled as > > > separate MIBs that augment the Entity MIB. > > > > Not sure how useful such a blanket statement is. > > > > > - The Entity State MIB is currently too complex and should be > > > simplified. > > > > I like to know what precisely people find too complex > before subscribing > > to such a blanket statement. Can someone please explain (and perhaps > > suggest what precisely needs to be removed)? > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 Bremen, > Germany > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Dec 11 14:57:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17330 for ; Thu, 11 Dec 2003 14:57:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvk-0005S6-3K; Thu, 11 Dec 2003 14:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvd-0005RY-Le for entmib@optimus.ietf.org; Thu, 11 Dec 2003 14:56:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17244 for ; Thu, 11 Dec 2003 14:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUWva-00066j-00 for entmib@ietf.org; Thu, 11 Dec 2003 14:56:50 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AUWva-000650-00 for entmib@ietf.org; Thu, 11 Dec 2003 14:56:50 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBBJuFg11989 for ; Thu, 11 Dec 2003 13:56:16 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 11 Dec 2003 20:56:01 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155031D6F32@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Entmib-wg (E-mail)" Date: Thu, 11 Dec 2003 20:55:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Entmib] Minutes from IETF58 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Need to be submitted to minutes@ietf.org no later than Friday 19th of December. Current status: No materials submitted See: http://www.ietf.org/proceedings/03nov/index.html Thanks, Bert _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Dec 11 14:57:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17334 for ; Thu, 11 Dec 2003 14:57:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvk-0005Sh-W6 for entmib-archive@odin.ietf.org; Thu, 11 Dec 2003 14:57:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBJv02q020982 for entmib-archive@odin.ietf.org; Thu, 11 Dec 2003 14:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvk-0005S6-3K; Thu, 11 Dec 2003 14:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUWvd-0005RY-Le for entmib@optimus.ietf.org; Thu, 11 Dec 2003 14:56:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17244 for ; Thu, 11 Dec 2003 14:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUWva-00066j-00 for entmib@ietf.org; Thu, 11 Dec 2003 14:56:50 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AUWva-000650-00 for entmib@ietf.org; Thu, 11 Dec 2003 14:56:50 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBBJuFg11989 for ; Thu, 11 Dec 2003 13:56:16 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Thu, 11 Dec 2003 20:56:01 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155031D6F32@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Entmib-wg (E-mail)" Date: Thu, 11 Dec 2003 20:55:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [Entmib] Minutes from IETF58 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Need to be submitted to minutes@ietf.org no later than Friday 19th of December. Current status: No materials submitted See: http://www.ietf.org/proceedings/03nov/index.html Thanks, Bert _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Tue Dec 16 15:16:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01539 for ; Tue, 16 Dec 2003 15:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLbu-0003Iw-PP for entmib-archive@odin.ietf.org; Tue, 16 Dec 2003 15:16:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGKG2lY012688 for entmib-archive@odin.ietf.org; Tue, 16 Dec 2003 15:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLbt-0003IE-TX; Tue, 16 Dec 2003 15:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLaz-0003HQ-TM for entmib@optimus.ietf.org; Tue, 16 Dec 2003 15:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01361 for ; Tue, 16 Dec 2003 15:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLay-0000td-00 for entmib@ietf.org; Tue, 16 Dec 2003 15:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLaw-0000tN-00 for entmib@ietf.org; Tue, 16 Dec 2003 15:15:04 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AWLaw-0000sU-00 for entmib@ietf.org; Tue, 16 Dec 2003 15:15:02 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBGKEU708213 for ; Tue, 16 Dec 2003 15:14:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 15:14:31 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DDF0A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Tue, 16 Dec 2003 15:14:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #79] AutoReply: Missing States for Physical Componen ts Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution to ent-state-79 Replace section 2.2.1-2.2.8, 2.3 and the object definitions (not the textual conventions) for entStateAdmin, entStateOper, entStateUsage, entStateAlarm, and entStateStandby. Note that this may not include all edit to this objects proposed in relation to other issues. entStateAdmin OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative state for this entity. A value of 'notApplicable' means that this entity is unable to report administrative state. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. Some physical entities exhibit only a subset of the remaining administrative state values. Some entities cannot be locked, and hence this object exhibits only the unlocked state. Other entities can not be shut down gracefully, and hence this object does not exhibit the shutting down state. A value of 'inconsistentValue' will be returned if attempts are made to set this object to values not supported by its administrative model." ::= { entStateEntry 2 } entStateOper OBJECT-TYPE SYNTAX OperState MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state for this entity. A value of 'notApplicable' means that this entity is unable to report operational state. Note that unlike the state model used within the Interfaces MIB [RFC2863], this object does not follow the administrative state. An administrative state of down does not guarantee an operational state of disabled. A value of disabled means that an entity is totally inoperable and unable to provide service both to entities within its containment hierarchy, as defined by having a value of entPhysicalContainedIn that refers to this entity, or to other receivers of its service as defined in ways outside the scope of this MIB. A value of enabled means that an entity is fully or partially operable and able to provide service both to entities within its containment hierarchy, as defined by having a value of entPhysicalContainedIn that refers to this entity, or to other receivers of its service as defined in ways outside the scope of this MIB " ::= { entStateEntry 3 } entStateUsage OBJECT-TYPE SYNTAX UsageState MAX-ACCESS read-only STATUS current DESCRIPTION "The usage state for this entity. A value of 'notApplicable' means that this entity is unable to report usage state. Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of idle means that no other entity is contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity. Some entities will exhibit only a subset of the remaining usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of busy. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of idle and busy." ::= { entStateEntry 4 } entStateAlarm OBJECT-TYPE SYNTAX AlarmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The alarm status for this entity. It does not include the alarms raised on child components within its containment hierarchy, as defined by a value of entPhysicalContainedIn that references this entity. A value of 'notApplicable' means that this entity is unable to report alarm state. If no bits are set, then this entity supports reporting of alarms, but there are currently no active alarms against this entity." ::= { entStateEntry 5 } entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby status for this entity. A value of 'notApplicable' means that this entity is unable to report standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity does not have a standby, this object will always be providingService." ::= { entStateEntry 6 } Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:32 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #79] AutoReply: Missing States for Physical Components Thank you, rt+entity-state@rt.psg.com ------------------------------------------------------------------------- Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'd) state 'lock' for entStateAdmin of a container? f) state 'active' for entStateUsage of a power supply? g) state 'active' for entStateUsage of a fan?' 'y) In general, the description of the states for each combination of entity class and state value is incomplete (see d,e,f above). What is the interpretation of combinations not mentioned in the text? Are such combinations simply undefined but not illegal or are they illegal?' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Dec 16 16:03:08 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01538 for ; Tue, 16 Dec 2003 15:16:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLbt-0003IE-TX; Tue, 16 Dec 2003 15:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLaz-0003HQ-TM for entmib@optimus.ietf.org; Tue, 16 Dec 2003 15:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01361 for ; Tue, 16 Dec 2003 15:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLay-0000td-00 for entmib@ietf.org; Tue, 16 Dec 2003 15:15:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLaw-0000tN-00 for entmib@ietf.org; Tue, 16 Dec 2003 15:15:04 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AWLaw-0000sU-00 for entmib@ietf.org; Tue, 16 Dec 2003 15:15:02 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBGKEU708213 for ; Tue, 16 Dec 2003 15:14:31 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 15:14:31 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DDF0A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Tue, 16 Dec 2003 15:14:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #79] AutoReply: Missing States for Physical Componen ts Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Proposed Resolution to ent-state-79 Replace section 2.2.1-2.2.8, 2.3 and the object definitions (not the textual conventions) for entStateAdmin, entStateOper, entStateUsage, entStateAlarm, and entStateStandby. Note that this may not include all edit to this objects proposed in relation to other issues. entStateAdmin OBJECT-TYPE SYNTAX AdminState MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative state for this entity. A value of 'notApplicable' means that this entity is unable to report administrative state. This object can not be administratively set to 'notSupported'. For entities that do not support administrative state, changing the value of this object to something other than 'notSupported' is not permitted. A value of 'inconsistentValue' will be returned in either case. Some physical entities exhibit only a subset of the remaining administrative state values. Some entities cannot be locked, and hence this object exhibits only the unlocked state. Other entities can not be shut down gracefully, and hence this object does not exhibit the shutting down state. A value of 'inconsistentValue' will be returned if attempts are made to set this object to values not supported by its administrative model." ::= { entStateEntry 2 } entStateOper OBJECT-TYPE SYNTAX OperState MAX-ACCESS read-only STATUS current DESCRIPTION "The operational state for this entity. A value of 'notApplicable' means that this entity is unable to report operational state. Note that unlike the state model used within the Interfaces MIB [RFC2863], this object does not follow the administrative state. An administrative state of down does not guarantee an operational state of disabled. A value of disabled means that an entity is totally inoperable and unable to provide service both to entities within its containment hierarchy, as defined by having a value of entPhysicalContainedIn that refers to this entity, or to other receivers of its service as defined in ways outside the scope of this MIB. A value of enabled means that an entity is fully or partially operable and able to provide service both to entities within its containment hierarchy, as defined by having a value of entPhysicalContainedIn that refers to this entity, or to other receivers of its service as defined in ways outside the scope of this MIB " ::= { entStateEntry 3 } entStateUsage OBJECT-TYPE SYNTAX UsageState MAX-ACCESS read-only STATUS current DESCRIPTION "The usage state for this entity. A value of 'notApplicable' means that this entity is unable to report usage state. Note that in the context of a physical entity, this object refers to an entity's ability to service more physical entities in a containment hierarchy. A value of idle means that no other entity is contained within this entity, as would have been demonstrated by a value of entPhysicalContainedIn that referenced this entity. A value of 'active' means that at least one entity is contained within this entity and therefore has a value of entPhysicalContainedIn that references this entity, but that it could handle more. A value of 'busy' means that the entity is unable to handle any additional entities being contained in it, as demonstrated by having a value of entPhysicalContainedIn that refers to this entity. Some entities will exhibit only a subset of the remaining usage state values. Entities that are unable to ever service any entities within a containment hierarchy will always have a usage state of busy. Some entities will only ever be able to support one entity within its containment hierarchy and will therefore only exhibit values of idle and busy." ::= { entStateEntry 4 } entStateAlarm OBJECT-TYPE SYNTAX AlarmStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The alarm status for this entity. It does not include the alarms raised on child components within its containment hierarchy, as defined by a value of entPhysicalContainedIn that references this entity. A value of 'notApplicable' means that this entity is unable to report alarm state. If no bits are set, then this entity supports reporting of alarms, but there are currently no active alarms against this entity." ::= { entStateEntry 5 } entStateStandby OBJECT-TYPE SYNTAX StandbyStatus MAX-ACCESS read-only STATUS current DESCRIPTION "The standby status for this entity. A value of 'notApplicable' means that this entity is unable to report standby state. Some entities will exhibit only a subset of the remaining standby state values. If this entity does not have a standby, this object will always be providingService." ::= { entStateEntry 6 } Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:32 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #79] AutoReply: Missing States for Physical Components Thank you, rt+entity-state@rt.psg.com ------------------------------------------------------------------------- Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'd) state 'lock' for entStateAdmin of a container? f) state 'active' for entStateUsage of a power supply? g) state 'active' for entStateUsage of a fan?' 'y) In general, the description of the states for each combination of entity class and state value is incomplete (see d,e,f above). What is the interpretation of combinations not mentioned in the text? Are such combinations simply undefined but not illegal or are they illegal?' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 17 08:33:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06942 for ; Wed, 17 Dec 2003 08:33:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbnR-0001yf-81; Wed, 17 Dec 2003 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbn7-0001y2-4z for entmib@optimus.ietf.org; Wed, 17 Dec 2003 08:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06934 for ; Wed, 17 Dec 2003 08:32:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWbn5-00039A-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:32:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWbn4-000392-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:32:39 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWbn4-00038Z-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:32:38 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHDVlr19122 for ; Wed, 17 Dec 2003 08:31:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 08:31:48 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DE1C9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 17 Dec 2003 08:31:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #80] AutoReply: Relationship with other MIBs Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Note that I have added descriptions of these three items to entstate-80 on http://rt.psg.com (ietf, ietf) The proposed resolution to entstate-80 is as follows: Create a section called "Relation to Other MIBs, move the discussion about the relation to the Alarm MIB and the text that did not get deleted from the first two paragraphs in section 2.2 as a "Relationship to the Interfaces MIB". Add in extra sections to cover the first two of theses items. [Although the textual convention from the printer MIB could have been generic, it contains "Status of a printer sub-unit" within its description which would seem to discourage its use outside of the printer physical type, which to my knowledge is not a currently recognized entPhysicalType. I suggest not putting in a section relating this to the Entity State MIB at this time.] N.3 Relation to Bridge MIB For entities of physical type of 'port' that support the dot1dStpPortEnable object, a value of 'enabled' is equivalent to setting the entStateAdmin object to 'unlocked'. Setting dot1dStpPortEnable to 'disabled' is equivalent to setting the entStateAdmin object to 'locked'. N.4 Relation to the Host Resources MIB The hrDeviceStatus object in the Host Resources MIB provides an operational state for devices. For entities that logically correspond to the concept of a device, a value of 'unknown' for hrDeviceStatus corresponds to an entStateOper value of 'notSupported'. A value of 'running' corresponds to an entStateOper value of 'enabled'. A value of 'warning' also corresponds to an entStateOper value of 'enabled', but with appropriate bits set in the entStateAlarm object to indicate the alarms corresponding to the unusual error condition detected. A value of 'testing' or 'down' is equivalent to an entStateOper value of 'disabled'. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:47 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #80] AutoReply: Relationship with other MIBs ------------------------------------------------------------------------- Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'h) Relationship of the entState* objects to the dot1dStpPortEnable of the BRIDGE-MIB? i) Relationship of the entState* objects to the hrDeviceStatus of the HOST-RESOURCES-MIB? j) Relationship of the entState* objects to the objects using the SubUnitStatus TC of the Printer-MIB? ' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 17 08:33:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06944 for ; Wed, 17 Dec 2003 08:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbnT-0001yw-Kq for entmib-archive@odin.ietf.org; Wed, 17 Dec 2003 08:33:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHDX3Wx007617 for entmib-archive@odin.ietf.org; Wed, 17 Dec 2003 08:33:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbnR-0001yf-81; Wed, 17 Dec 2003 08:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbn7-0001y2-4z for entmib@optimus.ietf.org; Wed, 17 Dec 2003 08:32:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06934 for ; Wed, 17 Dec 2003 08:32:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWbn5-00039A-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:32:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWbn4-000392-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:32:39 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWbn4-00038Z-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:32:38 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHDVlr19122 for ; Wed, 17 Dec 2003 08:31:47 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 08:31:48 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DE1C9@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 17 Dec 2003 08:31:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #80] AutoReply: Relationship with other MIBs Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Note that I have added descriptions of these three items to entstate-80 on http://rt.psg.com (ietf, ietf) The proposed resolution to entstate-80 is as follows: Create a section called "Relation to Other MIBs, move the discussion about the relation to the Alarm MIB and the text that did not get deleted from the first two paragraphs in section 2.2 as a "Relationship to the Interfaces MIB". Add in extra sections to cover the first two of theses items. [Although the textual convention from the printer MIB could have been generic, it contains "Status of a printer sub-unit" within its description which would seem to discourage its use outside of the printer physical type, which to my knowledge is not a currently recognized entPhysicalType. I suggest not putting in a section relating this to the Entity State MIB at this time.] N.3 Relation to Bridge MIB For entities of physical type of 'port' that support the dot1dStpPortEnable object, a value of 'enabled' is equivalent to setting the entStateAdmin object to 'unlocked'. Setting dot1dStpPortEnable to 'disabled' is equivalent to setting the entStateAdmin object to 'locked'. N.4 Relation to the Host Resources MIB The hrDeviceStatus object in the Host Resources MIB provides an operational state for devices. For entities that logically correspond to the concept of a device, a value of 'unknown' for hrDeviceStatus corresponds to an entStateOper value of 'notSupported'. A value of 'running' corresponds to an entStateOper value of 'enabled'. A value of 'warning' also corresponds to an entStateOper value of 'enabled', but with appropriate bits set in the entStateAlarm object to indicate the alarms corresponding to the unusual error condition detected. A value of 'testing' or 'down' is equivalent to an entStateOper value of 'disabled'. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Tuesday, July 15, 2003 4:47 AM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #80] AutoReply: Relationship with other MIBs ------------------------------------------------------------------------- Juergen Schoenwaelder [schoenw@ibr.cs.tu-bs.de] 'h) Relationship of the entState* objects to the dot1dStpPortEnable of the BRIDGE-MIB? i) Relationship of the entState* objects to the hrDeviceStatus of the HOST-RESOURCES-MIB? j) Relationship of the entState* objects to the objects using the SubUnitStatus TC of the Printer-MIB? ' _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 17 08:41:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07123 for ; Wed, 17 Dec 2003 08:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbvB-0002Pe-9D; Wed, 17 Dec 2003 08:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbv1-0002PR-Iu for entmib@optimus.ietf.org; Wed, 17 Dec 2003 08:40:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07110 for ; Wed, 17 Dec 2003 08:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWbv0-0003H6-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:40:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWbuz-0003Gz-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:40:50 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWbuz-0003GX-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:40:49 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHDeHr20076 for ; Wed, 17 Dec 2003 08:40:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 08:40:18 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DE1DF@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 17 Dec 2003 08:40:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #244] AutoReply: support for cpu(12) in Entity Stat e MIB Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi The following is the proposed resolution to entstate-244: The change proposed to entstate-79, namely to remove the descriptions in section 2.3.X in favour of more precise object description makes this a bit of a moot point. It also shows why the proposed change is a better approach since we automatically pick up support of new entPhysicalTypes without needing to update section 2.3.X. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Friday, November 21, 2003 1:06 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #244] AutoReply: support for cpu(12) in Entity State MIB ------------------------------------------------------------------------- Andy Bierman [abierman@cisco.com]: - add text in section 2.3.x to define the appropriate MIB object values for a physical entity with an entPhysicalClass value of cpu(12). _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Wed Dec 17 09:11:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08109 for ; Wed, 17 Dec 2003 09:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcOE-0003dA-HO; Wed, 17 Dec 2003 09:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcO8-0003cu-Gg for entmib@optimus.ietf.org; Wed, 17 Dec 2003 09:10:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08101 for ; Wed, 17 Dec 2003 09:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWcO5-00043i-00 for entmib@ietf.org; Wed, 17 Dec 2003 09:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWcO4-00043b-00 for entmib@ietf.org; Wed, 17 Dec 2003 09:10:52 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWcO4-00043T-00 for entmib@ietf.org; Wed, 17 Dec 2003 09:10:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHEAKr28923 for ; Wed, 17 Dec 2003 09:10:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 09:10:20 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DE26A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 17 Dec 2003 09:10:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] Entity State MIB Issue Status Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi The goal is to get the updated Entity State MIB out by the end of the week. As the proposed resolutions to the following entstate issues have received no objections, I will close them in rt.psg.com. 71, 72,73,74, 75, 76 and 78. Proposed resolutions for the following issues were only recently posted so these will remain open until Friday to allow more time to comment: 79, 80 and 244 The following issues are awaiting either proposed resolutions or updated proposed resolutions: 77 and 243 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 17 09:11:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08113 for ; Wed, 17 Dec 2003 09:11:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcOF-0003dr-JZ for entmib-archive@odin.ietf.org; Wed, 17 Dec 2003 09:11:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHEB3RP013986 for entmib-archive@odin.ietf.org; Wed, 17 Dec 2003 09:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcOE-0003dA-HO; Wed, 17 Dec 2003 09:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWcO8-0003cu-Gg for entmib@optimus.ietf.org; Wed, 17 Dec 2003 09:10:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08101 for ; Wed, 17 Dec 2003 09:10:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWcO5-00043i-00 for entmib@ietf.org; Wed, 17 Dec 2003 09:10:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWcO4-00043b-00 for entmib@ietf.org; Wed, 17 Dec 2003 09:10:52 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWcO4-00043T-00 for entmib@ietf.org; Wed, 17 Dec 2003 09:10:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHEAKr28923 for ; Wed, 17 Dec 2003 09:10:20 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 09:10:20 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DE26A@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 17 Dec 2003 09:10:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] Entity State MIB Issue Status Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi The goal is to get the updated Entity State MIB out by the end of the week. As the proposed resolutions to the following entstate issues have received no objections, I will close them in rt.psg.com. 71, 72,73,74, 75, 76 and 78. Proposed resolutions for the following issues were only recently posted so these will remain open until Friday to allow more time to comment: 79, 80 and 244 The following issues are awaiting either proposed resolutions or updated proposed resolutions: 77 and 243 Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Wed Dec 17 09:26:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07125 for ; Wed, 17 Dec 2003 08:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbvC-0002Qf-6U for entmib-archive@odin.ietf.org; Wed, 17 Dec 2003 08:41:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHDf28V009304 for entmib-archive@odin.ietf.org; Wed, 17 Dec 2003 08:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbvB-0002Pe-9D; Wed, 17 Dec 2003 08:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWbv1-0002PR-Iu for entmib@optimus.ietf.org; Wed, 17 Dec 2003 08:40:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07110 for ; Wed, 17 Dec 2003 08:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWbv0-0003H6-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:40:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWbuz-0003Gz-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:40:50 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWbuz-0003GX-00 for entmib@ietf.org; Wed, 17 Dec 2003 08:40:49 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBHDeHr20076 for ; Wed, 17 Dec 2003 08:40:17 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 08:40:18 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD34099DE1DF@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Wed, 17 Dec 2003 08:40:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #244] AutoReply: support for cpu(12) in Entity Stat e MIB Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi The following is the proposed resolution to entstate-244: The change proposed to entstate-79, namely to remove the descriptions in section 2.3.X in favour of more precise object description makes this a bit of a moot point. It also shows why the proposed change is a better approach since we automatically pick up support of new entPhysicalTypes without needing to update section 2.3.X. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Friday, November 21, 2003 1:06 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #244] AutoReply: support for cpu(12) in Entity State MIB ------------------------------------------------------------------------- Andy Bierman [abierman@cisco.com]: - add text in section 2.3.x to define the appropriate MIB object values for a physical entity with an entPhysicalClass value of cpu(12). _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Dec 18 07:59:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18713 for ; Thu, 18 Dec 2003 07:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxk4-0008Ts-FR; Thu, 18 Dec 2003 07:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxjH-0008Sr-8g for entmib@optimus.ietf.org; Thu, 18 Dec 2003 07:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18576 for ; Thu, 18 Dec 2003 07:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxjG-0005T9-00 for entmib@ietf.org; Thu, 18 Dec 2003 07:58:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxjF-0005T2-00 for entmib@ietf.org; Thu, 18 Dec 2003 07:58:09 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWxjE-0005Rl-00 for entmib@ietf.org; Thu, 18 Dec 2003 07:58:08 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBICvaY28013 for ; Thu, 18 Dec 2003 07:57:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 07:57:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409A41F17@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disab led - correct ive action required? Date: Thu, 18 Dec 2003 07:57:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi As we've heard no interest in supporting a dual-mode oper status I propose we keep things the way they are and close this issue (entstate-77). Note that the improved object descriptions should help people better understand the externally expected behaviour. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Saturday, November 22, 2003 1:18 PM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Hi Hmmm. The problem is then that there are two different ways to interpret the state of the entity by reading the same values for those three objects. I'd suggest one of the following then 1) Always force people to use the states as described. Then even if the internal state model is as you described, the externally visible behaviour would be as described in section 2.2. 2) Support two behaviours for oper state and provide a type object to tell you which one is being used. These would be INTEGER { operIndependentAdmin, operFollowsAdmin (2) }. I'm not sure about this approach, but I suspect it would make some people happy. Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, November 21, 2003 2:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? 2.2.2 is fine. It looks to me that what is not covered in the current version of 2.2.1 is the case of these devices that are modeled in their state machine so that the operStatus follows a adminStatus transition to down, although no fault was detected on the respective interface. These interfaces will never be in the state described by 2.2.2. For these cases, when adminStatus transitions back to up is enough to re-establish operStatus as well. (I used the IETF MIB-II terminology that I am more familiar with) Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > Sharon Chisholm > Sent: 21 November, 2003 9:35 PM > To: entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: > Operational State Disabled - correct ive action required? > > > Hi > > Well, the difference between 2.2.1 and 2.2.2 is that one can be made > operational simply by enabling the administrative state while one > requires some corrective action AND someone to enable the > administrative state. I think this covers all the cases you are > referring to. Or am I missing something? > > Sharon > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Friday, November 21, 2003 2:13 PM > To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State > Disabled - correct ive action required? > > > Sharon, > > You are correct about the section number. The text I was commenting on > is in Section 2.2.1 > > 2.2.1 Admin State Locked, Operational State Disabled and Usage State > Idle > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, both management permission and some corrective > action are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > I still believe that there is no need for a corrective action in all > cases. In some cases restoring management permission by setting > the admin state to unlock should be enough. The suggested text: > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, management permission (and in some cases > corrective > action) are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > Regards, > > Dan > > > > > -----Original Message----- > > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf > > Of Sharon Chisholm > > Sent: 21 November, 2003 8:38 PM > > To: entmib@ietf.org > > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State > > Disabled - correct ive action required? > > > > > > Hi > > > > Proposed Resolution to ent-state-77: > > > > Actually, I believe what you are describing is in section 2.2.2. > > > > I propose that no change is required as a result of this comment. > > > > > > -----Original Message----- > > From: entity-state [mailto:rt+entity-state@rt.psg.com] > > Sent: Tuesday, July 15, 2003 4:24 AM > > To: Chisholm, Sharon [CAR:0S00:EXCH] > > Subject: [psg.com #77] AutoReply: Operational State Disabled > > - corrective > > action required? > > > > > > > > -------------------------------------------------------------- > > ----------- > > Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > "Section 2.2.1 in [in version 01]- A corrective action is not > > necessary in all cases to make an entity available for use. In some > > cases setting the admin state to unlock should be enough." > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Dec 18 07:59:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18717 for ; Thu, 18 Dec 2003 07:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxk4-0008UN-RN for entmib-archive@odin.ietf.org; Thu, 18 Dec 2003 07:59:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBICx0mp032613 for entmib-archive@odin.ietf.org; Thu, 18 Dec 2003 07:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxk4-0008Ts-FR; Thu, 18 Dec 2003 07:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxjH-0008Sr-8g for entmib@optimus.ietf.org; Thu, 18 Dec 2003 07:58:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18576 for ; Thu, 18 Dec 2003 07:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxjG-0005T9-00 for entmib@ietf.org; Thu, 18 Dec 2003 07:58:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxjF-0005T2-00 for entmib@ietf.org; Thu, 18 Dec 2003 07:58:09 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWxjE-0005Rl-00 for entmib@ietf.org; Thu, 18 Dec 2003 07:58:08 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBICvaY28013 for ; Thu, 18 Dec 2003 07:57:37 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 07:57:37 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409A41F17@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disab led - correct ive action required? Date: Thu, 18 Dec 2003 07:57:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi As we've heard no interest in supporting a dual-mode oper status I propose we keep things the way they are and close this issue (entstate-77). Note that the improved object descriptions should help people better understand the externally expected behaviour. Sharon -----Original Message----- From: Chisholm, Sharon [CAR:0S00:EXCH] Sent: Saturday, November 22, 2003 1:18 PM To: entmib@ietf.org Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? Hi Hmmm. The problem is then that there are two different ways to interpret the state of the entity by reading the same values for those three objects. I'd suggest one of the following then 1) Always force people to use the states as described. Then even if the internal state model is as you described, the externally visible behaviour would be as described in section 2.2. 2) Support two behaviours for oper state and provide a type object to tell you which one is being used. These would be INTEGER { operIndependentAdmin, operFollowsAdmin (2) }. I'm not sure about this approach, but I suspect it would make some people happy. Sharon -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, November 21, 2003 2:53 PM To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State Disabled - correct ive action required? 2.2.2 is fine. It looks to me that what is not covered in the current version of 2.2.1 is the case of these devices that are modeled in their state machine so that the operStatus follows a adminStatus transition to down, although no fault was detected on the respective interface. These interfaces will never be in the state described by 2.2.2. For these cases, when adminStatus transitions back to up is enough to re-establish operStatus as well. (I used the IETF MIB-II terminology that I am more familiar with) Regards, Dan > -----Original Message----- > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf Of > Sharon Chisholm > Sent: 21 November, 2003 9:35 PM > To: entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: > Operational State Disabled - correct ive action required? > > > Hi > > Well, the difference between 2.2.1 and 2.2.2 is that one can be made > operational simply by enabling the administrative state while one > requires some corrective action AND someone to enable the > administrative state. I think this covers all the cases you are > referring to. Or am I missing something? > > Sharon > > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Friday, November 21, 2003 2:13 PM > To: Chisholm, Sharon [CAR:0S00:EXCH]; entmib@ietf.org > Subject: RE: [Entmib] FW: [psg.com #77] AutoReply: Operational State > Disabled - correct ive action required? > > > Sharon, > > You are correct about the section number. The text I was commenting on > is in Section 2.2.1 > > 2.2.1 Admin State Locked, Operational State Disabled and Usage State > Idle > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, both management permission and some corrective > action are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > I still believe that there is no need for a corrective action in all > cases. In some cases restoring management permission by setting > the admin state to unlock should be enough. The suggested text: > > The entity is totally inoperable, it is not servicing any entities > and it is also administratively prohibited from use. To make it > available for use, management permission (and in some cases > corrective > action) are necessary. This is similar to an ifAdminStatus of down > and ifOperStatus of down. > > Regards, > > Dan > > > > > -----Original Message----- > > From: entmib-admin@ietf.org [mailto:entmib-admin@ietf.org]On Behalf > > Of Sharon Chisholm > > Sent: 21 November, 2003 8:38 PM > > To: entmib@ietf.org > > Subject: [Entmib] FW: [psg.com #77] AutoReply: Operational State > > Disabled - correct ive action required? > > > > > > Hi > > > > Proposed Resolution to ent-state-77: > > > > Actually, I believe what you are describing is in section 2.2.2. > > > > I propose that no change is required as a result of this comment. > > > > > > -----Original Message----- > > From: entity-state [mailto:rt+entity-state@rt.psg.com] > > Sent: Tuesday, July 15, 2003 4:24 AM > > To: Chisholm, Sharon [CAR:0S00:EXCH] > > Subject: [psg.com #77] AutoReply: Operational State Disabled > > - corrective > > action required? > > > > > > > > -------------------------------------------------------------- > > ----------- > > Romascanu, Dan (Dan) [dromasca@avaya.com] > > > > "Section 2.2.1 in [in version 01]- A corrective action is not > > necessary in all cases to make an entity available for use. In some > > cases setting the admin state to unlock should be enough." > > > > _______________________________________________ > > Entmib mailing list > > Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib > > > > _______________________________________________ > Entmib mailing list > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Thu Dec 18 08:12:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19901 for ; Thu, 18 Dec 2003 08:12:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxwf-0000z2-Fg; Thu, 18 Dec 2003 08:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxwb-0000yZ-6H for entmib@optimus.ietf.org; Thu, 18 Dec 2003 08:11:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19868 for ; Thu, 18 Dec 2003 08:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxwY-00073O-00 for entmib@ietf.org; Thu, 18 Dec 2003 08:11:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxwX-00073H-00 for entmib@ietf.org; Thu, 18 Dec 2003 08:11:53 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWxwW-00071n-00 for entmib@ietf.org; Thu, 18 Dec 2003 08:11:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBIDBK001399 for ; Thu, 18 Dec 2003 08:11:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 08:11:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409A41F1D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 18 Dec 2003 08:11:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #243] AutoReply: new enumerations for Operational St ate Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Note that failed is already represented by an entStateOper equal to 'disabled'. As far as the other proposed states go, we have three options: 1. Not support them for now and if there is more demand for them in the future add them. 2. Kluge them as additional enumerations to our existing states 3. Add new (optional )state objects that support these situations and other related ones. In the absence of additional demand for these states, I propose to resolve entstate-243 via method 1, i.e. to not add the additional states. The improved object descriptions should help make it more obvious that failure is the entStateOper value of 'disabled'. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Friday, November 21, 2003 1:00 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #243] AutoReply: new enumerations for Operational State ------------------------------------------------------------------------- Subrahmanya Hegde [subrah@cisco.com]: I would like to include following things in the Operational State of the entities. Atleast I would like entity mib working group to check whether these things can be added along with the existing ones Operational State/Usage: Boot : Device is in the process of booting or initialization failed : Entity is in failed state (so that it can not be used) mismatch : Entity mismatch with the expected entity missing : entity expected but currently not available. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Thu Dec 18 08:12:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19911 for ; Thu, 18 Dec 2003 08:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxwf-0000zU-KV for entmib-archive@odin.ietf.org; Thu, 18 Dec 2003 08:12:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDC1OU003790 for entmib-archive@odin.ietf.org; Thu, 18 Dec 2003 08:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxwf-0000z2-Fg; Thu, 18 Dec 2003 08:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxwb-0000yZ-6H for entmib@optimus.ietf.org; Thu, 18 Dec 2003 08:11:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19868 for ; Thu, 18 Dec 2003 08:11:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxwY-00073O-00 for entmib@ietf.org; Thu, 18 Dec 2003 08:11:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxwX-00073H-00 for entmib@ietf.org; Thu, 18 Dec 2003 08:11:53 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AWxwW-00071n-00 for entmib@ietf.org; Thu, 18 Dec 2003 08:11:52 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBIDBK001399 for ; Thu, 18 Dec 2003 08:11:21 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 08:11:21 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD3409A41F1D@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: entmib@ietf.org Date: Thu, 18 Dec 2003 08:11:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Entmib] FW: [psg.com #243] AutoReply: new enumerations for Operational St ate Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Hi Note that failed is already represented by an entStateOper equal to 'disabled'. As far as the other proposed states go, we have three options: 1. Not support them for now and if there is more demand for them in the future add them. 2. Kluge them as additional enumerations to our existing states 3. Add new (optional )state objects that support these situations and other related ones. In the absence of additional demand for these states, I propose to resolve entstate-243 via method 1, i.e. to not add the additional states. The improved object descriptions should help make it more obvious that failure is the entStateOper value of 'disabled'. Sharon -----Original Message----- From: entity-state [mailto:rt+entity-state@rt.psg.com] Sent: Friday, November 21, 2003 1:00 PM To: Chisholm, Sharon [CAR:0S00:EXCH] Subject: [psg.com #243] AutoReply: new enumerations for Operational State ------------------------------------------------------------------------- Subrahmanya Hegde [subrah@cisco.com]: I would like to include following things in the Operational State of the entities. Atleast I would like entity mib working group to check whether these things can be added along with the existing ones Operational State/Usage: Boot : Device is in the process of booting or initialization failed : Entity is in failed state (so that it can not be used) mismatch : Entity mismatch with the expected entity missing : entity expected but currently not available. _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Fri Dec 19 11:20:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14596 for ; Fri, 19 Dec 2003 11:20:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNMF-0007M3-PP; Fri, 19 Dec 2003 11:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNM1-0007J0-Fr for entmib@optimus.ietf.org; Fri, 19 Dec 2003 11:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14539 for ; Fri, 19 Dec 2003 11:19:51 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXNM0-0007gM-00 for entmib@ietf.org; Fri, 19 Dec 2003 11:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXNLz-0007gF-00 for entmib@ietf.org; Fri, 19 Dec 2003 11:19:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AXNLv-0007fR-00; Fri, 19 Dec 2003 11:19:47 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJGJd020659; Fri, 19 Dec 2003 18:19:39 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 18:19:36 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 10:18:49 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Dec 2003 11:18:48 -0500 Message-ID: Thread-Topic: On Vacation until January 5th Thread-Index: AcPGS8gg6qbBu0/RT0a942un+hJ03Q== To: , , , , , X-OriginalArrivalTime: 19 Dec 2003 16:18:49.0669 (UTC) FILETIME=[C92F8F50:01C3C64B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Entmib] On Vacation until January 5th Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable [Sent to several lists, please be prudent with replies.] Just FYI -- I will be on vacation starting tomorrow (the 20th) through Sunday, January 4th. I'll be back at work on the 5th. I will read mail sporadically during my vacation, but I may not respond to routine matters until after I return. =20 Happy Holidays! Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From exim@www1.ietf.org Fri Dec 19 11:20:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14623 for ; Fri, 19 Dec 2003 11:20:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNMG-0007MQ-3y for entmib-archive@odin.ietf.org; Fri, 19 Dec 2003 11:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJGK8Tv028283 for entmib-archive@odin.ietf.org; Fri, 19 Dec 2003 11:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNMF-0007M3-PP; Fri, 19 Dec 2003 11:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXNM1-0007J0-Fr for entmib@optimus.ietf.org; Fri, 19 Dec 2003 11:19:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14539 for ; Fri, 19 Dec 2003 11:19:51 -0500 (EST) From: Margaret.Wasserman@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXNM0-0007gM-00 for entmib@ietf.org; Fri, 19 Dec 2003 11:19:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXNLz-0007gF-00 for entmib@ietf.org; Fri, 19 Dec 2003 11:19:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AXNLv-0007fR-00; Fri, 19 Dec 2003 11:19:47 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJGJd020659; Fri, 19 Dec 2003 18:19:39 +0200 (EET) Received: from daebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 18:19:36 +0200 Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 10:18:49 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Dec 2003 11:18:48 -0500 Message-ID: Thread-Topic: On Vacation until January 5th Thread-Index: AcPGS8gg6qbBu0/RT0a942un+hJ03Q== To: , , , , , X-OriginalArrivalTime: 19 Dec 2003 16:18:49.0669 (UTC) FILETIME=[C92F8F50:01C3C64B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Entmib] On Vacation until January 5th Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-BeenThere: entmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IETF Entity MIB WG List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable [Sent to several lists, please be prudent with replies.] Just FYI -- I will be on vacation starting tomorrow (the 20th) through Sunday, January 4th. I'll be back at work on the 5th. I will read mail sporadically during my vacation, but I may not respond to routine matters until after I return. =20 Happy Holidays! Margaret _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib