From mailman-bounces@ietf.org Wed Dec 1 06:57:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18799 for ; Wed, 1 Dec 2004 06:57:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZTCO-0006dm-9Y for bridge-mib-archive@ietf.org; Wed, 01 Dec 2004 07:03:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSAd-0002RW-JO for bridge-mib-archive@ietf.org; Wed, 01 Dec 2004 05:57:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: bridge-mib-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:33:59 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for bridge-mib-archive@ietf.org: List Password // URL ---- -------- bridge-mib@ietf.org zopaeb https://www1.ietf.org/mailman/options/bridge-mib/bridge-mib-archive%40ietf.org From bridge-mib-bounces@ietf.org Thu Dec 9 17:00:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16355; Thu, 9 Dec 2004 17:00:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcWRZ-0002SM-Cv; Thu, 09 Dec 2004 17:07:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcW97-0002oy-Ev; Thu, 09 Dec 2004 16:48:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVh1-0000BR-Ph for bridge-mib@megatron.ietf.org; Thu, 09 Dec 2004 16:19:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05618 for ; Thu, 9 Dec 2004 16:19:18 -0500 (EST) Message-Id: <200412092119.QAA05618@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcVo4-0007Tr-8f for bridge-mib@ietf.org; Thu, 09 Dec 2004 16:26:37 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2004120921184401500eea4fe>; Thu, 9 Dec 2004 21:18:44 +0000 From: "David B Harrington" To: , "'Romascanu, Dan \(Dan\)'" Date: Thu, 9 Dec 2004 16:18:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTeNKceNGFKsT6LTLKGI4O/S2bqyg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T \(ProCurve\)'" Subject: [Bridge-mib] WG consensus on direction X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi, At this point, Dan and I are working on the assumption that WG consensus is to get our documents into a stable state and published as an RFC before transitioning responsibility for further updates to the IEEE. This topic was identified as an open issue as part of the WG last call. This chartered work started before 1D-2004 was approved. I believe we are not trying to update to the latest state of IEEE documents, but to finalize work that was started three years ago - updates to include support for 1t, 1u, 1v, etc., not for 1D-2004. If WG consensus is that we should try to synchronize to the current IEEE documents, then I believe we will need to re-charter. Given the lack of participatioin in this WG, I have strong doubts a re-charter would be approved. If WG consensus is that we should not publish something known to be out of date, we can ask the IEEE 802.1 WG to take our documents "as is", do the synchronization, and let them finalize and publish what we have been unable to finalize and publish. Everybody speak up as to what direction you want to take - finalize the current, out-of-sync documents, re-charter to synchronize, or turn them over to the IEEE for completion? David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Dec 9 17:34:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23011; Thu, 9 Dec 2004 17:34:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcWyQ-0004U8-Os; Thu, 09 Dec 2004 17:41:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcWlq-0005SF-MY; Thu, 09 Dec 2004 17:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcWNC-00018d-JH for bridge-mib@megatron.ietf.org; Thu, 09 Dec 2004 17:02:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16754 for ; Thu, 9 Dec 2004 17:02:52 -0500 (EST) Message-Id: <200412092202.RAA16754@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcWUG-0002XI-2Q for bridge-mib@ietf.org; Thu, 09 Dec 2004 17:10:12 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2004120922022101500e5ss8e>; Thu, 9 Dec 2004 22:02:22 +0000 From: "David B Harrington" To: "'John Flick'" , Subject: RE: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Date: Thu, 9 Dec 2004 17:02:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTOq8mWySJBD7ZWQCGjz6zbAdWdIQPcM9jw In-Reply-To: <419EAE82.8010707@hp.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T'" X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 Content-Transfer-Encoding: 7bit Hi, I have asked the editor to start addressing the easy-to-resolve comments. I have comments, inline. John, would you be willing to review the -smiv2- draft with the same attention to detail so we can get that one done? David Harrington dbharrington@comcast.net > -----Original Message----- > From: bridge-mib-bounces@ietf.org > [mailto:bridge-mib-bounces@ietf.org] On Behalf Of John Flick > Sent: Friday, November 19, 2004 9:40 PM > To: bridge-mib@ietf.org > Cc: Congdon, Paul T > Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt > > Hi, > > I have the following comments on this draft. I have divided > my comments into introductory text, P-BRIDGE-MIB, and Q-BRIDGE-MIB. > > Introductory text comments: > > 1. Throughout the document, references to 802.1D-1998 should be > updated to refer to 802.1D-2004. It seems some references need to refer to 1D-1998; some might be better referencing 1D-2004. Can you review each reference in the text and suggest replacement text? > > 2. References to RFC 1493 should refer to the updated version > in draft-ietf-bridge-bridgemib-smiv2-07.txt. I believe that is not true in all instances. Please review each and make specific recommendations. > > 3. Separate references to 802.1t are unnecessary, as .1t is now > included in D-2004. This work started before 1D-2004 was approved. We are not trying to update to the latest state of IEEE documents, but to finalize work that was started three years ago, so we can get it into a stable state before transitioning responsibility for updates to the IEEE. > > 4. Separate references to 802.1u and 802.1v are unnecessary, as > they are included in 802.1Q-2003. (Note, I realize we are > just trying to ship what we have and let IEEE deal with > maintaining this, but it does seem unwise to approve a document > for the IETF standards track that references obsolete versions > of an IEEE specification, or that references an RFC that we are > about to obsolete.) This work started before 1Q-2003 was approved. We are not trying to update to the latest state of IEEE documents, but to finalize work that was started three years ago, so we can get it into a stable state before transitioning responsibility for updates to the IEEE. > > 5. The RFC editor does not allow references in the Abstract. (Again, > I realize the goal is to just ship it, but the RFC Editor will not > publish this as is.) This should be corrected. I believe we can simply drop the reference text, e.g. [RFC2578], since the introductory sections will have the references. > > 6. In Section 2, the following sentence: > > "IEEE 802.1Q defined port-based Virtual LANs where membership > is determined by the bridge port on which data frames are > received" > > should be updated for protocol VLANs. The IEEE can update it. > > 7. Section 2.1 begins with "This MIB includes...". This should > be replaced with "This document includes" or "The MIB modules > defined in this document include" Agreed. > > 8. In the Historical note in 2.1, bullet 4 says "Limit the total > of objects.", which should probably be "Limit the total number > of objects." Agreed. > > 9. I'm not sure what we should do with section 3.1.1, since > 802.1D-2004 no longer defines the managed objects that we refer > to here. We should finish this document to refer to the 1D-1998 and let the IEEE obsolete the objects later if they choose. > > 10. Section 3.3, first paragraph seems like an archaic leftover from > SMIv1. Do we really need to define what a T-C is here? End of > second paragraph talks about PIB modules, which I > thought were dead. I agree the first paragraph seems archaic, and could be removed, even the part that lists the TCs used in the document. PIB has no reference, so either it should be removed or an informative reference added. > > 11. Section 3.4 and 3.4.1 refer to MIB-II and RFC 1213 for the system > group. Shouldn't we be referring to RFC 3418 for the > system group? RFC3418 appends new objects to the RFC1213 system group. This mib module has dependencies on the RFC1213 portion of the system group, but not to the RFC3418 additions, so I believe it is accurate to say that we "assume that a brdge implementing this MIB will also implement (at least) the system group defined in MIB-II. We can try to tighten up the language when we're in fixing "implementing this MIB" to being "implementing this MIB module". > > 12. In section 3.4.2.1, second paragraph, the recommendation > that VLANs > are not represented in the ifTable conflicts with SMON. Not sure > what to do about this one, and I'm not sure IEEE is the > right place > to deal with it. I agree this should be dealt with in the IETF. We need to come to a consistent recommendation for all virtual interfaces. It is rather important that RFC1493-compliant agents not be made non-compliant by any change we make. > > 13. Much of the text in section 3.4.3 is about to be rendered obsolete > by draft-ietf-bridge-bridgemib-smiv2-07.txt. I think we should consider writing a formal compliance statement for the original RFC1493 in its update or in a separate document. That would also solve open issue #1 in the update document. > > P-BRIDGE-MIB comments: > > 1. There are several problems with the MODULE-IDENTITY: > > - LAST-UPDATED and REVISION dates need updating > - Need to keep the original REVISION clause from 2674 and just add > another revision for this version > - DESCRIPTION needs the required copyright boilerplate > - REVISION DESCRIPTION needs to identify changes made to > this module > since 2674 (one of Bert's favorite IESG Discusses...) > - CONTACT-INFO normally has editor's contact info The unavailability of the editors of this draft has been a major reason for its delay. The rfc-editor has proposed that a "contact information" section be included in rfcs rather than "author's addresses" so the original authors and subsequent authors addresses can be listed to help readers contact somebody that knows why the document was written as it was. Since mib modules often are distributed without the surrounding text, maybe we need to make sure we have an editor's name in the module-identity, but putting the mailin glist there might be a better way to get them some help. Maybe we should put an alternate address - the "mibs" mailing list. > > 2. REFERENCE clauses should point to currently published IEEE > document, > not to an old IEEE draft. > Ideally, the mib module should be specified at the same time as the technolgy it is meant to manage. That is why we are transitioning the responsibility to the IEEE. I suggest that the document can be updated by the IEEE to bring it up-to-date with current IEEE documents. I think we will never be able to match the current IEEE documents at the glacial rate of this WG, so I would rather publish this and transition the responsibility so the IEEE can synchronize the mib and the technology specs. In the meantime, our job is to finalize the work started three years ago, not to try to synchronize to currrent IEEE documents. > 3. Several formatting oopses throughout See > dot1dPortPriorityT > able > for an example. There were more spurious line feeds like this > scattered throughout the document. I believe the internet-draft publication process introduced these spurious characters. They are aware of the problem and have fixed it. The next revision will resolve these, hopefully. > > 4. Description of dot1dPortOutboundAccessPriority seems wrong > - outbound > definition talks about received frame instead of > transmitted frame. Do you have access to ISO.IEC 15802-3 Table 7-3? What language do they use? > > 5. pBridgePortGmrpGroup adds a new object to an existing group from > 2674, which is forbidden by the SMI. We will need to deprecate > the existing group and define a new group that includes the new > object. Note that this will also mean defining a new > MODULE-COMPLIANCE that includes the new group. I believe the way we should proceed to be compatible with RFC2580 is this (please correct me if I'm wrong): We need to copy the old group definition and old module compliance into this document. We should define a new group with the new object Then we should define a new MODULE-compliance that includes the old group and the new group. We do not need to deprecate the old group and old module-compliance (although we may want to). > > Q-BRIDGE-MIB comments: > > 1. MODULE-IDENTITY has the same problems listed above. > > 2. VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone: The statement in > section 3.3 that says: "Notre that a MIB object that is defined > using one of these textual conventions should clarify the meaning > of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause." should > be included in the DESCRIPTION clauses of these T-Cs. I agree, with the wording modified to VlanIdOrAny: "a MIB object that is defined using this textual convention should clarify the meaning of 'any VLAN' in its DESCRIPTION clause." VlanIdOrNone: "a MIB object that is defined using this textual convention should clarify the meaning of 'no VLAN' in its DESCRIPTION clause." VlanIdOrAnyOrNone: "a MIB object that is defined using this textual convention should clarify the meaning of 'any VLAN' and 'no VLAN' in its DESCRIPTION clause." > > 3. dot1qForwardAllStaticPorts description talks about non-EFS > behaviour, > but the acronym EFS has not been defined, and does not appear > anywhere else in this document. Can you provide suggested text? > > 4. The description of dot1qPortAcceptableFrameTypes is no longer > accurate with protocol VLANs. Was this in scope three years ago? > > 5. There are several formatting glitches in this module, like in > P-BRIDGE-MIB. Note that these make the module uncompilable. To be corrected during publication. > > 6. Again, qBridgePortGroup was modified from RFC 2674, which the > SMI does not allow. To be corrected. > > 7. qBridgeCompliance was also modified to add the two new > OBJECT-GROUPs > which is also not allowed by the SMI. To be corrected. > > 8. 802.1Q says that support for management configuration of the > protocol group database is optional. An implementation that > implements a fixed set of database entries is fully compliant. > Therefore, the new MODULE-COMPLIANCE must allow > dot1vProtocolGroupId and dot1vProtocolGroupRowStatus to be > implemented read-only, otherwise we are taking something that is > optional in 802.1Q and making it mandatory to comply with the > MIB defintion. To be checked and corrected I fnecessary. > > Thanks, > John Thanks for the thorugh review of the document, John. > > David B Harrington wrote: > > Hi, > > > > This starts the WG last call for the update to RFC2674. > > We missed the IETF61 publication deadline, so the document can be > > found at: > > > > > http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-bridge-ext-v2-03.t > > xt > > > > The WG last call will end November 23. > > This date has been chosen to ensure that > > 1) IETF61 attendees have two weeks to perform reviews, > > 2) attendees of the IEEE meeting the following week > have two weeks to > > perform reviews, > > 3) the ID publication lockout is lifted and the > document becomes > > available in the normal repository If anybody has objection to this > > date, please post your concerns to bridge-mib@ietf.org. > > If anybody has comments on the draft, please post them to > > bridge-mib@ietf.org > > > > Thanks, > > David Harrington > > dbharrington@comcast.net > > Bridge-mib co-chair > > > > > > > > > > > > _______________________________________________ > > Bridge-mib mailing list > > Bridge-mib@ietf.org > > https://www1.ietf.org/mailman/listinfo/bridge-mib > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Dec 9 19:51:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04328; Thu, 9 Dec 2004 19:51:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcZ7O-0007Hw-Kg; Thu, 09 Dec 2004 19:58:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcYvt-0000fR-L5; Thu, 09 Dec 2004 19:46:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcYqp-0007G6-FA for bridge-mib@megatron.ietf.org; Thu, 09 Dec 2004 19:41:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03558 for ; Thu, 9 Dec 2004 19:41:36 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcYxu-00075f-9W for bridge-mib@ietf.org; Thu, 09 Dec 2004 19:48:59 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1F2493785; Fri, 10 Dec 2004 01:41:00 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28147-08; Fri, 10 Dec 2004 01:40:59 +0100 (CET) Received: from james (Iabf4.i.pppool.de [85.73.171.244]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id ED5983784; Fri, 10 Dec 2004 01:40:58 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CcYq9-00015c-GQ; Fri, 10 Dec 2004 01:40:57 +0100 Date: Fri, 10 Dec 2004 01:40:57 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] WG consensus on direction Message-ID: <20041210004057.GB4075@james> Mail-Followup-To: David B Harrington , bridge-mib@ietf.org, "'Romascanu, Dan (Dan)'" , "'Congdon, Paul T (ProCurve)'" References: <200412092119.QAA05618@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200412092119.QAA05618@ietf.org> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "'Congdon, Paul T \(ProCurve\)'" , "'Romascanu, Dan \(Dan\)'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b On Thu, Dec 09, 2004 at 04:18:39PM -0500, David B Harrington wrote: > At this point, Dan and I are working on the assumption that WG > consensus is to get our documents into a stable state and published as > an RFC before transitioning responsibility for further updates to the > IEEE. This topic was identified as an open issue as part of the WG > last call. > > This chartered work started before 1D-2004 was approved. I believe we > are not trying to update to the latest state of IEEE documents, but to > finalize work that was started three years ago - updates to include > support for 1t, 1u, 1v, etc., not for 1D-2004. > > If WG consensus is that we should try to synchronize to the current > IEEE documents, then I believe we will need to re-charter. Given the > lack of participatioin in this WG, I have strong doubts a re-charter > would be approved. > > If WG consensus is that we should not publish something known to be > out of date, we can ask the IEEE 802.1 WG to take our documents "as > is", do the synchronization, and let them finalize and publish what we > have been unable to finalize and publish. > > Everybody speak up as to what direction you want to take - finalize > the current, out-of-sync documents, re-charter to synchronize, or turn > them over to the IEEE for completion? Does this synchronization issue affect both documents in the same way? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Dec 10 08:37:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13875; Fri, 10 Dec 2004 08:37:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccl4y-0004z3-FJ; Fri, 10 Dec 2004 08:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cckt5-0007kQ-LI; Fri, 10 Dec 2004 08:32:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccklu-0005QV-2a for bridge-mib@megatron.ietf.org; Fri, 10 Dec 2004 08:25:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13198 for ; Fri, 10 Dec 2004 08:25:20 -0500 (EST) Message-Id: <200412101325.IAA13198@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cckt5-0004kh-92 for bridge-mib@ietf.org; Fri, 10 Dec 2004 08:32:48 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004121013244601300lja2be>; Fri, 10 Dec 2004 13:24:47 +0000 From: "David B Harrington" To: Subject: RE: [Bridge-mib] WG consensus on direction Date: Fri, 10 Dec 2004 08:24:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTeUOvqyRGIDMYlTJmmJbDbK7Z5/AAaJ/NA In-Reply-To: <20041210004057.GB4075@james> X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T \(ProCurve\)'" , "'Romascanu, Dan \(Dan\)'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hi, Since the synchronization issue was explicitly included as part of the WG last call for each of the documents, I believe all the documents could be impacted. Dan and I opened this topic for discussion previously, and few people responded. The majority of those who responded did not appear to want to synchronize because it will be a long drawn-out effort to hit a moving target. My message was motivated by John Flick's review, which requests synchronization to current IEEE documents in a number of places. Before deciding that those requests are out of scope because we are not doing synchronization to current documents, I wanted to encourage people to speak up on the topic so we could gauge the consensus better on this topic. David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Thursday, December 09, 2004 7:41 PM > To: David B Harrington > Cc: bridge-mib@ietf.org; 'Romascanu, Dan (Dan)'; 'Congdon, > Paul T (ProCurve)' > Subject: Re: [Bridge-mib] WG consensus on direction > > On Thu, Dec 09, 2004 at 04:18:39PM -0500, David B Harrington wrote: > > > At this point, Dan and I are working on the assumption that WG > > consensus is to get our documents into a stable state and > published as > > an RFC before transitioning responsibility for further > updates to the > > IEEE. This topic was identified as an open issue as part of the WG > > last call. > > > > This chartered work started before 1D-2004 was approved. I > believe we > > are not trying to update to the latest state of IEEE > documents, but to > > finalize work that was started three years ago - updates to include > > support for 1t, 1u, 1v, etc., not for 1D-2004. > > > > If WG consensus is that we should try to synchronize to the current > > IEEE documents, then I believe we will need to re-charter. > Given the > > lack of participatioin in this WG, I have strong doubts a > re-charter > > would be approved. > > > > If WG consensus is that we should not publish something known to be > > out of date, we can ask the IEEE 802.1 WG to take our documents "as > > is", do the synchronization, and let them finalize and > publish what we > > have been unable to finalize and publish. > > > > Everybody speak up as to what direction you want to take - finalize > > the current, out-of-sync documents, re-charter to > synchronize, or turn > > them over to the IEEE for completion? > > Does this synchronization issue affect both documents in the same way? > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Dec 10 19:05:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12753; Fri, 10 Dec 2004 19:05:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccusr-00043U-4t; Fri, 10 Dec 2004 19:13:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccuks-0002Qg-Gn; Fri, 10 Dec 2004 19:04:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcugX-0001M7-Q8 for bridge-mib@megatron.ietf.org; Fri, 10 Dec 2004 19:00:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12278 for ; Fri, 10 Dec 2004 19:00:26 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccuno-0003wi-9N for bridge-mib@ietf.org; Fri, 10 Dec 2004 19:08:01 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel11.hp.com (Postfix) with ESMTP id D378B17E6; Fri, 10 Dec 2004 16:00:26 -0800 (PST) Received: from [127.0.0.1] (ros54018lap.americas.hpqcorp.net [15.255.5.65]) by rosemail.rose.hp.com (Postfix) with ESMTP id 871C2827D; Fri, 10 Dec 2004 16:00:26 -0800 (PST) Message-ID: <41BA375C.2060906@hp.com> Date: Fri, 10 Dec 2004 15:55:08 -0800 From: John Flick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dbharrington@comcast.net Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt References: <200412092202.RAA16754@ietf.org> In-Reply-To: <200412092202.RAA16754@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Dave, I will review the -smiv2- draft and post detailed comments the first half of next week. I'll post a response to some of your detailed comments ASAP. Thanks, John David B Harrington wrote: > Hi, > > I have asked the editor to start addressing the easy-to-resolve > comments. > I have comments, inline. > > John, would you be willing to review the -smiv2- draft with the same > attention to detail so we can get that one done? > > David Harrington > dbharrington@comcast.net > > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Dec 10 19:20:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13489; Fri, 10 Dec 2004 19:20:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccv7Y-0004IL-R1; Fri, 10 Dec 2004 19:28:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuzX-00051D-Qx; Fri, 10 Dec 2004 19:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccuv3-0003wo-0H for bridge-mib@megatron.ietf.org; Fri, 10 Dec 2004 19:15:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13081 for ; Fri, 10 Dec 2004 19:15:25 -0500 (EST) Received: from palrel10.hp.com ([156.153.255.245]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccv2J-0004Au-Ox for bridge-mib@ietf.org; Fri, 10 Dec 2004 19:23:01 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by palrel10.hp.com (Postfix) with ESMTP id 9AB8F46996; Fri, 10 Dec 2004 16:15:26 -0800 (PST) Received: from [127.0.0.1] (ros54018lap.americas.hpqcorp.net [15.255.5.65]) by rosemail.rose.hp.com (Postfix) with ESMTP id 5498C82A0; Fri, 10 Dec 2004 16:15:26 -0800 (PST) Message-ID: <41BA3AE0.2040806@hp.com> Date: Fri, 10 Dec 2004 16:10:08 -0800 From: John Flick User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dbharrington@comcast.net Subject: Re: [Bridge-mib] WG consensus on direction References: <200412101325.IAA13198@ietf.org> In-Reply-To: <200412101325.IAA13198@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T \(ProCurve\)'" , "'Romascanu, Dan \(Dan\)'" , j.schoenwaelder@iu-bremen.de, bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Dave, I guess the issue here is since we are intending to publish the -ext-v2 draft as a standards-track document, can we get away with normative references an RFC that we are about to move to Historic (RFC 1493), or a superseded version of an IEEE standard. If the answer is yes, we can get away with it, let's just do it. If not, we need to decide whether we would rather update the references, or perhaps just publish what we have as Informational. Cheers, John David B Harrington wrote: > Hi, > > Since the synchronization issue was explicitly included as part of the > WG last call for each of the documents, I believe all the documents > could be impacted. Dan and I opened this topic for discussion > previously, and few people responded. The majority of those who > responded did not appear to want to synchronize because it will be a > long drawn-out effort to hit a moving target. > > My message was motivated by John Flick's review, which requests > synchronization to current IEEE documents in a number of places. > Before deciding that those requests are out of scope because we are > not doing synchronization to current documents, I wanted to encourage > people to speak up on the topic so we could gauge the consensus better > on this topic. > > David Harrington > dbharrington@comcast.net > co-chair, IETF Bridge WG > > > >>-----Original Message----- >>From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On >>Behalf Of Juergen Schoenwaelder >>Sent: Thursday, December 09, 2004 7:41 PM >>To: David B Harrington >>Cc: bridge-mib@ietf.org; 'Romascanu, Dan (Dan)'; 'Congdon, >>Paul T (ProCurve)' >>Subject: Re: [Bridge-mib] WG consensus on direction >> >>On Thu, Dec 09, 2004 at 04:18:39PM -0500, David B Harrington wrote: >> >> >>>At this point, Dan and I are working on the assumption that WG >>>consensus is to get our documents into a stable state and >> >>published as >> >>>an RFC before transitioning responsibility for further >> >>updates to the >> >>>IEEE. This topic was identified as an open issue as part of the WG > > >>>last call. >>> >>>This chartered work started before 1D-2004 was approved. I >> >>believe we >> >>>are not trying to update to the latest state of IEEE >> >>documents, but to >> >>>finalize work that was started three years ago - updates to > > include > >>>support for 1t, 1u, 1v, etc., not for 1D-2004. >>> >>>If WG consensus is that we should try to synchronize to the > > current > >>>IEEE documents, then I believe we will need to re-charter. >> >>Given the >> >>>lack of participatioin in this WG, I have strong doubts a >> >>re-charter >> >>>would be approved. >>> >>>If WG consensus is that we should not publish something known to > > be > >>>out of date, we can ask the IEEE 802.1 WG to take our documents > > "as > >>>is", do the synchronization, and let them finalize and >> >>publish what we >> >>>have been unable to finalize and publish. >>> >>>Everybody speak up as to what direction you want to take - > > finalize > >>>the current, out-of-sync documents, re-charter to >> >>synchronize, or turn >> >>>them over to the IEEE for completion? >> >>Does this synchronization issue affect both documents in the same > > way? > >>/js >> >>-- >>Juergen Schoenwaelder International University Bremen >> P.O. Box 750 561, >>28725 Bremen, Germany >> > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Mon Dec 13 15:01:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12437; Mon, 13 Dec 2004 15:01:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdwVV-0007ZR-TY; Mon, 13 Dec 2004 15:09:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdwKO-00022e-U7; Mon, 13 Dec 2004 14:57:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdw9z-0007vx-2D for bridge-mib@megatron.ietf.org; Mon, 13 Dec 2004 14:47:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11559 for ; Mon, 13 Dec 2004 14:47:05 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdwHq-0007FA-3K for bridge-mib@ietf.org; Mon, 13 Dec 2004 14:55:15 -0500 Received: from zsc3c026.us.nortel.com (zsc3c026.us.nortel.com [47.81.138.26]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iBDJkMr21212; Mon, 13 Dec 2004 14:46:22 -0500 (EST) Received: by zsc3c026.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Dec 2004 11:46:22 -0800 Message-ID: <0A11633F61BD9F40B43ABCC694004F93043BD05E@zsc3c026.us.nortel.com> From: "David Levi" To: "'John Flick'" , bridge-mib@ietf.org Subject: RE: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Date: Mon, 13 Dec 2004 11:46:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: f1dd3a65e68371b02f99ed5567ad74d9 Cc: "Congdon, Paul T" X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1247185427==" Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: f31e050dc7ce62aeed70903f7da21012 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. --===============1247185427== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E14C.6B6F716A" 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_01C4E14C.6B6F716A Content-Type: text/plain Hi All, I've fixed some of these items, as described below, in the nroff sources, so we'll have the changes in the next draft when/if it is submitted. -Dave -----Original Message----- From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] Sent: Friday, November 19, 2004 9:40 PM To: bridge-mib@ietf.org Cc: Congdon, Paul T Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt Hi, I have the following comments on this draft. I have divided my comments into introductory text, P-BRIDGE-MIB, and Q-BRIDGE-MIB. Introductory text comments: 1. Throughout the document, references to 802.1D-1998 should be updated to refer to 802.1D-2004. DBL> Waiting for results of discussion on the mailing list before DBL> changing this. 2. References to RFC 1493 should refer to the updated version in draft-ietf-bridge-bridgemib-smiv2-07.txt. DBL> I don't think it makes sense to change this, since these references DBL> will just need to be updated to the new RFC number for DBL> draft-ietf-bridge-bridgemib-smiv2-07.txt when it is published as an DBL> RFC. 3. Separate references to 802.1t are unnecessary, as .1t is now included in D-2004. DBL> Waiting for results of discussion on the mailing list before DBL> changing this. 4. Separate references to 802.1u and 802.1v are unnecessary, as they are included in 802.1Q-2003. (Note, I realize we are just trying to ship what we have and let IEEE deal with maintaining this, but it does seem unwise to approve a document for the IETF standards track that references obsolete versions of an IEEE specification, or that references an RFC that we are about to obsolete.) DBL> Waiting for results of discussion on the mailing list before DBL> changing this. 5. The RFC editor does not allow references in the Abstract. (Again, I realize the goal is to just ship it, but the RFC Editor will not publish this as is.) DBL> I took out the references from the abstract. 6. In Section 2, the following sentence: "IEEE 802.1Q defined port-based Virtual LANs where membership is determined by the bridge port on which data frames are received" should be updated for protocol VLANs. DBL> Can you suggest some text? 7. Section 2.1 begins with "This MIB includes...". This should be replaced with "This document includes" or "The MIB modules defined in this document include" DBL> Fixed. 8. In the Historical note in 2.1, bullet 4 says "Limit the total of objects.", which should probably be "Limit the total number of objects." DBL> Fixed. 9. I'm not sure what we should do with section 3.1.1, since 802.1D-2004 no longer defines the managed objects that we refer to here. DBL> Waiting for results of discussion on the mailing list before DBL> changing this. 10. Section 3.3, first paragraph seems like an archaic leftover from SMIv1. Do we really need to define what a T-C is here? End of second paragraph talks about PIB modules, which I thought were dead. DBL> Removed the first paragraph, and the statement about PIB modules. 11. Section 3.4 and 3.4.1 refer to MIB-II and RFC 1213 for the system group. Shouldn't we be referring to RFC 3418 for the system group? DBL> Fixed. 12. In section 3.4.2.1, second paragraph, the recommendation that VLANs are not represented in the ifTable conflicts with SMON. Not sure what to do about this one, and I'm not sure IEEE is the right place to deal with it. DBL> I changed this to Dan's suggested text. 13. Much of the text in section 3.4.3 is about to be rendered obsolete by draft-ietf-bridge-bridgemib-smiv2-07.txt. DBL> Is there anything in this section that will *not* be rendered DBL> obsolete, and so should not be removed? P-BRIDGE-MIB comments: 1. There are several problems with the MODULE-IDENTITY: - LAST-UPDATED and REVISION dates need updating - Need to keep the original REVISION clause from 2674 and just add another revision for this version - DESCRIPTION needs the required copyright boilerplate - REVISION DESCRIPTION needs to identify changes made to this module since 2674 (one of Bert's favorite IESG Discusses...) - CONTACT-INFO normally has editor's contact info DBL> Fixed LAST-UPDATED field, restored original REVISION, and added new DBL> REVISION. Restored the CONTACT-INFO from RFC 2674. 2. REFERENCE clauses should point to currently published IEEE document, not to an old IEEE draft. DBL> Waiting for results of discussion on the mailing list before DBL> changing this. 3. Several formatting oopses throughout See dot1dPortPriorityT able for an example. There were more spurious line feeds like this scattered throughout the document. DBL> These problems seem to have occurred after I submitted the last draft. DBL> The originals I have here don't have these formatting problems. I'm DBL> not sure how to address this. 4. Description of dot1dPortOutboundAccessPriority seems wrong - outbound definition talks about received frame instead of transmitted frame. DBL> Can others on the mailing-list verify this? The current wording is DBL> the same as was in RFC 2674. 5. pBridgePortGmrpGroup adds a new object to an existing group from 2674, which is forbidden by the SMI. We will need to deprecate the existing group and define a new group that includes the new object. Note that this will also mean defining a new MODULE-COMPLIANCE that includes the new group. DBL> Fixed. Q-BRIDGE-MIB comments: 1. MODULE-IDENTITY has the same problems listed above. DBL> Fixed as described above. 2. VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone: The statement in section 3.3 that says: "Notre that a MIB object that is defined using one of these textual conventions should clarify the meaning of 'any VLAN' and/or 'no VLAN' in its DESCRIPTION clause." should be included in the DESCRIPTION clauses of these T-Cs. DBL> Added text to the DESCRIPTIONs. 3. dot1qForwardAllStaticPorts description talks about non-EFS behaviour, but the acronym EFS has not been defined, and does not appear anywhere else in this document. DBL> What would you suggest we change? Perhaps adding a REFERENCE to DBL> this object? 4. The description of dot1qPortAcceptableFrameTypes is no longer accurate with protocol VLANs. DBL> Can you suggest how to change the text? 5. There are several formatting glitches in this module, like in P-BRIDGE-MIB. Note that these make the module uncompilable. DBL> Same comment as above. 6. Again, qBridgePortGroup was modified from RFC 2674, which the SMI does not allow. DBL> Fixed. 7. qBridgeCompliance was also modified to add the two new OBJECT-GROUPs which is also not allowed by the SMI. DBL> Fixed. 8. 802.1Q says that support for management configuration of the protocol group database is optional. An implementation that implements a fixed set of database entries is fully compliant. Therefore, the new MODULE-COMPLIANCE must allow dot1vProtocolGroupId and dot1vProtocolGroupRowStatus to be implemented read-only, otherwise we are taking something that is optional in 802.1Q and making it mandatory to comply with the MIB defintion. DBL> Fixed. Thanks, John David B Harrington wrote: > Hi, > > This starts the WG last call for the update to RFC2674. > We missed the IETF61 publication deadline, so the document can be > found at: > > http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-bridge-ext-v2-03.t > xt > > The WG last call will end November 23. > This date has been chosen to ensure that > 1) IETF61 attendees have two weeks to perform reviews, > 2) attendees of the IEEE meeting the following week have two weeks to > perform reviews, > 3) the ID publication lockout is lifted and the document becomes > available in the normal repository If anybody has objection to this > date, please post your concerns to bridge-mib@ietf.org. > If anybody has comments on the draft, please post them to > bridge-mib@ietf.org > > Thanks, > David Harrington > dbharrington@comcast.net > Bridge-mib co-chair > > > > > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib ------_=_NextPart_001_01C4E14C.6B6F716A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Bridge-mib] WG Last = Call:dratf-ietf-bridge-ext-v2-03.txt

