Dear Benoit, Thank you for your clarification. I understand that the IESG statement does not forbid all the use of objects with read-write access, and our vmPerVMNotificationsEnabled and vmBulkNotificationsEnabled can be read-write.
Hirochika On Jul 16, 2014, at 12:43 PM, Benoit Claise <[email protected]> wrote: > Dear Hirochika, > > Very sorry for the delay in getting back to you. > >> 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. > That's not quite the message. > The IESG statement is there to discourage the specification of > completely new MIB modules with read-write objects (like a complete new > framework around SNMP) and to point to NETCONF/YANG instead, but the > IESG statement is not there to forbid the use of read-write objects. > There are cases where read-write objects are useful (ex: your > notifications in last version). > I believe that you try to find hard rules in this statement. > > Regards, Benoit >> 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 >> >> >> On May 27, 2014, at 3:55 AM, joel jaeggli <[email protected]> wrote: >> >>> 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 >>> >>> On 5/26/14, 10:48 AM, Hirochika Asai wrote: >>>> 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 protected], CCing WG? Or ask WG chairs to >>>> handle it? >>>> >>>> Thank you. >>>> Hirochika >>>> >>>> >>>> On May 27, 2014, at 1:24 AM, joel jaeggli <[email protected]> wrote: >>>> >>>>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote: >>>>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggli wrote: >>>>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote: >>>>>>>> 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. >>>>>>> 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! >>>>>>> >>>>>> Joel, can you please decrypt your message so that it becomes perhaps >>>>>> actionable? >>>>> I'm agreeing with you. >>>>> >>>>>> /js >>>>>> >>>>> >>> > -- Hirochika Asai <[email protected]>, The University of Tokyo _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
