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

From: Donati Andrew-MGIA0477 <[email-masked]>
Date: Fri, 11 Jun 2004 08:51:28 -0400

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-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, June 11, 2004 8:04 AM
To: [email-masked]
Subject: IPCDN Digest, Vol 1, Issue 597

Send IPCDN mailing list submissions to
	[email-masked]

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-masked]

You can reach the person managing the list at
	[email-masked]

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-masked]>
Subject: RE: [ipcdn] Updates for next RFI v2 MIB I-D (11)
To: "Randy Presuhn" <[email-masked]>, <[email-masked]>
Message-ID:
	<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

See inline, 

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

Hi -

> From: "Eduardo Cardona" <[email-masked]>
> To: <[email-masked]>
> Cc: "DOCSIS OSS Majordomo List" <[email-masked]>
> 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-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

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

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

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

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