Hi All,

I've fixed some of these items, as described below, = in the nroff sources, so we'll have the changes in the next draft = when/if it is submitted.

-Dave

-----Original Message-----
From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ie= tf.org]
Sent: Friday, November 19, 2004 9:40 PM
To: bridge-mib@ietf.org
Cc: Congdon, Paul T
Subject: Re: [Bridge-mib] WG Last = Call:dratf-ietf-bridge-ext-v2-03.txt


Hi,

I have the following comments on this draft.  I = have divided my comments into introductory text, P-BRIDGE-MIB, and = Q-BRIDGE-MIB.

Introductory text comments:

1. Throughout the document, references to 802.1D-1998 = should be
    updated to refer to = 802.1D-2004.
DBL> Waiting for results of discussion on the = mailing list before
DBL> changing this.

2. References to RFC 1493 should refer to the updated = version
    in = draft-ietf-bridge-bridgemib-smiv2-07.txt.
DBL> I don't think it makes sense to change this, = since these references
DBL> will just need to be updated to the new RFC = number for
DBL> draft-ietf-bridge-bridgemib-smiv2-07.txt = when it is published as an
DBL> RFC.

3. Separate references to 802.1t are unnecessary, as = .1t is now
    included in D-2004.
DBL> Waiting for results of discussion on the = mailing list before
DBL> changing this.

