Management Information Base for Virtual Machines Controlled by a Hypervisor
draft-ietf-opsawg-vmm-mib-04

[Ballot comment]
I mean the following as a question, because it's something I've never thought about, but seems odd: Is it normal to have 2119 language in the description fields in a MIB definition? Who is that language intended for?

[Edit: I am told that this is okay. So be it.]

-- 6.1, vm-mib "description" field:

Do you expect the sentence about 'yyy' being temporary to be removed by the RFC Editor? If so, you probably want a note to that effect.

-- VirtualMachineList description: "... set of eight virtual machine vmIndex..."

Should vmIndex be plural?

-- 8, 1st paragraph:

"noticeable number of notifications"

Is "noticeable" the word you intended? It seems like any number of notifications might be noticeable--that's the point of notifications. Also, this sentence seems out of place (the next sentence seams to draw a conclusion from the sentence prior to this one.)

"... It is recommended that attention be given to these objects ...

I'm not sure what it means to give attention to the objects. Identifying who or what needs to give attention might help. (consider  active voice)

-- paragraph 5: "It is recommended that the implementers consider the security
  features as provided by the SNMPv3 framework."

Do you mean "use the ... features" or "consider using the ... features"?

[Ballot comment]
I mean the following as a question, because it's something I've never thought about, but seems odd: Is it normal to have 2119 language in the description fields in a MIB definition? Who is that language intended for?

{Edit: I am told that this is okay. So be it.]

-- 6.1, vm-mib "description" field:

Do you expect the sentence about 'yyy' being temporary to be removed by the RFC Editor? If so, you probably want a note to that effect.

-- VirtualMachineList description: "... set of eight virtual machine vmIndex..."

Should vmIndex be plural?

-- 8, 1st paragraph:

"noticeable number of notifications"

Is "noticeable" the word you intended? It seems like any number of notifications might be noticeable--that's the point of notifications. Also, this sentence seems out of place (the next sentence seams to draw a conclusion from the sentence prior to this one.)

"... It is recommended that attention be given to these objects ...

I'm not sure what it means to give attention to the objects. Identifying who or what needs to give attention might help. (consider  active voice)

-- paragraph 5: "It is recommended that the implementers consider the security
  features as provided by the SNMPv3 framework."

Do you mean "use the ... features" or "consider using the ... features"?

[Ballot comment]
- Idnit complains:

== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
    or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
    use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
    mean).
   
    Found 'SHOULD not' in this paragraph:
   
    vmHvSoftware OBJECT-TYPE SYNTAX      SnmpAdminString (SIZE
    (0..255)) MAX-ACCESS  read-only STATUS      current DESCRIPTION "A
    textual description of the hypervisor software.  This value SHOULD not
    include its version as it SHOULD be included in `vmHvVersion'." ::= {
    vmHypervisor 1 }

- EDITORIAL: there is something wrong with all single quote occurrences. Ex: `virtio'

- If you ever post a new version, in order to ease IANA job, change:
OLD:
        vmMIB                    { mib-2 TBD }
        IANAStorageMediaTypeMIB  { mib-2 TBD }


NEW:
        vmMIB                    { mib-2 yyy }
        IANAStorageMediaTypeMIB  { mib-2 zzz }

[Ballot comment]
I mean the following as a question, because it's something I've never thought about, but seems odd: Is it normal to have 2119 language in the description fields in a MIB definition? Who is that language intended for?

-- 6.1, vm-mib "description" field:

Do you expect the sentence about 'yyy' being temporary to be removed by the RFC Editor? If so, you probably want a note to that effect.

-- VirtualMachineList description: "... set of eight virtual machine vmIndex..."

Should vmIndex be plural?

-- 8, 1st paragraph:

"noticeable number of notifications"

Is "noticeable" the word you intended? It seems like any number of notifications might be noticeable--that's the point of notifications. Also, this sentence seems out of place (the next sentence seams to draw a conclusion from the sentence prior to this one.)

"... It is recommended that attention be given to these objects ...

I'm not sure what it means to give attention to the objects. Identifying who or what needs to give attention might help. (consider  active voice)

-- paragraph 5: "It is recommended that the implementers consider the security
  features as provided by the SNMPv3 framework."

Do you mean "use the ... features" or "consider using the ... features"?

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

[Ballot comment]
I found the SecDir review to be interesting, raising a point of clarification specific to this draft and not the agreed boilerplate text.  Since there was confusion by the reader as to the access possibilities and where this mib is used, I think it's worth adding a sentence with the clarifying point from the discussion.  How about:

This MIB module is typically implemented on the hypervisor not inside a virtual machine.  Virtual machines, possibly under other administrative domains, would not have access to this mib as the SNMP service would typically operate in a separate management network.

https://www.ietf.org/mail-archive/web/secdir/current/msg05705.html
https://www.ietf.org/mail-archive/web/secdir/current/msg05706.html

The suggested text, or something similar might fit into the introduction to limit the scope or after paragraph 2 in Section 3.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-opsawg-vmm-mib-02.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is
a single action which IANA must complete.

In the SMI Network Management MGMT Codes Internet-standard MIBsubregistry of the Network Management Parameters registry located at:

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

a new MIB will be registered as follows:

Decimal: [ TBD by IANA at time of registration ]
Name: vmMIB
Description: vmMIB
References: [ RFC-to-be ]

IANA understands this to be the only action required of IANA 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. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Management Information Base for Virtual Machines Controlled by a Hypervisor) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document:
- 'Management Information Base for Virtual Machines Controlled by a
  Hypervisor'
  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 2015-05-18. 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 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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/ballot/


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

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),

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).

and why the working group has chosen the requestedExperimental, or Historic).

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