RE: MIB reviewer comments on draft-ietf-ipcdn-device-mibv 2-06.txt

Randy,

Thanks for your detailed review. There is a lot I need to go over.

My plan is to respond to these comments (to you and the mailing list) by
Thursday December 4th. My intent is to generate a revision of the draft
incorporating these comments (and a few others) by mid-December.

- Rich

-----Original Message-----
From: Randy Presuhn [mailto:[email protected]]
Sent: Saturday, November 22, 2003 3:08 AM
To: [email protected]
Subject: [ipcdn] MIB reviewer comments on
draft-ietf-ipcdn-device-mibv2-06.txt


Hi -

Here are my comments on draft-ietf-ipcdn-device-mibv2-06.txt
I recognize that this is based on an earlier RFC and external
specifications, thus some of the "shoulds" you may choose
to ignore.

First the more-or-less mechanical stuff:

Abstract: the language about "draft revision"  and "will
obsolete" wouldn't be appropriate if this is to be published
as an RFC.  Should be replaced with words that will be true
when it becomes an RFC.

Intellectual Property: BCP-11 is missing from the references.

Table of contents:
  - many of the page numbers are wrong
  - the section titles in the table of contents sometimes
    don't match the actual section titles.

Items based on http://www.ietf.org/ietf/1id-guidelines.txt:
  - on first page, "Internet Draft" -> "INTERNET-DRAFT"

Items based on http://www.ietf.org/ID-nits.html:
  - missing introduction? (ID-nits.html section 1.2)
    this seems to be in the overview.

Items based on draft-rfc-editor-rfc2223bis-07.txt:
  - Title: the acronynm DOCSIS should be expanded (2223 bis 2.9)
  - Use two spaces after period at the end of a sentence. (2223 bis 3.1.7)
  - some References have "," before the "and", others don't.
    be consistent, using a "," before the "and", as in the
    references section of the guidelines.
  - not consistent in use of "RFCxxxx", "RFC-xxxx", and "RFC XXXX"
  - section 2.4: ITU-T J.112 is missing from the references
  - section 2.7: "MAC" not expanded on first use
  - section 2.7: "PDU" not expanded on first use
  - section 3: "SNMPv1", "SNMPv2c", "SNMPv3" not expanded on first use
  - section 3: spurious blank line before "requirements"
  - section 3: "CPE" not expanded on first use
  - section 3.1: "IGMP" not expanded on first use
  - section 3.2.1: "TFTP" not expanded on first use
  - section 3.2.1: "HTTP" not expanded on first use
  - section 3.2.2: no reference for "syslog"
  - section 3.3: "LLC" not expanded
  - section 3.3: "IPX" not expanded
  - section 3.3: "ICMP" not expanded
  - section 3.3.3: "ToS" not expanded
  - section 3.3.4: "QOS" not expanded
  - section 4: "DSCP" not expanded
  - section 4: "OIDs" not expanded
  - section 4: "VACM" not expanded
  - section 4: "NMS" not expanded
  - section 4: "DHCP" not expanded
  - section 4: "occurrance" -> "occurrence"
  - section 4: "CMCI" not expanded
  - section 4: "SNAP" not expanded
  - section 4: "DSAP" not expanded
  - section 4: "MCNS" not expanded
  - (section 5.1: "simplication" -> "simplification")
  - Table of contents and document in general: sections are not in
    order stipulated by rfc2223bis section 4.

MIB Compilation note:
  smilint produces lots of warnings regarding the fact that several
  of the "current" compliance statements reference "deprecated" groups,
  but this is specifically permitted by the MIB review guidelines
  and RFC 2580, so I'll assume it's intentional.

