Subject: Response:: [ipcdn] problems with draft-ietf-ipcdn-docs-rfmibv2-12.txt

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 2 Feb 2005 15:48:17 -0700

All, 

I have merged all Randy's emails with notes  x) ======== 
and responses following '>>'

(*) means probably It has no final solutions of what I am proposing 
and need more feedback from the list and MIB Doctor guidences  (if the
answer is not satisfactory or non conclusing)

Due the significant amount of comments,  Attached is the reviewed mib
and diff MIB v12 v13draft)

- includes edits for Bert comments in an email following this

Eduardo
Comments: 

1) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:01 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems with docsIfCmtsCmStatusTable
indraft-ietf-ipcdn-docs-rfmibv2-12.txt

docsIfCmtsCmStatusIndex: "SHOULD not" -> "SHOULD NOT"
>>Ok

the value in the UNITS clause doesn't match up with what the textual
convention's definition says. docsIfCmtsCmStatusRxPower,
>> UNITS       "ThenthdBmV"
docsIfCmtsCmStatusSignalNoise
>> UNITS       "TenthdB"
--> Odd case
docsIfCmtsCmStatusTimingOffset,
(*)
>>UNITS       "SixtyFourthOfTicks"

docsIfCmtsCmStatusUnerroreds,
>>UNITS       "codewords"
docsIfCmtsCmStatusCorrecteds,
>>UNITS       "codewords"
docsIfCmtsCmStatusUncorrectables,
>>UNITS       "codewords"
docsIfCmtsCmStatusExtUnerroreds
>>UNITS       "codewords"
docsIfCmtsCmStatusExtCorrecteds
>>UNITS       "codewords"
docsIfCmtsCmStatusExtUncorrectables
UNITS       "codewords"

--> odd case
docsIfCmtsCmStatusHighResolutionTimingOffset
(*)
>>UNITS     "SixtyFourthTwoHundredFiftySixthOfTicks"
Or (16384)
>>UNITS     "SixteenThousandsThreeHundredEigthyFourthOfTicks"
all need UNITS clauses

Randy

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

2) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:03 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems with docsIfCmtsStatusTable
indraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

Problems I saw with  docsIfCmtsStatusTable in
draft-ietf-ipcdn-docs-rfmibv2-12:

docsIfCmtsStatusInvalidRangeReqs,
>>UNITS       "messages"
docsIfCmtsStatusRangingAborteds,
>>UNITS       "attempts" 
docsIfCmtsStatusInvalidRegReqs,
>>UNITS       "messages"
docsIfCmtsStatusFailedRegReqs, 
>>UNITS       "attempts"
docsIfCmtsStatusInvalidDataReqs, 
>>UNITS       "messages"
docsIfCmtsStatusT5Timeouts 
>>UNITS       "timeouts"

all need UNITS clauses

Randy

3) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:06 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems with docsIfCmtsMacTable
indraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

Here's what I encountered in docsIfCmtsMacTable in
draft-ietf-ipcdn-docs-rfmibv2-12:

docsIfCmtsMaxServiceIds needs UNITS
>>UNITS      "SIDs" 
docsIfCmtsInvitedRangingAttempts
>>      UNITS      "attempts"
docsIfCmtsInsertInterval needs UNITS
>> Any common usage for TC TimeInterval
Perhaps
>> UNITS        "HundredOfSeconds"

docsIfCmtsMacStorageType - RFC 2579 in the definition of the StorageType
textual convention requires: " Every usage of this textual convention is
required to specify the columnar objects which a permanent(4) row must
at a minimum allow to be writable."

This TC object is read-only (ifTable extension) and indicates if changes
in read-write values will be retain as per TC StorageType value Also per
Compliance statements it is ok to implement RW objects as RO, thus 
No requirements for read-write objects to be writable for a permanent(4)
entry

docsIfCmtsMacStorageType OBJECT-TYPE
     SYNTAX       StorageType
     MAX-ACCESS   read-only
     STATUS       current
     DESCRIPTION
         "The storage type for this conceptual row.
          Entries with this object set to permanent(4) 
          do not require write operations for read-write
          objects."
     ::= { docsIfCmtsMacEntry 8 }