4. Separate references to 802.1u and 802.1v are = unnecessary, as
    they are included in = 802.1Q-2003.  (Note, I realize we are
    just trying to ship what we have = and let IEEE deal with
    maintaining this, but it does = seem unwise to approve a document
    for the IETF standards track that = references obsolete versions
    of an IEEE specification, or that = references an RFC that we are
    about to obsolete.)
DBL> Waiting for results of discussion on the = mailing list before
DBL> changing this.

5. The RFC editor does not allow references in the = Abstract.  (Again,
    I realize the goal is to just = ship it, but the RFC Editor will not
    publish this as is.)
DBL> I took out the references from the = abstract.

6. In Section 2, the following sentence:

    "IEEE 802.1Q defined = port-based Virtual LANs where membership
    is determined by the bridge port = on which data frames are
    received"

    should be updated for protocol = VLANs.
DBL> Can you suggest some text?

7. Section 2.1 begins with "This MIB = includes...".  This should
    be replaced with "This = document includes" or "The MIB modules
    defined in this document = include"
DBL> Fixed.

8. In the Historical note in 2.1, bullet 4 says = "Limit the total
    of objects.", which should = probably be "Limit the total number
    of objects."
DBL> Fixed.

9. I'm not sure what we should do with section 3.1.1, = since
    802.1D-2004 no longer defines the = managed objects that we refer
    to here.
