Re: Mini WG LAST CALL: draft-ietf-entmib-v3-06.txt

On Sun, Jan 16, 2005 at 07:50:17AM -0500, Margaret Wasserman wrote:
 
> Since this document has already been through WG Last Call several 
> times, I just like to do a quick check that no new problems have been 
> introduced as a result of the latest edits, then I will send this 
> document on to the IESG for publication.
> 
> So, if you have any objection to this document being submitted to the 
> IESG in its current form for publication as a Proposed Standard RFC, 
> please send them to the [email protected] mailing list by Wednesday, 
> January 19th.

I support this document being submitted to the IESG. However, I found
a few nits that probably should be addressed (personally I do not care
when in the process):

a) The description of entPhysicalMfgDate says '0000000000000000'H is
   returned if the date is unknown. The text in section 2.12.1 says
   that the object is not instantiated if the date is unknown. 
   
   It appears to me that entPhysicalFirmwareRev, entPhysicalSoftwareRev,
   entPhysicalSerialNum, entPhysicalMfgName, and entPhysicalModelName
   all return a zero-length string if the value is unknown so I think
   the description is actually consistent with them.
   
   Hence I propose the following change to section 2.12.1:

   OLD

     This object contains the date of manufacturing of the managed
     entity.  If the manufacturing date is unknown or not supported
     the object is not instantiated.

   NEW

     This object contains the date of manufacturing of the managed
     entity. If the manufacturing date is unknown or not supported
     the object is not instantiated. The special value 
     '0000000000000000'H may also be returned in this case.

b) My smilint says the following:

   ./ENTITY-MIB:90: warning: type `PhysicalIndex' has no format
                             specification
   ./ENTITY-MIB:104: warning: type `PhysicalIndexOrZero' has no format
			      specification

   I suggest to add DISPLAY-HINT "d" clauses to the TC definitions.

c) If I understand the MIB review guidelines correctly, then we should
   put the following into the IANA Considerations section:

      The MIB module in this document uses the following IANA-assigned
      OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

      Descriptor        OBJECT IDENTIFIER value
      ----------        -----------------------
      entityMIB         { mib-2 47 }

      Editor's Note (to be removed prior to publication):  this draft
      makes no additional requests of the IANA.

   (I know that one can debate the utility of this but I do not want
   to do this here.)

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany