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

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

Good, understood

Thanks

Eduardo

-----Original Message-----
From: Richard Woundy @ Comcast 
Sent: Wednesday, February 02, 2005 4:43 PM
To: Eduardo Cardona; Wijnen, Bert (Bert); Jean-Francois Mule; [email-masked]
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib - 2670bis

Eduardo,

Bert said:
>  * The document seems to lack an IANA Considerations section.

You said:
> 
>Added x. IANA Considerations
>    The MIB module in this document uses the following IANA-assigned
>    OBJECT IDENTIFIER values recorded in the SMI Numbers registry:
>
>    Descriptor     OBJECT IDENTIFIER Value
>    ----------     -----------------------
>    docsIfMib    { mib-2 transmission 127 }

I wouldn't write it this way. This object ID has already been assigned by IANA, so this isn't an IANA action for *this* document.

Bert said:
>  The missing IANA considerations is not good.
>  Section should say that there are no (new) IANA actions to be 
> performed

You said:
> see above

I would keep the IANA Considerations section very simple, per <http://www.ietf.org/ID-Checklist.html#anchor4>. I would include only one sentence like "This document has no actions for IANA" or "There are no new IANA actions to be performed for this document".

We cannot omit this section. But we don't need IANA to do any new work, either. :^)

-- Rich

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Wednesday, February 02, 2005 5:50 PM
To: Wijnen, Bert (Bert); Jean-Francois Mule; Woundy, Richard; [email-masked]
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib - 2670bis

Comments with >>

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

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Wednesday, December 29, 2004 9:30 AM
To: Jean-Francois Mule; Richard Woundy @ Comcast; [email-masked]; Eduardo Cardona
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib - 2670bis

Sorry that it took a (long) while to do AD review.

Here are my comments:

- my findref tool (prelimenary, borrowed from RFC-Editor) says:

  !! Missing Reference for citation: [RFC2670]
     P122 L050:      interfaces" [RFC2670].
>> will add in normative section

  !! Missing citation for Normative reference:
     P123 L048:     [RFC3291] Daniele, M., Haberman, B., Routhier, S.,
Schoenwaelder,

>> added in IMPORTS section
     InetAddressType,
     InetAddress
             FROM INET-ADDRESS-MIB  --[RFC3291]

- my idnits tool, available from:
           http://ietf.levkowetz.com/tools/idnits/
  tells me:

  $ idnits draft-ietf-ipcdn-docs-rfmibv2-12.txt
  idnits 1.58

  draft-ietf-ipcdn-docs-rfmibv2-12.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
    Checking conformance with RFC 3667/3668 boilerplate...

Added x. IANA Considerations
    The MIB module in this document uses the following IANA-assigned
    OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

    Descriptor     OBJECT IDENTIFIER Value
    ----------     -----------------------
    docsIfMib    { mib-2 transmission 127 }
    
  * The document seems to lack an RFC 3668 Section 5, para 1 IPR Disclosure
    Acknowledgement --
    however, there's a paragraph with a matching beginning. Boilerplate error?
>> will restructure
   x. Copyright Statement
    Acknowledgment
  * The document seems to lack an RFC 3668 Section 5, para 2 IPR Disclosure
    Acknowledgement.
Will add
     x.Intellectual Property

  * There are 2 instances of lines with non-ascii characters in the document.

