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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.