MIB Review Guidelines:
  ORGANIZATION clause MUST have full name of working group
  (IP over cable data network)

  All REVISION clauses should be updated to four-digit years.

  docsDevMaxCpe: a UNITS clause would be nice.

  docsDevNmAccessTable: should specify what the persistance
  properties of this information are.

  docsDevNmAccessInterfaces: DEFVAL should give the actual
  value, rather than just an ASN.1 comment.  However, since
  this is deprecated and the DESCRIPTION would make the length
  implementation dependent, I won't insist on it.

  docsDevSwServerTransportProtocol: are there any constraints
  on when this can be set to TFTP?  For example, if
  docsDevSwServerAddressType is DNS, must an implementation
  reject attempts to set this to TFTP?

  Can the other docsDevSw* objects be changed when docsDevSwOperStatus
  is "in progress"?

  docsDevServerBootState should explain what enumeration values
  9 and 10 mean.

  docsDevServerDhcpAddressType: what value does this have if
  DHCP was not used?

  docsDevServerTimeAddressType: what value does this have when
  no time server is known?

  docsDevServerConfigTftpAddressType: value if unknown?

  docsDevServerConfigTftpAddress: security considerations should
  address consequences of using TFTP here.

  docsDevEvThrottleThreshold and related objects should address
  the question of just what notifications they apply to.
  If, for example, the system also implemented the Alarm MIB,
  the answer would be of more than academic interest.

  docsDevEvThrottleThreshold: a UNITS clause would be nice

  docsDevEvThrottleInterval: should be Unsigned32.

  docsDevEvControlTable: what is the lifecycle / persistance of
  entries in this table?

  docsDevEvReporting: the DESCRIPTION doesn't mesh with the notion
  of using RFC 3413 where it talks about sending an SNMP trap.

  This bit of text is ambiguous:
             An event reported by trap or syslog logging MUST be
             accompanied by localVolatile logging.  If the bit value
             for either traps(1) or syslog(2) is set, then the agent
             MUST enforce that the bit value for local(0) or
             localVolatile(3) is set as well."
  Is the intent that the agent must reject attempts to do SETs that
  don't satisfy the criteria, or does this text mean that the agent
  must act as though the bits in the request had been set appropriately?

  docsDevEventTable: does stuff in this table persist across reboots?

  docsDevEvIndex should be Unisnged32.

  docsDevEvLastTime and docsDevEvFirstTime: do these get the same
  special values as docsDevDateTime?

  docsDevEvCounts should have UNITS.  Purists might object to
  using a Counter type here.

  docsDevEvLevel should explain what each of the enumeration
  values means.

  docsDevFilterLLCTable should spell out lifecycle / persistence

  docsDevFilterLLCIndex should be Unsigned32

  docsDevFilterLLCIfIndex: if rows in this table can persist across
  reboots, this object has persistence / consistency implications
  with the interfaces table and related objects.  Intent should be
  spelled out here.

  docsDevFilterLLCProtocol should be Unsigned32.

  docsDevFilterLLCMatches should have UNITS.

  docsDevFilterIpTable: should spell out persistance / lifecycle

  docsDevFilterIpIndex: should be Unsigned32.

  docsDevFilterIpIfIndex: if this table can persist across reboots,
  this object has implications for either the satbility of ifIndex
  values or its own renumbering.

  docsDevFilterIpDaddr: it's not quite right to talk about a value
  of "0" for this object, since it's syntactically an OCTET STRING.

  docsDevFilterIpProtocol: should be Unsigned32.
  a REFERENCE clause to the appropriate IANA registry would be nice.

  docsDevFilterIpSourcePortLow , docsDevFilterIpSourcePortHigh,
  docsDevFilterIpDestPortLow, docsDevFilterIpDestPortHigh:
  should be Unsigned32.

  docsDevFilterIpMatches needs UNITS, and syntax should be
  ZeroBasedCounter32.

  docsDevFilterIpPolicyId: should be Unsigned32.

  docsDevFilterPolicyTable: should talk about lifecycle and persistance.

  docsDevFilterPolicyIndex should be Unsigned32
  docsDevFilterPolicyId  should be Unsigned32

  docsDevFilterPolicyStatus use of the RowStatus TC requires
  spelling out what columns are permitted to be modified in
  an active row.

  docsDevFilterPolicyPtr: what happens when this points to
  a row which does not exist?

  docsDevFilterTosTable: lifecycle and persistence.

  docsDevFilterTosIndex: should be Unsigned32.

  docsDevCpeEnroll: what is meant by "manually"?

  docsDevCpeIpMax: may this object be set to a value
  larger than "the maximum permitted for this device"?
  If it weren't for that -1, I'd like to see UNITS.

  docsDevCpeTable: persistance and lifecycle

  docsDevCpeInetTable: persistance and lifecycle

  docsDevCpeInetAddr: these words should probably be tweaked to
  be a bit more protocol-neutral: " N.B. Neither the all zeros
  or all ones addresses may be used as values for this object."

  docsDevCpeInetSource: when is (1) used?

  Security Considerations fails to mention these read-write
  objects:
 docsDevDateTime
 docsDevSTPControl
 docsDevIgmpModeControl
 docsDevSwServer
 docsDevSwFilename
 docsDevSwAdminStatus
 docsDevSwServerAddressType
 docsDevSwServerAddress
 docsDevSwServerTransportProtocol
 docsDevEvControl
 docsDevEvSyslog
 docsDevEvThrottleThreshold
 docsDevEvThrottleInterval
 docsDevEvReporting
 docsDevEvSyslogAddressType
 docsDevEvSyslogAddress
 docsDevFilterLLCUnmatchedAction
 docsDevFilterIpDefault
 docsDevCpeEnroll
 docsDevCpeIpMax
  Security Considerations doesn specifically address these read-create
  objects, although it does talk about their tables in general terms:
 docsDevNmAccessIp
 docsDevNmAccessIpMask
 docsDevNmAccessCommunity
 docsDevNmAccessControl
 docsDevNmAccessInterfaces
 docsDevNmAccessStatus
 docsDevNmAccessTrapVersion
 docsDevFilterLLCStatus
 docsDevFilterLLCIfIndex
 docsDevFilterLLCProtocolType
 docsDevFilterLLCProtocol
 docsDevFilterIpStatus
 docsDevFilterIpControl
 docsDevFilterIpIfIndex
 docsDevFilterIpDirection
 docsDevFilterIpBroadcast
 docsDevFilterIpSaddr
 docsDevFilterIpSmask
 docsDevFilterIpDaddr
 docsDevFilterIpDmask
 docsDevFilterIpProtocol
 docsDevFilterIpSourcePortLow
 docsDevFilterIpSourcePortHigh
 docsDevFilterIpDestPortLow
 docsDevFilterIpDestPortHigh
 docsDevFilterIpTos
 docsDevFilterIpTosMask
 docsDevFilterIpContinue
 docsDevFilterIpPolicyId
 docsDevFilterPolicyId
 docsDevFilterPolicyType
 docsDevFilterPolicyAction
 docsDevFilterPolicyStatus
 docsDevFilterPolicyPtr
 docsDevFilterTosStatus
 docsDevFilterTosAndMask
 docsDevFilterTosOrMask
 docsDevCpeStatus
 docsDevCpeInetRowStatus
 docsDevFilterIpDirection
 docsDevFilterIpBroadcast

   The value assigned to docsDevNotification doesn't meet the
   requirements of the MIB review guidelines section 4.7: it
   needs to end in zero in order for the RFC 2576 algorithms
   to work, if any notifications are ever defined.

