Entity MIB (Version 4)
RFC 6933

[Ballot comment]

I'm glad to see you've recognised the potential security issue
with the new UUID objects and that you do allow the value to be
empty. However, I guess these (and other similar objects) could
also cause potential privacy problems, so would suggest maybe
making the following changes to section 5 (if you want, I'm not
insisting):

OLD:

Their mis-configuration or disclosure may reveal sensitive
information on assets or perturb the management of entities. 

NEW:

Their mis-configuration or disclosure may reveal sensitive
information on assets or perturb the management of entities,
or could cause privacy issues if they allow tracking of
values that are personally identifying. 

OLD:

These objects expose information about the physical entities
within a managed system, which may be used to identify the
vendor, model, and version information of each system
component.

NEW:

These objects expose information about the physical entities
within a managed system, which may be used to identify the
vendor, model, version and specific device identification
information of each system component.

IANA has reviewed draft-ietf-eman-rfc4133bis-06, which is currently in Evaluation, and has the following comment(s):

This version has added the following additional IANA action:

This document requests the following two new OBJECT IDENTIFIERS to
be registered under mib-2 in the SMI Numbers registry located at:

http://www.iana.org/assignments/smi-numbers

Descriptor OBJECT IDENTIFIER value Reference
---------- ----------------------- ---------
ianaEntityMIB { mib-2 TBD1 } [this document]
uuidTCMIB { mib-2 TBD2 } [this document]

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

Document: draft-ietf-eman-rfc4133bis-05
Title:    Entity MIB (Version 4)
Editors:  A. Bierman, D. Romascanu, J. Quittek, Mouli Chandramouli


As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.  Changes are expected over time. This version is
dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?

Standards Track.  This draft is a MIB that obsoletes RFC 4133.  Yes.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.  In
particular, it describes managed objects used for managing multiple
logical and physical entities managed by a single SNMP agent. This
document specifies a new version of the Entity MIB, which obsoletes
version 3 [RFC4133].

Working Group Summary:

EMAN's meeting at IETF 83 (Paris) identified the need for this as
a generic way to manage objects using a list of URIs.  Mouli Chandramouli
produced the -01 version in time for IETF 84, with co-editors Andy
Bierman, Dan Romascanu and Juergen Quittek.  The WG decided that this
would provide a sensible base for the EMAN MIBs.

Since then it has been discussed on the EMAN list; its WG Last Call
was of its -03 version, from 11 to 29 October.  The latest revision
addresses concerns arising from the WGLC, the editors consider that
it's now ready to publish.

Document Quality:

Are there existing implementations of the protocol?
  It obsoletes RFC 4133, Entity MIB v3.
Have a significant number of vendors indicated their plan to implement
the specification?
  Don't know.
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?

Juergen Schoenwalder was particularly helpful as a reviewer at WGLC
though the changes srising were minor.

If there was a MIB Doctor, Media Type or other expert review, what was
its course (briefly)?

Two of the draft's editors are on the MIB Doctors list, so is
Juergen Schoenwalder.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd:      Nevil Brownlee
Area Director: Benoit Claise

(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have read the draft carefully, it has all the details needed for
a MIB document, it clearly describes (section 2.16) the new features
it implements, and explains why they should be useful to writers of new
MIBs.  The usage examples given in section 4 show clearly how this MIB
can be used to describe routers, repeaters and a router with EMAN objects.

I believe that this draft is ready to publish.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

No issues of concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?

This is a generic MIB, I don't believe it needs any IPR declaraions
(it has none).  Further, its editors are all well aware of IPR
considerations.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No, see (7) above.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

There is strong consensus for this draft within the EMAN WG;
many WG members have a strong interest in using this with the various
EMAN MIBs (still in early draft versions).

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.

I-D-nits errors found and fixed.
Two obsolete references remain; RFC 2037 and RFC 2737 are needed -
since RFC 2037 is ENTITY-MIB V1 and RFC 2737 is ENTITY-MIB V2 and
they are explicitly mentioned in the draft.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This is a MIB, two editors and one reviewer are MIB Doctors.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?

No, all references are already published.

(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

This draft obsoletes RFC 4133 (Entity MIBv3).
That's clearly spelled out in its Abstract, near the top of
its title page.

(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in
IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC
5226).

This MIB uses { mib-2 47 }, entityMIB, no problems there.
It adds a new entry to the list of IANA-maintained MIBs,
see (18) below.

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

It introduces a new
    IANA-maintained IANA-ENTITY-MIB module, which will allow for new
    physical classes to be added to the enumeration in IANAPhysicalClass.
    An Expert Review, as defined in RFC 5226 [RFC5226], is REQUIRED,
    for each modification.

I suggest that IANA could simply send a request for a new
IANAPhysicalClass to the MIB-doctors list, rather than designating
one or two experts (?)

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

I extracted the MIB from the draft by hand, then checked it using
the SimpleWeb online  MIB Checker.  That gave a few warnings about
the TEXTUAL CONVENTION definitions, but these look fine to me.

Cheers, Nevil

IANA has reviewed draft-ietf-eman-rfc4133bis-05 and has the following comments:

IANA understands that, upon approval of this document, there is a single action which needs to be completed.

This document creates a new IANA maintained MIB to be called the IANA Entity MIB. The new IANA Entity MIB will be registered as a new entry on the IANA Matrix under IANA Maintained MIBs. Expert review, as defined in RFC 5226, is required for modification and maintenance this new MIB.

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

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

IANA confirms that that Object Identifier value has already been
registered in the SMI Numbers registry.

IANA understands that this is the only action required to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Entity MIB (Version 4)) to Proposed Standard


The IESG has received a request from the Energy Management WG (eman) to
consider the following document:
- 'Entity MIB (Version 4)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in the Internet community.  In
particular, it describes managed objects used for managing multiple
logical and physical entities managed by a single SNMP agent. This
document specifies version of the Entity MIB, which obsoletes version 3
[RFC4133].





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eman-rfc4133bis/ballot/


No IPR declarations have been submitted directly on this I-D.