[Dime] AD review of draft-ietf-dime-diameter-cc-appl-mib-03.txt

["Romascanu, Dan (Dan)" <[e-mail]>]

Please find below the AD review of
draft-ietf-dime-diameter-cc-appl-mib-03.txt. This document is in pretty
good shape, however, there are a number of issues that need to be
clarified and answered before it is sent for IETF Last Call. Please
consider the comments below and address them or clarify the questions
that I have misunderstood. 

Regards,

Dan

Technical Issues

T1. In Section 3: 

-- The
   MIB specification for the Diameter base protocol
   [I-D.ietf-dime-diameter-base-protocol-mib] SHOULD be implemented
   prior to the implementation of this MIB.

Why is this a SHOULD and not a MUST? 
Also, as an editorial observation around the same phrase, probably
'prior' is not the right term. What is meant is I think that it is
assumed that an agent implementing the CC-application MIB also
implements the  base DIAMETER MIB., 

T2. 

diameterCcAppMIB             OBJECT IDENTIFIER ::=
                                        { diameterCCAMIB 2 }
 
I do not see the reason for two nested OIDs diameterCcAppMIB and
diameterCCAMIB

T3. dccaHostID - the definition is similar with dbpLocalId in the
DIAMETER-BASE-PROTOCOL-MIB - why duplicate the object? 

T4. How does dccaHostIpAddrTable differ from dbpLocalIpAddrTable? And if
we are already here, the same question that I asked in the base MIB
review applies here: why a new table instead of using information from
the ipAddressTable in RFC 4293?

T5. dccaPeerFirmwareRevision - the SYNTAX of this object should be
consistent with the entPhysicalFirmwareRev object in RFC 4133 which is
an SnmpAdminString. Actually the DESCRIPTION clause should mention that
if the Entity MIB is supported on the peer, than the two objects must
have identical contents. 

T6. dccaPeerStorageType and dccaPeerVendorStorageType - the fact that
none of the writeable objects cannot be changed - does this include the
RowStatus object itself? This would mean that rows can be created by
never deleted. 

T7. The Security Considerations section does not follow the guidelines
listed at http://www.ops.ietf.org/mib-security.html 


Editorial Issues:

E1. RFC 4181 section 3.2 recommends that the narrative sections of MIB
documents 'include one or more sections to briefly describe the
structure of the MIB modules defined in the specification'. I see no
reason for an exception here. 

E2. Running id-nits results in a comment / question: 

 -- The document has a disclaimer for pre-RFC5378 work, but was first
     submitted on or after 10 November 2008.  Does it really need the
     disclaimer?

E3. Adding REFERENCE clauses to the definitions in RFC 4006 and other
places would be very useful and improve the readability of the document.


E4. Even if not used by now it's better to use the name
diameterCcAppNotifications rather than diameterCcAppTraps

E5. Adding UNITS clauses to the counter objects definitions would be
very useful