Detailed comments:
  editorial:
  section 3 says "Please note that the DOCSIS 1.0 standard only
  requires Cable Modems to implement SNMPv1 and to process
  IPv4 customer traffic.  Design choices in this MIB reflect
  those requirements."  Given the following paragraph, I'd suggest
  replacing these two sentences with something like: "Please
  not that the DOCSIS 1.0 standard only required Cable Models
  to implement SNMPv1 and to process IPv4 customer traffic.
  Design choices in the original version of this MIB reflected
  those requirements."

  technical question:
  section 3.1 is in terms of RFC 1213 system group (though no
  reference is given).  would it make sense to update this to
  the RFC 3418 system group?  (this is what one gets through
  the references to SNMPv3)

  Comment:
  It'd be nice if someone worked out the relationship between
  the docsDevEventGroup, the docsDevEventGroupV2, and RFC 3014
  as well as the current disman Alarm MIB.  I don't think it
  makes sense to delay things now, but someone really should
  figure out how these fit together.

  Section 3.2.1 (use of TFTP) should be addressed in the security
  considerations.  Does the HTTP option provide any protection?

  Page 10: Why is it talking about 24.0.16/255.255.255.0 and
  24.0.16.30?  Are these addresses reserved somewhere?

  Ultra-picky comment: purists would prefer talking about
  "this MIB module" rather than "this MIB".

Randy




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