RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib

IPCDN group participants,

Below is a list of the pending issues raised by Bert and Randy with my
reply, All other comments I believe are addressed in the attached draft
(build against XML2RFC  ver 1.28, and checked with levkowetz NITS ver
1.58 and smilint )

see reply emails:
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01582.html
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01583.html

Items NOT listed below still need MIB doctor's "RE:" to the proposed
resolution (marked with ">>" in the emails listed above).

Some of the pending items are editorial to complete prior to submit as
IETF ID 13 
Others (normally with *) are calling for MIB Doctors or IPCDN
participants comments.

In any case I do not believe these are technical changes ( to return to
WGLC) and more editorial issues that improve the content itself. -
comments? 

Please make the appropriate comments by COB Feb 11 before submitting the
ID.

Thanks

Eduardo

Pending issues for clarification and resolution:

--> Odd case
docsIfCmtsCmStatusTimingOffset,
(*)
>>UNITS       "SixtyFourthOfTicks"

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

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?

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

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

==================

Comments with >>

Attached draft for next ID with comments (+ Randy's this week email)
plus a diff file

Eduardo

Bert Wihnen  comments:

  !! Missing Reference for citation: [RFC2670]
     P122 L050:      interfaces" [RFC2670].
>> Added in informative reference  section (instead of normative
reference section)

5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type
used
    in `docsIfCmtsCmStatusEqualizationData'

   Probably OK. Can you add some text to explain why this is OK?
>>(*) 
   I do not have other explanation than "enough" room, probably for
future enhancements (?)
   Current DOCSIS MAC may constrain to 256 bytes total the equalizer
data maps.

   Does anyone recall the reasons for the number selection? 

7. ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type
used in
   `docsIfSigQEqualizationData'

   you may want to add some text why the range change is OK
>> same as 6.

Other comments:

- docsIfCmtsModControl OBJECT-TYPE
        SYNTAX      RowStatus
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
            "Controls and reflects the status of rows in this table."
        ::= { docsIfCmtsModulationEntry 3 }

  It would be good to add text to explain which (if any) objects can be 
  changed when the row is active.

  Pls check if there are other RowStatus objects that lack that text as
well.

>> Text was on the Entry object 
Moved to docsIfCmtsModControl object
         There is no restriction on the changing of values in this
          table while their associated rows are active with the
          exception of:

          1. If a modulation profile is being referenced by one
             or more upstream channels, an attempt to set the value
             of docsIfCmtsModChannelType returns 'inconsistentValue'
             error.

          2. If a modulation profile is being referenced by one
             or more upstream channels, an attempt to set
             docsIfCmtsModControl to destroy(6) or notInService(2)
             returns 'inconsistentValue' error."

- WHen you deprecate/obsolete objects or groups or module compliance or
  whatever, then it is good practice to ADD a little text to the
DESCRITPION
  clause to explain why the depraction/obsoletion occured and which (if
any)
  other definition should be used instead.

        SYNTAX      INTEGER {
            other(1),
            ranging(2),
            rangingAborted(3),
            rangingComplete(4),
            ipComplete(5),
            registrationComplete(6),
            accessDenied(7),
            operational(8), -- deprecated
            registeredBPIInitializing(9)

   I do not understand why a "deprecated" value gets added when
upgrading from
   RFC2670 to this new document. ??

>>
Two parts:
...

2) (*) Long Story... It was around draft 8 a spec ECR to update the MIB
with value 'complete' 
as final value after Cm is in stable mode and registered, 
It was found inconvenient to change the final state but few devices were
able to implement 
the complete state

Otherwise we need to say in the MIB value 8 -complete is reserved 

Alternative  : ( not sure if better for IETF process....

docsIfCmtsCmStatusValue OBJECT-TYPE
     SYNTAX      INTEGER {
         other(1),
         ranging(2),
         rangingAborted(3),
         rangingComplete(4),
         ipComplete(5),
         registrationComplete(6),
         accessDenied(7),
         -- Enumeration value 8 is reserved 
         registeredBPIInitializing(9)
     }
     MAX-ACCESS  read-only
     STATUS      current
     DESCRIPTION
         "Current Cable Modem connectivity state, as specified
          in the RF Interface Specification.  Returned status
          information is the CM status as assumed by the CMTS,
          and indicates the following events:
          other(1)
             Any state other than below.
          ranging(2)
             The CMTS has received an Initial Ranging Request
             message from the CM, and the ranging process is not
             yet complete.
          rangingAborted(3)
             The CMTS has sent a Ranging Abort message to the CM.
          rangingComplete(4)
             The CMTS has sent a Ranging Complete message to the CM.
          ipComplete(5)
             The CMTS has received a DHCP reply message and
             forwarded it to the CM.
          registrationComplete(6)
             The CMTS has sent a Registration Response message to
             the CM.
          accessDenied(7)
             The CMTS has sent a Registration Aborted message
             to the CM.
          registeredBPIInitializing(9)
             Baseline Privacy (BPI) is enabled and the CMTS is in the
             process of completing BPI initialization.  This state
             MAY last for a significant length of time if failures
             occur during the initialization process.  After
             completion of  BPI initialization, the CMTS will report
             registrationComplete(6).
          The CMTS only needs to report states it is able to
          detect.
          Enumeration value 8 is reserved and MUST not be used or 
          assigned when updating this MIB module"
     REFERENCE
         "Data-Over-Cable Service Interface Specifications: Radio
          Frequency Interface Specification SP-RFIv2.0-I05-040407,
          Section 11.2."
     ::= { docsIfCmtsCmStatusEntry 9 }

>> change to Update:

- The MIB module states:

        REVISION        "200411221700Z"
        DESCRIPTION
            "Revision of the IETF RF MIB module for DOCSIS 2.0.
             This version published as RFC XXXX."

  You need to list (at least the major) changes to the MIB module.
  Pls realize that a lot of people extract the MIB module from the
document
  and then the sect 10 is not always easily available/handy.

>> will move a quick version of them there. (not yet....)

- Can you explain why you need the compexity of clone from as described
in
  docsIfUpChannelCloneFrom, docsIfUpChannelUpdate and
docsIfUpChannelStatus
  I really do not understand why you have to make this so complex.

>> We have discussed that in the past, Randy Presuhn was also against
this mechanis
   The difference with a clone mechanis as used in USM is that the
clonned entry may 
   not be turn active ( real physical interface) with hardward
dependencies and ifStack 
   ramifications hardly described by ifIndex
   The clone mechanis copy the values of an active entry into a 'fake
entry'
   then parameters are changed and values set back to the ifIndex of
interest.

   It helps to minimize service disruption for on service updates.
   The group discussed alternatives like a group of scalar objects
mapping the table columns 
   to do so but it seemed to be at time of design over-defining new set
of objects.

   Any intermediate solution (?)

RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib - 2670bis

Attachment: draft-ietf-ipcdn-docs-rfmibv2-13.txt