Event Notification Management Information Base for Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems
draft-ietf-ipcdn-docsisevent-mib-06

New revision still has issues:
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Monday, January 10, 2005 20:23
To: Jean-Francois Mule
Cc: Richard Woundy @ Comcast; RWoundy@broadband.att.com;
azlina@protegonetworks.com; gnakanishi@motorola.com; Ipcdn (E-mail)
Subject: RE: New Version Notification -
draft-ietf-ipcdn-docsisevent-mib-05.txt


I get:
  !! Missing citation for Normative reference:
  P039 L042:    [10]  SCTE Data Standards Subcommittee, "Data-Over-Cable Service

I could fix theat with an RFC-Editor note if you tell me where to insert the citation.

On page 37:
  It is RECOMMENDED that implementers consider the security features as
  provided by the SNMPv3 framework (see [RFC3410], section 8),
  including full support for the SNMPv3 cryptographic mechanisms (for
  authentication and privacy).
Causes:
  !! Missing Reference for citation: [RFC3410]
  P038 L017:    provided by the SNMPv3 framework (see [RFC3410], section 8),

I could fix that with an RFC-Editor note.

It makes me wonder if all references are in sync with the citations.
Someone, please check and send a positive acknowledgement that you HAVE checked
them all and that they are OK.

But I still see:
  docsDevCmNotifCompliance MODULE-COMPLIANCE
      STATUS current

      DESCRIPTION
      "The compliance statement for CM Notifications and Control"

      MODULE --docsDevNotif
      --mandatory groups

          GROUP docsDevCmNotifControlGroup
          DESCRIPTION
              "Mandatory in CM."

          GROUP docsDevCmNotificationGroup
          DESCRIPTION
              "Mandatory in CM."

      ::= { docsDevNotifCompliances 1 }

And I thought we had agreed that you would change it to:

  docsDevCmNotifCompliance MODULE-COMPLIANCE
      STATUS current

      DESCRIPTION
      "The compliance statement for CM Notifications and Control"

      MODULE --docsDevNotif
          MANDATORY-GROUPS {
              docsDevCmNotifControlGroup,
              docsDevCmNotificationGroup
          }
      ::= { docsDevNotifCompliances 1 }

What am I missing?

And also:
  docsDevCmtsNotifCompliance MODULE-COMPLIANCE
      STATUS current
      DESCRIPTION
          "The compliance statement for DOCSIS CM and CMTS."
      MODULE --docsDevNotif
      --mandatory groups

          GROUP docsDevCmtsNotifControlGroup
          DESCRIPTION
              "Mandatory in CMTS."

          GROUP docsDevCmtsNotificationGroup
          DESCRIPTION
              "Mandatory in CMTS."

      ::= { docsDevNotifCompliances 2 }

should be (possibly) be (but see my questions):

  docsDevCmtsNotifCompliance MODULE-COMPLIANCE
      STATUS current
      DESCRIPTION
          "The compliance statement for DOCSIS CM and CMTS."

bw asks: is it really for CM and CMTS or only for CMTS?

      MODULE --docsDevNotif
          MANDATORY-GROUPS {
              docsDevCmtsNotifControlGroup,
              docsDevCmtsNotificationGroup
          }
      ::= { docsDevNotifCompliances 2 }

if it is both for CM and CMTS, then you seem to be telling me that it is
optional for CM. So maybe this one should be just for CMTS (with just
mandatory groups) and then the first MODULE-COMPLIANCE should have these
2 groups added as optional groups!?

If this is just for CMTS, then the DESCRIPTION clause should say so and then my
suggested change is the proper way to specify it.

You have put this
  Note that notifications are also under the control of the MIB modules
  defined in RFC 3413 [17].
In the security COnsiderations section. That is not a secuurity concern (I think).
Rather it is something to describe (I think) in the DESCRIPTION clauses of
docsDevCmNotifControl and docsDevCmtsNotifControl.

W.r.t. Persistency of the writable objects you have added:
        If the device is rebooted, the value of this object should revert
        to the default value.
which meets my concern.
It is something however that you and the WG chairs may want to make sure that
the WG agrees with.

Bert

