RE: Contents of IPCDN Digest, Vol 1, Issue 597 on docsIfCmStatu sValue "other(1)"

On the subject of docsIfCmStatusValue for the value of "other(1)": 

As Eduardo was refering to below, some vendors use the value of "other(1)" to represent
offline modems.  Would it be practical to add a new value of "offline" at this point
to represent modems in this state for vendors who support it?  
    
Thanks,
Andy 


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Friday, June 11, 2004 8:04 AM
To: [email protected]
Subject: IPCDN Digest, Vol 1, Issue 597


Send IPCDN mailing list submissions to
	[email protected]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www1.ietf.org/mailman/listinfo/ipcdn
or, via email, send a message with subject or body 'help' to
	[email protected]

You can reach the person managing the list at
	[email protected]

When replying, please edit your Subject line so it is more specific than "Re: Contents of IPCDN digest..."


Today's Topics:

   1. RE: Updates for next RFI v2 MIB I-D (11) (Eduardo Cardona)


----------------------------------------------------------------------

Message: 1
Date: Thu, 10 Jun 2004 08:07:53 -0600
From: "Eduardo Cardona" <[email protected]>
Subject: RE: [ipcdn] Updates for next RFI v2 MIB I-D (11)
To: "Randy Presuhn" <[email protected]>, <[email protected]>
Message-ID:
	<[email protected]>
Content-Type: text/plain;	charset="us-ascii"

See inline, 


-----Original Message-----
From: Randy Presuhn [mailto:[email protected]] 
Sent: Monday, June 07, 2004 5:49 PM
To: [email protected]
Subject: Re: [ipcdn] Updates for next RFI v2 MIB I-D (11)


Hi -

> From: "Eduardo Cardona" <[email protected]>
> To: <[email protected]>
> Cc: "DOCSIS OSS Majordomo List" <[email protected]>
> Sent: Tuesday, June 08, 2004 8:24 AM
> Subject: [ipcdn] Updates for next RFI v2 MIB I-D (11)
...
> 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.

The word "Total" seems rather odd, given the semantics
of this object.  Furthermore, the MIB review guidelines
section 4.6.1.1 suggest that Unsigned32 or Gauge32
would be a more appropriate type, since negative values
are precluded by the syntax.

(Also, if it's dBc *below* the signal, wouldn't the UNITS be
"-dBc"?)

<Edo>
Good point, Total is not needed, 
The units format also make sense, a measure of -52 dBc will be represented as 52 -dBc This is an object already defined if RFC 2670, understanding the recommended practice, I see impractical To deprecate it and create a new one with a quite precise syntax </Edo>


...
> docsIfCmStatusValue OBJECT-TYPE
>         SYNTAX      INTEGER {
>             other(1),
...
>             "Current Cable Modem connectivity state, as specified
>              in the RF Interface Specification.  Interpretations for
>              state values 1-12 are clearly outlined in the SP-RFI
>              reference given below.
>              The state value accessDenied(13) indicates the CMTS has
>              sent a Registration Aborted message to the CM. Same
>              state is reported as accessDenied(7) by the CMTS object
>              docsIfCmtsCmStatusValue."
...

Question: does this mean that some cases where SP-RFI would
say other(1) this object will say accessDenied(13)?

<edo>
Actually other(1) is a placeholder for states not defined in the state machine of the CM/CMTS initialization process 
In particular an CM can report other(1) and take advantage of docsIfCmStatusCode object to get more specific information of the situation via the CM Diagnostic interface.
 
When the CMTS rejects the registration of the CM by sending an error code in the registration response, at that time 
Both CMTS and CM will have status accessDenied  but both CM and CMTS have different timeouts cycles to refresh their own Status Value.

Specifically for the other(1) state e.g. some CMTSes (vendor
implementation) caches the Index assigned to the CM in docsIfCmtsCmStatusTable when the CM is power off to just reuse the index when the device come back. To keep the entry active in the table the
other(1) state may be used. 
</edo>


Randy



_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn




------------------------------

_______________________________________________
IPCDN mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn


End of IPCDN Digest, Vol 1, Issue 597
*************************************