Subject: [OPSAWG] Read-write access in VMM-MIB

From: Hirochika Asai <[email-masked]>
Date: Mon, 26 May 2014 16:24:38 +0900

Dear all,

We'd like to discuss the read-write access in the proposed MIB about virtual
machine monitoring: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib .

It has 10 read-write objects. All of them do not affect persistent configuration
of hypervisor or virtual machines. However, according to a comment during
the previous IETF meeting, the IESG statement also suggests not to include
read-write objects even if they do not persist after the restart of the agent or
system.

In this sense, I think the following 8 objects will be read-only.
1. vmAdminState
2. vmCurCpuNumber
3. vmMinCpuNumber
4. vmMaxCpuNumber
5. vmCurMem
6. vmMinMem
7. vmMaxMem
8. vmCpuAffinity

The following two objects require discussion because these objects are not
related to hypervisor or virtual machines, but notifications of SNMP.
The reason why I think they can be kept read-write is they are control objects
of an SNMP agent and it does not affect the configuration of monitoring targets.
However, from the viewpoint of security, I can agree that they should also be
read-only and operators configure them not through SNMP (or something) but
through another configuration scheme such as editing a configuration file.
9. vmPerVMNotificationsEnabled
10. vmBulkNotificationsEnabled

I hope you give us your comments on the access of 10 objects.

Thank you.
Hirochika

-- 
Hirochika Asai <[email-masked]>, The University of Tokyo

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 May 2014 11:31:37 +0200

Asai,

the IESG statement is here:

  http://www.ietf.org/iesg/statement/writable-mib-module.html

My reading is that it specifically talks about configuration. While
the discussion started with "lets ban all write access", it may be
important to note that the final statement does not say this. Hence,
I am not sure we have to remove the MAX-ACCESS read-write.

/js

On Mon, May 26, 2014 at 04:24:38PM +0900, Hirochika Asai wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: joel jaeggli <[email-masked]>
Date: Mon, 26 May 2014 08:42:47 -0700

> I am not sure we have to remove the MAX-ACCESS read-write.

some of the vm options do cause me existential peril. The remaining
one's however do not. so I think Juergen's assessment  is a correct one.
The statement seems to be serving it's purpose!

thanks

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 May 2014 18:20:33 +0200

> The statement seems to be serving it's purpose!

Joel, can you please decrypt your message so that it becomes perhaps
actionable?

/js

---

From: joel jaeggli <[email-masked]>
Date: Mon, 26 May 2014 09:24:24 -0700

> Joel, can you please decrypt your message so that it becomes perhaps

I'm agreeing with you.

---

From: Hirochika Asai <[email-masked]>
Date: Tue, 27 May 2014 02:48:47 +0900

js and Joel,

Thank you for your comments.

I agree that the IESG statement seems to be talking about configuration,
but I cannot definitely say that the objects I listed in my previous E-mail
are out of the IESG statement's scope.

I think it would be better to move this issue to the IESG, but I don't keep
up the procedure.  May I, as an author of the draft, send an E-mail
stating this issue to [email-masked], CCing WG? Or ask WG chairs to
handle it?

Thank you.
Hirochika

---

From: joel jaeggli <[email-masked]>
Date: Mon, 26 May 2014 11:55:15 -0700

yeah if you want to discuss it with the ops/management ADs and the
chairs that's fine.

I don't think there's a reason to involve the whole iesg.

Thanks
joel

---

From: Joe Marcus Clarke <[email-masked]>
Date: Mon, 26 May 2014 16:24:15 -0400

> I hope you give us your comments on the access of 10 objects.

I was vocal against persisting some of these objects, but I think 
offering the ability to write to them for running VMs has value (i.e., 
changes would not persist), but I can see how that could lead to 
confusion.  If you leave 1-8 as read-only, that is very clear.

I think leaving 9 and 10 read-write is fine.

Joe

---

From: Hirochika Asai <[email-masked]>
Date: Wed, 28 May 2014 07:49:03 +0900

Joe,

Yes, 1-8 might lead confusion even though they have the description saying
"Changes to this object MUST NOT persist across re-initialization of the
hypervisor."  If they are no use in practice, changing them to MAX-ACCESS
read-only makes things clear.  If there are use cases of write access, it can be
read-write, but I have currently received no use cases of write access to 1-8.

