Phase 1 Comments on draft-ietf-adslmib-adsl2-01

Thanks Moti, Menachem, Scott, and Umberto for the awesome work you are
doing on this draft. I'm going to be reviewing the draft and look
forward to providing comments. Most likely, I'll send comments in
phases as I dig deeper into it.

For phase 1, I just ran "smilint -m -s -l6 -inamelength-32" and it
identified the following issues:

- adsl2SCStatusDirection has an empty description.

- Several objects misuse INTEGER. Seems like Integer32 or
Unsigned32 should be used. See comment below on "Objects that are of a
`Count of seconds' below. The objects smilint tagged are as follows:

- adsl2LineAlarmConfProfileAtucThresh15MinFecSeconds

- adsl2LineAlarmConfProfileAtucThresh15MinEs

- adsl2LineAlarmConfProfileAtucThresh15MinSes

- adsl2LineAlarmConfProfileAtucThresh15MinLoss

- adsl2LineAlarmConfProfileAtucThresh15MinUas

- adsl2LineAlarmConfProfileAturThresh15MinFecSeconds

- adsl2LineAlarmConfProfileAturThresh15MinEs

- adsl2LineAlarmConfProfileAturThresh15MinSes

- adsl2LineAlarmConfProfileAturThresh15MinLoss

- adsl2LineAlarmConfProfileAturThresh15MinUas

- adsl2LineAlarmConfProfileThresh15MinFailedFullInt

- adsl2LineAlarmConfProfileThresh15MinFailedShrtInt

- adsl2ChAlarmConfProfileAtucThresh15MinCodingViolations

- adsl2ChAlarmConfProfileAtucThresh15MinCorrected

- adsl2ChAlarmConfProfileAturThresh15MinCodingViolations

- adsl2ChAlarmConfProfileAturThresh15MinCorrected

- adsl2LineAlarmConfTemplateGroup has an empty description.

- None of the notifications are reverse mappable.

Most likely the change needs to be made to adsl2Notifications such that
the OID is { someOID 0 }.

Perhaps adsl2Notifications OBJECT IDENTIFIER ::= { adsl2 0 } or

adsl2Notifications OBJECT IDENTIFIER ::= { ngdslMIB 0 }.

The important thing is to have the next-to-the-last integral value a 0.

- TimeTicks is imported but not used.

- snmpModules is imported but not use.

Other thinks that I noticed without going into any depth were:

- There are several objects that are a "Count of seconds" and have
a syntax of Unsigned32. Since they are counting, doesn't the Counter32
syntax provide a better fit?

- I wonder if it would be better to break out the TCs into another
one or more additional MIBs? I am especially concerned with the
Adsl2TransmissionModeType. I would expect that over time, reserved bits
may be defined or additional bits may be defined. The length of time to
respin an RFC could be measured in years. I would hope that it would
be less if it is a standalone TC. In any case it might be easier to
unload a TC and load a draft TC that defines the new bits. Thoughts?

The description text for adsl2LineStatusAtuTransSys and
adsl2LInvTransmissionType seem to reproduce much of the description
text in the Adsl2TransmissionModeType TC (i.e. the bit definitions). It
seems like the bit definition description text should be limited to the
TC so that when new bits are defined in the future, only one update is
needed.

I'll feed more comments as I dig deeper.

Thanks again for the awesome work!

Best Regards,

Clay Sikes

-- Paradyne Mail --

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