>> In the process to transfer the old RTF file to XML ID (identified
>> 0x96 istead of 0x2D '-'
  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:

  - Line 501 has weird spacing: '...astPkts  inter...'
  - Line 561 has weird spacing: '...astPkts   inte...'
  - Line 772 has weird spacing: '...astPkts  inter...'
  - Line 843 has weird spacing: '...astPkts   inte...'
  - Line 919 has weird spacing: '...astPkts   inte...'
  - (1 more instance...)

>> do not see it in IETF.org stored ID
Lines numbers do not match the ...UcastPkts  ? 
Will run awk scripts when done with new ID

    Run idnits with the --verbose option for more detailed information.
  
  The missing IANA considerations is not good.
  Section should say that there are no (new) IANA actions to be performed

>> see above

  one of non-ascii characters are in the MIB MODULE. not good for
compilation
    C:\bwijnen\smicng\work>smicmfm ipcdnDocsIfMIB.mi2
    E: f(ipcdnDocsIfMIB.mi2), (36,41) Syntax error
    ** 1 error and 0 warnings in parsing

  line 36 is the line
           LAST-UPDATED    "200411221700Z" \xFB- November 22, 2004

  after fixing that, compile goes reasonably. except for

    W: f(rfmibv2.mi2), (4948,1) OBJECT-GROUP "docsIfObsoleteGroup" is not
used
       in a MODULE-COMPLIANCE in current module

  now that was already the case in RFC2670. Strange but such is life.
  Might be good to add a ASN.1 comment about it so we know it has existed
  for a long time.

>> will add after :
-- conditionally mandatory group
GROUP docsIfCmtsGroup

The group reference, 

-- obsolete group
-- RFC 2670 already had a obsolete group, even though RFC2670 
-- was the first version of this MIB Module

GROUP docsIfObsoleteGroup
     DESCRIPTION
         "This group contains obsolete objects."

- Next I did run smidiff:

  $ smidiff -s -l 6 -m -inamelength-32 ..\ietf\DOCS-IF-MIB ./DOCS-IF-MIB 
       >docs-if-mib-diff.txt

  I have attached the doc-if-mib-diff.txt file for your perusal... pls check
  in detail to make sure that all the changes are indeed intentional.
>> OK REFERENCES, DESCRIPTIONS, UNITS, new Objects,

  What I find serious issues in there (and those that I checked in
  more detail) is the following:

1. You have removed and then re-added docsIfObsoleteGroup
   That was kind of OK if the OID that you used woul have been the same,
   but it changed from the last subid of 4 to 5.
   This is forbidden accoring to SMI rules. Why was this done?

>> no clue, 
docsIfObsoleteGroup OBJECT-GROUP       ::= { docsIfGroups 5 } --> back to 4

2. ./DOCS-IF-MIB:2988 [3] {range-changed} range of type used in 
   `docsIfCmtsModPreambleLen' changed from `(0..1024)' to `(0..1536)'

   That is acceptable, but since this is a read-create object, you must
   change the old MODULE-COMPLIANCE statement (i.e. the one you deprecated)
   to describe this OBJECT-TYPE with a limited range. For example:

    OBJECT  docsIfCmtsModPreambleLen
        SYNTAX Integer32 (0..1024)
        DESCRIPTION
            "The range of the values for this MODUL-COMPLIANCE is 0..1024."

   without it, old implementations claiming docsIfBasicCompliance would
   all of a sudden have to support the new values 1025..1536 as well.
>> good hint, done

3. ./DOCS-IF-MIB:3018 [3] {range-changed} range of type used in 
   `docsIfCmtsModFECErrorCorrection' changed from `(0..10)' to `(0..16)'

   That is acceptable, but since this is a read-create object, you must
   change the old MODULE-COMPLIANCE statement (i.e. the one you deprecated)
   to describe this OBJECT-TYPE with a limited range. For example:

    OBJECT  docsIfCmtsModFECErrorCorrection
        SYNTAX Integer32 (0..10)
        DESCRIPTION
            "The range of the values for this MODUL-COMPLIANCE is 0..10."

   without it, old implementations claiming docsIfBasicCompliance would
   all of a sudden have to support the new values 11..16 as well.
>> OK

4. I see that docsIfCmtsModType has a number of values/enumerations added.
   The old MODULE-COMPLIANCE statement has not changed, sofar sogood
   But the new MODULE-COMPLIANCE does not list this object. So can all
values
   (including other(1)) be written ???

>> That's a good Q.

Updated based on requirements of RFI spec sec 6.2.3

OBJECT docsIfCmtsModType
     WRITE-SYNTAX      INTEGER {
         qpsk(2),
         qam16(3),
         qam64(6)
     }
     DESCRIPTION
         "Management station MAY only set 64QAM, 16QAM or QPSK 
		  modulation for Time or Code division Multiple Access,
		  but others might be possible based on device
          configuration."

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? 

6. ./DOCS-IF-MIB:2414 [5] {named-number-added} warning: named number
`operational'
   added to type used in `docsIfCmtsCmStatusValue'
   ./DOCS-IF-MIB:2414 [5] {named-number-added} warning: named number 
   `registeredBPIInitializing' added to type used in
`docsIfCmtsCmStatusValue'

   That is OK sinmce it is a read-only object. So when an existing
implementation
   does not return the new values, it is still compliant with old
MODULE-COMPLIANCE

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.

8. ./DOCS-IF-MIB:278 [5] {named-number-added} warning: named number 
   `taps12increment17' added to type used in `docsIfDownChannelInterleave'

   is OK since it already has specific syntax in old MODULE-COMPLIANCE
>>OK 
9. ./DOCS-IF-MIB:457 [3] {range-changed} range of type used in
   `docsIfUpChannelWidth' changed from `(0..20000000)' to `(0..64000000)'

   is OK since there is already specific syntax in MODULE-COMPLIANCE
   statements
>> OK

Other comments:

- for object: docsIfCmtsQosProfilePermissions I see:
            "This object specifies permitted methods of creating
             entries in docsIfQosProfileTable.
             CreateByManagement(0) is set if entries can be created
             using SNMP.  UpdateByManagement(1) is set if updating
             entries using SNMP is permitted.  CreateByModems(2)
             is set if entries can be created based on information
             in REG-REQ MAC messages received from Cable Modems.
             Information in this object is only applicable if
             docsIfQosProfileTable is implemented as read-create.
             Otherwise, this object is implemented as read-only
             and returns CreateByModems(2).
             Either CreateByManagement(0) or CreateByModems(1)
             MUST be set when writing to this object.
             Note that BITS objects are encoded most significant bit
             first.  For example, if bit 2 is set, the value of this
             object is the octet string '20'H."

  1. The values start with lowercase. So it would be better to be
     consistent when using the names/labels of the values.
>>ok will update 
  2. I see "Either CreateByManagement(0) or CreateByModems(1)"
     but the valie for "createByModems" is actually 2 and not 1.
     You either want to fix it to 2, but probably you mean
     "updateByManagement(1)" ?? 
>> correct,  updateByManagement(1)
  3. If the latter,m does that mean that one cannot do a SET for
     "createByModems" ?? If so, then a WRITE-SYNTAX in the 
     MODULE-COMPLIANCE is the way to express that machine readable.
>> ok both compliances updated.
OBJECT  docsIfCmtsQosProfilePermissions
     WRITE-SYNTAX     BITS {
         createByManagement(0),
         updateByManagement(1),
        }
	 MIN-ACCESS  read-only
     DESCRIPTION
         "It is compliant to implement this object as read-only."

- 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:
1) Deprecated objects:
docsIfQosProfMaxTxBurst OK (has explanation)
docsIfCmtsCmStatusIpAddress OK
docsIfCmtsServiceCmStatusIndex OK
- docsIfCmtsCmStatusValue OBJECT-TYPE