Randy

4) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:07 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems with docsIfCmServiceTable
indraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

Here's what I saw in problems with docsIfCmServiceTable in
draft-ietf-ipcdn-docs-rfmibv2-12:

docsIfCmServiceTxRetries needs a UNITS clause 
>>UNITS       "attempts"
docsIfCmServiceTxExceededs needs a UNITS clause 
>>UNITS       "PDUs" 
docsIfCmServiceRqRetries needs a UNITS clause 
>>UNITS       "attempts"
docsIfCmServiceRqExceededs needs a UNITS clause
>>>>UNITS       "PDUs"

Randy

5) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:13 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems with docsIfCmStatusTable
indraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

Here's what I saw in docsIfCmStatusTable in
draft-ietf-ipcdn-docs-rfmibv2-12:

docsIfCmStatusCode: the SIZE doesn't fit what the DESCRIPTION says. The
DESCRIPTION makes it sounds like the maximum length would be five.

>> RFC2670 does not have any constrain (any way is a RO value), for 
>> future extensibility leaving as in RFC 2670 will be ok
I do not recall any comments on the changes made from draft -05 to 06
where the change was made ....does any one knows what was the intention
of this change?

When it says decimal, it tries to represent a ".n" as last component so
it will be 5 or 6 octets T02.1 or W035.4
   
docsIfCmStatusCode OBJECT-TYPE
     SYNTAX      OCTET STRING 

docsIfCmStatusTxPower: the UNITS clause doesn't match what the TC's
definition says (dB or tenths of a dB)

docsIfCmStatusResets,
>>docsIfCmStatusResets OBJECT-TYPE
     SYNTAX      Counter32
     UNITS       "resets"
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Number of times the CM reset or initialized this
          interface.
		  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."
     ::= { docsIfCmStatusEntry 4 }
and
docsIfCmStatusLostSyncs
>>UNITS       "????" cannot think in something more better than the
object context
Or 
>> UNITS      "LostSyncs" (odd)....

need UNITS clause and discontinuity indicator

docsIfCmStatusInvalidMaps,
>>UNITS       "maps"
docsIfCmStatusInvalidUcds,
>>UNITS       "messages"
docsIfCmStatusInvalidRangingResponses,
>>UNITS       "messages"
docsIfCmStatusInvalidRegistrationResponses,
>>UNITS       "messages"
docsIfCmStatusT1Timeouts,
>>UNITS       "timeouts"
docsIfCmStatusT2Timeouts,
>>UNITS       "timeouts"
docsIfCmStatusT3Timeouts,
>>UNITS       "timeouts"
docsIfCmStatusT4Timeouts,
>>UNITS       "timeouts"
docsIfCmStatusRangingAborteds
UNITS       "attempts"
docsIfCmStatusUCCs,
UNITS           "attempts"
and
docsIfCmStatusUCCFails
UNITS           "attempts"

all need UNITS clauses

Randy

6) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:21 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problem with
docsIfCmMacTableindraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

One minor problem in docsIfCmMacTable:
docsIfCmRangingTimeout needs a UNITS clause

>> same as docsIfCmtsInsertInterval 
>>UNITS     "HundredSeconds" ( TC TimeInterval preferences? ) 

Randy

7) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:25 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems in docsIfSignalQualityTable
indraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

In docsIfSignalQualityTable in draft-ietf-ipcdn-docs-rfmibv2-12:

docsIfSigQSignalNoise - the UNITS clause is in conflict with the TC
definition
>>UNITS       "TenthdB"

docsIfSigQMicroreflections - is this really a case for SHOULD?  (Just
asking)
>>Same for :
>>docsIfCmtsCmStatusMicroreflections, docsIfSigQMicroreflections: leaved

>>as RFC2670 originally was "should"

Randy

8) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:34 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems in docsIfQosProfileTable
indraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

