RE: RE: [Fwd: RE: comments ondraft-ietf-hubmib-efm-cu-mib-02.txt]

Ed, 
 
At this phase you need to provide proposals for comments resolution, which does not mean that you need to agree with all the comments. Please provide clear proposals for P17, P29 and P39 below, and let people reply if they are not content with the proposed resolution. 
 

Thanks and Regards,

Dan

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Edward Beili
Sent: 03 March, 2005 2:01 AM
To: Matt Squire
Cc: [email protected]
Subject: [Hubmib] RE: [Fwd: RE: comments ondraft-ietf-hubmib-efm-cu-mib-02.txt]



Hi Matt,
Sorry it took so long to answer. I've indicated the open issues by >>EdNote:
I'd appreciate if you could take a look.
Regards,
-Edward

>From: Matt Squire [[email protected]] Sent: Fri 12/3/2004 7:53 AM
>To: Edward Beili
>Cc: [email protected]
>Subject: comments on draft-ietf-hubmib-efm-cu-mib-02.txt
>
>Hi Ed -
>
>Had some old and new comments on the EFM CU MIB draft. 
>
>First, some old ones.  I submitted these against the -01 version and
>am not sure what decision was made with respect to them and why.  They
>don't look to be addressed in the new draft but I might have missed
>something.  A couple were discussed at the August(?) meeting and were
>supposed to go to the list, but nothing was ever discussed on the
>list.
>
>
>- Matt
>
><start old comments>
>
>P17, efmCuPAFDiscoveryCode.  Why is this read-write?  Seems like this
>should be generated by the system rather than provisioned by
>management.  E.g. the system can select a unique code based on MAC
>addresses, OUIs, etc.  Setting this via management seems more
>problematic than beneficial.  Its probably nice as read-only for
>troubleshooting reasons, but I don't get the r/w.

[EB] Your arguments are valid and initially I made this object
read-only. However the standard does not specify how the discovery
code is selected or which body would govern the code assignment. So it
is possible that two -O ports from different manufacturers would have
the same discovery code, thus I left the write capability to deal with
such cases. As an alternative we could choose a specific selection
method (say the MAC address of the port), specify it in the MIB and
make the efmCuPAFDiscoveryCode read-only.

>P17, efmCuAdminProfile. Why do we say "current operating Subtype of
>the PCS" instead of just "the subtype of the PCS"?.  Can that subtype
>change?  Also, given we're having profiles on the EFMCu and PME level,
>would it be better to have the PME level override the EFMCu level?  If
>we switched precedence order (PME wins over EFMCu), we don't lose any
>management function, but we allow the manager to set a default for all
>PMEs with the ability to override speicfic PMEs with something else.
>So we get more function, and don't lose anything.

[EB] The subtype of the PCS can not be changed by an admin command. It
reflects the common subtype of the connected PMEs. The system vendor
may decide to fix the PMEs subtype (this would be indicated by the
single value of efmCuPmeSubTypesSupported and obviously the resulting
system can only be a CO or a CPE) or make it manageable, in which case
the administrator would change the PMEs subtype to make the resulting
aggregated port to be of a specific subtype.

As for the precedence order between PME and PCS, I would leave
the PCS winning over the PMEs. Usually the user would want the
same profile on all PMEs, mostly due to the spectral restrictions that
all PMEs must obey. The administrator can still set the PMEs
individually by setting the value of efmCuAdminProfile to empty list,
so there's no functionality loss. When there is a need to change the
profile of the aggregated link it is easier to change just one
parameter (efmCuAdminProfile) and not to worry about checking (and
possibly re-writing) the individual efmCuPmeAdminProfile values for
each PME in the link.

>P8, 3.1.5.  On ifAdminStatus for the PAF, we say setting it to "up"
>re-initializes all PMEs associated with it.  Does setting the
>ifAdminStatus of the PCS to "down" take down all PMEs as well, or
>does it just stop aggregation from occurring?  Does the ifAdminStatus
>of the PMEs automatically change with that of the EFMCu port?
>There's still some more clarity needed here.  I guess I don't really
>care which way it ends up, but we need to say one way or the other.

[EB] Good point. I suggest the following clarification:

Changing the ifAdminStatus for a PCS from "down" to "up" initializes the PCS
and all PMEs connected to it, unconditionally setting the value of
ifAdminStatus of all connected PMEs to "up".

Changing the ifAdminStatus for a PCS from "up" to "down" shuts down
the PCS and all subtending PMEs, unconditionally setting the value of
ifAdminStatus of all connected PMEs to "down".