Obsoleted objects (obsoleted by RFC 2670 even though first version ) 
docsIfRangingResp - there is text description
( comments above the object explaining the obsolecence) 
moved to description of obsoleted object

docsIfCmtsInsertionInterval -same case
moved explanations to DESCRIPTION clause

2) (*) Long Story... It was around draft 8 a spec ECR to update the MIB with
value complete.
As final value after Cmis 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 }

- I do not understand (page 104):

  --
  -- RFC XXXX Conformance definitions
  --
  --    ************************************************************
  --    * NOTES TO RFC Editor (to be removed prior to publication) *
  --    *                                                          *
  --    *  replace XXXX with the IANA assigned RFC number          *
  --       of this document                                        *
  --    *                                                          *
  --    ************************************************************

  docsIfCompliancesV2  OBJECT IDENTIFIER     ::= { docsIfConformance 3 }
  docsIfGroupsV2       OBJECT IDENTIFIER     ::= { docsIfConformance 4 }

  That is... why do you want to add an extra level here?
  The above 2 do not seem needed in my view. Not that it is an error,
  it is just extra "baggage" so to speak that (I think) serves no
  purpose. Or am I missing something?

>> Fair, Will leave in one unique  branch
That was the decision back in 2003 Feb meeting, no issues on revisiting the
cases.

  The following then is more a RFC2670 definition... if you really want
  to make reference to an RFC.

  docsIfBasicCompliance MODULE-COMPLIANCE
        STATUS      deprecated
        DESCRIPTION
            "The compliance statement for devices that implement
             MCNS/DOCSIS compliant Radio Frequency Interfaces."

Changed with:

  docsIfBasicCompliance MODULE-COMPLIANCE
        STATUS      deprecated
        DESCRIPTION
            "The compliance statement for devices that implement
             DOCSIS 1.x compliant Radio Frequency Interfaces."

