Subject: [ipcdn] More comments on the PacketCable MTA MIB

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 18 Mar 2003 22:29:55 -0700

Folks,

Here are some additional comments on the PacketCable MTA MIB.

Many of these comments can be traced back to sections in the "Guidelines for
MIB Authors and Reviewers",
<http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-01
.txt>. All references to the "Guidelines" will be to that document.

- Please keep the width of the ASCII format of the draft to 72 characters.
My copy of the draft has a width of 73 characters, which includes trailing
spaces. I'll admit this is closer than the other two PacketCable drafts.
- The "Abstract" section is not supposed to be numbered, and is not supposed
to contain any references, e.g. "[5][6][7]". See Guidelines Appendix A, item
2.
- The first and third paragraphs of the "Abstract" can be deleted. The first
paragraph is irrelevant, and the third paragraph is redundant with the
"Management Framework" section. See draft-ietf-ipcdn-subscriber-mib-10.txt
for a recent example of a good Abstract.
- Change "The SNMP Management Framework" to "The Internet-Standard
Management Framework", and follow the MIB boilerplate in
<http://www.ops.ietf.org/mib-boilerplate.html>. You may wish to delete a
number of References as a result. See Guidelines Appendix A, item 3.
- There is a non-ASCII character in the definition of Public Key
Certificate: "entityÆs" should be "entity's". This appears to be a Microsoft
Word artifact.
- The DHCP definition should refer to RFC 2131. The FQDN definition should
refer to RFCs 1034 and 1035; RFC 821 describes the format of the entire
endpoint name, not just the FQDN. The Security Association definition should
refer to RFC 2401. Perhaps these RFC references should be added to the
"Information References" section?
- The CMS definition probably should refer to "MTAs" rather than to "TAs".
- The text in section 4.1 should be cleaned up. There needs to be stronger
correlation between the objects in pktcMtaDevServer and the new RFC 3495 for
the DHCP CCC option -- which should be in the Normative References section.
Note that pktcMtaDevServerDns1 and pktcMtaDevServerDns2 needs to be
reconciled with a variable number of domain name servers possible in DHCP
option 6 -- note that it might be OK to retain these two objects (it seems
overkill to add a table for this management issue).
- Assuming that the WG accepts my comments on table indexing for the
RealmTable and CmsTable, text in section 4.2 concerning "Realm Table to CMS
Table Relationship" will need to be revised.
- In the MODULE-IDENTITY, please update my contact information to
"[email-masked]".
- The MODULE-IDENTITY should include the new copyright clause. See
Guidelines section 3.8.
- Our IPCDN MIBs should not define a TEXTUAL-CONVENTION called
X509Certificate -- the name is too generic for the usage in our WG. At the
interim meeting <http://www.ipcdn.org/meetings/ipcdn-minutes-021303.html>,
Bert Wijnen suggested using a name such as DocsX509ASN1DEREncodedCertificate
for the BPI+ MIB. Should that TEXTUAL-CONVENTION (when it is included in a
revised DOCSIS BPI+ MIB) be imported into this MIB? Is there a reason that
the BPI+ MIB X.509 certificate can be up to 1400 bytes, but the MTA MIB
X.509 certificate can be up to 4096 bytes???
- Many comments in the MIB need to be fixed, so that the comment text is on
the same line as the "--" indicator.
- Is the value of pktcMtaDevMacAddress already captured in ifPhysAddress? So
is this MTA MIB object redundant?
- Objects such as pktcMtaDevEndPntCount should use SYNTAX "Unsigned 32
(1..255)" rather than "Integer32 (1..255)". This also applies to
pktcMtaDevProvisioningTimer, pktcMtaDevErrorOidIndex, and quite a few other
objects. See Guidelines section 4.6.1.1.
- Some folks in the WG have had a dispute about the use of DEFVAL clauses
for scalar objects such as pktcMtaDevProvisioningTimer and a number of other
objects. I already asked one MIB doctor at the IETF who wasn't sure about
the answer. This needs to be resolved.
- Is it important that pktcMtaDevProvisioningCounter reflect a count "since
the last reboot"? If so, you need to use ZeroBasedCounter32 from RMON2-MIB
instead. See Guidelines section 4.6.1.2.
- Why does pktcMtaDevErrorOid use the SYNTAX SnmpAdminString, when it could
use the SYNTAX OBJECT IDENTIFIER from RFC 2578 section 7.1.3?
- The object pktcMtaDevErrorValueGiven seems somewhat odd, in that it might
encode a value of any SYNTAX type. But maybe this is correct. We might need
to ask a real MIB doctor here.
- The DESCRIPTION clauses for pktcMtaDevServerDns1 and pktcMtaDevServerDns2
need to be revised to refer to DHCP option 6, for alignment with RFC 3495.
- The DESCRIPTION of pktcMtaDevConfigFile assumes a TFTP URL format, which
won't be approved until draft-lear-tftp-uri-02.txt is approved. This draft
has been stuck in Area Director review for about a year.
- The SYNTAX of pktcMtaDevProvKerbRealmName is SnmpAdminString, which
supports UTF-8 format as well as ASCII format. The DESCRIPTION refers
specifically to "upper case ASCII representation". Wouldn't it be sufficient
to state that the value of this object must match the value of
pktcMtaDevRealmName in the appropriate RealmTable row?
- It may be worth investigating whether multiple InetAddressType objects are
needed in this MIB. We might be able to define a single
pktcMtaDevServerAddressType object that is shared by multiple MTA MIB
objects (e.g. pktcMtaDevServerDhcp1), rather than defining individual
objects (e.g. pktcMtaDevServerDhcp1AddressType). Objects with SYNTAX
InetAddress (e.g. pktcMtaDevServerDhcp1) need to refer to the appropriate
InetAddressType object in their DESCRIPTION clauses.
- The SYNTAX of pktcMtaDevCorrelationId should be "Unsigned (0..4294967295)"
instead of "Integer32"; see Guidelines section 4.6.1.1.
- Please consider changing the indexing of the RealmTable and CmsTable per
my recent email. That also implies that you might relax the constraint on
"upper case ASCII representation" for the pktcMtaDevRealmName object. Also
see the discussion about table indexing and the dangers of long OIDs in
Guidelines section 4.6.5.
- For the pktcMtaDevRealmOrgName object, does this refer to the Service
Provider CA Certificate as defined in the PacketCable Security Spec? Is the
"organization name attribute" equal to what follows "O=" in the Subject
Name? Why is this encoded as SYNTAX "OCTET STRING (SIZE (1..64))" instead of
"SnmpAdminString"? Where does the assumption about a 64 byte organization
name come from???
- REFERENCE clauses should not contain numeric references (such as [18]),
because the context for such numeric references are lost when the MIB is
extracted from the draft/RFC.
- The RowStatus objects for the RealmTable and CmsTable may need some
additional DESCRIPTION text. If any columns MUST to be populated before the
row is activated, that has to be described in the status object. Also, the
object MUST describe whether other column values can be changed when the row
status is active. See Guidelines section 4.6.3.
- We need to add StorageType objects to the RealmTable and CmsTable;
alterbatively, each table entry DESCRIPTION clause MUST specify what happens
to dynamically-created rows after an MTA restart. Since Kerberos tickets
might or might not persist beyond an MTA restart, we might not be able to
declare the RealmTable rows to be volatile in all circumstances. See
Guidelines section 4.6.3.
- Sections 6, 7, and 8 could be better formatted (this is a nit about line
feeds).
- The references MUST be split into Normative and Information Reference
sections. See Guidelines Appendix A, item 5. The split of Normative and
Information References for the MIB boilerplate language is defined in
<http://www.ops.ietf.org/mib-boilerplate.html>.
- The references [1] through [4], and [8] through [16], could be deleted.
They were required by the old MIB boilerplate. I don't think you need to
include reference [20] in order to describe an SNMP Inform PDU; the
boilerplate should take care of this.
- Please clean up the text of references [17] through [19].
draft-ietf-ipcdn-subscriber-mib-10.txt and draft-ietf-ipcdn-qos-mib-08.txt
are good models to start with.
- Please rewrite the "Security Considerations" according to the MIB Security
Considerations boilerplate in <http://www.ops.ietf.org/security.html>. You
should consider which read-write/read-create and read-only objects should be
considered sensitive and why. See some of the more mature DOCSIS MIBs for
some examples.
- The "Full Copyright Statement" uses the year "2001" for a 2002 draft.

-- Rich

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