RE: Changes for next RFI v2 MIB (draft 10)

Hi
I just got around to looking at the latest draft. Quick question.
 
Does the statement
"Discontinuities in the value of this counter can occur 
             at reinitialization of the managed system, and at other 
             times as indicated by the value of  
             ifCounterDiscontinuityTime for the associated ifIndex."
 
Really belong in the object 
 
docsIfSigQMicroreflections OBJECT-TYPE 
        SYNTAX      Integer32 (0..255) 
        UNITS       "dBc"
 
-----Original Message-----
From: Woundy, Richard [mailto:[email protected]] 
Sent: Monday, April 26, 2004 12:51 PM
To: 'Lejeune, Andre'
Cc: [email protected]
Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)
 
Andre,
 
My apologies, this email was stuck in a "potential spam" queue for IPCDN
for way too long...
 
-- Rich
-----Original Message-----
From: Lejeune, Andre [mailto:[email protected]]
Sent: Thursday, April 15, 2004 11:32 AM
To: Eduardo Cardona; [email protected]; DOCSIS OSS Majordomo List; DOCSIS
Macup Majordomo List
Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)
I believe this object should have been defined as read-only as there is
no advantage in having it read-write. Moreover, the RFI specification,
in Annex B, defines a min and max value for it. I do not see how such a
timeout can take multiple values. There should have been a unique value
for it.
Andre 
-----Original Message----- 
From: Eduardo Cardona [mailto:[email protected]] 
Sent: Thursday, April 15, 2004 11:07 AM 
To: [email protected]; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo 
List 
Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) 
 
Hi all, 
I have some questions regarding the MIB object docsIfCmRangingTimeout 
Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96 
show docsIfCmRangingTimeout  with syntax read-write ( the only CM 
read-write object in RFI MIB). 
 
The questions are 
Is this object really need to be read-write? 
particularly if there is any management case where read-write is used. 
Currently there is no Compliance statement to allow read-only access, is

that needed? 
Is there any instance (in general) when the T3 timer is being adjusted 
by the CM and retained in Memory after CM reboots ?, or would be ok to 
explicitly not require persistence without incurring in spec changes? 
(just a clarification) 
I am Not planning to deprecate the object but The new revision of RF MIB

is being updated to address IETF OPS MIB revision guidelines related to 
persistence and would be good to precise CM usage of the object. 
See ipcdn mailing list for current discussion about draft 10 updates 
http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h

tml 
I will post OSSI DOCSIS reflector with a second revision of the changes 
as well as IPCDN list soon 
Thanks 
Eduardo 
 
PD: In Annex A of OSSI spec the obsolete object above 
docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being 
tracked to include in an Omnibus ECR)