And... 
docsIfBasicComplianceV2 MODULE-COMPLIANCE
     STATUS      current
     DESCRIPTION
         "The compliance statement for devices that implement
          DOCSIS 2.0 Radio Frequency Interfaces."

- This: docsIfCmtsOptionalGroupV2 OBJECT-GROUP
  is really a bad name for an OBJECT-GROUP.
  The fact that a group is optional of not is something that you express
  in the MODULE-COMPLIANCE. The OBJECT-GROUP macro is just to logically
  group objects together. The DESCRIPTION clause is also weird:
       DESCRIPTION
           "Group of objects implemented optionally in Cable Modem
            Termination Systems."
  I would rather see you describe what "logical group of objects" it
  is. FOr example: 
      "This is a group of counters to monitor mini-slots. These can
       be implemented in Cable Modem Termination Systems."
  Might even want to explain what mini-slots are (for the novice reader).

>> Lately** DOCSIS spec made those counters mandatory 
The reason for the optional group was to separate that implementation

--> This may appears like a technical change (for the implementation
implications)
, but can be seen as a Conformance update with the current interface
implementation.
  **non-intentional delay on solving this issues, but help in the way to go
forward.
  
- doc header states:     Obsoletes: RFC 2670
  but abstract says:
   This document revises RFC 2670.  Please see section 10 for a
   description of the changes from RFC 2670.
  Make sure that the abstract also states that this doc obsoletes 2670.

>> 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....)

- I see in docsIfUpstreamChannelEntry

             For DOCSIS 1.x CM/CMTSs and DOCSIS 2.0 CMs, an entry in
             this table exists for each ifEntry with an ifType of
             docsCableUpstreamInterface (129)."

  while the real label in the IANAifType-MIB is docsCableUpstream (129)

>> ok.

- 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 (?)

- your heading (page heading) dates are out of sync with the front page
  date.
