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

"Wijnen, Bert (Bert)" <[email protected]>
Newsgroups gmane.ietf.adslmib
Message-ID <7D5D48D2CAA3D84C813F5B154F43B1550808D9BB@nl0006exch001u.nl.lucent.com>
I think, these warnings are the same as that listed under point 2 below
 
C:\bwijnen\smicng\work>smicng adsl2.inc
W: f(adsl2.mi2), (3509,21) Item "adsl2LineAlarmConfProfileAtucThresh15MinFecSeco
nds" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3524,21) Item "adsl2LineAlarmConfProfileAtucThresh15MinEs" wit
h syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3538,21) Item "adsl2LineAlarmConfProfileAtucThresh15MinSes" wi
th syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3552,21) Item "adsl2LineAlarmConfProfileAtucThresh15MinLoss" w
ith syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3566,21) Item "adsl2LineAlarmConfProfileAtucThresh15MinUas" wi
th syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3580,21) Item "adsl2LineAlarmConfProfileAturThresh15MinFecSeco
nds" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3594,21) Item "adsl2LineAlarmConfProfileAturThresh15MinEs" wit
h syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3608,21) Item "adsl2LineAlarmConfProfileAturThresh15MinSes" wi
th syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3623,21) Item "adsl2LineAlarmConfProfileAturThresh15MinLoss" w
ith syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3637,21) Item "adsl2LineAlarmConfProfileAturThresh15MinUas" wi
th syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3651,21) Item "adsl2LineAlarmConfProfileThresh15MinFailedFullI
nt" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3664,21) Item "adsl2LineAlarmConfProfileThresh15MinFailedShrtI
nt" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3733,21) Item "adsl2ChAlarmConfProfileAtucThresh15MinCodingVio
lations" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3746,21) Item "adsl2ChAlarmConfProfileAtucThresh15MinCorrected
" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3760,21) Item "adsl2ChAlarmConfProfileAturThresh15MinCodingVio
lations" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (3773,21) Item "adsl2ChAlarmConfProfileAturThresh15MinCorrected
" with syntax INTEGER is required to have a range specified in SMIv2
W: f(adsl2.mi2), (4044,4) Sequence "Adsl2PMLineCurrInitEntry" and Row "adsl2PMrL
ineCurrInitEntry" should have related names
W: f(adsl2.mi2), (6,7) "TimeTicks" imported but not used
W: f(adsl2.mi2), (10,7) "snmpModules" imported but not used
 
*** 0 errors and 19 warnings in parsing

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of Clay Sikes
Sent: Friday, September 09, 2005 21:32
To: IETF ADSL MIB List
Subject: [Adslmib] 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:


1.	adsl2SCStatusDirection has an empty description. 

2.	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 

3.	adsl2LineAlarmConfTemplateGroup has an empty description. 

4.	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.


5.	TimeTicks is imported but not used. 

6.	snmpModules is imported but not use. 


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


1.	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? 

2.	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
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.