Re: [Adslmib] [MIB-DOCTORS] AD review of draft-ietf-adslmib-vdsl2-06.txt

["Romascanu, Dan (Dan)" <dromasca at avaya.com>]

There are some more comments from David Harrington listed below. 

Please address them in the new version of the MIB module and of the
document. 

1) as per RFC4181 the TruthValue TC SHOULD be used in the SYNTAX clause
of object definitions
    that require a Boolean type.  MIB modules SHOULD NOT use enumerated
    INTEGER types or define TCs that duplicate its semantics.

2) the MIB organization does not follow the RECOMMENDED OID assignment
scheme for notifications as per section 4.7 and Appendix D of RFC 4181

3) Xdsl2LineEntry  ::=
   SEQUENCE {
      xdsl2LineCnfgTemplate            SnmpAdminString,
      xdsl2LineCnfgFallbackTemplate    SnmpAdminString,
      xdsl2LineAlarmCnfgTemplate       SnmpAdminString,
      xdsl2LineCmndConfPmsf            Xdsl2ConfPmsForce,
      xdsl2LineCmndConfLdsf            Xdsl2LineLdsf,
      xdsl2LineCmndConfLdsfFailReason  Xdsl2LdsfResult,
      xdsl2LineCmndConfBpsc            Xdsl2LineBpsc,
      xdsl2LineCmndConfBpscFailReason  Xdsl2BpscResult,
      xdsl2LineCmndConfBpscReqCount    Unsigned32,
      xdsl2LineCmndAutomodeColdStart   TruthValue,
      xdsl2LineCmndConfReset           Xdsl2LineReset,
      xdsl2LineStatusActTemplate       SnmpAdminString,
      xdsl2LineStatusXtuTransSys       Xdsl2TransmissionModeType,
      xdsl2LineStatusPwrMngState       Xdsl2PowerMngState,
      xdsl2LineStatusInitResult        Xdsl2InitResult,
      xdsl2LineStatusLastStateDs       Xdsl2LastTransmittedState,
      xdsl2LineStatusLastStateUs       Xdsl2LastTransmittedState,
      xdsl2LineStatusXtur              Xdsl2LineStatus,
      xdsl2LineStatusXtuc              Xdsl2LineStatus,
      xdsl2LineStatusAttainableRateDs  Unsigned32,
      xdsl2LineStatusAttainableRateUs  Unsigned32,
      xdsl2LineStatusActPsdDs          Integer32,
      xdsl2LineStatusActPsdUs          Integer32,
      xdsl2LineStatusActAtpDs          Integer32,
      xdsl2LineStatusActAtpUs          Integer32,
      xdsl2LineStatusActProfile        Xdsl2LineProfiles,
      xdsl2LineStatusActLimitMask      Xdsl2LineLimitMask,
      xdsl2LineStatusActUs0Mask        Xdsl2LineUs0Mask,
      xdsl2LineStatusActSnrModeDs      Xdsl2LineSnrMode,
      xdsl2LineStatusActSnrModeUs      Xdsl2LineSnrMode,
      xdsl2LineStatusElectricalLength  Unsigned32,
      xdsl2LineStatusTssiDs            Xdsl2Tssi,
      xdsl2LineStatusTssiUs            Xdsl2Tssi,
      xdsl2LineStatusMrefPsdDs         Xdsl2MrefPsdDs,
      xdsl2LineStatusMrefPsdUs         Xdsl2MrefPsdUs,
      xdsl2LineStatusTrellisDs         TruthValue,
      xdsl2LineStatusTrellisUs         TruthValue,
      xdsl2LineStatusActualCe          Unsigned32
   }

Check out inconsistent abbreviations, such as
xdsl2LineCnfgFallbackTemplate which points to the
xdsl2LineConfTemplateTable. (cnfg and conf both mean configuration) I
note that RFC2662 uses "conf" consistently.

4)The counter  xdsl2LineCmndConfBpscReqCount let's management station M1
know when another management station M2 requested a measurement, which
caused the relevant counter to reset, such that M1's measurement is no
longer valid. 
      "SNMP managers can use this attribute to check that the
       measurement results retrieved by the manager where not 
       interupted by another measurement request."

We discouraged resetting counters in IETF MIB modules. Can you explain
why this is necessary? 

5) The naming conventions for counters are not being followed -
xdsl2LineCmndConfBpscReqCount should probably be
xdsl2LineCmndConfBpscRequests.

6) xdsl2LineCmndConfBpscReqCount -  why is this an Unsigned32 and not a
Counter32?

7) I am a bit concerned about the table that actually contains the
measurement - the xdsl2LineSegmentTable  The actual measurement is in
xdsl2LineSegmentBitsAlloc. It appears the value is overloaded to provide
subcarrier allocation status, as well as the result of a line diagnostic
test. 

8) from security considerations "Unauthorized changes to
xdsl2LineCmndConfBpsc could cause an unscheduled bits per subcarrier
measurement to be carried out on the line.", and "Unauthorized changes
to xdsl2LineCmndConfLdsf could cause an unscheduled line test to be
carried out on the line." Since these two measurements report using the
same object, and since one measurement can interfere with the validity
of the measurement requested by a different manager, this seems to have
serious issues of information reliability.

9) On a larger scale, I am concerned that this appears to be a
**competing** standard to RFC2662. This does not complement, or update,
or obsolete RFC2662.

I have not yet gone into the two mib modules to determine how compatible
they are, but section 4 in this document makes me really uneasy as a
(previous) management app designer. Can a device support both mib
modules simultaneously? Can a management app use both MIB modules
simultaneously to manage the same ADSL functions on a device?

I note that rfc2662 does support using the entity mib, while this mib
module does not. Which makes me wonder about the compatibility between
the two mib modules.

Thanks and Regards,

Dan



> -----Original Message-----
> From: mib-doctors-bounces at ietf.org 
_______________________________________________
Adslmib mailing list
Adslmib at ietf.org
https://www.ietf.org/mailman/listinfo/adslmib