Subject: [ipcdn] rf mib draft v5 - comment period end Friday Oct 25

From: "Raftus, David" <[email-masked]>
Date: Fri, 18 Oct 2002 12:55:22 -0700

Hi everyone,
 
Please find attached a draft of the Docsis RF Interface mib v5. The TOC and
compliance statements have not been updated, but suggestions received since
v4 regarding new mib objects have been incorporated after appropriate
massaging.
 
Comments are welcome on this draft until 5pm EST Friday October 25. At that
time an official version of the draft will be prepared for submission to the
IETF last call process, leading to RFC designation.
 
Thanks very much,
Dave
 
************************************
David Raftus
Imedia Semiconductor
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2
 
[email-masked]           
613.592.1052  ext 222
************************************

---

From: "Bob Himlin" <[email-masked]>
Date: Mon, 21 Oct 2002 15:14:16 -0700

Regarding the 64-bit docsIfSigQ codeword counters, is it the intent of the
authors to deprecate the 32-bit counters, or to have both 32-bit and 64-bit
counters, similar to ifTable & ifXTable octet counters?  If the intent is to
deprecate the 32-bit counters, the 32-bit objects should be listed as
deprecated, not as current.  If not, perhaps a note in the description of
the 32-bit counters should state that the 32-bit counters are intended to
reflect the 32 LSBs of the 64-bit counters.  This would prevent any unwanted
‘special’ behavior of the 32-bit counters on rollover, an example of which
might be to reset all the 32-bit counts to 0 when the highest one rolls (a
behavior I have observed in the past).

Also, the 64-bit counters are not referenced in any compliance statement.
Given they are not required by compliance statements, do you expect them to
be implemented?

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Raftus,
David
Sent: Friday, October 18, 2002 12:55 PM
To: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
Cc: Raftus, David
Subject: [ipcdn] rf mib draft v5 - comment period end Friday Oct 25

Hi everyone,

Thanks very much,
Dave

[email-masked]
613.592.1052  ext 222

---

From: "Margo Dolas" <[email-masked]>
Date: Fri, 25 Oct 2002 14:46:18 -0400

Dave,

I have one minor comment on the docsIfCmtsChannelUtilization object.

For granted slots, once the CMTS has made the grant, that bandwidth is
"utilized" regardless of whether the CM actually puts a burst in that slot
or not.  I think that the wording in the mib spec needs to be modified so
that any grant counts as "utilized".

How about the following text change?
Replace -
              Upstream Channel Utilization Index:
              The upstream channel utilization index is expressed as a
              percentage of minislots for which the CMTS received an
              upstream burst from any CM on the physical channel, regardless
              of burst type.

With -
              Upstream Channel Utilization Index:
              The upstream channel utilization index is expressed as a
              percentage of minislots for which the CMTS granted bandwidth
to
              any CM on the physical channel, regardless of burst type.

Regards,
Margo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Raftus, David
Sent: Friday, 18 October, 2002 3:55 PM
To: Docsis 20 Reflector (E-mail); Docsis Oss Reflector (E-mail); Ipcdn List
(E-mail)
Cc: Raftus, David
Subject: rf mib draft v5 - comment period end Friday Oct 25

Hi everyone,

Thanks very much,
Dave

[email-masked]
613.592.1052  ext 222

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

---

From: Minnie Lu <[email-masked]>
Date: Fri, 25 Oct 2002 12:04:00 -0700

Hi, Raftus,

    There is conflict between RFI spec. and the following MIB object range

  docsIfQosProfMaxTransmitBurst OBJECT-TYPE
         SYNTAX      Integer32 (0..1522)  <===========
         MAX-ACCESS  read-create
         STATUS      current
         DESCRIPTION
             "The maximum number of bytes that may be requested for a
              single upstream transmission. A value of zero means there
              is no limit. Note: This value does not include any
              physical layer overhead.
              MUST NOT be changed while this row is active."
         REFERENCE
             "Document [25] from References, Appendix C.1.1.4."
         DEFVAL { 0 }
         ::= { docsIfQosProfileEntry 9 }

In RFIv1.1 (C1.1.4.6) and RFIv2.0 (C1.1.4.6), it defined 2 bytes and does 
not have upper limit to 1522.    This conflict exists in v4 version which 
is in use by OSSI spec. (1.1, and 2.0).

  Any reason for MIB to have such upper limit ? If not, would you please 
correct this error in the MIB file ?

Thanks a lot !
Minnie

At 12:55 PM 10/18/2002 -0700, Raftus, David wrote:

>Hi everyone,
>
>
>
>Please find attached a draft of the Docsis RF Interface mib v5. The TOC 
>and compliance statements have not been updated, but suggestions received 
>since v4 regarding new mib objects have been incorporated after 
>appropriate massaging.
>
>
>
>Comments are welcome on this draft until 5pm EST Friday October 25. At 
>that time an official version of the draft will be prepared for submission 
>to the IETF last call process, leading to RFC designation.
>
>
>
>Thanks very much,
>
>Dave
>
>
>
>Ottawa Canada
>[email-masked]************************************ 
>58147a.jpg581498.jpg
>
>
>
>