Ok ( moving to the XML template so it won't be an iussue anymore )

- In Security COnsiderations:
           The table docsIfCmtsCmStatusTable also contain the MAC and IP
           addresses of the cable modems that cam be used of thief of
           service and IP spoofing.

  s/cam/can/
  "of thief of.." ??? is it "for theft of.." ??
>> updated to 

           The table docsIfCmtsCmStatusTable also contain the MAC and IP
           addresses of the cable modems that can be used for theft of
           service and suscribers IP spoofing.

I still need to sit down and try to understand all the MIB objects.

Bert
> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Friday, October 29, 2004 22:51
> To: [email-masked]; [email-masked]
> Cc: Richard Woundy @ Comcast
> Subject: [ipcdn] request for ID publication: DOCSIS RFIv2 mib
> - 2670bis
> 
> 
> We would like to request formal publication for the ID
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmib
> v2-11.txt.
> 
> Bert, please approve - see status below.
> 
> Jean-François
> 
> > -----Original Message-----
> > From: Jean-Francois Mule
> > Sent: Thursday, October 28, 2004 3:55 PM
> > To: [email-masked]
> > Cc: Eduardo Cardona; [email-masked]; [email-masked]
> > Subject: RE: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis
> > 
> > 
> > Just to close the loop on this mib, we received no comments
> > on this post. It is therefore our intent to request its publication.
> > 
> > -- Rich and Jean-Francois.
> > 
> > > -----Original Message-----
> > > From: Jean-Francois Mule
> > > Sent: Wednesday, October 06, 2004 1:57 PM
> > > To: [email-masked]
> > > Cc: Eduardo Cardona; [email-masked]
> > > Subject: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis
> > > 
> > > 
> > > 
> > >    This note provides a brief status update on the ipcdn
> > DOCSIS RFIv2
> > > mib Internet-Draft. It is also a follow-up from the IETF
> > meeting #60
> > > in San Diego.
> > > 
> > > --- Brief status
> > > The current ID is draft-ietf-ipcdn-docs-rfmibv2-11.
> > >  
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmib
> v2-11.txt
> A working group last call was issued on 1/23/2004 and ended
> on 2/6/2004. The authors believe that draft 11 does address 
> all the wg comments as well as AD review comments from Bert. 
> Based on the input received this week from the authors and 
> the current editor Eduardo, no new comments have been 
> received since the ID was revised at the end of July 2004.
> 
> --- San Diego wg meeting follow-up
> Based on our meeting minutes at
http://www.ietf.org/proceedings/04aug/171.htm#rfimib , we wanted to ping the
mailing list to see if another WGLC is needed. If you think a second WGLC
should be issued, please let the ipcdn wg know by sending an email to the
list by Wednesday October 13, 5pm ET.

--- Next steps
Pending wg consensus that a new WGLC is not needed and no objection to move
this ID forward, it is the wg chairs intent to submit the ID for
publication/IESG review to Bert.

Rich and Jean-Francois.
IPCDN co-chairs

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

---

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

Comments with >>

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Wednesday, December 29, 2004 9:30 AM
To: Jean-Francois Mule; Richard Woundy @ Comcast; [email-masked]; Eduardo Cardona
Cc: Ipcdn (E-mail)
Subject: RE: [ipcdn] request for ID publication: DOCSIS RFIv2 mib - 2670bis

Here are my comments:

  !! Missing citation for Normative reference:
     P123 L048:     [RFC3291] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder,

     InetAddressType,
     InetAddress

    
   x. Copyright Statement
    Acknowledgment
Will add
     x.Intellectual Property

>> In the process to transfer the old RTF file to XML ID (identified 0x96 istead of 0x2D '-'

  Miscellaneous warnings:

  

>> see above

  one of non-ascii characters are in the MIB MODULE. not good for compilation
    C:\bwijnen\smicng\work>smicmfm ipcdnDocsIfMIB.mi2
    E: f(ipcdnDocsIfMIB.mi2), (36,41) Syntax error
    ** 1 error and 0 warnings in parsing

  line 36 is the line

    W: f(rfmibv2.mi2), (4948,1) OBJECT-GROUP "docsIfObsoleteGroup" is not used
       in a MODULE-COMPLIANCE in current module

The group reference, 

-- obsolete group

4. I see that docsIfCmtsModType has a number of values/enumerations added.
   The old MODULE-COMPLIANCE statement has not changed, sofar sogood
   But the new MODULE-COMPLIANCE does not list this object. So can all values
   (including other(1)) be written ???

OBJECT docsIfCmtsModType
     WRITE-SYNTAX      INTEGER {
         qpsk(2),
         qam16(3),
         qam64(6)
     }
     DESCRIPTION

   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.

6. ./DOCS-IF-MIB:2414 [5] {named-number-added} warning: named number `operational'
   added to type used in `docsIfCmtsCmStatusValue'
   ./DOCS-IF-MIB:2414 [5] {named-number-added} warning: named number 
   `registeredBPIInitializing' added to type used in `docsIfCmtsCmStatusValue'

   That is OK sinmce it is a read-only object. So when an existing implementation
   does not return the new values, it is still compliant with old MODULE-COMPLIANCE

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

Other comments:

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

        SYNTAX      INTEGER {
            other(1),
            ranging(2),
            rangingAborted(3),
            rangingComplete(4),
            ipComplete(5),
            registrationComplete(6),
            accessDenied(7),

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

Two parts:
1) Deprecated objects:

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

>> Fair, Will leave in one unique  branch
That was the decision back in 2003 Feb meeting, no issues on revisiting the cases.

Changed with:

And... 

--> This may appears like a technical change (for the implementation implications)
, but can be seen as a Conformance update with the current interface implementation.
  **non-intentional delay on solving this issues, but help in the way to go forward.

- The MIB module states:

        REVISION        "200411221700Z"
        DESCRIPTION

>> 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.

  s/cam/can/

Bert
> Based on our meeting minutes at
http://www.ietf.org/proceedings/04aug/171.htm#rfimib , we wanted to ping the mailing list to see if another WGLC is needed. If you think a second WGLC should be issued, please let the ipcdn wg know by sending an email to the list by Wednesday October 13, 5pm ET.

--- Next steps
Pending wg consensus that a new WGLC is not needed and no objection to move this ID forward, it is the wg chairs intent to submit the ID for publication/IESG review to Bert.

Rich and Jean-Francois.
IPCDN co-chairs

---

From: "Eduardo Cardona" <[email-masked]>
Date: Sun, 6 Feb 2005 23:42:38 -0700

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:

>> 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'

   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.

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

Other comments:

- 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),

   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

- The MIB module states:

        REVISION        "200411221700Z"
        DESCRIPTION

  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.