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