[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn