From mailman-admin@ietf.org Mon Mar 1 09:19:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21509 for ; Mon, 1 Mar 2004 09:19: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 1AxoG7-00029j-4L for hubmib-archive@lists.ietf.org; Mon, 01 Mar 2004 09:19:03 -0500 Date: Mon, 01 Mar 2004 09:19:03 -0500 Message-ID: <20040301141903.27462.6777.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: hubmib-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, hubmib-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for hubmib-archive@lists.ietf.org: List Password // URL ---- -------- hubmib@ietf.org XUKx https://www1.ietf.org/mailman/options/hubmib/hubmib-archive%40lists.ietf.org From exim@www1.ietf.org Mon Mar 1 11:42:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18782 for ; Mon, 1 Mar 2004 11:42:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqFG-00069r-Ub for hubmib-archive@odin.ietf.org; Mon, 01 Mar 2004 11:26:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21GQICa023648 for hubmib-archive@odin.ietf.org; Mon, 1 Mar 2004 11:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqFG-00069J-7K; Mon, 01 Mar 2004 11:26:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqEs-0005wP-Mz for hubmib@optimus.ietf.org; Mon, 01 Mar 2004 11:25:54 -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 LAA16985 for ; Mon, 1 Mar 2004 11:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axpyr-0006Rn-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:09:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpuX-0004Tr-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:04:57 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1Axpon-0002Cv-00 for hubmib@ietf.org; Mon, 01 Mar 2004 10:58:57 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 18:04:49 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742100@il-mail02.actelis.net> From: Edward Beili To: hubmib@ietf.org Cc: "Dan Romascanu (Dan) (E-mail)" Subject: [Hubmib] EFM-CU-MIB - issues Date: Mon, 1 Mar 2004 18:04:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, Below are some issues I ran into while working on EFM-CU-MIB. I would appreciate any feedback. Regards, -Edward Issues list for the EFM-CU-MIB --------------------------------------------- 1. Is current use of ifStackTable for actual cross-connects between PMEs and PCSs (read-write) and efmCuAvailableStackTable for cross-connect capability (read only), the right choice? An alternative would be to use ifStackTable to describe cross-connect capability and efmCuAvailableStackTable to describe actual connections, so that the cross-connect action would be done in the EFM-CU-MIB by modifying the efmCuAvailableStackTable (and not in IF-MIB). 2. I've decided not to reference HDSL2-SHDSL-LINE-MIB and VDSL-LINE-MIB but to define all the relevant objects in this MIB (because of the differences between SHDSL/VDSL versions described in those MIBs and DSL versions used in EFM, and for the purposes of simplicity and name consistency). Again, is it the right choice? 3. Notifications - should we add more and which ones? Currently defined are: - efmCuPmeLineDefect, - efmCuPmeLineAtnCrossing, - efmCuPmeRemoteLineAtnCrossing, - efmCuPmeSnrMgnCrossing, - efmCuPmeRemoteSnrMgnCrossing Additional ones could be: - efmCuPmePerfES, - efmCuPmePerfSES, - efmCuPmePerfCRCanomalies, - efmCuPmePerfLOSWS, - efmCuPmePerfUAS, - efmCuPmeDeviceFault, - efmCuPmeLocalPowerLoss 4. MAU-MIB shall be augmented to include the following new values for ifMauType (instances of dot2MauType): - dot3MauType2BaseTL - voice grade UTP Phy specified in Clause 61 and 63 - dot3MauType10PassTS - voice grade UTP Phy specified in Clause 61 and 62 Question: Should we include -O/-R subtype? 5. I would like to have both possibilities for EFMCu PME configuration: - A single profile for 10PassTS/Up to 5 profiles for 2BaseTL (each profile is a specific set of values for parameters comprising a profile, e.g. DataRate, Region, PSD, Constellation for 2BaseTL) - Set each parameter separately. For the meantime I've defined a profile variable in addition to parameter variables. Questions: - Should we have only one possibility? - Should we have both? Some error handling is needed when both Profile and parameters are specified, could be as simple as precedence rules. 6. In EFM Draft D3.1 a new layer at the PME is defined called TC, with corresponding error counters. Should we define a new Sequence in the MIB for TC or put all these counters under current efmCuPmeEntry Sequence (I'm leaning toward 2nd option). _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 1 11:42:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18966 for ; Mon, 1 Mar 2004 11:42:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqF7-0005zz-6y for hubmib-archive@odin.ietf.org; Mon, 01 Mar 2004 11:26:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21GQ83K023047 for hubmib-archive@odin.ietf.org; Mon, 1 Mar 2004 11:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqF5-0005z6-Jn; Mon, 01 Mar 2004 11:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqEL-0005gy-Fr for hubmib@optimus.ietf.org; Mon, 01 Mar 2004 11:25:22 -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 LAA16512 for ; Mon, 1 Mar 2004 11:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axq42-00008R-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:14:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axq1k-0007HZ-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:12:22 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1Axpyt-0006Lj-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:09:23 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 18:15:16 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742101@il-mail02.actelis.net> From: Edward Beili To: "'Matt Squire'" , hubmib@ietf.org Cc: "Dan Romascanu (Dan) (E-mail)" Subject: RE: [Hubmib] EFM Common MIB - issues Date: Mon, 1 Mar 2004 18:15:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Matt, 1) I support the name change from EFM-COMMON-MIB to EFM-OAM-MIB. The overview section is not worth it. The current name is misleading since an EPON or EFMCu equipment manufacturer doesn't have to implement this MIB unless an OAM functionality is supported. Regards, -Edward > -----Original Message----- > From: Matt Squire [mailto:MSquire@HatterasNetworks.com] > Sent: Friday, February 27, 2004 12:18 AM > To: hubmib@ietf.org > Cc: Dan Romascanu (Dan) (E-mail) > Subject: [Hubmib] EFM Common MIB - issues > > > > Below are some issues I'm running into when working on the > next version of the EFM Common MIB. Would appreciate any feedback. > > - Matt > > ================= > > 1) "Common" vs "OAM". Right now, we call this MIB the EFM > "common" MIB. The idea, originally, was that this would > cover anything common across all EFM PHYs. Right now, the > only thing in this MIB is OAM. The new copper and EPON work > have their own MIB. So should we re-name/re-focus this MIB > to be just OAM and not "common"? Although the difference to > the MIB section is negligible (a few name changes), I think > the difference in the overview/intro section is substantial. > If "common", it needs to talk about .3ah in all its glory, > and provide an overview of OAM/copper/PON. If "OAM", that > goes away and its a relatively focused overview/intro. > > ====================== > > 2) Loopback. I'd like to go to a loopback control that looks like > Dot3OamLoopbackEntry ::= > SEQUENCE { > dot3OamLoopbackCommand INTEGER, > dot3OamLoopbackStatus INTEGER > } > Where you can issue a loopback command with the first entry, > and the second entry gives a loopoback state. The > difficulty/benefit of the loopback status variable is that in > OAM and C30, we expose the local/remote multiplexor/parser > state, but there's no simple loopback status. It seems more > beneficial from a management status to provide something > simpler than exposing parser/mux status on each end of the > link. So here's what I'm thinking, and I'd appreciate > thoughts if its acceptable to try to simplify the interface > like this, or of people would rather have the parser/mux > states available and let the user figure out how that relates > to a good loopback operation. > > dot3OamLoopbackStatus OBJECT-TYPE > SYNTAX INTEGER { > noLoopback (1), > initiatingLoopback (2), > remoteLoopback (3), > terminatingLoopback (4), > localLoopback (5), > unknown (6) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The loopback status of the OAM entity. This > status is determined by a combination of the > local parser and multiplexer states, the remote > parser and multiplexer states, as well as > by the actions of the local OAM client. When > operating in normal mode with no loopback in > progress, the status reads noLoopback(1). > > If the OAM client has sent an OAM loopback PDU > and is waiting for a response, where the local > parser and multiplexer states are DISCARD (see > [802.3ah, 57.2.11.1]), the status is > 'initiatingLoopback'. In this case, the local > OAM entity has yet to receive any > acknowledgement that the remote OAM entity has > received its loopback command request. > > If the local OAM client knows that the remote > OAM entity is in loopback mode (via the remote > state information as described in [802.3ah, > 57.2.11.1, 30.11.1.1.15]), the status is > remoteLoopback(3). If the local OAM client is > in the process of terminating the remote > loopback [802.3ah, 57.2.11.3, 30.11.1.1.14], > with its local multiplexer and parser states in > DISCARD, the status is terminatingLoopback(4). > If the remote OAM client has put the local OAM > entity in loopback mode as indicated by its > local parser state, the status is > localLoopback(5). > > The unknown(6) status indicates the parser and > multiplexer combination is unexpected. This > status may be returned if the OAM loopback is > in a transition state but should not persist. > > The values of this attribute correspond to the > following values of the local and remote paser > and multiplexer states, where 'X' means the > state can be any value. > value LclPrsr LclMux RmtPrsr RmtMux > noLoopback FWD FWD FWD FWD > initLoopback DISCARD DISCARD FWD FWD > rmtLoopback DISCARD FWD LPBK DISCARD > tmtngLoopback DISCARD DISCARD LPBK DISCARD > lclLoopback LPBK DISCARD DISCARD FWD > unknown ** any other combination ** > " > REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.11.1.1.14, > 30.11.1.1.15" > ::= { dot3OamLoopbackEntry 2 } > > > ======================= > > 3) Counters. For all of the counters, do we have to (or just > should we) always include some text reference on > discontinuities, and if so, can we just reference the > ifCounterDiscontinuityTime or do we need something else. For > example, is the following text sufficient/good for each counter: > > Discontinuities of this counter can occur at > re-initialization of the management system, and > at other times as indicated by the value of the > ifCounterDiscontinuityTime. > > ========================= > > 4) Event counters exposure. As has been discussed a little > on the list, Events can expose information thats not always > there, and its kind of funky. The primary example is symbol > errors. There is not Ethernet counter for symbol errors. > However, we have events that trigger on symbol errors, and if > the event occurs, the number of symbol errors that have > occurred *at the time of the event* is available. So its a > counter, but its a snapshot view. > > =========================== > > 5) Event Control. I had received a suggestion to have more > control on events (e.g. be able to turn them on/off). Such > controls don't exist in C30. However, the issueing of events > happens architecturally within the OAM client, which is sort > of a black box and not specified within the document. So I'd > like to add controls for each event to (a) if that event > occurs, send an Event Notification OAMPDU, (b) if that event > occurs, send a SNMP notification, and (c) if that event is > received from the OAM peer, send a SNMP notification. I'm > thinking about attributes like the following (below is for > Errored Symbol Events, but this applies to other events too): > > dot3OamErrSymPeriodWindow OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION "The number of symbols over which the > threshold is defined. > > If dot3OamErrSymPeriodThreshold symbol errors > occur within a window of > dot3OamErrSymPeriodWindow symbols, an Event > Notification OAMPDU should be generated with an > Errored Symbol Period Event TLV indicating the > threshold has been crossed in this window. > " > REFERENCE "[802.3ah], 30.11.1.1.34" > ::= { dot3OamEventConfigEntry 1 } > > dot3OamErrSymPeriodThreshold OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION "The number of symbols errors that must occur > for this event to be triggered. > > If dot3OamErrSymPeriodThreshold symbol errors > occur within a window of > dot3OamErrSymPeriodWindow symbols, an Event > Notification OAMPDU should be generated with an > Errored Symbol Period Event TLV indicating the > threshold has been crossed in this window. > " > REFERENCE "[802.3ah], 30.11.1.1.34" > ::= { dot3OamEventConfigEntry 2 } > > dot3OamErrSymPeriodEvNotifEnable OBJECT-TYPE > SYNTAX INTEGER { enabled(1), disabled(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION "Indicates whether the occurence of > Errored Symbol > Period Events should result in Event > Notification OAMPDUs generated by the > OAM layer. > > By default, this object should have the value > enabled(1) for Ethernet like interfaces that > support OAM. If the OAM layer does not support > event notifications (as indicated via the > dot3OamFunctionsSupported attribute), this > value is ignored. > " > REFERENCE "N/A" > ::= { dot3OamEventConfigEntry 3 } > > dot3OamErrSymPeriodLclTrapEnable OBJECT-TYPE > SYNTAX INTEGER { enabled(1), disabled(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION "Indicates whether the occurence of > Errored Symbol > Period Events should result in SNMP traps. > > By default, this object should have the value > disabled(1) for Ethernet like interfaces that > support OAM. If the OAM layer does not support > event notifications (as indicated via the > dot3OamFunctionsSupported attribute), this > value is ignored. > " > REFERENCE "N/A" > ::= { dot3OamEventConfigEntry 4 } > > dot3OamErrSymPeriodRmtTrapEnable OBJECT-TYPE > SYNTAX INTEGER { enabled(1), disabled(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION "Indicates whether the reception of Errored > Symbol Period event from an OAM peer should > result in an SNMP trap. > > By default, this object should have the value > disabled(1) for Ethernet like interfaces that > support OAM. If the OAM layer does not support > event notifications (as indicated via the > dot3OamFunctionsSupported attribute), this > value is ignored. > " > REFERENCE "N/A" > ::= { dot3OamEventConfigEntry 5 } > > The idea being you can set threshold that define "when > something bad" happens. Then you have additional control > that define what you do about it - e.g. send OAM events, send > SNMP notifications, etc. > > =========================== > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 1 12:34:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23720 for ; Mon, 1 Mar 2004 12:34: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 1AxqFG-00069J-7K; Mon, 01 Mar 2004 11:26:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqEs-0005wP-Mz for hubmib@optimus.ietf.org; Mon, 01 Mar 2004 11:25:54 -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 LAA16985 for ; Mon, 1 Mar 2004 11:25:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axpyr-0006Rn-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:09:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxpuX-0004Tr-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:04:57 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1Axpon-0002Cv-00 for hubmib@ietf.org; Mon, 01 Mar 2004 10:58:57 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 18:04:49 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742100@il-mail02.actelis.net> From: Edward Beili To: hubmib@ietf.org Cc: "Dan Romascanu (Dan) (E-mail)" Subject: [Hubmib] EFM-CU-MIB - issues Date: Mon, 1 Mar 2004 18:04:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, Below are some issues I ran into while working on EFM-CU-MIB. I would appreciate any feedback. Regards, -Edward Issues list for the EFM-CU-MIB --------------------------------------------- 1. Is current use of ifStackTable for actual cross-connects between PMEs and PCSs (read-write) and efmCuAvailableStackTable for cross-connect capability (read only), the right choice? An alternative would be to use ifStackTable to describe cross-connect capability and efmCuAvailableStackTable to describe actual connections, so that the cross-connect action would be done in the EFM-CU-MIB by modifying the efmCuAvailableStackTable (and not in IF-MIB). 2. I've decided not to reference HDSL2-SHDSL-LINE-MIB and VDSL-LINE-MIB but to define all the relevant objects in this MIB (because of the differences between SHDSL/VDSL versions described in those MIBs and DSL versions used in EFM, and for the purposes of simplicity and name consistency). Again, is it the right choice? 3. Notifications - should we add more and which ones? Currently defined are: - efmCuPmeLineDefect, - efmCuPmeLineAtnCrossing, - efmCuPmeRemoteLineAtnCrossing, - efmCuPmeSnrMgnCrossing, - efmCuPmeRemoteSnrMgnCrossing Additional ones could be: - efmCuPmePerfES, - efmCuPmePerfSES, - efmCuPmePerfCRCanomalies, - efmCuPmePerfLOSWS, - efmCuPmePerfUAS, - efmCuPmeDeviceFault, - efmCuPmeLocalPowerLoss 4. MAU-MIB shall be augmented to include the following new values for ifMauType (instances of dot2MauType): - dot3MauType2BaseTL - voice grade UTP Phy specified in Clause 61 and 63 - dot3MauType10PassTS - voice grade UTP Phy specified in Clause 61 and 62 Question: Should we include -O/-R subtype? 5. I would like to have both possibilities for EFMCu PME configuration: - A single profile for 10PassTS/Up to 5 profiles for 2BaseTL (each profile is a specific set of values for parameters comprising a profile, e.g. DataRate, Region, PSD, Constellation for 2BaseTL) - Set each parameter separately. For the meantime I've defined a profile variable in addition to parameter variables. Questions: - Should we have only one possibility? - Should we have both? Some error handling is needed when both Profile and parameters are specified, could be as simple as precedence rules. 6. In EFM Draft D3.1 a new layer at the PME is defined called TC, with corresponding error counters. Should we define a new Sequence in the MIB for TC or put all these counters under current efmCuPmeEntry Sequence (I'm leaning toward 2nd option). _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 1 12:34:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23722 for ; Mon, 1 Mar 2004 12:34: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 1AxqF5-0005z6-Jn; Mon, 01 Mar 2004 11:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxqEL-0005gy-Fr for hubmib@optimus.ietf.org; Mon, 01 Mar 2004 11:25:22 -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 LAA16512 for ; Mon, 1 Mar 2004 11:25:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axq42-00008R-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:14:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axq1k-0007HZ-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:12:22 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1Axpyt-0006Lj-00 for hubmib@ietf.org; Mon, 01 Mar 2004 11:09:23 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Mon, 1 Mar 2004 18:15:16 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742101@il-mail02.actelis.net> From: Edward Beili To: "'Matt Squire'" , hubmib@ietf.org Cc: "Dan Romascanu (Dan) (E-mail)" Subject: RE: [Hubmib] EFM Common MIB - issues Date: Mon, 1 Mar 2004 18:15:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Matt, 1) I support the name change from EFM-COMMON-MIB to EFM-OAM-MIB. The overview section is not worth it. The current name is misleading since an EPON or EFMCu equipment manufacturer doesn't have to implement this MIB unless an OAM functionality is supported. Regards, -Edward > -----Original Message----- > From: Matt Squire [mailto:MSquire@HatterasNetworks.com] > Sent: Friday, February 27, 2004 12:18 AM > To: hubmib@ietf.org > Cc: Dan Romascanu (Dan) (E-mail) > Subject: [Hubmib] EFM Common MIB - issues > > > > Below are some issues I'm running into when working on the > next version of the EFM Common MIB. Would appreciate any feedback. > > - Matt > > ================= > > 1) "Common" vs "OAM". Right now, we call this MIB the EFM > "common" MIB. The idea, originally, was that this would > cover anything common across all EFM PHYs. Right now, the > only thing in this MIB is OAM. The new copper and EPON work > have their own MIB. So should we re-name/re-focus this MIB > to be just OAM and not "common"? Although the difference to > the MIB section is negligible (a few name changes), I think > the difference in the overview/intro section is substantial. > If "common", it needs to talk about .3ah in all its glory, > and provide an overview of OAM/copper/PON. If "OAM", that > goes away and its a relatively focused overview/intro. > > ====================== > > 2) Loopback. I'd like to go to a loopback control that looks like > Dot3OamLoopbackEntry ::= > SEQUENCE { > dot3OamLoopbackCommand INTEGER, > dot3OamLoopbackStatus INTEGER > } > Where you can issue a loopback command with the first entry, > and the second entry gives a loopoback state. The > difficulty/benefit of the loopback status variable is that in > OAM and C30, we expose the local/remote multiplexor/parser > state, but there's no simple loopback status. It seems more > beneficial from a management status to provide something > simpler than exposing parser/mux status on each end of the > link. So here's what I'm thinking, and I'd appreciate > thoughts if its acceptable to try to simplify the interface > like this, or of people would rather have the parser/mux > states available and let the user figure out how that relates > to a good loopback operation. > > dot3OamLoopbackStatus OBJECT-TYPE > SYNTAX INTEGER { > noLoopback (1), > initiatingLoopback (2), > remoteLoopback (3), > terminatingLoopback (4), > localLoopback (5), > unknown (6) > } > MAX-ACCESS read-only > STATUS current > DESCRIPTION "The loopback status of the OAM entity. This > status is determined by a combination of the > local parser and multiplexer states, the remote > parser and multiplexer states, as well as > by the actions of the local OAM client. When > operating in normal mode with no loopback in > progress, the status reads noLoopback(1). > > If the OAM client has sent an OAM loopback PDU > and is waiting for a response, where the local > parser and multiplexer states are DISCARD (see > [802.3ah, 57.2.11.1]), the status is > 'initiatingLoopback'. In this case, the local > OAM entity has yet to receive any > acknowledgement that the remote OAM entity has > received its loopback command request. > > If the local OAM client knows that the remote > OAM entity is in loopback mode (via the remote > state information as described in [802.3ah, > 57.2.11.1, 30.11.1.1.15]), the status is > remoteLoopback(3). If the local OAM client is > in the process of terminating the remote > loopback [802.3ah, 57.2.11.3, 30.11.1.1.14], > with its local multiplexer and parser states in > DISCARD, the status is terminatingLoopback(4). > If the remote OAM client has put the local OAM > entity in loopback mode as indicated by its > local parser state, the status is > localLoopback(5). > > The unknown(6) status indicates the parser and > multiplexer combination is unexpected. This > status may be returned if the OAM loopback is > in a transition state but should not persist. > > The values of this attribute correspond to the > following values of the local and remote paser > and multiplexer states, where 'X' means the > state can be any value. > value LclPrsr LclMux RmtPrsr RmtMux > noLoopback FWD FWD FWD FWD > initLoopback DISCARD DISCARD FWD FWD > rmtLoopback DISCARD FWD LPBK DISCARD > tmtngLoopback DISCARD DISCARD LPBK DISCARD > lclLoopback LPBK DISCARD DISCARD FWD > unknown ** any other combination ** > " > REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.11.1.1.14, > 30.11.1.1.15" > ::= { dot3OamLoopbackEntry 2 } > > > ======================= > > 3) Counters. For all of the counters, do we have to (or just > should we) always include some text reference on > discontinuities, and if so, can we just reference the > ifCounterDiscontinuityTime or do we need something else. For > example, is the following text sufficient/good for each counter: > > Discontinuities of this counter can occur at > re-initialization of the management system, and > at other times as indicated by the value of the > ifCounterDiscontinuityTime. > > ========================= > > 4) Event counters exposure. As has been discussed a little > on the list, Events can expose information thats not always > there, and its kind of funky. The primary example is symbol > errors. There is not Ethernet counter for symbol errors. > However, we have events that trigger on symbol errors, and if > the event occurs, the number of symbol errors that have > occurred *at the time of the event* is available. So its a > counter, but its a snapshot view. > > =========================== > > 5) Event Control. I had received a suggestion to have more > control on events (e.g. be able to turn them on/off). Such > controls don't exist in C30. However, the issueing of events > happens architecturally within the OAM client, which is sort > of a black box and not specified within the document. So I'd > like to add controls for each event to (a) if that event > occurs, send an Event Notification OAMPDU, (b) if that event > occurs, send a SNMP notification, and (c) if that event is > received from the OAM peer, send a SNMP notification. I'm > thinking about attributes like the following (below is for > Errored Symbol Events, but this applies to other events too): > > dot3OamErrSymPeriodWindow OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION "The number of symbols over which the > threshold is defined. > > If dot3OamErrSymPeriodThreshold symbol errors > occur within a window of > dot3OamErrSymPeriodWindow symbols, an Event > Notification OAMPDU should be generated with an > Errored Symbol Period Event TLV indicating the > threshold has been crossed in this window. > " > REFERENCE "[802.3ah], 30.11.1.1.34" > ::= { dot3OamEventConfigEntry 1 } > > dot3OamErrSymPeriodThreshold OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-write > STATUS current > DESCRIPTION "The number of symbols errors that must occur > for this event to be triggered. > > If dot3OamErrSymPeriodThreshold symbol errors > occur within a window of > dot3OamErrSymPeriodWindow symbols, an Event > Notification OAMPDU should be generated with an > Errored Symbol Period Event TLV indicating the > threshold has been crossed in this window. > " > REFERENCE "[802.3ah], 30.11.1.1.34" > ::= { dot3OamEventConfigEntry 2 } > > dot3OamErrSymPeriodEvNotifEnable OBJECT-TYPE > SYNTAX INTEGER { enabled(1), disabled(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION "Indicates whether the occurence of > Errored Symbol > Period Events should result in Event > Notification OAMPDUs generated by the > OAM layer. > > By default, this object should have the value > enabled(1) for Ethernet like interfaces that > support OAM. If the OAM layer does not support > event notifications (as indicated via the > dot3OamFunctionsSupported attribute), this > value is ignored. > " > REFERENCE "N/A" > ::= { dot3OamEventConfigEntry 3 } > > dot3OamErrSymPeriodLclTrapEnable OBJECT-TYPE > SYNTAX INTEGER { enabled(1), disabled(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION "Indicates whether the occurence of > Errored Symbol > Period Events should result in SNMP traps. > > By default, this object should have the value > disabled(1) for Ethernet like interfaces that > support OAM. If the OAM layer does not support > event notifications (as indicated via the > dot3OamFunctionsSupported attribute), this > value is ignored. > " > REFERENCE "N/A" > ::= { dot3OamEventConfigEntry 4 } > > dot3OamErrSymPeriodRmtTrapEnable OBJECT-TYPE > SYNTAX INTEGER { enabled(1), disabled(2) } > MAX-ACCESS read-write > STATUS current > DESCRIPTION "Indicates whether the reception of Errored > Symbol Period event from an OAM peer should > result in an SNMP trap. > > By default, this object should have the value > disabled(1) for Ethernet like interfaces that > support OAM. If the OAM layer does not support > event notifications (as indicated via the > dot3OamFunctionsSupported attribute), this > value is ignored. > " > REFERENCE "N/A" > ::= { dot3OamEventConfigEntry 5 } > > The idea being you can set threshold that define "when > something bad" happens. Then you have additional control > that define what you do about it - e.g. send OAM events, send > SNMP notifications, etc. > > =========================== > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Mar 2 14:48:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26698 for ; Tue, 2 Mar 2004 14:48: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 1AyFs1-0000Dh-BX; Tue, 02 Mar 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFrm-0000D6-Rm for hubmib@optimus.ietf.org; Tue, 02 Mar 2004 14:47:49 -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 OAA26688 for ; Tue, 2 Mar 2004 14:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyFrk-0003Tt-00 for hubmib@ietf.org; Tue, 02 Mar 2004 14:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyFql-0003Mn-00 for hubmib@ietf.org; Tue, 02 Mar 2004 14:46:44 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1AyFpr-00039F-00 for hubmib@ietf.org; Tue, 02 Mar 2004 14:45:48 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 21:51:40 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF274211A@il-mail02.actelis.net> From: Edward Beili To: "'mathias.riess@infineon.com'" Cc: hubmib@ietf.org, "'Romascanu, Dan (Dan)'" , "'David Law'" Date: Tue, 2 Mar 2004 21:51:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Hubmib] RE: More EFM - Clause 30 Management Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Mathias, The latest officially published version is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt from Jan 15th. I'm currently working on an update, nothing major yet, so you can safely use the version above. noPMEAssigned means that PAF is enabled but Aggregation register is all zeros (no modems assigned). Currently there's no limitation in the text that you have to have at least 1 bit set in the Aggregation. May we should add that in. noPeerPMEPresent means that there was no answer during handshake initialization (as far as I understand it). It could also mean that the modem on the other end physically exists but was excluded from the aggregation as a result of Discovery (i.e. belongs to a different CPE already taken by another CO). You are correct that there's no exact definition in the draft. I'm personally not concerned very much about Clause 30 as I discovered during my work on the MIB that it is acceptable to reference Clause 45 registers if there is no substitute in clause 30. As you may notice from the last published version of the MIB above, I almost exclusively referred to Clause 45 registers. However if you take that "optional" nature of Clause 45 to the extreme than yes, we need all MIB objects reference Clause 30 objects (clause 30 is mandatory). I've added David Law, Dan Romascanu and HUBMIB group in Cc: as I find your comments important. Hope it's OK with you. Regards, -E. > -----Original Message----- > From: mathias.riess@infineon.com [mailto:mathias.riess@infineon.com] > Sent: Tuesday, March 02, 2004 07:52 PM > To: Edward Beili > Subject: More EFM - Clause 30 Management > > > Hi Edward, > at the end of the last meeting in Vancouver, you sent > out an updated > version of the HubMIB, is there already a newer version > available?? If yes, > can you share it with us?? > Additionally I came across some questions, especailly management > issues when I was reviewing draft 3.0. On clause 30 I have > the following > questions: > Clause 30.12.1.1.3 page 71, line 15: The value 'no PMEAssigned' > > Does it mean that the physical layer is not up or does it > mean that the PME > Aggregation register has just 1 bit set with the PAF enable > bit not set (no > PAF) or does it relate to something else? > > Clause 30.12.1.1.3 page 71, line 15: The value 'noPeerPMEPresent'' > > Again, it is not clear to what condition this releates to, is > it that the > physical link is not up, that the remot TC is not > synchronized or is it > intended to use some PMD parameter or is it the result of the > discovery > phase, saying there is no link to be aggergatable with the > selected one?? > > In general I still think there are some Clause 30 parameter > missing if I > want to bring up and manage an entire session using Clause > 30. From my point > of view i.e. the entire discovery phase seems to me somehow hidden to > Clause 30. > May be I just miss some parts of the entire picture. So my question is > whether there is kind of an overview/flow chart or something > similar showing > how to bringing up/manage an EFM connection using Clause 30. > > Thank you for your help! > > Regards > Mathias > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Mar 2 14:48:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26715 for ; Tue, 2 Mar 2004 14:48: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 1AyFs1-0000ED-S6 for hubmib-archive@odin.ietf.org; Tue, 02 Mar 2004 14:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22Jm1Ea000863 for hubmib-archive@odin.ietf.org; Tue, 2 Mar 2004 14:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFs1-0000Dh-BX; Tue, 02 Mar 2004 14:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyFrm-0000D6-Rm for hubmib@optimus.ietf.org; Tue, 02 Mar 2004 14:47:49 -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 OAA26688 for ; Tue, 2 Mar 2004 14:47:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyFrk-0003Tt-00 for hubmib@ietf.org; Tue, 02 Mar 2004 14:47:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyFql-0003Mn-00 for hubmib@ietf.org; Tue, 02 Mar 2004 14:46:44 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1AyFpr-00039F-00 for hubmib@ietf.org; Tue, 02 Mar 2004 14:45:48 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 21:51:40 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF274211A@il-mail02.actelis.net> From: Edward Beili To: "'mathias.riess@infineon.com'" Cc: hubmib@ietf.org, "'Romascanu, Dan (Dan)'" , "'David Law'" Date: Tue, 2 Mar 2004 21:51:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Hubmib] RE: More EFM - Clause 30 Management Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Mathias, The latest officially published version is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt from Jan 15th. I'm currently working on an update, nothing major yet, so you can safely use the version above. noPMEAssigned means that PAF is enabled but Aggregation register is all zeros (no modems assigned). Currently there's no limitation in the text that you have to have at least 1 bit set in the Aggregation. May we should add that in. noPeerPMEPresent means that there was no answer during handshake initialization (as far as I understand it). It could also mean that the modem on the other end physically exists but was excluded from the aggregation as a result of Discovery (i.e. belongs to a different CPE already taken by another CO). You are correct that there's no exact definition in the draft. I'm personally not concerned very much about Clause 30 as I discovered during my work on the MIB that it is acceptable to reference Clause 45 registers if there is no substitute in clause 30. As you may notice from the last published version of the MIB above, I almost exclusively referred to Clause 45 registers. However if you take that "optional" nature of Clause 45 to the extreme than yes, we need all MIB objects reference Clause 30 objects (clause 30 is mandatory). I've added David Law, Dan Romascanu and HUBMIB group in Cc: as I find your comments important. Hope it's OK with you. Regards, -E. > -----Original Message----- > From: mathias.riess@infineon.com [mailto:mathias.riess@infineon.com] > Sent: Tuesday, March 02, 2004 07:52 PM > To: Edward Beili > Subject: More EFM - Clause 30 Management > > > Hi Edward, > at the end of the last meeting in Vancouver, you sent > out an updated > version of the HubMIB, is there already a newer version > available?? If yes, > can you share it with us?? > Additionally I came across some questions, especailly management > issues when I was reviewing draft 3.0. On clause 30 I have > the following > questions: > Clause 30.12.1.1.3 page 71, line 15: The value 'no PMEAssigned' > > Does it mean that the physical layer is not up or does it > mean that the PME > Aggregation register has just 1 bit set with the PAF enable > bit not set (no > PAF) or does it relate to something else? > > Clause 30.12.1.1.3 page 71, line 15: The value 'noPeerPMEPresent'' > > Again, it is not clear to what condition this releates to, is > it that the > physical link is not up, that the remot TC is not > synchronized or is it > intended to use some PMD parameter or is it the result of the > discovery > phase, saying there is no link to be aggergatable with the > selected one?? > > In general I still think there are some Clause 30 parameter > missing if I > want to bring up and manage an entire session using Clause > 30. From my point > of view i.e. the entire discovery phase seems to me somehow hidden to > Clause 30. > May be I just miss some parts of the entire picture. So my question is > whether there is kind of an overview/flow chart or something > similar showing > how to bringing up/manage an EFM connection using Clause 30. > > Thank you for your help! > > Regards > Mathias > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Mar 3 15:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22264 for ; Wed, 3 Mar 2004 15: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 1Aycc1-0001hs-Gv; Wed, 03 Mar 2004 15:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayb2r-0004jx-Vx for hubmib@optimus.ietf.org; Wed, 03 Mar 2004 13:24:38 -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 NAA16070 for ; Wed, 3 Mar 2004 13:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayb2q-0005bq-00 for hubmib@ietf.org; Wed, 03 Mar 2004 13:24:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayb1s-0005SD-00 for hubmib@ietf.org; Wed, 03 Mar 2004 13:23:37 -0500 Received: from columba.eur.3com.com ([161.71.171.238]) by ietf-mx with esmtp (Exim 4.12) id 1Ayb0x-0005J6-00 for hubmib@ietf.org; Wed, 03 Mar 2004 13:22:40 -0500 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com with ESMTP id i23IO5s02581; Wed, 3 Mar 2004 18:24:05 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id i23IPgEG009943; Wed, 3 Mar 2004 18:25:42 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256E4C.0064EFB9 ; Wed, 3 Mar 2004 18:22:29 +0000 X-Lotus-FromDomain: 3COM From: "David Law" To: Edward Beili cc: "'mathias.riess@infineon.com'" , hubmib@ietf.org, "'Romascanu, Dan (Dan)'" Message-ID: <80256E4C.0064ED50.00@notesmta.eur.3com.com> Date: Wed, 3 Mar 2004 18:29:59 +0000 Subject: Re: [Hubmib] RE: More EFM - Clause 30 Management Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ed, Thanks very much for bringing these comments to my attention - have you submitted them as comments against Clause 30 or would you like me to do so. In respect to you other questions, as I'm sure you know, I agree that you have to reference Clause 45 directly where it is not possible to for you reference Clause 30. As you correctly state Clause 45 is indeed optional and that is why when you read Clause 30 you will see that we have text that specifies the behaviour of the attribute stand alone and then text that say that if a Clause 45 interface is available the attribute maps to some particular register. Ultimately of course even if a vendor chooses not to implement Clause 45 itself it is likely that they will instead implement similar register though accessed by a different mechanism - I think we even recommend that in Clause 45. The only slight concern I have is this - the Clause 45 registers and the Clause 30 behaviours should match and as they are both under the auspices of the IEEE-SA balloting we all work to ensure they do by the time the standard is published. Hence ultimately there should be no difference between referencing Clause 45 or Clause 30 in the case where a Clause 30 attribute to reference to exists - so if you are saying there is problem with a Clause 30 attribute somewhere and are therefore referencing Clause 45 instead you are running the risk that we change the Clause 45 register to match Clause 30 and pull the rug from under your Clause 45 reference. Remember that in IEEE 802.3 Clause 30 is the Management Clause and it might therefore seem a reasonable course of action to change the optional Clause 45 management register in the case of a difference between the two. Now to be fair I doubt this would actually happen as we all continue to work successfully together to make sure it doesn't - this however is why I express a preference to a Clause 30 reference if possible. So to summarise untimely what I personally would like to see is the IETF MIB, Clause 30 and Clause 45 all to be in harmony. And of course in the case where you wish to add additional attributes above and beyond what we have in Clause 30 all we need to do is ensure the IETF MIB and Clause 45 are in harmony. Best regards, David Law Edward Beili @ietf.org on 02/03/2004 19:51:32 Sent by: hubmib-admin@ietf.org To: "'mathias.riess @infineon.com'" cc: hubmib@ietf.org, "'Romascanu, Dan , David Law/GB/3Com@3Com Subject: [Hubmib] RE: More EFM - Clause 30 Management Hi Mathias, The latest officially published version is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt from Jan 15th. I'm currently working on an update, nothing major yet, so you can safely use the version above. noPMEAssigned means that PAF is enabled but Aggregation register is all zeros (no modems assigned). Currently there's no limitation in the text that you have to have at least 1 bit set in the Aggregation. May we should add that in. noPeerPMEPresent means that there was no answer during handshake initialization (as far as I understand it). It could also mean that the modem on the other end physically exists but was excluded from the aggregation as a result of Discovery (i.e. belongs to a different CPE already taken by another CO). You are correct that there's no exact definition in the draft. I'm personally not concerned very much about Clause 30 as I discovered during my work on the MIB that it is acceptable to reference Clause 45 registers if there is no substitute in clause 30. As you may notice from the last published version of the MIB above, I almost exclusively referred to Clause 45 registers. However if you take that "optional" nature of Clause 45 to the extreme than yes, we need all MIB objects reference Clause 30 objects (clause 30 is mandatory). I've added David Law, Dan Romascanu and HUBMIB group in Cc: as I find your comments important. Hope it's OK with you. Regards, -E. > -----Original Message----- > From: mathias.riess@infineon.com [mailto:mathias.riess@infineon.com] > Sent: Tuesday, March 02, 2004 07:52 PM > To: Edward Beili > Subject: More EFM - Clause 30 Management > > > Hi Edward, > at the end of the last meeting in Vancouver, you sent > out an updated > version of the HubMIB, is there already a newer version > available?? If yes, > can you share it with us?? > Additionally I came across some questions, especailly management > issues when I was reviewing draft 3.0. On clause 30 I have > the following > questions: > Clause 30.12.1.1.3 page 71, line 15: The value 'no PMEAssigned' > > Does it mean that the physical layer is not up or does it > mean that the PME > Aggregation register has just 1 bit set with the PAF enable > bit not set (no > PAF) or does it relate to something else? > > Clause 30.12.1.1.3 page 71, line 15: The value 'noPeerPMEPresent'' > > Again, it is not clear to what condition this releates to, is > it that the > physical link is not up, that the remot TC is not > synchronized or is it > intended to use some PMD parameter or is it the result of the > discovery > phase, saying there is no link to be aggergatable with the > selected one?? > > In general I still think there are some Clause 30 parameter > missing if I > want to bring up and manage an entire session using Clause > 30. From my point > of view i.e. the entire discovery phase seems to me somehow hidden to > Clause 30. > May be I just miss some parts of the entire picture. So my question is > whether there is kind of an overview/flow chart or something > similar showing > how to bringing up/manage an EFM connection using Clause 30. > > Thank you for your help! > > Regards > Mathias > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Wed Mar 3 15:05:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22268 for ; Wed, 3 Mar 2004 15: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 1Aycc2-0001iG-GH for hubmib-archive@odin.ietf.org; Wed, 03 Mar 2004 15:05:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23K52xI006582 for hubmib-archive@odin.ietf.org; Wed, 3 Mar 2004 15:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aycc1-0001hs-Gv; Wed, 03 Mar 2004 15:05:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayb2r-0004jx-Vx for hubmib@optimus.ietf.org; Wed, 03 Mar 2004 13:24:38 -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 NAA16070 for ; Wed, 3 Mar 2004 13:24:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayb2q-0005bq-00 for hubmib@ietf.org; Wed, 03 Mar 2004 13:24:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayb1s-0005SD-00 for hubmib@ietf.org; Wed, 03 Mar 2004 13:23:37 -0500 Received: from columba.eur.3com.com ([161.71.171.238]) by ietf-mx with esmtp (Exim 4.12) id 1Ayb0x-0005J6-00 for hubmib@ietf.org; Wed, 03 Mar 2004 13:22:40 -0500 Received: from toucana.eur.3com.com (eurelay.eur.3com.com [140.204.220.50]) by columba.eur.3com.com with ESMTP id i23IO5s02581; Wed, 3 Mar 2004 18:24:05 GMT Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206]) by toucana.eur.3com.com with SMTP id i23IPgEG009943; Wed, 3 Mar 2004 18:25:42 GMT Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 80256E4C.0064EFB9 ; Wed, 3 Mar 2004 18:22:29 +0000 X-Lotus-FromDomain: 3COM From: "David Law" To: Edward Beili cc: "'mathias.riess@infineon.com'" , hubmib@ietf.org, "'Romascanu, Dan (Dan)'" Message-ID: <80256E4C.0064ED50.00@notesmta.eur.3com.com> Date: Wed, 3 Mar 2004 18:29:59 +0000 Subject: Re: [Hubmib] RE: More EFM - Clause 30 Management Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline 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: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi Ed, Thanks very much for bringing these comments to my attention - have you submitted them as comments against Clause 30 or would you like me to do so. In respect to you other questions, as I'm sure you know, I agree that you have to reference Clause 45 directly where it is not possible to for you reference Clause 30. As you correctly state Clause 45 is indeed optional and that is why when you read Clause 30 you will see that we have text that specifies the behaviour of the attribute stand alone and then text that say that if a Clause 45 interface is available the attribute maps to some particular register. Ultimately of course even if a vendor chooses not to implement Clause 45 itself it is likely that they will instead implement similar register though accessed by a different mechanism - I think we even recommend that in Clause 45. The only slight concern I have is this - the Clause 45 registers and the Clause 30 behaviours should match and as they are both under the auspices of the IEEE-SA balloting we all work to ensure they do by the time the standard is published. Hence ultimately there should be no difference between referencing Clause 45 or Clause 30 in the case where a Clause 30 attribute to reference to exists - so if you are saying there is problem with a Clause 30 attribute somewhere and are therefore referencing Clause 45 instead you are running the risk that we change the Clause 45 register to match Clause 30 and pull the rug from under your Clause 45 reference. Remember that in IEEE 802.3 Clause 30 is the Management Clause and it might therefore seem a reasonable course of action to change the optional Clause 45 management register in the case of a difference between the two. Now to be fair I doubt this would actually happen as we all continue to work successfully together to make sure it doesn't - this however is why I express a preference to a Clause 30 reference if possible. So to summarise untimely what I personally would like to see is the IETF MIB, Clause 30 and Clause 45 all to be in harmony. And of course in the case where you wish to add additional attributes above and beyond what we have in Clause 30 all we need to do is ensure the IETF MIB and Clause 45 are in harmony. Best regards, David Law Edward Beili @ietf.org on 02/03/2004 19:51:32 Sent by: hubmib-admin@ietf.org To: "'mathias.riess @infineon.com'" cc: hubmib@ietf.org, "'Romascanu, Dan , David Law/GB/3Com@3Com Subject: [Hubmib] RE: More EFM - Clause 30 Management Hi Mathias, The latest officially published version is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt from Jan 15th. I'm currently working on an update, nothing major yet, so you can safely use the version above. noPMEAssigned means that PAF is enabled but Aggregation register is all zeros (no modems assigned). Currently there's no limitation in the text that you have to have at least 1 bit set in the Aggregation. May we should add that in. noPeerPMEPresent means that there was no answer during handshake initialization (as far as I understand it). It could also mean that the modem on the other end physically exists but was excluded from the aggregation as a result of Discovery (i.e. belongs to a different CPE already taken by another CO). You are correct that there's no exact definition in the draft. I'm personally not concerned very much about Clause 30 as I discovered during my work on the MIB that it is acceptable to reference Clause 45 registers if there is no substitute in clause 30. As you may notice from the last published version of the MIB above, I almost exclusively referred to Clause 45 registers. However if you take that "optional" nature of Clause 45 to the extreme than yes, we need all MIB objects reference Clause 30 objects (clause 30 is mandatory). I've added David Law, Dan Romascanu and HUBMIB group in Cc: as I find your comments important. Hope it's OK with you. Regards, -E. > -----Original Message----- > From: mathias.riess@infineon.com [mailto:mathias.riess@infineon.com] > Sent: Tuesday, March 02, 2004 07:52 PM > To: Edward Beili > Subject: More EFM - Clause 30 Management > > > Hi Edward, > at the end of the last meeting in Vancouver, you sent > out an updated > version of the HubMIB, is there already a newer version > available?? If yes, > can you share it with us?? > Additionally I came across some questions, especailly management > issues when I was reviewing draft 3.0. On clause 30 I have > the following > questions: > Clause 30.12.1.1.3 page 71, line 15: The value 'no PMEAssigned' > > Does it mean that the physical layer is not up or does it > mean that the PME > Aggregation register has just 1 bit set with the PAF enable > bit not set (no > PAF) or does it relate to something else? > > Clause 30.12.1.1.3 page 71, line 15: The value 'noPeerPMEPresent'' > > Again, it is not clear to what condition this releates to, is > it that the > physical link is not up, that the remot TC is not > synchronized or is it > intended to use some PMD parameter or is it the result of the > discovery > phase, saying there is no link to be aggergatable with the > selected one?? > > In general I still think there are some Clause 30 parameter > missing if I > want to bring up and manage an entire session using Clause > 30. From my point > of view i.e. the entire discovery phase seems to me somehow hidden to > Clause 30. > May be I just miss some parts of the entire picture. So my question is > whether there is kind of an overview/flow chart or something > similar showing > how to bringing up/manage an EFM connection using Clause 30. > > Thank you for your help! > > Regards > Mathias > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Wed Mar 3 15:35:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25150 for ; Wed, 3 Mar 2004 15:35: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 1Ayd55-0000he-Hc for hubmib-archive@odin.ietf.org; Wed, 03 Mar 2004 15:35:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23KZ3EM002702 for hubmib-archive@odin.ietf.org; Wed, 3 Mar 2004 15:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayd55-0000hO-6l; Wed, 03 Mar 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayd4o-0000eV-TQ for hubmib@optimus.ietf.org; Wed, 03 Mar 2004 15:34:46 -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 PAA25108 for ; Wed, 3 Mar 2004 15:34:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayd4n-0007TQ-00 for hubmib@ietf.org; Wed, 03 Mar 2004 15:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayd3p-0007Jb-00 for hubmib@ietf.org; Wed, 03 Mar 2004 15:33:46 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1Ayd2x-00070T-00 for hubmib@ietf.org; Wed, 03 Mar 2004 15:32:51 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 22:38:39 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF274212D@il-mail02.actelis.net> From: Edward Beili To: "'David Law '" Cc: "''mathias.riess@infineon.com' '" , "'hubmib@ietf.org '" , "''Romascanu, Dan (Dan)' '" Subject: RE: [Hubmib] RE: More EFM - Clause 30 Management Date: Wed, 3 Mar 2004 22:38:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , David, I didn't mean to put clause 30 down, in fact it has improved tremendously in D3.1 and I am planning to change all the appropriate references in the MIB to clause 30 objects. While we are at clause 30, there are 2 comments I was about to submit (I just realized that today is the dead line). I would appreciate your opinion: #: 7 Type: TR Clause: 30 Subclause: 30.2.2.1 Page: 33 Line: 39 Comment: oTC is described as providing PME Aggregation Function (PAF), while 61.1.4.1.3 states that "The PAF is located in the PCS, between the MAC-PHY Rate Matching function and the TC sublayer." Suggested Remedy: Replace oTC definition with the following: "oPAF - The oPAF managed object class provides the management controls necessary for PME Aggregation Function sublayer to be managed." Replace "oTC" with "oPAF" in the definition of oPME (page 33, line 7). Replace "oTC" with "oPAF" in Figure 30-3 and in Table 30-5. #: 8 Type: TR Clause: 30 Subclause: 30.2.5 Page: 40 Line: 44 Comment: PME Aggregation Capability is set as Mandatory. oPME attributes (e.g. PMESNRMgn) are shown to be a part of PME Aggregation Capability while clearly they are not and should be a part of 10P/2B capability. Suggested Remedy: Add 10P/2B Package (Conditional). Make aPhyEnd, aPhyCurrentStatus, aPAFSupported, aRemotePAFSupported and all attributes of oPME to be part of the 10P/2B Package. Replace "PME Aggregation Capability (Mandatory)" with "PME Aggregation Package (Optional)". Put the rest of the oPAF (see my comment 7) attributes there. Regards, -Edward -----Original Message----- From: David Law To: Edward Beili Cc: 'mathias.riess@infineon.com'; hubmib@ietf.org; 'Romascanu, Dan (Dan)' Sent: 03/03/04 20:29 Subject: Re: [Hubmib] RE: More EFM - Clause 30 Management Hi Ed, Thanks very much for bringing these comments to my attention - have you submitted them as comments against Clause 30 or would you like me to do so. In respect to you other questions, as I'm sure you know, I agree that you have to reference Clause 45 directly where it is not possible to for you reference Clause 30. As you correctly state Clause 45 is indeed optional and that is why when you read Clause 30 you will see that we have text that specifies the behaviour of the attribute stand alone and then text that say that if a Clause 45 interface is available the attribute maps to some particular register. Ultimately of course even if a vendor chooses not to implement Clause 45 itself it is likely that they will instead implement similar register though accessed by a different mechanism - I think we even recommend that in Clause 45. The only slight concern I have is this - the Clause 45 registers and the Clause 30 behaviours should match and as they are both under the auspices of the IEEE-SA balloting we all work to ensure they do by the time the standard is published. Hence ultimately there should be no difference between referencing Clause 45 or Clause 30 in the case where a Clause 30 attribute to reference to exists - so if you are saying there is problem with a Clause 30 attribute somewhere and are therefore referencing Clause 45 instead you are running the risk that we change the Clause 45 register to match Clause 30 and pull the rug from under your Clause 45 reference. Remember that in IEEE 802.3 Clause 30 is the Management Clause and it might therefore seem a reasonable course of action to change the optional Clause 45 management register in the case of a difference between the two. Now to be fair I doubt this would actually happen as we all continue to work successfully together to make sure it doesn't - this however is why I express a preference to a Clause 30 reference if possible. So to summarise untimely what I personally would like to see is the IETF MIB, Clause 30 and Clause 45 all to be in harmony. And of course in the case where you wish to add additional attributes above and beyond what we have in Clause 30 all we need to do is ensure the IETF MIB and Clause 45 are in harmony. Best regards, David Law Edward Beili @ietf.org on 02/03/2004 19:51:32 Sent by: hubmib-admin@ietf.org To: "'mathias.riess @infineon.com'" cc: hubmib@ietf.org, "'Romascanu, Dan , David Law/GB/3Com@3Com Subject: [Hubmib] RE: More EFM - Clause 30 Management Hi Mathias, The latest officially published version is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt from Jan 15th. I'm currently working on an update, nothing major yet, so you can safely use the version above. noPMEAssigned means that PAF is enabled but Aggregation register is all zeros (no modems assigned). Currently there's no limitation in the text that you have to have at least 1 bit set in the Aggregation. May we should add that in. noPeerPMEPresent means that there was no answer during handshake initialization (as far as I understand it). It could also mean that the modem on the other end physically exists but was excluded from the aggregation as a result of Discovery (i.e. belongs to a different CPE already taken by another CO). You are correct that there's no exact definition in the draft. I'm personally not concerned very much about Clause 30 as I discovered during my work on the MIB that it is acceptable to reference Clause 45 registers if there is no substitute in clause 30. As you may notice from the last published version of the MIB above, I almost exclusively referred to Clause 45 registers. However if you take that "optional" nature of Clause 45 to the extreme than yes, we need all MIB objects reference Clause 30 objects (clause 30 is mandatory). I've added David Law, Dan Romascanu and HUBMIB group in Cc: as I find your comments important. Hope it's OK with you. Regards, -E. > -----Original Message----- > From: mathias.riess@infineon.com [mailto:mathias.riess@infineon.com] > Sent: Tuesday, March 02, 2004 07:52 PM > To: Edward Beili > Subject: More EFM - Clause 30 Management > > > Hi Edward, > at the end of the last meeting in Vancouver, you sent > out an updated > version of the HubMIB, is there already a newer version > available?? If yes, > can you share it with us?? > Additionally I came across some questions, especailly management > issues when I was reviewing draft 3.0. On clause 30 I have > the following > questions: > Clause 30.12.1.1.3 page 71, line 15: The value 'no PMEAssigned' > > Does it mean that the physical layer is not up or does it > mean that the PME > Aggregation register has just 1 bit set with the PAF enable > bit not set (no > PAF) or does it relate to something else? > > Clause 30.12.1.1.3 page 71, line 15: The value 'noPeerPMEPresent'' > > Again, it is not clear to what condition this releates to, is > it that the > physical link is not up, that the remot TC is not > synchronized or is it > intended to use some PMD parameter or is it the result of the > discovery > phase, saying there is no link to be aggergatable with the > selected one?? > > In general I still think there are some Clause 30 parameter > missing if I > want to bring up and manage an entire session using Clause > 30. From my point > of view i.e. the entire discovery phase seems to me somehow hidden to > Clause 30. > May be I just miss some parts of the entire picture. So my question is > whether there is kind of an overview/flow chart or something > similar showing > how to bringing up/manage an EFM connection using Clause 30. > > Thank you for your help! > > Regards > Mathias > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Mar 3 16:24:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25149 for ; Wed, 3 Mar 2004 15:35: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 1Ayd55-0000hO-6l; Wed, 03 Mar 2004 15:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayd4o-0000eV-TQ for hubmib@optimus.ietf.org; Wed, 03 Mar 2004 15:34:46 -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 PAA25108 for ; Wed, 3 Mar 2004 15:34:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayd4n-0007TQ-00 for hubmib@ietf.org; Wed, 03 Mar 2004 15:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayd3p-0007Jb-00 for hubmib@ietf.org; Wed, 03 Mar 2004 15:33:46 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1Ayd2x-00070T-00 for hubmib@ietf.org; Wed, 03 Mar 2004 15:32:51 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Mar 2004 22:38:39 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF274212D@il-mail02.actelis.net> From: Edward Beili To: "'David Law '" Cc: "''mathias.riess@infineon.com' '" , "'hubmib@ietf.org '" , "''Romascanu, Dan (Dan)' '" Subject: RE: [Hubmib] RE: More EFM - Clause 30 Management Date: Wed, 3 Mar 2004 22:38:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , David, I didn't mean to put clause 30 down, in fact it has improved tremendously in D3.1 and I am planning to change all the appropriate references in the MIB to clause 30 objects. While we are at clause 30, there are 2 comments I was about to submit (I just realized that today is the dead line). I would appreciate your opinion: #: 7 Type: TR Clause: 30 Subclause: 30.2.2.1 Page: 33 Line: 39 Comment: oTC is described as providing PME Aggregation Function (PAF), while 61.1.4.1.3 states that "The PAF is located in the PCS, between the MAC-PHY Rate Matching function and the TC sublayer." Suggested Remedy: Replace oTC definition with the following: "oPAF - The oPAF managed object class provides the management controls necessary for PME Aggregation Function sublayer to be managed." Replace "oTC" with "oPAF" in the definition of oPME (page 33, line 7). Replace "oTC" with "oPAF" in Figure 30-3 and in Table 30-5. #: 8 Type: TR Clause: 30 Subclause: 30.2.5 Page: 40 Line: 44 Comment: PME Aggregation Capability is set as Mandatory. oPME attributes (e.g. PMESNRMgn) are shown to be a part of PME Aggregation Capability while clearly they are not and should be a part of 10P/2B capability. Suggested Remedy: Add 10P/2B Package (Conditional). Make aPhyEnd, aPhyCurrentStatus, aPAFSupported, aRemotePAFSupported and all attributes of oPME to be part of the 10P/2B Package. Replace "PME Aggregation Capability (Mandatory)" with "PME Aggregation Package (Optional)". Put the rest of the oPAF (see my comment 7) attributes there. Regards, -Edward -----Original Message----- From: David Law To: Edward Beili Cc: 'mathias.riess@infineon.com'; hubmib@ietf.org; 'Romascanu, Dan (Dan)' Sent: 03/03/04 20:29 Subject: Re: [Hubmib] RE: More EFM - Clause 30 Management Hi Ed, Thanks very much for bringing these comments to my attention - have you submitted them as comments against Clause 30 or would you like me to do so. In respect to you other questions, as I'm sure you know, I agree that you have to reference Clause 45 directly where it is not possible to for you reference Clause 30. As you correctly state Clause 45 is indeed optional and that is why when you read Clause 30 you will see that we have text that specifies the behaviour of the attribute stand alone and then text that say that if a Clause 45 interface is available the attribute maps to some particular register. Ultimately of course even if a vendor chooses not to implement Clause 45 itself it is likely that they will instead implement similar register though accessed by a different mechanism - I think we even recommend that in Clause 45. The only slight concern I have is this - the Clause 45 registers and the Clause 30 behaviours should match and as they are both under the auspices of the IEEE-SA balloting we all work to ensure they do by the time the standard is published. Hence ultimately there should be no difference between referencing Clause 45 or Clause 30 in the case where a Clause 30 attribute to reference to exists - so if you are saying there is problem with a Clause 30 attribute somewhere and are therefore referencing Clause 45 instead you are running the risk that we change the Clause 45 register to match Clause 30 and pull the rug from under your Clause 45 reference. Remember that in IEEE 802.3 Clause 30 is the Management Clause and it might therefore seem a reasonable course of action to change the optional Clause 45 management register in the case of a difference between the two. Now to be fair I doubt this would actually happen as we all continue to work successfully together to make sure it doesn't - this however is why I express a preference to a Clause 30 reference if possible. So to summarise untimely what I personally would like to see is the IETF MIB, Clause 30 and Clause 45 all to be in harmony. And of course in the case where you wish to add additional attributes above and beyond what we have in Clause 30 all we need to do is ensure the IETF MIB and Clause 45 are in harmony. Best regards, David Law Edward Beili @ietf.org on 02/03/2004 19:51:32 Sent by: hubmib-admin@ietf.org To: "'mathias.riess @infineon.com'" cc: hubmib@ietf.org, "'Romascanu, Dan , David Law/GB/3Com@3Com Subject: [Hubmib] RE: More EFM - Clause 30 Management Hi Mathias, The latest officially published version is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt from Jan 15th. I'm currently working on an update, nothing major yet, so you can safely use the version above. noPMEAssigned means that PAF is enabled but Aggregation register is all zeros (no modems assigned). Currently there's no limitation in the text that you have to have at least 1 bit set in the Aggregation. May we should add that in. noPeerPMEPresent means that there was no answer during handshake initialization (as far as I understand it). It could also mean that the modem on the other end physically exists but was excluded from the aggregation as a result of Discovery (i.e. belongs to a different CPE already taken by another CO). You are correct that there's no exact definition in the draft. I'm personally not concerned very much about Clause 30 as I discovered during my work on the MIB that it is acceptable to reference Clause 45 registers if there is no substitute in clause 30. As you may notice from the last published version of the MIB above, I almost exclusively referred to Clause 45 registers. However if you take that "optional" nature of Clause 45 to the extreme than yes, we need all MIB objects reference Clause 30 objects (clause 30 is mandatory). I've added David Law, Dan Romascanu and HUBMIB group in Cc: as I find your comments important. Hope it's OK with you. Regards, -E. > -----Original Message----- > From: mathias.riess@infineon.com [mailto:mathias.riess@infineon.com] > Sent: Tuesday, March 02, 2004 07:52 PM > To: Edward Beili > Subject: More EFM - Clause 30 Management > > > Hi Edward, > at the end of the last meeting in Vancouver, you sent > out an updated > version of the HubMIB, is there already a newer version > available?? If yes, > can you share it with us?? > Additionally I came across some questions, especailly management > issues when I was reviewing draft 3.0. On clause 30 I have > the following > questions: > Clause 30.12.1.1.3 page 71, line 15: The value 'no PMEAssigned' > > Does it mean that the physical layer is not up or does it > mean that the PME > Aggregation register has just 1 bit set with the PAF enable > bit not set (no > PAF) or does it relate to something else? > > Clause 30.12.1.1.3 page 71, line 15: The value 'noPeerPMEPresent'' > > Again, it is not clear to what condition this releates to, is > it that the > physical link is not up, that the remot TC is not > synchronized or is it > intended to use some PMD parameter or is it the result of the > discovery > phase, saying there is no link to be aggergatable with the > selected one?? > > In general I still think there are some Clause 30 parameter > missing if I > want to bring up and manage an entire session using Clause > 30. From my point > of view i.e. the entire discovery phase seems to me somehow hidden to > Clause 30. > May be I just miss some parts of the entire picture. So my question is > whether there is kind of an overview/flow chart or something > similar showing > how to bringing up/manage an EFM connection using Clause 30. > > Thank you for your help! > > Regards > Mathias > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Mar 3 23:43:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26490 for ; Wed, 3 Mar 2004 23:43: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 1AykhJ-0006VL-B4; Wed, 03 Mar 2004 23:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykgs-0006Jt-BU for hubmib@optimus.ietf.org; Wed, 03 Mar 2004 23:42:34 -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 XAA26427 for ; Wed, 3 Mar 2004 23:42:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykgp-00061K-00 for hubmib@ietf.org; Wed, 03 Mar 2004 23:42:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aykff-0005jQ-00 for hubmib@ietf.org; Wed, 03 Mar 2004 23:41:20 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Aykea-0005Lu-00 for hubmib@ietf.org; Wed, 03 Mar 2004 23:40:12 -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 i244dFs2029240 for ; Wed, 3 Mar 2004 23:39:15 -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 i244dDs2029225 for ; Wed, 3 Mar 2004 23:39:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C401A2.C6B8F1EA" Date: Thu, 4 Mar 2004 06:40:10 +0200 Message-ID: Thread-Topic: hubmib meeting at ietf 59 Thread-Index: AcQBosSw3p2DbjABSpeHHGdLkDfwxQ== From: "Romascanu, Dan (Dan)" To: , "David Kessens" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] hubmib meeting at ietf 59 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C401A2.C6B8F1EA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The Ethernet Interfaces and Hub MIB WG hold one session at the 59th IETF = meeting. About 20 people participated. The WG reviewed the changes and = open issues in the three Internet-Drafts covering the current charter of = the WG, related to the Ethernet First Mile (EFM) a.k.a. IEEE 802.3ah = technology. Recommendations concerning the edits and changes for the = next version of the Internet-Drafts were made during the meeting, and = will be included in the detailed WG minutes. The next round of = Internet-Drafts is expected to be submitted in the six weeks following = the meeting, and if they are stable enough these Internet-Drafts will go = through WG Last Call immediately after publication. Regards, Dan ------_=_NextPart_001_01C401A2.C6B8F1EA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable hubmib meeting at ietf 59

