Subject: [Entmib] sensor mib

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 30 Jul 2002 11:59:30 +0200

I reviewed draft-ietf-entmib-sensor-mib-00.txt in
preparation for IETF Last Call.

I have some nits.

- in the abstract section one should not use references/citations
  It is OK to replace [RFC2737] by (RFC 2737)
  I know... but look at http://www.rfc-editor.org/policy.html

- RFC-Editor wants separation of Normative and informative
  references. Same rfc-editor policy page for details.
  I know we need to find a generic split for the SNMP Framework
  section. Proposals are welcome. (I suggest to do the generic
  discussion on the mib mailing list: [email-masked]).

- you talk about "augments" (sect 5), "conceptually extend" 
  (sect 5.2), "SPARSE-AUGMENTS" (comment in MIB itself).
  Might be better to be consistent in our terminology, no?

- Section 6: there seems to be still an "OPEN ISSUE" ?? for
  entSensorType. My take: instead of IANA registered OIDs.
  we could also choose an IANA-maintained TC with the ENUMs.

- Would it not be better to rename entSensorStatus to 
  entSensorOperStatus ???

- if you are going to edit, then I would change

    REVISION        "200201180000Z"
    DESCRIPTION
            "Initial version of the Entity Sensor MIB module."
    ::= { mib-2 xxx } -- unassigned

  into

    REVISION        "200201180000Z"
    DESCRIPTION
            "Initial version of the Entity Sensor MIB module,
             publsihed as RFC xxxx." -- RFC-Editor assigns xxxx
    ::= { mib-2 xxx } -- IANA needs to assign xxx

- I wonder why entitySensorNotifications is defined, it is not used
  and there are no notifcations specified.

- I guess that the contact info for KC needs to be updated.

Would it make sense to (quickly) do a revision to address the above?

Thanks,
Bert 

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