From nobody Mon May 5 09:36:02 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23D31A00D7; Mon, 5 May 2014 09:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYhds9ZWkYxH; Mon, 5 May 2014 09:35:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFFE1A0194; Mon, 5 May 2014 09:35:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140505163555.10419.513.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 09:35:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/SpBx5Brry8fMGI8BWwJ1E9Ozxfk Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-03.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:35:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : IEEE 802.11 MAC Profile for CAPWAP Authors : Chunju Shao Hui Deng Rajesh S. Pazhyannur Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-03.txt Pages : 10 Date : 2014-05-05 Abstract: CAPWAP defines two entities: Wireless Transmission Point (WTP) and Access Controller (AC). CAPWAP also defines two MAC (Medium Access Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each MAC mode, CAPWAP describes how the MAC functionality is split between the WTP and AC. However, certain functions have not been clearly defined. For example in the Split MAC mode description, the IEEE 802.11 encryption is specified as located in either the AC or the WTP with no clear way for the AC to inform the WTP where it should be. This lack of specification leads to interoperability especially when AC and WTP come from different vendors. To solve the problem, this specification defines a IEEE 802.11 MAC profile where each profile specifies an unambiguous division of functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles while configuring the WLAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-hybridmac-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 5 09:48:09 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D1F1A03FC; Mon, 5 May 2014 09:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb1OajPr50eP; Mon, 5 May 2014 09:48:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 958401A01BB; Mon, 5 May 2014 09:48:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140505164802.20331.79436.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 09:48:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/U34K1Do5YfKV23pkiUttIijwLGQ Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:48:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : IEEE 802.11 MAC Profile for CAPWAP Authors : Chunju Shao Hui Deng Rajesh S. Pazhyannur Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-04.txt Pages : 10 Date : 2014-05-05 Abstract: CAPWAP defines two entities: Wireless Transmission Point (WTP) and Access Controller (AC). CAPWAP also defines two MAC (Medium Access Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each MAC mode, CAPWAP describes how the MAC functionality is split between the WTP and AC. However, certain functions have not been clearly defined. For example in the Split MAC mode description, the IEEE 802.11 encryption is specified as located in either the AC or the WTP with no clear way for the AC to inform the WTP where it should be. This lack of specification leads to interoperability especially when AC and WTP come from different vendors. To solve the problem, this specification defines a IEEE 802.11 MAC profile where each profile specifies an unambiguous division of functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles while configuring the WLAN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-hybridmac-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 5 11:47:20 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53341A0439; Mon, 5 May 2014 11:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhBH-sycslcC; Mon, 5 May 2014 11:47:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC401A0424; Mon, 5 May 2014 11:47:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140505184710.7635.95324.idtracker@ietfa.amsl.com> Date: Mon, 05 May 2014 11:47:10 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/X2kfZc5KZ55eVue_FPQhnyg_jM8 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-alt-tunnel-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 18:47:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : Alternate Tunnel Encapsulation for Data Frames in CAPWAP Authors : Rong Zhang Zhen Cao Hui Deng Rajesh S. Pazhyannur Sri Gundavelli Li Xue Filename : draft-ietf-opsawg-capwap-alt-tunnel-00.txt Pages : 11 Date : 2014-05-05 Abstract: CAPWAP defines a specification to encapsulate a station's data frames between the Wireless Transmission Point (WTP) and Access Controller (AC) using CAPWAP. Specifically, the station's IEEE 802.11 data frames can be either locally bridged or tunneled to the AC. When tunneled, a CAPWAP data channel is used for tunneling. In many deployments it is desirable to encapsulate date frames to an entity different from the AC for example to an Access Router (AR). Further, it may also be desirable to use different tunnel encapsulations to carry the stations' data frames. This document provides a specification for this and refers to it as Alternate tunnel encapsulation. The Alternate tunnel encapsulation allows 1) the WTP to tunnel non-management data frames to an endpoint different from the AC and 2) the WTP to tunnel using one of many known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support for Alternate tunnel encapsulation during the discovery or join process and AC may select one of the supported Alternate Tunnel encapsulation types while configuring the WTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-alt-tunnel-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 6 03:56:22 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375051A02A5 for ; Tue, 6 May 2014 03:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBeAM-Po4mv6 for ; Tue, 6 May 2014 03:56:18 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6988E1A07A4 for ; Tue, 6 May 2014 03:56:18 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id C90311A00B4; Tue, 6 May 2014 12:56:13 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2vdbg8jDex_3; Tue, 6 May 2014 12:56:09 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id EF0D51A00AF; Tue, 6 May 2014 12:56:09 +0200 (CEST) Received: from [10.53.40.204] (port=49982 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1Whd2f-000351-Ct; Tue, 06 May 2014 12:56:09 +0200 Received: from [10.208.1.57] (10.208.1.57) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 6 May 2014 12:56:09 +0200 Message-ID: <5368BFC8.2010101@secunet.com> Date: Tue, 6 May 2014 12:56:08 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: References: <20140506093829.24743.53393.idtracker@ietfa.amsl.com> In-Reply-To: <20140506093829.24743.53393.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.208.1.57] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/MsNMesNsmfIQ-r7MU9zNXh8LX-0 Cc: uri@ll.mit.edu Subject: [OPSAWG] Fwd: New Version Notification for draft-hmac-sha-2-usm-snmp-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:56:21 -0000 Hi, after a fruitful discussion on the first version (http://www.ietf.org/mail-archive/web/opsawg/current/msg03022.html), we have updated draft-hmac-sha-2-usm-snmp. Major changes are: - Protocol names unified to usmHMACXXXSHAYYYAuthProtocol. - Definition of mandatory (usmHMAC192SHA256AuthProtocol) and recommended (usmHMAC256SHA512AuthProtocol) protocols. (I just noticed that the abstract and introduction still talk about "new optional authentication protocols"; this is an error I will fix in the next revision) - Key word reference (RFC 2119) added - MIB biolerplate added (Sections on The Internet-Standard Management Framework, Structure of the MIB Module, Relationship to Other MIB Modules) - Security Considerations considerably extended (guidance on cryptographic strength, key derivation from passwords, access to MIB) - IANA considerations clarified and comments for RFC Ed in MIB definition added Comments are welcome. There was considerable interest in adoption by the WG, so please stand up if you have issues. Johannes -------- Original Message -------- Betreff: New Version Notification for draft-hmac-sha-2-usm-snmp-01.txt Datum: Tue, 6 May 2014 02:38:29 -0700 Von: An: Johannes Merkle , Manfred Lochter , Manfred Lochter , Johannes Merkle A new version of I-D, draft-hmac-sha-2-usm-snmp-01.txt has been successfully submitted by Johannes Merkle and posted to the IETF repository. Name: draft-hmac-sha-2-usm-snmp Revision: 01 Title: HMAC-SHA-2 Authentication Protocols in USM for SNMP Document date: 2014-05-06 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-hmac-sha-2-usm-snmp-01.txt Status: https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ Htmlized: http://tools.ietf.org/html/draft-hmac-sha-2-usm-snmp-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-hmac-sha-2-usm-snmp-01 Abstract: This memo specifies new optional HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. -- Mit freundlichen Grüßen, Dr. Johannes Merkle Principal Beratung, Elektronische Identitäten Public Sector secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From nobody Thu May 8 02:35:08 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 412691A04BC; Thu, 8 May 2014 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFR5ESpUBSAu; Thu, 8 May 2014 01:49:45 -0700 (PDT) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by ietfa.amsl.com (Postfix) with ESMTP id 972741A04A7; Thu, 8 May 2014 01:49:45 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube7.xs4all.net [194.109.20.205]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id s488nd8D004927; Thu, 8 May 2014 10:49:40 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 08 May 2014 10:49:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 08 May 2014 10:49:39 +0200 From: peter van der Stok To: Core , coman@ietf.org, opsawg@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <840dfdb4eef3161ac722a6e9c062de53@xs4all.nl> X-Sender: stokcons@xs4all.nl (/n0By8w2v6K2mjGTOA4mIbSLYfnVamY1) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/9jH7JyjFE4QOTNX3xREyrHB1ads X-Mailman-Approved-At: Thu, 08 May 2014 02:35:05 -0700 Subject: [OPSAWG] Fwd: New Version Notification for draft-vanderstok-core-comi-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 08:49:48 -0000 Dear all, Bert and I have a submitted version 4 of the comi draft to core. We were encouraged to inform also the opsawg and coman groups because the management subject is linked to these two groups. Changes from version 03 to version 04 are: o Added design considerations section o Extended comparison of management protocols in introduction o Added automatic generation of CBOR tables o Moved lowpan table to Appendix Looking forward to your comments Peter -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-core-comi-04.txt Datum: 2014-05-08 10:43 Afzender: internet-drafts@ietf.org Ontvanger: "Peter Van der Stok" , "Bert Greevenbosch" , Bert Greevenbosch , Peter van der Stok A new version of I-D, draft-vanderstok-core-comi-04.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Name: draft-vanderstok-core-comi Revision: 04 Title: CoAp Management Interfaces Document date: 2014-05-08 Group: Individual Submission Pages: 38 URL: http://www.ietf.org/internet-drafts/draft-vanderstok-core-comi-04.txt Status: https://datatracker.ietf.org/doc/draft-vanderstok-core-comi/ Htmlized: http://tools.ietf.org/html/draft-vanderstok-core-comi-04 Diff: http://www.ietf.org/rfcdiff?url2=draft-vanderstok-core-comi-04 Abstract: The draft describes an interface based on CoAP to manage constrained devices via MIBs. The proposed integration of CoAP with SNMP reduces the code- and application development complexity by accessing MIBs via a standard CoAP server. The payload of the MIB request is CBOR based on JSON. The mapping from SMI to CBOR is specified. The introduction motivates the choices of CoMI with respect to utilization of YANG, NETCONF, SMI, CBOR, CoAP, and URI structure. Note Discussion and suggestions for improvement are requested, and should be sent to core@ietf.org. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Thu May 8 13:41:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7607E1A011E; Thu, 8 May 2014 13:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZVbPH88jnXA; Thu, 8 May 2014 13:41:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70E1A0095; Thu, 8 May 2014 13:41:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 6000) id 5328218000D; Thu, 8 May 2014 13:40:38 -0700 (PDT) Date: Thu, 8 May 2014 13:40:38 -0700 From: RFC Editor To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Message-ID: <20140508204038.GD14585@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/wMXQMkAdRuqbsJk5BEgLkp96kLg Cc: drafts-update-ref@iana.org, opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] STD 78, RFC 5343 on Simple Network Management Protocol (SNMP) Context EngineID Discovery X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 20:41:23 -0000 A new Request for Comments is now available in online RFC libraries. STD 78 RFC 5343 Title: Simple Network Management Protocol (SNMP) Context EngineID Discovery Author: J. Schoenwaelder Status: Standards Track Stream: IETF Date: September 2008 Mailbox: j.schoenwaelder@jacobs-university.de Pages: 9 Characters: 19938 See Also: STD 78 I-D Tag: draft-ietf-opsawg-snmp-engineid-discovery-03.txt URL: http://www.rfc-editor.org/rfc/rfc5343.txt The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. This document updates RFC 3411. This document is a product of the Operations and Management Area Working Group of the IETF. This is now an Internet Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri May 9 19:20:15 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0901A0164 for ; Fri, 9 May 2014 19:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-0ys02LvgNo for ; Fri, 9 May 2014 19:20:11 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 379011A00F9 for ; Fri, 9 May 2014 19:20:11 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id l6so5791934oag.4 for ; Fri, 09 May 2014 19:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mNKfu3DRCpHm9XqRvK/h2SQ/2sv8gdgilnA/tu+cfDo=; b=H/kjUq+JUptq06epz2A/y7UlHcr7FPE3BZXhBCDUx1FB3yfzHs3d+3XcfoaRDZwNSh wwOyaEgHQPNbQWZgk13Uew0MQBfu5e5rCqCyLXUKYC0AQDKOh4fZtfF5iyk80InAPzII eTdB3O01+aVAEr8DwKzJd6MfLrXYupK5MQRg8IwN5xDMlfhWidcyNnoXs2fYkD0DLWRj D8mGMjd3Zd5zTvOHjH9MCLG3via5s9x7gdhLk16DWDA+aZ93e7zv0F/Of48yHD2CkoEw VWRqqUodxwePlxkdd3BkY/4jhMobb7kB1yuHq2cy9F2Z5+/LT9Q4drvRJiXnyyhzSUoE TVDg== MIME-Version: 1.0 X-Received: by 10.60.44.204 with SMTP id g12mr18686027oem.38.1399688405976; Fri, 09 May 2014 19:20:05 -0700 (PDT) Received: by 10.76.123.43 with HTTP; Fri, 9 May 2014 19:20:05 -0700 (PDT) In-Reply-To: <4ED2E36A22261145861BAB2C24088B4320F7632B@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F7632B@xmb-aln-x09.cisco.com> Date: Fri, 9 May 2014 19:20:05 -0700 Message-ID: From: Dorothy Stanley To: "Rajesh Pazhyannur (rpazhyan)" Content-Type: multipart/alternative; boundary=001a113335ca3c0c9204f9025a58 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/XPwUyZVjOAralJLpGf35LG3BiCE Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 02:20:13 -0000 --001a113335ca3c0c9204f9025a58 Content-Type: text/plain; charset=UTF-8 Hi - Some additional, largely editorial comments on the -04 version: 1. In Figures 1,2, and 3, change from "IEEE 802.1X/EWTP" to ""IEEE 802.1X/EAP" 2. Some suggestions on the abstract wording: From CAPWAP defines two entities: Wireless Transmission Point (WTP) and Access Controller (AC). CAPWAP also defines two MAC (Medium Access Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each MAC mode, CAPWAP describes how the MAC functionality is split between the WTP and AC. However, certain functions have not been clearly defined. For example in the Split MAC mode description, the IEEE 802.11 encryption is specified as located in either the AC or the WTP with no clear way for the AC to inform the WTP where it should be. This lack of specification leads to interoperability especially when AC and WTP come from different vendors. To solve the problem, this specification defines a IEEE 802.11 MAC profile where each profile specifies an unambiguous division of functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles while configuring the WLAN. to The CAPWAP protocol defines two entities: a Wireless Transmission Point (WTP) and an Access Controller (AC). The CAPWAP protocol binding for IEEE 802.11 defines two MAC (Medium Access Control) modes for IEEE 802.11 WTP: Split and Local MAC, and describes the required functionality split between the WTP and AC for each mode. However, in the split MAC mode, the partitioning of encryption/decryption functions are not been clearly clearly defined. In the Split MAC mode description, IEEE 802.11 encryption is specified as located in either at the AC or the WTP with no clear way for the AC to inform the WTP of where the encryption functionality should be located. This lack of specification leads to interoperability issues, especially when the AC and WTP come from different vendors. To prevent interoperability issues, this specification defines an IEEE 802.11 MAC profile message element in which each profile specifies an unambiguous division of encryption functionality between the WTP and AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs the AC of the supported profiles during the discovery or join process and the AC configures the WTP with one of the supported profiles when configuring the WLAN. 3. In section 1, end of first paragraph, change from " "operators will experience difficulty in interoperating WTPs and ACs from different vendors." to "operators will experience interoperability issues with WTPs and ACs from different vendors." 4. In section 1, end of second paragraph, insert a comma after "WTP/AC": "is specified as WTP/AC implying to "is specified as WTP/AC, implying" Thanks, Dorothy On Tue, Apr 22, 2014 at 9:16 PM, Rajesh Pazhyannur (rpazhyan) < rpazhyan@cisco.com> wrote: > Hello Warren, > > I will address the nits and submit a new version. > > Thanks for shepherding this through. > > Regards > > Rajesh > -----Original Message----- > From: Warren Kumari [mailto:warren@kumari.net] > Sent: Tuesday, April 22, 2014 11:19 AM > To: opsawg@ietf.org; draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org > Subject: Re: Start of WGLC for draft-ietf-opsawg-capwap-hybridmac > > On Mon, Apr 7, 2014 at 12:44 PM, Warren Kumari wrote: > > Dear opsawg WG, > > > > The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that > > they believe that the document is ready, and have asked for Working > > Group Last Call. > > > > The draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ > > > > Please review this draft to see if you think it is ready for > > publication and send comments to the list, clearly stating your view. > > > > This WGLC ends Mon 21-Apr-2014. > > This WGLC has concluded, thanks to everyone for the feedback. > > The chairs just met, and have decided that there is sufficient support to > progress this. > Authors, please spin another version with the nits addressed (some typo's, > the nits checker made grumpyface, etc) -- this will help speed it through > the IESG. > Once you resubmit with these done, please poke me / us to submit to the > IESG. > > Thanks for all the hard work. > W > > > > > > > Thanks, > > Warren Kumari > > (as opsawg WG co-chair) > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --001a113335ca3c0c9204f9025a58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi -

Some additional, largely editor= ial comments on the -04 version:

1. In Figures 1,2, and 3, cha= nge from "IEEE 802.1X/EWTP" to ""IEEE 802.1X/EAP"<= br>
2. Some suggestions on the abstract wording:

From
CAPWAP defines two entities: Wireless Transmission Point (WTP) and
   Access Controller (AC).  CAPWAP also defines two MAC (Medium Access
   Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each
   MAC mode, CAPWAP describes how the MAC functionality is split between
   the WTP and AC.  However, certain functions have not been clearly
   defined.  For example in the Split MAC mode description, the IEEE
   802.11 encryption is specified as located in either the AC or the WTP
   with no clear way for the AC to inform the WTP where it should be.
   This lack of specification leads to interoperability especially when
   AC and WTP come from different vendors.  To solve the problem, this
   specification defines a IEEE 802.11 MAC profile where each profile
   specifies an unambiguous division of functionality between the WTP
   and AC.  The IEEE 802.11 MAC profile is used as follows: the WTP
   informs the AC of the supported profiles during the discovery or join
   process and the AC configures the WTP with one of the supported
   profiles while configuring the WLAN.
to

The CAPWAP =
protocol defines two entities: a Wireless Transmission Point (WTP) and an
   Access Controller (AC).  The CAPWAP protocol binding for IEEE 802.11 def=
ines two MAC (Medium Access
   Control) modes for IEEE 802.11 WTP: Split and Local MAC, and describes t=
he required functionality split between
   the WTP and AC for each mode.  However, in the split MAC mode, the parti=
tioning of encryption/decryption functions are not been clearly
   clearly defined.  In the Split MAC mode description, IEEE
   802.11 encryption is specified as located in either at the AC or the WTP
   with no clear way for the AC to inform the WTP of where the encryption f=
unctionality should be located.
   This lack of specification leads to interoperability issues, especially =
when the
   AC and WTP come from different vendors.  To prevent interoperability iss=
ues, this
   specification defines an IEEE 802.11 MAC profile message element in whic=
h each profile
   specifies an unambiguous division of encryption functionality between th=
e WTP
   and AC.  The IEEE 802.11 MAC profile is used as follows: the WTP
   informs the AC of the supported profiles during the discovery or join
   process and the AC configures the WTP with one of the supported
   profiles when configuring the WLAN.
3. In section 1, end of fir= st paragraph, change from "
"operators will experience di=
fficulty in interoperating WTPs and ACs from different vendors."


to
"operators will experience interoperability issues wi=
th WTPs and ACs from different vendors."

4. In secti=
on 1, end of second paragraph, insert a comma after "WTP/AC":

"is specified as WTP/AC implying to "is specified as WTP/AC, impl=
ying"
Thanks,

Dorothy


On Tue, Apr 22, 2014 at 9:16 = PM, Rajesh Pazhyannur (rpazhyan) <rpazhyan@cisco.com> wrote= :
Hello Warren,

I will address the nits and submit a new version.

Thanks for shepherding this through.

Regards

Rajesh
-----Original Message-----
From: Warren Kumari [mailto:warren@kum= ari.net]
Sent: Tuesday, April 22, 2014 11:19 AM
To: opsawg@ietf.org; draft-ietf-opsawg-cap= wap-hybridmac@tools.ietf.org
Subject: Re: Start of WGLC fo= r draft-ietf-opsawg-capwap-hybridmac

On Mon, Apr 7, 2014 at 12:44 PM, Warren Kumari <warren@kumari.net> wrote:
> Dear opsawg WG,
>
> The authors of draft-ietf-opsawg-capwap-hybridmac have indicated that<= br> > they believe that the document is ready, and have asked for Working > Group Last Call.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-op= sawg-capwap-hybridmac/
>
> Please review this draft to see if you think it is ready for
> publication and send comments to the list, clearly stating your view.<= br> >
> This WGLC ends Mon 21-Apr-2014.

This WGLC has concluded, thanks to everyone for the feedback.

The chairs just met, and have decided that there is sufficient support to p= rogress this.
Authors, please spin another version with the nits addressed (some typo'= ;s, the nits checker made grumpyface, etc) -- this will help speed it throu= gh the IESG.
Once you resubmit with these done, please poke me / us to submit to the IES= G.

Thanks for all the hard work.
W



>
> Thanks,
> Warren Kumari
> (as opsawg WG co-chair)

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--001a113335ca3c0c9204f9025a58-- From nobody Mon May 12 07:47:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6EB1A074F for ; Mon, 12 May 2014 07:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.079 X-Spam-Level: X-Spam-Status: No, score=-0.079 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQt0JLR1sbGp for ; Mon, 12 May 2014 07:47:23 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8531A0744 for ; Mon, 12 May 2014 07:47:23 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so6835523wgh.28 for ; Mon, 12 May 2014 07:47:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=h2bOxTHpLwZD7s6yORQKLCaeIOfA+ov+tyqEVKatdRo=; b=BWiMlr2Nb4pBRZKeBvl/Aqrg5V/3KQc+u1rqWjwEwvVc+r84Fnlsim2v+Q80pqzuoS gQ2INJTcSu4TBu0TSWFLXVSaG7gTZGm+wErIsRjBD7fUqofcpp/xrY7x8j5LcohZQGq2 nNR6Hhrpa05omaPEW2Tz57REglt3jqp4/ceBmJzb953RiZLPcKyGUwLK6SjKlk70SRWu VnFK6eXAcSGA5I5quJuqvSKfVasHaUy5HWLpCjpnHfnxW80pR9dSz+76l0N6u8HXX+AU +6yxespIqVCJcWzvu/pt2mCW9NXuoWCkB2iPK2WFWuM4K4Ry07BBFBhsbKLfVCW+6YPM ErGw== X-Gm-Message-State: ALoCoQkYXMVHsk7pefV7nYj+Scd+w19bLH0FxFVV6asbZvpJ4G+jFobLuJAiX/oAiQ4Fa9ji3Wx9 MIME-Version: 1.0 X-Received: by 10.194.187.50 with SMTP id fp18mr965561wjc.89.1399906036989; Mon, 12 May 2014 07:47:16 -0700 (PDT) Received: by 10.194.62.70 with HTTP; Mon, 12 May 2014 07:47:16 -0700 (PDT) Date: Mon, 12 May 2014 16:47:16 +0200 Message-ID: From: Warren Kumari To: "opsawg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/22C8W5eM8sV-qhBpPlXZlmqgrPM Subject: [OPSAWG] Getting OpsAWG meeting time... X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 14:47:25 -0000 Hi all, The Toronto meeting is approaching, and we would like to remind you: In order to get agenda time, you need to have had some on-list discussions about the subject / draft. Face to face meeting time is best used for discussing and closing issues, not introducing new work, etc. If we have an abundance of free time we might make some exceptions, but don't count on this, get your on-list discussions going now... W From nobody Mon May 12 10:05:08 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06051A073C for ; Mon, 12 May 2014 10:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0VCHBNTUVf3 for ; Mon, 12 May 2014 10:05:04 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 017F21A073B for ; Mon, 12 May 2014 10:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23360; q=dns/txt; s=iport; t=1399914298; x=1401123898; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QGHUZjzBBm4tXKIEW397m+kI9GO1TOK5uMf4o1iHbzg=; b=MMSQ/mJVRmIeDvV0eDDjtgUAi0XsplzMNPQ28FLBi1mUUm6dpVjkl/BW P0xlFnqMGCxrztZfs0FEEA3UhuAzpzmvPdRRW8pyaQ1db2iwkpJ9KchlZ d3yfPtGbQ3cQaQXM3hhrfjQmW4/PVG6rCT0HFXnhyzULan1+fVaNOLD5f s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8IANL+cFOtJA2I/2dsb2JhbABZgkJET1iCZ6hlAQUBkmABhmlRARmBABZ0giUBAQEDAQEBASAKQQIJDAQCAQgOAwQBAQEKHQMCAgIfBgsUCQgCBA4FCIglAwkHAQ2rSZ1aDYV1EwSFVoZlgWYWFwQGAQaCbzaBFQSXVo8RhWiDNoIv X-IronPort-AV: E=Sophos;i="4.97,1036,1389744000"; d="scan'208,217";a="43112783" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 12 May 2014 17:04:57 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s4CH4vQV026147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 17:04:57 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.72]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 12 May 2014 12:04:57 -0500 From: "Rajesh Pazhyannur (rpazhyan)" To: Dorothy Stanley Thread-Topic: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac Thread-Index: AQHPXldbf6pywHaTjUaLzQO/xUI3SpsemJhQgBrrQICAA8eakA== Date: Mon, 12 May 2014 17:04:56 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320F8B75E@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320F7632B@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.71.133.94] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320F8B75Exmbalnx09ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/eiRS5W_EoX9gj4ZEL3nO3GZRfc4 Cc: "opsawg@ietf.org" , "draft-ietf-opsawg-capwap-hybridmac@tools.ietf.org" Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 17:05:07 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320F8B75Exmbalnx09ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gRG9yb3RoeQ0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gV2lsbCBpbmNvcnBvcmF0 ZSB0aGVtLg0KDQpSZWdhcmRzDQoNClJhamVzaA0KRnJvbTogRG9yb3RoeSBTdGFubGV5IFttYWls dG86ZHN0YW5sZXkxMzg5QGdtYWlsLmNvbV0NClNlbnQ6IEZyaWRheSwgTWF5IDA5LCAyMDE0IDc6 MjAgUE0NClRvOiBSYWplc2ggUGF6aHlhbm51ciAocnBhemh5YW4pDQpDYzogV2FycmVuIEt1bWFy aTsgb3BzYXdnQGlldGYub3JnOyBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW09QU0FXR10gU3RhcnQgb2YgV0dMQyBmb3IgZHJh ZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYw0KDQpIaSAtDQoNClNvbWUgYWRkaXRpb25h bCwgbGFyZ2VseSBlZGl0b3JpYWwgY29tbWVudHMgb24gdGhlIC0wNCB2ZXJzaW9uOg0KMS4gSW4g RmlndXJlcyAxLDIsIGFuZCAzLCBjaGFuZ2UgZnJvbSAiSUVFRSA4MDIuMVgvRVdUUCIgdG8gIiJJ RUVFIDgwMi4xWC9FQVAiDQoyLiBTb21lIHN1Z2dlc3Rpb25zIG9uIHRoZSBhYnN0cmFjdCB3b3Jk aW5nOg0KRnJvbQ0KDQpDQVBXQVAgZGVmaW5lcyB0d28gZW50aXRpZXM6IFdpcmVsZXNzIFRyYW5z bWlzc2lvbiBQb2ludCAoV1RQKSBhbmQNCg0KICAgQWNjZXNzIENvbnRyb2xsZXIgKEFDKS4gIENB UFdBUCBhbHNvIGRlZmluZXMgdHdvIE1BQyAoTWVkaXVtIEFjY2Vzcw0KDQogICBDb250cm9sKSBt b2RlcyBmb3IgSUVFRSA4MDIuMTEgV1RQczogU3BsaXQgYW5kIExvY2FsIE1BQyAuIEZvciBlYWNo DQoNCiAgIE1BQyBtb2RlLCBDQVBXQVAgZGVzY3JpYmVzIGhvdyB0aGUgTUFDIGZ1bmN0aW9uYWxp dHkgaXMgc3BsaXQgYmV0d2Vlbg0KDQogICB0aGUgV1RQIGFuZCBBQy4gIEhvd2V2ZXIsIGNlcnRh aW4gZnVuY3Rpb25zIGhhdmUgbm90IGJlZW4gY2xlYXJseQ0KDQogICBkZWZpbmVkLiAgRm9yIGV4 YW1wbGUgaW4gdGhlIFNwbGl0IE1BQyBtb2RlIGRlc2NyaXB0aW9uLCB0aGUgSUVFRQ0KDQogICA4 MDIuMTEgZW5jcnlwdGlvbiBpcyBzcGVjaWZpZWQgYXMgbG9jYXRlZCBpbiBlaXRoZXIgdGhlIEFD IG9yIHRoZSBXVFANCg0KICAgd2l0aCBubyBjbGVhciB3YXkgZm9yIHRoZSBBQyB0byBpbmZvcm0g dGhlIFdUUCB3aGVyZSBpdCBzaG91bGQgYmUuDQoNCiAgIFRoaXMgbGFjayBvZiBzcGVjaWZpY2F0 aW9uIGxlYWRzIHRvIGludGVyb3BlcmFiaWxpdHkgZXNwZWNpYWxseSB3aGVuDQoNCiAgIEFDIGFu ZCBXVFAgY29tZSBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLiAgVG8gc29sdmUgdGhlIHByb2JsZW0s IHRoaXMNCg0KICAgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgSUVFRSA4MDIuMTEgTUFDIHByb2Zp bGUgd2hlcmUgZWFjaCBwcm9maWxlDQoNCiAgIHNwZWNpZmllcyBhbiB1bmFtYmlndW91cyBkaXZp c2lvbiBvZiBmdW5jdGlvbmFsaXR5IGJldHdlZW4gdGhlIFdUUA0KDQogICBhbmQgQUMuICBUaGUg SUVFRSA4MDIuMTEgTUFDIHByb2ZpbGUgaXMgdXNlZCBhcyBmb2xsb3dzOiB0aGUgV1RQDQoNCiAg IGluZm9ybXMgdGhlIEFDIG9mIHRoZSBzdXBwb3J0ZWQgcHJvZmlsZXMgZHVyaW5nIHRoZSBkaXNj b3Zlcnkgb3Igam9pbg0KDQogICBwcm9jZXNzIGFuZCB0aGUgQUMgY29uZmlndXJlcyB0aGUgV1RQ IHdpdGggb25lIG9mIHRoZSBzdXBwb3J0ZWQNCg0KICAgcHJvZmlsZXMgd2hpbGUgY29uZmlndXJp bmcgdGhlIFdMQU4uDQoNCnRvDQoNClRoZSBDQVBXQVAgcHJvdG9jb2wgZGVmaW5lcyB0d28gZW50 aXRpZXM6IGEgV2lyZWxlc3MgVHJhbnNtaXNzaW9uIFBvaW50IChXVFApIGFuZCBhbg0KDQogICBB Y2Nlc3MgQ29udHJvbGxlciAoQUMpLiAgVGhlIENBUFdBUCBwcm90b2NvbCBiaW5kaW5nIGZvciBJ RUVFIDgwMi4xMSBkZWZpbmVzIHR3byBNQUMgKE1lZGl1bSBBY2Nlc3MNCg0KICAgQ29udHJvbCkg bW9kZXMgZm9yIElFRUUgODAyLjExIFdUUDogU3BsaXQgYW5kIExvY2FsIE1BQywgYW5kIGRlc2Ny aWJlcyB0aGUgcmVxdWlyZWQgZnVuY3Rpb25hbGl0eSBzcGxpdCBiZXR3ZWVuDQoNCiAgIHRoZSBX VFAgYW5kIEFDIGZvciBlYWNoIG1vZGUuICBIb3dldmVyLCBpbiB0aGUgc3BsaXQgTUFDIG1vZGUs IHRoZSBwYXJ0aXRpb25pbmcgb2YgZW5jcnlwdGlvbi9kZWNyeXB0aW9uIGZ1bmN0aW9ucyBhcmUg bm90IGJlZW4gY2xlYXJseQ0KDQogICBjbGVhcmx5IGRlZmluZWQuICBJbiB0aGUgU3BsaXQgTUFD IG1vZGUgZGVzY3JpcHRpb24sIElFRUUNCg0KICAgODAyLjExIGVuY3J5cHRpb24gaXMgc3BlY2lm aWVkIGFzIGxvY2F0ZWQgaW4gZWl0aGVyIGF0IHRoZSBBQyBvciB0aGUgV1RQDQoNCiAgIHdpdGgg bm8gY2xlYXIgd2F5IGZvciB0aGUgQUMgdG8gaW5mb3JtIHRoZSBXVFAgb2Ygd2hlcmUgdGhlIGVu Y3J5cHRpb24gZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgbG9jYXRlZC4NCg0KICAgVGhpcyBsYWNr IG9mIHNwZWNpZmljYXRpb24gbGVhZHMgdG8gaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMsIGVzcGVj aWFsbHkgd2hlbiB0aGUNCg0KICAgQUMgYW5kIFdUUCBjb21lIGZyb20gZGlmZmVyZW50IHZlbmRv cnMuICBUbyBwcmV2ZW50IGludGVyb3BlcmFiaWxpdHkgaXNzdWVzLCB0aGlzDQoNCiAgIHNwZWNp ZmljYXRpb24gZGVmaW5lcyBhbiBJRUVFIDgwMi4xMSBNQUMgcHJvZmlsZSBtZXNzYWdlIGVsZW1l bnQgaW4gd2hpY2ggZWFjaCBwcm9maWxlDQoNCiAgIHNwZWNpZmllcyBhbiB1bmFtYmlndW91cyBk aXZpc2lvbiBvZiBlbmNyeXB0aW9uIGZ1bmN0aW9uYWxpdHkgYmV0d2VlbiB0aGUgV1RQDQoNCiAg IGFuZCBBQy4gIFRoZSBJRUVFIDgwMi4xMSBNQUMgcHJvZmlsZSBpcyB1c2VkIGFzIGZvbGxvd3M6 IHRoZSBXVFANCg0KICAgaW5mb3JtcyB0aGUgQUMgb2YgdGhlIHN1cHBvcnRlZCBwcm9maWxlcyBk dXJpbmcgdGhlIGRpc2NvdmVyeSBvciBqb2luDQoNCiAgIHByb2Nlc3MgYW5kIHRoZSBBQyBjb25m aWd1cmVzIHRoZSBXVFAgd2l0aCBvbmUgb2YgdGhlIHN1cHBvcnRlZA0KDQogICBwcm9maWxlcyB3 aGVuIGNvbmZpZ3VyaW5nIHRoZSBXTEFOLg0KMy4gSW4gc2VjdGlvbiAxLCBlbmQgb2YgZmlyc3Qg cGFyYWdyYXBoLCBjaGFuZ2UgZnJvbSAiDQoNCiJvcGVyYXRvcnMgd2lsbCBleHBlcmllbmNlIGRp ZmZpY3VsdHkgaW4gaW50ZXJvcGVyYXRpbmcgV1RQcyBhbmQgQUNzIGZyb20gZGlmZmVyZW50IHZl bmRvcnMuIg0KDQoNCnRvDQoib3BlcmF0b3JzIHdpbGwgZXhwZXJpZW5jZSBpbnRlcm9wZXJhYmls aXR5IGlzc3VlcyB3aXRoIFdUUHMgYW5kIEFDcyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLiINCg0K NC4gSW4gc2VjdGlvbiAxLCBlbmQgb2Ygc2Vjb25kIHBhcmFncmFwaCwgaW5zZXJ0IGEgY29tbWEg YWZ0ZXIgIldUUC9BQyI6DQoNCg0KImlzIHNwZWNpZmllZCBhcyBXVFAvQUMgaW1wbHlpbmcgdG8g ImlzIHNwZWNpZmllZCBhcyBXVFAvQUMsIGltcGx5aW5nIg0KVGhhbmtzLA0KDQpEb3JvdGh5DQoN Ck9uIFR1ZSwgQXByIDIyLCAyMDE0IGF0IDk6MTYgUE0sIFJhamVzaCBQYXpoeWFubnVyIChycGF6 aHlhbikgPHJwYXpoeWFuQGNpc2NvLmNvbTxtYWlsdG86cnBhemh5YW5AY2lzY28uY29tPj4gd3Jv dGU6DQpIZWxsbyBXYXJyZW4sDQoNCkkgd2lsbCBhZGRyZXNzIHRoZSBuaXRzIGFuZCBzdWJtaXQg YSBuZXcgdmVyc2lvbi4NCg0KVGhhbmtzIGZvciBzaGVwaGVyZGluZyB0aGlzIHRocm91Z2guDQoN ClJlZ2FyZHMNCg0KUmFqZXNoDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogV2Fy cmVuIEt1bWFyaSBbbWFpbHRvOndhcnJlbkBrdW1hcmkubmV0PG1haWx0bzp3YXJyZW5Aa3VtYXJp Lm5ldD5dDQpTZW50OiBUdWVzZGF5LCBBcHJpbCAyMiwgMjAxNCAxMToxOSBBTQ0KVG86IG9wc2F3 Z0BpZXRmLm9yZzxtYWlsdG86b3BzYXdnQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fw d2FwLWh5YnJpZG1hY0B0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1vcHNhd2ctY2Fw d2FwLWh5YnJpZG1hY0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTdGFydCBvZiBXR0xD IGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjDQoNCk9uIE1vbiwgQXByIDcs IDIwMTQgYXQgMTI6NDQgUE0sIFdhcnJlbiBLdW1hcmkgPHdhcnJlbkBrdW1hcmkubmV0PG1haWx0 bzp3YXJyZW5Aa3VtYXJpLm5ldD4+IHdyb3RlOg0KPiBEZWFyIG9wc2F3ZyBXRywNCj4NCj4gVGhl IGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYyBoYXZlIGluZGlj YXRlZCB0aGF0DQo+IHRoZXkgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSwgYW5k IGhhdmUgYXNrZWQgZm9yIFdvcmtpbmcNCj4gR3JvdXAgTGFzdCBDYWxsLg0KPg0KPiBUaGUgZHJh ZnQgaXMgYXZhaWxhYmxlIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWMvDQo+DQo+IFBsZWFzZSByZXZpZXcg dGhpcyBkcmFmdCB0byBzZWUgaWYgeW91IHRoaW5rIGl0IGlzIHJlYWR5IGZvcg0KPiBwdWJsaWNh dGlvbiBhbmQgc2VuZCBjb21tZW50cyB0byB0aGUgbGlzdCwgY2xlYXJseSBzdGF0aW5nIHlvdXIg dmlldy4NCj4NCj4gVGhpcyBXR0xDIGVuZHMgTW9uIDIxLUFwci0yMDE0Lg0KDQpUaGlzIFdHTEMg aGFzIGNvbmNsdWRlZCwgdGhhbmtzIHRvIGV2ZXJ5b25lIGZvciB0aGUgZmVlZGJhY2suDQoNClRo ZSBjaGFpcnMganVzdCBtZXQsIGFuZCBoYXZlIGRlY2lkZWQgdGhhdCB0aGVyZSBpcyBzdWZmaWNp ZW50IHN1cHBvcnQgdG8gcHJvZ3Jlc3MgdGhpcy4NCkF1dGhvcnMsIHBsZWFzZSBzcGluIGFub3Ro ZXIgdmVyc2lvbiB3aXRoIHRoZSBuaXRzIGFkZHJlc3NlZCAoc29tZSB0eXBvJ3MsIHRoZSBuaXRz IGNoZWNrZXIgbWFkZSBncnVtcHlmYWNlLCBldGMpIC0tIHRoaXMgd2lsbCBoZWxwIHNwZWVkIGl0 IHRocm91Z2ggdGhlIElFU0cuDQpPbmNlIHlvdSByZXN1Ym1pdCB3aXRoIHRoZXNlIGRvbmUsIHBs ZWFzZSBwb2tlIG1lIC8gdXMgdG8gc3VibWl0IHRvIHRoZSBJRVNHLg0KDQpUaGFua3MgZm9yIGFs bCB0aGUgaGFyZCB3b3JrLg0KVw0KDQoNCg0KPg0KPiBUaGFua3MsDQo+IFdhcnJlbiBLdW1hcmkN Cj4gKGFzIG9wc2F3ZyBXRyBjby1jaGFpcikNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk9QU0FXRyBtYWlsaW5nIGxpc3QNCk9QU0FXR0BpZXRmLm9y ZzxtYWlsdG86T1BTQVdHQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vcHNhd2cNCg0K --_000_4ED2E36A22261145861BAB2C24088B4320F8B75Exmbalnx09ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xh cyIsInNlcmlmIjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bh bi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIy DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJ Zm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBEb3Jv dGh5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgdGhlIGNvbW1l bnRzLiBXaWxsIGluY29ycG9yYXRlIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmFqZXNoPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IERvcm90aHkgU3RhbmxleSBbbWFpbHRvOmRzdGFubGV5MTM4OUBnbWFpbC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBNYXkgMDksIDIwMTQgNzoyMCBQTTxicj4NCjxiPlRvOjwvYj4g UmFqZXNoIFBhemh5YW5udXIgKHJwYXpoeWFuKTxicj4NCjxiPkNjOjwvYj4gV2FycmVuIEt1bWFy aTsgb3BzYXdnQGlldGYub3JnOyBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjQHRv b2xzLmlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT1BTQVdHXSBTdGFydCBvZiBX R0xDIGZvciBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5IaSAtPGJyPg0KPGJyPg0KU29tZSBhZGRpdGlvbmFsLCBsYXJnZWx5 IGVkaXRvcmlhbCBjb21tZW50cyBvbiB0aGUgLTA0IHZlcnNpb246PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ MS4gSW4gRmlndXJlcyAxLDIsIGFuZCAzLCBjaGFuZ2UgZnJvbSAmcXVvdDtJRUVFIDgwMi4xWC9F V1RQJnF1b3Q7IHRvICZxdW90OyZxdW90O0lFRUUgODAyLjFYL0VBUCZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjIuIFNvbWUgc3VnZ2VzdGlvbnMgb24gdGhlIGFic3RyYWN0IHdvcmRpbmc6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb208bzpwPjwvbzpwPjwv cD4NCjxwcmU+Q0FQV0FQIGRlZmluZXMgdHdvIGVudGl0aWVzOiBXaXJlbGVzcyBUcmFuc21pc3Np b24gUG9pbnQgKFdUUCkgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFj Y2VzcyBDb250cm9sbGVyIChBQykuJm5ic3A7IENBUFdBUCBhbHNvIGRlZmluZXMgdHdvIE1BQyAo TWVkaXVtIEFjY2VzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBDb250cm9s KSBtb2RlcyBmb3IgSUVFRSA4MDIuMTEgV1RQczogU3BsaXQgYW5kIExvY2FsIE1BQyAuIEZvciBl YWNoPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IE1BQyBtb2RlLCBDQVBXQVAg ZGVzY3JpYmVzIGhvdyB0aGUgTUFDIGZ1bmN0aW9uYWxpdHkgaXMgc3BsaXQgYmV0d2VlbjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGUgV1RQIGFuZCBBQy4mbmJzcDsgSG93 ZXZlciwgY2VydGFpbiBmdW5jdGlvbnMgaGF2ZSBub3QgYmVlbiBjbGVhcmx5PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRlZmluZWQuJm5ic3A7IEZvciBleGFtcGxlIGluIHRo ZSBTcGxpdCBNQUMgbW9kZSBkZXNjcmlwdGlvbiwgdGhlIElFRUU8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgODAyLjExIGVuY3J5cHRpb24gaXMgc3BlY2lmaWVkIGFzIGxvY2F0 ZWQgaW4gZWl0aGVyIHRoZSBBQyBvciB0aGUgV1RQPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IHdpdGggbm8gY2xlYXIgd2F5IGZvciB0aGUgQUMgdG8gaW5mb3JtIHRoZSBXVFAg d2hlcmUgaXQgc2hvdWxkIGJlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBU aGlzIGxhY2sgb2Ygc3BlY2lmaWNhdGlvbiBsZWFkcyB0byBpbnRlcm9wZXJhYmlsaXR5IGVzcGVj aWFsbHkgd2hlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBBQyBhbmQgV1RQ IGNvbWUgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycy4mbmJzcDsgVG8gc29sdmUgdGhlIHByb2JsZW0s IHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbiBk ZWZpbmVzIGEgSUVFRSA4MDIuMTEgTUFDIHByb2ZpbGUgd2hlcmUgZWFjaCBwcm9maWxlPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHNwZWNpZmllcyBhbiB1bmFtYmlndW91cyBk aXZpc2lvbiBvZiBmdW5jdGlvbmFsaXR5IGJldHdlZW4gdGhlIFdUUDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBhbmQgQUMuJm5ic3A7IFRoZSBJRUVFIDgwMi4xMSBNQUMgcHJv ZmlsZSBpcyB1c2VkIGFzIGZvbGxvd3M6IHRoZSBXVFA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgaW5mb3JtcyB0aGUgQUMgb2YgdGhlIHN1cHBvcnRlZCBwcm9maWxlcyBkdXJp bmcgdGhlIGRpc2NvdmVyeSBvciBqb2luPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IHByb2Nlc3MgYW5kIHRoZSBBQyBjb25maWd1cmVzIHRoZSBXVFAgd2l0aCBvbmUgb2YgdGhl IHN1cHBvcnRlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwcm9maWxlcyB3 aGlsZSBjb25maWd1cmluZyB0aGUgV0xBTi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50bzxicj48 YnI+VGhlIENBUFdBUCBwcm90b2NvbCBkZWZpbmVzIHR3byBlbnRpdGllczogYSBXaXJlbGVzcyBU cmFuc21pc3Npb24gUG9pbnQgKFdUUCkgYW5kIGFuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IEFjY2VzcyBDb250cm9sbGVyIChBQykuJm5ic3A7IFRoZSBDQVBXQVAgcHJvdG9j b2wgYmluZGluZyBmb3IgSUVFRSA4MDIuMTEgZGVmaW5lcyB0d28gTUFDIChNZWRpdW0gQWNjZXNz PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IENvbnRyb2wpIG1vZGVzIGZvciBJ RUVFIDgwMi4xMSBXVFA6IFNwbGl0IGFuZCBMb2NhbCBNQUMsIGFuZCBkZXNjcmliZXMgdGhlIHJl cXVpcmVkIGZ1bmN0aW9uYWxpdHkgc3BsaXQgYmV0d2VlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyB0aGUgV1RQIGFuZCBBQyBmb3IgZWFjaCBtb2RlLiZuYnNwOyBIb3dldmVy LCBpbiB0aGUgc3BsaXQgTUFDIG1vZGUsIHRoZSBwYXJ0aXRpb25pbmcgb2YgZW5jcnlwdGlvbi9k ZWNyeXB0aW9uIGZ1bmN0aW9ucyBhcmUgbm90IGJlZW4gY2xlYXJseTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyBjbGVhcmx5IGRlZmluZWQuJm5ic3A7IEluIHRoZSBTcGxpdCBN QUMgbW9kZSBkZXNjcmlwdGlvbiwgSUVFRTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyA4MDIuMTEgZW5jcnlwdGlvbiBpcyBzcGVjaWZpZWQgYXMgbG9jYXRlZCBpbiBlaXRoZXIg YXQgdGhlIEFDIG9yIHRoZSBXVFA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg d2l0aCBubyBjbGVhciB3YXkgZm9yIHRoZSBBQyB0byBpbmZvcm0gdGhlIFdUUCBvZiB3aGVyZSB0 aGUgZW5jcnlwdGlvbiBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSBsb2NhdGVkLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIGxhY2sgb2Ygc3BlY2lmaWNhdGlvbiBsZWFk cyB0byBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcywgZXNwZWNpYWxseSB3aGVuIHRoZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBBQyBhbmQgV1RQIGNvbWUgZnJvbSBkaWZmZXJl bnQgdmVuZG9ycy4mbmJzcDsgVG8gcHJldmVudCBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlcywgdGhp czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzcGVjaWZpY2F0aW9uIGRlZmlu ZXMgYW4gSUVFRSA4MDIuMTEgTUFDIHByb2ZpbGUgbWVzc2FnZSBlbGVtZW50IGluIHdoaWNoIGVh Y2ggcHJvZmlsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzcGVjaWZpZXMg YW4gdW5hbWJpZ3VvdXMgZGl2aXNpb24gb2YgZW5jcnlwdGlvbiBmdW5jdGlvbmFsaXR5IGJldHdl ZW4gdGhlIFdUUDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBhbmQgQUMuJm5i c3A7IFRoZSBJRUVFIDgwMi4xMSBNQUMgcHJvZmlsZSBpcyB1c2VkIGFzIGZvbGxvd3M6IHRoZSBX VFA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW5mb3JtcyB0aGUgQUMgb2Yg dGhlIHN1cHBvcnRlZCBwcm9maWxlcyBkdXJpbmcgdGhlIGRpc2NvdmVyeSBvciBqb2luPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHByb2Nlc3MgYW5kIHRoZSBBQyBjb25maWd1 cmVzIHRoZSBXVFAgd2l0aCBvbmUgb2YgdGhlIHN1cHBvcnRlZDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyBwcm9maWxlcyB3aGVuIGNvbmZpZ3VyaW5nIHRoZSBXTEFOLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBJbiBzZWN0aW9uIDEsIGVuZCBv ZiBmaXJzdCBwYXJhZ3JhcGgsIGNoYW5nZSBmcm9tICZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHBy ZT4mcXVvdDtvcGVyYXRvcnMgd2lsbCBleHBlcmllbmNlIGRpZmZpY3VsdHkgaW4gaW50ZXJvcGVy YXRpbmcgV1RQcyBhbmQgQUNzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuJnF1b3Q7PGJyPjxicj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPnRvPGJy PiZxdW90O29wZXJhdG9ycyB3aWxsIGV4cGVyaWVuY2UgaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMg d2l0aCBXVFBzIGFuZCBBQ3MgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycy4mcXVvdDs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT40LiBJbiBzZWN0aW9uIDEsIGVuZCBvZiBzZWNvbmQgcGFyYWdyYXBoLCBp bnNlcnQgYSBjb21tYSBhZnRlciAmcXVvdDtXVFAvQUMmcXVvdDs6PGJyPjxicj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mcXVvdDtpcyBzcGVjaWZpZWQgYXMgV1RQL0FDIGltcGx5aW5nIHRvICZx dW90O2lzIHNwZWNpZmllZCBhcyBXVFAvQUMsIGltcGx5aW5nJnF1b3Q7PG86cD48L286cD48L3By ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPGJyPg0KPGJyPg0KRG9yb3Ro eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXByIDIyLCAyMDE0IGF0IDk6MTYg UE0sIFJhamVzaCBQYXpoeWFubnVyIChycGF6aHlhbikgJmx0OzxhIGhyZWY9Im1haWx0bzpycGF6 aHlhbkBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5ycGF6aHlhbkBjaXNjby5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIFdhcnJl biw8YnI+DQo8YnI+DQpJIHdpbGwgYWRkcmVzcyB0aGUgbml0cyBhbmQgc3VibWl0IGEgbmV3IHZl cnNpb24uPGJyPg0KPGJyPg0KVGhhbmtzIGZvciBzaGVwaGVyZGluZyB0aGlzIHRocm91Z2guPGJy Pg0KPGJyPg0KUmVnYXJkczxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8 c3BhbiBjbGFzcz0iaG9lbnpiIj5SYWplc2g8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KRnJvbTogV2FycmVuIEt1bWFyaSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp3YXJyZW5Aa3Vt YXJpLm5ldCI+d2FycmVuQGt1bWFyaS5uZXQ8L2E+XTxicj4NClNlbnQ6IFR1ZXNkYXksIEFwcmls IDIyLCAyMDE0IDExOjE5IEFNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzpvcHNhd2dAaWV0Zi5v cmciPm9wc2F3Z0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW9wc2F3 Zy1jYXB3YXAtaHlicmlkbWFjQHRvb2xzLmlldGYub3JnIj4NCmRyYWZ0LWlldGYtb3BzYXdnLWNh cHdhcC1oeWJyaWRtYWNAdG9vbHMuaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogUmU6IFN0YXJ0IG9m IFdHTEMgZm9yIGRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWM8YnI+DQo8YnI+DQpP biBNb24sIEFwciA3LCAyMDE0IGF0IDEyOjQ0IFBNLCBXYXJyZW4gS3VtYXJpICZsdDs8YSBocmVm PSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiPndhcnJlbkBrdW1hcmkubmV0PC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0OyBEZWFyIG9wc2F3ZyBXRyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgYXV0 aG9ycyBvZiBkcmFmdC1pZXRmLW9wc2F3Zy1jYXB3YXAtaHlicmlkbWFjIGhhdmUgaW5kaWNhdGVk IHRoYXQ8YnI+DQomZ3Q7IHRoZXkgYmVsaWV2ZSB0aGF0IHRoZSBkb2N1bWVudCBpcyByZWFkeSwg YW5kIGhhdmUgYXNrZWQgZm9yIFdvcmtpbmc8YnI+DQomZ3Q7IEdyb3VwIExhc3QgQ2FsbC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIGhlcmU6PGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3 Zy1jYXB3YXAtaHlicmlkbWFjLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJpZG1hYy88L2E+PGJy Pg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIHJldmlldyB0aGlzIGRyYWZ0IHRvIHNlZSBpZiB5b3Ug dGhpbmsgaXQgaXMgcmVhZHkgZm9yPGJyPg0KJmd0OyBwdWJsaWNhdGlvbiBhbmQgc2VuZCBjb21t ZW50cyB0byB0aGUgbGlzdCwgY2xlYXJseSBzdGF0aW5nIHlvdXIgdmlldy48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBUaGlzIFdHTEMgZW5kcyBNb24gMjEtQXByLTIwMTQuPGJyPg0KPGJyPg0KVGhpcyBX R0xDIGhhcyBjb25jbHVkZWQsIHRoYW5rcyB0byBldmVyeW9uZSBmb3IgdGhlIGZlZWRiYWNrLjxi cj4NCjxicj4NClRoZSBjaGFpcnMganVzdCBtZXQsIGFuZCBoYXZlIGRlY2lkZWQgdGhhdCB0aGVy ZSBpcyBzdWZmaWNpZW50IHN1cHBvcnQgdG8gcHJvZ3Jlc3MgdGhpcy48YnI+DQpBdXRob3JzLCBw bGVhc2Ugc3BpbiBhbm90aGVyIHZlcnNpb24gd2l0aCB0aGUgbml0cyBhZGRyZXNzZWQgKHNvbWUg dHlwbydzLCB0aGUgbml0cyBjaGVja2VyIG1hZGUgZ3J1bXB5ZmFjZSwgZXRjKSAtLSB0aGlzIHdp bGwgaGVscCBzcGVlZCBpdCB0aHJvdWdoIHRoZSBJRVNHLjxicj4NCk9uY2UgeW91IHJlc3VibWl0 IHdpdGggdGhlc2UgZG9uZSwgcGxlYXNlIHBva2UgbWUgLyB1cyB0byBzdWJtaXQgdG8gdGhlIElF U0cuPGJyPg0KPGJyPg0KVGhhbmtzIGZvciBhbGwgdGhlIGhhcmQgd29yay48YnI+DQpXPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgV2FycmVu IEt1bWFyaTxicj4NCiZndDsgKGFzIG9wc2F3ZyBXRyBjby1jaGFpcik8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9QU0FXRyBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T1BTQVdHQGlldGYub3JnIj5PUFNBV0dA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vcHNhd2ciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29wc2F3ZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4ED2E36A22261145861BAB2C24088B4320F8B75Exmbalnx09ciscoc_-- From nobody Tue May 13 13:08:16 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA20C1A013F for ; Tue, 13 May 2014 13:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NooWSDqYYRRO for ; Tue, 13 May 2014 13:07:43 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A3F8B1A01C6 for ; Tue, 13 May 2014 13:07:40 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fa1so687127pad.11 for ; Tue, 13 May 2014 13:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=VsqNxwU1W6SNRgxO7QggAkvGnzGYQ3Axoz4DpkHDwSE=; b=XmlCF2tSPZ6H+L8imgeH4JnmWwWZe71DLOFQV7z0q7ZkikQcZwmrJQSf5HDZD/yDGm 9XPCLeGw5U1w6mPbqdJlIvhXwIQWlG1Fuy/+RrrhP7sZk+Bh2LTW7bAgz2edWuv6LcHy dphreR8YAIGMmkz1Q+5vhBOi11JRwoeHClUZi2dBdc8IqJbpyeRLV0WB8SaSBcz9Iou9 qKmgZUewDeZFz1YWNTWnJ2MqPa3Sfwp0va8TixfkW3+CkDUXqgMJEfNjixD3T8DwRmFL r9q6LsVNmBMz0Tk4aZPNudPy1JfZqZ4CSRxs1UUa6bpDZrCmaNFOYuFEmhvM6hQ8fEot Yk9A== X-Received: by 10.67.14.69 with SMTP id fe5mr66962554pad.120.1400011654414; Tue, 13 May 2014 13:07:34 -0700 (PDT) Received: from [192.168.178.20] (8.193.69.111.dynamic.snap.net.nz. [111.69.193.8]) by mx.google.com with ESMTPSA id gu1sm29774289pbd.0.2014.05.13.13.07.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 May 2014 13:07:33 -0700 (PDT) Message-ID: <53727B87.1010008@gmail.com> Date: Wed, 14 May 2014 08:07:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/UPVBRCZc6-LVoXDBZIynKBLdSsA Subject: [OPSAWG] BOF proposal on autonomic networking use cases X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 20:07:48 -0000 FYI http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal Brian From nobody Tue May 13 16:39:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB791A0266; Tue, 13 May 2014 16:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gf43EPtECOVf; Tue, 13 May 2014 16:38:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 951951A0153; Tue, 13 May 2014 16:38:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140513233859.26228.43665.idtracker@ietfa.amsl.com> Date: Tue, 13 May 2014 16:38:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/B31jxho12We4oIUC6iTghMCudYc Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-extension-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 23:39:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : CAPWAP Extension for 802.11n and Power/channel Autoconfiguration Authors : Yifan Chen Dapeng Liu Hui Deng Lei Zhu Filename : draft-ietf-opsawg-capwap-extension-04.txt Pages : 17 Date : 2014-05-13 Abstract: The CAPWAP binding for 802.11 is specified by RFC5416 and it was based on IEEE 802-11.2007 standard. Several new amendments of 802.11 have been published since RFC5416 was published in 2009. 802.11n is one of those amendments and it has been widely used in real deployment. This document extends the CAPWAP binding for 802.11 to support 802.11n and also defines a power and channel auto configuration extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-extension/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-capwap-extension-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 19 21:12:00 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D4C1A0236 for ; Mon, 19 May 2014 21:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDOfG7ynuWez for ; Mon, 19 May 2014 21:11:55 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB04B1A0230 for ; Mon, 19 May 2014 21:11:55 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rq2so6657089pbb.17 for ; Mon, 19 May 2014 21:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=Nj5+HJBjN348e4q5hh437Ct3Z1/5J4by+Cq4YGfbQD8=; b=Oj2B+lBc6uASrn+9DllvwFVCCQZ8XzOG89gIQ3uUjoMEarzcDpfFzmRJweBjttoNMG L8/kI9lX9B6MYbnwzfiS3meUY+K1by/BnZtOPbjGQnfihNYB0LdhEn1nqBE1CoNUE6no 5EGTz28Z3PMBklOZaFpz/1eQRjhH4xNzW2l4n+3/XW0kL3fnDxSy4xg7N9BV9YVevQae 2dsRIFxZLwBSK2gbojcCdy23W8RDWimK9xQXdKN55642zl4YsmZDFfKQsXqa3rW852kR tIYskmEcmvNF87L8IlTtSZ6uEP3PhRg9RzoNxYp89XayslYdHl05TB5JdR3QrO9gTw33 2uFg== X-Received: by 10.68.139.36 with SMTP id qv4mr47509294pbb.82.1400559115436; Mon, 19 May 2014 21:11:55 -0700 (PDT) Received: from [192.168.178.23] (20.199.69.111.dynamic.snap.net.nz. [111.69.199.20]) by mx.google.com with ESMTPSA id hb10sm496477pbd.75.2014.05.19.21.11.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 May 2014 21:11:54 -0700 (PDT) Message-ID: <537AD60D.4060000@gmail.com> Date: Tue, 20 May 2014 16:11:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Nkv5toasvWA_X9W6xr5me-s0YSg Subject: [OPSAWG] [Fwd: I-D Action: draft-jiang-config-negotiation-ps-03.txt] X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 04:11:59 -0000 Hi, This has been updated according to feedback received in London and more recently. The main change is that RESTCONF and HNCP are now discussed in the "Existing protocols" section. The next revision would logically come after the proposed UCAN BOF has allowed us to evaluate several use cases. Brian -------- Original Message -------- Subject: I-D Action: draft-jiang-config-negotiation-ps-03.txt Date: Mon, 19 May 2014 21:04:57 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Network Configuration Negotiation Problem Statement and Requirements Authors : Sheng Jiang Yuanbin Yin Brian Carpenter Filename : draft-jiang-config-negotiation-ps-03.txt Pages : 15 Date : 2014-05-19 Abstract: This document describes a problem statement and general requirements for distributed autonomic configuration of multiple aspects of networks, in particular carrier networks. The basic model is that network elements need to negotiate configuration settings with each other to meet overall goals. The document describes a generic negotiation behavior model. The document also reviews whether existing management and configuration protocols may be suitable for autonomic networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-jiang-config-negotiation-ps/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-jiang-config-negotiation-ps-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-jiang-config-negotiation-ps-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue May 20 09:31:58 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F001A1A079F; Tue, 20 May 2014 09:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kftmqz6H39J; Tue, 20 May 2014 09:26:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E811A079D; Tue, 20 May 2014 09:26:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: Melinda Shore , Scott Bradner , Warren Kumari X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140520162659.18390.49768.idtracker@ietfa.amsl.com> Date: Tue, 20 May 2014 09:26:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/XxNEU-bn59OcjgoRSPgPvMC6qjo X-Mailman-Approved-At: Tue, 20 May 2014 09:31:57 -0700 Cc: dstanley@arubanetworks.com, pthaler@broadcom.com, draft-ietf-opsawg-capwap-hybridmac.all@tools.ietf.org, opsawg@ietf.org, Sean Turner Subject: [OPSAWG] New Liaison Statement, "Liaison from IEEE 802.11 on IEEE 802.11 MAC Profile for CAPWAP draft" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 16:27:01 -0000 Title: Liaison from IEEE 802.11 on IEEE 802.11 MAC Profile for CAPWAP draft Submission Date: 2014-05-20 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1325/ From: IEEE 802.11 (Adrian Stephens ) To: Operations and Management Area Working Group (Melinda Shore , Scott Bradner , Warren Kumari ) Cc: Benoit Claise ,Joel Jaeggli ,opsawg@ietf.org,Sean Turner ,dromasca@avaya.com,warren@kumari.net,melinda.shore@gmail.com,sob@harvard.edu,dstanley@arubanetworks.com,pthaler@broadcom.com,bclaise@cisco.com,draft-ietf-opsawg-capwap-hybridmac.all@tools.ietf.org Response Contact: Technical Contact: Purpose: In response Referenced liaison: Alternate Tunnel Encapsulation for Data Frames in CAPWAP. (http://datatracker.ietf.org/liaison/1312/) Body: Thank you for the opportunity to review the "IEEE 802.11 MAC Profile for CAPWAP”, https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ document. The IEEE 802.11 Working Group has reviewed this document and has no comments on its content. We will inform IEEE 802.11 WG members of this work, and welcome further requests from the OPSAWG for information or clarification of the IEEE 802.11 standard. Thank you, Adrian P STEPHENS (Dr.) IEEE 802.11 Working Group Chair Office: +44 (1793) 404 825 Mobile: +44 (7920) 084900 USA Mobile: +1 (408) 239 7485 ---------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 Attachments: No document has been attached From nobody Sun May 25 13:15:44 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA42E1A03E6 for ; Sun, 25 May 2014 13:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcsRyo145Vye for ; Sun, 25 May 2014 13:15:41 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C231B1A03E1 for ; Sun, 25 May 2014 13:15:41 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lf10so6560586pab.34 for ; Sun, 25 May 2014 13:15:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZJoEHR7MFKkvvIuGpHAfwRpwiE4V+BXD0GprMX20cb0=; b=H5pIZ/bbSOFgDcRjSdMxN72cUBE9dzsXNJzLWdJoITv0/inAMBwnToGk0glaksw3nI HSF6lym0ys9TswRlIumTTvS6Hhlmv4cwdTqSoF2/6/rXuplInYkMCT19awsIj/XELHn8 ysseqNtYZisCbl9pS+/FshLzgt6mSGuDUtg1V8RuQ+7oEkU37oAVIvl3ml8ocBz0ePhI NXk2zumRAZuO6zdb8f35ZBUL2LYcJoxO10CkxXkFlLjqarQYCKePvUl+ZPuMWx+i+779 43eNcde2iy9Mb+tpeqPpWqD3uVNp9y+XoRBSGLYzoEHHEN0NakxmPFmRmcDEculOJ843 3gPQ== X-Received: by 10.66.249.165 with SMTP id yv5mr14600683pac.79.1401048939298; Sun, 25 May 2014 13:15:39 -0700 (PDT) Received: from [192.168.178.23] (6.192.69.111.dynamic.snap.net.nz. [111.69.192.6]) by mx.google.com with ESMTPSA id vm3sm14719545pbc.45.2014.05.25.13.15.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 May 2014 13:15:38 -0700 (PDT) Message-ID: <53824F67.7070302@gmail.com> Date: Mon, 26 May 2014 08:15:35 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: opsawg@ietf.org References: <53727B87.1010008@gmail.com> In-Reply-To: <53727B87.1010008@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/mfe2Gl8ohCsZZgVO3Llrx3L2VbA Subject: Re: [OPSAWG] BOF proposal on autonomic networking use cases X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 20:15:43 -0000 Just to remind everybody: we're interested in additional use cases for autonomic networking, posted as I-Ds as soon as possible. The BOF proposal deadline is in 10 days (June 6th) and we'd like to have more use cases before then. Regards Brian On 14/05/2014 08:07, Brian E Carpenter wrote: > FYI > > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal > > Brian > > From nobody Mon May 26 00:24:54 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991931A0024 for ; Mon, 26 May 2014 00:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.651 X-Spam-Level: *** X-Spam-Status: No, score=3.651 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9okRZoYJ0nUK for ; Mon, 26 May 2014 00:24:50 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id 228101A0023 for ; Mon, 26 May 2014 00:24:50 -0700 (PDT) Received: from [172.20.10.2] (pw126255073011.9.panda-world.ne.jp [126.255.73.11]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 23F9C108DF45; Mon, 26 May 2014 16:24:45 +0900 (JST) From: Hirochika Asai Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Date: Mon, 26 May 2014 16:24:38 +0900 To: "opsawg@ietf.org" Message-Id: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/f2Yx4LSX_uQgt89zmZiz5Qyz710 Subject: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 07:24:51 -0000 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 --=20 Hirochika Asai , The University of Tokyo From nobody Mon May 26 02:22:07 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF41A007E for ; Mon, 26 May 2014 02:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uv9NN-NX-Kzt for ; Mon, 26 May 2014 02:22:04 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009C81A0069 for ; Mon, 26 May 2014 02:22:04 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2365F1A0071 for ; Mon, 26 May 2014 11:22:00 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gwiKwmtkXtL4 for ; Mon, 26 May 2014 11:21:56 +0200 (CEST) Received: from mail-gw-int (unknown [10.53.40.207]) by a.mx.secunet.com (Postfix) with ESMTP id 4B8341A007E for ; Mon, 26 May 2014 11:21:56 +0200 (CEST) Received: from [10.53.40.204] (port=32506 helo=mail-essen-01.secunet.de) by mail-gw-int with esmtp (Exim 4.80 #2 (Debian)) id 1Wor6S-0007TP-9s for ; Mon, 26 May 2014 11:21:56 +0200 Received: from [172.16.40.201] (172.16.40.201) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 26 May 2014 11:21:56 +0200 Message-ID: <538307B4.9060507@secunet.com> Date: Mon, 26 May 2014 11:21:56 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: References: <20140506093829.24743.53393.idtracker@ietfa.amsl.com> <5368BFC8.2010101@secunet.com> In-Reply-To: <5368BFC8.2010101@secunet.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [172.16.40.201] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/NYrEhfLj39H-T3bf62pcNNwrjdk Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-hmac-sha-2-usm-snmp-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 09:22:05 -0000 so far, there has been no feedback on the new version, but the discussion on the previous one indicated considerable interest. Does the silence indicate "no objections" or are there still issues? Should the draft be adopted by the WG? Johannes Johannes Merkle wrote on 06.05.2014 12:56: > Hi, > > after a fruitful discussion on the first version (http://www.ietf.org/mail-archive/web/opsawg/current/msg03022.html), we > have updated draft-hmac-sha-2-usm-snmp. > > Major changes are: > > - Protocol names unified to usmHMACXXXSHAYYYAuthProtocol. > > - Definition of mandatory (usmHMAC192SHA256AuthProtocol) and recommended (usmHMAC256SHA512AuthProtocol) protocols. > (I just noticed that the abstract and introduction still talk about "new optional authentication protocols"; this is an > error I will fix in the next revision) > > - Key word reference (RFC 2119) added > > - MIB biolerplate added (Sections on The Internet-Standard Management Framework, Structure of the MIB Module, > Relationship to Other MIB Modules) > > - Security Considerations considerably extended (guidance on cryptographic strength, key derivation from passwords, > access to MIB) > > - IANA considerations clarified and comments for RFC Ed in MIB definition added > > Comments are welcome. There was considerable interest in adoption by the WG, so please stand up if you have issues. > > Johannes > > -------- Original Message -------- > Betreff: New Version Notification for draft-hmac-sha-2-usm-snmp-01.txt > Datum: Tue, 6 May 2014 02:38:29 -0700 > Von: > An: Johannes Merkle , Manfred Lochter , Manfred Lochter > , Johannes Merkle > > > A new version of I-D, draft-hmac-sha-2-usm-snmp-01.txt > has been successfully submitted by Johannes Merkle and posted to the > IETF repository. > > Name: draft-hmac-sha-2-usm-snmp > Revision: 01 > Title: HMAC-SHA-2 Authentication Protocols in USM for SNMP > Document date: 2014-05-06 > Group: Individual Submission > Pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-hmac-sha-2-usm-snmp-01.txt > Status: https://datatracker.ietf.org/doc/draft-hmac-sha-2-usm-snmp/ > Htmlized: http://tools.ietf.org/html/draft-hmac-sha-2-usm-snmp-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-hmac-sha-2-usm-snmp-01 > > Abstract: > This memo specifies new optional HMAC-SHA-2 authentication protocols > for the User-based Security Model (USM) for SNMPv3 defined in RFC > 3414. > > > > From shaochunju@hotmail.com Mon May 26 02:21:34 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A447D1A007E for ; Mon, 26 May 2014 02:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NumFSETaEcG for ; Mon, 26 May 2014 02:21:33 -0700 (PDT) Received: from BAY004-OMC1S9.hotmail.com (bay004-omc1s9.hotmail.com [65.54.190.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC741A0069 for ; Mon, 26 May 2014 02:21:33 -0700 (PDT) Received: from BAY175-W9 ([65.54.190.61]) by BAY004-OMC1S9.hotmail.com with Microsoft SMTPSVC(7.5.7601.22678); Mon, 26 May 2014 02:21:30 -0700 X-TMN: [eKNdpvRmVnZhiisnK9zZ9fw1IwRp889x] X-Originating-Email: [shaochunju@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_102cb9af-1123-4b1d-85e9-dc74fff3799c_" From: chunju shao To: "opsawg@ietf.org" , "shaochunju@chinamobile.com" Date: Mon, 26 May 2014 17:21:30 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 May 2014 09:21:30.0976 (UTC) FILETIME=[E13B7600:01CF78C3] Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/0lkFeGHULQXEIA415QJwqPX0jqo Subject: Re: [OPSAWG] minder about IPR relating to draft-ietf-opsawg-capwap-hybridmac X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 09:22:26 -0000 --_102cb9af-1123-4b1d-85e9-dc74fff3799c_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KIA0KSSBhbSBub3QgYXdhcmVkIG9mIGFueSBJUFIgb24gdGhpcyBkcmFmdCwN CiANCkJlc3QgcmVnYXJkcywNCiANClNoYW8gQ2h1bmp1DQogDQogDQogDQogDQogDQpEZWFyIG9w c2F3ZyBXRywNCg0KQmUgbm90IGFsYXJtZWQuDQpUaGlzIGVtYWlsIHdhcyBjcmVhdGVkIHRvIHNh dGlzZnkgUkZDIDY3MDIgIlByb21vdGluZyBDb21wbGlhbmNlIHdpdGgNCkludGVsbGVjdHVhbCBQ cm9wZXJ0eSBSaWdodHMgKElQUikiDQooaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmYy9yZmM2NzAy LnR4dCkuDQoNCg0KVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJp ZG1hYyBoYXZlIGFza2VkIGZvciBhDQpXb3JraW5nIEdyb3VwIExhc3QgQ2FsbC4gV2hpbGUgcnVu bmluZyB0aGUgV29ya2luZyBHcm91cCBMYXN0IENhbGwsIHdlDQp3b3VsZCBsaWtlIHRvIGNoZWNr IHdoZXRoZXIgYW55IGNsYWltcyBvZiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzDQooSVBS KSBvbiB0aGUgZG9jdW1lbnQgaGF2ZSBub3QgeWV0IGJlZW4gZGlzY2xvc2VkLg0KDQpBcmUgeW91 IHBlcnNvbmFsbHkgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8NCmRyYWZ0LWlldGYt b3BzYXdnLWNhcHdhcC1oeWJyaWRtYWM/ICBJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4NCmRpc2Ns b3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXM/DQooU2VlIFJGQ3MgMzk3OSwg NDg3OSwgMzY2OSwgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscy4pDQoNCklmIHlvdSBhcmUgYSBk b2N1bWVudCBhdXRob3Igb3IgbGlzdGVkIGNvbnRyaWJ1dG9yIG9uIHRoaXMgZG9jdW1lbnQsDQpw bGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlv dSBhcmUNCnBlcnNvbmFsbHkgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gIFdlIG1pZ2h0IG5v dCBiZSBhYmxlIHRvIGFkdmFuY2UNCnRoaXMgZG9jdW1lbnQgdG8gdGhlIG5leHQgc3RhZ2UgdW50 aWwgd2UgaGF2ZSByZWNlaXZlZCBhIHJlcGx5IGZyb20NCmVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQg Y29udHJpYnV0b3IuDQoNCklmIHlvdSBhcmUgb24gdGhlIG9wc2F3ZyBXRyBlbWFpbCBsaXN0IGJ1 dCBhcmUgbm90IGFuIGF1dGhvciBvciBsaXN0ZWQNCmNvbnRyaWJ1dG9yIGZvciB0aGlzIGRvY3Vt ZW50LCB5b3UgYXJlIHJlbWluZGVkIG9mIHlvdXIgb3Bwb3J0dW5pdHkNCmZvciBhIHZvbHVudGFy eSBJUFIgZGlzY2xvc3VyZSB1bmRlciBCQ1AgNzkuICBQbGVhc2UgZG8gbm90IHJlcGx5DQp1bmxl c3MgeW91IHdhbnQgdG8gbWFrZSBzdWNoIGEgdm9sdW50YXJ5IGRpc2Nsb3N1cmUuDQoNCk9ubGlu ZSB0b29scyBmb3IgZmlsaW5nIElQUiBkaXNjbG9zdXJlcyBjYW4gYmUgZm91bmQgYXQNCjxodHRw Oi8vd3d3LmlldGYub3JnL2lwci9maWxlLWRpc2Nsb3N1cmU+Lg0KDQpUaGFua3MsDQpXYXJyZW4g S3VtYXJpDQooYXMgb3BzYXdnIFdHIGNvLWNoYWlyKQ0KDQogCQkgCSAgIAkJICA= --_102cb9af-1123-4b1d-85e9-dc74fff3799c_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SGVsbG8gYWxsLDxCUj4mbmJzcDs8QlI+SSBhbSBub3Qg YXdhcmVkIG9mIGFueSBJUFIgb24gdGhpcyBkcmFmdCw8QlI+Jm5ic3A7PEJSPkJlc3QgcmVnYXJk cyw8QlI+Jm5ic3A7PEJSPlNoYW8gQ2h1bmp1PEJSPiZuYnNwOzxCUj4mbmJzcDs8QlI+Jm5ic3A7 PEJSPiZuYnNwOzxCUj4mbmJzcDs8QlI+RGVhciBvcHNhd2cgV0csPGJyPjxicj5CZSBub3QgYWxh cm1lZC48YnI+VGhpcyBlbWFpbCB3YXMgY3JlYXRlZCB0byBzYXRpc2Z5IFJGQyA2NzAyICJQcm9t b3RpbmcgQ29tcGxpYW5jZSB3aXRoPGJyPkludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgKElQ UikiPGJyPig8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjL3JmYzY3MDIudHh0IiBy ZWw9Im5vZm9sbG93Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjL3JmYzY3MDIudHh0PC9hPiku PGJyPjxicj48YnI+VGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1vcHNhd2ctY2Fwd2FwLWh5YnJp ZG1hYyBoYXZlIGFza2VkIGZvciBhPGJyPldvcmtpbmcgR3JvdXAgTGFzdCBDYWxsLiBXaGlsZSBy dW5uaW5nIHRoZSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCwgd2U8YnI+d291bGQgbGlrZSB0byBj aGVjayB3aGV0aGVyIGFueSBjbGFpbXMgb2YgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0czxi cj4oSVBSKSBvbiB0aGUgZG9jdW1lbnQgaGF2ZSBub3QgeWV0IGJlZW4gZGlzY2xvc2VkLjxicj48 YnI+QXJlIHlvdSBwZXJzb25hbGx5IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvPGJy PmRyYWZ0LWlldGYtb3BzYXdnLWNhcHdhcC1oeWJyaWRtYWM/Jm5ic3A7IElmIHNvLCBoYXMgdGhp cyBJUFIgYmVlbjxicj5kaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVz Pzxicj4oU2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSwgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cy4pPGJyPjxicj5JZiB5b3UgYXJlIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGxpc3RlZCBjb250cmli dXRvciBvbiB0aGlzIGRvY3VtZW50LDxicj5wbGVhc2UgcmVwbHkgdG8gdGhpcyBlbWFpbCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmU8YnI+cGVyc29uYWxseSBhd2FyZSBvZiBh bnkgcmVsZXZhbnQgSVBSLiZuYnNwOyBXZSBtaWdodCBub3QgYmUgYWJsZSB0byBhZHZhbmNlPGJy PnRoaXMgZG9jdW1lbnQgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgd2UgaGF2ZSByZWNlaXZlZCBh IHJlcGx5IGZyb208YnI+ZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci48YnI+PGJy PklmIHlvdSBhcmUgb24gdGhlIG9wc2F3ZyBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGFuIGF1 dGhvciBvciBsaXN0ZWQ8YnI+Y29udHJpYnV0b3IgZm9yIHRoaXMgZG9jdW1lbnQsIHlvdSBhcmUg cmVtaW5kZWQgb2YgeW91ciBvcHBvcnR1bml0eTxicj5mb3IgYSB2b2x1bnRhcnkgSVBSIGRpc2Ns b3N1cmUgdW5kZXIgQkNQIDc5LiZuYnNwOyBQbGVhc2UgZG8gbm90IHJlcGx5PGJyPnVubGVzcyB5 b3Ugd2FudCB0byBtYWtlIHN1Y2ggYSB2b2x1bnRhcnkgZGlzY2xvc3VyZS48YnI+PGJyPk9ubGlu ZSB0b29scyBmb3IgZmlsaW5nIElQUiBkaXNjbG9zdXJlcyBjYW4gYmUgZm91bmQgYXQ8YnI+Jmx0 OzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByL2ZpbGUtZGlzY2xvc3VyZSIgcmVsPSJu b2ZvbGxvdyI+aHR0cDovL3d3dy5pZXRmLm9yZy9pcHIvZmlsZS1kaXNjbG9zdXJlPC9hPiZndDsu PGJyPjxicj5UaGFua3MsPGJyPldhcnJlbiBLdW1hcmk8YnI+KGFzIG9wc2F3ZyBXRyBjby1jaGFp cik8YnI+PEJSPiAJCSAJICAgCQkgIDwvZGl2PjwvYm9keT4NCjwvaHRtbD4= --_102cb9af-1123-4b1d-85e9-dc74fff3799c_-- From nobody Mon May 26 02:31:51 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3D61A0092 for ; Mon, 26 May 2014 02:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOahXhOnm_hG for ; Mon, 26 May 2014 02:31:46 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A4991A0099 for ; Mon, 26 May 2014 02:31:46 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B85D0748; Mon, 26 May 2014 11:31:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8fAFg531UAdl; Mon, 26 May 2014 11:31:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 May 2014 11:31:41 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18F8E20017; Mon, 26 May 2014 11:31:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id adHkk7WwiUQA; Mon, 26 May 2014 11:31:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E917E20013; Mon, 26 May 2014 11:31:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 832592CF68D1; Mon, 26 May 2014 11:31:38 +0200 (CEST) Date: Mon, 26 May 2014 11:31:37 +0200 From: Juergen Schoenwaelder To: Hirochika Asai Message-ID: <20140526093137.GE6042@elstar.local> Mail-Followup-To: Hirochika Asai , "opsawg@ietf.org" References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Fh84gDZt7f3OOz1XSGC2yKsN-qQ Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 09:31:48 -0000 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: > 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 , The University of Tokyo > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > 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 From nobody Mon May 26 08:43:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56441A01A9 for ; Mon, 26 May 2014 08:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJBUtO6_APnx for ; Mon, 26 May 2014 08:42:59 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449321A01A5 for ; Mon, 26 May 2014 08:42:59 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4QFgqo9019992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 May 2014 15:42:53 GMT (envelope-from joelja@bogus.com) Message-ID: <538360F7.10307@bogus.com> Date: Mon, 26 May 2014 08:42:47 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Hirochika Asai , "opsawg@ietf.org" References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> In-Reply-To: <20140526093137.GE6042@elstar.local> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9cOwcMSMPruDmMDTCOw6EwmD0Iah36Lqa" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 26 May 2014 15:42:53 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/gX9jqy97Cc7XkhDcER8IH4b4ouQ Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 15:43:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9cOwcMSMPruDmMDTCOw6EwmD0Iah36Lqa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote: > Asai, >=20 > the IESG statement is here: >=20 > http://www.ietf.org/iesg/statement/writable-mib-module.html >=20 > 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! thanks > /js >=20 > On Mon, May 26, 2014 at 04:24:38PM +0900, Hirochika Asai wrote: >> Dear all, >> >> We'd like to discuss the read-write access in the proposed MIB about v= irtual >> machine monitoring: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-m= ib . >> >> It has 10 read-write objects. All of them do not affect persistent con= figuration >> of hypervisor or virtual machines. However, according to a comment dur= ing >> the previous IETF meeting, the IESG statement also suggests not to inc= lude >> read-write objects even if they do not persist after the restart of th= e 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 monitorin= g 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 f= ile. >> 9. vmPerVMNotificationsEnabled >> 10. vmBulkNotificationsEnabled >> >> I hope you give us your comments on the access of 10 objects. >> >> Thank you. >> Hirochika >> >> --=20 >> Hirochika Asai , The University of Tokyo >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >=20 --9cOwcMSMPruDmMDTCOw6EwmD0Iah36Lqa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlODYPcACgkQ8AA1q7Z/VrI6swCeKC92xaX651W8wD79TQ65skrS GSEAn31qfUO+0zP5+xQAS0VTnLJxZTP6 =bv7t -----END PGP SIGNATURE----- --9cOwcMSMPruDmMDTCOw6EwmD0Iah36Lqa-- From nobody Mon May 26 09:20:47 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E831A01BD for ; Mon, 26 May 2014 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVU0eJdwtVpe for ; Mon, 26 May 2014 09:20:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C761A01C2 for ; Mon, 26 May 2014 09:20:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6C43471A; Mon, 26 May 2014 18:20:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BzjIYNkluCpE; Mon, 26 May 2014 18:20:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 26 May 2014 18:20:34 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92D6020017; Mon, 26 May 2014 18:20:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qFBx8DONSGSz; Mon, 26 May 2014 18:20:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A84920013; Mon, 26 May 2014 18:20:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E54422CF7A25; Mon, 26 May 2014 18:20:33 +0200 (CEST) Date: Mon, 26 May 2014 18:20:33 +0200 From: Juergen Schoenwaelder To: joel jaeggli Message-ID: <20140526162033.GA1312@elstar.local> Mail-Followup-To: joel jaeggli , Hirochika Asai , "opsawg@ietf.org" References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> <538360F7.10307@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538360F7.10307@bogus.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/Cp3sk6-CyjcJ46An8Hjo9qjH-cs Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 16:20:46 -0000 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? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon May 26 09:24:37 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D191A01C2 for ; Mon, 26 May 2014 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pkQu2I7KmME for ; Mon, 26 May 2014 09:24:35 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DADBA1A01BF for ; Mon, 26 May 2014 09:24:34 -0700 (PDT) Received: from mbp.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4QGOTDi020227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 May 2014 16:24:30 GMT (envelope-from joelja@bogus.com) Message-ID: <53836AB8.3020806@bogus.com> Date: Mon, 26 May 2014 09:24:24 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Hirochika Asai , "opsawg@ietf.org" References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> <538360F7.10307@bogus.com> <20140526162033.GA1312@elstar.local> In-Reply-To: <20140526162033.GA1312@elstar.local> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rBF82mCCWA7FQBHh9UKG1sJ6sIoKvwfHm" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 26 May 2014 16:24:30 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/ZZTA7e2a6y8k6HshpD8g6xNFRxk Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 16:24:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rBF82mCCWA7FQBHh9UKG1sJ6sIoKvwfHm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 on= e. >> The statement seems to be serving it's purpose! >> >=20 > Joel, can you please decrypt your message so that it becomes perhaps > actionable? I'm agreeing with you. > /js >=20 --rBF82mCCWA7FQBHh9UKG1sJ6sIoKvwfHm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlODargACgkQ8AA1q7Z/VrKHqQCfbMTxYLDKH3EjmcY3GrjoZI3s VUcAn3LBqFZetzS82wTSe7Am2Yhhgo0s =eISV -----END PGP SIGNATURE----- --rBF82mCCWA7FQBHh9UKG1sJ6sIoKvwfHm-- From nobody Mon May 26 10:48:56 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47001A01F5 for ; Mon, 26 May 2014 10:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFu-woIrZS1Z for ; Mon, 26 May 2014 10:48:52 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id 35EEE1A01EE for ; Mon, 26 May 2014 10:48:52 -0700 (PDT) Received: from [157.82.3.200] (unknown [157.82.3.200]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id CEE5F108DF45; Tue, 27 May 2014 02:48:47 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <53836AB8.3020806@bogus.com> Date: Tue, 27 May 2014 02:48:47 +0900 Content-Transfer-Encoding: 7bit Message-Id: <078CE1DA-BBC2-4EB6-B90D-070EF4BB2CF3@hongo.wide.ad.jp> References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> <538360F7.10307@bogus.com> <20140526162033.GA1312@elstar.local> <53836AB8.3020806@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/XqpWCa-oAdEuYtFbkQRNIqOXNlg Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 17:48:53 -0000 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 iesg@ietf.org, CCing WG? Or ask WG chairs to handle it? Thank you. Hirochika On May 27, 2014, at 1:24 AM, joel jaeggli 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 , The University of Tokyo From nobody Mon May 26 11:55:35 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC311A0227 for ; Mon, 26 May 2014 11:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ib0SIFYXbdwx for ; Mon, 26 May 2014 11:55:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EBA1A021E for ; Mon, 26 May 2014 11:55:31 -0700 (PDT) Received: from [192.168.43.98] ([172.56.38.126]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s4QItLvP020763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 May 2014 18:55:22 GMT (envelope-from joelja@bogus.com) Message-ID: <53838E13.70503@bogus.com> Date: Mon, 26 May 2014 11:55:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Hirochika Asai References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> <538360F7.10307@bogus.com> <20140526162033.GA1312@elstar.local> <53836AB8.3020806@bogus.com> <078CE1DA-BBC2-4EB6-B90D-070EF4BB2CF3@hongo.wide.ad.jp> In-Reply-To: <078CE1DA-BBC2-4EB6-B90D-070EF4BB2CF3@hongo.wide.ad.jp> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="o9Rkp1eS1sUVCVhXVhHrMAFRv5eMgXAdC" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Mon, 26 May 2014 18:55:24 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/EOR-atWKif0sKjkuyMQo8TMVJLc Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 18:55:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --o9Rkp1eS1sUVCVhXVhHrMAFRv5eMgXAdC Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, >=20 > Thank you for your comments. >=20 > 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. >=20 > 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 iesg@ietf.org, CCing WG? Or ask WG chairs to > handle it? >=20 > Thank you. > Hirochika >=20 >=20 > On May 27, 2014, at 1:24 AM, joel jaeggli wrote: >=20 >> 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 >>> >> >> >=20 --o9Rkp1eS1sUVCVhXVhHrMAFRv5eMgXAdC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlODjhMACgkQ8AA1q7Z/VrI8pQCfQDf09dIVElLoA/in/D91/+Sf TmQAn1/0i7wWKXA4Q0nJqjpsjtS9lwRO =6+sY -----END PGP SIGNATURE----- --o9Rkp1eS1sUVCVhXVhHrMAFRv5eMgXAdC-- From nobody Mon May 26 13:24:23 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDE41A0248 for ; Mon, 26 May 2014 13:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKLTzQTgpXNW for ; Mon, 26 May 2014 13:24:20 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6471A026B for ; Mon, 26 May 2014 13:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1831; q=dns/txt; s=iport; t=1401135857; x=1402345457; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=RoqdtkIBYby8ZlBPXHMxWIgp7oSoOuRuY8/+dSjjrio=; b=O2gWtawccFcynmuz6ZPBM220WT5C0BfQWRDBy3iIzp2JPZPzgxHZae6E 5lI6ppr+3hlOmK6HLfcHx5dCSGcwdLDgNNtnNiVW7CyHiRY592BTbW6NI CARgcBDBZi2RUyqAvRCORVHKLYi2Lu64l01WSj+WKSNg7wuemrCtrn8qY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8HAHiig1OtJV2S/2dsb2JhbABZgwdSqkoLAQEBAQEBBQGYDAGBFxZ0giUBAQEDAThAEQsOCgkWDwkDAgECAUUGAQwIAQGINggN1QsXhVWJBIRAAQOZc4E9kWqDVCE X-IronPort-AV: E=Sophos;i="4.98,914,1392163200"; d="scan'208";a="47355783" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP; 26 May 2014 20:24:16 +0000 Received: from JCLARKE-M-32CH.CISCO.COM ([10.89.11.86]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s4QKOFAE006678; Mon, 26 May 2014 20:24:15 GMT Message-ID: <5383A2EF.8060601@cisco.com> Date: Mon, 26 May 2014 16:24:15 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Hirochika Asai , "opsawg@ietf.org" References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> In-Reply-To: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/K0ZMfO2rwAj5l9B9kcLmRW5Wkr4 Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 20:24:22 -0000 On 5/26/14, 3:24 AM, Hirochika Asai wrote: > 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. 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 > > Thank you. > Hirochika > From nobody Mon May 26 18:51:50 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0679D1A020B for ; Mon, 26 May 2014 11:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSJruBmkiRwH for ; Mon, 26 May 2014 11:27:13 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 498EE1A0201 for ; Mon, 26 May 2014 11:27:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pE4Ypao3v4ZToVeFeO7vVnCeX0qTHdYCJIyK5YnYtM6bRQvdLw/p9845Q5ypGQOh; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Wozc5-0006aq-I3 for opsawg@ietf.org; Mon, 26 May 2014 14:27:09 -0400 Received: from 76.254.53.37 by webmail.earthlink.net with HTTP; Mon, 26 May 2014 14:27:08 -0400 Message-ID: <22620116.1401128829439.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Mon, 26 May 2014 11:27:08 -0700 (GMT-07:00) From: Randy Presuhn To: opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd81b392879fc7f6aa79e471ae3ca37cb64b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/SaOCJCP_QgiyBg-KY8ymhhAHSyM X-Mailman-Approved-At: Mon, 26 May 2014 18:51:48 -0700 Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 18:27:15 -0000 Hi - >From: Hirochika Asai >Sent: May 26, 2014 10:48 AM >To: joel jaeggli >Cc: "opsawg@ietf.org" >Subject: Re: [OPSAWG] Read-write access in VMM-MIB ... >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 iesg@ietf.org, CCing WG? Or ask WG chairs to >handle it? If the IESG frequently receives such questions, it might eventually realize that our workload seems to be changing from discussing adding writeable objects of questionable value to discussing removing objects of clear value. Randy From nobody Tue May 27 15:49:11 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC31D1A02B0 for ; Tue, 27 May 2014 15:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeCYOjmQEVed for ; Tue, 27 May 2014 15:49:08 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF11A029F for ; Tue, 27 May 2014 15:49:08 -0700 (PDT) Received: from [157.82.3.200] (unknown [157.82.3.200]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 558C0108DF47; Wed, 28 May 2014 07:49:03 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <5383A2EF.8060601@cisco.com> Date: Wed, 28 May 2014 07:49:03 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <48DE4161-C46A-480E-956B-789255A371E7@hongo.wide.ad.jp> References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <5383A2EF.8060601@cisco.com> To: Joe Marcus Clarke X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/aYZxeZTKuixy0SLIFxzsEjA27IM Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:49:09 -0000 Joe, Thank you for your comments. 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 = wrote: > On 5/26/14, 3:24 AM, Hirochika Asai wrote: >> Dear all, >>=20 >> 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 . >>=20 >> 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. >>=20 >> 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 >>=20 >> 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 >>=20 >> I hope you give us your comments on the access of 10 objects. >=20 > 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. >=20 > I think leaving 9 and 10 read-write is fine. >=20 > Joe >=20 >>=20 >> Thank you. >> Hirochika >>=20 >=20 --=20 Hirochika Asai , The University of Tokyo From nobody Tue May 27 16:57:27 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501251A07D5 for ; Tue, 27 May 2014 16:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Irv_Y2XmgGyN for ; Tue, 27 May 2014 16:57:22 -0700 (PDT) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id B5F2D1A07D7 for ; Tue, 27 May 2014 16:57:22 -0700 (PDT) Received: from [157.82.3.200] (unknown [157.82.3.200]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id EB78F108DF45; Wed, 28 May 2014 08:57:18 +0900 (JST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-2022-jp From: Hirochika Asai In-Reply-To: <53838E13.70503@bogus.com> Date: Wed, 28 May 2014 08:57:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <898AF5E1-3597-47EF-A4D9-8DC38FFCA55F@hongo.wide.ad.jp> References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> <538360F7.10307@bogus.com> <20140526162033.GA1312@elstar.local> <53836AB8.3020806@bogus.com> <078CE1DA-BBC2-4EB6-B90D-070EF4BB2CF3@hongo.wide.ad.jp> <53838E13.70503@bogus.com> To: joel jaeggli X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/c1Rkb3N76x_gPLnSWr-X4yKEEBU Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 23:57:24 -0000 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 On May 27, 2014, at 3:55 AM, joel jaeggli wrote: > yeah if you want to discuss it with the ops/management ADs and the > chairs that's fine. >=20 > I don't think there's a reason to involve the whole iesg. >=20 > Thanks > joel >=20 > On 5/26/14, 10:48 AM, Hirochika Asai wrote: >> js and Joel, >>=20 >> Thank you for your comments. >>=20 >> 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. >>=20 >> 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 iesg@ietf.org, CCing WG? Or ask WG chairs to >> handle it? >>=20 >> Thank you. >> Hirochika >>=20 >>=20 >> On May 27, 2014, at 1:24 AM, joel jaeggli wrote: >>=20 >>> 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, >>>>>>=20 >>>>>> the IESG statement is here: >>>>>>=20 >>>>>> http://www.ietf.org/iesg/statement/writable-mib-module.html >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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! >>>>>=20 >>>>=20 >>>> Joel, can you please decrypt your message so that it becomes = perhaps >>>> actionable? >>>=20 >>> I'm agreeing with you. >>>=20 >>>> /js >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 --=20 Hirochika Asai , The University of Tokyo From nobody Wed May 28 02:38:06 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1907B1A0043 for ; Wed, 28 May 2014 02:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIrPnrgN4CHc for ; Wed, 28 May 2014 02:38:00 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0012.outbound.protection.outlook.com [213.199.154.12]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F6F1A0041 for ; Wed, 28 May 2014 02:38:00 -0700 (PDT) Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.949.11; Wed, 28 May 2014 09:37:54 +0000 Message-ID: <031a01cf7a58$1dd5df20$4001a8c0@gateway.2wire.net> From: t.petch To: Hirochika Asai , joel jaeggli References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> <538360F7.10307@bogus.com> <20140526162033.GA1312@elstar.local> <53836AB8.3020806@bogus.com> <078CE1DA-BBC2-4EB6-B90D-070EF4BB2CF3@hongo.wide.ad.jp> <53838E13.70503@bogus.com> <898AF5E1-3597-47EF-A4D9-8DC38FFCA55F@hongo.wide.ad.jp> Date: Wed, 28 May 2014 10:30:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-ClientProxiedBy: AM3PR07CA0046.eurprd07.prod.outlook.com (10.141.45.174) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0225B0D5BC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(24454002)(479174003)(377454003)(51444003)(51704005)(13464003)(199002)(189002)(15202345003)(89996001)(77982001)(19580405001)(83322001)(101416001)(102836001)(87976001)(88136002)(19580395003)(87286001)(15975445006)(50466002)(14496001)(84392001)(99396002)(76482001)(74502001)(33646001)(4396001)(44736004)(50226001)(31966008)(77156001)(46102001)(74662001)(42186004)(21056001)(86362001)(81686999)(81816999)(50986999)(76176999)(93916002)(83072002)(85852003)(92726001)(92566001)(66066001)(80022001)(104166001)(23756003)(44716002)(62236002)(79102001)(47776003)(20776003)(64706001)(81342001)(81542001)(62966002)(61296002)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:AMXPRD0111HT002.eurprd01.prod.exchangelabs.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/V6tV3_Zj1NPzH5Sx72vJhNjuJ8Q Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:38:05 -0000 ----- Original Message ----- From: "Hirochika Asai" To: "joel jaeggli" Cc: Sent: Wednesday, May 28, 2014 12:57 AM > Dear Joel and Benoit, > > 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? 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 > (*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 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 iesg@ietf.org, CCing WG? Or ask WG chairs to > >> handle it? > >> > >> Thank you. > >> Hirochika > >> > >> > >> On May 27, 2014, at 1:24 AM, joel jaeggli 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 , The University of Tokyo > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From nobody Wed May 28 09:12:38 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ADE1A016C for ; Wed, 28 May 2014 09:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy3v2qEupCy8 for ; Wed, 28 May 2014 09:12:32 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757E81A0164 for ; Wed, 28 May 2014 09:12:32 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id z60so18475083qgd.32 for ; Wed, 28 May 2014 09:12:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=B/AfbG9E0tFG7yXjMtFcQWxYSLXo05VKZdXe/1bE1sg=; b=KX1htUCQraHs0c9w6ElKso/3HKMpEknZchbSaqaoScEiSd80WsbR/jLshh5VwzbUC8 PR4RFiTt5kKnvsb5W1SXGiMG8vMDux32wV/ahZr0JjS66Dki+i8EhbUTn9p8hzGI1O7J +mp2/6b8bdCXt3kzL965ULDZv5cy9xhT+3p9mr8OZquT2MhuNvdq4N2M7bilwrMU84Pm 4cmzFKiMOobMD/cnDldRzgCe6iRWmouvNPQBmZ7MzBqJWimHjfo0ve7Vt4m2xUcMOBTI tg/vxzsCEcqQgaG49dPjhyepqadOU8nrC5lyWpgxHa0jpUtHG3pPVM/lj5VoqblsDyfH dAAw== X-Gm-Message-State: ALoCoQlEPEK2xIoDkPrPijaPRVSOfL55rs14pahYA+0LBSw2hFXcvbmrj1KESv9gFJWk59g805rS MIME-Version: 1.0 X-Received: by 10.224.165.70 with SMTP id h6mr864391qay.78.1401293548329; Wed, 28 May 2014 09:12:28 -0700 (PDT) Received: by 10.140.104.49 with HTTP; Wed, 28 May 2014 09:12:28 -0700 (PDT) Date: Wed, 28 May 2014 09:12:28 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: multipart/alternative; boundary=089e0149c3a42cb50a04fa781489 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/RsLqTWowF1xjhtPO1Xraz_2vLsA Cc: "opsawg@ietf.org" Subject: [OPSAWG] config persistence (was Re: Read-write access in VMM-MIB) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 16:12:35 -0000 --089e0149c3a42cb50a04fa781489 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, On Wed, May 28, 2014 at 2:30 AM, t.petch wrote: > ----- Original Message ----- > From: "Hirochika Asai" > To: "joel jaeggli" > Cc: > Sent: Wednesday, May 28, 2014 12:57 AM > > > Dear Joel and Benoit, > > > > 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? > > 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). > > I don't agree NETCONF/YANG persistence is ill-defined. It is not uniform. There are a few variants, identified by capability URIs. The XMLCONF design team (pre-4741) tried very hard to get the router vendors to agree on a single transaction model but it was way too big a change, and (of course) each vendor thought their way was better, so the standard should use that. We ended up with 3 configuration datastores (candidate, running, startup). The transaction models that can be used with these datastores are compatible with specific router CLI architectures. Two particular vendors do not agree on how to recover from the "unreachable" problem. If the operator makes config changes that break the connectivity to the device, then the device has to recover somehow. M1: do not persist the changes until they are proven to be correct. Force the device to reboot with the saved (known good) config if things go bad. M2: persist the changes right away. Pick some timeout and if the client does not follow up with a confirmation before the timeout, automatically revert to the version that was running before the transaction started. RFC 6241 could be more clear on the motivation for the capabilities and operations that support various transaction models. Maybe that is what you meant by 'ill-defined'. Andy 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 > > > (*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 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 iesg@ietf.org, CCing WG? Or ask WG chairs to > > >> handle it? > > >> > > >> Thank you. > > >> Hirochika > > >> > > >> > > >> On May 27, 2014, at 1:24 AM, joel jaeggli 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 , The University of Tokyo > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --089e0149c3a42cb50a04fa781489 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom,


On Wed, May 28, 2014 at 2:30 AM, t.petch <ietfc@btconne= ct.com> wrote:
----- Original Message -----
From: "Hirochika Asai" <panda@hongo.wide.ad.jp>
To: "joel jaeggli" <joelja= @bogus.com>
Cc: <opsawg@ietf.org>
Sent: Wednesday, May 28, 2014 12:57 AM

> Dear Joel and Benoit,
>
> 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. =A0However, the scope of th= e
> nomenclature "configuration" is not clear to me. =A0In my un= derstanding,
> "configuration" does not contain non-persistent (volatile) c= hanges 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?

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
=A0 =A0separated into two classes, configuration data and state data.
=A0 =A0Configuration data is the set of writable data that is required to =A0 =A0transform a system from its initial default state into its current =A0 =A0state. =A0State data is the additional data on a system that is not<= br>
=A0 =A0configuration data such as read-only status information and collecte= d
=A0 =A0statistics."

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). =A0Persistence is orthogonal, and ill-defined, in NETCONF/YANG. =A0If you key it in via CLI,<= br> 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. =A0SNMP has never said much about persistence (table row status being the exception).



I don't agree NETCO= NF/YANG persistence is ill-defined.
It is not uniform. There are = a few variants, identified by
capability URIs.

The XMLCONF design team (pre-4741) tried very hard to
= get the router vendors to agree on a single transaction model
but= it was way too big a change, and (of course) each vendor
thought= their way was better, so the standard should use that.
We ended up with 3 configuration datastores (candidate, running, start= up).
The transaction models that can be used with these datastore= s
are compatible with specific router CLI architectures.

Two particular vendors do not agree on how to recover
from the "unreachable" problem. =A0If the operator makes=
config changes that break the connectivity to the device,
then the device has to recover somehow.

=A0 M= 1: do not persist the changes until they are proven to
=A0 =A0 = =A0 =A0 be correct. =A0Force the device to reboot with the saved
= =A0 =A0 =A0 =A0 (known good) config if things go bad.

=A0 M2: persist the changes right away. =A0Pick some ti= meout
=A0 =A0 =A0 =A0 and if the client does not follow up with a= confirmation
=A0 =A0 =A0 =A0 before the timeout, automatically r= evert to the version
=A0 =A0 =A0 =A0 that was running before the transaction started.
=

RFC 6241 could be more clear on the motivation for the<= /div>
capabilities and operations that support various transaction mode= ls.
Maybe that is what you meant by 'ill-defined'.

<= /div>

Andy

So the two objects controlling Notifications seem clearly configuration, whether or not the setting of them persists or is lost on reboot. =A0You 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

> (*1) http://www.ietf.org/iesg/statement/writable-mib-mo= dule.html
> (*2) http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib-0= 0
>
> Hirochika
>
>
> On May 27, 2014, at 3:55 AM, joel jaeggli <joelja@bogus.com> wrote:
>
> > yeah if you want to discuss it with the ops/management ADs and th= e
> > 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, bu= t I
don't keep
> >> up the procedure. =A0May I, as an author of the draft, send a= n E-mail
> >> stating this issue to iesg@i= etf.org, CCing WG? Or ask WG chairs to
> >> handle it?
> >>
> >> Thank you.
> >> Hirochika
> >>
> >>
> >> On May 27, 2014, at 1:24 AM, joel jaeggli <joelja@bogus.com> wrote:
> >>
> >>> On 5/26/14, 9:20 AM, Juergen Schoenwaelder wrote:
> >>>> On Mon, May 26, 2014 at 08:42:47AM -0700, joel jaeggl= i wrote:
> >>>>> On 5/26/14, 2:31 AM, Juergen Schoenwaelder wrote:=
> >>>>>> Asai,
> >>>>>>
> >>>>>> the IESG statement is here:
> >>>>>>
> >>>>>> http://www.ietf.org/iesg/state= ment/writable-mib-module.html
> >>>>>>
> >>>>>> My reading is that it specifically talks abou= t configuration.
While
> >>>>>> the discussion started with "lets ban al= l write access", it may
be
> >>>>>> important to note that the final statement do= es not say this.
Hence,
> >>>>>> I am not sure we have to remove the MAX-ACCES= S read-write.
> >>>>>
> >>>>> some of the vm options do cause me existential pe= ril. The
remaining
> >>>>> one's however do not. so I think Juergen'= s assessment =A0is a
correct one.
> >>>>> The statement seems to be serving it's purpos= e!
>>>>
> >>>> Joel, can you please decrypt your message so that it = becomes
perhaps
> >>>> actionable?
> >>>
> >>> I'm agreeing with you.
> >>>
> >>>> /js
> --
> Hirochika Asai <panda@hon= go.wide.ad.jp>, The University of Tokyo
>
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg

--089e0149c3a42cb50a04fa781489-- From nobody Wed May 28 10:22:17 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40341A049C for ; Wed, 28 May 2014 10:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjqs5SU4UK1K for ; Wed, 28 May 2014 10:21:58 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 77D261A09F6 for ; Wed, 28 May 2014 10:21:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TQR9L1vVpf2QkdX/8U/VoJcOdvhsb/CEnwaZ4rpWK4yD+QiFPmjF2oxYegjEVcp2; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WphXg-0006CU-0s for opsawg@ietf.org; Wed, 28 May 2014 13:21:32 -0400 Received: from 76.254.53.37 by webmail.earthlink.net with HTTP; Wed, 28 May 2014 13:21:31 -0400 Message-ID: <16444361.1401297691924.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Wed, 28 May 2014 10:21:31 -0700 (GMT-07:00) From: Randy Presuhn To: opsawg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88864c4c3a38ce6fd81a59d641a5f4f8de844d3e48451d24927350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/F-g9ZnptEYNY-Uu76fiQZVynKR4 Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 17:22:02 -0000 X-List-Received-Date: Wed, 28 May 2014 17:22:02 -0000 Hi - >From: "t.petch" >Sent: May 28, 2014 2:30 AM >To: Hirochika Asai , joel jaeggli >Cc: opsawg@ietf.org >Subject: Re: [OPSAWG] Read-write access in VMM-MIB ... >SNMP has never >said much about persistence (table row status being the exception). You seem to have overlooked the StorageType textual convention from RFC 2579. It's fairly widely used. Randy From nobody Wed May 28 11:27:32 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4766A1A01D8 for ; Wed, 28 May 2014 11:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt_BUWgyCofm for ; Wed, 28 May 2014 11:27:29 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F2DB1A01E1 for ; Wed, 28 May 2014 11:27:29 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4SIRJ9e000641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 May 2014 14:27:20 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s4SIRJ9e000641 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1401301641; bh=7qzoTbl/n4e+nFHrnS+jMgiE2nc=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Dv4/fWQwPOFk5dYykBeLVjZh63ax0uOCKCnVaLuQbIwo0IDuk2mJOmVpPKSV5BC/m y9WDkOyb6ihphbEVjdCg8lGuwDVJdm3swGsMTmPXJfHzAMMPCx+HmHt0tIufqcIv1N FO0U3nWfMLOYq+Bq9Vd1QVPo8+R/u6OO091UUeHI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com s4SIRJ9e000641 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 28 May 2014 14:27:06 -0400 Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s4SIR5Un008074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 14:27:06 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Wed, 28 May 2014 14:27:05 -0400 From: "Black, David" To: Hirochika Asai , "opsawg@ietf.org" Date: Wed, 28 May 2014 14:27:04 -0400 Thread-Topic: [OPSAWG] Read-write access in VMM-MIB Thread-Index: Ac94s5lhz9keURFbQKCj/57SHJplFgB60o1g Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C663389@MX15A.corp.emc.com> References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> In-Reply-To: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/IkwMFb3OmsmJdFLaaan7CDUWJOA Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 18:27:31 -0000 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 as the definitions of the controlled notification: > 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! Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Hirochika Asai > Sent: Monday, May 26, 2014 3:25 AM > To: opsawg@ietf.org > Subject: [OPSAWG] Read-write access in VMM-MIB >=20 > Dear all, >=20 > We'd like to discuss the read-write access in the proposed MIB about virt= ual > machine monitoring: http://tools.ietf.org/html/draft-ietf-opsawg-vmm-mib = . >=20 > 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 includ= e > read-write objects even if they do not persist after the restart of the a= gent > or > system. >=20 > 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 >=20 > The following two objects require discussion because these objects are no= t > 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 ob= jects > 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 als= o be > read-only and operators configure them not through SNMP (or something) bu= t > through another configuration scheme such as editing a configuration file= . > 9. vmPerVMNotificationsEnabled > 10. vmBulkNotificationsEnabled >=20 > I hope you give us your comments on the access of 10 objects. >=20 > Thank you. > Hirochika >=20 > -- > Hirochika Asai , The University of Tokyo From nobody Fri May 30 03:42:18 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10771A04B4 for ; Fri, 30 May 2014 03:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7PluEQBleFl for ; Fri, 30 May 2014 03:42:14 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0016.outbound.protection.outlook.com [213.199.154.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94081A0113 for ; Fri, 30 May 2014 03:42:13 -0700 (PDT) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.949.11; Fri, 30 May 2014 10:42:07 +0000 Message-ID: <02c401cf7bf3$68fcc8a0$4001a8c0@gateway.2wire.net> From: t.petch To: Randy Presuhn , References: <16444361.1401297691924.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Fri, 30 May 2014 11:39:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.252.165] X-ClientProxiedBy: AM3PR07CA0018.eurprd07.prod.outlook.com (10.141.45.146) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Microsoft-Antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(51704005)(199002)(189002)(377454003)(50986999)(81816999)(62966002)(85852003)(83072002)(74662001)(44716002)(62236002)(92566001)(86362001)(81686999)(89996001)(76176999)(74502001)(23756003)(47776003)(20776003)(64706001)(79102001)(81342001)(61296002)(81542001)(50226001)(88136002)(101416001)(31966008)(19580395003)(83322001)(87976001)(87286001)(19580405001)(102836001)(80022001)(84392001)(99396002)(76482001)(42186004)(77982001)(21056001)(4396001)(92726001)(93916002)(77156001)(104166001)(46102001)(50466002)(44736004)(33646001)(66066001)(14496001)(74416001)(7726001); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; FPR:; MLV:nov; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-OriginatorOrg: btconnect.com Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/EYBYWybHlry0b7DlSsZf9tAVXlg Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 10:42:16 -0000 ----- Original Message ----- From: "Randy Presuhn" To: Sent: Wednesday, May 28, 2014 6:21 PM > >From: "t.petch" > >Sent: May 28, 2014 2:30 AM > >To: Hirochika Asai , joel jaeggli > >Cc: opsawg@ietf.org > >Subject: Re: [OPSAWG] Read-write access in VMM-MIB > ... > >SNMP has never > >said much about persistence (table row status being the exception). > > You seem to have overlooked the StorageType textual convention > from RFC 2579. It's fairly widely used. Randy, No, not overlooked, just referred to in common parlance as 'table row status '. OK, I might have said 'the StorageType textual convention from RFC2579' but thought the colloquialism would be easier to understand in this context. Sigh:-( Tom Petch > Randy > From nobody Fri May 30 07:50:26 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495451A0928 for ; Fri, 30 May 2014 07:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myRr_8YIUgUO for ; Fri, 30 May 2014 07:50:19 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F85E1A0955 for ; Fri, 30 May 2014 07:50:18 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 9344398CCF; Fri, 30 May 2014 07:50:14 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 8D685400CE; Fri, 30 May 2014 07:50:14 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP id 7BD84E004B; Fri, 30 May 2014 07:50:14 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-2.vmware.com (Postfix) with ESMTP; Fri, 30 May 2014 07:50:14 -0700 (PDT) Date: Fri, 30 May 2014 07:50:14 -0700 (PDT) From: Michael MacFaden To: "t.petch" Message-ID: <462634044.32705439.1401461414213.JavaMail.root@vmware.com> In-Reply-To: <02c401cf7bf3$68fcc8a0$4001a8c0@gateway.2wire.net> References: <16444361.1401297691924.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <02c401cf7bf3$68fcc8a0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.68] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: Read-write access in VMM-MIB Thread-Index: 9OfM/zlokAblpF9VAyPSNHvTDpwfiQ== Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/lyX6nFO8w2u4ypVddy2zJehQAGU Cc: Randy Presuhn , opsawg@ietf.org Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:50:21 -0000 > > >From: "t.petch" > > >SNMP has never > > >said much about persistence (table row status being the exception). > > > > You seem to have overlooked the StorageType textual convention > > from RFC 2579. It's fairly widely used. > > Randy, > > No, not overlooked, just referred to in common parlance as > 'table row status '. > > OK, I might have said > 'the StorageType textual convention from RFC2579' > but thought the colloquialism would be easier to understand > in this context. Having coded my fair share of SNMP agents, my understanding was what Randy's Tom. Tables have both a row status and a storage type object typically. Table row status, when one codes that state machine, was about from the agent's cache to some other part of the system outside the agent passing the appropriate StorageType flag or othwerise writing that bit of config to persistent store. So StorageType is often used with but not the same thing as RowStatus. And yes that model, per row, was alot of state to maintain, RFC 3514. I had some notes on using it in RFC 3512 http://tools.ietf.org/html/rfc3512#section-3.8.2 Mike From nobody Fri May 30 07:51:57 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDF41A0904 for ; Fri, 30 May 2014 07:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.552 X-Spam-Level: X-Spam-Status: No, score=-7.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zQIp8M26TUF for ; Fri, 30 May 2014 07:51:56 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432271A08F6 for ; Fri, 30 May 2014 07:51:56 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 452A698D17; Fri, 30 May 2014 07:51:52 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 3BE6C90DD1; Fri, 30 May 2014 07:51:52 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 2AF43E0105; Fri, 30 May 2014 07:51:52 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Fri, 30 May 2014 07:51:52 -0700 (PDT) Date: Fri, 30 May 2014 07:51:52 -0700 (PDT) From: Michael MacFaden To: "t.petch" Message-ID: <1034326907.32706045.1401461512066.JavaMail.root@vmware.com> In-Reply-To: <462634044.32705439.1401461414213.JavaMail.root@vmware.com> References: <16444361.1401297691924.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> <02c401cf7bf3$68fcc8a0$4001a8c0@gateway.2wire.net> <462634044.32705439.1401461414213.JavaMail.root@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.68] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: Read-write access in VMM-MIB Thread-Index: 9OfM/zlokAblpF9VAyPSNHvTDpwfiYx9zuSA Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/1oDGE1Bqf1kosNFQdpT3JzyiRyA Cc: Randy Presuhn , opsawg@ietf.org Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:51:57 -0000 > And yes that model, per row, was alot of state to maintain, RFC 3514. Correction, d/RFC 3514/cut past error. Sorry for the confusion. Mike From nobody Sat May 31 20:01:13 2014 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FBF1A015B for ; Sat, 31 May 2014 20:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHISDlbllVR3 for ; Sat, 31 May 2014 20:01:09 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D701A015A for ; Sat, 31 May 2014 20:01:09 -0700 (PDT) Received: (qmail 15379 invoked from network); 31 May 2014 20:01:03 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 31 May 2014 20:01:03 -0700 Date: Sat, 31 May 2014 20:01:02 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSAWG In-Reply-To: <031a01cf7a58$1dd5df20$4001a8c0@gateway.2wire.net> Message-ID: References: <291D9650-5AF9-4CE2-B74D-E7BB45239C94@hongo.wide.ad.jp> <20140526093137.GE6042@elstar.local> <538360F7.10307@bogus.com> <20140526162033.GA1312@elstar.local> <53836AB8.3020806@bogus.com> <078CE1DA-BBC2-4EB6-B90D-070EF4BB2CF3@hongo.wide.ad.jp> <53838E13.70503@bogus.com> <898AF5E1-3597-47EF-A4D9-8DC38FFCA55F@hongo.wide.ad.jp> <031a01cf7a58$1dd5df20$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsawg/iBDPwQSV6ozrSPZ2Nvk5RBgbkug Subject: Re: [OPSAWG] Read-write access in VMM-MIB X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 03:01:11 -0000 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