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

Hi Dan, 
Thanks for the note, certainly a good catch,

It is certainly a typo, while adding discontinuity statements back In
February 2003 if I am not mistaken


Draft 06 says :

docsIfSigQMicroreflections OBJECT-TYPE
        SYNTAX      Integer32 (0..255)
        UNITS       "dBc"
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "Total microreflections including in-channel response
             as perceived on this interface, measured in dBc below
             the signal level.
             This object is not assumed to return an absolutely
             accurate value, but should give a rough indication
             of microreflections received on this interface.
             It is up to the implementer to provide information
             as accurate as possible."
        REFERENCE
            "Data-Over-Cable Service Interface Specifications: Radio
             Frequency Interface Specification SP-RFIv2.0-IO2-020617,
             Tables 4-1 and 4-2"
        ::= { docsIfSignalQualityEntry 6 }

and draft 07 updates multiple counter objects like docsIfSigQUnerroreds,
docsIfSigQCorrecteds, docsIfSigQCorrecteds, docsIfSigQUncorrectables,
docsIfSigQCorrecteds, docsIfSigQUncorrectables, Ext objects, etc.

By mistake it was included also in docsIfSigQMicroreflections 

Perhaps a correction should be done during final editorial revision to
remove that statement

docsIfSigQMicroreflections OBJECT-TYPE 
        SYNTAX      Integer32 (0..255) 
        UNITS       "dBc" 
        MAX-ACCESS  read-only 
        STATUS      current 
        DESCRIPTION 
            "Total microreflections including in-channel response 
             as perceived on this interface, measured in dBc below 
             the signal level. 
             This object is not assumed to return an absolutely 
             accurate value, but SHOULD give a rough indication 
             of microreflections received on this interface. 
             It is up to the implementer to provide information 
             as accurate as possible." 
        REFERENCE 
            "Data-Over-Cable Service Interface Specifications: Radio 
             Frequency Interface Specification SP-RFIv2.0-I05-040407, 
             Tables 4-1 and 4-2" 
        ::= { docsIfSignalQualityEntry 6 } 


Thanks 

Eduardo

-----Original Message-----
From: Dan Rice @ Stargus 
Sent: Tuesday, May 04, 2004 9:47 PM
To: Richard Woundy @ Comcast; Lejeune, Andre
Cc: [email protected]
Subject: RE: [ipcdn] 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)