RE: EFM Common MIB - issues

Matt,

1) I support the name change from EFM-COMMON-MIB to EFM-OAM-MIB.
The overview section is not worth it. The current name is misleading since
an EPON or EFMCu equipment manufacturer doesn't have to implement this MIB
unless an OAM functionality is supported.

Regards,
-Edward

> -----Original Message-----
> From: Matt Squire [mailto:MSquire <at> HatterasNetworks.com]
> Sent: Friday, February 27, 2004 12:18 AM
> To: hubmib <at> ietf.org
> Cc: Dan Romascanu (Dan) (E-mail)
> Subject: [Hubmib] EFM Common MIB - issues
> 
> 
> 
> Below are some issues I'm running into when working on the 
> next version of the EFM Common MIB.  Would appreciate any feedback.  
> 
> - Matt
> 
> =================
> 
> 1) "Common" vs "OAM".  Right now, we call this MIB the EFM 
> "common" MIB.  The idea, originally, was that this would 
> cover anything common across all EFM PHYs.  Right now, the 
> only thing in this MIB is OAM.  The new copper and EPON work 

EFM-CU-MIB - issues

Hi,

Below are some issues I ran into while working on EFM-CU-MIB. I would
appreciate any feedback.

Regards,
-Edward

Issues list for the EFM-CU-MIB
---------------------------------------------

1. Is current use of ifStackTable for actual cross-connects between
   PMEs and PCSs (read-write) and efmCuAvailableStackTable for cross-connect
   capability (read only), the right choice?

   An alternative would be to use ifStackTable to describe cross-connect
capability
   and efmCuAvailableStackTable to describe actual connections, so that the
cross-connect
   action would be done in the EFM-CU-MIB by modifying the
efmCuAvailableStackTable 
   (and not in IF-MIB).

2. I've decided not to reference HDSL2-SHDSL-LINE-MIB and
   VDSL-LINE-MIB but to define all the relevant objects in this MIB
   (because of the differences between SHDSL/VDSL versions described in
   those MIBs and DSL versions used in EFM, and for the purposes of
   simplicity and name consistency). Again, is it the right choice?

3. Notifications - should we add more and which ones?

RE: More EFM - Clause 30 Management

Hi Mathias,

The latest officially published version is:
http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-cu-mib-00.txt
from Jan 15th. I'm currently working on an update, nothing major yet, so you
can safely use the version above.

noPMEAssigned means that PAF is enabled but Aggregation register is all
zeros (no modems assigned).
Currently there's no limitation in the text that you have to have at least 1
bit set in the Aggregation.
May we should add that in.

noPeerPMEPresent means that there was no answer during handshake
initialization (as far as I understand it). It could also mean that the
modem on the other end physically exists but was excluded from the
aggregation as a result of Discovery (i.e. belongs to a different CPE
already taken by another CO). You are correct that there's no exact
definition in the draft.

I'm personally not concerned very much about Clause 30 as I discovered
during my work on the MIB that it is acceptable to reference Clause 45
registers if there is no substitute in clause 30. As you may notice from the
last published version of the MIB above, I almost exclusively referred to
Clause 45 registers.
However if you take that "optional" nature of Clause 45 to the extreme than
yes, we need all MIB objects reference Clause 30 objects (clause 30 is
mandatory).

I've added David Law, Dan Romascanu and HUBMIB group in Cc: as I find your

Re: RE: More EFM - Clause 30 Management

Hi Ed,

Thanks very much for bringing these comments to my attention - have you
submitted them as comments against Clause 30 or would you like me to do so.

In respect to you other questions, as I'm sure you know, I agree that you have
to reference Clause 45 directly where it is not possible to for you reference
Clause 30. As you correctly state Clause 45 is indeed optional and that is why
when you read Clause 30 you will see that we have text that specifies the
behaviour of the attribute stand alone and then text that say that if a Clause
45 interface is available the attribute maps to some particular register.
Ultimately of course even if a vendor chooses not to implement Clause 45 itself
it is likely that they will instead implement similar register though accessed
by a different mechanism - I think we even recommend that in Clause 45.

The only slight concern I have is this - the Clause 45 registers and the Clause
30 behaviours should match and as they are both under the auspices of the
IEEE-SA balloting we all work to ensure they do by the time the standard is
published. Hence ultimately there should be no difference between referencing
Clause 45 or Clause 30 in the case where a Clause 30 attribute to reference to
exists - so if you are saying there is problem with a Clause 30 attribute
somewhere and are therefore referencing Clause 45 instead you are running the
risk that we change the Clause 45 register to match Clause 30 and pull the rug
from under your Clause 45 reference. Remember that in IEEE 802.3 Clause 30 is
the Management Clause and it might therefore seem a reasonable course of action
to change the optional Clause 45 management register in the case of a difference
between the two. Now to be fair I doubt this would actually happen as we all
continue to work successfully together to make sure it doesn't - this however is
why I express a preference to a Clause 30 reference if possible.

