From hubmib-bounces@ietf.org Wed Jan 03 06:24:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24Dw-00006U-Gp; Wed, 03 Jan 2007 06:24:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H24Dt-00004t-Ls; Wed, 03 Jan 2007 06:23:57 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H24Dq-0005PW-CI; Wed, 03 Jan 2007 06:23:57 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l03BMxFE017235; Wed, 3 Jan 2007 05:23:47 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 05:23:25 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Jan 2007 12:23:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Jan 2007 12:23:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PLS review BEFORE 10 Jan 2007 - IANA-MAU-MIB under mib-2 (rfc3636bis) Thread-Index: AccvKY92B3Mpv1IhRA6CyhnZswM46A== From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 03 Jan 2007 11:23:23.0216 (UTC) FILETIME=[9455BD00:01C72F29] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Hubmib] PLS review BEFORE 10 Jan 2007 - IANA-MAU-MIB under mib-2 (rfc3636bis) X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org Dear HUBMIBers, First, a happy, prosperous and healthy new year to all of you. draft-ietf-hubmib-rfc3636bis-05.txt is in the RFC-editor Queue and is in a stage where IANA wants to make the final registration for the IANA-MAU-MIB. During that step, we found that the document=20 draft-ietf-hubmib-rfc3636bis-05.txt suggest to put this new IANA-maintained MIB module under ::=3D { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1 It is not a (fatal) technical flaw, but... sofar, ALL IANA maintained MIB modules are located directly under mib-2. I missed this during my reviews. The proposal now is to make this MIB module location inline with all other IANA maintained MIB modules and so to ask=20 for assignment as follows: IANA-MAU-MIB .. snip .. ianaMauMIB MODULE-IDENTITY .. snip .. ::=3D { mib-2 nnn } -- to be assigned by IANA Pls speak up BEFORE 10 Jan 2007 if you see an issue with this (late) change. Silence will (this time) be interpreted as no-objection. Bert Wijnen chair HUBMIB WG. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Wed Jan 03 10:18:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27sg-0001D4-Ll; Wed, 03 Jan 2007 10:18:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H27se-0001CS-NN for hubmib@ietf.org; Wed, 03 Jan 2007 10:18:16 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H27sc-0001O0-BX for hubmib@ietf.org; Wed, 03 Jan 2007 10:18:16 -0500 Received: (qmail 26687 invoked from network); 3 Jan 2007 07:18:09 -0800 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Jan 2007 07:18:09 -0800 Date: Wed, 3 Jan 2007 07:18:09 -0800 (PST) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Hub Mib Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Hubmib] Re: PLS review BEFORE 10 Jan 2007 - IANA-MAU-MIB under mib-2 (rfc3636bis) X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org On Wed, 3 Jan 2007 12:23:15 +0100 Bert Wijnen wrote: > draft-ietf-hubmib-rfc3636bis-05.txt is in the RFC-editor Queue > and is in a stage where IANA wants to make the final > registration for the IANA-MAU-MIB. > During that step, we found that the document > draft-ietf-hubmib-rfc3636bis-05.txt > suggest to put this new IANA-maintained MIB module under > ::= { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1 > > It is not a (fatal) technical flaw, but... > sofar, ALL IANA maintained MIB modules are located > directly under mib-2. I missed this during my reviews. > > The proposal now is to make this MIB module location inline > with all other IANA maintained MIB modules and so to ask > for assignment as follows: > > IANA-MAU-MIB > .. snip .. > ianaMauMIB MODULE-IDENTITY > .. snip .. > ::= { mib-2 nnn } -- to be assigned by IANA > > Pls speak up BEFORE 10 Jan 2007 if you see an issue with this > (late) change. > Silence will (this time) be interpreted as no-objection. Here is some perspective from the MIB Doctor reviewer. Although I recommended during my early reviews to put the MODULE-IDENTITY value for the IANA-MAU-MIB under mib-2, I also noted that it is not a technical flaw to have it set to { mib-2 snmpDot3MauMgt(26) 7 }. So I let it pass as long as the assignment was noted with the appropriate ASN.1 comments in the MAU-MIB, which "owns" the { mib-2 snmpDot3MauMgt(26) } OID branch, which was done. I am frankly uneasy about making such last-minute changes if they are not necessary to correct technical flaws, as they tend to introduce errors or inconsistencies elsewhere. If the WG does agree to make the change to the IANA-MAU-MIB MODULE-IDENTITY assignment, then the following change also needs to be made to the ASN.1 comments in the MAU-MIB: OLD: -- the following OID is the MODULE-IDENTITY value -- for this MIB module: { snmpDot3MauMgt 6 } -- the following OID is the MODULE-IDENTITY value -- for the IANA-MAU-MIB: { snmpDot3MauMgt 7 } NEW: -- the following OID is the MODULE-IDENTITY value -- for this MIB module: { snmpDot3MauMgt 6 } The text to be removed is at the bottom of p. 12 and the top of p. 13 of draft-ietf-hubmib-rfc3636bis-05.txt. Mike _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Jan 15 16:13:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z8c-0005D2-1C; Mon, 15 Jan 2007 16:13:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z8a-0005Cq-W9 for hubmib@ietf.org; Mon, 15 Jan 2007 16:13:05 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Z8X-0004ap-GG for hubmib@ietf.org; Mon, 15 Jan 2007 16:13:04 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0FLD082025022 for ; Mon, 15 Jan 2007 15:13:01 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 15:13:00 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 22:12:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 15 Jan 2007 22:12:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Internet-Draft Boilerplate Reminder Thread-index: Acc4xe0SKcO2/eHBQlKbwOhJjPwD9QAIudfg From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 15 Jan 2007 21:12:59.0469 (UTC) FILETIME=[EF2E8FD0:01C738E9] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.2 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Subject: [Hubmib] FW: Internet-Draft Boilerplate Reminder X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org FYI and consideration when new revisions are submitted Bert=20 -----Original Message----- From: IETF Secretariat [mailto:ietf-secretariat@ietf.org]=20 Sent: maandag 15 januari 2007 17:51 To: IETF Announcement list Cc: iesg@ietf.org Subject: Internet-Draft Boilerplate Reminder=20 This message is to remind you that as of February 1, 2007 the IETF Secretariat will no longer accept Internet-Drafts with the old (i.e. pre RFC 4748) boilerplate. For your convenience, below is the text of the message that was sent to the IETF Announcement List by the IETF Chair on October 26, 2006 with Subject: Update to Internet Draft and RFC Boilerplate. The IETF Secretariat. -------------------------------------------------------------- A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate. XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team -------- Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. NEW "Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." NEW "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE=20 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD "Copyright (C) The Internet Society . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." NEW "Copyright (C) The IETF Trust . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." When the MIB or PIB module is the initial version of a module that is to be maintained by the IANA, the following abbreviated notice shall be included: OLD "Copyright (C) The Internet Society . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." NEW "Copyright (C) The IETF Trust . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From 133kalle@innersell.com Tue Jan 16 04:03:02 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kDe-0001HC-GS; Tue, 16 Jan 2007 04:03:02 -0500 Received: from [189.137.19.67] (helo=mbbdyi.hhif8kuj.rr.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6kDV-0005Lw-6G; Tue, 16 Jan 2007 04:03:02 -0500 Message-ID: <61365144407693.732E238C35@MKG7> From: "(270) 818-7244 Merrill " <298al@mail.jl.cn> To: Subject: Get a Diploma without the hassel! Date: Tue, 16 Jan 2007 03:04:44 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: kKnj6y4hKbSF9XyHN8qQ23tKX0xCJxeazVMa Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Greetings Grow-archive! A Genuine Univers1ty Degree 1n 4-6 weeks! Have you ever thought that the only thing sotpping you from a great job and better pay was a few letters behind you name? Well now you can get them! BA BSc MA MSc MBA PhD Within 4-6 weeks! No Study Requierd! 100% Verifiable! These are real, genuine degrees that include Bachelors,M asters, MBA and Doctorate Degrees. They are fully verifiable and certified transcripts are also available. Just call the numbre below. You?ll thank me later? Ring Us Today +1 (270) 818-7244 7 days a week 24/7 **************************** best not kill the ones who held to their faith. His ribs ached withproudly, as if its presence alone could turn the camp into a Romanmarched straight into myths? Asia-especially Central Asia-is anmurmured by Tiberbank, not whispered this way. And there were otherstrength himself from the way the centurion went about his rounds,the sun, which could blind you here, where even in May the sunlightmurmured by Tiberbank, not whispered this way. And there were otherwhich upheld first the Roman republic, and then the Empire- the From hubmib-bounces@ietf.org Tue Jan 16 04:07:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kHm-0003n7-MY; Tue, 16 Jan 2007 04:07:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kHl-0003kX-Cx for hubmib@ietf.org; Tue, 16 Jan 2007 04:07:17 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6kHj-0004eO-SA for hubmib@ietf.org; Tue, 16 Jan 2007 04:07:17 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0G974WM018780; Tue, 16 Jan 2007 03:07:11 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 03:07:04 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 10:07:02 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Hubmib] Re: PLS review BEFORE 10 Jan 2007 - IANA-MAU-MIB under mib-2 (rfc3636bis) Date: Tue, 16 Jan 2007 10:03:31 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hubmib] Re: PLS review BEFORE 10 Jan 2007 - IANA-MAU-MIB under mib-2 (rfc3636bis) Thread-index: AccvSnZuIQNArmPlRWmzN8ZjkZqMnAKAcekA From: "Wijnen, Bert \(Bert\)" To: "Hub Mib" X-OriginalArrivalTime: 16 Jan 2007 09:07:02.0766 (UTC) FILETIME=[AFC6E0E0:01C7394D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: "C. M. Heard" X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org The only comment I have seen is that Mike feels a bit uneasy about the change, because of a risk of messing up. (not that I had stated that silence would be interpreted as no objection).=20 The good news is that Mike also included additional instructions to make sure we do not mess up. Thanks Mike. SO I interpret this as consensus to request IANA for the change. So I will tell IANA that we want the change as follows: Document draft-ietf-hubmib-rfc3636bis-05.txt suggests to put=20 the new IANA-maintained IANA-MAU-MIB module under ::=3D { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1 =20 It is not a (fatal) technical flaw, but... sofar, ALL IANA maintained MIB modules are located directly under=20 mib-2. I missed this during my reviews (as HUBMIB WG chair). =20 The WG has consensus to make this MIB module location inline=20 with all other IANA maintained MIB modules and so we ask for=20 assignment as follows: IANA-MAU-MIB .. snip .. ianaMauMIB MODULE-IDENTITY .. snip .. ::=3D { mib-2 nnn } -- to be assigned by IANA Pls note that this also means that these comments need to be changed (bottom of page 12, top of page 13) by the RFC-Editor: OLD: -- the following OID is the MODULE-IDENTITY value -- for this MIB module: { snmpDot3MauMgt 6 } =20 -- the following OID is the MODULE-IDENTITY value -- for the IANA-MAU-MIB: { snmpDot3MauMgt 7 } =20 NEW: -- the following OID is the MODULE-IDENTITY value -- for this MIB module: { snmpDot3MauMgt 6 } =20 Bert Wijnen HUBMIB WG chair > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com]=20 > Sent: woensdag 3 januari 2007 16:18 > To: Hub Mib > Subject: [Hubmib] Re: PLS review BEFORE 10 Jan 2007 -=20 > IANA-MAU-MIB under mib-2 (rfc3636bis) >=20 > On Wed, 3 Jan 2007 12:23:15 +0100 Bert Wijnen wrote: > > draft-ietf-hubmib-rfc3636bis-05.txt is in the RFC-editor=20 > Queue and is=20 > > in a stage where IANA wants to make the final registration for the=20 > > IANA-MAU-MIB. > > During that step, we found that the document > > draft-ietf-hubmib-rfc3636bis-05.txt > > suggest to put this new IANA-maintained MIB module under > > ::=3D { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1 > >=20 > > It is not a (fatal) technical flaw, but... > > sofar, ALL IANA maintained MIB modules are located directly under=20 > > mib-2. I missed this during my reviews. > >=20 > > The proposal now is to make this MIB module location inline=20 > with all=20 > > other IANA maintained MIB modules and so to ask for assignment as=20 > > follows: > > > > IANA-MAU-MIB > > .. snip .. > > ianaMauMIB MODULE-IDENTITY > > .. snip .. > > ::=3D { mib-2 nnn } -- to be assigned by IANA > >=20 > > Pls speak up BEFORE 10 Jan 2007 if you see an issue with this > > (late) change. > > Silence will (this time) be interpreted as no-objection. >=20 > Here is some perspective from the MIB Doctor reviewer. >=20 > Although I recommended during my early reviews to put the=20 > MODULE-IDENTITY value for the IANA-MAU-MIB under mib-2, I=20 > also noted that it is not a technical flaw to have it set to=20 > { mib-2 snmpDot3MauMgt(26) 7 }. So I let it pass as long as=20 > the assignment was noted with the appropriate > ASN.1 comments in the MAU-MIB, which "owns" the { mib-2=20 > snmpDot3MauMgt(26) } OID branch, which was done. >=20 > I am frankly uneasy about making such last-minute changes if=20 > they are not necessary to correct technical flaws, as they=20 > tend to introduce errors or inconsistencies elsewhere. > If the WG does agree to make the change to the IANA-MAU-MIB=20 > MODULE-IDENTITY assignment, then the following change also=20 > needs to be made to the ASN.1 comments in the MAU-MIB: >=20 > OLD: > -- the following OID is the MODULE-IDENTITY value > -- for this MIB module: { snmpDot3MauMgt 6 } >=20 > -- the following OID is the MODULE-IDENTITY value > -- for the IANA-MAU-MIB: { snmpDot3MauMgt 7 } >=20 > NEW: > -- the following OID is the MODULE-IDENTITY value > -- for this MIB module: { snmpDot3MauMgt 6 } >=20 > The text to be removed is at the bottom of p. 12 and the top=20 > of p. 13 of draft-ietf-hubmib-rfc3636bis-05.txt. >=20 > Mike >=20 > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Tue Jan 16 04:08:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kIj-0004W4-7h; Tue, 16 Jan 2007 04:08:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6kIh-0004Vi-Ae; Tue, 16 Jan 2007 04:08:15 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6kIg-0004pR-1D; Tue, 16 Jan 2007 04:08:15 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l0G974WK018780; Tue, 16 Jan 2007 03:07:04 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 03:07:03 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 10:07:01 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 16 Jan 2007 10:06:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IANA #33594] draft-ietf-hubmib-rfc3636bis Thread-index: Acc5M+HykAal8ZF/RLiHI/DhRQbKxAAGVcxg From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 16 Jan 2007 09:07:01.0642 (UTC) FILETIME=[AF1B5EA0:01C7394D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: edward.beili@actelis.com, Hub Mib , dromasca@avaya.com, iesg@ietf.org, hubmib-ads@tools.ietf.org, rfc-editor@rfc-editor.org Subject: [Hubmib] RE: [IANA #33594] draft-ietf-hubmib-rfc3636bis X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org Michelle (IANA), Document draft-ietf-hubmib-rfc3636bis-05.txt suggests to put=20 the new IANA-maintained IANA-MAU-MIB module under ::=3D { mib-2 snmpDot3MauMgt(26) 7 } -- mauMod+1 =20 It is not a (fatal) technical flaw, but... sofar,=20 ALL IANA maintained MIB modules are located directly under=20 mib-2. I missed this during my reviews (as HUBMIB WG chair). I have checked with the WG, and the WG has consensus to=20 make this MIB module location inline with all other=20 IANA maintained MIB modules and so we ask for=20 assignment as follows: IANA-MAU-MIB .. snip .. ianaMauMIB MODULE-IDENTITY .. snip .. ::=3D { mib-2 nnn } -- to be assigned by IANA Pls note that this also means that the following comments need to be changed (bottom of page 12, top of page 13) by=20 the RFC-Editor: OLD: -- the following OID is the MODULE-IDENTITY value -- for this MIB module: { snmpDot3MauMgt 6 } =20 -- the following OID is the MODULE-IDENTITY value -- for the IANA-MAU-MIB: { snmpDot3MauMgt 7 } =20 NEW: -- the following OID is the MODULE-IDENTITY value -- for this MIB module: { snmpDot3MauMgt 6 } =20 Bert Wijnen HUBMIB WG chair _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu Jan 18 14:40:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7d7n-0002Jb-K1; Thu, 18 Jan 2007 14:40:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7d7m-0002JW-Hq for hubmib@ietf.org; Thu, 18 Jan 2007 14:40:38 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7d7l-000198-Kk for hubmib@ietf.org; Thu, 18 Jan 2007 14:40:38 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0IJeRlE002298; Thu, 18 Jan 2007 13:40:28 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 13:40:27 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 20:40:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] My review of: draft-ietf-hubmib-efm-cu-mib-06.txt Date: Thu, 18 Jan 2007 20:39:50 +0100 Message-ID: In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550AF7FA7B@nl0006exch001u.nl.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hubmib] My review of: draft-ietf-hubmib-efm-cu-mib-06.txt Thread-Index: AccSOnrmhQlHEtW9SfqC9BBdl0yl4wAAWy5gCgjMysA= From: "Wijnen, Bert \(Bert\)" To: "Edward Beili" X-OriginalArrivalTime: 18 Jan 2007 19:40:25.0547 (UTC) FILETIME=[800691B0:01C73B38] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4be0d55bab88df9d21005ced9551e26 Cc: "Dan Romascanu \(E-mail\)" , Hub Mib X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org My appology, "this week" took a bit longer than I had expected.=20 So here is my review as WG chair. - SMICng: W: f(EFM-CU-MIB.mi2), (300,21) Item "efmCuPAFDiscoveryCode" should have SIZE specified W: f(EFM-CU-MIB.mi2), (1178,21) Item "efmCuPAFRemoteDiscoveryCode" should have SIZE specified W: f(EFM-CU-MIB.mi2), (2925,23) For "efmCuPmeSubTypesSupported", syntax is identical for the first two, I think: SIZE(6) for the 3rd one I am OK to let the warning go., i.e. ignore it. W: f(IF-CAP-STACK-MIB.mi2), (195,17) Row "ifInvCapStackEntry" does not have a consistent indexing scheme - index items must be in same order as used in INDEX clause for "base row" ifStackEntry E: f(IF-CAP-STACK-MIB.mi2), (291,13) Item "ifInvStackGroup" should be IMPORTed Warning is OK I think, but pls fix error. - You may want to add a note-to-rfcs-editor to: [I-D.ietf-hubmib-efm-mib] Squire, M., "Definitions and Managed Objects for OAM Functions on Ethernet Like Interfaces", draft-ietf-hubmib-efm-mib-04 (work in progress), March 2006. [I-D.ietf-hubmib-rfc3636bis] Beili, E., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", draft-ietf-hubmib-rfc3636bis-05 (work in progress), July 2006. in which you ask them to replace with actual RFC numbers if those are available at time of publication. - note that if you do a revision, you must use new copyright and no longer=20 Copyright (C) The Internet Society (2006). See my earlier post to the hubmib list - Did we resolve the use of Rowstatus for the ifCapStackTable and ifInvCapStackTable? In any event, pls re-check the=20 feedback we've got on that. I do not think that what we currently have in the MIB module is acceptable. - In order to avoid any possible future name clashed, I would prefer it if we rename Textual Convnetions: ProfileIndex ::=3D TEXTUAL-CONVENTION ProfileIndexOrZero ::=3D TEXTUAL-CONVENTION ProfileIndexList ::=3D TEXTUAL-CONVENTION TruthValueOrUnknown ::=3D TEXTUAL-CONVENTION such that they are prefixed with Efm, so I would name them: EfmProfileIndex ::=3D TEXTUAL-CONVENTION EfmProfileIndexOrZero ::=3D TEXTUAL-CONVENTION EfmProfileIndexList ::=3D TEXTUAL-CONVENTION EfmTruthValueOrUnknown ::=3D TEXTUAL-CONVENTION this is also common practice in most (if not all) other=20 IETF MIB modules these days - for efmCuPAFAdminState you describe a few operations that should be ignore when tried. I am not sure how to inerpret that and what would happen when a SNMP SET is received. I would think it is better to say the need to be rejected. (that is, cause an error on an SNMP SET). - for=20 efmCuPAFDiscoveryCode OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-write STATUS current DESCRIPTION "PAF Discovery Code of the EFMCu port (PCS). A unique 6 Byte long code used by the Discovery function, when PAF is supported. PCS ports incapable of supporting PAF SHALL return a value of all zeroes. Attempts to change this object SHALL be ignored in this case. This object MUST be instantiated for the -O subtype PCS before writing operations on the efmCuPAFRemoteDiscoveryCode (Set_if_Clear and Clear_if_Same) are performed by PMEs associated with the PCS. The value of this object is read-only for -R port subtypes. The initial value of this object for -R ports after reset is 0. This value may be changed as a result of writing operation on efmCuPAFRemoteDiscoveryCode variable of remote PME of -O subtype, connected to one of the local PMEs associated with the PCS. Discovery MUST be performed when the link is Down. Attempts to change this object MUST be rejected with the error inconsistentValue if the link is Up or Initializing. The PAF Discovery code maps to the local Discovery code variable in PAF (note that it does not have a corresponding Clause 45 register)" REFERENCE "[802.3ah] 61.2.2.8.3, 61.2.2.8.4, 45.2.6.6.1" ::=3D { efmCuPortConfEntry 2 } I am trying to figure out what made you choose PhysAddress as the SYNTAX for the discovery code. Can you explain, or point me to the 802.3ah clause that explains/justifies that? I wonder what you mean with "the value of this object is read-only" The value has to be a PhysAddress ( 6 octets) value, no? If you mean that for -R port subtypes the object cannot allow write access, then I would say it in terms aka: The initial value of this object for -R port subtypes after reset is all zeroes. For such -R ports, the value of this object cannot be changed directly. The value may be changed as a result of a writing operation on the=20 efmCuPAFRemoteDiscoveryCode object of a remote PME of=20 -O subtype, connected to one of the local PMEs associated with the PCS. I hope I understood the intention and reworded it properly. These day we prefer to not hard-wire SNMP error codes in DESCRIPTION clause, or if we do, then as an example (A MIB could be used by non SNMP protocols). SO I suggest=20 =20 Discovery MUST be performed when the link is Down. Attempts to change this object MUST be rejected (in case of SNMP with the error inconsistentValue) if the link is Up=20 or Initializing. - For efmCuAdminProfile I read in DESCRIPTION clause: This object is writable and readable for the -O subtype (2BaseTL-O or 10PassTS-O) EFMCu ports. It is unavailable for the -R subtype (2BaseTL-R or 10PassTS-R) ports. what does it mean that this object is "unavailable" Do you not want it instatntiated in that case, or do you want its value to be ignored/irrelevant? Pls be specific. You use that at various other places as well. Pls check and fix. - For efmCuPAFRemoteDiscoveryCode OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS read-write STATUS current DESCRIPTION "PAF Remote Discovery Code of the PME port at CO. A 6 Byte long Discovery Code of the peer PCS connected via the PME. Reading this object results in a Discovery Get operation. Writing a zero to this object results in a Discovery Clear_if_Same operation (the value of efmCuPAFDiscoveryCode at the peer PCS SHALL be the same as efmCuPAFDiscoveryCode of the local PCS associated with the PME for the operation to succeed). Writing a non-zero value to this object results in a Discovery Set_if_Clear operation. This object does not exist in CPE port subtypes. A zero length octet string SHALL be returned for CPE port subtypes and also when PAF aggregation is not enabled. What is "writing a zero value" ?? Is that 6 octets, all zeroes? Or one octet conatining zero,=20 or the zero length octet-string? What means "does not exist" is it not instanctiated? I guess so. pls be clear. You do get gaps in the tables if some objects are not instantiated. Might be easier (on NM apps) if there was a value (like all zeros, or zerolength string) that can be ignored. - I believe I have seen this SYNTAX SYNTAX INTEGER { ieee2BaseTLO(1), ieee2BaseTLR(2), ieee10PassTSO(3), ieee10PassTSR(4) } several times. Candidate for a Textual Convention? - for efmCuPme2BRegion I wonder if we ever (soon?) expect more regions? If so, maybe we ought to make this a TC? How will regions be added? - For efmCuPme2BProfileRowStatus I wonder if any (all?) of the objects in a row can be changed while the row is active? Would that not=20 be disruptive? In any event, pls specify if any (which( objects can be changed or stat eif none can be change in active state. Same question for efmCuPme2BsModeRowStatus, although there a change is probably not disruptive. Pls check all occurences of RowStatus - I really wonder if we are doing a smart thing by give the same labels to the various enums in efmCuPme10PBandplanPSDMskProfile INTEGER, efmCuPme10PUPBOReferenceProfile INTEGER, efmCuPme10PBandNotchProfiles BITS, efmCuPme10PPayloadURateProfile INTEGER, efmCuPme10PPayloadDRateProfile INTEGER, They have different meanings, don't they? So would it not be better to differentiate between the labels of the neumerations? - For OBBJECT-GROUP definitions, one is NOT supposed to state requirements or optional attributes. Such things (if a group if required or optional) are stated in the MODULE-COMPLIANCE. The OBJECT0GROUP macro is ONLY intended to group objects that logically fit together in order to model something. Sof (for example): efmCuBasicGroup OBJECT-GROUP OBJECTS { efmCuPAFSupported, efmCuAdminProfile, efmCuTargetDataRate, efmCuTargetSnrMgn, efmCuAdaptiveSpectra, efmCuPortSide, efmCuFltStatus } STATUS current DESCRIPTION "A collection of objects required for all of EFMCu ports." ::=3D { efmCuGroups 1 } Sould NOT state that these objects are "required". I would phrase it as: "A collection of objects reperesenting management information that is common for all of EFMCu ports." The fact that is is REQUIRED for all EFMCu ports is expressed in efmCuCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION ... snip ... MODULE -- this module MANDATORY-GROUPS { efmCuBasicGroup, That is, here it is listed in the MANDATORY-GROUPS clause and so that inidicated that it is required. =20 Pls try to rephrase for all OBJECT-GROUPs - With regard to naming, I am somewhat worried about the conventions that are used (or maybe those that are not used). I always find it smarter to have all columnar objects in a table prefixed with a string that makes it clear to which table the object belongs. For example for the efmCuPortConfTable: EfmCuPortConfEntry ::=3D SEQUENCE { efmCuPAFAdminState INTEGER, efmCuPAFDiscoveryCode PhysAddress, efmCuAdminProfile ProfileIndexList, efmCuTargetDataRate Unsigned32, efmCuTargetSnrMgn Unsigned32, efmCuAdaptiveSpectra TruthValue, efmCuThreshLowRate Unsigned32, efmCuLowRateCrossingEnable TruthValue } =20 I would personally prefer the columns to be alll prefixed with=20 efmCuPortConf, so I would have named them as follows: EfmCuPortConfEntry ::=3D SEQUENCE { efmCuPortConfPAFAdminState INTEGER, efmCuPortConfPAFDiscoveryCode PhysAddress, efmCuPortConfAdminProfile ProfileIndexList, efmCuPortConfTargetDataRate Unsigned32, efmCuPortConfTargetSnrMgn Unsigned32, efmCuPortConfAdaptiveSpectra TruthValue, efmCuPortConfThreshLowRate Unsigned32, efmCuPortConfLowRateCrossingEnable TruthValue } This also holds true for most (all of) the other tables. My suggested naming convention above has (in my view) 2 advantages: =20 - less change for conflicting names.=20 I will admit, that this is not too big a risk, since this is all within the same MIB module. Nevertheless, I think it just makes it easier if any additions need to be made in the future. - easier for people to see which objects belong to which tables. I think this is a strong point. But I also understand it is somewhat subjective. I can accept if the WG and/or editor/author tells me that I am far too late with this type of comment. It of course requires a quite=20 massive editorial change. So, although I think it would improve the human-friendlyness of the MIB module, I will not insist on this change. NITS: - the RFC editor probably wants you to expand acronyms when they are used for the first time. Pls check you do it for all acronyms. I found for example VDSL, DMT, SHDSL acronyms which have not been expanded. There may be others. Pls check. - For: ifCapStackEntry OBJECT-TYPE SYNTAX IfCapStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information on a particular relationship between two sub-layers, specifying that one sub-layer runs on 'top' of the other sub-layer. Each sub-layer corresponds to a conceptual I wonder if we should: s/runs on top/can run on 'top'/ After all, it is a capability, which not necessarily is used, right? - for efmCuPAFDiscoveryCode you speak about a "6 Byte code" If this is common 802.3 terminology, then I guess it is OK. I know that some people in the IETF prefer to use 'octet' instead of 'byte'. - This table efmCuPmeStatusTable OBJECT-TYPE SYNTAX SEQUENCE OF EfmCuPmeStatusEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table provides common status information of EFMCu 2BASE-TL/10PASS-TS PME ports. Status information specific to 10PASS-TS PME is represented in efmCuPme10PStatusTable. This table contains live data from the equipment. As such, it is NOT persistent." ::=3D { efmCuPme 3 } Is cmposed of just read-only objects. So the last sentence of the DESCRIPTION clause is not needed. In general people expect (I think) writable objects when they see such a ststament. - For efmCuPme2BProfileDescr I think I would change the uppercase MAY to a lowercase may. Same for efmCuPme10PProfileDescr. There may be other places. Pls check RFC2119 to understand how/when capilaized terms are needed. They are for COMPLIANCE, the two objects above have no special compliance requirments for content except for adhering to the SYNTAX, right? TYPOs: - typo in table 1: | ifIndex | Interface index. Note that each PME and each PCS | | | in the EFMCu PHY MUST have a unique index, as | | | there some PCS and PME specific attributes | | | accessible only on the PCS or PME level. | =20 s/there some/there are some/ I think - 3rd para of sect 4.3: A specific configuration or administrative profile is assigned to a specific PME via efmCuPmeAdminProfile object. If efmCuPmeAdminProfile is zero, then efmCuAdminProfile object of the PCS port, connected to the PME, determines the configuration profile (or a list of possible profiles) for that PME. This mechanism allows to specify a common profile(s) for all PMEs connected to the PCS port, with an ability to change individual PME profiles by setting efmCuPmeAdminProfile object, which overwrites profile set by efmCuAdminProfile. s/overwrites profile set by/overwrites the profile set by/ I think. > -----Original Message----- > From: Wijnen, Bert (Bert)=20 > Sent: maandag 27 november 2006 16:52 > To: Edward Beili; Wijnen, Bert (Bert) > Cc: Dan Romascanu (E-mail) > Subject: RE: [Hubmib] My review of:=20 > draft-ietf-hubmib-efm-cu-mib-06.txt >=20 > Better to wait. I will try to get my review done this week. >=20 > Bert >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: Monday, November 27, 2006 16:41 > > To: Wijnen, Bert (Bert) > > Cc: Dan Romascanu (E-mail) > > Subject: RE: [Hubmib] My review of:=20 > > draft-ietf-hubmib-efm-cu-mib-06.txt > >=20 > >=20 > > Bert, > > I've got a few comments about IF-CAP-STACK-MIB in addition to yours. > > Should I issue another version of > > draft-ietf-hubmib-efm-cu-mib fixing those or should I wait for you=20 > > comments on the EFM-CU-MIB? > >=20 > > Regards, > > -E. > >=20 > > > -----Original Message----- > > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > > Sent: Wednesday, October 18, 2006 5:45 PM > > > To: Hubmib Mailing List (E-mail) > > > Subject: [Hubmib] My review of:=20 > draft-ietf-hubmib-efm-cu-mib-06.txt > > >=20 > > >=20 > > > My WG LC review comments are here. > > > For the EFM-U-MIB itself I will do a separate posting to the list. > > >=20 > > > - Abstract 3rd line > > >=20 > > > This document proposes an extension to the Ethernet-like=20 > > > Interfaces > > >=20 > > > By the time we get published as RFC, we no longer "propose". > > > So how about: > > >=20 > > > This document describes extensions to the Ethernet-like > > Interfaces > > >=20 > > > - Page 7, a nit: > > > // pottentially be connected to the PCS > > > s/pottentially/potentially/ > > > // for PCS[i] and there room for another=20 > PME in the > > > s/there room/there is room/ ?? > > >=20 > > > - A nit/typo on page 10: > > > | ifIndex | Interface index. Note that each PME and=20 > > > each PCS | > > > | | in the EFMCu PHY MUST have a unique=20 > > > index, as | > > > | | there some PCS and PME specific=20 > > > attributes | > > > | | accessible only on the PCS or PME level.=20 > > > | > > >=20 > > > s/as there some/as there are some/ ?? > > >=20 > > > - a type in 2nd para in sect 4.2 > > >=20 > > > The PME profiles are defined in efmCuPme2BProfileTable and > > > efmCu10PProfileTable for 2BASE-TL and 10PASS-TS PMEs > > respectively. > > >=20 > > > I think: s/efmCu10PProfileTable/efmCuPme10PProfileTable/ > > > So insert "Pme" > > >=20 > > > - SMICng IF-CAP-STACK-MIB tells me: > > >=20 > > > W: f(IF-CAP-STACK-MIB.mi2), (195,17) Row "ifInvCapStackEntry" > > > does not have a consistent indexing scheme - index=20 > items must > > > be in same order as used in INDEX clause for "base row" > > > ifStackEntry > > >=20 > > > The above is OK, it is an INVERTED table. > > > So we can ignore the warning. > > >=20 > > > E: f(IF-CAP-STACK-MIB.mi2), (291,13) Item "ifInvStackGroup" > > > should be IMPORTed > > >=20 > > > I think that error should be fixed and we shoul dimport > > that group. > > >=20 > > > - SMICNg EFM-CU-MIB tells me: > > >=20 > > > W: f(EFM-CU-MIB.mi2), (300,21) Item > > "efmCuPAFDiscoveryCode" should > > > have SIZE specified > > >=20 > > > Do we know a reasonable size for this? In the pseudo code on=20 > > > pages 7/8 > > > it speaks about a 6-byte (octet) code. And so does the > > DESCRIPTION > > > clause. Is it always fixed to 6 octets? > > > Now and in future? If so, I would suggest to use > > >=20 > > > SYNTAX PhysAddress (SIZE(6)) > > >=20 > > > W: f(EFM-CU-MIB.mi2), (1178,21) Item > > "efmCuPAFRemoteDiscoveryCode" > > > should have SIZE specified > > >=20 > > > Same story for the above. > > >=20 > > > W: f(EFM-CU-MIB.mi2), (2925,23) For=20 > "efmCuPmeSubTypesSupported", > > > syntax is identical > > >=20 > > > This is probably OK, although it looks a bit weird: > > > OBJECT efmCuPmeSubTypesSupported > > > SYNTAX BITS { > > > ieee2BaseTLO(0), > > > ieee2BaseTLR(1), > > > ieee10PassTSO(2), > > > ieee10PassTSR(3) > > > } > > > DESCRIPTION > > > "Support for all subtypes is not required.=20 > > > However at least > > > one value SHALL be supported" > > >=20 > > > - W.r.t. the SYNTAX of objects ifCapStackStatus and=20 > > > ifInvCapStackStatus > > > I think it would be much better to use a SYNTAX of TruthValue. > > > See my separate posting on this topic to the HubMIB WG list. > > >=20 > > > - I believe that instead of > > >=20 > > > ifCapStackConformance OBJECT IDENTIFIER > > > ::=3D { ifCapStackObjects 3 } > > >=20 > > > It would be better to adhere to the strcuture suggested by > > > RFC4181 page 38 > > > and so use instead: > > >=20 > > > ifCapStackConformance OBJECT IDENTIFIER ::=3D { > > ifCapStackMIB 2 } > > >=20 > > > - I still need to review the EFM-CU-MIB module. I will do=20 > a separate=20 > > > posting > > > on that one once I am done. > > >=20 > > > - In the Security Considerations section I see capitalized MAY > > > which I think is not what RFC2119 intended. Unless you can=20 > > > explain to me why this capilaized MAY makes sense, I would > > > prefer if we change it to just lowercase "may" for all > > > occurences in the Security Considerations section. > > >=20 > > > - 2nd para on page 83 (a NIT): > > > Even if the network itself is secure (for example by > > using IPSec), > > > pls change "IPSec" into "IPsec", that is a lower case "s". > > > The current MIB security template has it fixed. I know that the > > > Security ADs want/prefer the proper spelling. > > >=20 > > > - IANA Considerations. > > > Since you state that some values SHALL be defined in the > > > IANA-MAU-MIB, I think that you make rfc3636bis a normative > > > reference, while it is now listed under informative.=20 > And by making > > > that document normative, you/we automagically make sure=20 > that this > > > efmCuMIB will not get published before 3636bis. > > >=20 > > > You must also request/ask (in IANA COnsiderations section) that=20 > > > IANA assigns two new OID branches for > > >=20 > > > ifCapStackMIB ::=3D { mib-2 ZZZ } > > >=20 > > > efmCuMIB ::=3D { mib-2 YYY } > > >=20 > > > - If/wehen we do a revision, we must adhere to new boilerplate. > > > That means we must change all occurences of: > > >=20 > > > Copyright (C) The Internet Society (2006). > > >=20 > > > into > > >=20 > > > Copyright (C) The IETF Trust (2006). > > >=20 > > > If you are using xml2rfc, thsi can be achieved with: > > >=20 > > > ipr=3D"full3978update" > > >=20 > > > You can/could not yet know this. I know that this starts > > on Nov 1st > > > (because I was asked to update the IDChecklist.html. > > >=20 > > > Bert > > >=20 > > > _______________________________________________ > > > Hubmib mailing list > > > Hubmib@ietf.org > > > https://www1.ietf.org/mailman/listinfo/hubmib > > >=20 > >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu Jan 18 20:09:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7iGI-0008Ky-9K; Thu, 18 Jan 2007 20:09:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7iGG-0008Kt-Tx for hubmib@ietf.org; Thu, 18 Jan 2007 20:09:44 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7iGF-0006Oa-Iw for hubmib@ietf.org; Thu, 18 Jan 2007 20:09:44 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l0J19TdP001793; Thu, 18 Jan 2007 19:09:29 -0600 (CST) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Jan 2007 19:09:28 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 02:09:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jan 2007 02:09:13 +0100 Message-ID: In-Reply-To: <467C77F6373BDE4BB16A3E8A62C03955A56AA9@Exchserv.hatteras.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-hubmib-efm-mib-05.txt Thread-Index: Acb15slA2Mx+c38ORrCQ5RNd32/CHRFfFk+A From: "Wijnen, Bert \(Bert\)" To: "Matt Squire" , "Dan Romascanu \(E-mail\)" X-OriginalArrivalTime: 19 Jan 2007 01:09:26.0651 (UTC) FILETIME=[76A3FCB0:01C73B66] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Hub Mib Subject: [Hubmib] RE: draft-ietf-hubmib-efm-mib-05.txt X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org Wow... this one dropped through the cracks. And nobody warned me. Oh well.. I see (I means smicng tells me) an INDEX object: dot3OamEventLogIndex OBJECT-TYPE SYNTAX Unsigned32=20 that would need a range. I assume that zero is not an intended value, so I would do: dot3OamEventLogIndex OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) I also see that you have mad a few "editorial" changes - a few occurences of "possibility" into "possiblity". The latter is nota real word, is it? - "multiplexer" into "mulitplexor" ?? - "identifying" into "identifiying" ?? Anyway, the latter can be fixed by RFC editor, and the INDEX fix (if that is acceptable) can be done with a note-to-rfc-editor by Dan, or we can see it as a first IETF Last Call Comments. I don't think we need to respin a new version for this. (However, if you do plan a new rev, then pls be aware you need new copy-right text, as I posted to the list last week). Dan, if you agree we do not need a new rev for this, can you pls move to the next step, which I think is IETF Last Call. Bert > -----Original Message----- > From: Matt Squire [mailto:MSquire@HatterasNetworks.com]=20 > Sent: zondag 22 oktober 2006 7:32 > To: Wijnen, Bert (Bert) > Cc: Dan Romascanu (E-mail) > Subject: RE: draft-ietf-hubmib-efm-mib-05.txt >=20 > Just as a re-cap, the changes from -04 were minimal > - change last paragraph of Section 5 as per D Perkins comment > - change text around initial OUI value from "zero" to "three=20 > octets of zero" per D Perkins comment > - Change PDU size information for (0|64..1518) rather than=20 > (0..1518) with text saying "1..63 are not allowed" > - change order of enable/disable in OAM state, and=20 > passive/active of OAM mode to match order of clause 30 and=20 > your and Dan's suggestion > - any header/title changes to reflect new version and date >=20 > Hope that makes the review easier. =20 >=20 > - Matt >=20 >=20 > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Sunday, October 22, 2006 5:55 AM > > To: Matt Squire > > Cc: Dan Romascanu (E-mail) > > Subject: RE: draft-ietf-hubmib-efm-mib-05.txt > >=20 > > Thanks Matt! I'll review asap. > >=20 > > Bert > >=20 > > > -----Original Message----- > > > From: Matt Squire [mailto:MSquire@HatterasNetworks.com] > > > Sent: Saturday, October 21, 2006 21:03 > > > To: internet-drafts@ietf.org > > > Cc: Wijnen, Bert (Bert) > > > Subject: draft-ietf-hubmib-efm-mib-05.txt > > > > > > > > > > > > Please accept this Internet Draft revision for the hubmib working=20 > > > group. > > > Thanks. > > > > > > - Matt > > > > > > >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Fri Jan 19 14:40:25 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zb5-0005O9-61; Fri, 19 Jan 2007 14:40:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7zb4-0005O4-MG for hubmib@ietf.org; Fri, 19 Jan 2007 14:40:22 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7zb2-000342-9J for hubmib@ietf.org; Fri, 19 Jan 2007 14:40:22 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l0JJeHnX028995 for ; Fri, 19 Jan 2007 13:40:19 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 13:40:17 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jan 2007 20:40:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jan 2007 20:40:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HUBMIB WG Milestone updates Thread-Index: Acc7/5r4h8d4VaZ4Qo2iX6HRxufP1wAAZS2Q From: "Wijnen, Bert \(Bert\)" To: "Hub Mib" X-OriginalArrivalTime: 19 Jan 2007 19:40:15.0470 (UTC) FILETIME=[A46EB0E0:01C73C01] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Hubmib] FW: HUBMIB WG Milestone updates X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org FYI, this is what I have asked as updates to our (overdue) milestone(s). Don't take april as a "oh we have plenty of time". I have chosen the month after the upcoming IETF as a date that we really=20 CAN and SHOULD meet. The EFM-CU-MIB is our last document to complete. Ed Beili has indicated he will try (and be able) to=20 do an update (to address the comments on the=20 current revision) in the next few weeks. Bert Wijnen HUBMIB WG chair =20 -----Original Message----- From: Wijnen, Bert (Bert)=20 Sent: vrijdag 19 januari 2007 11:26 To: iesg-secretary@ietf.org Cc: dromasca@avaya.com Subject: HUBMIB WG Milestone updates Secretariat, can you pls update the HUBMIB WG milestones. The last 3 milestones currently read: Nov 2006 Submit (3) EFM MIB Internet-Drafts to the IESG for=20 consideration as Proposed Standards =20 Dec 2006 WG Last Call for updated MAU MIB document =20 Jan 2007 Submit updated MAU MIB document to the IESG for consideration as a Proposed standard, replacing RFC 3636 =20 The last two have been completed, so can be marked as DONE. The first one is partially done. 2 MIB documents have been submitted, the 3rd one is still being worked on. Maybe you can change that milestone into 3 milestones: Done Submit EFM-MIB for consideration as Proposed Standard =20 Done Submit EFM-EPON-MIB for consideration as Proposed Standard=20 Apr 2007 Submit EFM-CU-MIB for consideration as Proposed Standard=20 Thanks, Bert=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mtdklzoxyib@opticon.hu Tue Jan 23 10:36:16 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9Nh2-00020T-3w for hubmib-archive@lists.ietf.org; Tue, 23 Jan 2007 10:36:16 -0500 Received: from host-161-70.opticon.hu ([85.90.161.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9Ngz-0008I3-Rk for hubmib-archive@lists.ietf.org; Tue, 23 Jan 2007 10:36:15 -0500 From: "UsContact Admin" To: hubmib-archive@lists.ietf.org Subject: Refinance approved Date: Tue, 23 Jan 2007 16:40:05 -0100 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C73F0D.230DF330" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Acc/DSMNpFU2PNAuTdePtmmubVzT8g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 2.4 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0005_01C73F0D.230DF330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for your loan request, which we recieved yesterday, your refinance application has been accepted

Good Credit or Not, We are ready to give you a $377,000 loan, after further review, our lenders have established the lowest monthly payments.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second Secure Web-Form.

www.amoremioos.com
------=_NextPart_000_0005_01C73F0D.230DF330-- From ohltysshr@coral.com Thu Jan 25 09:00:06 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA594-0003Lt-94 for hubmib-archive@lists.ietf.org; Thu, 25 Jan 2007 09:00:06 -0500 Received: from [193.109.249.122] (helo=[193.109.249.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA592-0000ji-Bq for hubmib-archive@lists.ietf.org; Thu, 25 Jan 2007 09:00:05 -0500 From: "Motion tension" To: hubmib-archive@lists.ietf.org Subject: Loan request approved Date: Thu, 25 Jan 2007 16:00:01 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0005_01C74099.DEBE35D0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdAmd6+Mgah6rxnQWCuyMmhdZxrwA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <6D9B0E99431AD11.C7612AF879@coral.com> X-Spam-Score: 2.6 (++) X-Scan-Signature: d6b246023072368de71562c0ab503126 ------=_NextPart_000_0005_01C74099.DEBE35D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thank you for your loan request, which we recieved yesterday, your refinance application has been accepted

Good Credit or Not, We are ready to give you a $372,000 loan, after further review, our lenders have established the lowest monthly payments.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second Secure Web-Form.

www.worlfdepaandas.com
------=_NextPart_000_0005_01C74099.DEBE35D0-- From shosgygvczo@carterexcavating.com Fri Jan 26 01:21:08 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAKSR-0006rC-QN for hubmib-archive@lists.ietf.org; Fri, 26 Jan 2007 01:21:07 -0500 Received: from [150.140.180.182] (helo=[150.140.180.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HAKSQ-0006iu-0N for hubmib-archive@lists.ietf.org; Fri, 26 Jan 2007 01:21:07 -0500 From: "digitized" To: hubmib-archive@lists.ietf.org Subject: Next Big market Winner! Date: Fri, 26 Jan 2007 08:20:53 -0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0002_01C74122.E54E0EA0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdBIuVO27T6hwkHTMGSMz8P6gEhmw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: X-Spam-Score: 1.7 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 ------=_NextPart_000_0002_01C74122.E54E0EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
<> ATTENTION DAY TRADERS AND INVESTORS. GET ON PSUD! <>

INVESTOR ALERT! DON'T MISS THIS RUN ON PSUD!!!

Watch PSUD Like a Hawk on January 26, 2007

Company: PetroSun
Sym: PSUD
Currently: $0.43 (+0.01 Close)
Friday Target: $1.50

PHOENIX, AZ--(MRKET WIRE)--Jan 11, 2007 -- PetroSun, Incorporated (Other 0TC:PSUD,PK - News) announced today that an agreement has been executed with New Standard Exploration NL of West Perth, Australia covering Exploration Permit 417 located within the Canning Basin of Western Australia. PetroSun and New Standard will form a joint venture to explore, develop and produce oil and/or gas from EP417. PetroSun is the designated Manager/Operator and will be assigned a 75% working interest in the permit for the initial consideration of A$5,000,000 through PetroSun's sole funding of exploration, permit development and drilling.

Keep a look out for additional GREAT weekly news and be sure to watch them trade like crazy on Friday January 26, 2007

------=_NextPart_000_0002_01C74122.E54E0EA0-- From hubmib-bounces@ietf.org Fri Jan 26 10:43:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATEa-0002QO-BX; Fri, 26 Jan 2007 10:43:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HATEY-0002Pn-PE; Fri, 26 Jan 2007 10:43:22 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HATEW-0005hi-FL; Fri, 26 Jan 2007 10:43:22 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3495917651; Fri, 26 Jan 2007 15:42:50 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HATE1-00069O-QA; Fri, 26 Jan 2007 10:42:49 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 26 Jan 2007 10:42:49 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: hubmib@ietf.org Subject: [Hubmib] Last Call: draft-ietf-hubmib-efm-mib (Definitions and Managed Objects for OAM Functions on Ethernet Like Interfaces) to Proposed Standard X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: hubmib-bounces@ietf.org The IESG has received a request from the Ethernet Interfaces and Hub MIB WG (hubmib) to consider the following document: - 'Definitions and Managed Objects for OAM Functions on Ethernet Like Interfaces ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-mib-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11360&rfc_flag=0 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From zoexgsgzfam@bossig.com Tue Jan 30 00:06:07 2007 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBlC3-0005lB-11 for hubmib-archive@lists.ietf.org; Tue, 30 Jan 2007 00:06:07 -0500 Received: from [211.44.221.41] (helo=[211.44.221.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HBlC1-0005bv-D6 for hubmib-archive@lists.ietf.org; Tue, 30 Jan 2007 00:06:06 -0500 From: "moral authority" To: hubmib-archive@lists.ietf.org Subject: Aggressive Investors Alert Date: Tue, 30 Jan 2007 14:05:56 -0900 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0001_01C74477.C31CCCB0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcdEd8Mcxd1GNMYJSpKoGFjv4CV9+Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-Id: <3515EC58261610E.090893FD67@bossig.com> X-Spam-Score: 3.9 (+++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab ------=_NextPart_000_0001_01C74477.C31CCCB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
PSUD IS ON THE MOVE! GET IN WHILE YOU CAN!

Will this Stock be a "Super Nova?"

The Company: PetroSun
Ticker: PSUD
Current: $0.80 (+0.28 Close) 53.8%
3 Day Target: $2.00

BREAKING NEWS: PetroSun, Incorporated (PNKSHEETS: PSUD) recently announced that they have an agreement executed with New Standard Exploration NL of West Perth, Australia.

Put PSUD on your radar's now. Good luck and trade out at the top!!
------=_NextPart_000_0001_01C74477.C31CCCB0--