Changing the ifAdminStatus for a PME from "down" to "up" initializes
the PME regardless the value of ifAdminStatus for the PCS connected to
that PME. Note that EFMCu PME initialization is a lengthy process
which may succeed or fail (e.g. if initialization parameters cannot be
achieved due to the copper characteristics). The ifOperStatus for the
PME SHALL remain "down" for the duration of initialization.
>> EdNote: anoter alternative is to make ifOperStatus to be "dormant"
during initialization, however the definition of "dormant" in the
IF-MIB is "waiting for an external action" and initialization is
really a self-sufficient process which doesn't require any external
action for completion. <<
At the end of a successful initialization, the ifOperStatus SHALL
change to "up". It SHALL remain "down" if the initialization fails. The
efmCuPmeOperStatus provides additional information on the operational
status of the PME, indicating if the PME is down and there is no
handshake tones ("downNotReady"), the PME is down and the handshake
tones are detected ("downReady"), the PME is initializing ("init") and
the PME is ready to pass operational traffic ("up").
Note that no operational traffic can pass via the PME if the
aggregating PCS is administratively "down".

Changing the ifAdminStatus for a PME from "up" to "down" shuts down
the PME link, regardless the value of ifAdminStatus for the PCS
connected to that PME. The ifOperStatus for the PME SHALL change to
"down", with efmCuPmeOperStatus indicating "downReady" or
"downNotReady" depending on the handshake detection form the peer PME.

>P21, efmCuPeerPAFSupported.  Seems like it might be worthwhile to have
>a third value (unknown) given thats whats in 30.11.1.1.9.  Makes the
>mapping easier:)

[EB] I wanted it to resemble the boolean syntax of efmCuPAFSupported,
also Clause 45 Remote PAF Supported bit has only 2 values. Supporting the
unknown value would require some intelligence from the SNMP agent.
>> EdNote: I'd like to get more opinions here <<

>P29, PME Notifications.  Many of the notifications (DeviceFault,
>ConfigInitFailure, ProtocolInitFailure) seem like they could be
>handled by one notification- e.g. there was a failure and a reason
>for the failure.  You're including the FltStatus anyway - do we need
>multiple notifications?  I know in some you include more info (for
>example, the profile index), but does getting an integer index into
>a profile table help the notification receiver to know what
>happened?  Also, are there any rules/guidelines on using these with
>the standard linkDown ifTable notification?  Can/should someone send
>both, one or the other, does it matter, etc.?

[EB] I've copied most of the notifications from the SHDSL
MIB. I guess I could group together ConfigInitFailure and
ProtocolInitFailure, since they both happen during initialization
phase, DeviceFault is a bit different as it can happen anytime
(e.g. as a result of a periodic test). On the other hand IF-MIB put 2
different traps for linkUp and linkDown events (these could certainly
be served by the same notification), so I'm not sure what is the rules
here.
>> EdNote: I'd like to get more opinions here <<

As for the concurrent linkUp/linkDown notifications - most of the
notifications defined in the MIB are independent from those link
notifications, i.e. ConfigInitFailure and ProtocolInitFailure happen
during initialization when link continues to be down, DeviceFault if
happened during normal work would probably be preceded by linkDown,
LineAtnCrossing and SnrMgnCrossing would not cause any linkDown events
by themselves, efmCuLowBandwidth would probably be preceded by a linkDown in
one or more PMEs, so once again - they are independent and I'm not
sure this fact should be explicitly stated in the MIB.

>P39, efmCuPmeFltStatus.  Should this be zero'd when the link is up or
>initializing (there's no current faults in these oper states).  Or is
>this intended to hold the last fault?

[EB] You are right, it is not clear. My intention was as follows:
 - All indications hold the last fault
 - lossOfFraming, configInitFailure, protocolInitFailure - cleared by the PME init & device restart.
 - deviceFault - cleared by successful diagnostics/test & device restart
 - snrMgnDefect, lineAtnDefect - cleared by snrMgn/lineAtn returning
 to norm (above threshold), PME init, device restart
>> EdNote: Should it all be also cleared by setting the PME
administratively Down? <<

>P44, EfmCu2BConfProfileEntry.  The definitions here allow a
>completely rate adaptive profile (set data rate to 0), but not a
>restricted data rate profile (e.g. between 2 and 4 Mbps).  Supporting
>min/max rates would be good.

[EB] efmCuAdminProfile is a list of up to 6 pointers to profile entries, which
allows you to specify up to 6 different possible rates.
Current clause 45 registers do not allow specification of a restricted
data profile, that is why I didn't do it. Besides EFM puts a
limitation of 1:4 ratio between the fastest and the slowest PME in the
aggregation group, so you would always have a min rate in the rate
adaptive profile, based on the highest attainable rate, which is in
turn limited by the region, power and constellation.
In general I tried not to put in the MIB anything that could not be
supported by clause 45 registers or clause 30 objects.

>/end old comments>

>Now for some new comments.

>General.  There's a ton of Editors notes scattered throughout
>indicating that certain parts aren't finished.  I guess the draft
>isn't really ready for last call?

[EB] All editorial notes would be removed or turned into meaningful
text in the next draft.

>General.  Should reference final EFM doc not D3.3. 

[EB] Corrected.

>P4, 3.1.1.  What is the "configured bit-rate for a pre-activated
>modem"?  What is the ifSpeed of a PME when it is in a rate adaptive
>mode? 

[EB] What I had in mind was to show max data rate specified by the
profile as ifSpeed for a PME during initialization. I now think it is
better to return 0 during initialization or when the link is down.

>P4, 3.1.1.  There are a couple definitions of the ifSpeed of the PCS
> a) ifSpeed is "rate across the MII" (in 3.1.5)
> b) ifSpeed is "sum of the current operating data rates of all modems
>in the aggregation group without the 64/65B encapsulation overhead
>and PAF overhead but accounting for the interframe gap"
>
>I'd prefer we just go with the first one consistently.  If you want
>to state somewhere what goes across the MII, thats fine, but it seems
>like there are two definitions laying out there.