AD review comments/questions:

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Tuesday, December 28, 2004 18:11
To: Nakanishi Greg-MGI8179; 'Jean-Francois Mule'
Cc: Comcast""@az33exr02.mot.com;
Harrie Hazewinkel (E-mail)
Subject: RE: PING - AD review: draft-ietf-ipcdn-docsisevent-mib-04.txt


Sorry for very late response.
Using the holidays to catch up.

OK, I was surprised to not yet see the updates included,
but I now see you were waiting for potentially more review
comments from me.

- Note that the same comemnt (as in below email) is also true
  for the otehr MODULE-COMPLIANCE.

- I wonder why you do:
      docsDevNotifs OBJECT IDENTIFIER ::= { docsDevNotifMIB 1 }
  it just inserts an extra subId of 1 into all notifications and objects
  does it not?

- The idnits program, see: http://ietf.levkowetz.com/tools/idnits/

  tells me:

  $ idnits draft-ietf-ipcdn-docsisevent-mib-04.txt
  idnits 1.58

  draft-ietf-ipcdn-docsisevent-mib-04.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...
    the boilerplate looks good.
  * There are 12 instances of too long lines in the document, the longest one being 6
    characters in excess of 72.

  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:

    None.

    Run idnits with the --verbose option for more detailed information.

- Checking references I find:

  !! Missing citation for Informative reference:
  P039 L040:    [15]  Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 

  !! Missing citation for Normative reference:
  P038 L042:    [6]  Raftus, D., "Radio Frequency (RF) Interface Management

  !! Missing citation for Normative reference:
  P038 L049:    [7]  SCTE Data Standards Subcommittee, "Data-Over-Cable Service

  !! Missing citation for Normative reference:
  P039 L006:    [8]  CableLabs, "Baseline Privacy Plus Interface Specification

  !! Missing Reference for citation: [RFC3410]
  P038 L007:    provided by the SNMPv3 framework (see [RFC3410], section 8),

- In sect 1 I see:
    RFC 3410 [2].
  and
      RFC 2578 [2],
  seems conflicting citation

- I see reference:
  [9]  SCTE Data Standards Subcommittee, "Data-Over-Cable Service
        Interface Specifications: DOCSIS 1.0 Operations Support System
        Interface Specification Radio Frequency Interface SCTE 22-3",
        2002, .

  but on that web page I do not see a ptr to SCTE 22-3 ??

- I see
  [8]  CableLabs, "Baseline Privacy Plus Interface Specification
        SP-BPI-020830", August 2002,
        .
  but have trouble finding the SP-BPI-020830 ???

- Please check all references, I have not done them all


- I see no normative reference to RFC2863.
  All MIB documents that you IMPORT from must have a normative reference.
  You can do something like:

  OLD:

  4.  Definitions

  DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB DEFINITIONS ::= BEGIN

  NEW:

  4.  Definitions

  The MIB module defined here IMPORTs from the IF-MIB [RFC2863] and xxx

  DOCS-IETF-CABLE-DEVICE-NOTIFICATION-MIB DEFINITIONS ::= BEGIN

- In the Security COnsiderations section you have:

  network operations.  These are the tables and objects and their
  sensitivity/vulnerability:

Is it proper englis to then start a sentence as follows:

  Setting docsDevCmNotifControl or docsDevCmtsNotifControl (defined in
  RFC 2669) may cause flooding of notifications, which can disrupt
  network service.

  While it seems to me you have defined docsDevCmNotifControl and
  docsDevCmtsNotifControl in this MIB document !!??

  And anyway these are the only 2 writable objects in this MIB module.
  no tables! You may want to adapt the text a little bit.

  Besides causing "flooding", changing the objects can also mean that
  notifications will not be emitted while one intended that to happen.


- Pls state in the DESCRIPTION clauses of docsDevCmNotifControl and
  docsDevCmtsNotifControl what you want the persistency behaviour to be

  The Notifications are further under control of the MIB modules in
  RFC 3413, and you may want to say a few words about that and make
  a reference to that RFC.

Those are my additional comments.

Pls address and submit a new rev.

Next step is then most probably to do anm IETF Last Call and
then onto IESG agenda.

Bert