The Ethernet Interfaces and = Hub MIB WG hold one session at the 59th IETF meeting. About 20 people = participated. The WG reviewed the changes and open issues in the three = Internet-Drafts covering the current charter of the WG, related to the = Ethernet First Mile (EFM) a.k.a. IEEE 802.3ah technology. = Recommendations concerning the edits and changes for the next version of = the Internet-Drafts were made during the meeting, and will be included = in the detailed WG minutes. The next round of Internet-Drafts is = expected to be submitted in the six weeks following the meeting, and if = they are stable enough these Internet-Drafts will go through WG Last = Call immediately after publication.

Regards,

Dan

------_=_NextPart_001_01C401A2.C6B8F1EA-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Mar 4 00:58:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02153 for ; Thu, 4 Mar 2004 00: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 1Aylrt-0007rC-3h; Thu, 04 Mar 2004 00:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylr6-0007qD-0h for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 00:57: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 AAA02095 for ; Thu, 4 Mar 2004 00:57:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylr3-0005UK-00 for hubmib@ietf.org; Thu, 04 Mar 2004 00:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylqB-0005Ku-00 for hubmib@ietf.org; Thu, 04 Mar 2004 00:56:15 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AylpU-00053N-00 for hubmib@ietf.org; Thu, 04 Mar 2004 00:55:32 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i245sxc06392 for ; Wed, 3 Mar 2004 23:55:00 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699LW7S>; Thu, 4 Mar 2004 06:54:58 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B6465A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , bwijnen@lucent.com, David Kessens Cc: hubmib@ietf.org Date: Thu, 4 Mar 2004 06:54:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C401AD.397BE58C" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] RE: hubmib meeting at ietf 59 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C401AD.397BE58C Content-Type: text/plain; charset="windows-1255" Thanks Dan, Bert ------_=_NextPart_001_01C401AD.397BE58C Content-Type: text/html; charset="windows-1255" hubmib meeting at ietf 59
Thanks Dan,
Bert
------_=_NextPart_001_01C401AD.397BE58C-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Mar 4 00:58:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02155 for ; Thu, 4 Mar 2004 00: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 1Aylrt-0007rl-Dz for hubmib-archive@odin.ietf.org; Thu, 04 Mar 2004 00:58:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i245w1PN030217 for hubmib-archive@odin.ietf.org; Thu, 4 Mar 2004 00:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylrt-0007rC-3h; Thu, 04 Mar 2004 00:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylr6-0007qD-0h for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 00:57: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 AAA02095 for ; Thu, 4 Mar 2004 00:57:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylr3-0005UK-00 for hubmib@ietf.org; Thu, 04 Mar 2004 00:57:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylqB-0005Ku-00 for hubmib@ietf.org; Thu, 04 Mar 2004 00:56:15 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AylpU-00053N-00 for hubmib@ietf.org; Thu, 04 Mar 2004 00:55:32 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i245sxc06392 for ; Wed, 3 Mar 2004 23:55:00 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699LW7S>; Thu, 4 Mar 2004 06:54:58 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B6465A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , bwijnen@lucent.com, David Kessens Cc: hubmib@ietf.org Date: Thu, 4 Mar 2004 06:54:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C401AD.397BE58C" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] RE: hubmib meeting at ietf 59 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C401AD.397BE58C Content-Type: text/plain; charset="windows-1255" Thanks Dan, Bert ------_=_NextPart_001_01C401AD.397BE58C Content-Type: text/html; charset="windows-1255" hubmib meeting at ietf 59
Thanks Dan,
Bert
------_=_NextPart_001_01C401AD.397BE58C-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Mar 4 09:15:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20949 for ; Thu, 4 Mar 2004 09:15: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 1Aytct-0000nh-Fi; Thu, 04 Mar 2004 09:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AytcY-0000mV-RT for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 09:14: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 JAA20857 for ; Thu, 4 Mar 2004 09:14:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AytcX-0006DJ-00 for hubmib@ietf.org; Thu, 04 Mar 2004 09:14:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AytbN-0005m9-00 for hubmib@ietf.org; Thu, 04 Mar 2004 09:13:30 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AytZl-0005FE-00; Thu, 04 Mar 2004 09:11:49 -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 i24EAps2014234; Thu, 4 Mar 2004 09:10:51 -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 i24EAns2014195; Thu, 4 Mar 2004 09:10:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C401F2.A0CC0A38" Date: Thu, 4 Mar 2004 16:11:46 +0200 Message-ID: Thread-Topic: hubmib minutes Thread-Index: AcQB8p5nXhTxG5SjSGegMRu8g7NlOA== From: "Romascanu, Dan (Dan)" To: Cc: , "Shailaja Yadawad" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] hubmib minutes Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C401F2.A0CC0A38 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C401F2.A0CC0A38" ------_=_NextPart_002_01C401F2.A0CC0A38 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please find attached the minutes of the Ethernet Interfaces and Hub MIB = WG meeting hold at the 59th IETF. Thanks to Shailaja Yadawad for = volunteering to be the minutes taker during the meeting. Regards, Dan <>=20 ------_=_NextPart_002_01C401F2.A0CC0A38 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable hubmib minutes