DBL> Waiting for results of discussion on the = mailing list before
DBL> changing this.

10. Section 3.3, first paragraph seems like an = archaic leftover from
     SMIv1.  Do we really = need to define what a T-C is here?  End of
     second paragraph talks = about PIB modules, which I thought were dead.
DBL> Removed the first paragraph, and the = statement about PIB modules.

11. Section 3.4 and 3.4.1 refer to MIB-II and RFC = 1213 for the system
     group.  Shouldn't we = be referring to RFC 3418 for the system group?
DBL> Fixed.

12. In section 3.4.2.1, second paragraph, the = recommendation that VLANs
     are not represented in the = ifTable conflicts with SMON.  Not sure
     what to do about this one, = and I'm not sure IEEE is the right place
     to deal with it.
DBL> I changed this to Dan's suggested = text.

13. Much of the text in section 3.4.3 is about to be = rendered obsolete
     by = draft-ietf-bridge-bridgemib-smiv2-07.txt.
DBL> Is there anything in this section that will = *not* be rendered
DBL> obsolete, and so should not be = removed?

P-BRIDGE-MIB comments:

1. There are several problems with the = MODULE-IDENTITY:

    - LAST-UPDATED and REVISION dates = need updating
    - Need to keep the original = REVISION clause from 2674 and just add
      another revision for = this version
    - DESCRIPTION needs the required = copyright boilerplate
    - REVISION DESCRIPTION needs to = identify changes made to this module
      since 2674 (one of = Bert's favorite IESG Discusses...)
    - CONTACT-INFO normally has = editor's contact info
DBL> Fixed LAST-UPDATED field, restored original = REVISION, and added new
DBL> REVISION.  Restored the CONTACT-INFO = from RFC 2674.

2. REFERENCE clauses should point to currently = published IEEE document,
    not to an old IEEE draft.
DBL> Waiting for results of discussion on the = mailing list before
DBL> changing this.

3. Several formatting oopses throughout See
    dot1dPortPriorityT
able
    for an example.  There were = more spurious line feeds like this
    scattered throughout the = document.
DBL> These problems seem to have occurred after I = submitted the last draft.
DBL> The originals I have here don't have these = formatting problems.  I'm
DBL> not sure how to address this.

4. Description of dot1dPortOutboundAccessPriority = seems wrong - outbound
    definition talks about received = frame instead of transmitted frame.
DBL> Can others on the mailing-list verify = this?  The current wording is
DBL> the same as was in RFC 2674.

5. pBridgePortGmrpGroup adds a new object to an = existing group from
    2674, which is forbidden by the = SMI.  We will need to deprecate
    the existing group and define a = new group that includes the new
    object.  Note that this will = also mean defining a new
    MODULE-COMPLIANCE that includes = the new group.
DBL> Fixed.

Q-BRIDGE-MIB comments:

1. MODULE-IDENTITY has the same problems listed = above.
DBL> Fixed as described above.

2. VlanIdOrAny, VlanIdOrNone, VlanIdOrAnyOrNone: The = statement in
    section 3.3 that says: = "Notre that a MIB object that is defined
    using one of these textual = conventions should clarify the meaning
    of 'any VLAN' and/or 'no VLAN' in = its DESCRIPTION clause." should
    be included in the DESCRIPTION = clauses of these T-Cs.
DBL> Added text to the DESCRIPTIONs.

3. dot1qForwardAllStaticPorts description talks about = non-EFS behaviour,
    but the acronym EFS has not been = defined, and does not appear
    anywhere else in this = document.
DBL> What would you suggest we change?  = Perhaps adding a REFERENCE to
DBL> this object?

4. The description of dot1qPortAcceptableFrameTypes = is no longer
    accurate with protocol = VLANs.
DBL> Can you suggest how to change the = text?

5. There are several formatting glitches in this = module, like in
    P-BRIDGE-MIB.  Note that = these make the module uncompilable.
DBL> Same comment as above.

6. Again, qBridgePortGroup was modified from RFC = 2674, which the
    SMI does not allow.
DBL> Fixed.

7. qBridgeCompliance was also modified to add the two = new OBJECT-GROUPs
    which is also not allowed by the = SMI.
DBL> Fixed.

8. 802.1Q says that support for management = configuration of the
    protocol group database is = optional.  An implementation that
    implements a fixed set of = database entries is fully compliant.
    Therefore, the new = MODULE-COMPLIANCE must allow
    dot1vProtocolGroupId and = dot1vProtocolGroupRowStatus to be
    implemented read-only, otherwise = we are taking something that is
    optional in 802.1Q and making it = mandatory to comply with the
    MIB defintion.
DBL> Fixed.



Thanks,
John

David B Harrington wrote:
> Hi,
>
> This starts the WG last call for the update to = RFC2674.
> We missed the IETF61 publication deadline, so = the document can be
> found at:
> 
> http://www.ibr.cs.tu-bs.de/users/schoenw/draft-ietf-br= idge-ext-v2-03.t
> xt
>
> The WG last call will end November 23.
> This date has been chosen to ensure that =
>       1) IETF61 = attendees have two weeks to perform reviews,
>       2) attendees of = the IEEE meeting the following week have two weeks to
> perform reviews,
>       3) the ID = publication lockout is lifted and the document becomes
> available in the normal repository If anybody = has objection to this
> date, please post your concerns to = bridge-mib@ietf.org.
> If anybody has comments on the draft, please = post them to
> bridge-mib@ietf.org
>
> Thanks,
> David Harrington
> dbharrington@comcast.net
> Bridge-mib co-chair
> 
>
>
>
>
> = _______________________________________________
> Bridge-mib mailing list
> Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib<= /FONT>
>


_______________________________________________
Bridge-mib mailing list
Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib<= /FONT>