[EB] I view both definitions a) and b) as equivalent. I agree that
since there is no clear formula defined it is hard to compute the
ifSpeed value (it would depend on the frame size, IFG, fragment size
etc.).
In the end I guess the equipment would report some empirical function of
the PMEs rates (say 95% of the sum of the rates), as long as there is
no frame loss in the configuration with the test sets.

>P4, 3.1.1.  On the examples ("the following configuration shall have
>no frame loss..."), it would seem preferable to eliminate the "shall"
>as we're not really dicating anything.  Maybe more along the lines
>of: "When using the stated definition of ifSpeed for the PCS, there
>would be no packet loss in the following configurations..."

[EB] Agreed. Corrected.

>P29-30, Notifications.  Some of the defined notifications are events,
>others are threshold crossing.  For the threshold crossing, is the
>notification to be generated when the threshold is crossed in each
>direction, only when its exceeded, etc.?  E.g. there are
>linkUp/linkDown notifications defined in other MIBs for when things
>go up and down, its not clear if the threshold notifications should
>be sent on clear as well.  I think they should be, but the text
>doesn't really indicate one way or another.

[EB] Actually I just copied it from the SHDSL MIB:).
My understanding of the current text (as well as the one in SHDSL and
VDSL MIBs) is that the notification is not sent on clear, but
only when the threshold is exceeded. However it does make sense to
provide a notification on clear as well, so I've changed the text accordingly.

>P42, status table. In the efmCuPmeStatusTable, it's not clear what
>should be returned for some of the objects when the link is down or
>initializing.  Some of the objects have text (efmCuPmeOperProfile)
>while others don't (efmCuPmeSnrMargin, etc.).  Should probably
>consistently say what to return when the PME is down.

[EB] You are right. I suggest adding an additional out of range
value of 65535 (similar to efmCuPme10PElectricalLength, meaning that
the data is unavailable) for efmCuPmeSnrMargin,
efmCuPmePeerSnrMargin, efmCuPmeSnrMargin, efmCuPmePeerSnrMargin when
the PME is down or initializing and the value of 0 for
efmCuPmeTCCodingErrors when the PME is down or initializing.

>Editorial
>
>P10 3.4:  "most of the MAU characteristics is not" => "are not"

[EB] Corrected.

>P38 efmCuPmeStatsuTable - description indicates its the configuration
>not the status (cut & paste error)

[EB] Corrected.

>P44, efmCuPme2BConfProfileEntry (ditto for the 10P version) -
>Another cut&paste error?  Reads like the profile entry for the PCS
>not the PME.

[EB] This one is correct. The efmCuPme2BConfProfileEntry can be
referenced by efmCuAdminProfile (per PCS) and/or efmCuPmeAdminProfile (per
PME). When PCS port is initialized and its efmCuAdminProfile is not
zero, referencing a specific efmCuPme2BConfProfileEntry or
efmCuPme10PConfProfileEntry, all PMEs connected to that PCS are
initialized using that particular profile. If the efmCuAdminProfile
is zero then each PME connected to that PCS is initialized according
to the profile referenced by the efmCuPmeAdminProfile.
When a PME is initialized and the efmCuAdminProfile of the connected
PCS is not zero, the PME is initialized according to the profile
referenced by the efmCuAdminProfile (which takes precedence over
efmCuPmeAdminProfile). If the efmCuAdminProfile iz zero the
initialization is done using the profile referenced by the
efmCuPmeAdminProfile.

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