Management Information Base for Virtual Machines Controlled by a Hypervisor
(draft-ietf-opsawg-vmm-mib) for proposed std
1. Summary
Who is the document shepherd?
Scott Bradner
Who is the responsible Area Director?
Joel Jaeggli
Explain briefly what the intent of the document is (the document's abstract is
usually good for this), and why the working group has chosen the
requestedExperimental, or Historic).
This document defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, this specifies objects for managing
virtual machines controlled by a hypervisor (a.k.a. virtual machine
monitor).
The working group felt that this ID should be standards track (Proposed
Standard) since the technology it covers is widely deployed and having a
management (at least monitoring) interface will be very useful.
2. Review and Consensus
Explain how actively the document was reviewed andhow much of the interested
community is behind the document. Explain anything notable about the discussion
of the document.
This document was discussed in the opsawg for quite a while (more
than a year) with the only real question involving the number of
writeable variables in the MIB. The ID was modified to reflect the
WG consensus.
There were no comments during WGLC until the chairs indicated that they
interpreted the lack of comments as an indication of no support - this
produced a number of messages of support - enough support for the
chairs to bring the ID forward.
3. Intellectual Property
Confirm that each author has stated that theirsummarize the outcome.
No disclosures have been filed against the ID and the ID authors
each indicated that they did not know of any IPR relating to the ID.
4. Other Points
Note any downward references (see RFC 3967) and whether they appear in the
DOWNREF Registry
(http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry), as these
need to be announced during Last Call.
n/a
Check the IANA Considerations for clarity and against the checklist below.
The ID registers a new object ID.
Note any registrations that require expert review,ction of the RFC 5226) that
were selected for them. If any new registries require expert review for future
allocations, provide any public guidance that the IESG would find useful in
selecting the designated experts (private comments may be sent to the Area
Director separately).
N/A
Explain anything else that the IESG might need tomessage to the responsible
Area Director.
none
Checklist
This section is not meant to be submitted, but isbody of the writeup.
• Does the shepherd stand behind the document and think the document is ready
for publication?
yes
• Is the correct RFC type indicated in the title page header?
yes
• Is the abstract both brief and sufficient, and does it stand alone as a brief
summary?
yes
• Is the intent of the document accurately and adequately explained in the
introduction?
yes
• Have all required formal reviews (MIB Doctor, Media Type, URI, etc.) been
requested and/or completed?
• Has the shepherd performed automated checks -- idnits (see
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist), checks of
BNF rules, XML code and schemas, MIB definitions, and so on -- and determined
that the document passes the tests? (In general, nits should be fixed before
the document is sent to the IESG. If there are reasons that some remain (false
positives, perhaps, or abnormal things that are necessary for this particular
document), explain them.)
ID nits passes with minor warnings as does the MIB checker
• Has each author stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed, in conformance with BCPs
78 and 79?
yes
• Have all references within this document been identified as either normative
or informative, and does the shepherd agree with how they have been classified?
yes
• Are all normative references made to documents that are ready for advancement
and are otherwise in a clear state?
yes
• If publication of this document changes the status of any existing RFCs, are
those RFCs listed on the title page header, and are the changes listed in the
abstract and discussed (explained, not just mentioned) in the introduction?
n/a
• If this is a "bis" document, have all of the errata been considered?
n/a
• IANA Considerations:
• Are the IANA Considerations clear and complete? Remember that IANA have to
understand unambiguously what's being requested, so they can perform the
required actions.
yes
• Are all protocol extensions that the document makes associated with the
appropriate reservations in IANA registries?
yes
• Are all IANA registries referred to by their exact names (check them in
http://www.iana.org/protocols/ to be sure)?
yes
• Have you checked that any registrations made by this document correctly
follow the policies and procedures for the appropriate registries?
yes
• For registrations that require expert review (policies of Expert Review or
Specification Required), have you or the working group had any early review
done, to make sure the requests are ready for last call?
n/a
• For any new registries that this document creates, has the working group
actively chosen the allocation procedures and policies and discussed the
alternatives? Have reasonable registry names been chosen (that will not be
confused with those of other registries), and have the initial contents and
valid value ranges been clearly specified?
n/a