Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 10:58:54 +0200

As you have seen in the announcements that went out in the last couple of days, the three individual submission Internet-Drafts including the initial submissions for the EFM MIBs are now available. The relevant URLs are:

*	http://www.ietf.org/internet-drafts/draft-squire-hubmib-efm-mib-00.txt
*	http://www.ietf.org/internet-drafts/draft-beili-hubmib-efm-cu-mib-00.txt
*	http://www.ietf.org/internet-drafts/draft-khermosh-hubmib-epon-mib-00.txt

First, I would like to thank the editors of the three documents - Matt, Edward, and Lior for the effort, and for meeting the submission deadline. With this we have already accomplished in time the first item in our new charter! 

Second, I would strongly suggest that you read the proposals and send your comments. The final work can happen only with your support and contribution, and will be as good as we all make it. Take into account that these are only initial proposals, and there is a long way to go. All comments need to be sent to the WG list, at [email-masked]. 

Third, if there are other contributions, let me know, and prepare them in Internet-Draft format. Our next milestone is issuing the first round of WG Internet-Drafts in December - we need to know if the three drafts already published are the only contributions, or there will be other I-Ds to be considered. 

Now about WG meetings. The Ethernet Interfaces and Hub MIB WG will not meet during the November IETF meeting, because of the conflict between the IETF meeting and the IEEE Plenary that are scheduled for the same week. Personally I think that we do need face-to-face meetings, although much of the work can be done on the mailing list. The next two opportunities for face to face meetings seem to be:

- an interim meeting in Vancouver, BC in January (I do not know the exact week) co-located with the IEEE 802.3 Interim meeting 
- meeting at the IETF meeting in Seoul, Korea (2/29-3/5)

Everybody who thinks that they can/will attend one or both of the meetings - please send me an e-mail - we need a headcount before making a decision and engaging in any logistics. 

If we decide for an Interim, we need to have it approved by the IETF Area Director, and we might need a sponsor for the room meeting space in Vancouver (maybe IEEE 802.3ah can help?).

Thanks and Regards,

Dan

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 23 Oct 2003 10:01:04 -0400

Just speaking for the draft I submitted, it is a very early draft that still has a lot of holes.  All input is very appreciated.  
 
In particular, one big nagging question is how these new MIBs are organized within the existing MIB heirarchy.  For the common stuff, does it get a new mib-2 branch, or do we somehow hang it under the dot3 branch as something under the Ethernet tree?  
 
Hoping some of you MIB experts can lend some guidance.  

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 4:59 AM
To: [email-masked]
Cc: [email-masked]; Bert Wijnen (E-mail)
Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings

Thanks and Regards,

Dan

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 23 Oct 2003 10:01:04 -0400

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Thursday, October 23, 2003 4:59 AM
To: [email-masked]
Cc: [email-masked]; Bert Wijnen (E-mail)
Subject: [Hubmib] EFM MIB Internet-Drafts, WG Meetings

Thanks and Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 17:02:09 +0200

The later Ethernet MIB module that went under review got the following structure, as result of the MIB Doctor comments:
 
powerEthernetMIB MODULE-IDENTITY
          ::= { mib-2 XXX }
   -- RFC Ed.: replace XXX with IANA-assigned number & remove this notice

   pethNotifications OBJECT IDENTIFIER ::= { powerEthernetMIB 0 }
   pethObjects       OBJECT IDENTIFIER ::= { powerEthernetMIB 1 }
   pethConformance   OBJECT IDENTIFIER ::= { powerEthernetMIB 2 }
 
Accordingly, I would say that we need to plan for our three MIB modules to be placed under MIB-II, and probably separatily, do that dependencies are reduced to the possible extent. 
 
Rergards,
 
Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 17:02:09 +0200

Rergards,
 
Dan

---

From: John Messenger <[email-masked]>
Date: Thu, 23 Oct 2003 19:01:35 +0200

Hi Matt,
 
Thanks very much for your EFM MIB proposal.  I have a few comments,
editorial and technical.
 
You use both "Ethernet like" and "Ethernet-like" - I think the latter is
better.
 
dot3OamUnidirectionalSupport: could you give an example of when it might be
good to be able to write this?  Seems to me perhaps better as read-only.
 
dot3OamParserState: in the Description there is a cut-and-paste error: it
says "multiplexor" but should say "parser".
 
dot3OamPeerEntry: somehow the Description needs to mention that the
information relates to the Peer.
 
dot3OamPeerVendorInfo: Error in 802.3ah! (30.11.1.1.12 D2.1 refers to table
57-10, but should refer to table 57-11).
 
What about traps?  Is it usual to define a set of traps, which in this case
might correspond with the OAM Events, and traps based on the important bits
in the OAM Flags field (critical event, dying gasp, link fault).
 
You have included a commented-out block of config variables for the
parameters associated with error reporting.  If we have OAM Event traps,
then we may need these config variables, otherwise probably not I feel.
 
Regards,
    -- John
John Messenger ([email-masked]) 
R&D Manager, Software 
ADVA Optical Networking Ltd. 
+44-1904-699309 
www.advaoptical.com 

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: 23 October 2003 15:01
To: Romascanu, Dan (Dan); [email-masked]
Cc: [email-masked]
Subject: [EFM] RE: [Hubmib] EFM MIB Internet-Drafts, WG Meetings

Just speaking for the draft I submitted, it is a very early draft that still
has a lot of holes.  All input is very appreciated.  
 
In particular, one big nagging question is how these new MIBs are organized
within the existing MIB heirarchy.  For the common stuff, does it get a new
mib-2 branch, or do we somehow hang it under the dot3 branch as something
under the Ethernet tree?

---

From: John Messenger <[email-masked]>
Date: Thu, 23 Oct 2003 19:01:35 +0200

Hi Matt,

 

 

 
Regards,
    -- John

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 27 Oct 2003 10:13:08 -0500

> Thanks very much for your EFM MIB proposal.  I have a few comments, editorial and technical.

Thanks a bunch.  

> You use both "Ethernet like" and "Ethernet-like" - I think the latter is better.

Can do.

> dot3OamUnidirectionalSupport: could you give an example of when it might be good to be able to write this?  Seems to me perhaps better as read-only.

Probably right. I couldn't justify it when I wrote it.  

> dot3OamParserState: in the Description there is a cut-and-paste error: it says "multiplexor" but should say "parser".

Will fix. 

> dot3OamPeerEntry: somehow the Description needs to mention that the information relates to the Peer.

Can do.

> dot3OamPeerVendorInfo: Error in 802.3ah! (30.11.1.1.12 D2.1 refers to table 57-10, but should refer to table 57-11).

There's a comment cycle open, so hopefully one of us can log this.

> What about traps?  Is it usual to define a set of traps, which in this case might correspond with the OAM Events, and traps based on the important bits in the OAM Flags field (critical event, dying gasp, link fault).

Yea, I wasnt sure at the time what to do with events (which is why I skipped that part the first go-round).  My expectation is that there will be a set of traps defined for the events.  It just gets tricky when you have non-standard events happening.  I assume I'll end up defining a "organization specific trap" for each of the organization specific event. 

>  You have included a commented-out block of config variables for the parameters associated with error reporting.  If we have OAM Event traps, then we may need these config variables, otherwise probably not I feel.

Agreed.  Since I didn't fill in the event part, I felt it was premature to include the other part.  But I also didn't want to delete and forget it.  So its there commented out.  But it will (hopefully) be consistent and uncommented in the next revision.  

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 27 Oct 2003 10:13:08 -0500

Thanks a bunch.  

Can do.

Will fix. 

Can do.