Subject: RE: [Hubmib] Re: EFM MIB - Work Plan and Re-charter Proposal

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 1 Sep 2003 09:47:56 +0300

Grant,

Thank you for the message. A few points:

1. As I wrote in my message, I was not aware about cases of simultaneous support of copper and optical in the same 'box'. You gave me an example that such solutions do exist. This being the first input in this direction, I invite other folks who are aware similar cases to provide their inputs, in order to help us understand if this is an exception, or there are more such cases out there. 
2. The IEEE work (Annex 30A and 30B) are our principal model in defining the Ethernet MIB objects. However, the IETF Ethernet MIB is not constrained in following exactly the model and structure defined by IEEE. 
3. Whatever the outcome of the discussion ('one MIB module' vs. 'separate MIB modules'), we are still in waiting for a volunteer to edit the common OAM portion. Up to now Edward Beili volunteered to be editor of he EFM Cu MIB, and Lior Khermosh volunteered for the EPON part. Who will be doing the core EFM OAM side - which is mainly in my view reflecting the common OAM set of objects from IEEE Annex 30? 

So, in order for me as WG Chair to forward the re-charter proposal to the Area Director for approval we need:
a. a name the common EFM OAM MIB editor
b. some more comments - approval or disapproval - on the Charter proposal that I posted a couple of weeks ago. Even a short note 'yes, I like it' would be enough. 

Thanks, 

Dan