Problems in docsIfQosProfileTable in draft-ietf-ipcdn-docs-rfmibv2-12:

In docsIfQosProfileEntry the  words about read-create are a bit odd
here. I know what you mean, but as a literal description of this OBJECT
it seems odd.
>> SAME as RF  2670, not updated in RFIv2.0, can revisit later if 
>> needed....

docsIfQosProfMaxTransmitBurst: the type would be better as Unsigned32,
since these cannot be negative.
>>correct, Already since draft 05 and standard de-facto for 
>>implementations since draft 05, prefered leave as is

docsIfQosProfStorageType - RFC 2579 requires that "Every usage of this
textual convention is required to specify the columnar objects which a
permanent(4) row must at a minimum allow to be writable."
>>same as docsIfCmtsMacStorageType

docsIfQosProfStorageType OBJECT-TYPE
     SYNTAX       StorageType
     MAX-ACCESS   read-only
     STATUS       current
     DESCRIPTION
         "The storage type for this conceptual row."
          Entries with this object set to permanent(4) 
          do not require write operations for read-write
          objects." 
     ::= { docsIfQosProfileEntry 10 }

Randy

9) ======================

There are some problems with
docsIfUpstreamChannelTable in draft-ietf-ipcdn-docs-rfmibv2-12

docsIfUpChannelModulationProfile: returning a genErr under those
circumstances would be inappropriate.  RFC 3416 section 4.2.5 clearly
indicates that inconsistentValue would be the correct response.
>> FIXED

docsIfUpChannelSlotSize - should have UNITS
>>UNITS       "ticks"
>> I believe is not good to use timeticks, which could be confusing with
TC TimeTicks from RFC 2679, 
the "DOCSIS" ticks are slots of 6.25 usecs, 
see 1) above, the issues of how to name units of ticks/64 or
ticks/(64*256)

docsIfUpChannelTxTimingOffset - should have UNITS
(*)
>>UNITS       "SixtyFourthOfTicks"

docsIfUpChannelScdmaActiveCodes - since the primes can never be set and
can never be returned, they should be excluded in the SYNTAX
(*) 
>> I am not sure if this is appropiate or will breaks the regular
applications, 
To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109,113,127,
the SYNTAX clause will be 
SYNTAX     Unsigned32
(0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102|104..106|108
|110..112|114..126|128)
Do you prefer this? 
How do you break this for the 72 columns ID text file format?

docsIfUpChannelScdmaCodesPerSlot: needs UNITS, and would be better as
Unsigned32
>> UNITS       "codesperMinislots"
docsIfUpChannelScdmaFrameSize needs UNITS
>>UNITS       "spreadIntervals"

docsIfUpChannelScdmaHoppingSeed - may be set to non-zero for non-scdma?
>> Now reads:
docsIfUpChannelScdmaHoppingSeed OBJECT-TYPE
     SYNTAX     Unsigned32 (0..32767)
     MAX-ACCESS read-create
     STATUS     current
     DESCRIPTION
         "Applicable for SCDMA channel types only.
          15 bit seed used for code hopping sequence initialization.
          Returns zero for non-SCDMA channel types.
		  Setting this value to a value different than zero for 
		  non-SCDMA channel types returns error 'wrongValue'"
     REFERENCE
         "Data-Over-Cable Service Interface Specifications: Radio
          Frequency Interface Specification SP-RFIv2.0-I05-040407,
          Section 6.2.14.1."
     ::= { docsIfUpstreamChannelEntry 14 }

docsIfUpChannelUpdate: the use of genErr and commitFailed is
inappropriate in this DESCRIPTION.  RFC 3416 section 4.2.5 clearly
indicates that inconsistentValue would be the correct response.
comparing the request-id  from RFC 1157 and RFC 3416, the author was
keeping that backward compatible elements. 
I agree that only SMIv2 references being explicit and RFC 3584 handles
the mapping accordingly e.g. (4.4.  Error Status Mappings) 
 
Now it reads

