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).
Make aPhyEnd, aPhyCurrentStatus, aPAFSupported, aRemotePAFSupported and all
attributes of oPME to be part of the 10P/2B Package.
Replace "PME Aggregation Capability (Mandatory)" with "PME Aggregation
Package (Optional)". Put the rest of the oPAF (see my comment 7) attributes
there.

Regards,
-Edward

-----Original Message-----
From: David Law
To: Edward Beili
Cc: '[email protected]'; [email protected]; 'Romascanu, Dan (Dan)'
Sent: 03/03/04 20:29
Subject: Re: [Hubmib] 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.

So to summarise untimely what I personally would like to see is the IETF
MIB,
Clause 30 and Clause 45 all to be in harmony. And of course in the case
where
you wish to add additional attributes above and beyond what we have in
Clause 30
all we need to do is ensure the IETF MIB and Clause 45 are in harmony.

Best regards,
  David Law







Edward Beili <[email protected]>@ietf.org on 02/03/2004 19:51:32

Sent by:  [email protected]


To:   "'mathias.riess @infineon.com'" <[email protected]>
cc:   [email protected], "'Romascanu, Dan , David Law/GB/3Com@3Com
Subject:  [Hubmib] 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
comments important.
Hope it's OK with you.

Regards,
-E.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, March 02, 2004 07:52 PM
> To: Edward Beili
> Subject: More EFM - Clause 30 Management
>
>
> Hi Edward,
>    at the end of the last meeting in Vancouver, you sent
> out an updated
> version of the HubMIB, is there already a newer version
> available?? If yes,
> can you share it with us??
>    Additionally I came across some questions, especailly management
> issues when I was reviewing draft 3.0. On clause 30 I have
> the following
> questions:
> Clause 30.12.1.1.3 page 71, line 15: The value 'no PMEAssigned'
>
> Does it mean that the physical layer is not up or does it
> mean that the PME
> Aggregation register has just 1 bit set with the PAF enable
> bit not set (no
> PAF) or does it relate to something else?
>
> Clause 30.12.1.1.3 page 71, line 15: The value 'noPeerPMEPresent''
>
> Again, it is not clear to what condition this releates to, is
> it that the
> physical link is not up, that the remot TC is not
> synchronized or is it
> intended to use some PMD parameter or is it the result of the
> discovery
> phase, saying there is no link to be aggergatable with the
> selected one??
>
> In general I still think there are some Clause 30 parameter
> missing if I
> want to bring up and manage an entire session using Clause
> 30. From my point
> of view i.e.  the entire discovery phase seems to me somehow hidden to
> Clause 30.
> May be I just miss some parts of the entire picture. So my question is
> whether there is kind of an overview/flow chart or something
> similar showing
> how to bringing up/manage an EFM connection using Clause 30.
>
> Thank you for your help!
>
> Regards
> Mathias
>

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





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