> -----Original Message-----
> From: Grant Schnebly [mailto:[email-masked]]
> Sent: 30 August, 2003 1:16 AM
> To: [email-masked]'
> Subject: [Hubmib] Re: EFM MIB - Work Plan and Re-charter Proposal
> 
> 
>  > 3. We had some discussions, but did not decide yet whether 
> we want to do
>  > one MIB module or separate modules. The charter proposal 
> below mentions
>  > separate modules, the main reason being that I  do not see too many
>  > cases (if at all) in which simultaneous support of copper 
> and optical is
>  > required. Please comment.
> 
> MRV plans a line of products which will simultaneously 
> support both copper
> and fiber ports on the same managed device.  
> 
> A single MIB supporting any transmission medium seems 
> straightforward to me.
> This appears to be what IEEE is doing in Annex 30A and 30B.  If I'm
> overlooking something, please let me know.
> 
> -Grant
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 21, 2003 9:00 AM
> To: [email-masked]
> Subject: Hubmib digest, Vol 1 #216 - 3 msgs
> 
> 
> Send Hubmib mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/hubmib
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Hubmib digest..."
> 
> 
> Today's Topics:
> 
>    1. EFM MIB - Work Plan and Re-charter Proposal (Romascanu, 
> Dan (Dan))
>    2. FW: evaluation: draft-ietf-hubmib-power-ethernet-mib 
> (Wijnen, Bert
> (Bert))
>    3. RE: FW: evaluation: 
> draft-ietf-hubmib-power-ethernet-mib (Romascanu,
> Dan (Dan))
> 
> --__--__--
> 
> Message: 1
> Date: Thu, 21 Aug 2003 11:53:11 +0300
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: <[email-masked]>
> Subject: [Hubmib] EFM MIB - Work Plan and Re-charter Proposal
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C367C1.A6925C97
> Content-Type: text/plain;
> 	charset="windows-1255"
> Content-Transfer-Encoding: quoted-printable
> 
> Let me try to summarize where we are with the discussions 
> concerning the =
> new EFM MIB work.=20
> 
> 1. I suggest that all discussions will happen on 
> [email-masked]. I sent =
> a message on this respect to the IEEE 802.3ah reflector.=20
> 
> 2. My call for participation in this work received a very 
> good answer - =
> 15 individuals representing 11 different companies volunteered to =
> particpate in the work. At this point in time we need 
> specific names for =
> editors. Lior Khermosh graciously volunteered to be the 
> editor for the =
> EPON MIB (or EPON section of the EFM MIB, if we decide to go 
> this way). =
> I need names for editors of the generic EFM MIB and the copper MIB.=20
> 
> 3. We had some discussions, but did not decide yet whether we 
> want to do =
> one MIB module or separate modules. The charter proposal 
> below mentions =
> separate modules, the main reason being that I  do not see too many =
> cases (if at all) in which simultaneous support of copper and 
> optical is =
> required. Please comment.=20
> 
> 4. Here is a proposal for wording of an Charter Update. This 
> is the time =
> to send feedback, proposal change, or just a short message 
> that you are =
> OK with this wording.=20
> 
> ----------------------------------------------------
> 
> 'The working group will work on the following MIB modules for 
> the IEEE =
> 802.3ah (Ethernet First Mile) interfaces and devices:
> 
> - Ethernet First Mile (EFM) MIB - common attributes, OAM 
> operations and =
> statistics
> - Copper EFM MIB
> - Ethernet Passive Optical Networks (EPON) MIB
> 
> The base for the definition of the managed objects in these 
> MIB modules =
> will be the management-related clauses in IEEE 802.3ah 
> specification. =
> The working group will also take into consideration 
> management objects =
> defined by other Working Groups in the IETF (ADSL MIB for 
> example), or =
> other standard bodies (G.983.2), will avoid work duplication, and =
> describe the relationship with these specifications.
> 
> Schedules
> 
> October 2003 - Individual submissions for the EFM MIB modules
> December 2003 - First round of WG Internet-Drafts for the EFM MIB =
> modules
> April 2004 - Working Group Last Call
> June 2004 - Submit the Internet- Drafts to the IESG for 
> consideration as =
> Proposed Standards'
> 
> Please comment!
> 
> Dan
> =20
> 
> =20
> 
> ------_=_NextPart_001_01C367C1.A6925C97
> Content-Type: text/html;
> 	charset="windows-1255"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dwindows-1255">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 6.0.6388.0">
> <TITLE>EFM MIB - Work Plan and Re-charter Proposal</TITLE>
> </HEAD>
> <BODY>
> <!-- Converted from text/rtf format -->
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Let me try to 
> summarize where =
> we are with the discussions concerning the new EFM MIB work. 
> </FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">1. I suggest that all =
> discussions will happen on [email-masked]. I sent a message on this =
> respect to the IEEE 802.3ah reflector. </FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">2. My call for 
> participation =
> in this work received a very good answer - 15 individuals 
> representing =
> 11 different companies volunteered to particpate in the work. 
> At this =
> point in time we need specific names for editors. Lior Khermosh =
> graciously volunteered to be the editor for the EPON MIB (or EPON =
> section of the EFM MIB, if we decide to go this way). I need 
> names for =
> editors of the generic EFM MIB and the copper MIB. </FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">3. We had some 
> discussions, =
> but did not decide yet whether we want to do one MIB module 
> or separate =
> modules. The charter proposal below mentions separate 
> modules, the main =
> reason being that I&nbsp; do not see too many cases (if at 
> all) in which =
> simultaneous support of copper and optical is required. 
> Please comment. =
> </FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">4. Here is a proposal for =
> wording of an Charter Update. This is the time to send feedback, =
> proposal change, or just a short message that you are OK with this =
> wording. </FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 =
> FACE=3D"Arial">-----------------------------------------------
> -----</FONT=
> ></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">'The working group 
> will work =
> on the following MIB modules for the IEEE 802.3ah (Ethernet 
> First Mile) =
> interfaces and devices:</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">- Ethernet First 
> Mile (EFM) =
> MIB - common attributes, OAM operations and statistics</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">- Copper EFM MIB</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">- Ethernet Passive 
> Optical =
> Networks (EPON) MIB</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">The base for the 
> definition =
> of the managed objects in these MIB modules will be the =
> management-related clauses in IEEE 802.3ah specification. The 
> working =
> group will also take into consideration management objects 
> defined by =
> other Working Groups in the IETF (ADSL MIB for example), or other =
> standard bodies (G.983.2), will avoid work duplication, and 
> describe the =
> relationship with these specifications.</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Schedules</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">October 2003 - Individual =
> submissions for the EFM MIB modules</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">December 2003 - 
> First round =
> of WG Internet-Drafts for the EFM MIB modules</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">April 2004 - 
> Working Group =
> Last Call</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">June 2004 - Submit the =
> Internet- Drafts to the IESG for consideration as Proposed =
> Standards'</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Please comment!</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">Dan</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT></P>
> 
> <P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;</FONT></P>
> 
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C367C1.A6925C97--
> 
> 
> --__--__--
> 
> Message: 2
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Hubmib Mailing List (E-mail)" <[email-masked]>
> Cc: "Ted Hardie (E-mail)" <[email-masked]>
> Date: Thu, 21 Aug 2003 11:34:07 +0200
> Subject: [Hubmib] FW: evaluation: draft-ietf-hubmib-power-ethernet-mib
> 
> I am going to assume that the hubmib WG will agree if I
> make the editorial changes/fixes (fixing typos) in the
> form of an RFC-Editor note.
> If anyone objects, pls let me know asap!
> 
> Thanks,
> Bert 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: woensdag 20 augustus 2003 1:29
> To: [email-masked]; [email-masked]
> Subject: evaluation: draft-ietf-hubmib-power-ethernet-mib
> 
> Notes:
> 
>      pethPsePortTable OBJECT-TYPE
>            SYNTAX      SEQUENCE OF PethPsePortEntry
>            MAX-ACCESS  not-accessible
>            STATUS      current
>            DESCRIPTION
>                "A table of objects that display and control the power
>                 characteristics power Ethernet ports on a Power Source
> 
> --->missing "of" in "characteristics of power Ethernet ports"?
> 
> 
>          pethPsePortPowerPairsControlAbility OBJECT-TYPE
>         SYNTAX TruthValue
>         MAX-ACCESS read-only
>         STATUS current
>         DESCRIPTION
>              "Describes the capability of controlling the power pairs
>              functionality to switch pins for sourcing power.
>              The value true indicate that the device has the 
> capability
>              to control the power pairs. When false the PSE Pinout
>              Alternative used cannot be controlled through the
>              PethPsePortAdminEnabe attribute."
> 
> --->should be PethPsePortAdminEnable?
> 
>         pethPsePortPowerPairs OBJECT-TYPE
>         SYNTAX INTEGER   {
>                    signal(1),
>                    spare(2)
>          }
>         MAX-ACCESS read-write
>         STATUS current
>         DESCRIPTION
>             "Describes or controls the pairs in use. If the value of
>              pethPsePortPowerPairsControl is true, this object is
>              writable.
>              A value of signal(1) menas that the signal pairs
> 
> --->menas should be means?
> 
> 
> --__--__--
> 
> Message: 3
> Subject: RE: [Hubmib] FW: evaluation: 
> draft-ietf-hubmib-power-ethernet-mib
> Date: Thu, 21 Aug 2003 16:25:42 +0300
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Wijnen, Bert (Bert)" <[email-masked]>,
>         "Hubmib Mailing List (E-mail)" <[email-masked]>
> Cc: "Ted Hardie (E-mail)" <[email-masked]>
> 
> All edits are OK with me. Thanks for catching them. Dan
> 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: 21 August, 2003 12:34 PM
> > To: Hubmib Mailing List (E-mail)
> > Cc: Ted Hardie (E-mail)
> > Subject: [Hubmib] FW: evaluation: 
> draft-ietf-hubmib-power-ethernet-mib
> >=20
> >=20
> > I am going to assume that the hubmib WG will agree if I
> > make the editorial changes/fixes (fixing typos) in the
> > form of an RFC-Editor note.
> > If anyone objects, pls let me know asap!
> >=20
> > Thanks,
> > Bert=20
> >=20
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: woensdag 20 augustus 2003 1:29
> > To: [email-masked]; [email-masked]
> > Subject: evaluation: draft-ietf-hubmib-power-ethernet-mib
> >=20
> > Notes:
> >=20
> >      pethPsePortTable OBJECT-TYPE
> >            SYNTAX      SEQUENCE OF PethPsePortEntry
> >            MAX-ACCESS  not-accessible
> >            STATUS      current
> >            DESCRIPTION
> >                "A table of objects that display and control 
> the power
> >                 characteristics power Ethernet ports on a 
> Power Source
> >=20
> > --->missing "of" in "characteristics of power Ethernet ports"?
> >=20
> >=20
> >          pethPsePortPowerPairsControlAbility OBJECT-TYPE
> >         SYNTAX TruthValue
> >         MAX-ACCESS read-only
> >         STATUS current
> >         DESCRIPTION
> >              "Describes the capability of controlling the 
> power pairs
> >              functionality to switch pins for sourcing power.
> >              The value true indicate that the device has the=20
> > capability
> >              to control the power pairs. When false the PSE Pinout
> >              Alternative used cannot be controlled through the
> >              PethPsePortAdminEnabe attribute."
> >=20
> > --->should be PethPsePortAdminEnable?
> >=20
> >         pethPsePortPowerPairs OBJECT-TYPE
> >         SYNTAX INTEGER   {
> >                    signal(1),
> >                    spare(2)
> >          }
> >         MAX-ACCESS read-write
> >         STATUS current
> >         DESCRIPTION
> >             "Describes or controls the pairs in use. If the value of
> >              pethPsePortPowerPairsControl is true, this object is
> >              writable.
> >              A value of signal(1) menas that the signal pairs
> >=20
> > --->menas should be means?
> >=20
> > _______________________________________________
> > Hubmib mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/hubmib
> >=20
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Hubmib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hubmib
> 
> 
> End of Hubmib Digest
> 
> _______________________________________________
> Hubmib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hubmib
> 

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