docsIfUpChannelUpdate OBJECT-TYPE
     SYNTAX      TruthValue
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         " Used to perform the transfer of adjusted parameters
          from the temporary upstream row to the physical upstream
          row indicated by the docsIfUpChannelCloneFrom object.  The
          transfer is initiated through an SNMP SET to 'true' of
          this object.  The SNMP SET failure returns 'inconsistentValue'
          if the adjusted parameter values are not compatible with each
          other.  Reading this object always return 'false'."
     ::= { docsIfUpstreamChannelEntry 17 }
Randy

10) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:51 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] problems in docsIfDownstreamChannelTable
indraft-ietf-ipcdn-docs-rfmibv2-12

Hi -

I saw a few problems in docsIfDownstreamChannelTable in
draft-ietf-ipcdn-docs-rfmibv2-12

docsIfDownChannelWidth and docsIfDownChannelModulation:
question: what is meant by "associated compliance object"?
>> I believe the intention of RFC 2670 was to indicate Compliance
modules

changed to :

docsIfDownChannelWidth OBJECT-TYPE
     SYNTAX      Integer32 (0..16000000)
     UNITS       "hertz"
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The bandwidth of this downstream channel.  Most
          implementations are expected to support a channel width
          of 6 MHz (North America) and/or 8 MHz (Europe).  See the
          associated compliance statements for a description of the
          valid channel widths for this object."
     REFERENCE
         "Data-Over-Cable Service Interface Specifications: Radio
          Frequency Interface Specification SP-RFIv2.0-I05-040407,
          Table 6-17."
     ::= { docsIfDownstreamChannelEntry 3 }

docsIfDownChannelPower:  looks like some words got lost
in the update to the DESCRIPTION.

The diff text is:

"May be set to zero at the CM if power level measurement is not
supported."

I believe it was intended to say:
"May report zero at the CM if power level measurement is not supported."

Clearly indicate a DOCSIS 1.0 optional measurement of this parameter.
DOCSIs spec intention was to make that mandatort , therefore removed
since 
draft-ietf-ipcdn-docs-rfmibv2-01.txt ( not documented in Changes from
RFC2670 )

(*) Will add the change track

docsIfDownChannelStorageType: RFC 2579 requires:
"Every usage of this textual convention is required to
specify the columnar objects which a permanent(4) row must
at a minimum allow to be writable."

>>same as other StorageType read-only entries

Entries with this object set to permanent(4) 
          do not require write operations for read-write
          objects.
same done for 
docsIfQosProfStorageType
docsIfCmtsModStorageType           

Randy

11) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 6:54 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] textual conventions in draft-ietf-ipcdn-docs-rfmibv2-12

Hi -

Some of the textual conventions in draft-ietf-ipcdn-docs-rfmibv2-12 need
a little work.  
Specifically, The DocsisVersion, 
DocsisQosVersion, 
DocsisUpstreamType, and 
DocsisUpstreamTypeStatus 
TCs shouldspecify in their respective DESCRIPTIONS what each of their
enumerated values means.

Randy
>> changed to:

DocsisVersion ::= TEXTUAL-CONVENTION
    STATUS          current
    DESCRIPTION     "Indicates the DOCSIS Radio 
	                 Frequency specification being 
					 referenced.  
	                 'docsis10' indicates DOCSIS 1.0, 
					 'docsis11' indicates DOCSIS 1.1
					 'docsis20' indicates DOCSIS
2.0"
    SYNTAX          INTEGER {
        docsis10 (1),
        docsis11 (2),
        docsis20 (3)
    }

DocsisQosVersion ::= TEXTUAL-CONVENTION
    STATUS          current
    DESCRIPTION     "Indicates the referenced quality of service
	                 level. 
					 'docsis10 refers to DOCSIS 1.0
Class of 
					 Service queuing services.
					 'docsis11' refers to DOCSIS 1.1
Quality of
					 Service."
    SYNTAX          INTEGER {
        docsis10 (1),
        docsis11 (2)
    }