Please find attached the = minutes of the Ethernet Interfaces and Hub MIB WG meeting hold at the = 59th IETF. Thanks to Shailaja Yadawad for volunteering to be the minutes = taker during the meeting.

Regards,

Dan

<<minutes_hubmib_ietf59.txt>> =

------_=_NextPart_002_01C401F2.A0CC0A38-- ------_=_NextPart_001_01C401F2.A0CC0A38 Content-Type: text/plain; name="minutes_hubmib_ietf59.txt" Content-Transfer-Encoding: base64 Content-Description: minutes_hubmib_ietf59.txt Content-Disposition: attachment; filename="minutes_hubmib_ietf59.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpXRzpFdGhlcm5ldCBJbnRlcmZhY2VzIGFuZCBIdWIgTUlCIFdHIChodWJtaWIpDQpEYXRlOldl ZG5lc2RheSwgTWFyY2ggMyBhdCAwOTAwLTExMzANCkNIQUlSOiBEYW4gUm9tYXNjYW51IDxkcm9t YXNjYUBhdmF5YS5jb20+DQpSZXBvcnRlZCBieTogU2hhaWxhamENCg0KDQpHZW5lcmFsIENvbW1l bnQ6DQoNClNpbmNlIG5leHQgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0cyB3aWxsIGJlIHRoZSBsYXN0 IGNhbGwgYW5kIGhlbmNlIGF1dGhvcnMgDQpuZWVkIHRvIGRvIGdpdmUgc3BlY2lhbCBhdHRlbnRp b24gdG8gYWxsIHRoZSBhc3BlY3RzIG9mIHRoZSBkcmFmdCBsaWtlIA0KZm9ybWF0dGluZyxjb21w aWxhdGlvbiBvZiB0aGUgTUlCIGV0Yy4NCg0KDQozLiBHZW5lcmljIEVGTSBNSUIgSXNzdWVzIChE YW4gb24gYmVoYWxmIG9mIE1hdHQpIC0gMzAgbWludXRlcw0KDQpTbGlkZS1Db21tb24gTUlCIG9y IE9BTSBNSUINClRoZXJlIHdhcyBhIGRpc2N1c3Npb24gYWJvdXQgT0FNIGFuZCBNSUIgc2VlbSB0 byByZXByZXNlbnQgDQp0aGUgc2FtZSBtZWFuaW5nIGFuZCBoZW5jZSBuZWVkIHRvIGNvbnNpZGVy IHJlbW92aW5nIHRoZSB3b3JkIE9BTS4NCkRhbiB0byB0YWtlIHRoaXMgbWF0dGVyIHRvIHRoZSBs aXN0Lg0KDQoNClNsaWRlLWxvb3BiYWNrKEkpDQoNCk1vcmUgZGV0YWlsZWQgbWFpbCBzZW50IGJ5 IE1hdHQgU3F1aXJlIHRvIHRoZSBsaXN0LiANCkl0IHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhlIG5l eHQgZHJhZnQsIHVubGVzcyB0aGVyZSBhcmUgb2JqZWN0aW9ucy4NCg0KU2xpZGUgLUNvdW50ZXJz IGFuZCBEaXNjb250aW51aXRpZXMNCg0KUHJvcG9zYWwgLSBpbmNsdWRlIHRoZSBjbGFyaWZpY2F0 aW9uIHRleHQgdW5sZXNzIHRoZXJlIGFyZSBvYmplY3Rpb25zIG9uIHRoZSBsaXN0Lg0KDQpTbGlk ZSAtRXZlbnQgQ291bnRlciBJbmNvbnNpc3RlbmN5IChJSSkNClByb3Bvc2FsIC0gSW5jbHVkZSBy ZWFkLW9ubHkgb2JqZWN0cyB0byByZWZsZWN0IHRoZSBpbnRlcm5hbCBjb3VudGVycywgDQp1bmxl c3Mgb2JqZWN0ZWQgb24gdGhlIGxpc3QuICANCg0KRXZlbnQgQ29udHJvbHMNClByb3Bvc2FsIC0g cHJvdmlkZSBldmVudCBjb250cm9sIG1lY2hhbmlzbSBhcyByZWNvbW1lbmRlZCBpbiB0aGUgc2xp ZGVzLCANCnVubGVzcyBvYmplY3RlZCBvbiB0aGUgbGlzdA0KDQo0LiBFUE9OIE1JQiBJc3N1ZXMg KExpb3IpIA0KDQpBY2NlcHQgYWxsIGVkaXRvcmlhbCBjb21tZW50cyBtYWRlIGJ5IERhbg0KDQpT ZXR0bGluZyBUaW1lIGFuZCBMb2NrIFRpbWUgLSBlaXRoZXIgZG8gbm90IGluY2x1ZGUgYXQgYWxs LCANCm9yIGluY2x1ZGUgd2l0aCBhIGNvbmZvcm1hbmNlIGNsYXVzZSwgc28gdGhhdCB3ZSBkbyBu b3QgZGVsYXkgdGhlIElFRUUgcHJvY2Vzcy4NCg0KTGlvciB0byBsb29rIGludG8gRW50aXR5IFNl bnNvciBNSUIgZm9yIHBvd2VyIGFuZCB0ZW1wZXJhdHVyZSByZXBvcnRpbmcsIA0KaW4gRW50aXR5 IFN0YXRlIE1JQiBmb3IgZnVuY3Rpb25hbCBzdGF0dXMsIGFuZCBpbiBBbGFybSBNSUIgZm9yIGFs YXJtIHN0YXR1cy4gDQoNCkxpb3IgdG8gdGFrZSBpdCB0byB0aGUgV0cgbGlzdCBkaXNjdXNzaW9u IGFib3V0IGRlLWFzc2VydGluZyBtZWNoYW5pc20sIA0KYWxhcm0gdGhyZXNob2xkaW5nIGFuZCB0 aGUgZXZlbnRzLiBQcmVmZXJlbmNlIHRvIHJlZmVyZW5jaW5nIGV4aXN0aW5nIElFVEYgTUlCDQoN CkFsbCBvdGhlciByZXNvbHV0aW9uIC0gYXMgcHJvcG9zZWQgYnkgTGlvciBvbiB0aGUgbGlzdCwg dW5sZXNzIHRoZXJlIGFyZSBvYmplY3Rpb25zLg0KDQoNCg0KDQo1LiBFRk0gQ3UgSXNzdWVzIA0K DQoNClNsaWRlIGlmc3RhY2tUYWJsZS9lZm1DdSBNSUINCg0KLUxlYXZlICBpdCBhcyBpdCBpcyB1 bmxlc3MgaXQgYm90aGVycyBzb21lb25lIGluIHRoZSBXRyBsaXN0Lg0KDQpTSERTTC9WRFNMIE1J Qg0KDQpKdXN0IGxlYXZlIGl0IGFzIGl0IGlzLiANCg0KLSBOb3RpZmljYXRpb25zIC0gYWRkIGlm IHRoZXJlIGlzIGEgbmVlZCBmb3IgRUZNIEN1IHNwZWNpZmljIGV2ZW50cy4gDQpFZHdhcmQgd2ls bCBicmluZyB0aGlzIHRvIHRoZSBsaXN0LiBTb21lIGV2ZW50cyBkbyBub3Qgc2VlbSBDdSBzcGVj aWZpYyANCihwb3dlciBsb3NzLCBkZXZpY2UgZmF1bHQpIC0gdXNlIEFsYXJtIE1JQiBmb3IgdGhl c2UNCg0KLU1BVS1NSUINCg0KUmVjb21tZW5kYXRpb24gdG8gYWRkIHRoZSBzdWItbGF5ZXJzIGFz IGRpc3RpbmN0IHN1Yi10eXBlcw0KDQpNQVUgTUlCIHdpbGwgYmUgb3BlbiBhbmQgcmUtY3ljbGVk IG9uIFByb3Bvc2VkLCB1bmxlc3MgdGhlcmUgYXJlIG9iamVjdGlvbnMgb24gdGhlIGxpc3QuIA0K DQotIFRDL1BNRSBsYXllciAtIGRlZmluZSBuZXcgZW50cnkgaWYgdGhlcmUgYXJlIG9iamVjdHMg c3BlY2lmaWMgdG8gdGhlIG5ldyBsYXllcg0K ------_=_NextPart_001_01C401F2.A0CC0A38-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Mar 4 09:15:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20954 for ; Thu, 4 Mar 2004 09:15: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 1Aytcu-0000pE-So for hubmib-archive@odin.ietf.org; Thu, 04 Mar 2004 09:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24EF4N2003151 for hubmib-archive@odin.ietf.org; Thu, 4 Mar 2004 09:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aytct-0000nh-Fi; Thu, 04 Mar 2004 09:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AytcY-0000mV-RT for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 09:14: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 JAA20857 for ; Thu, 4 Mar 2004 09:14:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AytcX-0006DJ-00 for hubmib@ietf.org; Thu, 04 Mar 2004 09:14:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AytbN-0005m9-00 for hubmib@ietf.org; Thu, 04 Mar 2004 09:13:30 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AytZl-0005FE-00; Thu, 04 Mar 2004 09:11:49 -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 i24EAps2014234; Thu, 4 Mar 2004 09:10:51 -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 i24EAns2014195; Thu, 4 Mar 2004 09:10:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C401F2.A0CC0A38" Date: Thu, 4 Mar 2004 16:11:46 +0200 Message-ID: Thread-Topic: hubmib minutes Thread-Index: AcQB8p5nXhTxG5SjSGegMRu8g7NlOA== From: "Romascanu, Dan (Dan)" To: Cc: , "Shailaja Yadawad" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] hubmib minutes Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C401F2.A0CC0A38 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C401F2.A0CC0A38" ------_=_NextPart_002_01C401F2.A0CC0A38 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please find attached the minutes of the Ethernet Interfaces and Hub MIB = WG meeting hold at the 59th IETF. Thanks to Shailaja Yadawad for = volunteering to be the minutes taker during the meeting. Regards, Dan <>=20 ------_=_NextPart_002_01C401F2.A0CC0A38 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable hubmib minutes