------_=_NextPart_001_01C4E14C.6B6F716A-- --===============1247185427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib --===============1247185427==-- From bridge-mib-bounces@ietf.org Tue Dec 14 03:32:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01135; Tue, 14 Dec 2004 03:32:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ce8F1-00014c-WB; Tue, 14 Dec 2004 03:41:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ce86B-0001aP-Mi; Tue, 14 Dec 2004 03:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cco3F-0003eN-Ev for bridge-mib@megatron.ietf.org; Fri, 10 Dec 2004 11:55:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29091 for ; Fri, 10 Dec 2004 11:55:26 -0500 (EST) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcoAQ-0000RA-LA for bridge-mib@ietf.org; Fri, 10 Dec 2004 12:02:57 -0500 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel13.hp.com (Postfix) with ESMTP id 5404B1C0DF66; Fri, 10 Dec 2004 08:55:20 -0800 (PST) Received: from cacexc07.americas.cpqcorp.net ([16.92.1.32]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 08:55:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Dec 2004 08:55:18 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A7F1@cacexc07.americas.cpqcorp.net> Thread-Topic: WG consensus on direction Thread-Index: AcTeNKceNGFKsT6LTLKGI4O/S2bqygAouWUw From: "Congdon, Paul T (ProCurve)" To: , , "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 10 Dec 2004 16:55:19.0670 (UTC) FILETIME=[07FFF160:01C4DED9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 14 Dec 2004 03:31:47 -0500 Subject: [Bridge-mib] RE: WG consensus on direction X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable At the last 802.1 meeting we discussed the fact that all NEW 802.1 projects will have MIBs associated with them. The IETF was finishing support for .1t, .1u, .1v. We needed to start a specific project in 802.1 for 802.1s MIB support. Now it appears we may also need to consider a project to update the what the IETF is about to produce. I would prefer to see the RFCs published 'as is' and any updates handled as part of 802.1 later - it may even be in the scope of 802.1D-2004 to make small MIB changes?. All this said, we still don't have a real strong commitment to start the projects within 802.1, primarily because of the lack of an assigned/volunteered and committed editor. This editor must run the project through the 802 standards process (balloting, submission, etc). This should NOT stop work in the current MSTP MIB that is going on over the email reflector. We can still develop the MIB module in this fashion. Discussion of the MIB should take place at the meetings as well. Paulo=20 > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net]=20 > Sent: Thursday, December 09, 2004 1:19 PM > To: bridge-mib@ietf.org; 'Romascanu, Dan (Dan)' > Cc: Congdon, Paul T (ProCurve) > Subject: WG consensus on direction >=20 > Hi, >=20 > At this point, Dan and I are working on the assumption that=20 > WG consensus is to get our documents into a stable state and=20 > published as an RFC before transitioning responsibility for=20 > further updates to the IEEE. This topic was identified as an=20 > open issue as part of the WG last call.=20 >=20 > This chartered work started before 1D-2004 was approved. I=20 > believe we are not trying to update to the latest state of=20 > IEEE documents, but to finalize work that was started three=20 > years ago - updates to include support for 1t, 1u, 1v, etc.,=20 > not for 1D-2004.=20 >=20 > If WG consensus is that we should try to synchronize to the=20 > current IEEE documents, then I believe we will need to=20 > re-charter. Given the lack of participatioin in this WG, I=20 > have strong doubts a re-charter would be approved. >=20 > If WG consensus is that we should not publish something known=20 > to be out of date, we can ask the IEEE 802.1 WG to take our=20 > documents "as is", do the synchronization, and let them=20 > finalize and publish what we have been unable to finalize and publish. >=20 > Everybody speak up as to what direction you want to take -=20 > finalize the current, out-of-sync documents, re-charter to=20 > synchronize, or turn them over to the IEEE for completion? >=20 >=20 > David Harrington > dbharrington@comcast.net > co-chair, IETF Bridge WG > =20 >=20 >=20 >=20 _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Dec 15 16:44:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19518; Wed, 15 Dec 2004 16:44:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ceh5D-0004K7-U8; Wed, 15 Dec 2004 16:53:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CegpH-0006Ne-E1; Wed, 15 Dec 2004 16:36:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CegD9-0008On-TG for bridge-mib@megatron.ietf.org; Wed, 15 Dec 2004 15:57:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10024 for ; Wed, 15 Dec 2004 15:57:24 -0500 (EST) Message-Id: <200412152057.PAA10024@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CegLR-0001QD-Ej for bridge-mib@ietf.org; Wed, 15 Dec 2004 16:06:01 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004121520565401300g1lm7e>; Wed, 15 Dec 2004 20:56:54 +0000 From: "David B Harrington" To: Date: Wed, 15 Dec 2004 15:56:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTi6Jh+ZBlsLlq0QqeRBGstgDVb4g== X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: "'Romascanu, Dan \(Dan\)'" , "'Wijnen, Bert \(Bert\)'" Subject: [Bridge-mib] Consensus determination X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Hi, Just to make things official: Over the past six weeks or so, we have had a discussion to determine consensus about the status sought for the current documents, and whether those documents should be synchronized with current IEEE documents. Members of this WG have had plenty of opportunity to express their opinions on these two issues. The two issues are now officially declared closed. Dan and I are in agreement that consensus of the WG is that the documents in process are to be published 1) as candidates for Proposed Standard status, and 2) without trying to synchronize them with IEEE documents. We will only modify the documents according to that consensus. Thanks to everybody who contributed to the discussion, David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Dec 15 17:25:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24234; Wed, 15 Dec 2004 17:25:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CehjA-0005ha-MS; Wed, 15 Dec 2004 17:34:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CehWG-0006t5-UL; Wed, 15 Dec 2004 17:21:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CehRv-0005kP-RU for bridge-mib@megatron.ietf.org; Wed, 15 Dec 2004 17:16:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23234; Wed, 15 Dec 2004 17:16:44 -0500 (EST) Message-Id: <200412152216.RAA23234@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ceha4-0005R3-II; Wed, 15 Dec 2004 17:25:23 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004121522160201300fur16e>; Wed, 15 Dec 2004 22:16:03 +0000 From: "David B Harrington" To: , "'Wijnen, Bert \(Bert\)'" Date: Wed, 15 Dec 2004 17:15:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTi86b+d49hKF/kTqiR4WfOrmM8Dw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: "'Romascanu, Dan \(Dan\)'" , bridge-mib@ietf.org Subject: [Bridge-mib] milestone updates for the Bridge WG X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Here are milestone updates for the Bridge WG. The items have been reworded to reflect WG decisions about how to partition the work into documents. Done (dropped) Submit new I-D for RFC 1525 in SMIv2 format Done (dropped) Evaluate status of RFC 1525 and the SMIv2 version and get WG consensus if it should be recycled a Draft or can be elevated to Full Standard Done (dropped) Submit SMIv2 version of RFC 1525 to IESG for consideration as Full Standard. done (Oct 04) Submit new I-D for RFC 1493 in SMIv2 form done (Nov 04) Evaluate status of RFC 1493 and the SMIv2 version and get WG consensus if it should be recycled at Draft or can be elevated to Full Standard (consensus was to recycle at Proposed) Mar 05 Submit updated SMIv2 version of RFC 1493 to IESG for consideration as Proposed Standard, according to consensus. done (Oct 04) Submit an Internet-Draft with MIB support for RFC2674 and extensions for the Bridge standards defined in 802.1t, 802.1u, and 802.1v. done (Nov 04) Evaluate status of RFC 2674 and get WG consensus if it should be recycled at Proposed or can be elevated to Draft Standard (consensus was to recycle at Proposed) Mar 05 Submit an Internet-Draft with MIB support for RFC2674 and extensions to the Bridge standards defined in 802.1t, 802.1u, and 802.1v to IESG for consideration as Proposed Standard, according to consensus done (Sep 04) Submit an Internet-Draft with MIB support for extensions to the Bridge standards defined in 802.1w done (Sep 04) Submit an Internet-Draft with MIB support for extensions to the Bridge standards defined in 802.1w. Mar 05 Submit completed draft with MIB support for extensions to 802.1w to the IESG, for consideration as a Proposed Standard. David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Dec 17 22:00:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23962; Fri, 17 Dec 2004 22:00:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfUxw-0003QJ-O8; Fri, 17 Dec 2004 22:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfUjZ-0006Vl-Bo; Fri, 17 Dec 2004 21:54:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfUeU-0004za-Rp for bridge-mib@megatron.ietf.org; Fri, 17 Dec 2004 21:49:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21735 for ; Fri, 17 Dec 2004 21:49:00 -0500 (EST) Received: from atlrel7.hp.com ([156.153.255.213]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfUnF-0002q6-Gg for bridge-mib@ietf.org; Fri, 17 Dec 2004 21:58:06 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel7.hp.com (Postfix) with ESMTP id 6AA1110A30 for ; Fri, 17 Dec 2004 21:49:00 -0500 (EST) Received: from [127.0.0.1] (ros54018lap.americas.hpqcorp.net [15.255.5.65]) by rosemail.rose.hp.com (Postfix) with ESMTP id E86487FF3; Fri, 17 Dec 2004 18:48:59 -0800 (PST) Message-ID: <41C39955.5020804@hp.com> Date: Fri, 17 Dec 2004 18:43:33 -0800 From: John Flick User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bridge-mib@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "Congdon, Paul T" Subject: [Bridge-mib] Review comments on draft-ietf-bridge-bridgemib-smiv2-07.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hi, I had only a few comments on this draft: 1. In Section 3, bullet 4, says: "Limit the total of objects.", which should be "Limit the total number of objects." 2. Section 3.1: the term "group" has a more specific meaning in SMIv2 than it did in SMIv1. It seems like most MIB doctor reviews have been discouraging the use of the term "group" for meanings other than "OBJECT-GROUP". Perhaps "subtree" would be better here (and a few other places in the document). 3. Section 3.1.3: Should we have an Informative reference to the SR Bridge MIB RFC here (RFC 1513)? It did not exist yet when RFC 1493 was written, but it does now, so we could get rid of the vague "a separate document" wording. 4. Section 3.3 seems unnecessary - we shouldn't have to describe what a textual convention is. 5. The forward reference in the MODULE-IDENTITY {dot1dBridge 8} is known to cause problems with some broken MIB compilers. It is a problem with the MIB compilers, but customers typically don't care - they complain to the equipment vendor that provided them with the copy of the MIB module. We had the same problem with the MAU-MIB. We would save ourselves, vendors, and customers alot of grief by registering the MODULE-IDENTITY directly below mib-2. 6. The big comment blocks around the T-Cs seem unnecessary. Again, it should not be necessary to describe what a textual convention is here. Text specific to the textual convention should be in the DESCRIPTION clause, not in a comment. 7. Is the BridgeId description still correct, or did 802.1t change this? 8. On page 12 where we list registrations defined in other modules, should we also list rstpMIB? 9. I would suggest changing bridgeCompliance and bridgeCompliance2 to bridgeCompliance1493 and bridgeCompliance (or some better name for the new compliance) and making both current, to avoid deprecating support for 1493-compliant bridges. Not sure if we should be deprecating dot1dStpPortPathCost...I can see valid arguments either way. Reporting 65535, and stating that PortCost32 should be examined for the real path cost when PathCost reports 65535, would be compatible with what we did for ifSpeed/ifHighSpeed in the IF-MIB. 10. Open issues 1: I think this has been discussed on the mailing list - PortCost32 is necessitated by higher speed links, not RSTP. Can we steal some text from 802.1t Table 8.5 and the following Note 2 to explain this issue. Place it in the Overview text, or better yet, in the Description clauses of PortCost and PortCost32. 11. Open issues 3: We return bytes here. The comment above the object about how it would have been nice if we could have used ifMtu seems to imply it should be bytes. I agree we should say so exlicitly. Hope this helps, John _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Dec 17 22:28:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27482; Fri, 17 Dec 2004 22:28:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfVPa-0004Q5-Cw; Fri, 17 Dec 2004 22:37:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfVFb-0005Fc-Bp; Fri, 17 Dec 2004 22:27:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CfV9J-0004MC-6O for bridge-mib@megatron.ietf.org; Fri, 17 Dec 2004 22:20:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27089 for ; Fri, 17 Dec 2004 22:20:50 -0500 (EST) Received: from atlrel9.hp.com ([156.153.255.214]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CfVI2-0004Eq-Hi for bridge-mib@ietf.org; Fri, 17 Dec 2004 22:29:56 -0500 Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.43.209.160]) by atlrel9.hp.com (Postfix) with ESMTP id 3EDC93104; Fri, 17 Dec 2004 22:20:48 -0500 (EST) Received: from [127.0.0.1] (ros54018lap.americas.hpqcorp.net [15.255.5.65]) by rosemail.rose.hp.com (Postfix) with ESMTP id C753B7FF3; Fri, 17 Dec 2004 19:20:47 -0800 (PST) Message-ID: <41C3A0CA.1010900@hp.com> Date: Fri, 17 Dec 2004 19:15:22 -0800 From: John Flick User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Levi Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt References: <0A11633F61BD9F40B43ABCC694004F93043BD05E@zsc3c026.us.nortel.com> In-Reply-To: <0A11633F61BD9F40B43ABCC694004F93043BD05E@zsc3c026.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: "Congdon, Paul T" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit See inline. Thanks, John David Levi wrote: > Hi All, > > I've fixed some of these items, as described below, in the nroff > sources, so we'll have the changes in the next draft when/if it is > submitted. > > -Dave > > -----Original Message----- > From: bridge-mib-bounces@ietf.org [mailto:bridge-mib-bounces@ietf.org] > Sent: Friday, November 19, 2004 9:40 PM > To: bridge-mib@ietf.org > Cc: Congdon, Paul T > Subject: Re: [Bridge-mib] WG Last Call:dratf-ietf-bridge-ext-v2-03.txt > > > Hi, > > I have the following comments on this draft. I have divided my comments > into introductory text, P-BRIDGE-MIB, and Q-BRIDGE-MIB. > > Introductory text comments: > 2. References to RFC 1493 should refer to the updated version > in draft-ietf-bridge-bridgemib-smiv2-07.txt. > DBL> I don't think it makes sense to change this, since these references > DBL> will just need to be updated to the new RFC number for > DBL> draft-ietf-bridge-bridgemib-smiv2-07.txt when it is published as an > DBL> RFC. Making this change would help the RFC editor find the places that need to be updated to refer to the new RFC when published, as well as alerting the RFC editor to the dependency between these two drafts in case one gets approved by the IESG before the other. > 6. In Section 2, the following sentence: > > "IEEE 802.1Q defined port-based Virtual LANs where membership > is determined by the bridge port on which data frames are > received" > > should be updated for protocol VLANs. > DBL> Can you suggest some text? "IEEE 802.1Q defines port-based Virtual LANs where membership is determined by the bridge port on which data frames are received, and port-and-protocol-based Virtual LANs where membership is determined by the bridge port on which frames are received and the protocol identifier of the frame." Note: I picked on consistency with protocol VLANs in my comments because we define MIB objects in this document for managing protocol VLANs. This is not so much an issue of alignment with the latest version of 802.1Q as it is an issue of internal consistency of this document. > 13. Much of the text in section 3.4.3 is about to be rendered obsolete > by draft-ietf-bridge-bridgemib-smiv2-07.txt. > DBL> Is there anything in this section that will *not* be rendered > DBL> obsolete, and so should not be removed? A minimal change would be to remove the note about compliance statements not existing because the MIB uses SMIv1. > P-BRIDGE-MIB comments: > 4. Description of dot1dPortOutboundAccessPriority seems wrong - outbound > definition talks about received frame instead of transmitted frame. > DBL> Can others on the mailing-list verify this? The current wording is > DBL> the same as was in RFC 2674. We may want to leave this for IEEE to fix. 802.1D-1998 seems a bit inconsistent here - the text in section 7.5.1 suggests that the outbound access priority should be mapped from the regenerated user priority, but the text in 7.7.5 seems to say that it should be mapped from the user_priority in the receive data indication, which would be the receive user_priority before the regenerated user priority mapping is applied. > Q-BRIDGE-MIB comments: > 3. dot1qForwardAllStaticPorts description talks about non-EFS behaviour, > but the acronym EFS has not been defined, and does not appear > anywhere else in this document. > DBL> What would you suggest we change? Perhaps adding a REFERENCE to > DBL> this object? EFS probably means "extended filtering services", but the acronym is never defined in either this document or in 802.1D. This description talks about non-EFS behavior. 802.1D refers to 802.1D-1990 filtering behavior as "basic filtering services". We should just replace "non-EFS behavior" with "basic filtering services behavior". > 4. The description of dot1qPortAcceptableFrameTypes is no longer > accurate with protocol VLANs. > DBL> Can you suggest how to change the text? In the first paragraph of the description, replace "assigned to the PVID for this port" with "assigned based on the PVID and VID Set for this port". _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Dec 28 17:44:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09912; Tue, 28 Dec 2004 17:44:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQGL-0001Yn-Rb; Tue, 28 Dec 2004 17:56:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjQ09-0005ZI-N0; Tue, 28 Dec 2004 17:39:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPw4-0004ds-0h for bridge-mib@megatron.ietf.org; Tue, 28 Dec 2004 17:35:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09392 for ; Tue, 28 Dec 2004 17:35:20 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQ73-0001LF-DO for bridge-mib@ietf.org; Tue, 28 Dec 2004 17:46:46 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id ACFCD40C7; Tue, 28 Dec 2004 23:34:46 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07003-07; Tue, 28 Dec 2004 23:34:45 +0100 (CET) Received: from james (I8537.i.pppool.de [85.73.133.55]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 22D194073; Tue, 28 Dec 2004 23:34:45 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CjQr5-0002GN-U5; Wed, 29 Dec 2004 00:34:19 +0100 Date: Wed, 29 Dec 2004 00:34:19 +0100 From: Juergen Schoenwaelder To: John Flick Subject: Re: [Bridge-mib] Review comments on draft-ietf-bridge-bridgemib-smiv2-07.txt Message-ID: <20041228233419.GA4868@james> Mail-Followup-To: John Flick , bridge-mib@ietf.org, "Congdon, Paul T" References: <41C39955.5020804@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C39955.5020804@hp.com> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: "Congdon, Paul T" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a On Fri, Dec 17, 2004 at 06:43:33PM -0800, John Flick wrote: > I had only a few comments on this draft: Thanks very much for the comments. Please see my response to your comments below. Note that there are some questions where I like to have more input. > 1. In Section 3, bullet 4, says: "Limit the total of objects.", which > should be "Limit the total number of objects." fixed > 2. Section 3.1: the term "group" has a more specific meaning in SMIv2 > than it did in SMIv1. It seems like most MIB doctor reviews have > been discouraging the use of the term "group" for meanings other > than "OBJECT-GROUP". Perhaps "subtree" would be better here > (and a few other places in the document). fixed > 3. Section 3.1.3: Should we have an Informative reference to the > SR Bridge MIB RFC here (RFC 1513)? It did not exist yet when > RFC 1493 was written, but it does now, so we could get rid > of the vague "a separate document" wording. makes sense - done > 4. Section 3.3 seems unnecessary - we shouldn't have to describe > what a textual convention is. well, ok - removed > 5. The forward reference in the MODULE-IDENTITY {dot1dBridge 8} > is known to cause problems with some broken MIB compilers. > It is a problem with the MIB compilers, but customers typically > don't care - they complain to the equipment vendor that > provided them with the copy of the MIB module. We had the > same problem with the MAU-MIB. We would save ourselves, > vendors, and customers alot of grief by registering the > MODULE-IDENTITY directly below mib-2. I have replaced { dot1dBridge 8 } with { mib-2 dot1dBridge(17) 8 }. Does that address you concern? Note that we have more module identities below dot1dBridge so using { dot1dBridge 8 } is at least consistent with the other registrations. Let me know if you are happy with { mib-2 dot1dBridge(17) 8 } or have other proposals. > 6. The big comment blocks around the T-Cs seem unnecessary. Again, > it should not be necessary to describe what a textual convention > is here. Text specific to the textual convention should be in > the DESCRIPTION clause, not in a comment. removed TC explanation and moved semantics into DESCRIPTION clauses > 7. Is the BridgeId description still correct, or did 802.1t change > this? I have no clue - someone familiar with 802.1t must provide input or the description stays as it is now. > 8. On page 12 where we list registrations defined in other modules, > should we also list rstpMIB? I have added a comment. However, I am not sure what the status and future of draft-ietf-bridge-rstpmib-05.txt is. Dave, can you tell me what to do here? > 9. I would suggest changing bridgeCompliance and bridgeCompliance2 > to bridgeCompliance1493 and bridgeCompliance (or some better > name for the new compliance) and making both current, to avoid > deprecating support for 1493-compliant bridges. Not sure if > we should be deprecating dot1dStpPortPathCost...I can see > valid arguments either way. Reporting 65535, and stating > that PortCost32 should be examined for the real path cost when > PathCost reports 65535, would be compatible with what we did > for ifSpeed/ifHighSpeed in the IF-MIB. I think it does not make sence to have a current compliance statement which refers to a deprecated object. I do like the proposal to rename the compliance statements and I do agree that the bridgeCompliance1493 should be current given the actual deployment of this module. So I tend to make dot1dStpPortPathCost current and to add language similar to the ifSpeed/ifHighSpeed objects in the IF-MIB. > 10. Open issues 1: I think this has been discussed on the mailing > list - PortCost32 is necessitated by higher speed links, not > RSTP. Can we steal some text from 802.1t Table 8.5 and the > following Note 2 to explain this issue. Place it in the > Overview text, or better yet, in the Description clauses of > PortCost and PortCost32. Since I do not have 802.1t, can you please draft some text to put in place? > 11. Open issues 3: We return bytes here. The comment above the > object about how it would have been nice if we could have used > ifMtu seems to imply it should be bytes. I agree we should > say so exlicitly. I have added UNITS "bytes" and I have closed this issue. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Tue Dec 28 17:45:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10007; Tue, 28 Dec 2004 17:45:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQGs-0001aR-Lh; Tue, 28 Dec 2004 17:56:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjQ0R-0005ak-S0; Tue, 28 Dec 2004 17:39:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjPyB-0004kZ-4W; Tue, 28 Dec 2004 17:37:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09457; Tue, 28 Dec 2004 17:37:32 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjQ9A-0001OM-1d; Tue, 28 Dec 2004 17:48:57 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id BBA404088; Tue, 28 Dec 2004 23:37:02 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06869-10; Tue, 28 Dec 2004 23:37:02 +0100 (CET) Received: from james (I8537.i.pppool.de [85.73.133.55]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id D807E4073; Tue, 28 Dec 2004 23:37:01 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CjQtI-0002Gm-V8; Wed, 29 Dec 2004 00:36:37 +0100 Date: Wed, 29 Dec 2004 00:36:36 +0100 From: Juergen Schoenwaelder To: internet-drafts@ietf.org Message-ID: <20041228233636.GA8719@james> Mail-Followup-To: internet-drafts@ietf.org, bridge-mib@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: bridge-mib@ietf.org Subject: [Bridge-mib] please post draft-ietf-bridge-bridgemib-smiv2-08.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Please post the following document as an Internet Draft: This ID is a product of the bridge mib working group. Thanks, /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Dec 29 12:34:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26553; Wed, 29 Dec 2004 12:34:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjhtK-0004Oj-8y; Wed, 29 Dec 2004 12:45:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjhgc-000235-UV; Wed, 29 Dec 2004 12:32:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjhZX-0008Ah-R6 for bridge-mib@megatron.ietf.org; Wed, 29 Dec 2004 12:25:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25752 for ; Wed, 29 Dec 2004 12:25:17 -0500 (EST) Message-Id: <200412291725.MAA25752@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjhkf-00048j-NR for bridge-mib@ietf.org; Wed, 29 Dec 2004 12:36:52 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004122917244501400qvudne>; Wed, 29 Dec 2004 17:24:45 +0000 From: "David B Harrington" To: , "'John Flick'" Subject: RE: [Bridge-mib] Review comments ondraft-ietf-bridge-bridgemib-smiv2-07.txt Date: Wed, 29 Dec 2004 12:24:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041228233419.GA4868@james> Thread-Index: AcTtLtt+orTzhQsXT4KwRRpF6lRGVAAkGaoQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Hi, I have opened issues for some of the items John raised that may require discussion. My comments inline reflect the RT Ticket Numbers for opened issues. I did not open tickets for the editorial tweaks. David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG > -----Original Message----- > From: bridge-mib-bounces@ietf.org > [mailto:bridge-mib-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > > > 3. Section 3.1.3: Should we have an Informative reference to the > > SR Bridge MIB RFC here (RFC 1513)? It did not exist yet when > > RFC 1493 was written, but it does now, so we could get rid > > of the vague "a separate document" wording. > > makes sense - done This should be RFC 1525, not RFC 1513. ------------------------------------------ RT Ticket#757: > > > 5. The forward reference in the MODULE-IDENTITY {dot1dBridge 8} > > is known to cause problems with some broken MIB compilers. > > It is a problem with the MIB compilers, but customers typically > > don't care - they complain to the equipment vendor that > > provided them with the copy of the MIB module. We had the > > same problem with the MAU-MIB. We would save ourselves, > > vendors, and customers alot of grief by registering the > > MODULE-IDENTITY directly below mib-2. > > I have replaced { dot1dBridge 8 } with { mib-2 dot1dBridge(17) 8 }. > Does that address you concern? Note that we have more module > identities > below dot1dBridge so using { dot1dBridge 8 } is at least consistent > with the other registrations. Let me know if you are happy with > { mib-2 dot1dBridge(17) 8 } or have other proposals. I have concerns that this change will impact OTHER broken MIB compilers. I suspect many compilers that broke as the result of the forward reference in SMIv2 will have already been fixed for this problem. I believe some compilers may have a problem with the new proposed syntax, and don't want to make this a moving target. Let's keep the forward reference approach that is legal SMIv2 and common in other IETF standard MIB modules. If a MIB compiler still breaks as the result of the (legal) forward reference, then the broken compiler should be fixed. ------------------------------------------ > > > 6. The big comment blocks around the T-Cs seem unnecessary. Again, > > it should not be necessary to describe what a textual convention > > is here. Text specific to the textual convention should be in > > the DESCRIPTION clause, not in a comment. > > removed TC explanation and moved semantics into DESCRIPTION clauses Makes sense to me. ------------------------------------------ RT Ticket#758: > > > 7. Is the BridgeId description still correct, or did 802.1t change > > this? > > I have no clue - someone familiar with 802.1t must provide input or > the description stays as it is now. We are not changing this document to be up-to-date with the most recent IEEE documents. Such an update can be done by the IEEE 802.1 WG. Changing the BridgeID semantics might alter the semantics of a number of objects and require that we deprecate and redefine such objects. We should not change BridgeId if it changes the semantics of any objects in the MIB module. ------------------------------------------ RT Ticket#759: > > > 8. On page 12 where we list registrations defined in other modules, > > should we also list rstpMIB? > > I have added a comment. However, I am not sure what the status and > future of draft-ietf-bridge-rstpmib-05.txt is. Dave, can you tell > me what to do here? I personally find it bad practice to predefine subtrees that are not actually used within a document, and I discourage the practice. I object to adding this registration here. ------------------------------------------ RT Ticket#760 (and 669): > > > 9. I would suggest changing bridgeCompliance and bridgeCompliance2 > > to bridgeCompliance1493 and bridgeCompliance (or some better > > name for the new compliance) and making both current, to avoid > > deprecating support for 1493-compliant bridges. Not sure if > > we should be deprecating dot1dStpPortPathCost...I can see > > valid arguments either way. Reporting 65535, and stating > > that PortCost32 should be examined for the real path cost when > > PathCost reports 65535, would be compatible with what we did > > for ifSpeed/ifHighSpeed in the IF-MIB. > > I think it does not make sence to have a current compliance statement > which refers to a deprecated object. I do like the proposal to rename > the compliance statements and I do agree that the bridgeCompliance1493 > should be current given the actual deployment of this module. So I > tend to make dot1dStpPortPathCost current and to add language similar > to the ifSpeed/ifHighSpeed objects in the IF-MIB. > ------------------------------------------ RT Ticket#761: > > 10. Open issues 1: I think this has been discussed on the mailing > > list - PortCost32 is necessitated by higher speed links, not > > RSTP. Can we steal some text from 802.1t Table 8.5 and the > > following Note 2 to explain this issue. Place it in the > > Overview text, or better yet, in the Description clauses of > > PortCost and PortCost32. > > Since I do not have 802.1t, can you please draft some text to put > in place? Keep in mind we are not trying to update this document to the current IEEE documents, but simply to update the original 1493 MIB module. We have added this object (a decision I sorely regret now) but any changes we make now should not impact the semantics of the original objects or require any other updates to the document, if possible. John can you propose some text for the description clause? ------------------------------------------ RT Ticket#763: > > > 11. Open issues 3: We return bytes here. The comment above the > > object about how it would have been nice if we could have used > > ifMtu seems to imply it should be bytes. I agree we should > > say so exlicitly. > > I have added UNITS "bytes" and I have closed this issue. As co-chair, I will consider this issue closed if there are no objections. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Bridge-mib mailing list > Bridge-mib@ietf.org > https://www1.ietf.org/mailman/listinfo/bridge-mib > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Dec 29 13:02:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28036; Wed, 29 Dec 2004 13:02:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjiKJ-0004xx-FO; Wed, 29 Dec 2004 13:13:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cji1n-0005sV-Nz; Wed, 29 Dec 2004 12:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjhrP-0004DP-Ix for bridge-mib@megatron.ietf.org; Wed, 29 Dec 2004 12:43:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27032 for ; Wed, 29 Dec 2004 12:43:44 -0500 (EST) Message-Id: <200412291743.MAA27032@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cji2Y-0004Zk-TS for bridge-mib@ietf.org; Wed, 29 Dec 2004 12:55:20 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004122917431401400r27kfe>; Wed, 29 Dec 2004 17:43:15 +0000 From: "David B Harrington" To: , "'John Flick'" Date: Wed, 29 Dec 2004 12:43:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041228233419.GA4868@james> Thread-Index: AcTtLtt+orTzhQsXT4KwRRpF6lRGVAAnsTXA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T'" , bridge-mib@ietf.org Subject: [Bridge-mib] Bridge#764: smiv2-07: add original authors as contacts X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Updated contact info: Andrew Smith ah_smith@pacbell.net FAX 415 345 1827 Anil Rijhsinghani Accton Technology Corporation 5 Mount Royal Ave Marlboro, MA 01752 USA we have no updated contact info for Paul Langille or E.Decker. David Harrington dbharrington@comcast.net _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Dec 29 16:02:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11989; Wed, 29 Dec 2004 16:02:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjl98-0000k9-Nv; Wed, 29 Dec 2004 16:14:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjkjG-0005z3-TO; Wed, 29 Dec 2004 15:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjkYj-0000IN-Nu; Wed, 29 Dec 2004 15:36:41 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08962; Wed, 29 Dec 2004 15:36:39 -0500 (EST) Message-Id: <200412292036.PAA08962@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 29 Dec 2004 15:36:39 -0500 Cc: bridge-mib@ietf.org Subject: [Bridge-mib] I-D ACTION:draft-ietf-bridge-bridgemib-smiv2-08.txt X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bridge MIB Working Group of the IETF. Title : Definitions of Managed Objects for Bridges Author(s) : K. Norseth, E. Bell Filename : draft-ietf-bridge-bridgemib-smiv2-08.txt Pages : 45 Date : 2004-12-29 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing MAC bridges based on the IEEE 802.1D-1998 standard between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges The MIB module presented in this memo is a translation of the BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemib-smiv2-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-bridge-bridgemib-smiv2-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-bridge-bridgemib-smiv2-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-29153942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-bridge-bridgemib-smiv2-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-bridge-bridgemib-smiv2-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-29153942.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib --NextPart-- From bridge-mib-bounces@ietf.org Wed Dec 29 18:16:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00246; Wed, 29 Dec 2004 18:16:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjnEe-0006he-2y; Wed, 29 Dec 2004 18:28:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjn1Q-00071o-5Y; Wed, 29 Dec 2004 18:14:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjmhU-0005rS-U4 for bridge-mib@megatron.ietf.org; Wed, 29 Dec 2004 17:53:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27540 for ; Wed, 29 Dec 2004 17:53:50 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cjmsf-0006D4-Bl for bridge-mib@ietf.org; Wed, 29 Dec 2004 18:05:27 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id EBA334066; Wed, 29 Dec 2004 23:53:13 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25289-01; Wed, 29 Dec 2004 23:53:13 +0100 (CET) Received: from james (Ib9f0.i.pppool.de [85.73.185.240]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E42C54052; Wed, 29 Dec 2004 23:53:12 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CjnxA-0000r6-C2; Thu, 30 Dec 2004 01:14:08 +0100 Date: Thu, 30 Dec 2004 01:14:08 +0100 From: Juergen Schoenwaelder To: David B Harrington Message-ID: <20041230001408.GD3207@james> Mail-Followup-To: David B Harrington , 'John Flick' , "'Congdon, Paul T'" , bridge-mib@ietf.org References: <20041228233419.GA4868@james> <20041229174316.D1F674053@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041229174316.D1F674053@hermes.iu-bremen.de> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "'Congdon, Paul T'" , "'John Flick'" , bridge-mib@ietf.org Subject: [Bridge-mib] Re: Bridge#764: smiv2-07: add original authors as contacts X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Wed, Dec 29, 2004 at 12:43:10PM -0500, David B Harrington wrote: > Updated contact info: > > Andrew Smith > ah_smith@pacbell.net > FAX 415 345 1827 Is not an author of RFC 1493 as far as I can tell. > Anil Rijhsinghani > Accton Technology Corporation > 5 Mount Royal Ave > Marlboro, MA 01752 > USA Already in the document. > we have no updated contact info for Paul Langille or E.Decker. This is what I need. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Dec 29 18:28:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01611; Wed, 29 Dec 2004 18:28:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjnQA-0006xX-59; Wed, 29 Dec 2004 18:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjnEA-0005V1-Qr; Wed, 29 Dec 2004 18:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cjn6j-0003Cn-IA for bridge-mib@megatron.ietf.org; Wed, 29 Dec 2004 18:19:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00754 for ; Wed, 29 Dec 2004 18:19:54 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjnHw-0006mK-JL for bridge-mib@ietf.org; Wed, 29 Dec 2004 18:31:33 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3300B4088; Thu, 30 Dec 2004 00:19:26 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25985-05; Thu, 30 Dec 2004 00:19:25 +0100 (CET) Received: from james (Ib9f0.i.pppool.de [85.73.185.240]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id D14254083; Thu, 30 Dec 2004 00:19:24 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CjoMW-0000s3-AW; Thu, 30 Dec 2004 01:40:20 +0100 Date: Thu, 30 Dec 2004 01:40:20 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Bridge-mib] Review comments ondraft-ietf-bridge-bridgemib-smiv2-07.txt Message-ID: <20041230004020.GE3207@james> Mail-Followup-To: David B Harrington , 'John Flick' , "'Congdon, Paul T'" , bridge-mib@ietf.org References: <20041228233419.GA4868@james> <20041229172447.900D44066@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041229172447.900D44066@hermes.iu-bremen.de> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "'Congdon, Paul T'" , "'John Flick'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac On Wed, Dec 29, 2004 at 12:24:41PM -0500, David B Harrington wrote: > > > 3. Section 3.1.3: Should we have an Informative reference to the > > > SR Bridge MIB RFC here (RFC 1513)? It did not exist yet when > > > RFC 1493 was written, but it does now, so we could get rid > > > of the vague "a separate document" wording. > > > > makes sense - done > > This should be RFC 1525, not RFC 1513. Fixed. > ------------------------------------------ > RT Ticket#757: > > > > > 5. The forward reference in the MODULE-IDENTITY {dot1dBridge 8} > > > is known to cause problems with some broken MIB compilers. > > > It is a problem with the MIB compilers, but customers typically > > > don't care - they complain to the equipment vendor that > > > provided them with the copy of the MIB module. We had the > > > same problem with the MAU-MIB. We would save ourselves, > > > vendors, and customers alot of grief by registering the > > > MODULE-IDENTITY directly below mib-2. > > > > I have replaced { dot1dBridge 8 } with { mib-2 dot1dBridge(17) 8 }. > > Does that address you concern? Note that we have more module > > identities > > below dot1dBridge so using { dot1dBridge 8 } is at least consistent > > with the other registrations. Let me know if you are happy with > > { mib-2 dot1dBridge(17) 8 } or have other proposals. > > I have concerns that this change will impact OTHER broken MIB > compilers. I suspect many compilers that broke as the result of the > forward reference in SMIv2 will have already been fixed for this > problem. I believe some compilers may have a problem with the new > proposed syntax, and don't want to make this a moving target. Let's > keep the forward reference approach that is legal SMIv2 and common in > other IETF standard MIB modules. If a MIB compiler still breaks as the > result of the (legal) forward reference, then the broken compiler > should be fixed. I have reverted back to the original format. But see below. > ------------------------------------------ > RT Ticket#759: > > > > > 8. On page 12 where we list registrations defined in other > modules, > > > should we also list rstpMIB? > > > > I have added a comment. However, I am not sure what the status and > > future of draft-ietf-bridge-rstpmib-05.txt is. Dave, can you tell > > me what to do here? > > I personally find it bad practice to predefine subtrees that are not > actually used within a document, and I discourage the practice. > I object to adding this registration here. We can't change the pBridgeMIB and qBridgeMIB registration anymore. We can of course move the bridgeMIB MODULE-IDENTITY registration to { mib-2 xxx } (which also addresses issue #757) and we can remove the comments that refer to the srMIB, dot1dPortPair, rstpMIB. We probably want to add a note saying the usage of the dot1dBridge subtree by other MIB modules is strongly discouraged. Any objections against this approach? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Wed Dec 29 19:40:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05574; Wed, 29 Dec 2004 19:40:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjoXZ-0008K9-69; Wed, 29 Dec 2004 19:51:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjoKm-0004aX-PQ; Wed, 29 Dec 2004 19:38:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjoFg-0003wb-Um for bridge-mib@megatron.ietf.org; Wed, 29 Dec 2004 19:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05108 for ; Wed, 29 Dec 2004 19:33:13 -0500 (EST) Message-Id: <200412300033.TAA05108@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjoQt-00089d-Gg for bridge-mib@ietf.org; Wed, 29 Dec 2004 19:44:52 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2004123000324301500c1ck0e>; Thu, 30 Dec 2004 00:32:43 +0000 From: "David B Harrington" To: Date: Wed, 29 Dec 2004 19:32:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041230001408.GD3207@james> Thread-Index: AcTt+S4k/dB5n37xSv+cS/cPeFTmyAADa+tw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: bridge-mib@ietf.org Subject: [Bridge-mib] RE: Bridge#764: smiv2-07: add original authors as contacts X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Unless they respond with updated info, we can do without. David Harrington dbharrington@comcast.net co-chair, IETF Bridge WG > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, December 29, 2004 7:14 PM > To: David B Harrington > Cc: 'John Flick'; 'Congdon, Paul T'; bridge-mib@ietf.org > Subject: Re: Bridge#764: smiv2-07: add original authors as contacts > > On Wed, Dec 29, 2004 at 12:43:10PM -0500, David B Harrington wrote: > > > Updated contact info: > > > > Andrew Smith > > ah_smith@pacbell.net > > FAX 415 345 1827 > > Is not an author of RFC 1493 as far as I can tell. > > > Anil Rijhsinghani > > Accton Technology Corporation > > 5 Mount Royal Ave > > Marlboro, MA 01752 > > USA > > Already in the document. > > > we have no updated contact info for Paul Langille or E.Decker. > > This is what I need. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Thu Dec 30 14:49:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10405; Thu, 30 Dec 2004 14:49:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck6Tv-0001Lr-PY; Thu, 30 Dec 2004 15:01:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck6Er-0003Rz-T8; Thu, 30 Dec 2004 14:45:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ck67C-0001Ik-SH for bridge-mib@megatron.ietf.org; Thu, 30 Dec 2004 14:37:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09486 for ; Thu, 30 Dec 2004 14:37:41 -0500 (EST) Message-Id: <200412301937.OAA09486@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ck6Ia-0000yI-VF for bridge-mib@ietf.org; Thu, 30 Dec 2004 14:49:29 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2004123019361001400r042ge>; Thu, 30 Dec 2004 19:36:11 +0000 From: "David B Harrington" To: Subject: RE: [Bridge-mib] Review comments ondraft-ietf-bridge-bridgemib-smiv2-07.txt Date: Thu, 30 Dec 2004 14:36:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <20041230004020.GE3207@james> Thread-Index: AcTt/NcgcnglBN4SSBywo3KjtyRrSQACtfEQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: "'Congdon, Paul T'" , "'John Flick'" , bridge-mib@ietf.org X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7bit Hi, Comments inline. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:schoenw@iu-bremen.de] On > Behalf Of Juergen Schoenwaelder > Sent: Wednesday, December 29, 2004 7:40 PM > To: David B Harrington > Cc: 'John Flick'; 'Congdon, Paul T'; bridge-mib@ietf.org > Subject: Re: [Bridge-mib] Review comments > ondraft-ietf-bridge-bridgemib-smiv2-07.txt > > > ------------------------------------------ > > RT Ticket#757: > > > > > > > 5. The forward reference in the MODULE-IDENTITY {dot1dBridge 8} > > > > is known to cause problems with some broken MIB compilers. > > > > It is a problem with the MIB compilers, but > customers typically > > > > don't care - they complain to the equipment vendor that > > > > provided them with the copy of the MIB module. We had the > > > > same problem with the MAU-MIB. We would save ourselves, > > > > vendors, and customers alot of grief by registering the > > > > MODULE-IDENTITY directly below mib-2. > > > > > > I have replaced { dot1dBridge 8 } with { mib-2 > dot1dBridge(17) 8 }. > > > Does that address you concern? Note that we have more module > > > identities > > > below dot1dBridge so using { dot1dBridge 8 } is at least > consistent > > > with the other registrations. Let me know if you are happy with > > > { mib-2 dot1dBridge(17) 8 } or have other proposals. > > > > I have concerns that this change will impact OTHER broken MIB > > compilers. I suspect many compilers that broke as the result of the > > forward reference in SMIv2 will have already been fixed for this > > problem. I believe some compilers may have a problem with the new > > proposed syntax, and don't want to make this a moving target. Let's > > keep the forward reference approach that is legal SMIv2 and > common in > > other IETF standard MIB modules. If a MIB compiler still > breaks as the > > result of the (legal) forward reference, then the broken compiler > > should be fixed. > > I have reverted back to the original format. But see below. Thanks. > > > ------------------------------------------ > > RT Ticket#759: > > > > > > > 8. On page 12 where we list registrations defined in other > > modules, > > > > should we also list rstpMIB? > > > > > > I have added a comment. However, I am not sure what the status and > > > future of draft-ietf-bridge-rstpmib-05.txt is. Dave, can you tell > > > me what to do here? > > > > I personally find it bad practice to predefine subtrees that are not > > actually used within a document, and I discourage the practice. > > I object to adding this registration here. > > We can't change the pBridgeMIB and qBridgeMIB registration anymore. > We can of course move the bridgeMIB MODULE-IDENTITY registration to > { mib-2 xxx } (which also addresses issue #757) and we can remove the > comments that refer to the srMIB, dot1dPortPair, rstpMIB. We probably > want to add a note saying the usage of the dot1dBridge subtree by > other MIB modules is strongly discouraged. Any objections against > this approach? For the SMI experts amongst us, can we legally register the MODULE-IDENTITY in the following way? dot1dBridge MODULE-IDENTITY ... ::= { mib-2 17 } RFC1493 registered dot1dbridge using "dot1dbridge OBJECT IDENTIFIER ::= { mib-2 17 }" Juergen pointed out that the SMIv2-to-SMIv1 translation of a MODULE-IDENTITY is simply an OID, so this might be legal. If we can do this, it would move the mib up under mib-2, and eliminate the forward reference (issue #757). It would also place the object and notification subtrees under the dot1dBridge MODULE-IDENTITY, approximating the recommended practices from draft-ietf-ops-mib-review-guidelines Suggested OID layout. We would want to remove the comment showing the assignment of bridgeMIB to { dot1dBridge 8 } And change dot1dConformance from { bridgeMIB 1 } to { dot1dBridge ## }, where ## is an unused subtree, possibly { dot1dBridge 8 } It is unfortunate that the MODULE-IDENTITY dot1dBridge would not mirror the BRIDGE-MIB name, and pBridge and qBridge MODULE-IDENTITIES are under dot1dBridge MODULE-IDENTITY, but we cannot change that now without great pain. Dbh > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib From bridge-mib-bounces@ietf.org Fri Dec 31 13:51:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17889; Fri, 31 Dec 2004 13:51:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkS3R-0007Pn-T4; Fri, 31 Dec 2004 14:03:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkRqi-0001Zy-Vo; Fri, 31 Dec 2004 13:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CkRpw-0001O6-Mv for bridge-mib@megatron.ietf.org; Fri, 31 Dec 2004 13:49:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17754 for ; Fri, 31 Dec 2004 13:49:19 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CkS1U-0007L9-O8 for bridge-mib@ietf.org; Fri, 31 Dec 2004 14:01:19 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id iBVImekc027602; Fri, 31 Dec 2004 10:48:40 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id iBVImfli003550; Fri, 31 Dec 2004 10:48:41 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id iBVImelR003539; Fri, 31 Dec 2004 10:48:40 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 31 Dec 2004 10:48:40 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: bridge-mib@ietf.org Subject: RE: [Bridge-mib] Review comments on draft-ietf-bridge-bridgemib-smiv2-07.txt In-Reply-To: <200412301937.OAA09486@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: bridge-mib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: bridge-mib.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: bridge-mib-bounces@ietf.org Errors-To: bridge-mib-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a On Thu, 30 Dec 2004, David B Harrington wrote: > For the SMI experts amongst us, can we legally register the > MODULE-IDENTITY in the following way? > > dot1dBridge MODULE-IDENTITY > ... > ::= { mib-2 17 } > > RFC1493 registered dot1dbridge using "dot1dbridge OBJECT IDENTIFIER > ::= { mib-2 17 }" > Juergen pointed out that the SMIv2-to-SMIv1 translation of a > MODULE-IDENTITY is simply an OID, so this might be legal. This is legal. The effect is to associate a registration, as well as an OID value, with the descriptor dot1dBridge, but the semantics remain unchanged, and any MIB module that imports the descriptor will continue to compile, and all subordinate OIDs will resolve to the same value as before. Note that RFC 2578 Section 3.6 explicitly allows the same descriptor to be associated with a registration and an assignment: A descriptor is allowed to be associated with both a registration and an assignment, providing both are associated with the same OBJECT IDENTIFIER value and semantics. For some precedents, the following definition in RFC 1406 ds1 OBJECT IDENTIFIER ::= { transmission 18 } has been translated to ds1 MODULE-IDENTITY ... ::= { transmission 18 } in RFCs 2495 and 3895 and the following definition in RFC 1407 ds3 OBJECT IDENTIFIER ::= { transmission 30 } has been translated to ds3 MODULE-IDENTITY ... ::= { transmission 30 } in RFCs 2496 and 3896. > If we can do this, it would move the mib up under mib-2, and eliminate > the forward reference (issue #757). > It would also place the object and notification subtrees under the > dot1dBridge MODULE-IDENTITY, approximating the recommended practices > from draft-ietf-ops-mib-review-guidelines Suggested OID layout. All of these sound to me like Good Things. Mike Heard _______________________________________________ Bridge-mib mailing list Bridge-mib@ietf.org https://www1.ietf.org/mailman/listinfo/bridge-mib