DocsisUpstreamType ::= TEXTUAL-CONVENTION
    STATUS          current
    DESCRIPTION     "Indicates the DOCSIS Upstream Channel Type.
	                'unknown' means not information available 
					or configured to determine.
					'tdma' is related to TDMA, Time
Division 
					 Multiple Access, 'atdma' is
related to A-TDMA,
					 Advanced Time Division Multiple
Access, 
					 'scdma' is related to S-CDMA,
Synchronous 
					 Code Division Multiple Access
					 'tdmaAndAtdma is related to
simultanous support of 
					 TDMA and A-TDMA modes."
    SYNTAX          INTEGER {
        unknown (0),
        tdma (1),
        atdma (2),
        scdma (3),
        tdmaAndAtdma (4)
    }

DocsisUpstreamTypeStatus ::= TEXTUAL-CONVENTION
    STATUS          current
    DESCRIPTION
        "Indicates the DOCSIS Upstream Channel Type Status.
         Values are the same as DocsisUpstramType but the shared
         channel indicator type (tdmaAndAtdma) is not valid, since
         this type is used to specifically identify PHY mode."
    SYNTAX          INTEGER {
        unknown (0),
        tdma (1),
        atdma (2),
        scdma (3)
    }
    
>> Your next Q. Why two TC instead of one TC with compliance statements
? 
It was for simplicity in the MIB scope of syntax. CMTS can configure
tdmaAndtdma, but CMs uses only one 
multiple access method, it means CM status values uses
DocsisUpstreamTypeStatus (DocsisUpstreamType minus tdmaAndAtdma)
and CMTSes uses for configuration DocsisUpstreamType 

(*) If recommended compliance statements  better that can be done

12) ======================

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Sunday, January 30, 2005 7:00 PM
To: Ipcdn (E-mail)
Subject: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in 

Hi -

A question on docsIfCmtsServiceNewCmStatusIndex  in
draft-ietf-ipcdn-docs-rfmibv2-12.txt

The definition says:

docsIfCmtsServiceNewCmStatusIndex OBJECT-TYPE
        SYNTAX      Integer32 (0..2147483647)
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "Pointer (via docsIfCmtsCmStatusIndex) to an entry in
             docsIfCmtsCmStatusTable identifying the Cable Modem
             using this Service Queue.  If multiple Cable Modems are
             using this Service Queue, the value of this object is
             zero."
        ::= { docsIfCmtsServiceEntry 8 }

What value would it have if no Cable Modems are using this Service
Queue?

>> below early replies.

-----Original Message-----
From: Eduardo Cardona 
Sent: Monday, January 31, 2005 12:53 PM
To: Randy Presuhn; Ipcdn (E-mail)
Subject: RE: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in 

Randy, I will answer on details your q. by COB today.
Also have in the Queue Bert's Questions whichI am resolving in
conjuction.

To this Q, all CMTS are associated to a Queue service (have to) . So one
CM either has its own particular Queue service, or a group (all
cms) are using the same Queue. 

RFC 2670 did not defined in docsIfCmtsCmStatusTable (per modem) the
matching ServiceQueue it belongs to, thus, by RFC 2670, it is probably
safe to say that only one Service Queue group is available. 

All the Service Queue mechanism (Class of Service) is being replaced for
the service Flow QoS mechanism in the Qos MIB. The service Queue
mechanism is being left as defined in RFC 2670 as backward compatibility
support of DOCSIS 1.0 technology.
 
Eduardo

-----Original Message-----
From: Fred Oko [mailto:[email-masked]] 
Sent: Monday, January 31, 2005 3:11 PM
To: Eduardo Cardona; Randy Presuhn; Ipcdn (E-mail)
Subject: RE: [ipcdn] question on docsIfCmtsServiceNewCmStatusIndex in 

Or simplified, a Service Queue would not exist in the absence of a
parent CM (non-zero-docsIfCmtsServiceNewCmStatusIndex case) or multicast
group defined by the CMTS (the "multiple Cable Modems" zero-
docsIfCmtsServiceNewCmStatusIndex case).

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