Hirochika

On May 27, 2014, at 5:24 AM, Joe Marcus Clarke <[email-masked]> wrote:

> I was vocal against persisting some of these objects, but I think offering the ability to write to them for running VMs has value (i.e., changes would not persist), but I can see how that could lead to confusion.  If you leave 1-8 as read-only, that is very clear.
>

---

From: Hirochika Asai <[email-masked]>
Date: Wed, 28 May 2014 08:57:18 +0900

Dear Joel and Benoit,

Thank you.

Since Joel has invited Benoit, another AD of OPS AREA, to this discussion,
I summarize my question for clarity as follows:

The IESG statement (*1) encourages to remove read-write access to objects
related to configuration from MIB modules.  However, the scope of the
nomenclature "configuration" is not clear to me.  In my understanding,
"configuration" does not contain non-persistent (volatile) changes to objects,
such as virtual machine administrative state (vmAdminState) in our I-D (*2).
They does not affect the configuration but changes state of the target system.
Therefore, I think they are not under "SNMP MIB modules creating and
modifying configuration state" stated in the IESG statement.

Is my understanding correct or not?

(*1) http://www.ietf.org/iesg/statement/writable-mib-module.html
(*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-00

Hirochika

---

From: t.petch <[email-masked]>
Date: Wed, 28 May 2014 10:30:45 +0100

----- Original Message -----
From: "Hirochika Asai" <[email-masked]>
To: "joel jaeggli" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 28, 2014 12:57 AM

> Is my understanding correct or not?

Note that the statement refers to NETCONF/YANG which has introduced a
new definition of configuration, namely

"The information that can be retrieved from a running system is
   separated into two classes, configuration data and state data.
   Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.  State data is the additional data on a system that is not

   configuration data such as read-only status information and collected
   statistics."

Other references make it clearer that configuration is what you might
put in through a CLI to get a box off the ground, while anything learnt
later via a protocol, such as BGP, NTP, DHCP, is (operational) state
(and read-only in NETCONF but not so limited in SNMP).  Persistence is
orthogonal, and ill-defined, in NETCONF/YANG.  If you key it in via CLI,
or do the equivalent via something other than Telnet, then it is
configuration, even if it is discarded at reboot; NETCONF optionally
allows for persistent and non-persistent configuration.  SNMP has never
said much about persistence (table row status being the exception).

So the two objects controlling Notifications seem clearly configuration,
whether or not the setting of them persists or is lost on reboot.  You
could create a YANG module which controls the setting of these two
objects for SNMP usage but I think that even the IESG might see that
that is an unusual approach, as opposed to making them read-write in
SMI!

When I first read the draft IESG statement, it was unclear to me whether
or not the authors fully understood what they had written.

Tom Petch

---

From: "Black, David" <[email-masked]>
Date: Wed, 28 May 2014 14:27:04 -0400

Hirochika-san,

I think this is a good proposal.

Although the 8 objects proposed to be made read-only do not affect
persistent hypervisor configuration, they do affect persistent virtual
machine configuration (e.g., change of vmAdmin state between running
and suspended, as the latter state involves use of "persistent store"
for memory and CPU execution state).  Making these 8 objects read-only
seems reasonable to me.

The other two read-write objects control notifications, and I agree
with Tom Petch that they should be read-write in the same MIB module

> that is an unusual approach, as opposed to making them read-write in

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Hirochika Asai
> Sent: Monday, May 26, 2014 3:25 AM
> To: [email-masked]
> Subject: [OPSAWG] Read-write access in VMM-MIB
> 
> Dear all,
>

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 31 May 2014 20:01:02 -0700 (PDT)

On Wed, 28 May 2014, t.petch wrote:
> SNMP has never said much about persistence (table row status [with 
> StorageType] being the exception).

This omission was recognized when the MIB review guidelines 
(http://tools.ietf.org/html/rfc4181) were developed, and as a result 
the following text was included in Section 4.6.2:

   For read-write objects (other than columns in read-create tables that
   have well-defined persistence properties), it is RECOMMENDED that the
   DESCRIPTION clause specify what happens to the value after an agent
   reboot.

//cmh