---

From: John Messenger <[email-masked]>
Date: Tue, 2 Sep 2003 11:57:50 +0200

Dan,

I'm happy with your charter and timescales.  If separate PHY-specific parts
are used, I suggest separating the core EFM objects from any PHY-specific
objects.  But I have no opinion on separating or combining the PHY-specific
parts.

Thanks,
	-- John

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: 01 September 2003 07:48
To: Grant Schnebly; [email-masked]
Subject: RE: [Hubmib] Re: EFM MIB - Work Plan and Re-charter Proposal

Grant,

1. As I wrote in my message, I was not aware about cases of simultaneous
support of copper and optical in the same 'box'. You gave me an example that
such solutions do exist. This being the first input in this direction, I
invite other folks who are aware similar cases to provide their inputs, in
order to help us understand if this is an exception, or there are more such
cases out there. 
2. The IEEE work (Annex 30A and 30B) are our principal model in defining the
Ethernet MIB objects. However, the IETF Ethernet MIB is not constrained in
following exactly the model and structure defined by IEEE. 
3. Whatever the outcome of the discussion ('one MIB module' vs. 'separate
MIB modules'), we are still in waiting for a volunteer to edit the common
OAM portion. Up to now Edward Beili volunteered to be editor of he EFM Cu
MIB, and Lior Khermosh volunteered for the EPON part. Who will be doing the
core EFM OAM side - which is mainly in my view reflecting the common OAM set
of objects from IEEE Annex 30? 

So, in order for me as WG Chair to forward the re-charter proposal to the
Area Director for approval we need:
a. a name the common EFM OAM MIB editor
b. some more comments - approval or disapproval - on the Charter proposal
that I posted a couple of weeks ago. Even a short note 'yes, I like it'
would be enough. 

Thanks, 

Dan

---

From: John Messenger <[email-masked]>
Date: Tue, 2 Sep 2003 11:57:50 +0200

Dan,

Thanks,
	-- John

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: 01 September 2003 07:48
To: Grant Schnebly; [email-masked]
Subject: RE: [Hubmib] Re: EFM MIB - Work Plan and Re-charter Proposal

Grant,

Thanks, 

Dan