Please find attached the = minutes of the Ethernet Interfaces and Hub MIB WG meeting hold at the = 59th IETF. Thanks to Shailaja Yadawad for volunteering to be the minutes = taker during the meeting.

Regards,

Dan

<<minutes_hubmib_ietf59.txt>> =

------_=_NextPart_002_01C401F2.A0CC0A38-- ------_=_NextPart_001_01C401F2.A0CC0A38 Content-Type: text/plain; name="minutes_hubmib_ietf59.txt" Content-Transfer-Encoding: base64 Content-Description: minutes_hubmib_ietf59.txt Content-Disposition: attachment; filename="minutes_hubmib_ietf59.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 DQpXRzpFdGhlcm5ldCBJbnRlcmZhY2VzIGFuZCBIdWIgTUlCIFdHIChodWJtaWIpDQpEYXRlOldl ZG5lc2RheSwgTWFyY2ggMyBhdCAwOTAwLTExMzANCkNIQUlSOiBEYW4gUm9tYXNjYW51IDxkcm9t YXNjYUBhdmF5YS5jb20+DQpSZXBvcnRlZCBieTogU2hhaWxhamENCg0KDQpHZW5lcmFsIENvbW1l bnQ6DQoNClNpbmNlIG5leHQgdmVyc2lvbnMgb2YgdGhlIGRyYWZ0cyB3aWxsIGJlIHRoZSBsYXN0 IGNhbGwgYW5kIGhlbmNlIGF1dGhvcnMgDQpuZWVkIHRvIGRvIGdpdmUgc3BlY2lhbCBhdHRlbnRp b24gdG8gYWxsIHRoZSBhc3BlY3RzIG9mIHRoZSBkcmFmdCBsaWtlIA0KZm9ybWF0dGluZyxjb21w aWxhdGlvbiBvZiB0aGUgTUlCIGV0Yy4NCg0KDQozLiBHZW5lcmljIEVGTSBNSUIgSXNzdWVzIChE YW4gb24gYmVoYWxmIG9mIE1hdHQpIC0gMzAgbWludXRlcw0KDQpTbGlkZS1Db21tb24gTUlCIG9y IE9BTSBNSUINClRoZXJlIHdhcyBhIGRpc2N1c3Npb24gYWJvdXQgT0FNIGFuZCBNSUIgc2VlbSB0 byByZXByZXNlbnQgDQp0aGUgc2FtZSBtZWFuaW5nIGFuZCBoZW5jZSBuZWVkIHRvIGNvbnNpZGVy IHJlbW92aW5nIHRoZSB3b3JkIE9BTS4NCkRhbiB0byB0YWtlIHRoaXMgbWF0dGVyIHRvIHRoZSBs aXN0Lg0KDQoNClNsaWRlLWxvb3BiYWNrKEkpDQoNCk1vcmUgZGV0YWlsZWQgbWFpbCBzZW50IGJ5 IE1hdHQgU3F1aXJlIHRvIHRoZSBsaXN0LiANCkl0IHdpbGwgYmUgaW5jbHVkZWQgaW4gdGhlIG5l eHQgZHJhZnQsIHVubGVzcyB0aGVyZSBhcmUgb2JqZWN0aW9ucy4NCg0KU2xpZGUgLUNvdW50ZXJz IGFuZCBEaXNjb250aW51aXRpZXMNCg0KUHJvcG9zYWwgLSBpbmNsdWRlIHRoZSBjbGFyaWZpY2F0 aW9uIHRleHQgdW5sZXNzIHRoZXJlIGFyZSBvYmplY3Rpb25zIG9uIHRoZSBsaXN0Lg0KDQpTbGlk ZSAtRXZlbnQgQ291bnRlciBJbmNvbnNpc3RlbmN5IChJSSkNClByb3Bvc2FsIC0gSW5jbHVkZSBy ZWFkLW9ubHkgb2JqZWN0cyB0byByZWZsZWN0IHRoZSBpbnRlcm5hbCBjb3VudGVycywgDQp1bmxl c3Mgb2JqZWN0ZWQgb24gdGhlIGxpc3QuICANCg0KRXZlbnQgQ29udHJvbHMNClByb3Bvc2FsIC0g cHJvdmlkZSBldmVudCBjb250cm9sIG1lY2hhbmlzbSBhcyByZWNvbW1lbmRlZCBpbiB0aGUgc2xp ZGVzLCANCnVubGVzcyBvYmplY3RlZCBvbiB0aGUgbGlzdA0KDQo0LiBFUE9OIE1JQiBJc3N1ZXMg KExpb3IpIA0KDQpBY2NlcHQgYWxsIGVkaXRvcmlhbCBjb21tZW50cyBtYWRlIGJ5IERhbg0KDQpT ZXR0bGluZyBUaW1lIGFuZCBMb2NrIFRpbWUgLSBlaXRoZXIgZG8gbm90IGluY2x1ZGUgYXQgYWxs LCANCm9yIGluY2x1ZGUgd2l0aCBhIGNvbmZvcm1hbmNlIGNsYXVzZSwgc28gdGhhdCB3ZSBkbyBu b3QgZGVsYXkgdGhlIElFRUUgcHJvY2Vzcy4NCg0KTGlvciB0byBsb29rIGludG8gRW50aXR5IFNl bnNvciBNSUIgZm9yIHBvd2VyIGFuZCB0ZW1wZXJhdHVyZSByZXBvcnRpbmcsIA0KaW4gRW50aXR5 IFN0YXRlIE1JQiBmb3IgZnVuY3Rpb25hbCBzdGF0dXMsIGFuZCBpbiBBbGFybSBNSUIgZm9yIGFs YXJtIHN0YXR1cy4gDQoNCkxpb3IgdG8gdGFrZSBpdCB0byB0aGUgV0cgbGlzdCBkaXNjdXNzaW9u IGFib3V0IGRlLWFzc2VydGluZyBtZWNoYW5pc20sIA0KYWxhcm0gdGhyZXNob2xkaW5nIGFuZCB0 aGUgZXZlbnRzLiBQcmVmZXJlbmNlIHRvIHJlZmVyZW5jaW5nIGV4aXN0aW5nIElFVEYgTUlCDQoN CkFsbCBvdGhlciByZXNvbHV0aW9uIC0gYXMgcHJvcG9zZWQgYnkgTGlvciBvbiB0aGUgbGlzdCwg dW5sZXNzIHRoZXJlIGFyZSBvYmplY3Rpb25zLg0KDQoNCg0KDQo1LiBFRk0gQ3UgSXNzdWVzIA0K DQoNClNsaWRlIGlmc3RhY2tUYWJsZS9lZm1DdSBNSUINCg0KLUxlYXZlICBpdCBhcyBpdCBpcyB1 bmxlc3MgaXQgYm90aGVycyBzb21lb25lIGluIHRoZSBXRyBsaXN0Lg0KDQpTSERTTC9WRFNMIE1J Qg0KDQpKdXN0IGxlYXZlIGl0IGFzIGl0IGlzLiANCg0KLSBOb3RpZmljYXRpb25zIC0gYWRkIGlm IHRoZXJlIGlzIGEgbmVlZCBmb3IgRUZNIEN1IHNwZWNpZmljIGV2ZW50cy4gDQpFZHdhcmQgd2ls bCBicmluZyB0aGlzIHRvIHRoZSBsaXN0LiBTb21lIGV2ZW50cyBkbyBub3Qgc2VlbSBDdSBzcGVj aWZpYyANCihwb3dlciBsb3NzLCBkZXZpY2UgZmF1bHQpIC0gdXNlIEFsYXJtIE1JQiBmb3IgdGhl c2UNCg0KLU1BVS1NSUINCg0KUmVjb21tZW5kYXRpb24gdG8gYWRkIHRoZSBzdWItbGF5ZXJzIGFz IGRpc3RpbmN0IHN1Yi10eXBlcw0KDQpNQVUgTUlCIHdpbGwgYmUgb3BlbiBhbmQgcmUtY3ljbGVk IG9uIFByb3Bvc2VkLCB1bmxlc3MgdGhlcmUgYXJlIG9iamVjdGlvbnMgb24gdGhlIGxpc3QuIA0K DQotIFRDL1BNRSBsYXllciAtIGRlZmluZSBuZXcgZW50cnkgaWYgdGhlcmUgYXJlIG9iamVjdHMg c3BlY2lmaWMgdG8gdGhlIG5ldyBsYXllcg0K ------_=_NextPart_001_01C401F2.A0CC0A38-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Mar 4 13:52:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07395 for ; Thu, 4 Mar 2004 13:52: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 1Ayxwt-0002TX-SI; Thu, 04 Mar 2004 13:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayxwd-0002TA-72 for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 13:51:43 -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 NAA07387 for ; Thu, 4 Mar 2004 13:51:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayxwa-00028H-00 for hubmib@ietf.org; Thu, 04 Mar 2004 13:51:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayxvh-0001z7-00 for hubmib@ietf.org; Thu, 04 Mar 2004 13:50:45 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1AyxvS-0001pG-00 for hubmib@ietf.org; Thu, 04 Mar 2004 13:50:30 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Mar 2004 20:56:22 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742138@il-mail02.actelis.net> From: Edward Beili To: "'Romascanu, Dan (Dan)'" Cc: hubmib@ietf.org Subject: RE: [Hubmib] hubmib minutes Date: Thu, 4 Mar 2004 20:56:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Dan, > Since next versions of the drafts will be the last call ... Could you please explain the procedure and the time line for the drafts approval. I assume all the editors and the chair are going to be present at the EFM meeting in Kissimmee in a week. I propose we meet to sync. How about Tuesday, March 23 at 18:00? Regards, -Edward -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, March 04, 2004 04:12 PM To: proceedings@ietf.org Cc: hubmib@ietf.org; Shailaja Yadawad Subject: [Hubmib] hubmib minutes Please find attached the minutes of the Ethernet Interfaces and Hub MIB WG meeting hold at the 59th IETF. Thanks to Shailaja Yadawad for volunteering to be the minutes taker during the meeting. Regards, Dan <> _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Mar 4 14:40:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07397 for ; Thu, 4 Mar 2004 13:52: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 1Ayxwu-0002U7-H0 for hubmib-archive@odin.ietf.org; Thu, 04 Mar 2004 13:52:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24Iq0M9009537 for hubmib-archive@odin.ietf.org; Thu, 4 Mar 2004 13:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayxwt-0002TX-SI; Thu, 04 Mar 2004 13:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayxwd-0002TA-72 for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 13:51:43 -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 NAA07387 for ; Thu, 4 Mar 2004 13:51:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayxwa-00028H-00 for hubmib@ietf.org; Thu, 04 Mar 2004 13:51:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayxvh-0001z7-00 for hubmib@ietf.org; Thu, 04 Mar 2004 13:50:45 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1AyxvS-0001pG-00 for hubmib@ietf.org; Thu, 04 Mar 2004 13:50:30 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Mar 2004 20:56:22 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742138@il-mail02.actelis.net> From: Edward Beili To: "'Romascanu, Dan (Dan)'" Cc: hubmib@ietf.org Subject: RE: [Hubmib] hubmib minutes Date: Thu, 4 Mar 2004 20:56:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Dan, > Since next versions of the drafts will be the last call ... Could you please explain the procedure and the time line for the drafts approval. I assume all the editors and the chair are going to be present at the EFM meeting in Kissimmee in a week. I propose we meet to sync. How about Tuesday, March 23 at 18:00? Regards, -Edward -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Thursday, March 04, 2004 04:12 PM To: proceedings@ietf.org Cc: hubmib@ietf.org; Shailaja Yadawad Subject: [Hubmib] hubmib minutes Please find attached the minutes of the Ethernet Interfaces and Hub MIB WG meeting hold at the 59th IETF. Thanks to Shailaja Yadawad for volunteering to be the minutes taker during the meeting. Regards, Dan <> _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Mar 4 17:59:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18755 for ; Thu, 4 Mar 2004 17:59:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1oI-00077R-A3 for hubmib-archive@odin.ietf.org; Thu, 04 Mar 2004 17:59:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24MxMkt027339 for hubmib-archive@odin.ietf.org; Thu, 4 Mar 2004 17:59:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1oH-00076e-N3; Thu, 04 Mar 2004 17:59:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1nr-0006zl-Fc for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 17:58: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 RAA18560 for ; Thu, 4 Mar 2004 17:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1np-0000zs-00 for hubmib@ietf.org; Thu, 04 Mar 2004 17:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1mu-0000lo-00 for hubmib@ietf.org; Thu, 04 Mar 2004 17:57:56 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1Az1m8-0000Qv-00 for hubmib@ietf.org; Thu, 04 Mar 2004 17:57:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] hubmib minutes Date: Thu, 4 Mar 2004 17:56:38 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714023388BA@mailserv.hatteras.com> Thread-Topic: [Hubmib] hubmib minutes Thread-Index: AcQCGctIYLpHoB57SQmrVQJIq4ZACwAHOmMw From: "Matt Squire" To: "Edward Beili" , "Romascanu, Dan (Dan)" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I assume all the editors and the chair are going to be=20 > present at the EFM > meeting in Kissimmee in a week. I propose we meet to sync. How about > Tuesday, March 23 at 18:00? >=20 We should definitely schedule some time. If there are no conflicting = CFIs, Tues night would work for me. - Matt _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Mar 4 18:45:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18753 for ; Thu, 4 Mar 2004 17:59:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1oH-00076e-N3; Thu, 04 Mar 2004 17:59:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az1nr-0006zl-Fc for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 17:58: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 RAA18560 for ; Thu, 4 Mar 2004 17:58:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az1np-0000zs-00 for hubmib@ietf.org; Thu, 04 Mar 2004 17:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az1mu-0000lo-00 for hubmib@ietf.org; Thu, 04 Mar 2004 17:57:56 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1Az1m8-0000Qv-00 for hubmib@ietf.org; Thu, 04 Mar 2004 17:57:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] hubmib minutes Date: Thu, 4 Mar 2004 17:56:38 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714023388BA@mailserv.hatteras.com> Thread-Topic: [Hubmib] hubmib minutes Thread-Index: AcQCGctIYLpHoB57SQmrVQJIq4ZACwAHOmMw From: "Matt Squire" To: "Edward Beili" , "Romascanu, Dan (Dan)" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > I assume all the editors and the chair are going to be=20 > present at the EFM > meeting in Kissimmee in a week. I propose we meet to sync. How about > Tuesday, March 23 at 18:00? >=20 We should definitely schedule some time. If there are no conflicting = CFIs, Tues night would work for me. - Matt _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Mar 4 19:32:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23578 for ; Thu, 4 Mar 2004 19:32: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 1Az3Fz-0005R2-Dz for hubmib-archive@odin.ietf.org; Thu, 04 Mar 2004 19:32:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i250W38k020878 for hubmib-archive@odin.ietf.org; Thu, 4 Mar 2004 19:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3Fy-0005PN-4f; Thu, 04 Mar 2004 19:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3F6-0005Le-4k for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 19:31:08 -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 TAA23535 for ; Thu, 4 Mar 2004 19:31:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az3F4-0002ml-00 for hubmib@ietf.org; Thu, 04 Mar 2004 19:31:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az3E7-0002b0-00 for hubmib@ietf.org; Thu, 04 Mar 2004 19:30:08 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Az3DD-0002Pa-00 for hubmib@ietf.org; Thu, 04 Mar 2004 19:29:11 -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 i250S9s2013998 for ; Thu, 4 Mar 2004 19:28:09 -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 i250S7s2013970 for ; Thu, 4 Mar 2004 19:28:08 -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="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] hubmib minutes Date: Fri, 5 Mar 2004 02:29:04 +0200 Message-ID: Thread-Topic: [Hubmib] hubmib minutes Thread-Index: AcQCGYGR7xgWNOiXQbihClSo//kBJAALYxqA From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Please see in-line. Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: 04 March, 2004 8:56 PM > To: Romascanu, Dan (Dan) > Cc: hubmib@ietf.org > Subject: RE: [Hubmib] hubmib minutes >=20 >=20 > Dan, >=20 > > Since next versions of the drafts will be the last call ... >=20 > Could you please explain the procedure and the time line for=20 > the drafts > approval. >=20 The Working Group Last Call is a formal step in the process of pushing a = work on the IETF standards track. When the WG Chair considers the work = stable enough he/she calls for a Last Call period (at least two weeks) = in which the WG members can send their comments to the list. If there = are no comments, consensus is declared and the Internet-Drafts will be = submitted to the IESG for consideration as IETF standards. If there are = problems, the document is re-edited, new version is published, and the = process is repeated until consensus this is appropriate quality is = reached. Note that this is only the beginning of the story. The IESG has its own = process, composed of an Area Director quality review, IETF Last Call, = and IESG members review. Then there is a clerical step by the RFC = Editor. At the end of the process, you have some more gray hair, but you = may be the author of a standards track RFC.=20 The WG charter schedules calls for us to reach WG Last Call after the = IETF meeting this week. My expectation is that we can solve all the = pending problems and issue I-Ds good enough for Last Call in the weeks = following the IEEE meeting. >=20 > I assume all the editors and the chair are going to be=20 > present at the EFM > meeting in Kissimmee in a week. I propose we meet to sync. How about > Tuesday, March 23 at 18:00? This cannot be a formal interim meeting, because we do not have the 30 = days required by the IETF rules to call for such a meeting. Informal = meetings are OK, but I suggest that all discussions and proposals will = be made on the WG e-mail list, so that all WG members can express = particpate in the discussions. =20 >=20 > Regards, > -Edward >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, March 04, 2004 04:12 PM > To: proceedings@ietf.org > Cc: hubmib@ietf.org; Shailaja Yadawad > Subject: [Hubmib] hubmib minutes >=20 >=20 > Please find attached the minutes of the Ethernet Interfaces=20 > and Hub MIB WG > meeting hold at the 59th IETF. Thanks to Shailaja Yadawad for=20 > volunteering > to be the minutes taker during the meeting. > Regards, > Dan > <>=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Mar 4 20:20:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23577 for ; Thu, 4 Mar 2004 19:32: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 1Az3Fy-0005PN-4f; Thu, 04 Mar 2004 19:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3F6-0005Le-4k for hubmib@optimus.ietf.org; Thu, 04 Mar 2004 19:31:08 -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 TAA23535 for ; Thu, 4 Mar 2004 19:31:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az3F4-0002ml-00 for hubmib@ietf.org; Thu, 04 Mar 2004 19:31:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az3E7-0002b0-00 for hubmib@ietf.org; Thu, 04 Mar 2004 19:30:08 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Az3DD-0002Pa-00 for hubmib@ietf.org; Thu, 04 Mar 2004 19:29:11 -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 i250S9s2013998 for ; Thu, 4 Mar 2004 19:28:09 -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 i250S7s2013970 for ; Thu, 4 Mar 2004 19:28:08 -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="windows-1255" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] hubmib minutes Date: Fri, 5 Mar 2004 02:29:04 +0200 Message-ID: Thread-Topic: [Hubmib] hubmib minutes Thread-Index: AcQCGYGR7xgWNOiXQbihClSo//kBJAALYxqA From: "Romascanu, Dan (Dan)" To: "Edward Beili" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Please see in-line. Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: 04 March, 2004 8:56 PM > To: Romascanu, Dan (Dan) > Cc: hubmib@ietf.org > Subject: RE: [Hubmib] hubmib minutes >=20 >=20 > Dan, >=20 > > Since next versions of the drafts will be the last call ... >=20 > Could you please explain the procedure and the time line for=20 > the drafts > approval. >=20 The Working Group Last Call is a formal step in the process of pushing a = work on the IETF standards track. When the WG Chair considers the work = stable enough he/she calls for a Last Call period (at least two weeks) = in which the WG members can send their comments to the list. If there = are no comments, consensus is declared and the Internet-Drafts will be = submitted to the IESG for consideration as IETF standards. If there are = problems, the document is re-edited, new version is published, and the = process is repeated until consensus this is appropriate quality is = reached. Note that this is only the beginning of the story. The IESG has its own = process, composed of an Area Director quality review, IETF Last Call, = and IESG members review. Then there is a clerical step by the RFC = Editor. At the end of the process, you have some more gray hair, but you = may be the author of a standards track RFC.=20 The WG charter schedules calls for us to reach WG Last Call after the = IETF meeting this week. My expectation is that we can solve all the = pending problems and issue I-Ds good enough for Last Call in the weeks = following the IEEE meeting. >=20 > I assume all the editors and the chair are going to be=20 > present at the EFM > meeting in Kissimmee in a week. I propose we meet to sync. How about > Tuesday, March 23 at 18:00? This cannot be a formal interim meeting, because we do not have the 30 = days required by the IETF rules to call for such a meeting. Informal = meetings are OK, but I suggest that all discussions and proposals will = be made on the WG e-mail list, so that all WG members can express = particpate in the discussions. =20 >=20 > Regards, > -Edward >=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Thursday, March 04, 2004 04:12 PM > To: proceedings@ietf.org > Cc: hubmib@ietf.org; Shailaja Yadawad > Subject: [Hubmib] hubmib minutes >=20 >=20 > Please find attached the minutes of the Ethernet Interfaces=20 > and Hub MIB WG > meeting hold at the 59th IETF. Thanks to Shailaja Yadawad for=20 > volunteering > to be the minutes taker during the meeting. > Regards, > Dan > <>=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Fri Mar 12 18:30:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27344 for ; Fri, 12 Mar 2004 18:30: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 1B1w6N-0001PH-QK for hubmib-archive@odin.ietf.org; Fri, 12 Mar 2004 18:30:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNU3mc005379 for hubmib-archive@odin.ietf.org; Fri, 12 Mar 2004 18:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w6L-0001OQ-Is; Fri, 12 Mar 2004 18:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w69-0001Nk-Mo for hubmib@optimus.ietf.org; Fri, 12 Mar 2004 18:29: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 SAA27330 for ; Fri, 12 Mar 2004 18:29:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1w66-0007dA-00 for hubmib@ietf.org; Fri, 12 Mar 2004 18:29:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1w5A-0007c7-00 for hubmib@ietf.org; Fri, 12 Mar 2004 18:28:49 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1B1w4W-0007ZT-00; Fri, 12 Mar 2004 18:28:08 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Sat, 13 Mar 2004 01:34:49 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742199@il-mail02.actelis.net> From: Edward Beili To: "'Bob Ray '" Cc: "'adslmib mail list '" , "'Romascanu, Dan (Dan) '" , "'hubmib@ietf.org'" Date: Sat, 13 Mar 2004 01:34:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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=AWL autolearn=no version=2.60 Subject: [Hubmib] RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bob, There's a lot of sense in your proposal, in fact I was thinking along the same lines a while ago. The connection capability tables could benefit other areas as well as the discovery stuff. And of course it is needed in G.Bond/M2DSL MIBs. The only issue I have with this is the time frame. I would like to have the EFM-CU-MIB approved around the same time as the 802.3ah is approved (summer 2004). I'm not sure it is possible if we start splitting the stuff now. That was also my problem with using your excellent VDSL and SHDSL MIBs - SHDSL.bis is not even started, besides there are some things (e.g. rate settings) that are done differently in EFM and SHDSL.bis. That was also the general feeling in the HUBMIB group and the EFM that it is better to define everything in a single MIB. So, if splitting the MIBs can be done in time, then I would go for it. Otherwise I would like to finish the EFM-CU-MIB and worry about general things later. I'm CC:'ing the HUBMIB group, for the benefit of those not subscribed to ADSLMIB, as I would like to hear their opinion as well. Regards, -Edward -----Original Message----- From: Bob Ray To: Edward Beili Cc: adslmib mail list Sent: 13/03/04 00:34 Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects On Thu, 2004-03-04 at 14:11, Edward Beili wrote: > You are right of course about the bonding stuff. I would like to have the > common MIB to manage the aggregation assignment and retrieval for all of > them. Note that ifStack describes and configures actual cross-connect > between the bonded group (upper layer) and individual lines (lower layer). > Another table is needed to describe cross-connect capability, e.g. which > lines can be connected to which groups, in case there are multiple groups. > Take a look at the EFM-CU-MIB: > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt > > Regards, > -Edward > Hi. I've been reading your draft. Really, I have! Being a co-author of the HDSL2/SDHSL MIB and of the VDSL MIB, I am disheartened by your discarding of them. But, I'll get over it! As for G.SHDSL.bis, we're addressing that... I wonder why EFM is redefining and duplicating all these objects, but don't have the clarity of vision perhaps to understand. I also wonder if many EFM vendors would end up implementing both sets of objects for a given modem (IETF model and EFM model) which would result in an increase in effort instead of a reduction in effort (you claim the EFM model has fewer objects to support). In any case, that's for the EFM guys to decide, I suppose. Ok. With THAT over with, the non-duplicated meat of your draft seems to be concerned with the "available" cross connects, which seems interesting. If I read your efmCuAvailableStackTable correctly, what you are stating is that the table contains a list of possible connections. RFC2863: For example, when the sub-layer with ifIndex value x runs over the sub-layer with ifIndex value y, then this table contains: ifStackStatus.x.y=active RFC2864: For example, when the sub-layer with ifIndex value x runs underneath the sub-layer with ifIndex value y, then this table contains: ifInvStackStatus.x.y=active You propose a new table that will report if x and y *CAN* be connected, which makes a lot of sense. You: For example, when the PCS port with ifIndex value x can be connected to run on top of the PMI with ifIndex value y, then this table contains: efcCuAvailableStackTable.x.y=active I think a draft which contains just such a table (and of course the inverse ala ifInvStackTable) would be of use in many places, not just in the EFM world. For example, in broadcast video switches. Which leads to the suggestion that perhaps two drafts (an available draft and an InvAvailable draft) are in order. I think great utility outside of EFM/DSL could be derived from such work - as long as it's interface neutral (i.e. no dsl/efm/ethernet stuff). However, I don't think the adslmib working group would be the right place for it. That is, the Interfaces MIB working group would seem to be the best place for it (is that group still formed?). I wonder if the hubmib group is the closest thing still running to that group. Bert? Mike? In short, then, my suggestions are: 1. EFM consider using existing MIBS (with the assumption that we drones in the IETF get g.shdsl.bis support going), and that 2. you create two drafts, somewhere, to implement your excellent idea of "can connect" and "inverse can connect" tables. Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Mar 12 19:16:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27342 for ; Fri, 12 Mar 2004 18:30: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 1B1w6L-0001OQ-Is; Fri, 12 Mar 2004 18:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w69-0001Nk-Mo for hubmib@optimus.ietf.org; Fri, 12 Mar 2004 18:29: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 SAA27330 for ; Fri, 12 Mar 2004 18:29:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1w66-0007dA-00 for hubmib@ietf.org; Fri, 12 Mar 2004 18:29:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1w5A-0007c7-00 for hubmib@ietf.org; Fri, 12 Mar 2004 18:28:49 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1B1w4W-0007ZT-00; Fri, 12 Mar 2004 18:28:08 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Sat, 13 Mar 2004 01:34:49 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742199@il-mail02.actelis.net> From: Edward Beili To: "'Bob Ray '" Cc: "'adslmib mail list '" , "'Romascanu, Dan (Dan) '" , "'hubmib@ietf.org'" Date: Sat, 13 Mar 2004 01:34:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" 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=AWL autolearn=no version=2.60 Subject: [Hubmib] RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bob, There's a lot of sense in your proposal, in fact I was thinking along the same lines a while ago. The connection capability tables could benefit other areas as well as the discovery stuff. And of course it is needed in G.Bond/M2DSL MIBs. The only issue I have with this is the time frame. I would like to have the EFM-CU-MIB approved around the same time as the 802.3ah is approved (summer 2004). I'm not sure it is possible if we start splitting the stuff now. That was also my problem with using your excellent VDSL and SHDSL MIBs - SHDSL.bis is not even started, besides there are some things (e.g. rate settings) that are done differently in EFM and SHDSL.bis. That was also the general feeling in the HUBMIB group and the EFM that it is better to define everything in a single MIB. So, if splitting the MIBs can be done in time, then I would go for it. Otherwise I would like to finish the EFM-CU-MIB and worry about general things later. I'm CC:'ing the HUBMIB group, for the benefit of those not subscribed to ADSLMIB, as I would like to hear their opinion as well. Regards, -Edward -----Original Message----- From: Bob Ray To: Edward Beili Cc: adslmib mail list Sent: 13/03/04 00:34 Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects On Thu, 2004-03-04 at 14:11, Edward Beili wrote: > You are right of course about the bonding stuff. I would like to have the > common MIB to manage the aggregation assignment and retrieval for all of > them. Note that ifStack describes and configures actual cross-connect > between the bonded group (upper layer) and individual lines (lower layer). > Another table is needed to describe cross-connect capability, e.g. which > lines can be connected to which groups, in case there are multiple groups. > Take a look at the EFM-CU-MIB: > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt > > Regards, > -Edward > Hi. I've been reading your draft. Really, I have! Being a co-author of the HDSL2/SDHSL MIB and of the VDSL MIB, I am disheartened by your discarding of them. But, I'll get over it! As for G.SHDSL.bis, we're addressing that... I wonder why EFM is redefining and duplicating all these objects, but don't have the clarity of vision perhaps to understand. I also wonder if many EFM vendors would end up implementing both sets of objects for a given modem (IETF model and EFM model) which would result in an increase in effort instead of a reduction in effort (you claim the EFM model has fewer objects to support). In any case, that's for the EFM guys to decide, I suppose. Ok. With THAT over with, the non-duplicated meat of your draft seems to be concerned with the "available" cross connects, which seems interesting. If I read your efmCuAvailableStackTable correctly, what you are stating is that the table contains a list of possible connections. RFC2863: For example, when the sub-layer with ifIndex value x runs over the sub-layer with ifIndex value y, then this table contains: ifStackStatus.x.y=active RFC2864: For example, when the sub-layer with ifIndex value x runs underneath the sub-layer with ifIndex value y, then this table contains: ifInvStackStatus.x.y=active You propose a new table that will report if x and y *CAN* be connected, which makes a lot of sense. You: For example, when the PCS port with ifIndex value x can be connected to run on top of the PMI with ifIndex value y, then this table contains: efcCuAvailableStackTable.x.y=active I think a draft which contains just such a table (and of course the inverse ala ifInvStackTable) would be of use in many places, not just in the EFM world. For example, in broadcast video switches. Which leads to the suggestion that perhaps two drafts (an available draft and an InvAvailable draft) are in order. I think great utility outside of EFM/DSL could be derived from such work - as long as it's interface neutral (i.e. no dsl/efm/ethernet stuff). However, I don't think the adslmib working group would be the right place for it. That is, the Interfaces MIB working group would seem to be the best place for it (is that group still formed?). I wonder if the hubmib group is the closest thing still running to that group. Bert? Mike? In short, then, my suggestions are: 1. EFM consider using existing MIBS (with the assumption that we drones in the IETF get g.shdsl.bis support going), and that 2. you create two drafts, somewhere, to implement your excellent idea of "can connect" and "inverse can connect" tables. Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Mar 14 14:59:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03380 for ; Sun, 14 Mar 2004 14:59:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bku-00040l-0Y; Sun, 14 Mar 2004 14:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2YTD-00020b-T8 for hubmib@optimus.ietf.org; Sun, 14 Mar 2004 11:28: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 LAA25921 for ; Sun, 14 Mar 2004 11:28:09 -0500 (EST) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2YT7-0002As-00 for hubmib@ietf.org; Sun, 14 Mar 2004 11:28:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2YSA-00025H-00 for hubmib@ietf.org; Sun, 14 Mar 2004 11:27:07 -0500 Received: from smtp1.infineon.com ([194.175.117.76]) by ietf-mx with esmtp (Exim 4.12) id 1B2YRd-0001vU-00; Sun, 14 Mar 2004 11:26:33 -0500 Received: from mucse012.eu.infineon.com (mucse012.ifx-mail1.com [172.29.27.229]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id i2EGKVCY009742; Sun, 14 Mar 2004 17:20:31 +0100 (MET) Received: by mucse012.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Mar 2004 17:25:34 +0100 Message-ID: To: EdwardB@actelis.com, rray@pesa.com Cc: adslmib@ietf.org, dromasca@avaya.com, hubmib@ietf.org, sneedmike@hotmail.com Date: Sun, 14 Mar 2004 17:20:39 +0100 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.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Hubmib] RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Edward, I agree with Bob. There is a lot of duplication work going on. The hubmib WG charter clearly states and I quote: "The working group will also take into consideration management objects defined by other Working Groups in the IETF (ADSL MIB for example), or other standard bodies (G.983.2), will avoid work duplication, and describe the relationship with these specifications." In my humble opinion, all of us ADSLMIB WG and HUBMIB WG need to work out and define the relationship between the two MIBS and how best they be implemented together. It would be a real shame to produce a MIB that duplicates and/or does not co-exist with the VDSL and SHDSL MIBs which are already completed and implemented in equipment. I don't think that the "time frame" issue is a "real" issue and I'm sure that if both Working Groups make an effort this issue can be sorted out quickly. Regards, Menachem Dodge. Infineon Technologies Savan. -----Original Message----- From: adslmib-admin@ietf.org [mailto:adslmib-admin@ietf.org] On Behalf Of Edward Beili Sent: Saturday, March 13, 2004 1:35 AM To: 'Bob Ray ' Cc: 'adslmib mail list '; 'Romascanu, Dan (Dan) '; 'hubmib@ietf.org' Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects Bob, There's a lot of sense in your proposal, in fact I was thinking along the same lines a while ago. The connection capability tables could benefit other areas as well as the discovery stuff. And of course it is needed in G.Bond/M2DSL MIBs. The only issue I have with this is the time frame. I would like to have the EFM-CU-MIB approved around the same time as the 802.3ah is approved (summer 2004). I'm not sure it is possible if we start splitting the stuff now. That was also my problem with using your excellent VDSL and SHDSL MIBs - SHDSL.bis is not even started, besides there are some things (e.g. rate settings) that are done differently in EFM and SHDSL.bis. That was also the general feeling in the HUBMIB group and the EFM that it is better to define everything in a single MIB. So, if splitting the MIBs can be done in time, then I would go for it. Otherwise I would like to finish the EFM-CU-MIB and worry about general things later. I'm CC:'ing the HUBMIB group, for the benefit of those not subscribed to ADSLMIB, as I would like to hear their opinion as well. Regards, -Edward -----Original Message----- From: Bob Ray To: Edward Beili Cc: adslmib mail list Sent: 13/03/04 00:34 Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects On Thu, 2004-03-04 at 14:11, Edward Beili wrote: > You are right of course about the bonding stuff. I would like to have the > common MIB to manage the aggregation assignment and retrieval for all of > them. Note that ifStack describes and configures actual cross-connect > between the bonded group (upper layer) and individual lines (lower layer). > Another table is needed to describe cross-connect capability, e.g. which > lines can be connected to which groups, in case there are multiple groups. > Take a look at the EFM-CU-MIB: > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt > > Regards, > -Edward > Hi. I've been reading your draft. Really, I have! Being a co-author of the HDSL2/SDHSL MIB and of the VDSL MIB, I am disheartened by your discarding of them. But, I'll get over it! As for G.SHDSL.bis, we're addressing that... I wonder why EFM is redefining and duplicating all these objects, but don't have the clarity of vision perhaps to understand. I also wonder if many EFM vendors would end up implementing both sets of objects for a given modem (IETF model and EFM model) which would result in an increase in effort instead of a reduction in effort (you claim the EFM model has fewer objects to support). In any case, that's for the EFM guys to decide, I suppose. Ok. With THAT over with, the non-duplicated meat of your draft seems to be concerned with the "available" cross connects, which seems interesting. If I read your efmCuAvailableStackTable correctly, what you are stating is that the table contains a list of possible connections. RFC2863: For example, when the sub-layer with ifIndex value x runs over the sub-layer with ifIndex value y, then this table contains: ifStackStatus.x.y=active RFC2864: For example, when the sub-layer with ifIndex value x runs underneath the sub-layer with ifIndex value y, then this table contains: ifInvStackStatus.x.y=active You propose a new table that will report if x and y *CAN* be connected, which makes a lot of sense. You: For example, when the PCS port with ifIndex value x can be connected to run on top of the PMI with ifIndex value y, then this table contains: efcCuAvailableStackTable.x.y=active I think a draft which contains just such a table (and of course the inverse ala ifInvStackTable) would be of use in many places, not just in the EFM world. For example, in broadcast video switches. Which leads to the suggestion that perhaps two drafts (an available draft and an InvAvailable draft) are in order. I think great utility outside of EFM/DSL could be derived from such work - as long as it's interface neutral (i.e. no dsl/efm/ethernet stuff). However, I don't think the adslmib working group would be the right place for it. That is, the Interfaces MIB working group would seem to be the best place for it (is that group still formed?). I wonder if the hubmib group is the closest thing still running to that group. Bert? Mike? In short, then, my suggestions are: 1. EFM consider using existing MIBS (with the assumption that we drones in the IETF get g.shdsl.bis support going), and that 2. you create two drafts, somewhere, to implement your excellent idea of "can connect" and "inverse can connect" tables. Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Sun Mar 14 14:59:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03419 for ; Sun, 14 Mar 2004 14:59: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 1B2bkx-00044v-N6 for hubmib-archive@odin.ietf.org; Sun, 14 Mar 2004 14:58:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EJwgWT015462 for hubmib-archive@odin.ietf.org; Sun, 14 Mar 2004 14:58:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bku-00040l-0Y; Sun, 14 Mar 2004 14:58:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2YTD-00020b-T8 for hubmib@optimus.ietf.org; Sun, 14 Mar 2004 11:28: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 LAA25921 for ; Sun, 14 Mar 2004 11:28:09 -0500 (EST) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2YT7-0002As-00 for hubmib@ietf.org; Sun, 14 Mar 2004 11:28:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2YSA-00025H-00 for hubmib@ietf.org; Sun, 14 Mar 2004 11:27:07 -0500 Received: from smtp1.infineon.com ([194.175.117.76]) by ietf-mx with esmtp (Exim 4.12) id 1B2YRd-0001vU-00; Sun, 14 Mar 2004 11:26:33 -0500 Received: from mucse012.eu.infineon.com (mucse012.ifx-mail1.com [172.29.27.229]) by smtp1.infineon.com (8.12.10/8.12.10) with ESMTP id i2EGKVCY009742; Sun, 14 Mar 2004 17:20:31 +0100 (MET) Received: by mucse012.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Mar 2004 17:25:34 +0100 Message-ID: To: EdwardB@actelis.com, rray@pesa.com Cc: adslmib@ietf.org, dromasca@avaya.com, hubmib@ietf.org, sneedmike@hotmail.com Date: Sun, 14 Mar 2004 17:20:39 +0100 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.6 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Hubmib] RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Edward, I agree with Bob. There is a lot of duplication work going on. The hubmib WG charter clearly states and I quote: "The working group will also take into consideration management objects defined by other Working Groups in the IETF (ADSL MIB for example), or other standard bodies (G.983.2), will avoid work duplication, and describe the relationship with these specifications." In my humble opinion, all of us ADSLMIB WG and HUBMIB WG need to work out and define the relationship between the two MIBS and how best they be implemented together. It would be a real shame to produce a MIB that duplicates and/or does not co-exist with the VDSL and SHDSL MIBs which are already completed and implemented in equipment. I don't think that the "time frame" issue is a "real" issue and I'm sure that if both Working Groups make an effort this issue can be sorted out quickly. Regards, Menachem Dodge. Infineon Technologies Savan. -----Original Message----- From: adslmib-admin@ietf.org [mailto:adslmib-admin@ietf.org] On Behalf Of Edward Beili Sent: Saturday, March 13, 2004 1:35 AM To: 'Bob Ray ' Cc: 'adslmib mail list '; 'Romascanu, Dan (Dan) '; 'hubmib@ietf.org' Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects Bob, There's a lot of sense in your proposal, in fact I was thinking along the same lines a while ago. The connection capability tables could benefit other areas as well as the discovery stuff. And of course it is needed in G.Bond/M2DSL MIBs. The only issue I have with this is the time frame. I would like to have the EFM-CU-MIB approved around the same time as the 802.3ah is approved (summer 2004). I'm not sure it is possible if we start splitting the stuff now. That was also my problem with using your excellent VDSL and SHDSL MIBs - SHDSL.bis is not even started, besides there are some things (e.g. rate settings) that are done differently in EFM and SHDSL.bis. That was also the general feeling in the HUBMIB group and the EFM that it is better to define everything in a single MIB. So, if splitting the MIBs can be done in time, then I would go for it. Otherwise I would like to finish the EFM-CU-MIB and worry about general things later. I'm CC:'ing the HUBMIB group, for the benefit of those not subscribed to ADSLMIB, as I would like to hear their opinion as well. Regards, -Edward -----Original Message----- From: Bob Ray To: Edward Beili Cc: adslmib mail list Sent: 13/03/04 00:34 Subject: RE: [Adslmib] MIBs for ITU-T G.Bond and T1E1 M2DSL projects On Thu, 2004-03-04 at 14:11, Edward Beili wrote: > You are right of course about the bonding stuff. I would like to have the > common MIB to manage the aggregation assignment and retrieval for all of > them. Note that ifStack describes and configures actual cross-connect > between the bonded group (upper layer) and individual lines (lower layer). > Another table is needed to describe cross-connect capability, e.g. which > lines can be connected to which groups, in case there are multiple groups. > Take a look at the EFM-CU-MIB: > http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt > > Regards, > -Edward > Hi. I've been reading your draft. Really, I have! Being a co-author of the HDSL2/SDHSL MIB and of the VDSL MIB, I am disheartened by your discarding of them. But, I'll get over it! As for G.SHDSL.bis, we're addressing that... I wonder why EFM is redefining and duplicating all these objects, but don't have the clarity of vision perhaps to understand. I also wonder if many EFM vendors would end up implementing both sets of objects for a given modem (IETF model and EFM model) which would result in an increase in effort instead of a reduction in effort (you claim the EFM model has fewer objects to support). In any case, that's for the EFM guys to decide, I suppose. Ok. With THAT over with, the non-duplicated meat of your draft seems to be concerned with the "available" cross connects, which seems interesting. If I read your efmCuAvailableStackTable correctly, what you are stating is that the table contains a list of possible connections. RFC2863: For example, when the sub-layer with ifIndex value x runs over the sub-layer with ifIndex value y, then this table contains: ifStackStatus.x.y=active RFC2864: For example, when the sub-layer with ifIndex value x runs underneath the sub-layer with ifIndex value y, then this table contains: ifInvStackStatus.x.y=active You propose a new table that will report if x and y *CAN* be connected, which makes a lot of sense. You: For example, when the PCS port with ifIndex value x can be connected to run on top of the PMI with ifIndex value y, then this table contains: efcCuAvailableStackTable.x.y=active I think a draft which contains just such a table (and of course the inverse ala ifInvStackTable) would be of use in many places, not just in the EFM world. For example, in broadcast video switches. Which leads to the suggestion that perhaps two drafts (an available draft and an InvAvailable draft) are in order. I think great utility outside of EFM/DSL could be derived from such work - as long as it's interface neutral (i.e. no dsl/efm/ethernet stuff). However, I don't think the adslmib working group would be the right place for it. That is, the Interfaces MIB working group would seem to be the best place for it (is that group still formed?). I wonder if the hubmib group is the closest thing still running to that group. Bert? Mike? In short, then, my suggestions are: 1. EFM consider using existing MIBS (with the assumption that we drones in the IETF get g.shdsl.bis support going), and that 2. you create two drafts, somewhere, to implement your excellent idea of "can connect" and "inverse can connect" tables. Bob Ray _______________________________________________ Adslmib mailing list Adslmib@ietf.org https://www1.ietf.org/mailman/listinfo/adslmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 15 10:19:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02454 for ; Mon, 15 Mar 2004 10:19: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 1B2trp-0002qT-1p; Mon, 15 Mar 2004 10:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2trh-0002o4-W2 for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 10:18:54 -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 KAA02379 for ; Mon, 15 Mar 2004 10:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2trf-0005dB-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:18:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tqh-0005VO-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:17:52 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B2tph-0005JA-00; Mon, 15 Mar 2004 10:16:49 -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 i2FFCXE0012614; Mon, 15 Mar 2004 10:12:34 -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 i2FFCVE0012553; Mon, 15 Mar 2004 10:12:32 -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 Date: Mon, 15 Mar 2004 17:16:41 +0200 Message-ID: Thread-Topic: available connections thoughts Thread-Index: AcQKoCoSjyV9Hz9mS9GKkm2gGAOTtQAACEAw From: "Romascanu, Dan (Dan)" To: , "Menachem Dodge" Cc: , "adslmib mail list" , , "Mike Sneed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable As this work is a hubmib WG item, I would remind everybody who wants to = contribute to this discussion to subscribe to hubmib@ietf.org, in order = to enjoy all the replies and discussions.=20 Regards, Dan > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com] > Sent: 15 March, 2004 5:14 PM > To: Menachem Dodge > Cc: EdwardB@actelis.com; adslmib mail list; Romascanu, Dan=20 > (Dan); hubmib@ietf.org; Mike Sneed > Subject: available connections thoughts >=20 >=20 > I think the can-connect tables (Edward's efcCuAvailableStackTable > and a proposed InvAvailableTable) need something more than a > RowStatus object. That is, it would be useful to identify a > possible connection as being **administratively** blocked. That > is, that a connection is physically possible but blocked for > administrative purposes. >=20 > Expanding upon the broadcast video example I used in an earlier > email,=20 >=20 > If video input X can be connected to video output Y > then an entry would exist in the **can connect** table. >=20 > However, there may be reasons to NOT allow X to connect > to Y. The most obvious example (for me) is where a=20 > broadcast facility might not want adult video sources=20 > to EVER be connected to a religious video feed. >=20 > Less obvious examples can be constructed (i.e. data security). > Does this make sense? >=20 > Building upon this, one might have interface group constructs > and group level blocking - group A can connect to group B, but > group A cannot connect to anything from group C. >=20 > Thoughts? >=20 > --=20 > Bob Ray >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 15 10:19:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02455 for ; Mon, 15 Mar 2004 10:19: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 1B2trp-0002rL-LW for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 10:19:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FFJ1bC010989 for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 10:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2trp-0002qT-1p; Mon, 15 Mar 2004 10:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2trh-0002o4-W2 for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 10:18:54 -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 KAA02379 for ; Mon, 15 Mar 2004 10:18:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2trf-0005dB-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:18:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tqh-0005VO-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:17:52 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B2tph-0005JA-00; Mon, 15 Mar 2004 10:16:49 -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 i2FFCXE0012614; Mon, 15 Mar 2004 10:12:34 -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 i2FFCVE0012553; Mon, 15 Mar 2004 10:12:32 -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 Date: Mon, 15 Mar 2004 17:16:41 +0200 Message-ID: Thread-Topic: available connections thoughts Thread-Index: AcQKoCoSjyV9Hz9mS9GKkm2gGAOTtQAACEAw From: "Romascanu, Dan (Dan)" To: , "Menachem Dodge" Cc: , "adslmib mail list" , , "Mike Sneed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable As this work is a hubmib WG item, I would remind everybody who wants to = contribute to this discussion to subscribe to hubmib@ietf.org, in order = to enjoy all the replies and discussions.=20 Regards, Dan > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com] > Sent: 15 March, 2004 5:14 PM > To: Menachem Dodge > Cc: EdwardB@actelis.com; adslmib mail list; Romascanu, Dan=20 > (Dan); hubmib@ietf.org; Mike Sneed > Subject: available connections thoughts >=20 >=20 > I think the can-connect tables (Edward's efcCuAvailableStackTable > and a proposed InvAvailableTable) need something more than a > RowStatus object. That is, it would be useful to identify a > possible connection as being **administratively** blocked. That > is, that a connection is physically possible but blocked for > administrative purposes. >=20 > Expanding upon the broadcast video example I used in an earlier > email,=20 >=20 > If video input X can be connected to video output Y > then an entry would exist in the **can connect** table. >=20 > However, there may be reasons to NOT allow X to connect > to Y. The most obvious example (for me) is where a=20 > broadcast facility might not want adult video sources=20 > to EVER be connected to a religious video feed. >=20 > Less obvious examples can be constructed (i.e. data security). > Does this make sense? >=20 > Building upon this, one might have interface group constructs > and group level blocking - group A can connect to group B, but > group A cannot connect to anything from group C. >=20 > Thoughts? >=20 > --=20 > Bob Ray >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 15 10:21:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02664 for ; Mon, 15 Mar 2004 10:21: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 1B2ttm-0003FU-Gq; Mon, 15 Mar 2004 10:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tp1-0002Bf-Nd for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 10:16:08 -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 KAA02086 for ; Mon, 15 Mar 2004 10:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2toz-0005GB-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:16:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tnx-00057g-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:15:01 -0500 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1B2tn0-0004zw-00; Mon, 15 Mar 2004 10:14:03 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i2FFE11N956103; Mon, 15 Mar 2004 09:14:01 -0600 (CST) Received: from [192.168.1.100] ([192.168.0.179]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v7.0.0.R) with ESMTP id md50000003082.msg; Mon, 15 Mar 2004 09:13:55 -0600 From: Bob Ray Reply-To: rray@pesa.com To: Menachem Dodge Cc: EdwardB@actelis.com, adslmib mail list , dromasca@avaya.com, hubmib@ietf.org, Mike Sneed In-Reply-To: References: Content-Type: text/plain Message-Id: <1079363634.2624.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 15 Mar 2004 09:13:54 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Mon, 15 Mar 2004 09:13:55 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.179 X-Return-Path: rray@pesa.com X-MDAV-Processed: pesa.com, Mon, 15 Mar 2004 09:14:00 -0600 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 Content-Transfer-Encoding: 7bit Subject: [Hubmib] available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the can-connect tables (Edward's efcCuAvailableStackTable and a proposed InvAvailableTable) need something more than a RowStatus object. That is, it would be useful to identify a possible connection as being **administratively** blocked. That is, that a connection is physically possible but blocked for administrative purposes. Expanding upon the broadcast video example I used in an earlier email, If video input X can be connected to video output Y then an entry would exist in the **can connect** table. However, there may be reasons to NOT allow X to connect to Y. The most obvious example (for me) is where a broadcast facility might not want adult video sources to EVER be connected to a religious video feed. Less obvious examples can be constructed (i.e. data security). Does this make sense? Building upon this, one might have interface group constructs and group level blocking - group A can connect to group B, but group A cannot connect to anything from group C. Thoughts? -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 15 10:21:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02666 for ; Mon, 15 Mar 2004 10:21: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 1B2ttn-0003HA-EQ for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 10:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FFL3Lt012510 for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 10:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2ttm-0003FU-Gq; Mon, 15 Mar 2004 10:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tp1-0002Bf-Nd for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 10:16:08 -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 KAA02086 for ; Mon, 15 Mar 2004 10:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2toz-0005GB-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:16:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tnx-00057g-00 for hubmib@ietf.org; Mon, 15 Mar 2004 10:15:01 -0500 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1B2tn0-0004zw-00; Mon, 15 Mar 2004 10:14:03 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i2FFE11N956103; Mon, 15 Mar 2004 09:14:01 -0600 (CST) Received: from [192.168.1.100] ([192.168.0.179]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v7.0.0.R) with ESMTP id md50000003082.msg; Mon, 15 Mar 2004 09:13:55 -0600 From: Bob Ray Reply-To: rray@pesa.com To: Menachem Dodge Cc: EdwardB@actelis.com, adslmib mail list , dromasca@avaya.com, hubmib@ietf.org, Mike Sneed In-Reply-To: References: Content-Type: text/plain Message-Id: <1079363634.2624.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 15 Mar 2004 09:13:54 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Mon, 15 Mar 2004 09:13:55 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.179 X-Return-Path: rray@pesa.com X-MDAV-Processed: pesa.com, Mon, 15 Mar 2004 09:14:00 -0600 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 Content-Transfer-Encoding: 7bit Subject: [Hubmib] available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think the can-connect tables (Edward's efcCuAvailableStackTable and a proposed InvAvailableTable) need something more than a RowStatus object. That is, it would be useful to identify a possible connection as being **administratively** blocked. That is, that a connection is physically possible but blocked for administrative purposes. Expanding upon the broadcast video example I used in an earlier email, If video input X can be connected to video output Y then an entry would exist in the **can connect** table. However, there may be reasons to NOT allow X to connect to Y. The most obvious example (for me) is where a broadcast facility might not want adult video sources to EVER be connected to a religious video feed. Less obvious examples can be constructed (i.e. data security). Does this make sense? Building upon this, one might have interface group constructs and group level blocking - group A can connect to group B, but group A cannot connect to anything from group C. Thoughts? -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 15 12:23:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11432 for ; Mon, 15 Mar 2004 12:23: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 1B2vnq-00008z-4f for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 12:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FHN2hW000528 for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 12:23:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vnp-00008A-3x; Mon, 15 Mar 2004 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vnE-00007Z-HB for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 12:22:25 -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 MAA11382 for ; Mon, 15 Mar 2004 12:22:21 -0500 (EST) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vnD-00070U-00 for hubmib@ietf.org; Mon, 15 Mar 2004 12:22:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vmX-0006vd-00 for hubmib@ietf.org; Mon, 15 Mar 2004 12:21:42 -0500 Received: from smtp2.infineon.com ([194.175.117.77]) by ietf-mx with esmtp (Exim 4.12) id 1B2vlc-0006jt-00 for hubmib@ietf.org; Mon, 15 Mar 2004 12:20:44 -0500 Received: from mucse012.eu.infineon.com (mucse012.ifx-mail1.com [172.29.27.229]) by smtp2.infineon.com (8.12.10/8.12.10) with ESMTP id i2FHI89t015607; Mon, 15 Mar 2004 18:18:08 +0100 (MET) Received: by mucse012.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 18:19:45 +0100 Message-ID: To: rray@pesa.com, Menachem.Dodge@infineon.com Cc: EdwardB@actelis.com, dromasca@avaya.com, hubmib@ietf.org, sneedmike@hotmail.com Date: Mon, 15 Mar 2004 18:14:48 +0100 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.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bob, "Administrative" blocking would certainly be a useful feature to have in addition to the physical possibility of connection. An additional field would be required in the MIB as the RowStatus is read-only and shows device capability. Regards, Menachem -----Original Message----- From: Bob Ray [mailto:rray@pesa.com] Sent: Monday, March 15, 2004 5:14 PM To: Menachem Dodge Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; hubmib@ietf.org; Mike Sneed Subject: available connections thoughts I think the can-connect tables (Edward's efcCuAvailableStackTable and a proposed InvAvailableTable) need something more than a RowStatus object. That is, it would be useful to identify a possible connection as being **administratively** blocked. That is, that a connection is physically possible but blocked for administrative purposes. Expanding upon the broadcast video example I used in an earlier email, If video input X can be connected to video output Y then an entry would exist in the **can connect** table. However, there may be reasons to NOT allow X to connect to Y. The most obvious example (for me) is where a broadcast facility might not want adult video sources to EVER be connected to a religious video feed. Less obvious examples can be constructed (i.e. data security). Does this make sense? Building upon this, one might have interface group constructs and group level blocking - group A can connect to group B, but group A cannot connect to anything from group C. Thoughts? -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 15 12:23:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11430 for ; Mon, 15 Mar 2004 12:23: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 1B2vnp-00008A-3x; Mon, 15 Mar 2004 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2vnE-00007Z-HB for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 12:22:25 -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 MAA11382 for ; Mon, 15 Mar 2004 12:22:21 -0500 (EST) From: Menachem.Dodge@infineon.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2vnD-00070U-00 for hubmib@ietf.org; Mon, 15 Mar 2004 12:22:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2vmX-0006vd-00 for hubmib@ietf.org; Mon, 15 Mar 2004 12:21:42 -0500 Received: from smtp2.infineon.com ([194.175.117.77]) by ietf-mx with esmtp (Exim 4.12) id 1B2vlc-0006jt-00 for hubmib@ietf.org; Mon, 15 Mar 2004 12:20:44 -0500 Received: from mucse012.eu.infineon.com (mucse012.ifx-mail1.com [172.29.27.229]) by smtp2.infineon.com (8.12.10/8.12.10) with ESMTP id i2FHI89t015607; Mon, 15 Mar 2004 18:18:08 +0100 (MET) Received: by mucse012.eu.infineon.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Mar 2004 18:19:45 +0100 Message-ID: To: rray@pesa.com, Menachem.Dodge@infineon.com Cc: EdwardB@actelis.com, dromasca@avaya.com, hubmib@ietf.org, sneedmike@hotmail.com Date: Mon, 15 Mar 2004 18:14:48 +0100 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.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bob, "Administrative" blocking would certainly be a useful feature to have in addition to the physical possibility of connection. An additional field would be required in the MIB as the RowStatus is read-only and shows device capability. Regards, Menachem -----Original Message----- From: Bob Ray [mailto:rray@pesa.com] Sent: Monday, March 15, 2004 5:14 PM To: Menachem Dodge Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; hubmib@ietf.org; Mike Sneed Subject: available connections thoughts I think the can-connect tables (Edward's efcCuAvailableStackTable and a proposed InvAvailableTable) need something more than a RowStatus object. That is, it would be useful to identify a possible connection as being **administratively** blocked. That is, that a connection is physically possible but blocked for administrative purposes. Expanding upon the broadcast video example I used in an earlier email, If video input X can be connected to video output Y then an entry would exist in the **can connect** table. However, there may be reasons to NOT allow X to connect to Y. The most obvious example (for me) is where a broadcast facility might not want adult video sources to EVER be connected to a religious video feed. Less obvious examples can be constructed (i.e. data security). Does this make sense? Building upon this, one might have interface group constructs and group level blocking - group A can connect to group B, but group A cannot connect to anything from group C. Thoughts? -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 15 17:04:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00805 for ; Mon, 15 Mar 2004 17:04: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 1B30Bm-00084I-P3; Mon, 15 Mar 2004 17:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30B9-00080V-Fw for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 17:03:24 -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 RAA00790 for ; Mon, 15 Mar 2004 17:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30B7-0003dS-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:03:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30AO-0003YS-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:02:36 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B309F-0003Q3-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:01:25 -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 i2FM0PgL025408 for ; Mon, 15 Mar 2004 17:00:25 -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 i2FM0NgL025381 for ; Mon, 15 Mar 2004 17:00:24 -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 Date: Tue, 16 Mar 2004 00:01:23 +0200 Message-ID: Thread-Topic: available connections thoughts Thread-Index: AcQKscJx7iwUV0VuQhWnyV21wb4NywAJx8hQ From: "Romascanu, Dan (Dan)" To: , Cc: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Actually this use of RowStatus in the EFM Cu MIB is not a good design, = and may not fly with the MIB Doctors.=20 Regards, Dan > -----Original Message----- > From: Menachem.Dodge@infineon.com [mailto:Menachem.Dodge@infineon.com] > Sent: 15 March, 2004 7:15 PM > To: rray@pesa.com; Menachem.Dodge@infineon.com > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan);=20 > hubmib@ietf.org; sneedmike@hotmail.com > Subject: RE: available connections thoughts >=20 >=20 > Bob, >=20 > "Administrative" blocking would certainly be a useful feature to > have in addition to the > physical possibility of connection. An additional field would=20 > be required in > the MIB as the RowStatus is read-only > and shows device capability. >=20 > Regards, > Menachem >=20 > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com]=20 > Sent: Monday, March 15, 2004 5:14 PM > To: Menachem Dodge > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > hubmib@ietf.org; Mike Sneed > Subject: available connections thoughts >=20 >=20 > I think the can-connect tables (Edward's=20 > efcCuAvailableStackTable and a > proposed InvAvailableTable) need something more than a=20 > RowStatus object. > That is, it would be useful to identify a possible connection as being > **administratively** blocked. That is, that a connection is=20 > physically > possible but blocked for administrative purposes. >=20 > Expanding upon the broadcast video example I used in an=20 > earlier email,=20 >=20 > If video input X can be connected to video output Y > then an entry would exist in the **can connect** table. >=20 > However, there may be reasons to NOT allow X to connect > to Y. The most obvious example (for me) is where a=20 > broadcast facility might not want adult video sources=20 > to EVER be connected to a religious video feed. >=20 > Less obvious examples can be constructed (i.e. data=20 > security). Does this > make sense? >=20 > Building upon this, one might have interface group constructs=20 > and group > level blocking - group A can connect to group B, but group A=20 > cannot connect > to anything from group C. >=20 > Thoughts? >=20 > --=20 > Bob Ray >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 15 17:26:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02500 for ; Mon, 15 Mar 2004 17:26: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 1B30X4-0001av-FM; Mon, 15 Mar 2004 17:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30WD-0001Xg-FZ for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 17:25: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 RAA02365 for ; Mon, 15 Mar 2004 17:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30WB-0005Wj-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:25:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30VD-0005Pc-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:24:08 -0500 Received: from bee.hiwaay.net ([216.180.54.11] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1B30UO-0005I0-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:23:17 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i2FMNFQP1471593 for ; Mon, 15 Mar 2004 16:23:16 -0600 (CST) Received: from [192.168.1.100] ([192.168.0.179]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v7.0.0.R) with ESMTP id md50000003578.msg for ; Mon, 15 Mar 2004 16:23:02 -0600 From: Bob Ray Reply-To: rray@pesa.com To: "Romascanu, Dan (Dan)" Cc: Menachem Dodge , EdwardB@actelis.com, hubmib@ietf.org, Mike Sneed In-Reply-To: References: Content-Type: text/plain Message-Id: <1079389377.2624.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 15 Mar 2004 16:22:57 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Mon, 15 Mar 2004 16:23:02 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.179 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: hubmib@ietf.org X-MDAV-Processed: pesa.com, Mon, 15 Mar 2004 16:23:15 -0600 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I meant a new textual convention or enumeration, not RowStatus. Similar, I suppose in some ways, but capable of handling adminstrative blocking. availabilityStatus.x.y = blocked or availabilityStatus.x.y = available or availabilityStatus.x.y = inUse or availabilityStatus.x.y = nonexistant Note that "nonexistant" implies that the hypothetical "can connect" table would track that two interfaces cannot physically be connected, which seems kinda pointless. In fact, in the prior discussion, there was no real need for RowStatus other than to have something in the table. Either the tuple was there or it wasn't, correct? That is, it was either "active" or not there. So, I'm suggesting something on the order of... canConnectEntry OBJECT-TYPE blah blah INDEX { ifIndex, ifIndex } CanConnectEntry ::= SEQUENCE { availabilityStatus Integer32 } availabilityStatus OBJECT-TYPE SYNTAX Integer32 { available(1), -- can be connected inUse(2), -- exclusively connected blocked(3) -- administratively blocked } Does that make sense? Please excuse any syntactical errors, I'm just trying to communicate an idea :) Regards, Bob Ray On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote: > Actually this use of RowStatus in the EFM Cu MIB is not a good design, and may not fly with the MIB Doctors. > > Regards, > > Dan > > > > > -----Original Message----- > > From: Menachem.Dodge@infineon.com [mailto:Menachem.Dodge@infineon.com] > > Sent: 15 March, 2004 7:15 PM > > To: rray@pesa.com; Menachem.Dodge@infineon.com > > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan); > > hubmib@ietf.org; sneedmike@hotmail.com > > Subject: RE: available connections thoughts > > > > > > Bob, > > > > "Administrative" blocking would certainly be a useful feature to > > have in addition to the > > physical possibility of connection. An additional field would > > be required in > > the MIB as the RowStatus is read-only > > and shows device capability. > > > > Regards, > > Menachem > > > > -----Original Message----- > > From: Bob Ray [mailto:rray@pesa.com] > > Sent: Monday, March 15, 2004 5:14 PM > > To: Menachem Dodge > > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > > hubmib@ietf.org; Mike Sneed > > Subject: available connections thoughts > > > > > > I think the can-connect tables (Edward's > > efcCuAvailableStackTable and a > > proposed InvAvailableTable) need something more than a > > RowStatus object. > > That is, it would be useful to identify a possible connection as being > > **administratively** blocked. That is, that a connection is > > physically > > possible but blocked for administrative purposes. > > > > Expanding upon the broadcast video example I used in an > > earlier email, > > > > If video input X can be connected to video output Y > > then an entry would exist in the **can connect** table. > > > > However, there may be reasons to NOT allow X to connect > > to Y. The most obvious example (for me) is where a > > broadcast facility might not want adult video sources > > to EVER be connected to a religious video feed. > > > > Less obvious examples can be constructed (i.e. data > > security). Does this > > make sense? > > > > Building upon this, one might have interface group constructs > > and group > > level blocking - group A can connect to group B, but group A > > cannot connect > > to anything from group C. > > > > Thoughts? > > > > -- > > Bob Ray > > > > -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 15 17:26:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02510 for ; Mon, 15 Mar 2004 17:26: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 1B30X5-0001bw-8u for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 17:26:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FMQ20P006147 for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 17:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30X4-0001av-FM; Mon, 15 Mar 2004 17:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30WD-0001Xg-FZ for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 17:25: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 RAA02365 for ; Mon, 15 Mar 2004 17:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30WB-0005Wj-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:25:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30VD-0005Pc-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:24:08 -0500 Received: from bee.hiwaay.net ([216.180.54.11] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1B30UO-0005I0-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:23:17 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i2FMNFQP1471593 for ; Mon, 15 Mar 2004 16:23:16 -0600 (CST) Received: from [192.168.1.100] ([192.168.0.179]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v7.0.0.R) with ESMTP id md50000003578.msg for ; Mon, 15 Mar 2004 16:23:02 -0600 From: Bob Ray Reply-To: rray@pesa.com To: "Romascanu, Dan (Dan)" Cc: Menachem Dodge , EdwardB@actelis.com, hubmib@ietf.org, Mike Sneed In-Reply-To: References: Content-Type: text/plain Message-Id: <1079389377.2624.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Mon, 15 Mar 2004 16:22:57 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Mon, 15 Mar 2004 16:23:02 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.179 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: hubmib@ietf.org X-MDAV-Processed: pesa.com, Mon, 15 Mar 2004 16:23:15 -0600 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I meant a new textual convention or enumeration, not RowStatus. Similar, I suppose in some ways, but capable of handling adminstrative blocking. availabilityStatus.x.y = blocked or availabilityStatus.x.y = available or availabilityStatus.x.y = inUse or availabilityStatus.x.y = nonexistant Note that "nonexistant" implies that the hypothetical "can connect" table would track that two interfaces cannot physically be connected, which seems kinda pointless. In fact, in the prior discussion, there was no real need for RowStatus other than to have something in the table. Either the tuple was there or it wasn't, correct? That is, it was either "active" or not there. So, I'm suggesting something on the order of... canConnectEntry OBJECT-TYPE blah blah INDEX { ifIndex, ifIndex } CanConnectEntry ::= SEQUENCE { availabilityStatus Integer32 } availabilityStatus OBJECT-TYPE SYNTAX Integer32 { available(1), -- can be connected inUse(2), -- exclusively connected blocked(3) -- administratively blocked } Does that make sense? Please excuse any syntactical errors, I'm just trying to communicate an idea :) Regards, Bob Ray On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote: > Actually this use of RowStatus in the EFM Cu MIB is not a good design, and may not fly with the MIB Doctors. > > Regards, > > Dan > > > > > -----Original Message----- > > From: Menachem.Dodge@infineon.com [mailto:Menachem.Dodge@infineon.com] > > Sent: 15 March, 2004 7:15 PM > > To: rray@pesa.com; Menachem.Dodge@infineon.com > > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan); > > hubmib@ietf.org; sneedmike@hotmail.com > > Subject: RE: available connections thoughts > > > > > > Bob, > > > > "Administrative" blocking would certainly be a useful feature to > > have in addition to the > > physical possibility of connection. An additional field would > > be required in > > the MIB as the RowStatus is read-only > > and shows device capability. > > > > Regards, > > Menachem > > > > -----Original Message----- > > From: Bob Ray [mailto:rray@pesa.com] > > Sent: Monday, March 15, 2004 5:14 PM > > To: Menachem Dodge > > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > > hubmib@ietf.org; Mike Sneed > > Subject: available connections thoughts > > > > > > I think the can-connect tables (Edward's > > efcCuAvailableStackTable and a > > proposed InvAvailableTable) need something more than a > > RowStatus object. > > That is, it would be useful to identify a possible connection as being > > **administratively** blocked. That is, that a connection is > > physically > > possible but blocked for administrative purposes. > > > > Expanding upon the broadcast video example I used in an > > earlier email, > > > > If video input X can be connected to video output Y > > then an entry would exist in the **can connect** table. > > > > However, there may be reasons to NOT allow X to connect > > to Y. The most obvious example (for me) is where a > > broadcast facility might not want adult video sources > > to EVER be connected to a religious video feed. > > > > Less obvious examples can be constructed (i.e. data > > security). Does this > > make sense? > > > > Building upon this, one might have interface group constructs > > and group > > level blocking - group A can connect to group B, but group A > > cannot connect > > to anything from group C. > > > > Thoughts? > > > > -- > > Bob Ray > > > > -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 15 17:39:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03863 for ; Mon, 15 Mar 2004 17:39: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 1B30je-0003D0-IZ; Mon, 15 Mar 2004 17:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30j9-00039X-Vj for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 17:38:32 -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 RAA03742 for ; Mon, 15 Mar 2004 17:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30j7-00078V-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30i0-0006y8-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:37:21 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B30gv-0006nG-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:36:13 -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 i2FMZDgL008917 for ; Mon, 15 Mar 2004 17:35:13 -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 i2FMZBgL008860 for ; Mon, 15 Mar 2004 17:35:12 -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 Date: Tue, 16 Mar 2004 00:36:11 +0200 Message-ID: Thread-Topic: available connections thoughts Thread-Index: AcQK3CA5jnMkacFXQwa6FTxOgXOXDgAASWAg From: "Romascanu, Dan (Dan)" To: Cc: "Menachem Dodge" , , , "Mike Sneed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This is better. However, your proposal lights another warning beacon for = me. Would not this 'nonexistent' value lead to an un-justified = multiplication of the number of rows? We should be careful here. The = ifStack like models have little deployment today, and the concern about = the multiplication of the number of entries in devices with multiple = overlayed interfaces may be related. What is the opertional benefit from = having a 'nonexistant' enumerated value defined? Thanks and Regards, Dan > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com] > Sent: 16 March, 2004 12:23 AM > To: Romascanu, Dan (Dan) > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > Subject: RE: available connections thoughts >=20 >=20 > I meant a new textual convention or enumeration, not=20 > RowStatus. Similar, I suppose in some ways, but capable=20 > of handling adminstrative blocking. >=20 > availabilityStatus.x.y =3D blocked > or availabilityStatus.x.y =3D available > or availabilityStatus.x.y =3D inUse > or availabilityStatus.x.y =3D nonexistant=20 >=20 > Note that "nonexistant" implies that the hypothetical=20 > "can connect" table would track that two interfaces cannot > physically be connected, which seems kinda pointless. =20 >=20 > In fact, in the prior discussion, there was no real > need for RowStatus other than to have something in the > table. Either the tuple was there or it wasn't, correct? > That is, it was either "active" or not there. >=20 > So, I'm suggesting something on the order of... >=20 > canConnectEntry OBJECT-TYPE > blah blah > INDEX { ifIndex, ifIndex } >=20 > CanConnectEntry ::=3D > SEQUENCE > { > availabilityStatus Integer32 > } >=20 > availabilityStatus OBJECT-TYPE > SYNTAX Integer32 > { > available(1), -- can be connected > inUse(2), -- exclusively connected > blocked(3) -- administratively blocked > } >=20 > Does that make sense? Please excuse any syntactical errors, > I'm just trying to communicate an idea :) >=20 > Regards, > Bob Ray >=20 > On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote: > > Actually this use of RowStatus in the EFM Cu MIB is not a=20 > good design, and may not fly with the MIB Doctors.=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Menachem.Dodge@infineon.com=20 > [mailto:Menachem.Dodge@infineon.com] > > > Sent: 15 March, 2004 7:15 PM > > > To: rray@pesa.com; Menachem.Dodge@infineon.com > > > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan);=20 > > > hubmib@ietf.org; sneedmike@hotmail.com > > > Subject: RE: available connections thoughts > > >=20 > > >=20 > > > Bob, > > >=20 > > > "Administrative" blocking would certainly be a useful feature to > > > have in addition to the > > > physical possibility of connection. An additional field would=20 > > > be required in > > > the MIB as the RowStatus is read-only > > > and shows device capability. > > >=20 > > > Regards, > > > Menachem > > >=20 > > > -----Original Message----- > > > From: Bob Ray [mailto:rray@pesa.com]=20 > > > Sent: Monday, March 15, 2004 5:14 PM > > > To: Menachem Dodge > > > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > > > hubmib@ietf.org; Mike Sneed > > > Subject: available connections thoughts > > >=20 > > >=20 > > > I think the can-connect tables (Edward's=20 > > > efcCuAvailableStackTable and a > > > proposed InvAvailableTable) need something more than a=20 > > > RowStatus object. > > > That is, it would be useful to identify a possible=20 > connection as being > > > **administratively** blocked. That is, that a connection is=20 > > > physically > > > possible but blocked for administrative purposes. > > >=20 > > > Expanding upon the broadcast video example I used in an=20 > > > earlier email,=20 > > >=20 > > > If video input X can be connected to video output Y > > > then an entry would exist in the **can connect** table. > > >=20 > > > However, there may be reasons to NOT allow X to connect > > > to Y. The most obvious example (for me) is where a=20 > > > broadcast facility might not want adult video sources=20 > > > to EVER be connected to a religious video feed. > > >=20 > > > Less obvious examples can be constructed (i.e. data=20 > > > security). Does this > > > make sense? > > >=20 > > > Building upon this, one might have interface group constructs=20 > > > and group > > > level blocking - group A can connect to group B, but group A=20 > > > cannot connect > > > to anything from group C. > > >=20 > > > Thoughts? > > >=20 > > > --=20 > > > Bob Ray > > >=20 > > >=20 > --=20 > Bob Ray >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 15 17:51:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00813 for ; Mon, 15 Mar 2004 17:04: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 1B30Bn-00084Y-Ia for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 17:04:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FM43Vx031030 for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 17:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30Bm-00084I-P3; Mon, 15 Mar 2004 17:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30B9-00080V-Fw for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 17:03:24 -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 RAA00790 for ; Mon, 15 Mar 2004 17:03:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30B7-0003dS-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:03:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30AO-0003YS-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:02:36 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B309F-0003Q3-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:01:25 -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 i2FM0PgL025408 for ; Mon, 15 Mar 2004 17:00:25 -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 i2FM0NgL025381 for ; Mon, 15 Mar 2004 17:00:24 -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 Date: Tue, 16 Mar 2004 00:01:23 +0200 Message-ID: Thread-Topic: available connections thoughts Thread-Index: AcQKscJx7iwUV0VuQhWnyV21wb4NywAJx8hQ From: "Romascanu, Dan (Dan)" To: , Cc: , , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Actually this use of RowStatus in the EFM Cu MIB is not a good design, = and may not fly with the MIB Doctors.=20 Regards, Dan > -----Original Message----- > From: Menachem.Dodge@infineon.com [mailto:Menachem.Dodge@infineon.com] > Sent: 15 March, 2004 7:15 PM > To: rray@pesa.com; Menachem.Dodge@infineon.com > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan);=20 > hubmib@ietf.org; sneedmike@hotmail.com > Subject: RE: available connections thoughts >=20 >=20 > Bob, >=20 > "Administrative" blocking would certainly be a useful feature to > have in addition to the > physical possibility of connection. An additional field would=20 > be required in > the MIB as the RowStatus is read-only > and shows device capability. >=20 > Regards, > Menachem >=20 > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com]=20 > Sent: Monday, March 15, 2004 5:14 PM > To: Menachem Dodge > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > hubmib@ietf.org; Mike Sneed > Subject: available connections thoughts >=20 >=20 > I think the can-connect tables (Edward's=20 > efcCuAvailableStackTable and a > proposed InvAvailableTable) need something more than a=20 > RowStatus object. > That is, it would be useful to identify a possible connection as being > **administratively** blocked. That is, that a connection is=20 > physically > possible but blocked for administrative purposes. >=20 > Expanding upon the broadcast video example I used in an=20 > earlier email,=20 >=20 > If video input X can be connected to video output Y > then an entry would exist in the **can connect** table. >=20 > However, there may be reasons to NOT allow X to connect > to Y. The most obvious example (for me) is where a=20 > broadcast facility might not want adult video sources=20 > to EVER be connected to a religious video feed. >=20 > Less obvious examples can be constructed (i.e. data=20 > security). Does this > make sense? >=20 > Building upon this, one might have interface group constructs=20 > and group > level blocking - group A can connect to group B, but group A=20 > cannot connect > to anything from group C. >=20 > Thoughts? >=20 > --=20 > Bob Ray >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Mar 15 18:25:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06678 for ; Mon, 15 Mar 2004 18:25: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 1B31SA-00045M-47; Mon, 15 Mar 2004 18:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31RR-00044F-Md for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 18:24:18 -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 SAA06586 for ; Mon, 15 Mar 2004 18:24:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31RO-0001xZ-00 for hubmib@ietf.org; Mon, 15 Mar 2004 18:24:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31QU-0001uM-00 for hubmib@ietf.org; Mon, 15 Mar 2004 18:23:18 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B31PX-0001op-00 for hubmib@ietf.org; Mon, 15 Mar 2004 18:22:19 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2FNLdc19793 for ; Mon, 15 Mar 2004 17:21:42 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699T9RD>; Tue, 16 Mar 2004 00:21:38 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C9DA14@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , rray@pesa.com Cc: Menachem Dodge , EdwardB@actelis.com, hubmib@ietf.org, Mike Sneed Subject: RE: [Hubmib] RE: available connections thoughts Date: Tue, 16 Mar 2004 00:21:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I wonder if this discussion does not belong on ifmib mailing list? Thanks, Bert > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: maandag 15 maart 2004 23:36 > To: rray@pesa.com > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > Subject: [Hubmib] RE: available connections thoughts > > > This is better. However, your proposal lights another warning > beacon for me. Would not this 'nonexistent' value lead to an > un-justified multiplication of the number of rows? We should > be careful here. The ifStack like models have little > deployment today, and the concern about the multiplication of > the number of entries in devices with multiple overlayed > interfaces may be related. What is the opertional benefit > from having a 'nonexistant' enumerated value defined? > > Thanks and Regards, > > Dan > > > > > -----Original Message----- > > From: Bob Ray [mailto:rray@pesa.com] > > Sent: 16 March, 2004 12:23 AM > > To: Romascanu, Dan (Dan) > > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > > Subject: RE: available connections thoughts > > > > > > I meant a new textual convention or enumeration, not > > RowStatus. Similar, I suppose in some ways, but capable > > of handling adminstrative blocking. > > > > availabilityStatus.x.y = blocked > > or availabilityStatus.x.y = available > > or availabilityStatus.x.y = inUse > > or availabilityStatus.x.y = nonexistant > > > > Note that "nonexistant" implies that the hypothetical > > "can connect" table would track that two interfaces cannot > > physically be connected, which seems kinda pointless. > > > > In fact, in the prior discussion, there was no real > > need for RowStatus other than to have something in the > > table. Either the tuple was there or it wasn't, correct? > > That is, it was either "active" or not there. > > > > So, I'm suggesting something on the order of... > > > > canConnectEntry OBJECT-TYPE > > blah blah > > INDEX { ifIndex, ifIndex } > > > > CanConnectEntry ::= > > SEQUENCE > > { > > availabilityStatus Integer32 > > } > > > > availabilityStatus OBJECT-TYPE > > SYNTAX Integer32 > > { > > available(1), -- can be connected > > inUse(2), -- exclusively connected > > blocked(3) -- administratively blocked > > } > > > > Does that make sense? Please excuse any syntactical errors, > > I'm just trying to communicate an idea :) > > > > Regards, > > Bob Ray > > > > On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote: > > > Actually this use of RowStatus in the EFM Cu MIB is not a > > good design, and may not fly with the MIB Doctors. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > From: Menachem.Dodge@infineon.com > > [mailto:Menachem.Dodge@infineon.com] > > > > Sent: 15 March, 2004 7:15 PM > > > > To: rray@pesa.com; Menachem.Dodge@infineon.com > > > > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan); > > > > hubmib@ietf.org; sneedmike@hotmail.com > > > > Subject: RE: available connections thoughts > > > > > > > > > > > > Bob, > > > > > > > > "Administrative" blocking would certainly be a > useful feature to > > > > have in addition to the > > > > physical possibility of connection. An additional field would > > > > be required in > > > > the MIB as the RowStatus is read-only > > > > and shows device capability. > > > > > > > > Regards, > > > > Menachem > > > > > > > > -----Original Message----- > > > > From: Bob Ray [mailto:rray@pesa.com] > > > > Sent: Monday, March 15, 2004 5:14 PM > > > > To: Menachem Dodge > > > > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > > > > hubmib@ietf.org; Mike Sneed > > > > Subject: available connections thoughts > > > > > > > > > > > > I think the can-connect tables (Edward's > > > > efcCuAvailableStackTable and a > > > > proposed InvAvailableTable) need something more than a > > > > RowStatus object. > > > > That is, it would be useful to identify a possible > > connection as being > > > > **administratively** blocked. That is, that a connection is > > > > physically > > > > possible but blocked for administrative purposes. > > > > > > > > Expanding upon the broadcast video example I used in an > > > > earlier email, > > > > > > > > If video input X can be connected to video output Y > > > > then an entry would exist in the **can connect** table. > > > > > > > > However, there may be reasons to NOT allow X to connect > > > > to Y. The most obvious example (for me) is where a > > > > broadcast facility might not want adult video sources > > > > to EVER be connected to a religious video feed. > > > > > > > > Less obvious examples can be constructed (i.e. data > > > > security). Does this > > > > make sense? > > > > > > > > Building upon this, one might have interface group constructs > > > > and group > > > > level blocking - group A can connect to group B, but group A > > > > cannot connect > > > > to anything from group C. > > > > > > > > Thoughts? > > > > > > > > -- > > > > Bob Ray > > > > > > > > > > -- > > Bob Ray > > > > > > > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 15 18:25:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06685 for ; Mon, 15 Mar 2004 18:25: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 1B31SB-00046J-5x for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 18:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FNP3UM015743 for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 18: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 1B31SA-00045M-47; Mon, 15 Mar 2004 18:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B31RR-00044F-Md for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 18:24:18 -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 SAA06586 for ; Mon, 15 Mar 2004 18:24:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B31RO-0001xZ-00 for hubmib@ietf.org; Mon, 15 Mar 2004 18:24:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B31QU-0001uM-00 for hubmib@ietf.org; Mon, 15 Mar 2004 18:23:18 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B31PX-0001op-00 for hubmib@ietf.org; Mon, 15 Mar 2004 18:22:19 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2FNLdc19793 for ; Mon, 15 Mar 2004 17:21:42 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699T9RD>; Tue, 16 Mar 2004 00:21:38 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C9DA14@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , rray@pesa.com Cc: Menachem Dodge , EdwardB@actelis.com, hubmib@ietf.org, Mike Sneed Subject: RE: [Hubmib] RE: available connections thoughts Date: Tue, 16 Mar 2004 00:21:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" 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=AWL autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I wonder if this discussion does not belong on ifmib mailing list? Thanks, Bert > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: maandag 15 maart 2004 23:36 > To: rray@pesa.com > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > Subject: [Hubmib] RE: available connections thoughts > > > This is better. However, your proposal lights another warning > beacon for me. Would not this 'nonexistent' value lead to an > un-justified multiplication of the number of rows? We should > be careful here. The ifStack like models have little > deployment today, and the concern about the multiplication of > the number of entries in devices with multiple overlayed > interfaces may be related. What is the opertional benefit > from having a 'nonexistant' enumerated value defined? > > Thanks and Regards, > > Dan > > > > > -----Original Message----- > > From: Bob Ray [mailto:rray@pesa.com] > > Sent: 16 March, 2004 12:23 AM > > To: Romascanu, Dan (Dan) > > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > > Subject: RE: available connections thoughts > > > > > > I meant a new textual convention or enumeration, not > > RowStatus. Similar, I suppose in some ways, but capable > > of handling adminstrative blocking. > > > > availabilityStatus.x.y = blocked > > or availabilityStatus.x.y = available > > or availabilityStatus.x.y = inUse > > or availabilityStatus.x.y = nonexistant > > > > Note that "nonexistant" implies that the hypothetical > > "can connect" table would track that two interfaces cannot > > physically be connected, which seems kinda pointless. > > > > In fact, in the prior discussion, there was no real > > need for RowStatus other than to have something in the > > table. Either the tuple was there or it wasn't, correct? > > That is, it was either "active" or not there. > > > > So, I'm suggesting something on the order of... > > > > canConnectEntry OBJECT-TYPE > > blah blah > > INDEX { ifIndex, ifIndex } > > > > CanConnectEntry ::= > > SEQUENCE > > { > > availabilityStatus Integer32 > > } > > > > availabilityStatus OBJECT-TYPE > > SYNTAX Integer32 > > { > > available(1), -- can be connected > > inUse(2), -- exclusively connected > > blocked(3) -- administratively blocked > > } > > > > Does that make sense? Please excuse any syntactical errors, > > I'm just trying to communicate an idea :) > > > > Regards, > > Bob Ray > > > > On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote: > > > Actually this use of RowStatus in the EFM Cu MIB is not a > > good design, and may not fly with the MIB Doctors. > > > > > > Regards, > > > > > > Dan > > > > > > > > > > > > > -----Original Message----- > > > > From: Menachem.Dodge@infineon.com > > [mailto:Menachem.Dodge@infineon.com] > > > > Sent: 15 March, 2004 7:15 PM > > > > To: rray@pesa.com; Menachem.Dodge@infineon.com > > > > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan); > > > > hubmib@ietf.org; sneedmike@hotmail.com > > > > Subject: RE: available connections thoughts > > > > > > > > > > > > Bob, > > > > > > > > "Administrative" blocking would certainly be a > useful feature to > > > > have in addition to the > > > > physical possibility of connection. An additional field would > > > > be required in > > > > the MIB as the RowStatus is read-only > > > > and shows device capability. > > > > > > > > Regards, > > > > Menachem > > > > > > > > -----Original Message----- > > > > From: Bob Ray [mailto:rray@pesa.com] > > > > Sent: Monday, March 15, 2004 5:14 PM > > > > To: Menachem Dodge > > > > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > > > > hubmib@ietf.org; Mike Sneed > > > > Subject: available connections thoughts > > > > > > > > > > > > I think the can-connect tables (Edward's > > > > efcCuAvailableStackTable and a > > > > proposed InvAvailableTable) need something more than a > > > > RowStatus object. > > > > That is, it would be useful to identify a possible > > connection as being > > > > **administratively** blocked. That is, that a connection is > > > > physically > > > > possible but blocked for administrative purposes. > > > > > > > > Expanding upon the broadcast video example I used in an > > > > earlier email, > > > > > > > > If video input X can be connected to video output Y > > > > then an entry would exist in the **can connect** table. > > > > > > > > However, there may be reasons to NOT allow X to connect > > > > to Y. The most obvious example (for me) is where a > > > > broadcast facility might not want adult video sources > > > > to EVER be connected to a religious video feed. > > > > > > > > Less obvious examples can be constructed (i.e. data > > > > security). Does this > > > > make sense? > > > > > > > > Building upon this, one might have interface group constructs > > > > and group > > > > level blocking - group A can connect to group B, but group A > > > > cannot connect > > > > to anything from group C. > > > > > > > > Thoughts? > > > > > > > > -- > > > > Bob Ray > > > > > > > > > > -- > > Bob Ray > > > > > > > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Mar 15 18:26:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03865 for ; Mon, 15 Mar 2004 17:39: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 1B30je-0003DW-PI for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 17:39:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FMd2iJ012344 for hubmib-archive@odin.ietf.org; Mon, 15 Mar 2004 17:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30je-0003D0-IZ; Mon, 15 Mar 2004 17:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B30j9-00039X-Vj for hubmib@optimus.ietf.org; Mon, 15 Mar 2004 17:38:32 -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 RAA03742 for ; Mon, 15 Mar 2004 17:38:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B30j7-00078V-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:38:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B30i0-0006y8-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:37:21 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B30gv-0006nG-00 for hubmib@ietf.org; Mon, 15 Mar 2004 17:36:13 -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 i2FMZDgL008917 for ; Mon, 15 Mar 2004 17:35:13 -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 i2FMZBgL008860 for ; Mon, 15 Mar 2004 17:35:12 -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 Date: Tue, 16 Mar 2004 00:36:11 +0200 Message-ID: Thread-Topic: available connections thoughts Thread-Index: AcQK3CA5jnMkacFXQwa6FTxOgXOXDgAASWAg From: "Romascanu, Dan (Dan)" To: Cc: "Menachem Dodge" , , , "Mike Sneed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: available connections thoughts Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable This is better. However, your proposal lights another warning beacon for = me. Would not this 'nonexistent' value lead to an un-justified = multiplication of the number of rows? We should be careful here. The = ifStack like models have little deployment today, and the concern about = the multiplication of the number of entries in devices with multiple = overlayed interfaces may be related. What is the opertional benefit from = having a 'nonexistant' enumerated value defined? Thanks and Regards, Dan > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com] > Sent: 16 March, 2004 12:23 AM > To: Romascanu, Dan (Dan) > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > Subject: RE: available connections thoughts >=20 >=20 > I meant a new textual convention or enumeration, not=20 > RowStatus. Similar, I suppose in some ways, but capable=20 > of handling adminstrative blocking. >=20 > availabilityStatus.x.y =3D blocked > or availabilityStatus.x.y =3D available > or availabilityStatus.x.y =3D inUse > or availabilityStatus.x.y =3D nonexistant=20 >=20 > Note that "nonexistant" implies that the hypothetical=20 > "can connect" table would track that two interfaces cannot > physically be connected, which seems kinda pointless. =20 >=20 > In fact, in the prior discussion, there was no real > need for RowStatus other than to have something in the > table. Either the tuple was there or it wasn't, correct? > That is, it was either "active" or not there. >=20 > So, I'm suggesting something on the order of... >=20 > canConnectEntry OBJECT-TYPE > blah blah > INDEX { ifIndex, ifIndex } >=20 > CanConnectEntry ::=3D > SEQUENCE > { > availabilityStatus Integer32 > } >=20 > availabilityStatus OBJECT-TYPE > SYNTAX Integer32 > { > available(1), -- can be connected > inUse(2), -- exclusively connected > blocked(3) -- administratively blocked > } >=20 > Does that make sense? Please excuse any syntactical errors, > I'm just trying to communicate an idea :) >=20 > Regards, > Bob Ray >=20 > On Mon, 2004-03-15 at 16:01, Romascanu, Dan (Dan) wrote: > > Actually this use of RowStatus in the EFM Cu MIB is not a=20 > good design, and may not fly with the MIB Doctors.=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Menachem.Dodge@infineon.com=20 > [mailto:Menachem.Dodge@infineon.com] > > > Sent: 15 March, 2004 7:15 PM > > > To: rray@pesa.com; Menachem.Dodge@infineon.com > > > Cc: EdwardB@actelis.com; Romascanu, Dan (Dan);=20 > > > hubmib@ietf.org; sneedmike@hotmail.com > > > Subject: RE: available connections thoughts > > >=20 > > >=20 > > > Bob, > > >=20 > > > "Administrative" blocking would certainly be a useful feature to > > > have in addition to the > > > physical possibility of connection. An additional field would=20 > > > be required in > > > the MIB as the RowStatus is read-only > > > and shows device capability. > > >=20 > > > Regards, > > > Menachem > > >=20 > > > -----Original Message----- > > > From: Bob Ray [mailto:rray@pesa.com]=20 > > > Sent: Monday, March 15, 2004 5:14 PM > > > To: Menachem Dodge > > > Cc: EdwardB@actelis.com; adslmib mail list; dromasca@avaya.com; > > > hubmib@ietf.org; Mike Sneed > > > Subject: available connections thoughts > > >=20 > > >=20 > > > I think the can-connect tables (Edward's=20 > > > efcCuAvailableStackTable and a > > > proposed InvAvailableTable) need something more than a=20 > > > RowStatus object. > > > That is, it would be useful to identify a possible=20 > connection as being > > > **administratively** blocked. That is, that a connection is=20 > > > physically > > > possible but blocked for administrative purposes. > > >=20 > > > Expanding upon the broadcast video example I used in an=20 > > > earlier email,=20 > > >=20 > > > If video input X can be connected to video output Y > > > then an entry would exist in the **can connect** table. > > >=20 > > > However, there may be reasons to NOT allow X to connect > > > to Y. The most obvious example (for me) is where a=20 > > > broadcast facility might not want adult video sources=20 > > > to EVER be connected to a religious video feed. > > >=20 > > > Less obvious examples can be constructed (i.e. data=20 > > > security). Does this > > > make sense? > > >=20 > > > Building upon this, one might have interface group constructs=20 > > > and group > > > level blocking - group A can connect to group B, but group A=20 > > > cannot connect > > > to anything from group C. > > >=20 > > > Thoughts? > > >=20 > > > --=20 > > > Bob Ray > > >=20 > > >=20 > --=20 > Bob Ray >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Mar 16 08:35:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00337 for ; Tue, 16 Mar 2004 08:35: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 1B3Eil-00085R-5B; Tue, 16 Mar 2004 08:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EiN-000830-Lf for hubmib@optimus.ietf.org; Tue, 16 Mar 2004 08:34:39 -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 IAA00226 for ; Tue, 16 Mar 2004 08:34:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EiM-0003i0-00 for hubmib@ietf.org; Tue, 16 Mar 2004 08:34:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EhN-0003a0-00 for hubmib@ietf.org; Tue, 16 Mar 2004 08:33:38 -0500 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1B3EgQ-0003Tm-00 for hubmib@ietf.org; Tue, 16 Mar 2004 08:32:38 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i2GDWabN764890 for ; Tue, 16 Mar 2004 07:32:36 -0600 (CST) Received: from [192.168.1.100] ([192.168.0.179]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v7.0.0.R) with ESMTP id md50000003795.msg for ; Tue, 16 Mar 2004 07:32:33 -0600 Subject: Re: [Hubmib] RE: available connections thoughts From: Bob Ray Reply-To: rray@pesa.com To: "Romascanu, Dan (Dan)" Cc: Menachem Dodge , EdwardB@actelis.com, hubmib@ietf.org, Mike Sneed In-Reply-To: References: Content-Type: text/plain Message-Id: <1079443949.2628.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 16 Mar 2004 07:32:29 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Tue, 16 Mar 2004 07:32:33 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.179 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: hubmib@ietf.org X-MDAV-Processed: pesa.com, Tue, 16 Mar 2004 07:32:36 -0600 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote: > This is better. However, your proposal lights another warning > beacon for me. Would not this 'nonexistent' value lead to an > un-justified multiplication of the number of rows? We should be > careful here. The ifStack like models have little deployment > today, and the concern about the multiplication of the number > of entries in devices with multiple overlayed interfaces may > be related. What is the opertional benefit from having a > 'nonexistant' enumerated value defined? Anything that manages a large number of interfaces (such as an OC-3/12 to dsl bridge/router), and that is based to some degree upon the cross product of the ifTable is gonna be huge. The current ifStackTable and ifInvStackTable have entries for unconnected upper and lower interfaces. From RFC2864: "For example, two rows exist even for an interface which has no others stacked on top or below it: ifInvStackStatus.z.0=active ifInvStackStatus.0.z=active This table contains exactly the same number of rows as the ifStackTable, but the rows appear in a different order." I suspect a "nonexistant" enumeration is equivalent to the above. You may have noted my comment that: > Note that "nonexistant" implies that the hypothetical > "can connect" table would track that two interfaces cannot > physically be connected, which seems kinda pointless. In which I meant, "I see no sense to a nonexistant enumeration". Which is why I left it out of the later enumeration. :) -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Mar 16 08:35:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00346 for ; Tue, 16 Mar 2004 08:35: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 1B3Eil-00085v-T4 for hubmib-archive@odin.ietf.org; Tue, 16 Mar 2004 08:35:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GDZ3tX031102 for hubmib-archive@odin.ietf.org; Tue, 16 Mar 2004 08:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Eil-00085R-5B; Tue, 16 Mar 2004 08:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3EiN-000830-Lf for hubmib@optimus.ietf.org; Tue, 16 Mar 2004 08:34:39 -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 IAA00226 for ; Tue, 16 Mar 2004 08:34:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3EiM-0003i0-00 for hubmib@ietf.org; Tue, 16 Mar 2004 08:34:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3EhN-0003a0-00 for hubmib@ietf.org; Tue, 16 Mar 2004 08:33:38 -0500 Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net) by ietf-mx with esmtp (Exim 4.12) id 1B3EgQ-0003Tm-00 for hubmib@ietf.org; Tue, 16 Mar 2004 08:32:38 -0500 Received: from pesa.com ([216.180.38.253]) by mail.hiwaay.net (8.12.11/8.12.11) with ESMTP id i2GDWabN764890 for ; Tue, 16 Mar 2004 07:32:36 -0600 (CST) Received: from [192.168.1.100] ([192.168.0.179]) by pesa.com (pesa.com [127.0.0.1]) (MDaemon.PRO.v7.0.0.R) with ESMTP id md50000003795.msg for ; Tue, 16 Mar 2004 07:32:33 -0600 Subject: Re: [Hubmib] RE: available connections thoughts From: Bob Ray Reply-To: rray@pesa.com To: "Romascanu, Dan (Dan)" Cc: Menachem Dodge , EdwardB@actelis.com, hubmib@ietf.org, Mike Sneed In-Reply-To: References: Content-Type: text/plain Message-Id: <1079443949.2628.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Tue, 16 Mar 2004 07:32:29 -0600 Content-Transfer-Encoding: 7bit X-Spam-Processed: pesa.com, Tue, 16 Mar 2004 07:32:33 -0600 (not processed: message from valid local sender) X-MDRemoteIP: 192.168.0.179 X-Return-Path: rray@pesa.com X-MDaemon-Deliver-To: hubmib@ietf.org X-MDAV-Processed: pesa.com, Tue, 16 Mar 2004 07:32:36 -0600 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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote: > This is better. However, your proposal lights another warning > beacon for me. Would not this 'nonexistent' value lead to an > un-justified multiplication of the number of rows? We should be > careful here. The ifStack like models have little deployment > today, and the concern about the multiplication of the number > of entries in devices with multiple overlayed interfaces may > be related. What is the opertional benefit from having a > 'nonexistant' enumerated value defined? Anything that manages a large number of interfaces (such as an OC-3/12 to dsl bridge/router), and that is based to some degree upon the cross product of the ifTable is gonna be huge. The current ifStackTable and ifInvStackTable have entries for unconnected upper and lower interfaces. From RFC2864: "For example, two rows exist even for an interface which has no others stacked on top or below it: ifInvStackStatus.z.0=active ifInvStackStatus.0.z=active This table contains exactly the same number of rows as the ifStackTable, but the rows appear in a different order." I suspect a "nonexistant" enumeration is equivalent to the above. You may have noted my comment that: > Note that "nonexistant" implies that the hypothetical > "can connect" table would track that two interfaces cannot > physically be connected, which seems kinda pointless. In which I meant, "I see no sense to a nonexistant enumeration". Which is why I left it out of the later enumeration. :) -- Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Mar 16 09:19:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02187 for ; Tue, 16 Mar 2004 09:19: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 1B3FPK-00041s-S4 for hubmib-archive@odin.ietf.org; Tue, 16 Mar 2004 09:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GEJ2kV015477 for hubmib-archive@odin.ietf.org; Tue, 16 Mar 2004 09:19:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FPK-00041K-Dz; Tue, 16 Mar 2004 09:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FP2-00040P-Cf for hubmib@optimus.ietf.org; Tue, 16 Mar 2004 09:18:44 -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 JAA02163 for ; Tue, 16 Mar 2004 09:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FP0-00079O-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:18:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FO3-00074i-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:17:44 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3FNP-00070m-00; Tue, 16 Mar 2004 09:17:04 -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 i2GEClE0020366; Tue, 16 Mar 2004 09:12:47 -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 i2GECjE0020317; Tue, 16 Mar 2004 09:12:46 -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: FW: [Hubmib] RE: available connections thoughts Date: Tue, 16 Mar 2004 16:16:57 +0200 Message-ID: Thread-Topic: [Hubmib] RE: available connections thoughts Thread-Index: AcQLWym23jJ/C6yJTsyEUEzL/OCZwgABaLYA From: "Romascanu, Dan (Dan)" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable if-mibers, This discussion happening in the hubmib wg may benefit from your = feedback. The I-D in cause is = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-m= ib-00.txt. Thanks and Regards, Dan -----Original Message----- From: Bob Ray [mailto:rray@pesa.com] Sent: 16 March, 2004 3:32 PM To: Romascanu, Dan (Dan) Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed Subject: Re: [Hubmib] RE: available connections thoughts On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote: > This is better. However, your proposal lights another warning > beacon for me. Would not this 'nonexistent' value lead to an=20 > un-justified multiplication of the number of rows? We should be > careful here. The ifStack like models have little deployment=20 > today, and the concern about the multiplication of the number=20 > of entries in devices with multiple overlayed interfaces may=20 > be related. What is the opertional benefit from having a=20 > 'nonexistant' enumerated value defined? Anything that manages a large number of interfaces (such as=20 an OC-3/12 to dsl bridge/router), and that is based to some degree upon the cross product of the ifTable is gonna be huge.=20 The current ifStackTable and ifInvStackTable have entries=20 for unconnected upper and lower interfaces. From RFC2864: "For example, two rows exist even for an interface which has no others stacked on top or below it: ifInvStackStatus.z.0=3Dactive ifInvStackStatus.0.z=3Dactive This table contains exactly the same number of rows as the ifStackTable, but the rows appear in a different order." I suspect a "nonexistant" enumeration is equivalent to the above. You may have noted my comment that: > Note that "nonexistant" implies that the hypothetical=20 > "can connect" table would track that two interfaces cannot > physically be connected, which seems kinda pointless. =20 In which I meant, "I see no sense to a nonexistant enumeration". =20 Which is why I left it out of the later enumeration. :) --=20 Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Mar 16 09:19:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02186 for ; Tue, 16 Mar 2004 09:19: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 1B3FPK-00041K-Dz; Tue, 16 Mar 2004 09:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FP2-00040P-Cf for hubmib@optimus.ietf.org; Tue, 16 Mar 2004 09:18:44 -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 JAA02163 for ; Tue, 16 Mar 2004 09:18:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FP0-00079O-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:18:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FO3-00074i-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:17:44 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3FNP-00070m-00; Tue, 16 Mar 2004 09:17:04 -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 i2GEClE0020366; Tue, 16 Mar 2004 09:12:47 -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 i2GECjE0020317; Tue, 16 Mar 2004 09:12:46 -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: FW: [Hubmib] RE: available connections thoughts Date: Tue, 16 Mar 2004 16:16:57 +0200 Message-ID: Thread-Topic: [Hubmib] RE: available connections thoughts Thread-Index: AcQLWym23jJ/C6yJTsyEUEzL/OCZwgABaLYA From: "Romascanu, Dan (Dan)" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable if-mibers, This discussion happening in the hubmib wg may benefit from your = feedback. The I-D in cause is = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-m= ib-00.txt. Thanks and Regards, Dan -----Original Message----- From: Bob Ray [mailto:rray@pesa.com] Sent: 16 March, 2004 3:32 PM To: Romascanu, Dan (Dan) Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed Subject: Re: [Hubmib] RE: available connections thoughts On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote: > This is better. However, your proposal lights another warning > beacon for me. Would not this 'nonexistent' value lead to an=20 > un-justified multiplication of the number of rows? We should be > careful here. The ifStack like models have little deployment=20 > today, and the concern about the multiplication of the number=20 > of entries in devices with multiple overlayed interfaces may=20 > be related. What is the opertional benefit from having a=20 > 'nonexistant' enumerated value defined? Anything that manages a large number of interfaces (such as=20 an OC-3/12 to dsl bridge/router), and that is based to some degree upon the cross product of the ifTable is gonna be huge.=20 The current ifStackTable and ifInvStackTable have entries=20 for unconnected upper and lower interfaces. From RFC2864: "For example, two rows exist even for an interface which has no others stacked on top or below it: ifInvStackStatus.z.0=3Dactive ifInvStackStatus.0.z=3Dactive This table contains exactly the same number of rows as the ifStackTable, but the rows appear in a different order." I suspect a "nonexistant" enumeration is equivalent to the above. You may have noted my comment that: > Note that "nonexistant" implies that the hypothetical=20 > "can connect" table would track that two interfaces cannot > physically be connected, which seems kinda pointless. =20 In which I meant, "I see no sense to a nonexistant enumeration". =20 Which is why I left it out of the later enumeration. :) --=20 Bob Ray _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Mar 16 09:20:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02270 for ; Tue, 16 Mar 2004 09:20: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 1B3FQJ-00048Q-WF for hubmib-archive@odin.ietf.org; Tue, 16 Mar 2004 09:20:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GEK3Gb015836 for hubmib-archive@odin.ietf.org; Tue, 16 Mar 2004 09:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FQJ-00047E-CS; Tue, 16 Mar 2004 09:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FQ3-00045t-Tc for hubmib@optimus.ietf.org; Tue, 16 Mar 2004 09:19:47 -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 JAA02248 for ; Tue, 16 Mar 2004 09:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FQ2-0007FP-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:19:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FP7-0007AW-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:18:49 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3FO8-00075E-00; Tue, 16 Mar 2004 09:17:48 -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 i2GEGjgL024841; Tue, 16 Mar 2004 09:16:45 -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 i2GEGhgL024773; Tue, 16 Mar 2004 09:16:43 -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: [Hubmib] RE: available connections thoughts Date: Tue, 16 Mar 2004 16:17:43 +0200 Message-ID: Thread-Topic: [Hubmib] RE: available connections thoughts Thread-Index: AcQLWym23jJ/C6yJTsyEUEzL/OCZwgABaLYAAAAnBdA= From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sorry, the correct reference is = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-c= u-mib-00.txt Regards, Dan > -----Original Message----- > From: Romascanu, Dan (Dan)=20 > Sent: 16 March, 2004 4:17 PM > To: 'ifmib@ietf.org' > Cc: 'hubmib@ietf.org' > Subject: FW: [Hubmib] RE: available connections thoughts >=20 >=20 > if-mibers, >=20 > This discussion happening in the hubmib wg may benefit from=20 > your feedback. The I-D in cause is=20 > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-h > ubmib-efm-mib-00.txt. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com] > Sent: 16 March, 2004 3:32 PM > To: Romascanu, Dan (Dan) > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > Subject: Re: [Hubmib] RE: available connections thoughts >=20 >=20 > On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote: > > This is better. However, your proposal lights another warning > > beacon for me. Would not this 'nonexistent' value lead to an=20 > > un-justified multiplication of the number of rows? We should be > > careful here. The ifStack like models have little deployment=20 > > today, and the concern about the multiplication of the number=20 > > of entries in devices with multiple overlayed interfaces may=20 > > be related. What is the opertional benefit from having a=20 > > 'nonexistant' enumerated value defined? >=20 > Anything that manages a large number of interfaces (such as=20 > an OC-3/12 to dsl bridge/router), and that is based to some > degree upon the cross product of the ifTable is gonna be huge.=20 >=20 > The current ifStackTable and ifInvStackTable have entries=20 > for unconnected upper and lower interfaces. From RFC2864: >=20 > "For example, two rows exist even for an interface which has > no others stacked on top or below it: >=20 > ifInvStackStatus.z.0=3Dactive > ifInvStackStatus.0.z=3Dactive >=20 > This table contains exactly the same number of rows as the > ifStackTable, but the rows appear in a different order." >=20 > I suspect a "nonexistant" enumeration is equivalent to the above. > You may have noted my comment that: >=20 > > Note that "nonexistant" implies that the hypothetical=20 > > "can connect" table would track that two interfaces cannot > > physically be connected, which seems kinda pointless. =20 >=20 > In which I meant, "I see no sense to a nonexistant enumeration". =20 > Which is why I left it out of the later enumeration. :) >=20 > --=20 > Bob Ray >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Mar 16 10:07:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02267 for ; Tue, 16 Mar 2004 09:20: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 1B3FQJ-00047E-CS; Tue, 16 Mar 2004 09:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3FQ3-00045t-Tc for hubmib@optimus.ietf.org; Tue, 16 Mar 2004 09:19:47 -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 JAA02248 for ; Tue, 16 Mar 2004 09:19:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3FQ2-0007FP-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:19:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3FP7-0007AW-00 for hubmib@ietf.org; Tue, 16 Mar 2004 09:18:49 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3FO8-00075E-00; Tue, 16 Mar 2004 09:17:48 -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 i2GEGjgL024841; Tue, 16 Mar 2004 09:16:45 -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 i2GEGhgL024773; Tue, 16 Mar 2004 09:16:43 -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: [Hubmib] RE: available connections thoughts Date: Tue, 16 Mar 2004 16:17:43 +0200 Message-ID: Thread-Topic: [Hubmib] RE: available connections thoughts Thread-Index: AcQLWym23jJ/C6yJTsyEUEzL/OCZwgABaLYAAAAnBdA= From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sorry, the correct reference is = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-c= u-mib-00.txt Regards, Dan > -----Original Message----- > From: Romascanu, Dan (Dan)=20 > Sent: 16 March, 2004 4:17 PM > To: 'ifmib@ietf.org' > Cc: 'hubmib@ietf.org' > Subject: FW: [Hubmib] RE: available connections thoughts >=20 >=20 > if-mibers, >=20 > This discussion happening in the hubmib wg may benefit from=20 > your feedback. The I-D in cause is=20 > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-h > ubmib-efm-mib-00.txt. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 > -----Original Message----- > From: Bob Ray [mailto:rray@pesa.com] > Sent: 16 March, 2004 3:32 PM > To: Romascanu, Dan (Dan) > Cc: Menachem Dodge; EdwardB@actelis.com; hubmib@ietf.org; Mike Sneed > Subject: Re: [Hubmib] RE: available connections thoughts >=20 >=20 > On Mon, 2004-03-15 at 16:36, Romascanu, Dan (Dan) wrote: > > This is better. However, your proposal lights another warning > > beacon for me. Would not this 'nonexistent' value lead to an=20 > > un-justified multiplication of the number of rows? We should be > > careful here. The ifStack like models have little deployment=20 > > today, and the concern about the multiplication of the number=20 > > of entries in devices with multiple overlayed interfaces may=20 > > be related. What is the opertional benefit from having a=20 > > 'nonexistant' enumerated value defined? >=20 > Anything that manages a large number of interfaces (such as=20 > an OC-3/12 to dsl bridge/router), and that is based to some > degree upon the cross product of the ifTable is gonna be huge.=20 >=20 > The current ifStackTable and ifInvStackTable have entries=20 > for unconnected upper and lower interfaces. From RFC2864: >=20 > "For example, two rows exist even for an interface which has > no others stacked on top or below it: >=20 > ifInvStackStatus.z.0=3Dactive > ifInvStackStatus.0.z=3Dactive >=20 > This table contains exactly the same number of rows as the > ifStackTable, but the rows appear in a different order." >=20 > I suspect a "nonexistant" enumeration is equivalent to the above. > You may have noted my comment that: >=20 > > Note that "nonexistant" implies that the hypothetical=20 > > "can connect" table would track that two interfaces cannot > > physically be connected, which seems kinda pointless. =20 >=20 > In which I meant, "I see no sense to a nonexistant enumeration". =20 > Which is why I left it out of the later enumeration. :) >=20 > --=20 > Bob Ray >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Mar 30 18:48:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05691 for ; Tue, 30 Mar 2004 18:48:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj1-0006WI-EJ for hubmib-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i244h2Xq025035 for hubmib-archive@odin.ietf.org; Wed, 3 Mar 2004 23:43:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykhJ-0006VL-B4; Wed, 03 Mar 2004 23:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykgs-0006Jt-BU for hubmib@optimus.ietf.org; Wed, 03 Mar 2004 23:42:34 -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 XAA26427 for ; Wed, 3 Mar 2004 23:42:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykgp-00061K-00 for hubmib@ietf.org; Wed, 03 Mar 2004 23:42:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aykff-0005jQ-00 for hubmib@ietf.org; Wed, 03 Mar 2004 23:41:20 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Aykea-0005Lu-00 for hubmib@ietf.org; Wed, 03 Mar 2004 23:40:12 -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 i244dFs2029240 for ; Wed, 3 Mar 2004 23:39:15 -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 i244dDs2029225 for ; Wed, 3 Mar 2004 23:39:14 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C401A2.C6B8F1EA" Date: Thu, 4 Mar 2004 06:40:10 +0200 Message-ID: Thread-Topic: hubmib meeting at ietf 59 Thread-Index: AcQBosSw3p2DbjABSpeHHGdLkDfwxQ== From: "Romascanu, Dan (Dan)" To: , "David Kessens" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] hubmib meeting at ietf 59 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C401A2.C6B8F1EA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The Ethernet Interfaces and Hub MIB WG hold one session at the 59th IETF = meeting. About 20 people participated. The WG reviewed the changes and = open issues in the three Internet-Drafts covering the current charter of = the WG, related to the Ethernet First Mile (EFM) a.k.a. IEEE 802.3ah = technology. Recommendations concerning the edits and changes for the = next version of the Internet-Drafts were made during the meeting, and = will be included in the detailed WG minutes. The next round of = Internet-Drafts is expected to be submitted in the six weeks following = the meeting, and if they are stable enough these Internet-Drafts will go = through WG Last Call immediately after publication. Regards, Dan ------_=_NextPart_001_01C401A2.C6B8F1EA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable hubmib meeting at ietf 59

The Ethernet Interfaces and = Hub MIB WG hold one session at the 59th IETF meeting. About 20 people = participated. The WG reviewed the changes and open issues in the three = Internet-Drafts covering the current charter of the WG, related to the = Ethernet First Mile (EFM) a.k.a. IEEE 802.3ah technology. = Recommendations concerning the edits and changes for the next version of = the Internet-Drafts were made during the meeting, and will be included = in the detailed WG minutes. The next round of Internet-Drafts is = expected to be submitted in the six weeks following the meeting, and if = they are stable enough these Internet-Drafts will go through WG Last = Call immediately after publication.

Regards,

Dan

------_=_NextPart_001_01C401A2.C6B8F1EA-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib