Comments on draft-ietf-hubmib-efm-cu-mib-01.txt
"Romascanu, Dan (Dan)" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F06916051@is0004avexu1.global.avaya.com> |
Technical T1. The language in 3.4 about adding new types of MAUs should be changed to present time. I would like to raise with the WG the issue to make the MAU list a TC maintained by IANA, but this would imply a revision of RFC 3636, and we need a volunteer to do it. T2 - The editor note in 4.1 would suggest some kind of a liaison with IEEE 802.3. I suggest this to be discussed in the meeting. T3 - the way thresholds objects like efmCuThreshLowBandwidth and other are designed, they may become a denial of service tool by simply setting them at the maximal value. This should at least be mentioned in the Security Considerations section T4 - The design of the efmCuPmeDeviceFault is not well explained, or maybe incomplete. What changes in efmCuPmeFltStatus cause sending the notification? Do they include all zero (no fault)? T5 - The design of the efmCuPAFRRemoteDiscoveryCode may be problematic for an SNMP operation. How long it takes for the Discovery Process? When is GetResponse returned on a SetRequest operation? What is returned on A GetRequest operation that arrives in the middle of a Set? Same for DiscoverySet_if_clear. T6. - Why is efmCuAvailableStackTable needed? Cannot ifStackTable be used? Editorial E1. Need to expand MAU in Abstract E2. Need to write 'Ethernet-like' in a consistent manner E3. All over the text replace 'MIB' with 'MIB module' (excepting when referring a specific Management Information Base), and 'MIBs' with 'MIB modules' E4. first paragraph of Section 3 - fix the references E5. Section 3.1 - replace 'in done' with 'is done' E6. Section 3.1.1, third paragraph - SHALL is a key word in this context, should be capitalized E7. Same section - replace 'unassigned' by 'an unassigned' E8. Section 3.1.2 - no need to capitalize MAY here E9 - page 6, last paragraph - should be 'Note that a PCS port...' E10 - Section 3.1.4, second paragraph ' start the initialization process' E11 - Table 1 - '...these are some PCS and PME specific attributes...' E12 - no need to mention RFC sources for IMPORTS. The references may change actually. E13 - the naming conventions in page 13 should be taken out of the DESCRIPTION, maybe made a separate section in the I-D E14 - DESCRIPTION clause of ProfileIndexOrZero - 'The usage for the value of zero' instead of 'The value of zero' E15 - When referring enumerated values or BITS the numerical value should be mentioned explicitly. This shows up in many places, for example in the DESCRIPTION clause of efmCuPAFAdminState, efmCuFltStatus, efmCuPortSide, efmCuPmeAdminSubType, efmCuPmeFltStatus, efmCuPme2BRegion, E16 - In many DESCRIPTION clauses appear phrases like 'Attempts to disable this port should be rejected' without explaining how. You may mean returning an 'inconsistentVallue' error on the SetRequest operation maybe. This needs to be detailed - e.g. for efmCuPAFAdminState, efmCuAdminProfile, efmCuPmeAdminProfile, E17 - DEFVAL missing for many objects with a read-write or read-create MAX-ACCESS. In the absence of DEFVAL, how would an agent initialize the objects before a first configuraton? E.g. efmCuPAFAdminState, efmCuPAFDiscoveryMode, efmCuAdminProfile, efmCuTargetSnrMgn, efmCuLowBandwidthEnable, efmCuPmeAdminSubType, efmCuPmeThreshLineAtn, efmCuPmeThreshSnrMgn, efmCuPmeLineAtnCrossingEnable, efmCuPmeDeviceFaultFaultEnable, efmCuPmeConfigInitEnable, efmCuPmeProtocolInitFailEnable, efmCuPme2BProfileDescr, efmCuPme2BDataRate, efmCuPme2BPower, efmCuPme2BConstellation, efmCuPme10ProfileDescr, efmCuPme10BandNothchProfiles, efmCuPme10PayloadURateProfile, E18 - In many DESCRIPTION clauses the expression 'the link is down' appears. Need to explain what link, how it is reflected in MIB objects value (for example ifOperStatus of the interface with the same ifNumber?)- E.g. efmCuPAFAdminState, efmCuPAFDiscoveryMode, efmCuTargetDataRate, efmCuTargetSnrMgn, efmCuPmeAdminSubType, efmCuPmeThreshLineAtn, efmCuPmeThreshSnrMgn E19 - no need to write commented explanation for BITS, especially as each bit significance is already described in the DESCRIPTION clauses. E.g. efmCuFltStatus, efmCuPortSide, efmCuPmeOperStatus, efmCuPmeFltStatus, efmCuPme2BRegion, efmCuPme10BandNothchProfiles, efmCuPme10PayloadURateProfile, E20 - Missing UNITS clause for counter objects - e.g. efmCuPAFInErrors, etc. Regards, Dan _______________________________________________ Hubmib mailing list [email protected] https://www1.ietf.org/mailman/listinfo/hubmib