RE: RE: More EFM - Clause 30 Management

David,
I didn't mean to put clause 30 down, in fact it has improved tremendously in
D3.1 and I am planning to change all the appropriate references in the MIB
to clause 30 objects.

While we are at clause 30, there are 2 comments I was about to submit
(I just realized that today is the dead line). I would appreciate your
opinion:

#: 7	Type: TR	Clause: 30	Subclause: 30.2.2.1	Page: 33
Line: 39
Comment:
oTC is described as providing PME Aggregation Function (PAF), while
61.1.4.1.3 states that "The PAF is located in the PCS, between the MAC-PHY
Rate Matching function and the TC sublayer."
Suggested Remedy:
Replace oTC definition with the following:
"oPAF	- The oPAF managed object class provides the management controls
necessary for PME Aggregation Function sublayer to be managed."
Replace "oTC" with "oPAF" in the definition of oPME (page 33, line 7).
Replace "oTC" with "oPAF" in Figure 30-3 and in Table 30-5.

#: 8	Type: TR	Clause: 30	Subclause: 30.2.5	Page: 40
Line: 44
Comment:
PME Aggregation Capability is set as Mandatory. oPME attributes (e.g.
PMESNRMgn) are shown to be a part of PME Aggregation Capability while
clearly they are not and should be a part of 10P/2B capability.
Suggested Remedy:
Add 10P/2B Package (Conditional).

hubmib meeting at ietf 59

RE: hubmib meeting at ietf 59

hubmib minutes

WG:Ethernet Interfaces and Hub MIB WG (hubmib)
Date:Wednesday, March 3 at 0900-1130
CHAIR: Dan Romascanu <dromasca <at> avaya.com>
Reported by: Shailaja


General Comment:

Since next versions of the drafts will be the last call and hence authors 
need to do give special attention to all the aspects of the draft like 
formatting,compilation of the MIB etc.


3. Generic EFM MIB Issues (Dan on behalf of Matt) - 30 minutes

Slide-Common MIB or OAM MIB
There was a discussion about OAM and MIB seem to represent 
the same meaning and hence need to consider removing the word OAM.
Dan to take this matter to the list.


Slide-loopback(I)

More detailed mail sent by Matt Squire to the list. 
It will be included in the next draft, unless there are objections.

Slide -Counters and Discontinuities

Proposal - include the clarification text unless there are objections on the list.

Slide -Event Counter Inconsistency (II)
Proposal - Include read-only objects to reflect the internal counters, 
unless objected on the list.  

Event Controls
Proposal - provide event control mechanism as recommended in the slides, 
unless objected on the list

4. EPON MIB Issues (Lior) 

Accept all editorial comments made by Dan

Settling Time and Lock Time - either do not include at all, 
or include with a conformance clause, so that we do not delay the IEEE process.

Lior to look into Entity Sensor MIB for power and temperature reporting, 
in Entity State MIB for functional status, and in Alarm MIB for alarm status. 

Lior to take it to the WG list discussion about de-asserting mechanism, 
alarm thresholding and the events. Preference to referencing existing IETF MIB

All other resolution - as proposed by Lior on the list, unless there are objections.




5. EFM Cu Issues 


Slide ifstackTable/efmCu MIB

-Leave  it as it is unless it bothers someone in the WG list.

SHDSL/VDSL MIB

Just leave it as it is. 

- Notifications - add if there is a need for EFM Cu specific events. 
Edward will bring this to the list. Some events do not seem Cu specific 
(power loss, device fault) - use Alarm MIB for these

-MAU-MIB

Recommendation to add the sub-layers as distinct sub-types

MAU MIB will be open and re-cycled on Proposed, unless there are objections on the list. 

- TC/PME layer - define new entry if there are objects specific to the new layer

RE: hubmib minutes

Dan,

> Since next versions of the drafts will be the last call ...

Could you please explain the procedure and the time line for the drafts
approval.

I assume all the editors and the chair are going to be present at the EFM
meeting in Kissimmee in a week. I propose we meet to sync. How about
Tuesday, March 23 at 18:00?

Regards,
-Edward

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca <at> avaya.com]
Sent: Thursday, March 04, 2004 04:12 PM
To: proceedings <at> ietf.org
Cc: hubmib <at> ietf.org; Shailaja Yadawad
Subject: [Hubmib] hubmib minutes

Please find attached the minutes of the Ethernet Interfaces and Hub MIB WG
meeting hold at the 59th IETF. Thanks to Shailaja Yadawad for volunteering
to be the minutes taker during the meeting.
Regards,
Dan
<<minutes_hubmib_ietf59.txt>> 

RE: hubmib minutes

> I assume all the editors and the chair are going to be 
> present at the EFM
> meeting in Kissimmee in a week. I propose we meet to sync. How about
> Tuesday, March 23 at 18:00?
> 

We should definitely schedule some time.  If there are no conflicting CFIs, Tues night would work for me.

- Matt