RE: 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)