From fb5431@att.com Fri Nov 1 14:19:00 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 987B111E8181 for ; Fri, 1 Nov 2013 14:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.598 X-Spam-Level: X-Spam-Status: No, score=-5.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR8B+r3yZEdK for ; Fri, 1 Nov 2013 14:18:53 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5611E8160 for ; Fri, 1 Nov 2013 14:18:53 -0700 (PDT) Received: from unknown [144.160.112.28] (EHLO tlpi048.enaf.dadc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id dba14725.0.1764511.00-204.4977147.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 01 Nov 2013 21:18:53 +0000 (UTC) X-MXL-Hash: 52741abd50c9831f-2dde344b75131d49aa8d778f241d1752a7bd0b99 Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id rA1LIpIq031028 for ; Fri, 1 Nov 2013 16:18:52 -0500 Received: from dalint03.pst.cso.att.com (dalint03.pst.cso.att.com [135.31.133.161]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id rA1LIlx9031023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 1 Nov 2013 16:18:47 -0500 Received: from WABOTH9MSGHUB8F.ITServices.sbc.com (WABOTH9MSGHUB8F.itservices.sbc.com [135.163.35.68]) by dalint03.pst.cso.att.com (RSA Interceptor) for ; Fri, 1 Nov 2013 21:18:40 GMT Received: from WABOTH9MSGUSR8D.ITServices.sbc.com ([135.163.35.90]) by WABOTH9MSGHUB8F.ITServices.sbc.com ([135.163.35.68]) with mapi id 14.03.0158.001; Fri, 1 Nov 2013 14:18:39 -0700 From: "BARI, FAROOQ" To: "opsawg@ietf.org" Thread-Topic: Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP Thread-Index: Ac7XR+3346lEqLdwSNajmHEBEPUojA== Date: Fri, 1 Nov 2013 21:18:39 +0000 Message-ID: <5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089@WABOTH9MSGUSR8D.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.163.34.5] Content-Type: multipart/related; boundary="_004_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_"; type="multipart/alternative" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: DAM Allow Patterns, Dam_Text, public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.112.28] X-AnalysisOut: [v=2.0 cv=FOSsMZUs c=1 sm=0 a=srMsL6ituuWTYeky9Bs9mA==:17 a] X-AnalysisOut: [=xPe8QG2wDAgA:10 a=NepiiaHIe_MA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=2dX6Jeql0] X-AnalysisOut: [DMA:10 a=WoLIVsU7PsmoGH688CYA:9 a=CjuIK1q_8ugA:10 a=r_pdws] X-AnalysisOut: [-IuSkA:10 a=-FPFUOWkErUA:10 a=Hz7IrDYlS0cA:10 a=yMhMjlubAA] X-AnalysisOut: [AA:8 a=SSmOFEACAAAA:8 a=QXPKzRyuVZRxcr_iM7kA:9 a=gKO2Hq4RS] X-AnalysisOut: [VkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:] X-AnalysisOut: [10 a=fCOVwJzLm-G1oDUm:21 a=R3HR34HaAjfJ7muh9zMA:9 a=KQqxNP] X-AnalysisOut: [gzF0kA:10 a=pYKTcjfSPkOQzn9d:18] Subject: Re: [OPSAWG] Seeking discussion on "Alternate Tunnel Encapsulation for Data Frames in CAPWAP X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 21:19:00 -0000 --_004_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_ Content-Type: multipart/alternative; boundary="_000_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_" --_000_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have read this draft. As mentioned in the draft, the current tunneling me= chanisms have some shortcomings when it comes to handling of larger scale o= perator deployments. So I would support its adoption as working group item. Farooq Bari, PhD Lead Member Technical Staff Strategic Standards AT&T Services, Inc. Email: farooq.bari@att.com Tel: +1 425 580 5526 [Bari_Bari.5240000053802400] This e-mail and any files transmitted with it are AT&T property, are confid= ential, and are intended solely for the use of the individual or entity to = whom this email is addressed. If you are not one of the named recipient(s) = or otherwise have reason to believe that you have received this message in = error, please notify the sender and delete this message immediately from yo= ur computer. Any other use, retention, dissemination, forwarding, printing,= or copying of this e-mail is strictly prohibited --_000_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have read this draft. As mentioned in the draft, t= he current tunneling mechanisms have some shortcomings when it comes to han= dling of larger scale operator deployments. So I would support its adoption= as working group item.

 

Farooq Bari, PhD
Lead Member Technical Staff
Strategic Standards

AT&T Services, Inc.<= /p>

 

Email: farooq.ba= ri@att.com
Tel: +1 425 580 5526

 

3D"Bari_Bari.5240000053802400"


This e-mail and any files transmitted wit= h it are AT&T property, are confidential, and are intended solely for t= he use of the individual or entity to whom this email is addressed. If you are not one of the named recipient(s) or otherwise have reason to b= elieve that you have received this message in error, please notify the send= er and delete this message immediately from your computer. Any other use, r= etention, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited

 

--_000_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_-- --_004_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_ Content-Type: image/jpeg; name="image002.jpg" Content-Description: image002.jpg Content-Disposition: inline; filename="image002.jpg"; size=2680; creation-date="Fri, 01 Nov 2013 21:18:39 GMT"; modification-date="Fri, 01 Nov 2013 21:18:39 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCABuAGMBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKK84+ JXxJv/BOrWlpZ2dtOk8Hmlpd2QdxGOD7Vs+OPF914W8Hw6va28M00jxqUkztG4Enp9Kr/DTxveeN rG+nvbaCBreRUURZ5yCecmuX074xare+NIdGfT7JYZL37MXBbcF3bc9etb/xM+IN94Im09LK0t5x dK5Yy7uNpHTB966Ua3N/whP9teUnn/YPtXl87d2zdj1xmua+GfxBvvG8+oJe2lvALVUKmLdzuJ65 PtVLxd8TtR8PeOotDt7K1lgcxDzH3bvnxnocd61viX43vPBNhYz2VtBO1xIyMJc4GBnjBq78PfFV z4w8NHUryCKCTz2i2xZxgAc8/Wupoorwf4+/8jLpn/Xof/QzVH4Lyvd+OvKuXaaP7JIdkh3DqvY1 654m8caH4HuIIL+GZGuVLr9nhBBAOOeRXgnhi4S7+J9hcRZ8ubUhIueuC+RX1DLbwz486KOTHTeo OK4r/ha/hz+2v7F8u78/7R9lx5A2bt2316ZrtYreGDPkxRx567FAzXJa74+8PaL4lTSdQt5nvmMY DLAGHzfd5JrrZYIpwBNEkgHQMoOK8w8cfDzXdb8YQ6ho8lvBZIkYZPNMfIJJ4Ar1OiivB/j7/wAj Lpn/AF6H/wBDNaMvhqH4SabD4qsJ3v55FWDyJwFUBxknI54xTtPsV+N6Pfak501tOPkotuN4cNzk 7vpXlttdHwx4sW4hUTHT7slVfjfsbjOPpX0B8NvHl144hv3ubOG2+ysgHlsTu3Z65+lZ5+DVifE/ 9tf2pdeb9r+1eXsXGd+7GfTtXo9fP/xN/wCSyW3+9bfzFem/EjxxceB7GyntrSK5NzIyESMRjAz2 rg7b49alPdRRHR7QB3Ck+Y3GTXt9FFeD/H3/AJGXTP8Ar0P/AKGa7b4m6Vfax8N7S2021lup/Mhb y4l3HAU5OK8KvbHXfDDrFdx3unNMNyqxaPfjjPvUs3g/xFHZPfz6Rei3Cea0zRnG3GdxNM0LS9f1 FZjoMF9KqEeb9l3cemcfjXu03i/RrbwA9hPrNvHqcenGJ4mmxKsojwVPfdnj61zPwGvbm7utZ+03 M021IsCSQtjluma9P1+xtZNIv55LaFpltpCJGjBYEKcc9a8W+Emv6fDqWonxNqEJiMS+V9tfcN2e cbu+K9Tj8SeBmkVY73RS5ICgBM5/Kusoorwf4+/8jLpn/Xof/QzXt+n/APINtf8Arin8hXi37QH/ ACGNH/64P/6EK9VXTBrXgSLTmlMS3VgkRkUZK5QDOK81uZv+FGlYbQf2r/anzsZT5Xl7OOMZznd+ lTR/Bq28TRrrb6vLA2pD7WYlhDBDJ820HPOM4zXX+A/h3D4GlvHi1CS7+1KoIaMLt259z61jeNvi PNpXih/DC6fHJHdIkRnMhBXzBjOMds1l/wDDP1p/0HZ//Acf/FVJB8A7WC4jlGuTkowbH2cc4OfW vW6KK8H+Pv8AyMumf9eh/wDQzXCafqXiTUZhbade6rcShciOGaRiAPYHpXsPwm0W8utO1E+KrCaa ZZVEJ1GIuwXBzt39s+leoIqoioihVUYAAwAKytcn0CFof7ebTlYg+V9r2fjjd+FZmseJ9Ek8O3tr perWRuGtnjt4reddxbaQqqAeucAYrlPgzB4ghudV/t5NRVSkflfbN+M5bON34Vw/xndk+I8zoxVl giIIOCDitr4N+KhDqmpHXtZKxmFPL+13Jxndzjcal8fXGtav44t7rw1Nf3WmBIlaSxd2i3BjuGV4 zjGa9uoorwf4+/8AIy6Z/wBeh/8AQzXYfD/4Xf8ACKavFrH9p/aPMtyvleTt+9g9c+1X/iB8SP8A hBr2zg/s77X9pjZ93m7NuDjHQ12Nhc/bdPtrnbs86JZNuc4yAcfrXjn7QP8Ax9aJ/uS/zWpPC3wY z/ZGtf2x/wA8bvyvI+jbc5/DNdt8QfH3/CDRWT/YPtf2ouP9Zs27cex9a8D8a+KP+Ev8RSap9m+z b41Ty9+77oxnOBWBXpHw/wDij/wimkR6P/Zn2jzLgv5vnbcbsDpj2r6Eoorwf4+/8jLpn/Xof/Qz Xt+nf8gy1/64p/IV5B8dNLvtQ1fSmsrK5uFWBwxiiZwDuHXAqn4Y8beOI9W0y01GKaDTFkjjmeWy 2KkYwCSxHHHel+O2o2eoXGjmyu7e4CJLu8mQPt5Xriuc0/4r+Lba2trGzuoykarFEgt1YkAYA6ZJ qHxLqXjPxalumsafeSrbljHtsmTGcZ6D2Fdl4O+GWl6l4Bmv9W027XU1E21WZ0Jxnb8teX/8I3rX /QI1D/wGf/CvTPh74K8M3GiJP4nX7Lqi3B2xz3BhbaMbTsJHGc17dRRXg/x9/wCRl0z/AK9D/wCh mu08BfFGDxVqkWjx6bJbtHblvMaUMDtwOmPevRKztf0xta8P3+nLIImuoGiDkZC5GM4r5x8eeAZf A0lkkt8l39qDkbYyu3bj3PrXZ+Ffgzc+ZpGtDWItuYbryxCc44bbnP4V7ZXB+JPijB4d8XR6E+mS zO5jHmrKFHz47Y7ZrvK868afC6fxX4ri1iPUo7dI0jTymiLE7ST1z716LRRXh/x1sLu78R6a1taz zKtoQTHGWAO8+lcL4cu/EXhXVPt+l2Fws/lmPMlszDBxnjHtXVf8LS8f/wDPp/5IGj/haXj/AP59 P/JA1z3ijWvFHjB7ZtWsZmNuGEfl2jL1xnt7Ctqy+I/juwsYLSC0IigjWNAbEk4AwP5VP/wtLx// AM+n/kga5fWL/wASa5r6aze2M5vEKEFbVgvy9OMV1H/C0vH/APz6f+SBqW1+J/j2S7hSS1+RnUN/ oJ6Zr3uiiiiiiiiiiiiiiiiiiiiori4itIHmncJGgyWPas8+JtLCKzXQGTggqcr9fTrUra5YLdG3 +0KZeRtGeoGcZ9cVXtPFGmXYgAnCPOcIrAjnOMUXfijTbQspm3sH2YVScnPOD7Vrg5AI6Glooooo oqpqVgmpWbQO5TkMrDqrA5B/MVkv4YmkeaRtVlM1woSd/KX51HQAdvwq2nh+GN4isrhYpzMBgc5U rj9az08HMsqM2pzOiTLMqtEp24OQAewqdvDDmHyF1GVbdM+TH5a/u8nPXv8AjW8AQoBOT6+tLX// 2Q== --_004_5E1F45A93ED6EA40A37348DFBC21A1AE1EDA0089WABOTH9MSGUSR8D_-- From mrm@vmware.com Fri Nov 1 17:22:51 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C7C21E8088 for ; Fri, 1 Nov 2013 17:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQlmKdMsNJy5 for ; Fri, 1 Nov 2013 17:22:46 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 71D1111E810C for ; Fri, 1 Nov 2013 17:22:46 -0700 (PDT) Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 741302BA89; Fri, 1 Nov 2013 17:22:46 -0700 (PDT) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 725A8182DB; Fri, 1 Nov 2013 17:22:46 -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 60AFDE0049; Fri, 1 Nov 2013 17:22:46 -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, 1 Nov 2013 17:22:46 -0700 (PDT) Date: Fri, 1 Nov 2013 17:22:45 -0700 (PDT) From: Michael MacFaden To: Benoit Claise Message-ID: <551469562.18909716.1383351765743.JavaMail.root@vmware.com> In-Reply-To: <52728DF5.2070701@cisco.com> References: <52728DF5.2070701@cisco.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: OPS guidance to the non-OPS community Thread-Index: 66/B5NyeGbuiWAjVHZ4pnajw6fdzww== Cc: opsawg@ietf.org, Dave Thaler Subject: Re: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 00:22:51 -0000 > Problem 1: > How do we share our OPS knowledge? How do we advice which OPS tools > (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should > be using? > The point is that we have multiple management frameworks, as opposed to > only one in the past: SNMP Right, SNMP is the Internet Standard Management Framework. Yet we've had RADIUS/DIAMETER alongside SNMP for decades then others come up from time to time COPS-PR. So while we've had one primary protocol IETF has others. Today I don't think it likely we're ever going back to one. Multiple mgmt frameworks I think is a result of the nature of problem first documented in Bellcore M.3010 breaking down operational practices into FCAPS. That the IETF now has more than one mgmt technology is imo a good thing. But like you said it now takes a conversation to answer the question. If often explain the role of SNMP in appliances to others who might prefer to use one web service api for all of FCAPS this way: In as much as I don't drive moving van to work opting for a small commuter car, I find that I do need to pick and choose among mgmt protocols appropriately. No one size fits all or plugs into the operational environment of most operators w/o needing some new adapter. So for instance if I want to monitor my network, its gonna be SNMP hands down. All the gear I have and will buy has it. Cost to develop cost to deploy known/cheap. Sure one can argue that IPFIX might do it better but it is not better enough such that the cost would make any sense to business to absorb such cost. And just as I'd use IPFIX for flow accounting or use NETCONF for configuration, that's just what is gonna look like. No short cuts or easy asnwers. My hope is that when IETF comes up with new protocols they build a decent data model to monitor it and a data model to configure it and whatever other model that makes sense and whatever else. The monitoring data model doesn't have to be SMIv2 but should be generated such that we get IETF standard oids. Then when it comes time for me to build a product that uses IETF technology I am lucky to stand on the shoulders of giants and use high quality MIB modules, example NTPv4-MIB, IP-MIB, not only in an SNMP agent but also in the proprietary protocols. Then sometimes I'm not so lucky as in no SYSLOG-MIB and NFS mib modules. Mike MacFaden From melinda.shore@gmail.com Sun Nov 3 13:36:18 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1D11E823E for ; Sun, 3 Nov 2013 13:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzESEz1H607j for ; Sun, 3 Nov 2013 13:36:17 -0800 (PST) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 911F711E823F for ; Sun, 3 Nov 2013 13:36:13 -0800 (PST) Received: by mail-bk0-f54.google.com with SMTP id 6so2072612bkj.41 for ; Sun, 03 Nov 2013 13:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=MhGWnlk54YdkZLj1sZTZ9XipBmxshPJxCjCDRWY951g=; b=qhFIs+UN42NwphI61AxTBkm2hxPzmbKr9G9Gu53GtJUypJDSSVWW5OAVSaFsqhv7dt C2jmP3CnUtenai8eZXP6PKb1C1C1R8rs2RX8B5K8TQSq3PEsmtCOkLXzo09L++CWgxy6 l1kRvrbE+4hprDx1O1eBLkb7r+UM0g1OBqpLUapoobb02QlKAfqtHiZa1wlmWyNApQ+z bWyRbmPgQ7+HM/TGfHCVBTn3PBdg9pbmnaZoqbBxDlmS4C9bDFY6dsxcwlkYW9VpcMKr C9tv5kWsvBpK/PUsU6HUvFZu4pXNLTzwK4cUoQclGakrjgMV4ZRSlwAbdMZPxNCQsYzY PLgw== X-Received: by 10.204.226.71 with SMTP id iv7mr790100bkb.32.1383514565695; Sun, 03 Nov 2013 13:36:05 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:4d45:4a68:a6c5:d83? ([2001:67c:370:160:4d45:4a68:a6c5:d83]) by mx.google.com with ESMTPSA id a4sm12602882bko.11.2013.11.03.13.36.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 13:36:05 -0800 (PST) Message-ID: <5276C1C3.5040705@gmail.com> Date: Sun, 03 Nov 2013 13:36:03 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Ping on slides X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 21:36:18 -0000 If you've got time on the agenda at our session on Tuesday, please get your slides to us. Thanks, Melinda, Scott, Warren From rpazhyan@cisco.com Sun Nov 3 13:38:47 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8077F11E8247 for ; Sun, 3 Nov 2013 13:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MH6H3-KdkpPw for ; Sun, 3 Nov 2013 13:38:42 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2A29121F9E98 for ; Sun, 3 Nov 2013 13:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28867; q=dns/txt; s=iport; t=1383514722; x=1384724322; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+7mBRk9t4XQyr5r+3IrYDD35mHd9hk6JaACqs1L3cZg=; b=ON+88sdkl07VCsiUj8SAwaS6ywfGNHV9XhXFoJANsU6u8sdxChM4qpyc nsb8MuB+1H6zSHKIU3VKrP+3WAm0wkefuQmThKuaP7vTCUwUSkgWGkpmX YRPR2SBGwummKn4dVHxq8kaEEvTp/RSRbgV4cErO5SI3UzUlgrL2k/gHX o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFABjBdlKtJXHB/2dsb2JhbABYgkNEOFO/BEuBGxZ0giUBAQEDAQEBASpBAgkFCwIBCA4DBAEBCxYBBgchBgsUCQgBAQQOBQiHZwMJBg2zSQ2JZwSMaII/LQQGAQaDGoEOA4kIjReOPYU3gyaCKg X-IronPort-AV: E=Sophos;i="4.93,627,1378857600"; d="scan'208,217";a="280100207" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 03 Nov 2013 21:38:40 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA3Lce5u024459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 3 Nov 2013 21:38:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Sun, 3 Nov 2013 15:38:39 -0600 From: "Rajesh Pazhyannur (rpazhyan)" To: Dorothy Stanley Thread-Topic: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP" Thread-Index: Ac7I7CILQDZSqPp7TqGmZS+kMlC6OQLQRCuAASuvY3A= Date: Sun, 3 Nov 2013 21:38:39 +0000 Message-ID: <4ED2E36A22261145861BAB2C24088B4320EE0A27@xmb-aln-x09.cisco.com> References: <4ED2E36A22261145861BAB2C24088B4320EC9109@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: [10.21.146.200] Content-Type: multipart/alternative; boundary="_000_4ED2E36A22261145861BAB2C24088B4320EE0A27xmbalnx09ciscoc_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 21:38:47 -0000 --_000_4ED2E36A22261145861BAB2C24088B4320EE0A27xmbalnx09ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Dorothy Thanks for the detailed review. We accept the suggested changes and will incorporate them in the next versi= on . Some additional comments below. Regards Rajesh From: Dorothy Stanley [mailto:dstanley1389@gmail.com] Sent: Monday, October 28, 2013 10:30 AM To: Rajesh Pazhyannur (rpazhyan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile fo= r CAPWAP" Hi Rajesh, Comments below. Dorothy ------------- 1. Today, Split and Local MAC are negotiated using the WTP MAC Type m= essage element. There is no need to include Local and Split MAC in the prof= ile element. The new mode is actually a profile of the current defined Spli= t MAC. In section 4, delete 0 and 1, renumber "2" to "0" and change from "i= ndentified" to "identified" in the line above. =D8 Yes. I was somewhat ambivalent when I included Split and Local MAC p= rofiles but I am happy to delete it. =D8 I am wondering whether we should create two profiles one each for th= e two cases: Encryption at the WTP and Encryption at the AC. Section 3.2 can be deleted, and Sections 3.1 and 3.3 combined into a single= table. 2. Section 3.3.1: "Frames Exchange" to "Frame Exchange" 3. Section 4, "The IEEE 802.11 WTP Profile message element allows the= WTP to communicate the profile(s) it supports to the AC." 4. 4. The new MAC model is named "Hybrid MAC profile". This name is v= ery general, and the description says that it is a specific profile of the = split MAC, not a hybrid (as the current name suggests) of split and local."= Suggest renaming "Hybrid MAC" to "Split MAC with WTP Encryption" (or simil= ar) > yes, this make sense. 5. 5. Section 5. The text is not clear: "it could directly reference"= . Well it could, Make it reference the section or not. Change to "There are no additional security considerations introduced by th= is specification in addition to those in [RFC5416]. > Yes (this is Section 6, I believe). 6. 6. Section 4 - add a period at the end of the first sentence after= "one such message element". 7. 7. Abstract. Suggested edits below: The CAPWAP protocol defines two modes of operation for IEEE 802.11 WTPs: Split and Local MAC (medium access control), as described in [RFC5415], and [RFC5416]. Specifically, [RFC5416] describes in detail t= he division of labor functionality between the WTP and AC in both the Split= and Local MAC modes. Unfortunately, tThere are many some functions that have not yet been clearly defined whether they belong can be performed in either to t= he WTP or the AC. For example, in the Split MAC mode, IEEE 802.11 encryption is specified as = located in either in the AC or the WTP with no clear way to negotiate where it should be located. This lack of specification leads to interoperability issues between an AC and WTP when the AC and WTP come from different vendors. = To solve this problem, this specification defines a profile of the Split MA= C mode, "Split MAC with WTP Encryption" mode of operation and an the concep= t of IEEE 802.11 MAC profile message element used to negotiate the profile. where = each profile refers to a table containing an unambigous division of labor between WTP and AC. The IEEE 802.11 MAC pr= ofile message element is used as follows: the WTP informs the AC of the supported profile(s) and the AC selects the profile when it configures to be configured on the WTP. On Mon, Oct 14, 2013 at 7:46 AM, Rajesh Pazhyannur (rpazhyan) > wrote: Greetings... We have submitted a new version of the draft (previously titled "Hybrid MAC= -Model for CAPWAP". While solving the same problem as in the original draft, this takes a diffe= rent approach. We introduce a new element IEEE 802.11 MAC Profile. This pro= file defines the functional split between the MAC and AC. The idea of usin= g profiles was based on discussion in the last working groups meeting as we= ll as offline meetings with other participants. While somewhat similar to m= ode defined in RFC 5416, this solves the problem with the ambiguity in the = mode definitions in RFC 5416 as well as enables different functional splits= to be defined in the future. The link to the draft is https://datatracker.= ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac We are soliciting comments and feedback. Thanks Regards Rajesh _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --_000_4ED2E36A22261145861BAB2C24088B4320EE0A27xmbalnx09ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Dorothy

 

Thanks for the detailed review.  

We accept the suggested changes and will i= ncorporate them in the next version .

 

Some additional comments below.=

 

Regards

 

Rajesh

From: Dorothy = Stanley [mailto:dstanley1389@gmail.com]
Sent: Monday, October 28, 2013 10:30 AM
To: Rajesh Pazhyannur (rpazhyan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] Seeking comments on draft "IEEE 802.11 MA= C Profile for CAPWAP"

 

Hi Rajesh,=

Comments below.<= /o:p>

Dorothy
-------------
1.   &nb= sp;   Today, Split and Local MAC are negotiated using the WTP MAC Type mes= sage element. There is no need to include Local and Split MAC in the profil= e element. The new mode is actually a profile of the current defined Split = MAC. In section 4, delete 0 and 1, renumber “2” to “0” and change from “inde= ntified” to “identified” in the line above.

=D8    Yes. I was somewhat ambivalent whe= n I included Split and Local MAC profiles  but I am happy to delete it= .

=D8    I am wondering whether we should c= reate two profiles one each for the two cases: Encryption at the WTP and En= cryption at the AC.


Sectio= n 3.2 can be deleted, and Sections 3.1 and 3.3 combined into a single table= .
2.      Se= ction 3.3.1: “Frames Exchange” to “Frame Exchange”<= /span>
3.     &nbs= p; Section 4, “The IEEE 802.11 WTP Profile message element allows th= e WTP to communicate the profile(s) it supports to the AC.&= #8221;

4.  =      4. The new MAC model is named “Hybrid MAC profile&#= 8221;. This name is very general, and the description says that it is a spe= cific profile of the split MAC, not a hybrid (as the current name suggests) of split and local.” Suggest renaming “Hybrid MAC= 221; to “Split MAC with WTP Encryption” (or similar)

> yes, this make sense.

5.  =      5. Section 5. The text is not clear: “it could dire= ctly reference”. Well it could, Make it reference the section or not.=
Change to “There are no additional security considerations introduced= by this specification in addition to those in [RFC5416].=

> Yes (this is Section 6, I believe).

 

6.  =      6. Section 4 – add a period at the end of the first= sentence after “one such message element”.

7.  =      7. Abstract. Suggested edits below:

The CAPWAP protocol defines two modes of operat=
ion for IEEE 802.11
   WTPs: Split and Local MAC (medium =
access control), as described in
   [RFC5415], and [RFC5416].&n=
bsp; Specifically, [RFC5416] describes in detail the
 
   division of labor functi=
onality between the WTP and AC in both the Split and Loca=
l MAC
 
   modes.  Unfortunately, =
tThere are many some functions that have no=
t yet
 
   been clearly defined whether th=
ey belong can be performed in either to the WTP or the A=
C.  For
   example, in the Split MAC mode,=
  IEEE 802.11 encryption is specified as located in either in
 
   the AC or the WTP with no clear wa=
y to negotiate where it should be
   located.  This lack of specif=
ication leads to interoperability issues
   between an AC and WTP when =
the AC and WTP come from different vendors.  To
 
   solve this problem, this specifica=
tion defines a profile of the Split MAC mode, “Split MAC with WTP =
Encryption” mode of operation and an the concept of IEEE
   802.11 MAC profile message elem=
ent used to negotiate the profile. where each profile refers to a ta=
ble containing an
   unambigous division of labor be=
tween WTP and AC.  The IEEE 802.11 MAC profile message =
element is used
   as follows: the WTP informs the AC=
 of the supported profile(s) and the
 
   AC selects the profile when it<=
/s> configures to be configured on the WTP.

 

 

 

 

On Mon, Oct 14, 2013 at 7:46 AM, Rajesh Pazhyannur (= rpazhyan) <rpazh= yan@cisco.com> wrote:

Greetings…

 

We have submitted a new version of the = draft (previously titled “Hybrid MAC-Model for CAPWAP”.

While solving the same problem as in th= e original draft, this takes a different approach. We= introduce a new element IEEE 802.11 MAC Profile. This profile defines the = functional split between the MAC and AC.  The idea of using profiles was based o= n discussion in the last working groups meeting as well as offline meetings= with other participants. While somewhat similar to mode defined in RFC 541= 6, this solves the problem with the ambiguity in the mode definitions in RFC 5416 as well as enables different functiona= l splits to be defined in the future. The link to the d= raft is https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac=

 

We are soliciting comments and feedback= .

 

Thanks

 

Regards

 <= /p>

Rajesh<= /p>

 <= /p>


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

 

--_000_4ED2E36A22261145861BAB2C24088B4320EE0A27xmbalnx09ciscoc_-- From wesley.george@twcable.com Sun Nov 3 14:56:59 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F0721E8106 for ; Sun, 3 Nov 2013 14:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqg7UQ6od2hR for ; Sun, 3 Nov 2013 14:56:54 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC2B21E80F9 for ; Sun, 3 Nov 2013 14:56:54 -0800 (PST) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.93,628,1378872000"; d="scan'208";a="151352528" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Nov 2013 17:56:46 -0500 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Sun, 3 Nov 2013 17:56:53 -0500 From: "George, Wes" To: Benoit Claise , "opsawg@ietf.org" Date: Sun, 3 Nov 2013 17:56:52 -0500 Thread-Topic: [OPSAWG] OPS guidance to the non-OPS community Thread-Index: Ac7WW4uDVywZhve1QZCcWeXvmS3n6wCV5hQA Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043DEB1773@PRVPEXVS15.corp.twcable.com> References: <52728DF5.2070701@cisco.com> In-Reply-To: <52728DF5.2070701@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Dave Thaler Subject: Re: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 22:57:00 -0000 Benoit - I think there's a more basic question. What is "ops" in this context and ho= w do we as the IETF or OPSArea expect to represent it to "non-ops"? What's = the desired outcome and audience - just to give those working within other = areas of the IETF better guidance on tools? That sounds more like the opera= tive word is "tools" or "management" not ops. If you are instead referring to broader operational feedback outside of IET= F, that asks a second question - is IETF still the right venue for this? Do= we have the credibility and experience? There are other initiatives aimed = at providing feedback from operations (BCOP, the *NOG community, Deploy 360= , etc) that have better operator participation than IETF, so I'd be hesitan= t to reinvent the wheel here. If the main goal is to update guidance more consistently and frequently bas= ed on what tools are in common use, you'd get better results from surveying= a much wider community periodically - e.g. publishing a survey on *NOG lis= ts, and using that to inform your results. Your other fundamental question seems to be - how do we make IETF recommend= ations, discussions of pros/cons for different tools and solutions, etc mor= e accessible for those who don't really fancy reading RFCs? Most of your ex= amples seem to indicate that we'd be better with some sort of system that p= ulls the relevant info out of multiple RFCs and presents them in one place = based on the subject, rather than expecting people to find the relevant doc= ument(s) and then follow a chain of document, updated document, updated upd= ated document, obsoleted section, erratum, etc to synthesize the actual cur= rent recommendation from all of the pieces. It's a real issue, but one much= larger than OpsArea. Wes George > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Benoit Claise > Sent: Thursday, October 31, 2013 1:06 PM > To: opsawg@ietf.org > Cc: Dave Thaler > Subject: [OPSAWG] OPS guidance to the non-OPS community > > Dear all, > > During the OPSAWG/OPSAREA meeting, I will be addressing one issue that > is now on the top of my mind: OPS guidance to the non-OPS community. > > Problem 1: > How do we share our OPS knowledge? How do we advice which OPS tools > (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should > be using? > > On regular basis, I have to provide these advice > How can we share this knowledge? > This is the perfect job for an OPS advisor, but one OPS advisor in all > WGs doesn't scale. > > Problem 2: > What are the OPS recommendations for future developments? > It might appear as the same problem as 1, but the audience is different. > Here, we speak about new charters for example. This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From bclaise@cisco.com Sun Nov 3 16:23:38 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC0021E810A for ; Sun, 3 Nov 2013 16:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZyTm84NJb69 for ; Sun, 3 Nov 2013 16:23:32 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B2B8421E80A3 for ; Sun, 3 Nov 2013 16:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3792; q=dns/txt; s=iport; t=1383524607; x=1384734207; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=REPBSAQnEEQ9BTvnLh7f6/GzJYE6vGeRtMyoyDBNm4g=; b=Fl6uKFnVlP9PZD57wvQRbOQo3nypbcHvNwBt6Af2Zqs65PRnN+E4jrqL TNqq6CM+XTqxO8p0kyBn+kaBZnk2orn8ZGPI8CyXkejtcoXJzJ9VucOfk go54o51yC+T21HFMBWBIsnNXrlrgcXriLLkhRJsVcW0ikdi6l34vG3Wwa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAAHodlKrRDoJ/2dsb2JhbABZgwfAWoEaFnSCJQEBAQQYIDoGAQwECxEEAQEKFggHCQMCAQIBNAkIBg0BBQIBARAHh2W9TY4fgTkHBoQoA4lAjkqGPYtMg0cbgTU X-IronPort-AV: E=Sophos;i="4.93,628,1378857600"; d="scan'208";a="93949260" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 04 Nov 2013 00:23:26 +0000 Received: from [10.21.123.118] (sjc-vpn6-886.cisco.com [10.21.123.118]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA40NNH6018859; Mon, 4 Nov 2013 00:23:23 GMT Message-ID: <5276E8FB.2020307@cisco.com> Date: Sun, 03 Nov 2013 16:23:23 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "George, Wes" References: <52728DF5.2070701@cisco.com> <2671C6CDFBB59E47B64C10B3E0BD5923043DEB1773@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043DEB1773@PRVPEXVS15.corp.twcable.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , Dave Thaler Subject: Re: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 00:23:38 -0000 Hi, > Benoit - > > I think there's a more basic question. What is "ops" in this context and how do we as the IETF or OPSArea expect to represent it to "non-ops"? What's the desired outcome and audience - just to give those working within other areas of the IETF better guidance on tools? That sounds more like the operative word is "tools" or "management" not ops. Good clarification. I meant "tools" or "management" , i.e. protocols and data models > > If you are instead referring to broader operational feedback outside of IETF, that asks a second question - is IETF still the right venue for this? Do we have the credibility and experience? There are other initiatives aimed at providing feedback from operations (BCOP, the *NOG community, Deploy 360, etc) that have better operator participation than IETF, so I'd be hesitant to reinvent the wheel here. > If the main goal is to update guidance more consistently and frequently based on what tools are in common use, you'd get better results from surveying a much wider community periodically - e.g. publishing a survey on *NOG lists, and using that to inform your results. Right, if we give guidance only based what is used today, we will never provide guidance for new tools. > > Your other fundamental question seems to be - how do we make IETF recommendations, discussions of pros/cons for different tools and solutions, etc more accessible for those who don't really fancy reading RFCs? Most of your examples seem to indicate that we'd be better with some sort of system that pulls the relevant info out of multiple RFCs and presents them in one place based on the subject, rather than expecting people to find the relevant document(s) and then follow a chain of document, updated document, updated updated document, obsoleted section, erratum, etc to synthesize the actual current recommendation from all of the pieces. It's a real issue, but one much larger than OpsArea. Exactly, this is what I would like to (try to) solve ... for OPS. Regards, Benoit > > Wes George > > >> -----Original Message----- >> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf >> Of Benoit Claise >> Sent: Thursday, October 31, 2013 1:06 PM >> To: opsawg@ietf.org >> Cc: Dave Thaler >> Subject: [OPSAWG] OPS guidance to the non-OPS community >> >> Dear all, >> >> During the OPSAWG/OPSAREA meeting, I will be addressing one issue that >> is now on the top of my mind: OPS guidance to the non-OPS community. >> >> Problem 1: >> How do we share our OPS knowledge? How do we advice which OPS tools >> (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should >> be using? >> >> On regular basis, I have to provide these advice >> How can we share this knowledge? >> This is the perfect job for an OPS advisor, but one OPS advisor in all >> WGs doesn't scale. >> >> Problem 2: >> What are the OPS recommendations for future developments? >> It might appear as the same problem as 1, but the audience is different. >> Here, we speak about new charters for example. > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > . > From j.schoenwaelder@jacobs-university.de Sun Nov 3 17:23:18 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431E111E8267 for ; Sun, 3 Nov 2013 17:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.179 X-Spam-Level: X-Spam-Status: No, score=-103.179 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtlWDTbK3dZv for ; Sun, 3 Nov 2013 17:23:13 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D29A711E81CB for ; Sun, 3 Nov 2013 17:23:10 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3940220077; Mon, 4 Nov 2013 02:23:10 +0100 (CET) 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 UQEkhiOqs2qS; Mon, 4 Nov 2013 02:23:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A076620075; Mon, 4 Nov 2013 02:23:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CAC9D2928765; Mon, 4 Nov 2013 02:23:04 +0100 (CET) Date: Mon, 4 Nov 2013 02:23:04 +0100 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20131104012304.GB75287@elstar.local> Mail-Followup-To: Benoit Claise , "opsawg@ietf.org" References: <52728DF5.2070701@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <52728DF5.2070701@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 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, 04 Nov 2013 01:23:18 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 31, 2013 at 06:05:57PM +0100, Benoit Claise wrote: > During the OPSAWG/OPSAREA meeting, I will be addressing one issue > that is now on the top of my mind: OPS guidance to the non-OPS > community. [...] This topic seems to be coming up repeatedly. So either this is a real problem to work on or it is something new ADs should be told about because after getting into the job (which takes about two years I have been told), they will raise this issue. /js PS: I am attaching my latest collection of ideas that was last modified in November 2012 (!) and I think I did send it to Benoit back then. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nm-guidelines.org" Guidelines for Developing Network Management Specifications * Introduction - WGs should consider operations and management aspects during the development of protocol specifications. For such guidelines, see RFC 5706. - IAB recommandations documented in RFC 1052 lead to the development of SNMP as the Internet network management protocol. This document is meanwhile obsolete and only of historic value. - Functional evolution of the SNMP framework failed (EOS working group, SMIng working), new approaches came along (COPS-PR, SPPI), resulting in an IAB workshop (documented in RFC 3535), which paved the way to the creation of NETCONF. - SYSLOG existed since the late 1980s but was not formally defined as a standard protocol specification, leading to many variants, making later attempts do document it challenging, see RFC 3164. Its only since 2009 that there is a standards-track IETF specification of SYSLOG [RFC5424]. - IPFIX [RFC5101], published in 2008, is a standards-track version of NETFLOW, which dates back to the early 1990s, a proprietary protocol for exporting network flow information. - There are now several network management protocols that WGs can use to address their network management needs. This document aims at providing guidelines how to choose between the technologies. * Relevant Network Management Technologies ** NETCONF/YANG - NETCONF can transport and filter large amounts of data more efficiently than SNMP - NETCONF provides specific support to manipulate (persistent) configuration datastores, including locking mechanisms to control concurrency and rollback mechansims to run transactions across a number of devices - The NETCONF transports are all TCP based. Hence, NETCONF can suffer from shaky network conditions, e.g., high degrees of packet loss. - The data modeling language YANG allows to model complex structured data types much more easily than SMIv2, which is restricted to flat tables ** SNMP/SMIv2 - SNMP is very low overhead for regular polling activities and it provides a very lightweight event notification mechanism - SNMP is particularly efficient if little information from many devices is monitored - SNMP uses a trap-directed polling approach. As such, regular polling is assumed and notifications are essentially there to reduce latency (i.e., no need to wait until the next polling cycle and event notifications do not have to carry all details of the event). - The most widely deployed SNMP transports are UDP based and thus allow SNMP managers to cope with shaky network conditions, e.g., high degrees of packet loss. (But note that it is implementation dependent whether implementations do that.) - There is a large collection of SNMP-based tools that collect and integrate SNMP accessible data and do perform event correlation. ** SYSLOG - SYSLOG traditionally does not use formally defined structured data. Even though standards-track SYSLOG has support for structured data, this does not seem to be widely used (yet). - SYSLOG has a signature mechanism (RFC 5848), which can be very useful to address legal requirements. - Tools typically allow to filter SYSLOG messages (often by matching messages against collections of regular expressions) and offer to trigger reactions if a filter matches. ** IPFIX - IPFIX was originally designed to export information about network flows, often used for traffic engineering or accounting purposes - IPFIX is template driven, which allows a rather compact encoding of structured data that is sent frequently since the naming and type information is carried in a template, separated from the data itself * Network Management Avtivities ** Configuration - For configuration, NETCONF/YANG is the choice since there are no direct competitors for configuration. ** Periodic Monitoring ** xxx Monitoring ** Logging - SYSLOG has been widely used for logging, mainly due to its flexibility. The SYSLOG signature mechanism makes it rather attractive in situations where legal requirements require to proof the origin and integrity of log messages. - IPFIX has more recently been proposed as an alternative for logging since it allows to bundle a number of similarly structured log messages into a single IPFIX messages. However, at this point in time, this is a proposal, it is not clear yet that the larger community has concensus on this direction of evolution of IPFIX. ** Alerting - SYSLOG has been widely used for event notification; it does not require a formal data model and thus is very flexible for device implementors but as a consequence requires more work on the event notification receiver side - SNMP has been widely used for event notification; it relies on a formal data model and thus is a bit easier to deal with on the even notificaiton receiver side but less flexible for device implementors - It seems there are deployments that prefer to translate all event notifications into SYSLOG format and there are deployments that prefer to translate all event notifications to SNMP format - NETCONF event notifications may make sense to provide event notifications to configuration management applications but likely will not compete any time soon with SNMP notifications and SYSLOG messages * Guidelines WGs are not required to produce SMIv2 data models (MIB modules) nor are they required to produce YANG data models (YANG modules). However, they are encouraged to do so. Note that MIB modules can even be read-only by providing appropriate compliance statements. The decision whether SMIv2 or YANG is more appropriate must be taken by the WG. --yrj/dFKFPuw6o+aM-- From maxpassion@gmail.com Sun Nov 3 22:32:01 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4111E82D2 for ; Sun, 3 Nov 2013 22:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBXI6rbNPT2V for ; Sun, 3 Nov 2013 22:31:58 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 413DE21E809B for ; Sun, 3 Nov 2013 22:31:57 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id oy12so1196837veb.1 for ; Sun, 03 Nov 2013 22:31:56 -0800 (PST) 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=Wjr0BpNo0NMIhKIiSur6oF9XENN+AdBHUu3eMcf/Yik=; b=cFQQAwek5pCYn2TgXVCon8h4zXGGRcoCfLFxp2hmE+07EkTWNx2TzfA3WqeMXwg2SC Dh1Cv6rmDF1EYILRlC/p3+6maeseFtFPcwiZ8oDQPAe8ZfsTpedrm7sxUrnu5mJDxy/g gUdX0Y+OykWmOEnD6YsYTiD/ms7TY72ysZZ0Ek4oOybdzG1YtEsAvqeXjFglHe/vTViL 7rR/cEnn+Mbce0a92yP5UCNXYxHXsyCAYvrxiP0It7xGUwFPDESfqLWaW5NJm0Iq56we 0gfDIv7qaaNmkKPRKWIieUOWqJgp0TP9wJz9pFABSx2WEGMYZp/sS7cuIl5vLtf1mhh0 SDIw== MIME-Version: 1.0 X-Received: by 10.221.40.10 with SMTP id to10mr560472vcb.22.1383546716668; Sun, 03 Nov 2013 22:31:56 -0800 (PST) Received: by 10.220.220.69 with HTTP; Sun, 3 Nov 2013 22:31:56 -0800 (PST) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1291CAE4@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1291CAE4@AZ-FFEXMB04.global.avaya.com> Date: Mon, 4 Nov 2013 14:31:56 +0800 Message-ID: From: Liu Dapeng To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=001a1133757693cca704ea541240 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 06:32:01 -0000 --001a1133757693cca704ea541240 Content-Type: text/plain; charset=ISO-8859-1 Hi Dan, Thanks for your comments. 2013/10/30 Romascanu, Dan (Dan) > Hi, > > I have read draft-ietf-opsawg-capwap-extension-01. I am no expert in IEEE > 802.11 technology, so I cannot confirm the accuracy of the .11-related > information in this I-D. It looks like straight forward and consistent > work, but it needs review from the IEEE experts as long as several > editorial improvements. > > IEEE experts have reviewed the draft during the September IEEE 802 wireless interim meeting. The 01 version draft has been updated according to the comments received. > Here are my comments (mostly editorial, but important to make the document > readable and usable): > > 1. The document obviously updated RFC 5416. This needs to be mentioned in > the Header. Moreover, there must be some information about the migration or > coexistence from a previous CAPWAP environment that did not support IEEE > 802.11n and a new environment that supports .11n and the CAPWAP extensions > defined in this document > The coexistence mechanism could be simple: just ignore the message if not supported. > 2. The document needs a section of abbreviations - expand and explain if > necessary what OFDM, MIMO, etc. mean > OK > 3. There is a need of cleaning the English syntax - preferable by a native > English speaker. > OK, we will clean the text and find a native speaker to review. > 4. Keywords need to be used in a manner that is consistent and conforms to > RFC 2119. For example the 'may' in the first paragraph of Section 4.2, or > in the first paragraph of section 4.3 need to be capitalized. > OK > 5. Some of the fields need to have the units for the parameters added - > e.g. MaxRxFactor, Min StaSpacing, HiSuppDataRate > 6. In Section 5.3 I could not understand what 'Report Count: The channel > number will be reported' - is it a number or a count? > It is a count. Since this draft has been reviewed by IEEE experts and only editorial comments left, the authors believe it is ready for WGLC. Regards, Dapeng Liu Thanks and Regards, > > Dan > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > -- ------ Best Regards, Dapeng Liu --001a1133757693cca704ea541240 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan,

Thanks for your comments.
=

2013/10/30 Romasc= anu, Dan (Dan) <dromasca@avaya.com>
Hi,

I have read draft-ietf-opsawg-capwap-extension-01. I am no expert in IEEE 8= 02.11 technology, so I cannot confirm the accuracy of the .11-related infor= mation in this I-D. It looks like straight forward and consistent work, but= it needs review from the IEEE experts as long as several editorial improve= ments.


IEEE experts have reviewed the draft d= uring the September IEEE 802 wireless interim meeting. The 01 version draft= has been updated according to the comments received.
=A0
Here are my comments (mostly editorial, but important to make the document = readable and usable):

1. The document obviously updated RFC 5416. This needs to be mentioned in t= he Header. Moreover, there must be some information about the migration or = coexistence from a previous CAPWAP environment that did not support IEEE 80= 2.11n and a new environment that supports .11n and the CAPWAP extensions de= fined in this document
=A0
The coexistence mechanism could be simple: = just ignore the message if not supported.
=A0
2. The document needs a section of abbreviations - expand and explain if ne= cessary what OFDM, MIMO, etc. mean
OK=A0
3. There is a need of cleaning the English syntax - preferable by a native = English speaker.
OK, we will clean the text and find a= native speaker to review.=A0
4. Keywords need to be used in a manner that is consistent and conforms to = RFC 2119. For example the 'may' in the first paragraph of Section 4= .2, or in the first paragraph of section 4.3 need to be capitalized.
OK=A0
5. Some of the fields need to have the units for the parameters added - e.g= . MaxRxFactor, Min StaSpacing, HiSuppDataRate
6. In Section 5.3 I could not understand what 'Report Count: The channe= l number will be reported' - is it a number or a count?
=A0It is a count.

Since this draft has been = reviewed by IEEE experts and only editorial comments left, the authors beli= eve it is ready for WGLC.

Regards,
Dapeng Liu

Thanks and Regards,

Dan





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



--

------Best Regards,
Dapeng Liu
--001a1133757693cca704ea541240-- From dromasca@avaya.com Mon Nov 4 05:52:14 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6744111E81DC for ; Mon, 4 Nov 2013 05:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.302 X-Spam-Level: X-Spam-Status: No, score=-103.302 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKKUjFKMwKbf for ; Mon, 4 Nov 2013 05:52:08 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 1931411E8108 for ; Mon, 4 Nov 2013 05:52:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAC6ld1LGmAcV/2dsb2JhbABZgkMjIThTvnJLgScWdIIlAQEBAQMBAQEPGz4DCxACAQgNAQMEAQELHQchBgsUCQgCBA4FCBqHTQMPAQyhQJJhDYlUEwSMaII/LQQGAQaDGoEOA5YeAYhPhW6FN4Mmgio X-IronPort-AV: E=Sophos;i="4.93,632,1378872000"; d="scan'208,217";a="35111914" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Nov 2013 08:52:05 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Nov 2013 08:46:39 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Mon, 4 Nov 2013 14:52:03 +0100 From: "Romascanu, Dan (Dan)" To: Liu Dapeng Thread-Topic: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 Thread-Index: AQHO2SeSHkfEb4RrrEGldDGPIA0GsJoVFzVA Date: Mon, 4 Nov 2013 13:52:03 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1292A5AD@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1291CAE4@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA1292A5ADAZFFEXMB04globa_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 13:52:14 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA1292A5ADAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for your answers. I agree that the document is ready for WGLC. As= we seem to agree on the need for edits, please consider addressing my comm= ents for the next version of the document (including clarification text fo= r items #1 and #6). Regards, Dan From: Liu Dapeng [mailto:maxpassion@gmail.com] Sent: Monday, November 04, 2013 8:32 AM To: Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 Hi Dan, Thanks for your comments. 2013/10/30 Romascanu, Dan (Dan) > Hi, I have read draft-ietf-opsawg-capwap-extension-01. I am no expert in IEEE 8= 02.11 technology, so I cannot confirm the accuracy of the .11-related infor= mation in this I-D. It looks like straight forward and consistent work, but= it needs review from the IEEE experts as long as several editorial improve= ments. IEEE experts have reviewed the draft during the September IEEE 802 wireless= interim meeting. The 01 version draft has been updated according to the co= mments received. Here are my comments (mostly editorial, but important to make the document = readable and usable): 1. The document obviously updated RFC 5416. This needs to be mentioned in t= he Header. Moreover, there must be some information about the migration or = coexistence from a previous CAPWAP environment that did not support IEEE 80= 2.11n and a new environment that supports .11n and the CAPWAP extensions de= fined in this document The coexistence mechanism could be simple: just ignore the message if not s= upported. 2. The document needs a section of abbreviations - expand and explain if ne= cessary what OFDM, MIMO, etc. mean OK 3. There is a need of cleaning the English syntax - preferable by a native = English speaker. OK, we will clean the text and find a native speaker to review. 4. Keywords need to be used in a manner that is consistent and conforms to = RFC 2119. For example the 'may' in the first paragraph of Section 4.2, or i= n the first paragraph of section 4.3 need to be capitalized. OK 5. Some of the fields need to have the units for the parameters added - e.g= . MaxRxFactor, Min StaSpacing, HiSuppDataRate 6. In Section 5.3 I could not understand what 'Report Count: The channel nu= mber will be reported' - is it a number or a count? It is a count. Since this draft has been reviewed by IEEE experts and only editorial comme= nts left, the authors believe it is ready for WGLC. Regards, Dapeng Liu Thanks and Regards, Dan _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg -- ------ Best Regards, Dapeng Liu --_000_9904FB1B0159DA42B0B887B7FA8119CA1292A5ADAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for your answer= s. I agree that the document is ready for WGLC. As we seem to agree on the = need for edits, please consider addressing my comments for the next version of the document  (including clarification text for i= tems #1 and #6).

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: Liu Dape= ng [mailto:maxpassion@gmail.com]
Sent: Monday, November 04, 2013 8:32 AM
To: Romascanu, Dan (Dan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-0= 1

 

Hi Dan,

 

Thanks for your comments.

 

2013/10/30 Romascanu, Dan (Dan) <dromasca@avaya.com>

Hi,

I have read draft-ietf-opsawg-capwap-extension-01. I am no expert in IEEE 8= 02.11 technology, so I cannot confirm the accuracy of the .11-related infor= mation in this I-D. It looks like straight forward and consistent work, but= it needs review from the IEEE experts as long as several editorial improvements.

 

IEEE experts have reviewed the draft during the Sept= ember IEEE 802 wireless interim meeting. The 01 version draft has been upda= ted according to the comments received.

 

Here are my comments (mostly editorial, but importan= t to make the document readable and usable):

1. The document obviously updated RFC 5416. This needs to be mentioned in t= he Header. Moreover, there must be some information about the migration or = coexistence from a previous CAPWAP environment that did not support IEEE 80= 2.11n and a new environment that supports .11n and the CAPWAP extensions defined in this document

 

The coexistence mechanism could be simple: just igno= re the message if not supported.

 

2. The document needs a section of abbreviations - e= xpand and explain if necessary what OFDM, MIMO, etc. mean

OK 

3. There is a need of cleaning the English syntax - = preferable by a native English speaker.

OK, we will clean the text and find a native speaker= to review. 

4. Keywords need to be used in a manner that is cons= istent and conforms to RFC 2119. For example the 'may' in the first paragra= ph of Section 4.2, or in the first paragraph of section 4.3 need to be capi= talized.

OK 

5. Some of the fields need to have the units for the= parameters added - e.g. MaxRxFactor, Min StaSpacing, HiSuppDataRate
6. In Section 5.3 I could not understand what 'Report Count: The channel nu= mber will be reported' - is it a number or a count?

 It is a count.

 

Since this draft has been reviewed by IEEE experts a= nd only editorial comments left, the authors believe it is ready for WGLC.<= o:p>

 

Regards,

Dapeng Liu

 

Thanks and Regards,

Dan





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



 

--

------
Best Regards,
Dapeng Liu

--_000_9904FB1B0159DA42B0B887B7FA8119CA1292A5ADAZFFEXMB04globa_-- From melinda.shore@gmail.com Mon Nov 4 09:37:22 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE46321E81F5 for ; Mon, 4 Nov 2013 09:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEP3Sw3I5KNi for ; Mon, 4 Nov 2013 09:37:21 -0800 (PST) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 50FDA21E821A for ; Mon, 4 Nov 2013 09:34:55 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id e11so793080bkh.33 for ; Mon, 04 Nov 2013 09:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=aSJ1A72WxSpaudCZJFTgDsPpJHMNNYPO2pMSD9vXeSE=; b=0dzxX6/+1dx7XpbIpPZLdX5VcqRrjRJVaRvVarki2xbfK6ZTuzH789ckPiJ9fW1wY4 hjlvaGnc3mF1lwiILUSJS2dTUU7NiaXpK7dStkRF8pZOLJpkK9k9OWrCnP8unm91D0gF kzk9iVLx4Gjcj7jdHkpeKRlOvrqkW7eX6wS4kwJw6QS1YlQUoUmhZdWjeI2xP9IYd6Le sHpqsf3joMuWVWBXNBc3fT5CIqR5NxYo4hpo5/0BcObho/MYZylyD80nOh5uV+gMTuPr fX3eqLt+cEvOR4Xy1xDVsd11TYWQYc8zztztuzNOVq7UPtUB1ZqZBf+eNLzpvfjcvBjh rRCg== X-Received: by 10.204.230.17 with SMTP id jk17mr7712319bkb.6.1383586493475; Mon, 04 Nov 2013 09:34:53 -0800 (PST) Received: from ?IPv6:2001:67c:370:160:4d45:4a68:a6c5:d83? ([2001:67c:370:160:4d45:4a68:a6c5:d83]) by mx.google.com with ESMTPSA id no2sm16177950bkb.15.2013.11.04.09.34.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 09:34:53 -0800 (PST) Message-ID: <5277DABA.6080902@gmail.com> Date: Mon, 04 Nov 2013 09:34:50 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Call for adoption reminder X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 17:37:23 -0000 Just a reminder. If you haven't yet done so, please give the VM MIB draft a read and provide feedback to the mailing list on whether or not you feel it should be adopted as a working group document: We are starting a call for working group adoption of "Management Information Base for Virtual Machines Controlled by a Hypervisor," https://datatracker.ietf.org/doc/draft-asai-vmm-mib/. This document has received extensive discussion on the opsawg mailing list and is on its 5th revision, and we believe it meets the criteria for consideration for adoption laid out by Benoit at IETF 86: 1. reach out to other people for review, 2. potentially put the bar higher for WG adoption 3. solicit reviews from chairs and AD 4. if no feedback, kill it. Demonstrate support. We've also allowed some time for discussion during the meeting session next Tuesday. We will be assessing consensus on Wednesday, 13 November. Please review the current version of the document, let us know whether or not you support adoption, and raise any issues you've identified. Thanks, Melinda, Scott, Warren From maxpassion@gmail.com Mon Nov 4 10:22:33 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B377811E82BA for ; Mon, 4 Nov 2013 10:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVjE9hZyFn-s for ; Mon, 4 Nov 2013 10:22:32 -0800 (PST) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3962F11E82B5 for ; Mon, 4 Nov 2013 10:22:29 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id cz12so1698072veb.17 for ; Mon, 04 Nov 2013 10:22:28 -0800 (PST) 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=ENBW/eeNwIrOHwG6HNrL9t0dx44tLTtTgLU9vJlHLX4=; b=i4g2aRE0sBoqC5gzXnxU0fj+rKQ5giGMeHbk6Dm1IM7Zg8iV7d4TX3yng0vBthrfJF N4YB5xzVtnwji6TkgJpR7oisbxQpzvKfPTLd5px/slNp6luzWueac0lAb7eEeIJUJ2Lj tlRDyZTOFb/E9W4EOnbqKNmvBhV7OK0N9qG2Se8l7ITj9L5URXzSfNrmaAAY32P8QRXe HRly337E4d4HZJwsYRT0SR7urncNe7u1xhfDSD14mXJrikqTzxAKFrE218YYliyXA0a6 P/DUq9e1k/kNdgt5vW2aZz0yIlLKtvdGEp+fI/6KnYeHrxwwMUyS3vdK8gdJNRYipZn3 DvNg== MIME-Version: 1.0 X-Received: by 10.58.186.173 with SMTP id fl13mr800430vec.31.1383589348515; Mon, 04 Nov 2013 10:22:28 -0800 (PST) Received: by 10.220.220.69 with HTTP; Mon, 4 Nov 2013 10:22:28 -0800 (PST) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1292A5AD@AZ-FFEXMB04.global.avaya.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1291CAE4@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1292A5AD@AZ-FFEXMB04.global.avaya.com> Date: Tue, 5 Nov 2013 02:22:28 +0800 Message-ID: From: Liu Dapeng To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=047d7b6dd1c6a2290804ea5dff17 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:22:34 -0000 --047d7b6dd1c6a2290804ea5dff17 Content-Type: text/plain; charset=ISO-8859-1 Hi Dan, Thank you for your kind review and valuable comments. We will address all your comments in the next version and will improve the writing as well. Tom Taylor has volunteered to do the editorial review and that would be very helpful to improve the quality of the draft. Many thanks to Tom. Thanks, Dapeng Liu 2013/11/4 Romascanu, Dan (Dan) > Thank you for your answers. I agree that the document is ready for WGLC. > As we seem to agree on the need for edits, please consider addressing my > comments for the next version of the document (including clarification > text for items #1 and #6). > > > > Regards, > > > > Dan > > > > > > > > *From:* Liu Dapeng [mailto:maxpassion@gmail.com] > *Sent:* Monday, November 04, 2013 8:32 AM > *To:* Romascanu, Dan (Dan) > *Cc:* opsawg@ietf.org > *Subject:* Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 > > > > Hi Dan, > > > > Thanks for your comments. > > > > 2013/10/30 Romascanu, Dan (Dan) > > Hi, > > I have read draft-ietf-opsawg-capwap-extension-01. I am no expert in IEEE > 802.11 technology, so I cannot confirm the accuracy of the .11-related > information in this I-D. It looks like straight forward and consistent > work, but it needs review from the IEEE experts as long as several > editorial improvements. > > > > IEEE experts have reviewed the draft during the September IEEE 802 > wireless interim meeting. The 01 version draft has been updated according > to the comments received. > > > > Here are my comments (mostly editorial, but important to make the document > readable and usable): > > 1. The document obviously updated RFC 5416. This needs to be mentioned in > the Header. Moreover, there must be some information about the migration or > coexistence from a previous CAPWAP environment that did not support IEEE > 802.11n and a new environment that supports .11n and the CAPWAP extensions > defined in this document > > > > The coexistence mechanism could be simple: just ignore the message if not > supported. > > > > 2. The document needs a section of abbreviations - expand and explain if > necessary what OFDM, MIMO, etc. mean > > OK > > 3. There is a need of cleaning the English syntax - preferable by a native > English speaker. > > OK, we will clean the text and find a native speaker to review. > > 4. Keywords need to be used in a manner that is consistent and conforms to > RFC 2119. For example the 'may' in the first paragraph of Section 4.2, or > in the first paragraph of section 4.3 need to be capitalized. > > OK > > 5. Some of the fields need to have the units for the parameters added - > e.g. MaxRxFactor, Min StaSpacing, HiSuppDataRate > 6. In Section 5.3 I could not understand what 'Report Count: The channel > number will be reported' - is it a number or a count? > > It is a count. > > > > Since this draft has been reviewed by IEEE experts and only editorial > comments left, the authors believe it is ready for WGLC. > > > > Regards, > > Dapeng Liu > > > > Thanks and Regards, > > Dan > > > > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > > > > > -- > > ------ > Best Regards, > Dapeng Liu > -- ------ Best Regards, Dapeng Liu --047d7b6dd1c6a2290804ea5dff17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dan,

Thank you for your kind review and v= aluable comments. We will address all your comments in the next version and= will improve the writing as well.
=A0 Tom Taylor has=A0volunte= ered to do the=A0editorial=A0review and that would be very helpful to impro= ve the quality of the draft. Many thanks to Tom.

= Thanks,
Dapeng Liu
2013/11/4 Romascanu, Dan (Dan) <= dromasca@avaya.com<= /a>>

Thank you for your answers. I agree that the= document is ready for WGLC. As we seem to agree on the need for edits, ple= ase consider addressing my comments for the next version of the document=A0 (including clarification text for item= s #1 and #6).

=A0

Regards,

=A0

Dan

=A0

=A0

=A0

From: Liu Dapeng [mailto:maxpassion@gmail.com]
Sent: Monday, November 04, 2013 8:32 AM
To: Romascanu, Dan (Dan)
Cc: opsawg@ietf= .org
Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-0= 1

=A0

Hi Dan,

=A0

Thanks for your comments.

=A0

2013/10/30 Romascanu, Dan (Dan) <dromasca@avaya.com>

Hi,

I have read draft-ietf-opsawg-capwap-extension-01. I am no expert in IEEE 8= 02.11 technology, so I cannot confirm the accuracy of the .11-related infor= mation in this I-D. It looks like straight forward and consistent work, but= it needs review from the IEEE experts as long as several editorial improvements.

=A0

IEEE experts have reviewed the draft during the Sept= ember IEEE 802 wireless interim meeting. The 01 version draft has been upda= ted according to the comments received.

=A0

Here are my comments (mostly editorial, but importan= t to make the document readable and usable):

1. The document obviously updated RFC 5416. This needs to be mentioned in t= he Header. Moreover, there must be some information about the migration or = coexistence from a previous CAPWAP environment that did not support IEEE 80= 2.11n and a new environment that supports .11n and the CAPWAP extensions defined in this document=

=A0

The coexistence mechanism could be simple: just igno= re the message if not supported.

=A0

2. The document needs a section of abbreviations - e= xpand and explain if necessary what OFDM, MIMO, etc. mean

OK=A0

3. There is a need of cleaning the English syntax - = preferable by a native English speaker.

OK, we will clean the text and find a native speaker= to review.=A0

4. Keywords need to be used in a manner that is cons= istent and conforms to RFC 2119. For example the 'may' in the first= paragraph of Section 4.2, or in the first paragraph of section 4.3 need to= be capitalized.

OK=A0

5. Some of the fields need to have the units for the= parameters added - e.g. MaxRxFactor, Min StaSpacing, HiSuppDataRate
6. In Section 5.3 I could not understand what 'Report Count: The channe= l number will be reported' - is it a number or a count?

=A0It is a count.

=A0

Since this draft has been reviewed by IEEE experts a= nd only editorial comments left, the authors believe it is ready for WGLC.<= u>

=A0

Regards,

Dapeng Liu

=A0

Thanks and Regards,

Dan





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



=A0

--

------
Best Regards,
Dapeng Liu




--

------Best Regards,
Dapeng Liu
--047d7b6dd1c6a2290804ea5dff17-- From sirokuma@k.u-tokyo.ac.jp Mon Nov 4 15:47:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6FF21E813C for ; Mon, 4 Nov 2013 15:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.362 X-Spam-Level: X-Spam-Status: No, score=-1.362 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, X_IP=3.177] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USMpAxxw05dm for ; Mon, 4 Nov 2013 15:46:59 -0800 (PST) Received: from mailv1.ecc.u-tokyo.ac.jp (mailv1.ecc.u-tokyo.ac.jp [133.11.225.59]) by ietfa.amsl.com (Postfix) with ESMTP id AB8E721E8126 for ; Mon, 4 Nov 2013 15:46:55 -0800 (PST) Received: from ums002.ecc.u-tokyo.ac.jp (ums002.ecc.u-tokyo.ac.jp [133.11.50.162]) by mailv1.ecc.u-tokyo.ac.jp (Postfix) with ESMTP id 0BAA76C003B for ; Tue, 5 Nov 2013 08:46:55 +0900 (JST) Received: from mail-pb0-f53.google.com (209.85.160.53 [209.85.160.53]) by ums002.ecc.u-tokyo.ac.jp (deepsmtpd.so 3.7.0) with ESMTP id for ; Tue, 5 Nov 2013 08:46:52 +0900 Received: by mail-pb0-f53.google.com with SMTP id up7so7724298pbc.26 for ; Mon, 04 Nov 2013 15:46:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=sen1ezXHTll74oxYZMHmRWTVKHC/O/0nKT+Nd9Bsvzc=; b=XT+Xn8P8cUP+wuAjz/DdWsZGXhh5ZTBhOI1x2ChwLdnrdeoNp2UuUOFqQZ8MxlfOX3 jFOBBR3dlgM1z7DnS1qLHGR2egkLeL6bgfD2T3pXoAnN/jgv8kMFm0eV0feIPcFj60Fu zwxZAOAxXhCbKLCQZoJTJa//rAzMFyZec64eAiqlGKYnhtSpjIZncMD/vSm7UwEpo3eT yNZBzV3Bd/05I/BxMiyRRKK4dHUxx1VR6k8lGb6NCglM6XwVuBX/mmLAG992NakBPLDH hfElVhlTkk4yM1ns/3cq+F1ZpntKnMZMSfPDL3DSyeSQ7JNoQQl/9LzQUHoBgNu5rdWj eI4A== MIME-Version: 1.0 X-Received: by 10.69.12.36 with SMTP id en4mr20007201pbd.54.1383608810600; Mon, 04 Nov 2013 15:46:50 -0800 (PST) Received: by 10.70.53.164 with HTTP; Mon, 4 Nov 2013 15:46:50 -0800 (PST) Date: Mon, 4 Nov 2013 15:46:50 -0800 Message-ID: From: Shunsuke Fujieda To: opsawg@ietf.org Content-Type: multipart/mixed; boundary=047d7b6758baaac46604ea62872a X-IP: 209.85.160.53 X-FROM-DOMAIN: k.u-tokyo.ac.jp X-FROM-EMAIL: sirokuma@k.u-tokyo.ac.jp Subject: [OPSAWG] EOI: Emergency Open Internet X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:47:06 -0000 --047d7b6758baaac46604ea62872a Content-Type: text/plain; charset=ISO-8859-1 Hello, My name is Shunsuke Fujieda, I have a proposal of making a reference operation plan of emergency free Wi-Fi on a time of a disaster. Free Wi-FI is not common in some regions, but it is very useful if they were offered at many places for neighboring people at the time of a disaster for a short period. We named this concept as EOI: Emergency Open Internet. Please see the attached file or the google document. https://docs.google.com/document/d/19eAMNAF8Muz57C-g0KEoQygLdF8mOieAP1LfDOqn7kM/edit I'm sorry that my proposal is not yet ID format... Is this topic suitable for this WG? And is there anyone who is interested in this topic? I'll stay in Vancouver until Wednesday. Please contact me on your convenience time. Thank you, Shunsuke --047d7b6758baaac46604ea62872a Content-Type: text/plain; charset=UTF-8; name="EOI-short.txt" Content-Disposition: attachment; filename="EOI-short.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hnmctn3v0 77u/DQpUaGUgQ29uY2VwdCBhbmQgU3RhbmRhcmRpemF0aW9uIE5lZWQgb2YgRU9JOiBFbWVyZ2Vu Y3kgT3BlbiBJbnRlcm5ldA0KU2h1bnN1a2UgRnVqaWVkYSwgVGhlIFVuaXZlcnNpdHkgb2YgVG9r eW8gKHNpcm9rdW1hQGsudS10b2t5by5hYy5qcCkNCg0KPE1vdGl2YXRpb24+DQpGcmVlIHdpcmVs ZXNzIExBTiBpcyBub3QgY29tbW9uIGluIHNvbWUgcmVnaW9ucywgYnV0IGl0IGlzIHZlcnkgdXNl ZnVsIGlmIHRoZXkgd2VyZSBvZmZlcmVkIGF0IG1hbnkgcGxhY2VzIGF0IHRoZSB0aW1lIG9mIGEg ZGlzYXN0ZXIgZm9yIGEgc2hvcnQgcGVyaW9kLiBCZWNhdXNlIHdpcmVsZXNzIExBTiBpcyB0aGUg Ym9yZGVybGVzcyBjb21tdW5pY2F0aW9uIG1lZGl1bSB0aGF0IGlzIGF2YWlsYWJsZSBldmVuIGZv ciBmb3JlaWduIHRvdXJpc3RzLiBPbiB0aGUgR3JlYXQgRWFzdCBKYXBhbiBFYXJ0aHF1YWtlLCBz b21lIHB1YmxpYyB3aXJlbGVzcyBMQU4gY2FycmllcnMgb3BlbmVkIHRoZWlyIGFjY2VzcyBwb2lu dHMgYmVmb3JlIGxvbmcgZnJvbSB0aGUgb3V0YnJlYWsgb2YgdGhlIGVhcnRocXVha2UuIEhvd2V2 ZXIsIGl0IHRvb2sgdGltZSB0byBwdWJsaWNpemUgdGhlIGZhY3QgYW5kIHRoZSB1c2FnZSBieSB0 aGVpciB3ZWIgc2l0ZSBvciBTTlMgc3VjaCBhcyBUd2l0dGVyLiBBbmQgYWx0aG91Z2ggdGhleSBp bnZhbGlkYXRlZCBzZWN1cml0eSBzZXR0aW5ncyBvZiBzdWNoIGZyZWUgc2lnbmFscywgdXNlcnMg c3RpbGwgaGFkIGEgcHJvYmxlbSBvbiB1bmRlcnN0YW5kaW5nIHdoaWNoIHNpZ25hbHMgd2VyZSBm cmVlLCBiZWNhdXNlIGZyZWUgU1NJRHMgd2VyZSBkaWZmZXJlbnQgYnkgcHJvdmlkZXJzIGFuZCB0 aGVyZSB3ZXJlIHNpZ25hbHMgd2l0aG91dCBsYXllcjIgcmVzdHJpY3Rpb25zIGJ1dCB3aXRoIG90 aGVyIHJlc3RyaWN0aW9ucyBzdWNoIGFzIHdlYiBhdXRoZW50aWNhdGlvbiwgTUFDIGFkZHJlc3Mg ZmlsdGVyaW5nLCBvciBsYXllcjMgZmlsdGVycyB0byB0aGUgaW50ZXJuZXQgaW4gYSBwZWFjZXRp bWUuIEluIG90aGVyIGdlbmVyYWwgb3JnYW5pemF0aW9ucywgc3VjaCBhcyBpbiB1bml2ZXJzaXRp ZXMsIGl0IHdhcyByYXJlIGlmIHRoZXkgY291bGQgb3BlbiB0aGVpciB3aXJlbGVzcyBMQU4gYmVj YXVzZSB0aGV5IHdlcmUgYWxzbyBpbiBjb25mdXNpb25zLiBOb3dhZGF5cyBzdWNoIG9yZ2FuaXph dGlvbnMgYWxzbyBjb25jZXJuIHdpdGggb3BlbmluZyB0aGVpciB3aXJlbGVzcyBMQU4gdG8gdGhl IHBlb3BsZSBvZiB0aGUgbmVpZ2hib3Job29kIGF0IHRoZSB0aW1lIG9mIGEgZGlzYXN0ZXIsIGJ1 dCBpdCBiZWNvbWVzIHRoZSBodXJkbGUgdGhhdCB0aGVyZSBpcyBub3QgYSB3ZWxsLWtub3duIG1l dGhvZC4gDQoNCiBUaGVyZSBhcmUgMiByZWFzb25zIHdoeSBhIHdlbGwta25vd24gbWV0aG9kIGZv ciBlbWVyZ2VuY3kgZnJlZSB3aXJlbGVzcyBMQU4gaXMgbmVjZXNzYXJ5Lg0KMSkgVGltZSBsYWc6 IFRoZSB0aW1lIG9uIHdoaWNoIHRlbGVjb20gZGVtYW5kcyBhbmQgdGhlIGluZmx1ZW5jZSBvbiBt b2JpbGUgdGVsZWNvbSBuZXR3b3JrcyBhcmUgdGhlIGJpZ2dlc3Qgd291bGQgYmUganVzdCBhZnRl ciB0aGUgYnJlYWtvdXQgb2YgYSBkaXNhc3Rlci4gRXZlbiBpZiB3aXJlbGVzcyBMQU5zIHdlcmUg b3BlbmVkLCBpZiB0aGUgZmFjdCBhbmQgdXNhZ2UgbmVlZGVkIHRvIGJlIGFubm91bmNlZCBhZnRl ciB0aGUgZGlzYXN0ZXIsIGl0IGlzIGhhcmQgdG8gYmUgdXNlZCBvbiB0aW1lLiBUaHVzIGNvbW1v biB1bmRlcnN0YW5kaW5nIG9mIEVPSSBieSBib3RoIOKAnHByb3ZpZGVycyBhbmQgdXNlcnPigJ0g YXJlIG5lZWRlZC4NCjIpIFVzZXJiaWxpdHk6IElmIG9wZW5pbmcgbWV0aG9kcyBvZiB3aXJlbGVz cyBMQU5zIGFyZSBpbmRpdmlkdWFsIGJ5IHByb3ZpZGVycywgdXNlcnMgd2lsbCBuZWVkIGVmZm9y dCB0byBzdHVkeSB1c2FnZXMgd2l0aG91dCBlbm91Z2ggaGVscC4gQW5kIHdoZW4gdXNlcnMgbW92 ZSB0byBhbm90aGVyIHBsYWNlLCBvdGhlciBtZXRob2QgbWF5IGJlIHJlcXVpcmVkIG5ld2x5Lg0K DQo8UHJvcG9zYWw+DQpJdCBpcyBvdXQgb2Ygc2NvcGUgdGhhdCB3aGV0aGVyIEVPSSBtdXN0IGJl IHByb3ZpZGVkIG9yIG5vdC4gVGhhdCB3aWxsIGRlcGVuZCBvbiB0aGUgc2l0dWF0aW9uLCBjb3Vu dHJ5LCBhbmQgcG9pbnQgb2Ygdmlldy4gV2UgcHJvcG9zZSBqdXN0IG1ha2luZyBhIHJlYWxpc3Rp YyByZWZlcmVuY2UgbWV0aG9kIHRoYXQgY2FuIGJlIHVzZWQgcmlnaHQgbm93LCB0byBoZWxwIHBl b3BsZSB3aG8gcHJlcGFyZSBFT0kgdG9kYXkuICBXZSBrbm93IHRoaXMgbWV0aG9kIGlzIG5vdCBz YWZlLCBhbmQgd2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byBzZWUgYSBiZXR0ZXIgbWV0aG9kIG9m IEVPSSBiZWNvbWVzIGF2YWlsYWJsZSBpbiBmdXR1cmUuDQoNCkEpIFdpcmVsZXNzIExBTiBDb25m aWd1cmF0aW9uDQoqIEF1dGhlbnRpY2F0aW9uOiBPcGVuIFN5c3RlbQ0KKiBFbmNyeXB0aW9uOiBO byBFbmNyeXB0aW9uDQoqIEVTU0lEOiBFT0ktWFhYDQoqIEVhY2ggb3JnYW5pemF0aW9uIG11c3Qg c2V0IHRoZSBwYXJ0IG9mIFhYWCBpbmRpdmlkdWFsbHk7IHRoYXQgY2FuIGJlIGluZGl2aWR1YWwg ZXZlbiBieSBwb3N0cy4NCiogRVNTSUQgc2hvdWxkIGJlIGFubm91bmNlZCBieSBiZWFjb24uDQog VGhlIHJlYXNvbiBvZiBkaXZpZGluZyBTU0lEIGludG8gYSBwbHVyYWwgbnVtYmVyIGlzLA0KMSkg SWYgYWxsIG9yZ2FuaXphdGlvbnMgc2V0IHNhbWUgRVNTSUQgKGUuZy4sIEVPSSkgYW5kIHRoZXJl IGFyZSBzZXZlcmFsIEFQcyBieSBkaWZmZXJlbnQgb3JnYW5pemF0aW9ucyBvbiBhbiBhcmVhLCB3 aGljaCBtZWFucyB0aGF0IHRoZXJlIGFyZSBzZXZlcmFsIGJhY2t5YXJkIElQIHN1Ym5ldHMgYmVo aW5kIEFQcyBidXQgY2xpZW50cyBjYW5ub3QgcmVjb2duaXplIHRoZW0uIFdoZW4gYSBjbGllbnQg bW92ZXMgYmV0d2VlbiB0aG9zZSBBUHMsIGl0IGV4cGVjdHMgc2FtZSBJUCBzdWJuZXQgYmVoaW5k IHRoZW0uIEJ1dCB0aGUgSVAgYWRkcmVzcyBnb3Qgb24gZm9ybWVyIEFQIGlzIG5vdCBhdmFpbGFi bGUgaW4gbGF0dGVyIEFQLCB0aHVzIHRoZSBjbGllbnQgbWF5IGJlIGNvbW11bmljYXRpb24gdW5h dmFpbGFibGUgZm9yIHNvbWUgcGVyaW9kcy4gDQoyKSBTb21lIEFQcyBtYXkgaGF2ZSB0cm91Ymxl IG9uIHRoZWlyIHVwcGVyIGxpbmtzLCBhbmQgdGhleSBtYXkgbm90IGJlIGFibGUgdG8gcHJvdmlk ZSBhY2Nlc3MgdG8gdGhlIGludGVybmV0IGV2ZW4gaWYgdGhlaXIgc2lnbmFsIHdhcyBhbGl2ZS4g V2UgY2FsbCBzdWNoIEFQICJCbGFjayBIb2xlIEFQ4oCdIHdoaWNoIHN1Y2tzIGNsaWVudHMuIElm IHRoZXJlIGFyZSBCbGFjayBIb2xlIEFQcyBhbmQgd29ya2luZyBBUHMgb24gYW4gYXJlYSwgY2xp ZW50cyBtdXN0IHNlbGVjdCB3b3JraW5nIEFQcyBhbnl3YXksIHNvIHNlcGFyYXRpb24gb2YgRVNT SURzIGFyZSByZXF1aXJlZC4NCg0KQikgUHJpbmNpcGxlcw0KKiBFT0kgc2hvdWxkIGJlIGZyZWUg b2YgY2hhcmdlLg0KKiBFT0kgc2hvdWxkIGJlIHByb3ZpZGVkIGZvciBvbmx5IGEgbGltaXRlZCBw ZXJpb2QgZHVyaW5nIGVtZXJnZW5jeSBzaXR1YXRpb25zLg0KKiBUaGUgdXNhZ2UgYW5kIHJlY29y ZHMgb2YgdGhlIHVzZSBvZiBFT0kgbXVzdCBub3QgYmUgdXNlZCBmb3IgcmVnaXN0cmF0aW9uIG9y IHRoZSBpbnZpdGF0aW9uIHRvIG90aGVyIHNlcnZpY2VzLg0KDQpDKSBTdGFydCBUaW1lIGFuZCBQ ZXJpb2RbMV0NCiogVGFyZ2V0IHN0YXJ0IHRpbWU6IGJlZm9yZSBzaXggaG91cnMgbGF0ZXIgZnJv bSB0aGUgZGlzYXN0ZXINCiogU2hvcnRlc3QgZHVyYXRpb246IHVudGlsIDcyIGhvdXJzIGxhdGVy IGZyb20gdGhlIGRpc2FzdGVyDQoqIFRpbWUgdG8gZXhhbWluZSB0aGUgc2VydmljZSBlbmQ6IEF0 IDcyIGhvdXJzIGFuZCAyd2Vla3MgbGF0ZXIgZnJvbSB0aGUgZGlzYXN0ZXINCiBFYWNoIEVPSSBw cm92aWRlciBwZXJmb3JtcyBqdWRnbWVudHMgb2YgdGhlIHNlcnZpY2UgZW5kIGluZGl2aWR1YWxs eS4gSG93ZXZlciwgaXQgbWF5IG9ic3RydWN0IHRlbGVjb20gYnVzaW5lc3MgaWYgd2UgY29udGlu dWVkIGZyZWUgaW50ZXJuZXQgc2VydmljZXMgZWFzaWx5IGFmdGVyIHRoZSBzaXR1YXRpb24gY2Fs bWVkLiBUaGVyZWZvcmUsIHNvbWUgcGhhc2VzIGFyZSBkZWZpbmVkIHRvIGV4YW1pbmUgdGhlIHNl cnZpY2UgZW5kIGFzIGFib3ZlLiANCl9fX19fX19fX19fX19fX18NClsxXSBUaGVzZSBjcml0ZXJp YSBvZiB0aW1lbGluZSBhcmUgYmFzZWQgb24gaW5zdHJ1Y3Rpb25zIGFib3V0IGFwcHJvcHJpYXRl IGFjdGlvbnMgb24gYSBkaXNhc3RlciBieSBKYXBhbmVzZSBnb3Zlcm5tZW50IG9mZmljZS4= --047d7b6758baaac46604ea62872a-- From dromasca@avaya.com Mon Nov 4 15:57:18 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49BA11E8105 for ; Mon, 4 Nov 2013 15:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.31 X-Spam-Level: X-Spam-Status: No, score=-103.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VazcmsW02Ps5 for ; Mon, 4 Nov 2013 15:57:13 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id BC9BC11E81F7 for ; Mon, 4 Nov 2013 15:57:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHAO8yeFLGmAcV/2dsb2JhbABZgmYhOFO+ckuBJxZtB4IlAQEBAQMBAQEPCx00FwQCAQgNBAQBAQsUCQcnCxQJCAIEEwgah18BDKE7nGMTBI8nOAaDGoEOA55uiyWDJoIq X-IronPort-AV: E=Sophos;i="4.93,636,1378872000"; d="scan'208";a="35212068" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 Nov 2013 18:57:12 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 04 Nov 2013 18:51:44 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0146.000; Tue, 5 Nov 2013 00:57:11 +0100 From: "Romascanu, Dan (Dan)" To: "opsawg@ietf.org" Thread-Topic: [OPSAWG] Call for adoption reminder Thread-Index: AQHO2YSKFoBvdqFiGE2ZEwDEISSjcJoVv9WQ Date: Mon, 4 Nov 2013 23:57:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1292B60A@AZ-FFEXMB04.global.avaya.com> References: <5277DABA.6080902@gmail.com> In-Reply-To: <5277DABA.6080902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Call for adoption reminder X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:57:18 -0000 I support adopting this document as WG item.=20 Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Monday, November 04, 2013 7:35 PM > To: opsawg@ietf.org > Subject: [OPSAWG] Call for adoption reminder >=20 > Just a reminder. If you haven't yet done so, please give the VM MIB > draft a read and provide feedback to the mailing list on whether or not > you feel it should be adopted as a working group document: >=20 > We are starting a call for working group adoption of "Management > Information Base for Virtual Machines Controlled by a Hypervisor," > https://datatracker.ietf.org/doc/draft-asai-vmm-mib/. > This document has received extensive discussion on the opsawg mailing > list and is on its 5th revision, and we believe it meets the criteria > for consideration for adoption laid out by Benoit at IETF 86: >=20 > 1. reach out to other people for review, > 2. potentially put the bar higher for WG adoption > 3. solicit reviews from chairs and AD > 4. if no feedback, kill it. Demonstrate support. >=20 > We've also allowed some time for discussion during the meeting session > next Tuesday. >=20 > We will be assessing consensus on Wednesday, 13 November. > Please review the current version of the document, let us know whether > or not you support adoption, and raise any issues you've identified. >=20 > Thanks, >=20 > Melinda, Scott, Warren > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From panda@hongo.wide.ad.jp Mon Nov 4 18:38:19 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE8621E82F0 for ; Mon, 4 Nov 2013 18:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.393 X-Spam-Level: ** X-Spam-Status: No, score=2.393 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILa0pEEIZybk for ; Mon, 4 Nov 2013 18:38:15 -0800 (PST) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1DED221E80F1 for ; Mon, 4 Nov 2013 18:38:15 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:74a4:d62b:7d9f:6d6e]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 044D0108E50A; Tue, 5 Nov 2013 11:38:12 +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: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> Date: Mon, 4 Nov 2013 18:38:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> To: Saperia Jon X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Comments on draft-asai-vmm-mib-05 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 02:38:19 -0000 Dear Jon, Thank you for your comments. I'm sorry for replying late but it took = some time to review the objects you proposed. First of all, I understand that these objects might be useful, = especially for analyzing the performance problems of virtual machines. However, I think we need discussion on these objects because they might be uncommon to the current implementations of hypervisors. The objects in the MIB module should be supported by implementation. I've checked the current implementation of Xen and KVM whether these are managed and accessible in these hypervisors. However, as far as I know, these objects are not accessible through their API. IMO, these objects are not commonly-used-measures at this moment, and consequently, they are not good to be added to the MIB module now. We might be able to work on updating the MIB module when they are implemented and commonly used in future. If you know any hypervisors providing these measures to operators, I would like you to share the information and let's discuss whether we'd add them. Best regards, Hirochika On Oct 24, 2013, at 10:08 AM, Saperia Jon wrote: > I thought two additional objects might be of value based on current = experience: >=20 > cpuReadyTime - how much time a VM is waiting for CPU resources. This = could be expressed in milliseconds over the past minute. >=20 > storageLatency - a problem that sometimes comes up is that the CPU is = available to the VM but due to storage latency work can not continue. = This object will show average storage latency over a short period of = time (perhaps 15 seconds). =20 >=20 > Notifications should be created for these two objects that can be sent = when values exceed configurable limits. >=20 > Thank you=20 > /jon >=20 > Jon Saperia > saperia@g.harvard.edu > Enterprise Architect > Harvard University Information Technology > Innovation & Architecture > (P) (617) 384-6683 > 1350 Mass Ave., room 758 > Cambridge, MA 02138 >=20 >=20 >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --=20 Hirochika Asai , The University of Tokyo From tom.taylor.stds@gmail.com Tue Nov 5 02:54:22 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D29421F9344 for ; Tue, 5 Nov 2013 02:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiMDqODeQnlz for ; Tue, 5 Nov 2013 02:54:21 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 949B121E823B for ; Tue, 5 Nov 2013 02:54:17 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so14911120iec.34 for ; Tue, 05 Nov 2013 02:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ey+3bcDpT9DFKhhJ3DLyMjSoT3hLgi8x/IJiEXu5w5c=; b=gANjqO74DCaDdpiZwk3aAPDU4JsAq52KfDFeqqpKuthac8rjzwEcgC9n3xCj4KnkxU cP19mmwG1I5UsZg3U30YnmLaVT41YNGL9625j84F132E83UIePs7R8FnwawRMJYqMvL0 atb+mdHMfBzcGK2m4VBOk+8rLPMHK1M7r8193aqPCCPtlJ8GYcr52dA5TOe+nWoEMZTG Vg25ThgRrsRMa8yR4PR5Mj2oRhHUod0i3KKnPKFE8HcYocHzJ6fxR1eOEs2Vx2y0PNYa C/gggV2JIMhZz1PKeeFpiB6gmQqJ8+FhOGSumD9h2voH9kQMdZYdryvkaP4c6Rt2oPxN ZLcQ== X-Received: by 10.42.29.129 with SMTP id r1mr771598icc.44.1383648857162; Tue, 05 Nov 2013 02:54:17 -0800 (PST) Received: from [192.168.1.69] ([64.56.250.4]) by mx.google.com with ESMTPSA id i11sm7924146igh.0.2013.11.05.02.54.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 02:54:16 -0800 (PST) Message-ID: <5278CE55.7000003@gmail.com> Date: Tue, 05 Nov 2013 05:54:13 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Liu Dapeng References: <9904FB1B0159DA42B0B887B7FA8119CA1291CAE4@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1292A5AD@AZ-FFEXMB04.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 10:54:22 -0000 I'm doing the editorial review I promised, but I'm having a little problem with Section 4.1 (which may also apply to other sections as I move forward). Section 4.1 says at first that it is defining a new 802.11n Radio Capability information element. Then at the end of the paragraph, it says it is defining a new 802.11n Radio Capability message element. I don't believe it is doing either one. Instead, it should simply say that this document specifies use of the IEEE 802.11 Information Element to transport the IEEE 802.11 HT information element. Does this sound reasonable? Tom On 04/11/2013 1:22 PM, Liu Dapeng wrote: > Hi Dan, > > Thank you for your kind review and valuable comments. We will address all > your comments in the next version and will improve the writing as well. > Tom Taylor has volunteered to do the editorial review and that would be > very helpful to improve the quality of the draft. Many thanks to Tom. > ... From Johannes.Merkle@secunet.com Tue Nov 5 07:58:53 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE521E81CF for ; Tue, 5 Nov 2013 07:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.541 X-Spam-Level: X-Spam-Status: No, score=-3.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hSiyigvRQNz for ; Tue, 5 Nov 2013 07:58:42 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id B16A921E81BF for ; Tue, 5 Nov 2013 07:58:32 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 031051A0075; Tue, 5 Nov 2013 16:58:30 +0100 (CET) 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 1C0BE4x1wQ6d; Tue, 5 Nov 2013 16:58:28 +0100 (CET) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id E597E1A0071; Tue, 5 Nov 2013 16:58:28 +0100 (CET) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Nov 2013 16:58:29 +0100 Message-ID: <527915A4.6060900@secunet.com> Date: Tue, 05 Nov 2013 16:58:28 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: opsawg@ietf.org X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2013 15:58:29.0174 (UTC) FILETIME=[DE8A8D60:01CEDA3F] Cc: Manfred Lochter , turners@ieca.com Subject: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:58:53 -0000 we have published a draft on a new authentication protocol for USM for SNMP. Abstract This memo specifies a new optional HMAC-SHA-256-128 authentication protocol for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. The new protocol is a straightforward adaptation of the protocols HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the SHA-256 based HMAC with truncation to 128 bits. Comments and suggestions are welcome. Is there any interest in adoption by the WG? -- Johannes From Johannes.Merkle@secunet.com Tue Nov 5 08:00:54 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEF911E8292 for ; Tue, 5 Nov 2013 08:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89OeXsBk6kpD for ; Tue, 5 Nov 2013 08:00:47 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id EDA0721F9FF3 for ; Tue, 5 Nov 2013 08:00:29 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 8AE2D1A0075 for ; Tue, 5 Nov 2013 17:00:28 +0100 (CET) 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 aVgfxsaUZ-Nl for ; Tue, 5 Nov 2013 17:00:27 +0100 (CET) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 14A8D1A0071 for ; Tue, 5 Nov 2013 17:00:27 +0100 (CET) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Nov 2013 17:00:27 +0100 Message-ID: <5279161A.7080703@secunet.com> Date: Tue, 05 Nov 2013 17:00:26 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: opsawg@ietf.org References: <527915A4.6060900@secunet.com> In-Reply-To: <527915A4.6060900@secunet.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2013 16:00:27.0305 (UTC) FILETIME=[24F3E990:01CEDA40] Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:00:54 -0000 stupid me, I forgot to include the link to the draft: http://www.ietf.org/internet-drafts/draft-hmac-sha-256-128-usm-snmp-00.txt http://tools.ietf.org/html/draft-hmac-sha-256-128-usm-snmp-00 Johannes Johannes Merkle schrieb am 05.11.2013 16:58: > we have published a draft on a new authentication protocol for USM for SNMP. > > Abstract > > This memo specifies a new optional HMAC-SHA-256-128 authentication > protocol for the User-based Security Model (USM) for SNMPv3 defined > in RFC 3414. > > The new protocol is a straightforward adaptation of the protocols HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the > SHA-256 based HMAC with truncation to 128 bits. Comments and suggestions are welcome. > > Is there any interest in adoption by the WG? > From j.schoenwaelder@jacobs-university.de Tue Nov 5 08:13:37 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A4C21E825C for ; Tue, 5 Nov 2013 08:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.181 X-Spam-Level: X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxShzRZNOP+P for ; Tue, 5 Nov 2013 08:13:31 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1744D21E825A for ; Tue, 5 Nov 2013 08:13:27 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 789F120087; Tue, 5 Nov 2013 17:13:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LORAW_QxW_Nu; Tue, 5 Nov 2013 17:13:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 841E220062; Tue, 5 Nov 2013 17:13:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 21519292C50C; Tue, 5 Nov 2013 17:13:20 +0100 (CET) Date: Tue, 5 Nov 2013 17:13:19 +0100 From: Juergen Schoenwaelder To: Johannes Merkle Message-ID: <20131105161319.GA80758@elstar.local> Mail-Followup-To: Johannes Merkle , opsawg@ietf.org, Manfred Lochter , turners@ieca.com References: <527915A4.6060900@secunet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527915A4.6060900@secunet.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Manfred Lochter , opsawg@ietf.org, turners@ieca.com Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 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: Tue, 05 Nov 2013 16:13:37 -0000 On Tue, Nov 05, 2013 at 04:58:28PM +0100, Johannes Merkle wrote: > we have published a draft on a new authentication protocol for USM for SNMP. > > Abstract > > This memo specifies a new optional HMAC-SHA-256-128 authentication > protocol for the User-based Security Model (USM) for SNMPv3 defined > in RFC 3414. > > The new protocol is a straightforward adaptation of the protocols HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the > SHA-256 based HMAC with truncation to 128 bits. Comments and suggestions are welcome. > To allocate an OID, I think you actually have to write a MIB module defining a suitable OBJECT-IDENTITY. This is quite some boilerplate work but provides a formal SMIv2 definition of the OID. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mrm@vmware.com Tue Nov 5 10:03:48 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53421F9EED for ; Tue, 5 Nov 2013 10:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.367 X-Spam-Level: X-Spam-Status: No, score=-9.367 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whqm9jpIxV3e for ; Tue, 5 Nov 2013 10:03:42 -0800 (PST) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAD811E8127 for ; Tue, 5 Nov 2013 10:02:30 -0800 (PST) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 6FCE89853D for ; Tue, 5 Nov 2013 10:02:29 -0800 (PST) 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 5E39CB04ED for ; Tue, 5 Nov 2013 10:02:29 -0800 (PST) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 4E4E5E00F7 for ; Tue, 5 Nov 2013 10:02:29 -0800 (PST) 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 for ; Tue, 5 Nov 2013 10:02:29 -0800 (PST) Date: Tue, 5 Nov 2013 10:02:29 -0800 (PST) From: Michael MacFaden To: opsawg@ietf.org Message-ID: <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> In-Reply-To: <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.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: feedback from operators received on vmm-mib Thread-Index: QRfcZOhnMVU9+OhdPqPYRn/3XmYKXbbVmqrN Subject: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:03:49 -0000 Hi, To add to Jon's request to see 'top' like stats from virtual cpus assigned to a given virtual machine, I worked recently finished collecting feedback for a few US fortune 50 enterprises, here is the compiled the following list of metrics they asked for. I think we already have quite a few covered, but still think some of these should be included in the next draft... Virtual Machine General Metrics MachineName name of VM MachineServer ESX server that hosts this VM MachinePowerStatus power status of the VM MachineUpTime number of seconds since last boot MachineLastUpdate number of heartbeats received from the VM MachineGuestOS fullname of the guest OS MachineGuestIpAddr IP address of the guest MachineCPUNum Number of vCPUs in SYSTEM MachineResourcePool The Resource Pool this VM is a part of MachineLastVMotionTime Shows the last time a VM was vmotion MachineHAEligible Is this Virtual machine protected using Vmware HA MachineCreatedBy Who Created this Virtual Machine MachineCreatedDateTime When was this Virtual Machine Created Virtual Machine Memory MemoryTotalSize memory size of the VM in MB MemoryMaxAlloc amount of memory in MB that the VM can receive MemoryMinAlloc amount of memory in MB guaranteed to the MB MemoryHostUsage consumed host memory in MB MemoryGuestUsage active guest memory in MB MemoryHostUtil host memory used as a percentage of the total VM memory MemoryGuestUtil guest memory used as a percentage of the total VM memory MemorySwapToFile amount of memory being swapped in KB Virtual Machine Processor ProcessorIdleTime CPU time spend in wait state (milliseconds) ProcessorUserTime CPU time spent on user processes (milliseconds) ProcessorSysTime CPU time spent on system processes (milliseconds) ProcessorWaitTime CPU time spent in ready state (milliseconds) ProcessorUtilization user time as a percentage of total CPU time Processor%Ready ready time as a percentage of total cpu time Virtual Machine Disk DiskDescription disk label DiskType type of disk (hard disk, floppy, etc) DiskAccess read/write DiskCapacity capacity of the virtual disk DiskRemovable true/false Virtual Machine Partitions PartitionLabel disk path (c:\, /boot, etc) PartitionCapacity capacity of the disk in bytes PartitionUsedSpace capacity minus freespace PartitionUtilization used as a percentage of capacity Virtual Machine Network Description Network device description PhysAddress physical MAC address Read Count number of packets read Write Count number of packets written Read Rate number of bytes read Write Rate number of bytes written Virtual Machine Processes PID Process ID ProcessName ProcessName ProcessParam ProcessParameters ProcessCPUUsage ProcessCPUUsage ProcessMemoryUsed ProcessMemoryUsage Next step, break these down from what we have and do not. Decide what goes where, not all of course has to go into VMM-MIB, for example reporting the process list of a VM might be best reported via ENTITY-MIB/HOST-RESOURES-MIB via context. Regards, Mike MacFaden Staff Engineer I R&D Apps, VMware Palo Alto CA From saperia@g.harvard.edu Tue Nov 5 10:16:42 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F32311E8297 for ; Tue, 5 Nov 2013 10:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBB7EHrBDDfu for ; Tue, 5 Nov 2013 10:16:34 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 15F2D11E8221 for ; Tue, 5 Nov 2013 10:16:16 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id k18so5021537qcv.10 for ; Tue, 05 Nov 2013 10:16:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=gyhcTLcfYh0lcRE9OnaksdfPcGlARzZ17dL5445x5j4=; b=IgSsG6AqwS3k0wMBaIOwUEYbrqHZ0WFur6e4d+97BH7vBbq2iPvlNatfsncluC6FY1 uoqIFfCPRefDShffSHr3y5OenBrH6tfaV4PyI2T09l5A8naw2y/vQ0AqpQN3FazABJMg +W0RAy9Ln1dUnhJhfPEx/3nzs3+nRpX0N+Saqry4OJSFJbcbbT1LV9462O6GkAmu4K19 bLUwO62buX22FmlsyvFx8n2WloJkIETSpIoHD4cbyZHHx4fdOeKFNkY3Nr0UXb6iY8Wx Pys0AUimnF8XxeXcWlwJzu994lt0/m3ucPq6l2DjOHv0GqYdjnL9t4h5c4Nl84inamNF zekw== X-Gm-Message-State: ALoCoQn8TQhw/4d1HXLTAaY9dYdj4ER0PUvA6iWsfqwWOYo3nhPW0OQ95PrmROjvArBl25cG/AoR X-Received: by 10.229.172.3 with SMTP id j3mr31206304qcz.10.1383675374523; Tue, 05 Nov 2013 10:16:14 -0800 (PST) Received: from dhcp-128-103-65-191.harvard.edu (dhcp-128-103-65-191.harvard.edu. [128.103.65.191]) by mx.google.com with ESMTPSA id h2sm48964415qaf.10.2013.11.05.10.16.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 10:16:13 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E839AB0-AD0D-4A4B-A389-9D5CDA596621" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Saperia Jon In-Reply-To: <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> Date: Tue, 5 Nov 2013 13:16:11 -0500 Message-Id: <378DDD8A-953C-48D2-BCC1-9BDAB190E54A@g.harvard.edu> References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:16:42 -0000 --Apple-Mail=_4E839AB0-AD0D-4A4B-A389-9D5CDA596621 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think Mike's additions are very helpful. I would also like to add a = comment about our approach for the development of the MIB Module. = Implementability is a key consideration for any object that we wish to = make a standard. That said, we should not set as a pre-requisite that = vendors have already implemented an object, or something like it, before = suggesting its addition. The first thing to consider is: will an object = help improve our operational environment? I suspect that is what drove = the responses in the results Mike posted. I got my addition from = talking with folks here at work that run our virtualization environment. The second point is that the suggestion to reporting certain information = via the ENTITY/HOST-RESOURCES ( or I suggest for some items the SYSAPPL = module) is a very good one that should be considered. /jon On Nov 5, 2013, at 1:02 PM, Michael MacFaden wrote: > Hi, >=20 >=20 > To add to Jon's request to see 'top' like stats from virtual cpus = assigned > to a given virtual machine, I worked recently finished collecting = feedback=20 > for a few US fortune 50 enterprises, here is the compiled the = following list of=20 > metrics they asked for. I think we already have quite a few covered, > but still think some of these should be included in the next draft... >=20 > Virtual Machine General Metrics > MachineName name of VM > MachineServer ESX server that hosts this VM > MachinePowerStatus power status of the VM > MachineUpTime number of seconds since last boot > MachineLastUpdate number of heartbeats received from the VM > MachineGuestOS fullname of the guest OS > MachineGuestIpAddr IP address of the guest > MachineCPUNum Number of vCPUs in SYSTEM > MachineResourcePool The Resource Pool this VM is a part of > MachineLastVMotionTime Shows the last time a VM was vmotion > MachineHAEligible Is this Virtual machine protected using = Vmware HA > MachineCreatedBy Who Created this Virtual Machine > MachineCreatedDateTime When was this Virtual Machine Created >=20 > Virtual Machine Memory > MemoryTotalSize memory size of the VM in MB > MemoryMaxAlloc amount of memory in MB that the VM can = receive > MemoryMinAlloc amount of memory in MB guaranteed to the MB > MemoryHostUsage consumed host memory in MB > MemoryGuestUsage active guest memory in MB > MemoryHostUtil host memory used as a percentage of the total = VM memory > MemoryGuestUtil guest memory used as a percentage of the = total VM memory > MemorySwapToFile amount of memory being swapped in KB >=20 > Virtual Machine Processor > ProcessorIdleTime CPU time spend in wait state = (milliseconds) > ProcessorUserTime CPU time spent on user processes = (milliseconds) > ProcessorSysTime CPU time spent on system processes = (milliseconds) > ProcessorWaitTime CPU time spent in ready state = (milliseconds) > ProcessorUtilization user time as a percentage of total CPU = time > Processor%Ready ready time as a percentage of total cpu time >=20 > Virtual Machine Disk > DiskDescription disk label > DiskType type of disk (hard disk, floppy, etc) > DiskAccess read/write > DiskCapacity capacity of the virtual disk > DiskRemovable true/false >=20 > Virtual Machine Partitions > PartitionLabel disk path (c:\, /boot, etc) > PartitionCapacity capacity of the disk in bytes > PartitionUsedSpace capacity minus freespace > PartitionUtilization used as a percentage of capacity >=20 > Virtual Machine Network > Description Network device description > PhysAddress physical MAC address > Read Count number of packets read > Write Count number of packets written > Read Rate number of bytes read > Write Rate number of bytes written >=20 > Virtual Machine Processes > PID Process ID > ProcessName ProcessName > ProcessParam ProcessParameters > ProcessCPUUsage ProcessCPUUsage > ProcessMemoryUsed ProcessMemoryUsage >=20 > Next step, break these down from what we have and do not. > Decide what goes where, not all of course has to go into VMM-MIB, > for example reporting the process list of a VM might be best reported > via ENTITY-MIB/HOST-RESOURES-MIB via context. >=20 > Regards, > Mike MacFaden > Staff Engineer I R&D Apps, VMware Palo Alto CA > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg Thank you=20 /jon Jon Saperia saperia@g.harvard.edu Enterprise Architect Harvard University Information Technology Innovation & Architecture (P) (617) 384-6683 1350 Mass Ave., room 758 Cambridge, MA 02138 --Apple-Mail=_4E839AB0-AD0D-4A4B-A389-9D5CDA596621 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think Mike's additions are very helpful.  I would also like to add = a comment about our approach for the development of the MIB = Module.  Implementability is a key consideration for any = object that we wish to make a standard.  That said, we should not = set as a pre-requisite that vendors have already implemented an object, = or something like it, before suggesting its addition.  The first = thing to consider is: will an object help improve our operational = environment?  I suspect that is what drove the responses in the = results Mike posted.  I got my addition from talking with folks = here at work that run our virtualization = environment.

The second point is that the suggestion = to reporting certain information via the ENTITY/HOST-RESOURCES ( or I = suggest for some items the SYSAPPL module) is a very good one that = should be considered.

/jon
 On Nov = 5, 2013, at 1:02 PM, Michael MacFaden <mrm@vmware.com> = wrote:

Hi,


To add to Jon's request to see 'top' like = stats from virtual cpus assigned
to a given virtual machine, I worked = recently finished collecting feedback
for a few US fortune 50 = enterprises, here is the compiled the following list of
metrics they = asked for. I think we already have quite a few covered,
but still = think some of these should be included in the next = draft...

Virtual Machine General Metrics
=          MachineName =  name of VM
=          MachineServer =  ESX server that hosts this VM
=          MachinePowerStatus =  power status of the VM
=          MachineUpTime =  number of seconds since last boot
=          MachineLastUpdate =  number of heartbeats received from the VM
=          MachineGuestOS =  fullname of the guest OS
=          MachineGuestIpAddr =  IP address of the guest
=          MachineCPUNum =  Number of vCPUs in SYSTEM
=          MachineResourcePool =  The Resource Pool this VM is a part of
=          MachineLastVMotionTi= me Shows the last time a VM was vmotion
=          MachineHAEligible =  Is this Virtual machine protected using Vmware HA
=          MachineCreatedBy =  Who Created this Virtual Machine
=          MachineCreatedDateTi= me When was this Virtual Machine Created

Virtual Machine = Memory
=          MemoryTotalSize =  memory size of the VM in MB
=          MemoryMaxAlloc =  amount of memory in MB that the VM can receive
=          MemoryMinAlloc =  amount of memory in MB guaranteed to the MB
=          MemoryHostUsage =  consumed host memory in MB
=          MemoryGuestUsage =  active guest memory in MB
=          MemoryHostUtil =  host memory used as a percentage of the total VM memory
=          MemoryGuestUtil =  guest memory used as a percentage of the total VM memory
=          MemorySwapToFile =  amount of memory being swapped in KB

Virtual Machine = Processor
=          ProcessorIdleTime =  CPU time spend in wait state (milliseconds)
=          ProcessorUserTime =  CPU time spent on user processes (milliseconds)
=          ProcessorSysTime =  CPU time spent on system processes (milliseconds)
=          ProcessorWaitTime =  CPU time spent in ready state (milliseconds)
=          ProcessorUtilization=  user time as a percentage of total CPU time
=          Processor%Ready =  ready time as a percentage of total cpu time

Virtual = Machine Disk
=          DiskDescription =  disk label
=          DiskType =  type of disk (hard disk, floppy, etc)
=          DiskAccess =  read/write
=          DiskCapacity =  capacity of the virtual disk
=          DiskRemovable =  true/false

Virtual Machine Partitions
=          PartitionLabel =  disk path (c:\, /boot, etc)
=          PartitionCapacity =  capacity of the disk in bytes
=          PartitionUsedSpace =  capacity minus freespace
=          PartitionUtilization=  used as a percentage of capacity

Virtual Machine = Network
=          Description =  Network device description
=          PhysAddress =  physical MAC address
=          Read Count =  number of packets read
=          Write Count =  number of packets written
=          Read Rate =  number of bytes read
=          Write Rate =  number of bytes written

Virtual Machine Processes
=          PID  Process = ID
         ProcessName =  ProcessName
=          ProcessParam =  ProcessParameters
=          ProcessCPUUsage =  ProcessCPUUsage
=          ProcessMemoryUsed = ProcessMemoryUsage

Next step, break these down from what we have = and do not.
Decide what goes where, not all of course has to go into = VMM-MIB,
for example reporting the process list of a VM might be best = reported
via ENTITY-MIB/HOST-RESOURES-MIB via = context.

Regards,
Mike MacFaden
Staff Engineer I R&D = Apps, VMware Palo Alto = CA
_______________________________________________
OPSAWG mailing = list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

Thank you 
/jon
Jon = Saperia
Harvard University Information Technology
 (617) = 384-6683
1350 = Mass Ave., room 758

= --Apple-Mail=_4E839AB0-AD0D-4A4B-A389-9D5CDA596621-- From maxpassion@gmail.com Tue Nov 5 10:52:13 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355D521F969F for ; Tue, 5 Nov 2013 10:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k5hS4QmAZwH for ; Tue, 5 Nov 2013 10:52:12 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E109311E821C for ; Tue, 5 Nov 2013 10:50:29 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so2826046veb.33 for ; Tue, 05 Nov 2013 10:50:06 -0800 (PST) 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=wvMYgsZ4Yg7zmIPSkSakrAO4hrCirKtp0mNK77qFIjs=; b=AzgXf2pQMb0QD/zQERX/S1cf24oLo0ZLPxtuljtQYCVTQjg3lRHXibCxw9EJasfJlj JtdIvUnP9iNoxZ/oZvCABuDYnGYIWo/LEFf25jSjLFkv9kg97ooHWcJbnWFOSeAVSkwi S6bZA3m87Ky5qC0xzDK+1oKH6Ci3biYVc79bT8ccGWxSwG0VWbvtJYAm/CkCl4/58AY/ ctYWw8K5dcIFCIGSAP632fAwXOs1IQB6meHFbJUleqXdolVpEz2ncnh/Llkr/fP3SqsR xlO9gNJ94yJ01dd0K+XMT8mnyluccXciZkqjFKFXhtC8QL5h5/MPd/V4ianVc3RKyv/T rmQg== MIME-Version: 1.0 X-Received: by 10.52.166.200 with SMTP id zi8mr775122vdb.38.1383677406813; Tue, 05 Nov 2013 10:50:06 -0800 (PST) Received: by 10.220.220.69 with HTTP; Tue, 5 Nov 2013 10:50:06 -0800 (PST) In-Reply-To: <5278CE55.7000003@gmail.com> References: <9904FB1B0159DA42B0B887B7FA8119CA1291CAE4@AZ-FFEXMB04.global.avaya.com> <9904FB1B0159DA42B0B887B7FA8119CA1292A5AD@AZ-FFEXMB04.global.avaya.com> <5278CE55.7000003@gmail.com> Date: Tue, 5 Nov 2013 10:50:06 -0800 Message-ID: From: Liu Dapeng To: Tom Taylor Content-Type: multipart/alternative; boundary=089e01634aa651265f04ea728021 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] review of draft-ietf-opsawg-capwap-extension-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:52:13 -0000 --089e01634aa651265f04ea728021 Content-Type: text/plain; charset=ISO-8859-1 2013/11/5 Tom Taylor > I'm doing the editorial review I promised, but I'm having a little problem > with Section 4.1 (which may also apply to other sections as I move > forward). Section 4.1 says at first that it is defining a new 802.11n Radio > Capability information element. Then at the end of the paragraph, it says > it is defining a new 802.11n Radio Capability message element. > > I don't believe it is doing either one. Instead, it should simply say that > this document specifies use of the IEEE 802.11 Information Element to > transport the IEEE 802.11 HT information element. > > Does this sound reasonable? Yes. Thanks. Dapeng Liu > > > Tom > > > On 04/11/2013 1:22 PM, Liu Dapeng wrote: > >> Hi Dan, >> >> Thank you for your kind review and valuable comments. We will address all >> your comments in the next version and will improve the writing as well. >> Tom Taylor has volunteered to do the editorial review and that would be >> very helpful to improve the quality of the draft. Many thanks to Tom. >> >> ... > -- ------ Best Regards, Dapeng Liu --089e01634aa651265f04ea728021 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2013/11/5 Tom Taylor <tom.taylor.stds@gmail.com>
I'm doing the editorial review I promised, but I'm having a little = problem with Section 4.1 (which may also apply to other sections as I move = forward). Section 4.1 says at first that it is defining a new 802.11n Radio= Capability information element. Then at the end of the paragraph, it says = it is defining a new 802.11n Radio Capability message element.

I don't believe it is doing either one. Instead, it should simply say t= hat this document specifies use of the IEEE 802.11 Information Element to t= ransport the IEEE 802.11 HT information element.

Does this sound reasonable?

Yes. Thanks.

Dapeng Liu=A0


Tom


On 04/11/2013 1:22 PM, Liu Dapeng wrote:
Hi Dan,

Thank you for your kind review and valuable comments. We will address all your comments in the next version and will improve the writing as well.
=A0 =A0Tom Taylor has volunteered to do the editorial review and that would= be
very helpful to improve the quality of the draft. Many thanks to Tom.

...



--

------Best Regards,
Dapeng Liu
--089e01634aa651265f04ea728021-- From panda@hongo.wide.ad.jp Tue Nov 5 10:52:21 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B0421F969F for ; Tue, 5 Nov 2013 10:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.648 X-Spam-Level: * X-Spam-Status: No, score=1.648 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJXejjAfD+Pa for ; Tue, 5 Nov 2013 10:52:17 -0800 (PST) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id E0B7E11E823E for ; Tue, 5 Nov 2013 10:50:33 -0800 (PST) Received: from wireless-a-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:176:e5ca:308a:7ba:77d5]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 75181108E583; Wed, 6 Nov 2013 03:50:24 +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: <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> Date: Tue, 5 Nov 2013 10:50:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 18:52:21 -0000 Dear Mike, Thank you for sharing the feedbacks from operators. I think some of = them are already defined in the current version, and some of the rest shall be = good to be defined in the next version. I will review these objects comparing the = current version of our proposal. At this moment, I don't understand some of them, so could you please = explain them? > Virtual Machine Processor > ProcessorUserTime CPU time spent on user processes = (milliseconds) > ProcessorSysTime CPU time spent on system processes = (milliseconds) What's the difference between these two time metrics? Are they user-time and system-time at a guest OS? > Virtual Machine Processes > PID Process ID > ProcessName ProcessName > ProcessParam ProcessParameters > ProcessCPUUsage ProcessCPUUsage > ProcessMemoryUsed ProcessMemoryUsage Do you mean they are processes on a guest OS? If the objects above are those of a guest OS, they need a special tool = such as vmware tools installed to the guest OS. So, MIB modules on guest OSes, = such as HOST-RESOURCES-MIB, could be used. The following objects are also related to guest OSes. > Virtual Machine Partitions > PartitionLabel disk path (c:\, /boot, etc) > PartitionCapacity capacity of the disk in bytes > PartitionUsedSpace capacity minus freespace > PartitionUtilization used as a percentage of capacity Some of them might be recognizable from hypervisor. The partition = format itself does not vary by guest OS (i.e., MBR or GPT partition), so some = of these might be able to available from hypervisor. However, I still don't = think VM-MIB is the appropriate place to contain these objects, and it is better to = use MIB modules on guest OS (e.g., HOST-RESOURCES-MIB). Moreover, PartitionLabel, PartitionUsedSpace, and PartitionUtilization are = information on file system, then a hypervisor cannot recognize them without any = special tools such as vmware tools. Thank you. Hirochika On Nov 5, 2013, at 10:02 AM, Michael MacFaden wrote: > Hi, >=20 >=20 > To add to Jon's request to see 'top' like stats from virtual cpus = assigned > to a given virtual machine, I worked recently finished collecting = feedback=20 > for a few US fortune 50 enterprises, here is the compiled the = following list of=20 > metrics they asked for. I think we already have quite a few covered, > but still think some of these should be included in the next draft... >=20 > Virtual Machine General Metrics > MachineName name of VM > MachineServer ESX server that hosts this VM > MachinePowerStatus power status of the VM > MachineUpTime number of seconds since last boot > MachineLastUpdate number of heartbeats received from the VM > MachineGuestOS fullname of the guest OS > MachineGuestIpAddr IP address of the guest > MachineCPUNum Number of vCPUs in SYSTEM > MachineResourcePool The Resource Pool this VM is a part of > MachineLastVMotionTime Shows the last time a VM was vmotion > MachineHAEligible Is this Virtual machine protected using = Vmware HA > MachineCreatedBy Who Created this Virtual Machine > MachineCreatedDateTime When was this Virtual Machine Created >=20 > Virtual Machine Memory > MemoryTotalSize memory size of the VM in MB > MemoryMaxAlloc amount of memory in MB that the VM can = receive > MemoryMinAlloc amount of memory in MB guaranteed to the MB > MemoryHostUsage consumed host memory in MB > MemoryGuestUsage active guest memory in MB > MemoryHostUtil host memory used as a percentage of the total = VM memory > MemoryGuestUtil guest memory used as a percentage of the = total VM memory > MemorySwapToFile amount of memory being swapped in KB >=20 > Virtual Machine Processor > ProcessorIdleTime CPU time spend in wait state = (milliseconds) > ProcessorUserTime CPU time spent on user processes = (milliseconds) > ProcessorSysTime CPU time spent on system processes = (milliseconds) > ProcessorWaitTime CPU time spent in ready state = (milliseconds) > ProcessorUtilization user time as a percentage of total CPU = time > Processor%Ready ready time as a percentage of total cpu time >=20 > Virtual Machine Disk > DiskDescription disk label > DiskType type of disk (hard disk, floppy, etc) > DiskAccess read/write > DiskCapacity capacity of the virtual disk > DiskRemovable true/false >=20 > Virtual Machine Partitions > PartitionLabel disk path (c:\, /boot, etc) > PartitionCapacity capacity of the disk in bytes > PartitionUsedSpace capacity minus freespace > PartitionUtilization used as a percentage of capacity >=20 > Virtual Machine Network > Description Network device description > PhysAddress physical MAC address > Read Count number of packets read > Write Count number of packets written > Read Rate number of bytes read > Write Rate number of bytes written >=20 > Virtual Machine Processes > PID Process ID > ProcessName ProcessName > ProcessParam ProcessParameters > ProcessCPUUsage ProcessCPUUsage > ProcessMemoryUsed ProcessMemoryUsage >=20 > Next step, break these down from what we have and do not. > Decide what goes where, not all of course has to go into VMM-MIB, > for example reporting the process list of a VM might be best reported > via ENTITY-MIB/HOST-RESOURES-MIB via context. >=20 > Regards, > Mike MacFaden > Staff Engineer I R&D Apps, VMware Palo Alto CA > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --=20 Hirochika Asai , The University of Tokyo From dthaler@microsoft.com Mon Nov 4 20:53:49 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF321E80B1 for ; Mon, 4 Nov 2013 20:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.624 X-Spam-Level: X-Spam-Status: No, score=-103.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g96DMj9XxLzZ for ; Mon, 4 Nov 2013 20:53:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0150.outbound.protection.outlook.com [207.46.163.150]) by ietfa.amsl.com (Postfix) with ESMTP id 479F521E80E1 for ; Mon, 4 Nov 2013 20:53:41 -0800 (PST) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB271.namprd03.prod.outlook.com (10.242.37.14) with Microsoft SMTP Server (TLS) id 15.0.815.6; Tue, 5 Nov 2013 04:53:33 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.185]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.185]) with mapi id 15.00.0815.000; Tue, 5 Nov 2013 04:53:33 +0000 From: Dave Thaler To: "George, Wes" , Benoit Claise , "opsawg@ietf.org" Thread-Topic: [OPSAWG] OPS guidance to the non-OPS community Thread-Index: AQHO1lt99VdLeR+HLEibYTHfa3dCHJoUI0EAgAH0UJA= Date: Tue, 5 Nov 2013 04:53:32 +0000 Message-ID: References: <52728DF5.2070701@cisco.com> <2671C6CDFBB59E47B64C10B3E0BD5923043DEB1773@PRVPEXVS15.corp.twcable.com> In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD5923043DEB1773@PRVPEXVS15.corp.twcable.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:144:e4b2:e26c:88c8:ce2a] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(51704005)(377454003)(13464003)(189002)(199002)(46102001)(51856001)(79102001)(49866001)(4396001)(53806001)(47736001)(50986001)(561944002)(47976001)(54356001)(77096001)(56816003)(81542001)(59766001)(77982001)(74366001)(81342001)(76576001)(63696002)(69226001)(56776001)(54316002)(2656002)(74316001)(31966008)(81816001)(74662001)(87266001)(65816001)(80022001)(81686001)(33646001)(83072001)(80976001)(76482001)(74502001)(47446002)(74706001)(19580395003)(19580405001)(76786001)(76796001)(83322001)(74876001)(85306002)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB271; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:67c:370:144:e4b2:e26c:88c8:ce2a; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Tue, 05 Nov 2013 11:27:11 -0800 Subject: Re: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 04:53:50 -0000 As a WG chair, I would find "management" guidance extremely useful. Outside of the OPS area, my WGs do protocols. But of course people want to do management, monitoring, logging, etc. of those protocols. So we get proposals to do logging with IPFIX, Syslog, etc.=20 And we get proposals to do management with Netconf, SNMP, etc (and if you extend "management" to include all types of configuration that would include DHCP and Router Advertisements in that list too). And we get RADIUS, etc proposals. People in other WGs are experts on their own protocol, rather than on the protocols for all the other aspects mentioned above, and any guidance is not only appreciated, it is needed. How should non-OPS WGs evaluate which ones they need, or do we just arbitrarily adopt specific proposals just because no one proposed=20 alternatives? Thanks Benoit for starting this discussion, -Dave > -----Original Message----- > From: George, Wes [mailto:wesley.george@twcable.com] > Sent: Sunday, November 3, 2013 2:57 PM > To: Benoit Claise; opsawg@ietf.org > Cc: Dave Thaler; Joel jaeggli (joelja@bogus.com) > Subject: RE: [OPSAWG] OPS guidance to the non-OPS community >=20 > Benoit - >=20 > I think there's a more basic question. What is "ops" in this context and = how > do we as the IETF or OPSArea expect to represent it to "non-ops"? What's > the desired outcome and audience - just to give those working within othe= r > areas of the IETF better guidance on tools? That sounds more like the > operative word is "tools" or "management" not ops. >=20 > If you are instead referring to broader operational feedback outside of I= ETF, > that asks a second question - is IETF still the right venue for this? Do = we have > the credibility and experience? There are other initiatives aimed at prov= iding > feedback from operations (BCOP, the *NOG community, Deploy 360, etc) > that have better operator participation than IETF, so I'd be hesitant to > reinvent the wheel here. > If the main goal is to update guidance more consistently and frequently > based on what tools are in common use, you'd get better results from > surveying a much wider community periodically - e.g. publishing a survey = on > *NOG lists, and using that to inform your results. >=20 > Your other fundamental question seems to be - how do we make IETF > recommendations, discussions of pros/cons for different tools and solutio= ns, > etc more accessible for those who don't really fancy reading RFCs? Most o= f > your examples seem to indicate that we'd be better with some sort of > system that pulls the relevant info out of multiple RFCs and presents the= m in > one place based on the subject, rather than expecting people to find the > relevant document(s) and then follow a chain of document, updated > document, updated updated document, obsoleted section, erratum, etc to > synthesize the actual current recommendation from all of the pieces. It's= a > real issue, but one much larger than OpsArea. >=20 > Wes George >=20 >=20 > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On > > Behalf Of Benoit Claise > > Sent: Thursday, October 31, 2013 1:06 PM > > To: opsawg@ietf.org > > Cc: Dave Thaler > > Subject: [OPSAWG] OPS guidance to the non-OPS community > > > > Dear all, > > > > During the OPSAWG/OPSAREA meeting, I will be addressing one issue that > > is now on the top of my mind: OPS guidance to the non-OPS community. > > > > Problem 1: > > How do we share our OPS knowledge? How do we advice which OPS tools > > (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should > > be using? > > > > On regular basis, I have to provide these advice How can we share this > > knowledge? > > This is the perfect job for an OPS advisor, but one OPS advisor in all > > WGs doesn't scale. > > > > Problem 2: > > What are the OPS recommendations for future developments? > > It might appear as the same problem as 1, but the audience is different= . > > Here, we speak about new charters for example. >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely = for > the use of the individual or entity to which it is addressed. If you are = not the > intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may= be > unlawful. If you have received this E-mail in error, please notify the se= nder > immediately and permanently delete the original and any copy of this E-ma= il > and any printout. From saperia@g.harvard.edu Tue Nov 5 11:55:51 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9921E80C4 for ; Tue, 5 Nov 2013 11:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPUOWSDBu+5n for ; Tue, 5 Nov 2013 11:55:46 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 861FE21E805F for ; Tue, 5 Nov 2013 11:55:44 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id k4so1357286qaq.0 for ; Tue, 05 Nov 2013 11:55:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=q8LbVouYGHHj07bpTuGGpUkRRqyY7//gYZwGV2EcdW4=; b=j6QTLbaVrmrPaXDizx3DvAgWTyRDDfE3D3LKTh/on//DGeG4XEu+XTYUW7xK7Tk3Dd JOOYvj1BbObn807wdxRFYtcX/FTWG6YedgwteEKwBY0uPYk4K0y0AP/QWJROsDGTdhH5 YyKnU2o120IUDbzgKykva46dCzTNwCcZhRe7VDBXDARz7hwjB6rt4nRwVfNCOunjlFX+ 1II+oB8pZuJ+mYjJMn7x/hxcyuHu3a/kLiia0bQ0MTyOyyH4t+q0m73o1os6OlHAk4oY I3a4FWX3nlXZ9+N793jEbfYATc5VM+fQ4Z5fmkHgcvfSsVdZOkep/L9jfFxX5C2Rui4m 4gSw== X-Gm-Message-State: ALoCoQl6crVXT9MVAl0sBmlE7YurArY/l+EsECZCpK8OXM2EGAJtiJRgkW51r1KzrZYCqJVg6t3B X-Received: by 10.49.71.131 with SMTP id v3mr12615154qeu.85.1383681342469; Tue, 05 Nov 2013 11:55:42 -0800 (PST) Received: from [192.168.2.254] (pool-72-93-30-40.bstnma.east.verizon.net. [72.93.30.40]) by mx.google.com with ESMTPSA id v19sm70660295qaw.0.2013.11.05.11.55.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 11:55:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_782C9BA0-D850-443A-942C-FC32F10DF3DE" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Saperia Jon In-Reply-To: Date: Tue, 5 Nov 2013 14:55:35 -0500 Message-Id: <8720F4E7-9F98-43E8-B0A8-04ACEF2D782D@g.harvard.edu> References: <52728DF5.2070701@cisco.com> <2671C6CDFBB59E47B64C10B3E0BD5923043DEB1773@PRVPEXVS15.corp.twcable.com> To: Dave Thaler X-Mailer: Apple Mail (2.1510) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 19:55:51 -0000 --Apple-Mail=_782C9BA0-D850-443A-942C-FC32F10DF3DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FWIW, the challenges in management are not related to protocols, we have = too many as it is. It is good for groups to have focus, and if this = group has its focus on protocols, that is fine. Another protocol will = only make things more difficult for operational people and likely add = cost to the products we buy. /jon On Nov 4, 2013, at 11:53 PM, Dave Thaler wrote: > As a WG chair, I would find "management" guidance extremely useful. > Outside of the OPS area, my WGs do protocols. But of course people > want to do management, monitoring, logging, etc. of those protocols. >=20 > So we get proposals to do logging with IPFIX, Syslog, etc.=20 > And we get proposals to do management with Netconf, SNMP, etc > (and if you extend "management" to include all types of configuration > that would include DHCP and Router Advertisements in that list too). > And we get RADIUS, etc proposals. >=20 > People in other WGs are experts on their own protocol, rather than > on the protocols for all the other aspects mentioned above, and > any guidance is not only appreciated, it is needed. >=20 > How should non-OPS WGs evaluate which ones they need, or do > we just arbitrarily adopt specific proposals just because no one = proposed=20 > alternatives? >=20 > Thanks Benoit for starting this discussion, > -Dave >=20 >> -----Original Message----- >> From: George, Wes [mailto:wesley.george@twcable.com] >> Sent: Sunday, November 3, 2013 2:57 PM >> To: Benoit Claise; opsawg@ietf.org >> Cc: Dave Thaler; Joel jaeggli (joelja@bogus.com) >> Subject: RE: [OPSAWG] OPS guidance to the non-OPS community >>=20 >> Benoit - >>=20 >> I think there's a more basic question. What is "ops" in this context = and how >> do we as the IETF or OPSArea expect to represent it to "non-ops"? = What's >> the desired outcome and audience - just to give those working within = other >> areas of the IETF better guidance on tools? That sounds more like the >> operative word is "tools" or "management" not ops. >>=20 >> If you are instead referring to broader operational feedback outside = of IETF, >> that asks a second question - is IETF still the right venue for this? = Do we have >> the credibility and experience? There are other initiatives aimed at = providing >> feedback from operations (BCOP, the *NOG community, Deploy 360, etc) >> that have better operator participation than IETF, so I'd be hesitant = to >> reinvent the wheel here. >> If the main goal is to update guidance more consistently and = frequently >> based on what tools are in common use, you'd get better results from >> surveying a much wider community periodically - e.g. publishing a = survey on >> *NOG lists, and using that to inform your results. >>=20 >> Your other fundamental question seems to be - how do we make IETF >> recommendations, discussions of pros/cons for different tools and = solutions, >> etc more accessible for those who don't really fancy reading RFCs? = Most of >> your examples seem to indicate that we'd be better with some sort of >> system that pulls the relevant info out of multiple RFCs and presents = them in >> one place based on the subject, rather than expecting people to find = the >> relevant document(s) and then follow a chain of document, updated >> document, updated updated document, obsoleted section, erratum, etc = to >> synthesize the actual current recommendation from all of the pieces. = It's a >> real issue, but one much larger than OpsArea. >>=20 >> Wes George >>=20 >>=20 >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On >>> Behalf Of Benoit Claise >>> Sent: Thursday, October 31, 2013 1:06 PM >>> To: opsawg@ietf.org >>> Cc: Dave Thaler >>> Subject: [OPSAWG] OPS guidance to the non-OPS community >>>=20 >>> Dear all, >>>=20 >>> During the OPSAWG/OPSAREA meeting, I will be addressing one issue = that >>> is now on the top of my mind: OPS guidance to the non-OPS community. >>>=20 >>> Problem 1: >>> How do we share our OPS knowledge? How do we advice which OPS tools >>> (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community = should >>> be using? >>>=20 >>> On regular basis, I have to provide these advice How can we share = this >>> knowledge? >>> This is the perfect job for an OPS advisor, but one OPS advisor in = all >>> WGs doesn't scale. >>>=20 >>> Problem 2: >>> What are the OPS recommendations for future developments? >>> It might appear as the same problem as 1, but the audience is = different. >>> Here, we speak about new charters for example. >>=20 >>=20 >> This E-mail and any of its attachments may contain Time Warner Cable >> proprietary information, which is privileged, confidential, or = subject to >> copyright belonging to Time Warner Cable. This E-mail is intended = solely for >> the use of the individual or entity to which it is addressed. If you = are not the >> intended recipient of this E-mail, you are hereby notified that any >> dissemination, distribution, copying, or action taken in relation to = the >> contents of and attachments to this E-mail is strictly prohibited and = may be >> unlawful. If you have received this E-mail in error, please notify = the sender >> immediately and permanently delete the original and any copy of this = E-mail >> and any printout. > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg Thank you=20 /jon Jon Saperia saperia@g.harvard.edu Enterprise Architect Harvard University Information Technology Innovation & Architecture (P) (617) 384-6683 1350 Mass Ave., room 758 Cambridge, MA 02138 --Apple-Mail=_782C9BA0-D850-443A-942C-FC32F10DF3DE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FWIW, = the challenges in management are not related to protocols, we have too = many as it is.  It is good for groups to have focus, and if this = group has its focus on protocols, that is fine.  Another protocol = will only make things more difficult for operational people and likely = add cost to the products we buy.

/jon
On = Nov 4, 2013, at 11:53 PM, Dave Thaler <dthaler@microsoft.com> = wrote:

As a WG chair, I would find "management" guidance = extremely useful.
Outside of the OPS area, my WGs do protocols. =  But of course people
want to do management, monitoring, = logging, etc. of those protocols.

So we get proposals to do = logging with IPFIX, Syslog, etc.
And we get proposals to do = management with Netconf, SNMP, etc
(and if you extend "management" to = include all types of configuration
that would include DHCP and Router = Advertisements in that list too).
And we get RADIUS, etc = proposals.

People in other WGs are experts on their own protocol, = rather than
on the protocols for all the other aspects mentioned = above, and
any guidance is not only appreciated, it is = needed.

How should non-OPS WGs evaluate which ones they need, or = do
we just arbitrarily adopt specific proposals just because no one = proposed
alternatives?

Thanks Benoit for starting this = discussion,
-Dave

-----Original = Message-----
From: George, Wes [mailto:wesley.george@twcable.com]
Sent: Sunday, November = 3, 2013 2:57 PM
To: Benoit Claise; opsawg@ietf.org
Cc: Dave Thaler; = Joel jaeggli (joelja@bogus.com)
Subject: RE: = [OPSAWG] OPS guidance to the non-OPS community

Benoit -

I = think there's a more basic question. What is "ops" in this context and = how
do we as the IETF or OPSArea expect to represent it to "non-ops"? = What's
the desired outcome and audience - just to give those working = within other
areas of the IETF better guidance on tools? That sounds = more like the
operative word is "tools" or "management" not = ops.

If you are instead referring to broader operational feedback = outside of IETF,
that asks a second question - is IETF still the = right venue for this? Do we have
the credibility and experience? = There are other initiatives aimed at providing
feedback from = operations (BCOP, the *NOG community, Deploy 360, etc)
that have = better operator participation than IETF, so I'd be hesitant = to
reinvent the wheel here.
If the main goal is to update guidance = more consistently and frequently
based on what tools are in common = use, you'd get better results from
surveying a much wider community = periodically - e.g. publishing a survey on
*NOG lists, and using that = to inform your results.

Your other fundamental question seems to = be - how do we make IETF
recommendations, discussions of pros/cons = for different tools and solutions,
etc more accessible for those who = don't really fancy reading RFCs? Most of
your examples seem to = indicate that we'd be better with some sort of
system that pulls the = relevant info out of multiple RFCs and presents them in
one place = based on the subject, rather than expecting people to find = the
relevant document(s) and then follow a chain of document, = updated
document, updated updated document, obsoleted section, = erratum, etc to
synthesize the actual current recommendation from all = of the pieces. It's a
real issue, but one much larger than = OpsArea.

Wes George


-----Original Message-----
From: opsawg-bounces@ietf.org = [mailto:opsawg-bounces@ietf.org] = On
Behalf Of Benoit Claise
Sent: Thursday, October 31, 2013 1:06 = PM
To: opsawg@ietf.org
Cc: = Dave Thaler
Subject: [OPSAWG] OPS guidance to the non-OPS = community

Dear all,

During the OPSAWG/OPSAREA meeting, I = will be addressing one issue that
is now on the top of my mind: OPS = guidance to the non-OPS community.

Problem 1:
How do we share = our OPS knowledge? How do we advice which OPS tools
(NETCONF, SNMP, = AAA, ping, syslog, IPFIX, etc...) the community should
be = using?

On regular basis, I have to provide these advice How can = we share this
knowledge?
This is the perfect job for an OPS = advisor, but one OPS advisor in all
WGs doesn't scale.

Problem = 2:
What are the OPS recommendations for future developments?
It = might appear as the same problem as 1, but the audience is = different.
Here, we speak about new charters for = example.


This E-mail and any of its attachments = may contain Time Warner Cable
proprietary information, which is = privileged, confidential, or subject to
copyright belonging to Time = Warner Cable. This E-mail is intended solely for
the use of the = individual or entity to which it is addressed. If you are not = the
intended recipient of this E-mail, you are hereby notified that = any
dissemination, distribution, copying, or action taken in relation = to the
contents of and attachments to this E-mail is strictly = prohibited and may be
unlawful. If you have received this E-mail in = error, please notify the sender
immediately and permanently delete = the original and any copy of this E-mail
and any = printout.
_______________________________________________<= br>OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

Thank you 
/jon
Jon = Saperia
Harvard University Information Technology
 (617) = 384-6683
1350 = Mass Ave., room 758

= --Apple-Mail=_782C9BA0-D850-443A-942C-FC32F10DF3DE-- From dthaler@microsoft.com Tue Nov 5 12:37:09 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F169021E8085 for ; Tue, 5 Nov 2013 12:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.623 X-Spam-Level: X-Spam-Status: No, score=-103.623 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7rAdb1nh0xy for ; Tue, 5 Nov 2013 12:37:04 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4D421E80B0 for ; Tue, 5 Nov 2013 12:36:29 -0800 (PST) Received: from BY2PR03MB269.namprd03.prod.outlook.com (10.242.37.11) by BY2PR03MB270.namprd03.prod.outlook.com (10.242.37.12) with Microsoft SMTP Server (TLS) id 15.0.815.6; Tue, 5 Nov 2013 20:36:27 +0000 Received: from BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.185]) by BY2PR03MB269.namprd03.prod.outlook.com ([169.254.5.185]) with mapi id 15.00.0815.000; Tue, 5 Nov 2013 20:36:26 +0000 From: Dave Thaler To: Saperia Jon Thread-Topic: [OPSAWG] OPS guidance to the non-OPS community Thread-Index: AQHO1lt99VdLeR+HLEibYTHfa3dCHJoUI0EAgAH0UJCAAP2zgIAACvsg Date: Tue, 5 Nov 2013 20:36:25 +0000 Message-ID: References: <52728DF5.2070701@cisco.com> <2671C6CDFBB59E47B64C10B3E0BD5923043DEB1773@PRVPEXVS15.corp.twcable.com> <8720F4E7-9F98-43E8-B0A8-04ACEF2D782D@g.harvard.edu> In-Reply-To: <8720F4E7-9F98-43E8-B0A8-04ACEF2D782D@g.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:160:adae:2c73:f5c0:4da1] x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(24454002)(189002)(199002)(13464003)(81816001)(74366001)(83322001)(16601075003)(77982001)(76576001)(59766001)(80976001)(79102001)(80022001)(83072001)(65816001)(561944002)(19580405001)(77096001)(19580395003)(56816003)(81686001)(76482001)(76786001)(76796001)(63696002)(46102001)(74876001)(51856001)(47976001)(74706001)(50986001)(56776001)(4396001)(47736001)(49866001)(54316002)(81342001)(81542001)(69226001)(2656002)(85306002)(33646001)(16236675002)(19609705001)(15202345003)(87266001)(74502001)(47446002)(74662001)(74316001)(31966008)(19300405004)(53806001)(15975445006)(54356001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB270; H:BY2PR03MB269.namprd03.prod.outlook.com; CLIP:2001:67c:370:160:adae:2c73:f5c0:4da1; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_d8e4fabc63ea4ba3b799513789c5762bBY2PR03MB269namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] OPS guidance to the non-OPS community X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 20:37:09 -0000 --_000_d8e4fabc63ea4ba3b799513789c5762bBY2PR03MB269namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree we have too many protocols as is, and that's part of the problem... t= oo much choice causes confusion. As the IETF has added protocols (and hence choices), confusion = has increased. The IETF hasn't sufficiently compensated enough by providing (enough) guida= nce to reduce that confusion. -Dave (as chair of 2 groups that have had to deal with that confusion) From: Saperia Jon [mailto:saperia@g.harvard.edu] Sent: Tuesday, November 5, 2013 11:56 AM To: Dave Thaler Cc: George, Wes; Benoit Claise; opsawg@ietf.org Subject: Re: [OPSAWG] OPS guidance to the non-OPS community FWIW, the challenges in management are not related to protocols, we have to= o many as it is. It is good for groups to have focus, and if this group ha= s its focus on protocols, that is fine. Another protocol will only make th= ings more difficult for operational people and likely add cost to the produ= cts we buy. /jon On Nov 4, 2013, at 11:53 PM, Dave Thaler > wrote: As a WG chair, I would find "management" guidance extremely useful. Outside of the OPS area, my WGs do protocols. But of course people want to do management, monitoring, logging, etc. of those protocols. So we get proposals to do logging with IPFIX, Syslog, etc. And we get proposals to do management with Netconf, SNMP, etc (and if you extend "management" to include all types of configuration that would include DHCP and Router Advertisements in that list too). And we get RADIUS, etc proposals. People in other WGs are experts on their own protocol, rather than on the protocols for all the other aspects mentioned above, and any guidance is not only appreciated, it is needed. How should non-OPS WGs evaluate which ones they need, or do we just arbitrarily adopt specific proposals just because no one proposed alternatives? Thanks Benoit for starting this discussion, -Dave -----Original Message----- From: George, Wes [mailto:wesley.george@twcable.com] Sent: Sunday, November 3, 2013 2:57 PM To: Benoit Claise; opsawg@ietf.org Cc: Dave Thaler; Joel jaeggli (joelja@bogus.com) Subject: RE: [OPSAWG] OPS guidance to the non-OPS community Benoit - I think there's a more basic question. What is "ops" in this context and ho= w do we as the IETF or OPSArea expect to represent it to "non-ops"? What's the desired outcome and audience - just to give those working within other areas of the IETF better guidance on tools? That sounds more like the operative word is "tools" or "management" not ops. If you are instead referring to broader operational feedback outside of IET= F, that asks a second question - is IETF still the right venue for this? Do we= have the credibility and experience? There are other initiatives aimed at provid= ing feedback from operations (BCOP, the *NOG community, Deploy 360, etc) that have better operator participation than IETF, so I'd be hesitant to reinvent the wheel here. If the main goal is to update guidance more consistently and frequently based on what tools are in common use, you'd get better results from surveying a much wider community periodically - e.g. publishing a survey on *NOG lists, and using that to inform your results. Your other fundamental question seems to be - how do we make IETF recommendations, discussions of pros/cons for different tools and solutions= , etc more accessible for those who don't really fancy reading RFCs? Most of your examples seem to indicate that we'd be better with some sort of system that pulls the relevant info out of multiple RFCs and presents them = in one place based on the subject, rather than expecting people to find the relevant document(s) and then follow a chain of document, updated document, updated updated document, obsoleted section, erratum, etc to synthesize the actual current recommendation from all of the pieces. It's a real issue, but one much larger than OpsArea. Wes George -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsaw= g-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Thursday, October 31, 2013 1:06 PM To: opsawg@ietf.org Cc: Dave Thaler Subject: [OPSAWG] OPS guidance to the non-OPS community Dear all, During the OPSAWG/OPSAREA meeting, I will be addressing one issue that is now on the top of my mind: OPS guidance to the non-OPS community. Problem 1: How do we share our OPS knowledge? How do we advice which OPS tools (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should be using? On regular basis, I have to provide these advice How can we share this knowledge? This is the perfect job for an OPS advisor, but one OPS advisor in all WGs doesn't scale. Problem 2: What are the OPS recommendations for future developments? It might appear as the same problem as 1, but the audience is different. Here, we speak about new charters for example. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely fo= r the use of the individual or entity to which it is addressed. If you are no= t the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may b= e unlawful. If you have received this E-mail in error, please notify the send= er immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg Thank you /jon Jon Saperia saperia@g.harvard.edu Enterprise Architect Harvard University Information Technology Innovation & Architecture (P) (617) 384-6683 1350 Mass Ave., room 758 Cambridge, MA 02138 --_000_d8e4fabc63ea4ba3b799513789c5762bBY2PR03MB269namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree we have too many pr= otocols as is, and that’s part of the problem… too much choice = causes

confusion.  As the I= ETF has added protocols (and hence choices), confusion has increased.<= /o:p>

The IETF hasn’t suf= ficiently compensated enough by providing (enough) guidance to reduce that = confusion.

 <= /p>

-Dave (as chair of 2 grou= ps that have had to deal with that confusion)

 

From: Saperi= a Jon [mailto:saperia@g.harvard.edu]
Sent: Tuesday, November 5, 2013 11:56 AM
To: Dave Thaler
Cc: George, Wes; Benoit Claise; opsawg@ietf.org
Subject: Re: [OPSAWG] OPS guidance to the non-OPS community

 

FWIW, the challenges in management are not related t= o protocols, we have too many as it is.  It is good for groups to have= focus, and if this group has its focus on protocols, that is fine.  A= nother protocol will only make things more difficult for operational people and likely add cost to the products we buy.

 

/jon

On Nov 4, 2013, at 11:53 PM, Dave Thaler <dthaler@microsoft.com> wrote:=



As a WG chair, I would find "management" g= uidance extremely useful.
Outside of the OPS area, my WGs do protocols.  But of course people want to do management, monitoring, logging, etc. of those protocols.

So we get proposals to do logging with IPFIX, Syslog, etc.
And we get proposals to do management with Netconf, SNMP, etc
(and if you extend "management" to include all types of configura= tion
that would include DHCP and Router Advertisements in that list too).
And we get RADIUS, etc proposals.

People in other WGs are experts on their own protocol, rather than
on the protocols for all the other aspects mentioned above, and
any guidance is not only appreciated, it is needed.

How should non-OPS WGs evaluate which ones they need, or do
we just arbitrarily adopt specific proposals just because no one proposed <= br> alternatives?

Thanks Benoit for starting this discussion,
-Dave


-----Original Message-----
From: George, Wes [mailto:wesley.george@twca= ble.com]
Sent: Sunday, November 3, 2013 2:57 PM
To: Benoit Claise; opsawg@ietf.org Cc: Dave Thaler; Joel jaeggli (joelja@b= ogus.com)
Subject: RE: [OPSAWG] OPS guidance to the non-OPS community

Benoit -

I think there's a more basic question. What is "ops" in this cont= ext and how
do we as the IETF or OPSArea expect to represent it to "non-ops"?= What's
the desired outcome and audience - just to give those working within other<= br> areas of the IETF better guidance on tools? That sounds more like the
operative word is "tools" or "management" not ops.

If you are instead referring to broader operational feedback outside of IET= F,
that asks a second question - is IETF still the right venue for this? Do we= have
the credibility and experience? There are other initiatives aimed at provid= ing
feedback from operations (BCOP, the *NOG community, Deploy 360, etc)
that have better operator participation than IETF, so I'd be hesitant to reinvent the wheel here.
If the main goal is to update guidance more consistently and frequently
based on what tools are in common use, you'd get better results from
surveying a much wider community periodically - e.g. publishing a survey on=
*NOG lists, and using that to inform your results.

Your other fundamental question seems to be - how do we make IETF
recommendations, discussions of pros/cons for different tools and solutions= ,
etc more accessible for those who don't really fancy reading RFCs? Most of<= br> your examples seem to indicate that we'd be better with some sort of
system that pulls the relevant info out of multiple RFCs and presents them = in
one place based on the subject, rather than expecting people to find the relevant document(s) and then follow a chain of document, updated
document, updated updated document, obsoleted section, erratum, etc to
synthesize the actual current recommendation from all of the pieces. It's a=
real issue, but one much larger than OpsArea.

Wes George



-----Original Message-----
From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] = On
Behalf Of Benoit Claise
Sent: Thursday, October 31, 2013 1:06 PM
To: opsawg@ietf.org
Cc: Dave Thaler
Subject: [OPSAWG] OPS guidance to the non-OPS community

Dear all,

During the OPSAWG/OPSAREA meeting, I will be addressing one issue that
is now on the top of my mind: OPS guidance to the non-OPS community.

Problem 1:
How do we share our OPS knowledge? How do we advice which OPS tools
(NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should
be using?

On regular basis, I have to provide these advice How can we share this
knowledge?
This is the perfect job for an OPS advisor, but one OPS advisor in all
WGs doesn't scale.

Problem 2:
What are the OPS recommendations for future developments?
It might appear as the same problem as 1, but the audience is different. Here, we speak about new charters for example.



This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely fo= r
the use of the individual or entity to which it is addressed. If you are no= t the
intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may b= e
unlawful. If you have received this E-mail in error, please notify the send= er
immediately and permanently delete the original and any copy of this E-mail=
and any printout.

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

 

Thank you 

/jon

 

Jon Saperia

Enterprise Architect

Harvard University Information Technology

Innovation & Architecture

(P) (617) 384-6683

1350 Mass Ave., room 758

Cambridge, MA 02138

 

 

 

 

--_000_d8e4fabc63ea4ba3b799513789c5762bBY2PR03MB269namprd03pro_-- From mrm@vmware.com Tue Nov 5 23:53:12 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51C921E80E4 for ; Tue, 5 Nov 2013 23:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.278 X-Spam-Level: X-Spam-Status: No, score=-10.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Psq3L29pKJYF for ; Tue, 5 Nov 2013 23:53:07 -0800 (PST) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id A907B21E80EA for ; Tue, 5 Nov 2013 23:53:07 -0800 (PST) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 2D1BC2BCCB; Tue, 5 Nov 2013 23:53:04 -0800 (PST) Received: from zcs-prod-mta-2.vmware.com (zcs-prod-mta-2.vmware.com [10.113.163.64]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 288AFB05A5; Tue, 5 Nov 2013 23:53:04 -0800 (PST) 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 1278DE0048; Tue, 5 Nov 2013 23:53:04 -0800 (PST) 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; Tue, 5 Nov 2013 23:53:03 -0800 (PST) Date: Tue, 5 Nov 2013 23:53:03 -0800 (PST) From: Michael MacFaden To: Hirochika Asai Message-ID: <626660772.22369402.1383724383317.JavaMail.root@vmware.com> In-Reply-To: References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.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: VMM-MIB metrics for performance and troubleshooting Virtual Machines Thread-Index: P4RveR1fUgtbinvVyYSnLlJDpUVTJQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 07:53:13 -0000 > > Virtual Machine Processor > > > ProcessorUserTime CPU time spent on user processes (milliseconds) > > ProcessorSysTime CPU time spent on system processes > > (milliseconds) > What's the difference between these two time metrics? Breakdown between apps and OS, can be code running in priviledged processor mode vs non as well. Helps to know if a driver is going nuts or some web service. > Are they user-time and system-time at a guest OS? Yes All of these items presented are about either the Virtual Machine or code running in the virtual machine. > > Virtual Machine Processes > > PID Process ID > > ProcessName ProcessName > > ProcessParam ProcessParameters > > ProcessCPUUsage ProcessCPUUsage > > ProcessMemoryUsed ProcessMemoryUsage > Do you mean they are processes on a guest OS? Yes, they want that. > If the objects above are those of a guest OS, they need a special tool such > as vmware tools installed to the guest OS. So, MIB modules on guest OSes, such > as HOST-RESOURCES-MIB, could be used. Yes, that's one way. There could be others. More typically there will be SNMP agent running in the Guest OS that is polled separately and/or have an entry in ENTITY-MIB with hypervisor is another way. > The following objects are also related to guest OSes. > > Virtual Machine Partitions > > PartitionLabel disk path (c:\, /boot, etc) > > PartitionCapacity capacity of the disk in bytes > > PartitionUsedSpace capacity minus freespace > > PartitionUtilization used as a percentage of capacity > > Some of them might be recognizable from hypervisor. The partition format > itself does not vary by guest OS (i.e., MBR or GPT partition), so some of > these might be able to available from hypervisor. However, I still don't think > VM-MIB is the appropriate place to contain these objects, and it is better to use > MIB modules on guest OS (e.g., HOST-RESOURCES-MIB). Moreover, > PartitionLabel, PartitionUsedSpace, and PartitionUtilization are information > on file system, then a hypervisor cannot recognize them without any special > tools such as vmware tools. Makes sense to me. In fact I'd prefer if there was prose in the MIB to explain all how and where we recommend they look for these items. Regards, Mike MacFaden From saperia@g.harvard.edu Wed Nov 6 02:59:32 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DF221E80F9 for ; Wed, 6 Nov 2013 02:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNLd9t2Fy4LH for ; Wed, 6 Nov 2013 02:59:19 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD621E80E8 for ; Wed, 6 Nov 2013 02:59:17 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id hu16so1815977qab.4 for ; Wed, 06 Nov 2013 02:59:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=4Hf4ZlcR4XEg1AmD1qM+el60aV/7lq0GL0S8m+yzATM=; b=VwQkcHp5ldWCxy87mTjLlKwZoNC+zBnJtAJjodY4k2UTN3V4wxHvCt3C2xSjUpMolw SUWLSt1lgp7AWzQ75NrL4ffFX9uYuZNJp6eE2BXNLBnAsvM0kNIENrSs+tIxCQmK/M1y YDb4bewP0HAW50dHOkc2PehX4BMrWHd6X7xqlkSCRX3klkRSb8/sqRFJfmf1bCAWtqoN kPRZYBWMjMrO0qZaxcGyfR6Pmx8hOyuybRwXsOaW7e4IxuWSNchKnUh+BNCGeXHAE81d 2xKqCurNUMHORsKYsRxlt64bMtmGpYwQIa+cyjJwVbxfVeBFCNU7l8Et7+NbxCzc2lsm urxA== X-Gm-Message-State: ALoCoQmBl/g6FHCY4zfJip0HZuVHpdM82S1cwsgM4mivzvM2DShAbPL7gTZba3FTcDodbMHDW5yD X-Received: by 10.49.50.7 with SMTP id y7mr3280850qen.81.1383735557333; Wed, 06 Nov 2013 02:59:17 -0800 (PST) Received: from [10.0.1.18] (pool-96-252-103-237.bstnma.fios.verizon.net. [96.252.103.237]) by mx.google.com with ESMTPSA id r5sm78149005qaj.13.2013.11.06.02.59.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 02:59:16 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_6218F3D8-8154-448A-BB19-2E86AB0CB929" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jon Saperia In-Reply-To: <626660772.22369402.1383724383317.JavaMail.root@vmware.com> Date: Wed, 6 Nov 2013 06:01:15 -0500 Message-Id: <850A8122-FF3D-4DA5-A8E2-69A2AC1153B4@g.harvard.edu> References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> <626660772.22369402.1383724383317.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 10:59:32 -0000 --Apple-Mail=_6218F3D8-8154-448A-BB19-2E86AB0CB929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please see one additional comment at the end... On Nov 6, 2013, at 2:53 AM, Michael MacFaden wrote: >>> Virtual Machine Processor >>=20 >>> ProcessorUserTime CPU time spent on user processes = (milliseconds) >>> ProcessorSysTime CPU time spent on system processes >>> (milliseconds) >> What's the difference between these two time metrics? >=20 > Breakdown between apps and OS, can be code running in priviledged = processor > mode vs non as well. Helps to know if a driver is going nuts or some = web service. >=20 >> Are they user-time and system-time at a guest OS? >=20 > Yes All of these items presented are about either the Virtual Machine = or code running in the=20 > virtual machine. >=20 >=20 >>> Virtual Machine Processes >>> PID Process ID >>> ProcessName ProcessName >>> ProcessParam ProcessParameters >>> ProcessCPUUsage ProcessCPUUsage >>> ProcessMemoryUsed ProcessMemoryUsage >=20 >> Do you mean they are processes on a guest OS? >=20 > Yes, they want that. >=20 >> If the objects above are those of a guest OS, they need a special = tool such >> as vmware tools installed to the guest OS. So, MIB modules on guest = OSes, such >> as HOST-RESOURCES-MIB, could be used. >=20 > Yes, that's one way. There could be others. More typically there will = be=20 > SNMP agent running in the Guest OS that is polled separately and/or = have an > entry in ENTITY-MIB with hypervisor is another way. >=20 >> The following objects are also related to guest OSes. >>> Virtual Machine Partitions >>> PartitionLabel disk path (c:\, /boot, etc) >>> PartitionCapacity capacity of the disk in bytes >>> PartitionUsedSpace capacity minus freespace >>> PartitionUtilization used as a percentage of capacity >>=20 >> Some of them might be recognizable from hypervisor. The partition = format >> itself does not vary by guest OS (i.e., MBR or GPT partition), so = some of >> these might be able to available from hypervisor. However, I still = don't think >> VM-MIB is the appropriate place to contain these objects, and it is = better to use >> MIB modules on guest OS (e.g., HOST-RESOURCES-MIB). Moreover, >> PartitionLabel, PartitionUsedSpace, and PartitionUtilization are = information >> on file system, then a hypervisor cannot recognize them without any = special >> tools such as vmware tools. >=20 > Makes sense to me. In fact I'd prefer if there was prose in the MIB to > explain all how and where we recommend they look for these items. A good proposal. A number of earlier MIB Documents contained a section = call "Relationship to other MIBs". That would be a good way to address = this. >=20 > Regards, > Mike MacFaden > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg Jon Saperia Enterprise Architect Harvard University Information Technology Innovation & Architecture (M) (617) 201-2655 (P) (617) 384-6683 1350 Mass Ave., room 758 Cambridge, MA 02138 --Apple-Mail=_6218F3D8-8154-448A-BB19-2E86AB0CB929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii mrm@vmware.com> wrote:

Virtual Machine = Processor

=         ProcessorUserTime =  CPU time spent on user processes (milliseconds)
=         ProcessorSysTime =  CPU time spent on system processes
=         (milliseconds)
What's the difference between these two time = metrics?

Breakdown between apps and OS, can be code = running in priviledged processor
mode vs non as well. Helps to know = if a driver is going nuts or some web service.

Are they user-time and system-time at a guest = OS?

Yes All of these items presented are about = either the Virtual Machine or code running in the
virtual = machine.


Virtual Machine Processes
=         PID  Process ID
=         ProcessName =  ProcessName
=         ProcessParam =  ProcessParameters
=         ProcessCPUUsage =  ProcessCPUUsage
=         ProcessMemoryUsed = ProcessMemoryUsage

Do you mean they are processes on a guest = OS?

Yes, they want that.

If the objects above are those of a guest OS, they need a = special tool such
as vmware tools installed to the guest OS. =  So, MIB modules on guest OSes, such
as HOST-RESOURCES-MIB, = could be used.

Yes, that's one way. There could be = others. More typically there will be
SNMP agent running in the Guest = OS that is polled separately and/or have an
entry in ENTITY-MIB with = hypervisor is another way.

The = following objects are also related to guest OSes.
Virtual Machine Partitions
=         PartitionLabel =  disk path (c:\, /boot, etc)
=         PartitionCapacity =  capacity of the disk in bytes
=         PartitionUsedSpace =  capacity minus freespace
=         PartitionUtilization =  used as a percentage of capacity

Some of them = might be recognizable from hypervisor.  The partition = format
itself does not vary by guest OS (i.e., MBR or GPT partition), = so some of
these  might be able to available from hypervisor. =  However, I still don't think
VM-MIB is the appropriate place to = contain these objects, and it is better to use
MIB modules on guest = OS (e.g., HOST-RESOURCES-MIB).  Moreover,
PartitionLabel, = PartitionUsedSpace, and PartitionUtilization are information
on file = system, then a hypervisor cannot recognize them without any = special
tools such as vmware tools.

Makes sense = to me. In fact I'd prefer if there was prose in the MIB to
explain = all how and where we recommend they look for these = items.

A good proposal.  A number of = earlier MIB Documents contained a section call "Relationship to other = MIBs".  That would be a good way to address this.

Regards,
Mike = MacFaden
_______________________________________________
OPSAWG = mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

Jon = Saperia
Enterprise Architect
Harvard University Information = Technology
Innovation & Architecture
(M) (617)(P) (617) = 384-6683
1350 = Mass Ave., room 758



= --Apple-Mail=_6218F3D8-8154-448A-BB19-2E86AB0CB929-- From rstory@tislabs.com Wed Nov 6 05:09:28 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6234C11E8197 for ; Wed, 6 Nov 2013 05:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcBGO3m5QeXf for ; Wed, 6 Nov 2013 05:09:23 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4463511E814C for ; Wed, 6 Nov 2013 05:09:23 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id E26B928B0017; Wed, 6 Nov 2013 08:09:22 -0500 (EST) Received: from ispx.vb.futz.org (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id B63711F8035; Wed, 6 Nov 2013 08:09:22 -0500 (EST) Date: Wed, 6 Nov 2013 08:09:18 -0500 From: Robert Story To: Michael MacFaden Message-ID: <20131106080918.77bff086@ispx.vb.futz.org> In-Reply-To: <626660772.22369402.1383724383317.JavaMail.root@vmware.com> References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> <626660772.22369402.1383724383317.JavaMail.root@vmware.com> Organization: Parsons X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/OjZ6rJ_H94yKh3VUtPguutR"; protocol="application/pgp-signature" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:09:28 -0000 --Sig_/OjZ6rJ_H94yKh3VUtPguutR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 5 Nov 2013 23:53:03 -0800 (PST) Michael wrote: MM> [...] Yes All of these items presented are about either the Virtual MM> Machine or code running in the virtual machine. MM>=20 MM> [...] More typically there will be SNMP agent running in the Guest OS MM> that is polled separately and/or have an entry in ENTITY-MIB with MM> hypervisor is another way.=20 MM> >=20 MM> > [...] However, I still don't think VM-MIB is the appropriate place to MM> > contain these objects, and it is better to use MIB modules on guest MM> > OS (e.g., HOST-RESOURCES-MIB). [...] MM>=20 MM> Makes sense to me. In fact I'd prefer if there was prose in the MIB to MM> explain all how and where we recommend they look for these items. I don't think that the MIB is the right place for this. Sounds to me like what you are looking for is a BCP on monitoring virtual machines. Robert -- Senior Software Engineer Parsons Government Services , National Security & Defense Division --Sig_/OjZ6rJ_H94yKh3VUtPguutR Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlJ6P4IACgkQ7/fVLLY1mninjwCfe3GKzG8MOp5tKdAasPux75dC oVYAnAxjYFH2NhImjkar0TdVBUW9iI3D =BnCD -----END PGP SIGNATURE----- --Sig_/OjZ6rJ_H94yKh3VUtPguutR-- From mrm@vmware.com Wed Nov 6 07:49:24 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0567A11E81E8 for ; Wed, 6 Nov 2013 07:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.342 X-Spam-Level: X-Spam-Status: No, score=-10.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRGzJG5uB78u for ; Wed, 6 Nov 2013 07:49:18 -0800 (PST) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id EF37511E81DE for ; Wed, 6 Nov 2013 07:49:18 -0800 (PST) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 71A7A29D82; Wed, 6 Nov 2013 07:49:07 -0800 (PST) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 6D57B40431; Wed, 6 Nov 2013 07:49:07 -0800 (PST) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 5C4AAE00F7; Wed, 6 Nov 2013 07:49:07 -0800 (PST) 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; Wed, 6 Nov 2013 07:49:07 -0800 (PST) Date: Wed, 6 Nov 2013 07:49:07 -0800 (PST) From: Michael MacFaden To: Robert Story Message-ID: <820391329.22555106.1383752947141.JavaMail.root@vmware.com> In-Reply-To: <20131106080918.77bff086@ispx.vb.futz.org> References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> <626660772.22369402.1383724383317.JavaMail.root@vmware.com> <20131106080918.77bff086@ispx.vb.futz.org> 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: VMM-MIB metrics for performance and troubleshooting Virtual Machines Thread-Index: 4x5fn83jjKgbz0eDU3flQQPkEKh7Vw== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:49:24 -0000 >I don't think that the MIB is the right place for this. Sounds to me like Maybe I'm not making myself clear. Take the context of an an engineer trying to implement this MIB module. Commonly such engineers will not be experts in SNMP or IETF standard data modules. Take the context of an engineer writing the mgmt app usin said MIB module. They also might not know where to look for said information. A best practice would not be useful here as it doesn't provide prescriptive relationship. And it has been common practice for a given MIB module to explain its relationship to other MIB modules. This greatly improves interoperability in my experience. Regards, Mike MacFaden ----- Original Message ----- > On Tue, 5 Nov 2013 23:53:03 -0800 (PST) Michael wrote: > MM> [...] Yes All of these items presented are about either the Virtual > MM> Machine or code running in the virtual machine. > MM> > MM> [...] More typically there will be SNMP agent running in the Guest OS > MM> that is polled separately and/or have an entry in ENTITY-MIB with > MM> hypervisor is another way. > MM> > > MM> > [...] However, I still don't think VM-MIB is the appropriate place to > MM> > contain these objects, and it is better to use MIB modules on guest > MM> > OS (e.g., HOST-RESOURCES-MIB). [...] > MM> > MM> Makes sense to me. In fact I'd prefer if there was prose in the MIB to > MM> explain all how and where we recommend they look for these items. > > I don't think that the MIB is the right place for this. Sounds to me like > what you are looking for is a BCP on monitoring virtual machines. > > > Robert > > -- > Senior Software Engineer > Parsons Government Services , National Security & Defense Division > From internet-drafts@ietf.org Wed Nov 6 12:02:35 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6407021E818D; Wed, 6 Nov 2013 12:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nhUrkDxkGpo; Wed, 6 Nov 2013 12:02:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 318C421E81B4; Wed, 6 Nov 2013 12:02:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.82 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131106200216.12211.67743.idtracker@ietfa.amsl.com> Date: Wed, 06 Nov 2013 12:02:17 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-04.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:02:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Author(s) : Edward Beili Filename : draft-ietf-opsawg-rfc5066bis-04.txt Pages : 7 Date : 2013-11-06 Abstract: This document updates RFC 5066. It amends that specification by informing the internet community about the transition of the EFM-CU- MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-rfc5066bis-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 tom.taylor.stds@gmail.com Thu Nov 7 06:35:46 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A7821E81CA for ; Thu, 7 Nov 2013 06:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKO0GcMcvSeu for ; Thu, 7 Nov 2013 06:35:46 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9981121E81C1 for ; Thu, 7 Nov 2013 06:35:43 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id e14so898297iej.39 for ; Thu, 07 Nov 2013 06:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=rEOU556vVbwssqLEGWdXuj1uKfjJl/lVhrWqUYwaaNk=; b=cJl4d1fWf4hHqRn8tZyj/51Ix9fOfX4MV/Z0A6STueB1r6PzbrfcUCQtkxS2YUgW6Q Bkel31Mi3josbHDhjXrscbE1AsEUjmVitsrnSOs0TIi16Sl9zMOmXIsONKAIYVvb7oRQ m2mNk6lff6uLOrotIBnkRkAVp6eeXqUycbEnPvCXD4oCE+c6n9lgZfDTQkesii87d9Pl WQ2qbGAVic7HCSPq3gR2X4V8g/qbhxFHYCOUCcT0yjoSlCANQsXXaAzJ0GBvP2zqTzDY XNek3ilCNTgbik90EasAkjWywkT2AmAJ4pXFCdCMFoTedJJrsNCLPcmK4lZOupvPiOwC WQgQ== X-Received: by 10.50.114.67 with SMTP id je3mr2079868igb.59.1383834942985; Thu, 07 Nov 2013 06:35:42 -0800 (PST) Received: from [192.168.1.69] ([64.56.250.4]) by mx.google.com with ESMTPSA id ka1sm4427031igb.7.2013.11.07.06.35.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 06:35:42 -0800 (PST) Message-ID: <527BA53B.30507@gmail.com> Date: Thu, 07 Nov 2013 09:35:39 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Review of draft-ietf-opsawg-capwap-extension-01: Section 4.2 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:35:46 -0000 Section 4.2 of draft-ietf-opsawg-capwap-extension-01 defines the 802.11n Radio Configuration message element. I have some comments here: (1) Wouldn't this element appear in the CAPWAP Configuration Update Response message as well as the Request? (2) What are A-MSDU, A-MPDU? Need a little explanation. Similarly, what is MCS, and what is the difference between maximal supported and maximal mandatory MCS? (3) Are the antennae all the same, so ordering does not matter, or do particular bits correspond to particular uniquely identifiable antennae. Tom Taylor From tom.taylor.stds@gmail.com Thu Nov 7 15:28:34 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAC211E8103 for ; Thu, 7 Nov 2013 15:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2z66pmCnqHr for ; Thu, 7 Nov 2013 15:28:32 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C339121E80FC for ; Thu, 7 Nov 2013 15:28:21 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id u16so2083021iet.18 for ; Thu, 07 Nov 2013 15:28:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zKT41mfP+Es7gbrIVT7BKif3DaQWg2/vAwq7AVPEHxU=; b=VqLU2IzdVcSNKSFkUuKD8kPzcQ6C/I2f/NjlE0CEnzkzACWIAGZ7GP2s+hYYBrZUDs 6wU9kh/8DoacAEt/V54HauOqFLYHIF+Gom4ZtWCk8EexRzlk4WJLeFubTMXQ66KO+kFJ QVzg42McR24OrOFNqFdZkee9KM6vI6yTKGIwL1l3Y8vDpMx4+E3AEJj7FQFnnVHMWKI5 fbDvai3jzg25IeSnMsSovagLg7t33qeOTzuag4G6ZCLAlvOR9A/SuAeBNHTdHHzrqNRs DiNycxw9FT/PpmqwjvBWJXZm9nnlQf3jGyA9YBhif4bI8CrlpO9qQJJ2wHCilvT2v4Q+ 1ilw== X-Received: by 10.50.106.20 with SMTP id gq20mr4090igb.36.1383866901137; Thu, 07 Nov 2013 15:28:21 -0800 (PST) Received: from [192.168.1.69] ([64.56.250.4]) by mx.google.com with ESMTPSA id x5sm68416iga.6.2013.11.07.15.28.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 15:28:20 -0800 (PST) Message-ID: <527C2211.2010005@gmail.com> Date: Thu, 07 Nov 2013 18:28:17 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "opsawg@ietf.org" , liu dapeng Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSAWG] WTP scan process in draft-ietf-opsawg-capwap-extension-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:28:34 -0000 I'm not clear on the description of scan only mode. Is it correct that the WTP provides no service to stations when operating in this as opposed to active mode? If so, setting PrimeChnlSrvTime to 0 makes sense, but there should also be an explicit statement that no service is provided. If not, it makes no sense to set PrimeChnlSrvTime to 0. Follow-up question: if no service is provided, is that true until the WTP is reconfigured, or only until scanning is complete? Tom Taylor From reid@snmp.com Fri Nov 8 12:34:54 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8178421E809B for ; Fri, 8 Nov 2013 12:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A32SwcYus7XV for ; Fri, 8 Nov 2013 12:34:47 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C4CC621E8082 for ; Fri, 8 Nov 2013 12:34:46 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA01855; Fri, 8 Nov 2013 15:34:38 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA05846; Fri, 8 Nov 2013 15:34:35 -0500 (EST) Message-Id: <201311082034.PAA05846@adminfs.snmp.com> To: Johannes Merkle From: David Reid In-reply-to: Your message of Tue, 05 Nov 2013 16:58:28 +0100. <527915A4.6060900@secunet.com> Date: Fri, 08 Nov 2013 15:34:35 -0500 Sender: reid@snmp.com Cc: Manfred Lochter , opsawg@ietf.org, turners@ieca.com Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:34:54 -0000 > we have published a draft on a new authentication protocol for USM for SNMP. > > Abstract > > This memo specifies a new optional HMAC-SHA-256-128 authentication > protocol for the User-based Security Model (USM) for SNMPv3 defined > in RFC 3414. > > The new protocol is a straightforward adaptation of the protocols > HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the > SHA-256 based HMAC with truncation to 128 bits. Comments and > suggestions are welcome. > > Is there any interest in adoption by the WG? Yes, I would like to see this adopted by the working group and I'm willing to review documents. We implemented SHA-2 in almost exactly the same way that this document suggests. We would almost certainly implement the standard version if the working group adopts it. -David Reid From saperia@g.harvard.edu Fri Nov 8 12:47:06 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0D121E8137 for ; Fri, 8 Nov 2013 12:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSa0vubIR4V4 for ; Fri, 8 Nov 2013 12:47:01 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 78F4021E808D for ; Fri, 8 Nov 2013 12:46:50 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id ii20so2140987qab.4 for ; Fri, 08 Nov 2013 12:46:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=m5qKroKqKwOmtOm8HlRJg8QfKdUYOG+LLdHETbo0ZmE=; b=KlLQbpr/VaG+WLAVnBIDemaaHJeCIsiZOlK4lqgYaor6ydXs1MZlxN+Xkaj9jDaX4G 928FLJFdiXs6uB/VcpCDOZJScpC81LlCTahimyhxrEQiuqUnDLSYr/iz6/YpGY7FktlT 4IXoA3QVzY6F8/LhAZrbxq5/FCkly0lmymO+5OnYhCYP1TPQji18hEg6fpXmiXu9cq6W E/iXlCTRH1R2a9UHdQZ40aPS0IJduSzE9LNUByAJpyWN38NpT1AEhrScWADOqq3a0OCb autEIL+p0EXicTLDRSacfGowsGP4FL2Uy17etEBhpWJD6w8ooHP4C6YFa/QtQixQSPpz rQQA== X-Gm-Message-State: ALoCoQls+53lGGRIYvLpHF4WbffYgoqmHnKN7mPmnUHff3Bxgp7P9uVQ74+mgJzHYeXBtotjhJI3 X-Received: by 10.49.98.1 with SMTP id ee1mr25748723qeb.28.1383943607999; Fri, 08 Nov 2013 12:46:47 -0800 (PST) Received: from [10.0.1.18] (pool-96-252-103-237.bstnma.fios.verizon.net. [96.252.103.237]) by mx.google.com with ESMTPSA id og1sm22323198qeb.3.2013.11.08.12.46.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 12:46:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F84BC6F-679B-4146-BDC8-FAB6D667F028" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jon Saperia In-Reply-To: <201311082034.PAA05846@adminfs.snmp.com> Date: Fri, 8 Nov 2013 15:46:47 -0500 Message-Id: <3A7A405F-FC8C-42D0-AC0E-3F5F8C1CD171@g.harvard.edu> References: <201311082034.PAA05846@adminfs.snmp.com> To: David Reid X-Mailer: Apple Mail (2.1510) Cc: Manfred Lochter , opsawg@ietf.org, turners@ieca.com Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:47:06 -0000 --Apple-Mail=_2F84BC6F-679B-4146-BDC8-FAB6D667F028 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would be as well. /jon On Nov 8, 2013, at 3:34 PM, David Reid wrote: >> we have published a draft on a new authentication protocol for USM = for SNMP. >>=20 >> Abstract >>=20 >> This memo specifies a new optional HMAC-SHA-256-128 authentication >> protocol for the User-based Security Model (USM) for SNMPv3 defined >> in RFC 3414. >>=20 >> The new protocol is a straightforward adaptation of the protocols=20 >> HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the >> SHA-256 based HMAC with truncation to 128 bits. Comments and=20 >> suggestions are welcome. >>=20 >> Is there any interest in adoption by the WG? >=20 > Yes, I would like to see this adopted by the working group and I'm > willing to review documents. We implemented SHA-2 in almost exactly > the same way that this document suggests. We would almost certainly=20 > implement the standard version if the working group adopts it.=20 >=20 > -David Reid > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail=_2F84BC6F-679B-4146-BDC8-FAB6D667F028 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = would be as well.
/jon
On Nov 8, 2013, at 3:34 PM, = David Reid <reid@snmp.com> = wrote:

we have published a draft on a = new authentication protocol for USM for SNMP.

Abstract

=   This memo specifies a new optional HMAC-SHA-256-128 = authentication
  protocol for the User-based Security = Model (USM) for SNMPv3 defined
  in RFC 3414.

The = new protocol is a straightforward adaptation of the protocols =
HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the
SHA-256 based = HMAC with truncation to 128 bits. Comments and
suggestions are = welcome.

Is there any interest in adoption by the = WG?

Yes, I would like to see this adopted by the = working group and I'm
willing to review documents. We implemented = SHA-2 in almost exactly
the same way that this document suggests. We = would almost certainly
implement the standard version if the working = group adopts it.

-David = Reid
_______________________________________________
OPSAWG = mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg


= --Apple-Mail=_2F84BC6F-679B-4146-BDC8-FAB6D667F028-- From melinda.shore@gmail.com Sun Nov 10 21:22:23 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C7321E805F for ; Sun, 10 Nov 2013 21:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYY+4jtpNPYy for ; Sun, 10 Nov 2013 21:22:23 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 369FF11E8203 for ; Sun, 10 Nov 2013 21:22:23 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id hz1so1395068pad.37 for ; Sun, 10 Nov 2013 21:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=UIaHsApxTgMPRPQLkmQvaf3vsPYlvs+AotUgbQdy/6A=; b=Up13f3bag85tZdNGO3JH+XIAXAdaIw9kV5EvIkYrTFIxeScpizlritPBpk7IcM5L3v HsvgqqGtVkn9peasn/ef7VXix2yM9aWVqKs2xogp65CPRyjMdZW+CQoF54z4f7+S5FgC FUsiozEKklHj4LADZajrh1lFpgBr7k0sIlQa+M4EDuIUAcGef3uHaeSR5OyLhfNyiRIX KEQo1hAS0cvzHB6EM1QDYki9/vBPwPqYb6nPLn9cqCGLeKw4pZ5NNXyelticldlazxw+ KAEHhYtVLZf8EP0N4o2e8V/iAzF5KNnQ3y/qZLGr8+N/Erow8M2qerANJeXESHqXYBaw hZvg== X-Received: by 10.67.21.130 with SMTP id hk2mr29469113pad.76.1384147342997; Sun, 10 Nov 2013 21:22:22 -0800 (PST) Received: from spandex.local (216-67-63-247-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.63.247]) by mx.google.com with ESMTPSA id ha10sm3570460pbd.17.2013.11.10.21.22.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 21:22:22 -0800 (PST) Message-ID: <5280698C.7010603@gmail.com> Date: Sun, 10 Nov 2013 20:22:20 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] opsawg minutes uploaded X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 05:22:23 -0000 Many thanks to Tom Taylor for his exceptionally good minutes, which we've uploaded to http://www.ietf.org/proceedings/88/minutes/minutes-88-opsawg. Over the next week or so we'll be following up on action items coming out of last weeks's session; in the meantime please review the minutes and let us know of any corrections that need to be made, missing information, etc. Again, many thanks to Tom for doing such a wonderful job on the minutes. Melinda, Scott, Warren From panda@hongo.wide.ad.jp Tue Nov 12 23:43:29 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C758421F9BC2 for ; Tue, 12 Nov 2013 23:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.979 X-Spam-Level: X-Spam-Status: No, score=0.979 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+zB-N+UfUmm for ; Tue, 12 Nov 2013 23:43:14 -0800 (PST) Received: from mail.hongo.wide.ad.jp (mail.hongo.wide.ad.jp [203.178.135.13]) by ietfa.amsl.com (Postfix) with ESMTP id 36E8521F9A7D for ; Tue, 12 Nov 2013 23:43:14 -0800 (PST) Received: from [157.82.7.197] (unknown [157.82.7.197]) by mail.hongo.wide.ad.jp (Postfix) with ESMTPSA id 746BC108E8D7; Wed, 13 Nov 2013 16:43:12 +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: <626660772.22369402.1383724383317.JavaMail.root@vmware.com> Date: Wed, 13 Nov 2013 16:43:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> <626660772.22369402.1383724383317.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 07:43:29 -0000 Dear Mike and all, Thank you for your description on several metrics I asked. The = followings are the correspondence table of metrics you had sent us to the current definition of VM-MIB. The metrics that are not contained in VM-MIB is marked with "*". However, some of them cannot be obtained at hypervisors without any support of a special tool such as VMware tools because they are managed by a guest OS. These objects are marked with "#". Virtual Machine General Metrics MachineName name of VM =3D=3D> vmName MachineServer ESX server that hosts this VM =3D=3D> vmHvSoftware etc. MachinePowerStatus power status of the VM =3D=3D> vmAdminState, vmOperState MachineUpTime number of seconds since last boot =3D=3D> vmUpTime (But I think we need to clarify that this = is uptime since last boot, but not last migration) *MachineLastUpdate number of heartbeats received from the VM =3D=3D> Need vmware tools? Hypervisors can know whether a = CPU is to scheduled to a guest without heartbeat. MachineGuestOS fullname of the guest OS =3D=3D> vmOSType *MachineGuestIpAddr IP address of the guest =3D=3D> Need vmware tools? =3D=3D> ENTITY-MIB? MachineCPUNum Number of vCPUs in SYSTEM =3D=3D> The number of physical CPUs: HOST-RESOURCES-MIB at = hypervisor The number of virtual CPUs: Count entries in vmCpuTable *MachineResourcePool The Resource Pool this VM is a part of =3D=3D> What is resource pool? an ID of hypervisor cluster? *MachineLastVMotionTime Shows the last time a VM was vmotion =3D=3D> discussion-general-1: Do we need to have this? = e.g., vmLastMigration *MachineHAEligible Is this Virtual machine protected using = Vmware HA =3D=3D> discussion-general-2: I don't think it's to be = added to VM-MIB. *MachineCreatedBy Who Created this Virtual Machine =3D=3D> discussion-general-3: This is needed (as = SnmpAdminString)? Or not needed? *MachineCreatedDateTime When was this Virtual Machine Created =3D=3D> discussion-general-4: Whether we add this or not Virtual Machine Memory =3D=3D=3D=3D> In this set of metrics, I may misunderstand the = difference between host, guest, and VM MemoryTotalSize memory size of the VM in MB =3D=3D> vmCurMem? What's the difference from = MemoryGuestUsage? MemoryMaxAlloc amount of memory in MB that the VM can receive =3D=3D> vmMaxMem MemoryMinAlloc amount of memory in MB guaranteed to the MB =3D=3D> vmMinMem *?MemoryHostUsage consumed host memory in MB =3D=3D> What's this? MemoryGuestUsage active guest memory in MB =3D=3D> vmCurMem? What's the difference from = MemoryTotalSize? *MemoryHostUtil host memory used as a percentage of the total = VM memory =3D=3D> This can be calculated from vmCurMem and = hrMemorySize of HOST-RESOURCES-MIB *MemoryGuestUtil guest memory used as a percentage of the = total VM memory =3D=3D> This an be calculated from vmCurMem and = hrMemorySize of HOST-RESOURCES-MIB? *#?MemorySwapToFile amount of memory being swapped in KB =3D=3D> discussion-men-1: Hypervisor cannot know the = swap size on the guest OS without a special tool, i.e., this metrics is = to be obtained from the agent on guest OSes. So does VMM-MIB need not to = have this? If this means the memory managed by a hypervisor is = swapped to the hypervisor's storage, we need another discussion. Virtual Machine Processor *ProcessorIdleTime CPU time spend in wait state (milliseconds) =3D=3D> discussion-cpu-1: (wait state?) Related to = Jon's proposal #ProcessorUserTime CPU time spent on user processes = (milliseconds) #ProcessorSysTime CPU time spent on system processes = (milliseconds) =3D=3D> vmCpuTime (user&sys are combined, because = hypervisors do not distinguish these on a guest OS.) *ProcessorWaitTime CPU time spent in ready state = (milliseconds) =3D=3D> discussion-cpu-1: (ready state?) Related to = Jon's proposal *ProcessorUtilization user time as a percentage of total CPU = time =3D=3D> (calculated from vmCpuTime) *Processor%Ready ready time as a percentage of total cpu time =3D=3D> (calculated from ProcessorWaitTime if newly = defined) Virtual Machine Disk DiskDescription disk label =3D=3D> vmStorageResourceID? DiskType type of disk (hard disk, floppy, etc) =3D=3D> vmStorageMediaType (but floopy is not = defined), vmStorageMediaTypeString DiskAccess read/write =3D=3D> vmStorageAccess DiskCapacity capacity of the virtual disk =3D=3D> vmStorageDefinedSize, vmStorageAllocatedSize *DiskRemovable true/false =3D=3D> discussion-storage-1: whether we need this or = not Virtual Machine Partitions *#PartitionLabel disk path (c:\, /boot, etc) *#PartitionCapacity capacity of the disk in bytes *#PartitionUsedSpace capacity minus freespace *#PartitionUtilization used as a percentage of capacity =3D=3D> (should be HOST-RESOURCES-MIB on guest OS?) Virtual Machine Network Description Network device description =3D=3D> ifDescr or ifName from vmNetworIfIndex PhysAddress physical MAC address =3D=3D> vmNetworkPhysAddress Read Count number of packets read =3D=3D> ifOutUcastPkts (ifInUcastPkts?) from = vmNetworIfIndex Write Count number of packets written =3D=3D> ifInUcastPkts (ifOutUcastPkts?) from = vmNetworkIfIndex Read Rate number of bytes read =3D=3D> ifOutOctets (ifInOctets?) from vmNetworIfIndex Write Rate number of bytes written =3D=3D> ifInOctets (ifOutOctets?) from vmNetworIfIndex Virtual Machine Processes *#PID Process ID *#ProcessName ProcessName *#ProcessParam ProcessParameters *#ProcessCPUUsage ProcessCPUUsage *#ProcessMemoryUsed ProcessMemoryUsage =3D=3D> (should be HOST-RESOURCES-MIB on guest OS?) Thank you, Hirochika --=20 Hirochika Asai , The University of Tokyo From saperia@g.harvard.edu Wed Nov 13 04:59:02 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E155421F9F8E for ; Wed, 13 Nov 2013 04:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07vvwLlEqpNU for ; Wed, 13 Nov 2013 04:58:57 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id E5B7E21E80EB for ; Wed, 13 Nov 2013 04:58:38 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id cy11so193416qeb.26 for ; Wed, 13 Nov 2013 04:58:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=CFnrpfMVeFvuPKHN7M/5/l83BbvcTVQwYDeVIvAFZ20=; b=J8Y0GbqNMphSgWVh4ZBHggOSr8B+hautRlv2jCAmrbqOA7SO5mFJtLPh9xwBGh8Zxj j4ijWnkcxozlbiK+zjf2dSDE9046W18yAHS6BYfsB8DAhk477wlsVt3K/YDNwBr1rGyc VoX4N7R4Vc+VUOdBouq269PnqciTW9ottyixEoZqiIc2YOCI8rnjSeLw2btRwqh2ZS5i jLy+I0+8DEfsdJREHFeHSNWB+5kryTWXw99wSSgJvgSNrBQB93iKOgTCwp4CTtWo0/rc 3vmluCwU1cGylLC6mPda5AVPQaIl9Kql83k5mQVcBBYycp127fluaDM6TSoJIwfic5kI yQ4w== X-Gm-Message-State: ALoCoQnDFL96iVUi8kAlHXYTe2KtkbvwT4H/eDP5iIsc0zHZIvwRS7EtsVjHSauMRXhFsKRbw432 X-Received: by 10.224.115.81 with SMTP id h17mr67558880qaq.64.1384347518459; Wed, 13 Nov 2013 04:58:38 -0800 (PST) Received: from dhcp-128-103-65-199.harvard.edu (dhcp-128-103-65-199.harvard.edu. [128.103.65.199]) by mx.google.com with ESMTPSA id ge5sm10943779qeb.5.2013.11.13.04.58.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Nov 2013 04:58:37 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A8EEAC46-0A58-4830-8153-42939A59DC6C" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Saperia Jon In-Reply-To: <820391329.22555106.1383752947141.JavaMail.root@vmware.com> Date: Wed, 13 Nov 2013 07:58:38 -0500 Message-Id: References: <8FF796B9-B3E1-4202-B189-F80E82175DCD@g.harvard.edu> <750BAC21-6292-4594-918C-862588A22320@hongo.wide.ad.jp> <1899989239.21369520.1383627994607.JavaMail.root@vmware.com> <1245953610.21762972.1383674549075.JavaMail.root@vmware.com> <626660772.22369402.1383724383317.JavaMail.root@vmware.com> <20131106080918.77bff086@ispx.vb.futz.org> <820391329.22555106.1383752947141.JavaMail.root@vmware.com> To: Michael MacFaden X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] VMM-MIB metrics for performance and troubleshooting Virtual Machines X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 12:59:02 -0000 --Apple-Mail=_A8EEAC46-0A58-4830-8153-42939A59DC6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think Mike has it right as I noted earlier. A section of this module = that describes the relationship of this to other relevant MIB modules = would be helpful, not only to the two groups (MIB and Management = Application Engineers) but also to people that run networks since they = are also not commonly standards experts. /jon On Nov 6, 2013, at 10:49 AM, Michael MacFaden wrote: >=20 >> I don't think that the MIB is the right place for this. Sounds to me = like >=20 > Maybe I'm not making myself clear.=20 >=20 > Take the context of an an engineer trying to implement this MIB = module. > Commonly such engineers will not be experts in SNMP or IETF standard = data modules. >=20 > Take the context of an engineer writing the mgmt app usin said MIB = module. > They also might not know where to look for said information. >=20 > A best practice would not be useful here as it doesn't provide = prescriptive relationship. > And it has been common practice for a given MIB module to explain its = relationship to > other MIB modules. This greatly improves interoperability in my = experience. >=20 > Regards, > Mike MacFaden >=20 >=20 > ----- Original Message ----- >> On Tue, 5 Nov 2013 23:53:03 -0800 (PST) Michael wrote: >> MM> [...] Yes All of these items presented are about either the = Virtual >> MM> Machine or code running in the virtual machine. >> MM> >> MM> [...] More typically there will be SNMP agent running in the = Guest OS >> MM> that is polled separately and/or have an entry in ENTITY-MIB with >> MM> hypervisor is another way. >> MM> > >> MM> > [...] However, I still don't think VM-MIB is the appropriate = place to >> MM> > contain these objects, and it is better to use MIB modules on = guest >> MM> > OS (e.g., HOST-RESOURCES-MIB). [...] >> MM> >> MM> Makes sense to me. In fact I'd prefer if there was prose in the = MIB to >> MM> explain all how and where we recommend they look for these items. >>=20 >> I don't think that the MIB is the right place for this. Sounds to me = like >> what you are looking for is a BCP on monitoring virtual machines. >>=20 >>=20 >> Robert >>=20 >> -- >> Senior Software Engineer >> Parsons Government Services , National Security & Defense Division >>=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg Thank you=20 /jon Jon Saperia saperia@g.harvard.edu Enterprise Architect Harvard University Information Technology Innovation & Architecture (P) (617) 384-6683 1350 Mass Ave., room 758 Cambridge, MA 02138 --Apple-Mail=_A8EEAC46-0A58-4830-8153-42939A59DC6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think Mike has it right as I noted earlier.  A section of this = module that describes the relationship of this to other relevant MIB = modules would be helpful, not only to the two groups (MIB and Management = Application Engineers) but also to people that run networks since they = are also not commonly standards experts.
/jon
On Nov 6, = 2013, at 10:49 AM, Michael MacFaden <mrm@vmware.com> wrote:


I don't think that the MIB = is the right place for this. Sounds to me like

Maybe = I'm not making myself clear.

Take the context of an an engineer = trying to implement this MIB module.
Commonly such engineers will not = be experts in SNMP or IETF standard data modules.

Take the = context of an engineer writing the mgmt app usin said MIB = module.
They also might not know where to look for said = information.

A best practice would not be useful here as it = doesn't provide prescriptive relationship.
And it has been common = practice for a given MIB module to explain its relationship to
other = MIB modules. This greatly improves interoperability in my = experience.

Regards,
Mike MacFaden


----- Original = Message -----
On Tue, 5 Nov 2013 23:53:03 = -0800 (PST) Michael wrote:
MM> [...] Yes All of these items = presented are about either the Virtual
MM> Machine or code running = in the virtual machine.
MM>
MM> [...] More typically there = will be SNMP agent running in the Guest OS
MM> that is polled = separately and/or have an entry in ENTITY-MIB with
MM> hypervisor = is another way.
MM> >
MM> > [...] However, I still = don't think VM-MIB is the appropriate place to
MM> > contain = these objects, and it is better to use MIB modules on guest
MM> = > OS (e.g., HOST-RESOURCES-MIB).  [...]
MM>
MM> = Makes sense to me. In fact I'd prefer if there was prose in the MIB = to
MM> explain all how and where we recommend they look for these = items.

I don't think that the MIB is the right place for this. = Sounds to me like
what you are looking for is a BCP on monitoring = virtual machines.


Robert

--
Senior Software = Engineer
Parsons Government Services , National Security & = Defense = Division

_____________________________________________= __
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.or= g/mailman/listinfo/opsawg

Thank you 
/jon
Jon = Saperia
Harvard University Information Technology
 (617) = 384-6683
1350 = Mass Ave., room 758

= --Apple-Mail=_A8EEAC46-0A58-4830-8153-42939A59DC6C-- From melinda.shore@gmail.com Fri Nov 15 21:53:49 2013 Return-Path: X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD58E11E80ED for ; Fri, 15 Nov 2013 21:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_102=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76Ych-0oN-Od for ; Fri, 15 Nov 2013 21:53:49 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9EC11E8125 for ; Fri, 15 Nov 2013 21:53:49 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id rd3so4550124pab.0 for ; Fri, 15 Nov 2013 21:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=6N/BCHnq1ND9fmE0ft3SjKpHftudgyNA1WtGM/FR6Ho=; b=UUBv8yLV2JjLDxHwpg7g8DR4jkADXJeN19WpQsTEWWN/qRiRzgSyrWjzdzuU7z4x8U kaqBoh7xfgdborB3jUgzfVgLcYrsjGK1hJa3vKBkjlpKpdstZQTh+Uz/nD/nNXr/yIGl vqpsHlZ6oenY1lXLT4MS5PesHFxhggEBLYBp3dQR95AJi+w+eyHhHpnD98tmg5z5d0My URr5gSqu++YEI0mn4T2zVWx5MWnSDzZZGp1f6gDW+XinLIkOB/eDuPw8vOTKXDyM9E45 CrA2EqNlpoQ6uM0v3UJVdV49lrEfLwgozX4bARucTeP8OxgUDSab1WTPtkujAF1V2YiH VDvQ== X-Received: by 10.67.22.38 with SMTP id hp6mr10477895pad.53.1384581229283; Fri, 15 Nov 2013 21:53:49 -0800 (PST) Received: from spandex.local (216-67-38-134-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.38.134]) by mx.google.com with ESMTPSA id py4sm8546694pbb.33.2013.11.15.21.53.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 21:53:48 -0800 (PST) Message-ID: <52870869.6000405@gmail.com> Date: Fri, 15 Nov 2013 20:53:45 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-asai-vmm-mib@tools.ietf.org Subject: [OPSAWG] "Management Information Base for Virtual Machines Controlled, by a Hypervisor" adopted X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Nov 2013 05:53:50 -0000 Sorry not to get this posted sooner; we had an ice storm and are just now getting back online. We've agreed to adopt "Management Information Base for Virtual Machines Controlled by a Hypervisor" as an opsawg draft. The authors should resubmit the draft as draft-ietf-vmm-mib, and one of the chairs will approve it. Melinda From alex@cisco.com Tue Nov 19 14:02:41 2013 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 A54311AE0B6 for ; Tue, 19 Nov 2013 14:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, 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 YnO1Nhy3Q3qV for ; Tue, 19 Nov 2013 14:02:38 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7EE1AE078 for ; Tue, 19 Nov 2013 14:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5875; q=dns/txt; s=iport; t=1384898552; x=1386108152; h=from:to:cc:subject:date:message-id:mime-version; bh=EGbpniSF2kNp+gK7mnrOTNb5vPvl6hf1xVGiDVo3MAA=; b=kEZRAYIWwK4qSqvfRYsyPWMoxt9dqXfjKwVlWRJmYEn+wmdO2hplD9UV bfHSDQl1YieShUbhmgMfKKrlGAmDxeNqqLr1KisY88v7Ps2sdU69aKE8H NQoWA6pPP0viAQQZFVy089/KoKMlPhl+T/Y7aqtusHSD5g/KBomtxxY4W I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroGAPHei1KtJV2b/2dsb2JhbABZDoI1RDhTrRWJYIhLgSEWdIInAQQtTBIBKlYmAQQBDQ2HeQ2/dY8mMYMngRIDmUGQXoJpP4Iq X-IronPort-AV: E=Sophos;i="4.93,732,1378857600"; d="scan'208,217";a="286273684" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 19 Nov 2013 22:02:31 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAJM2UxP026610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 22:02:30 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.100]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 16:02:30 -0600 From: "Alexander Clemm (alex)" To: "opsawg@ietf.org" , "melinda.shore@gmail.com" , "sob@harvard.edu" , "warren@kumari.net" , "Juergen Schoenwaelder (j.schoenwaelder@jacobs-university.de)" Thread-Topic: Stateless packet filters and ACLs Thread-Index: Ac7lcu1kz55x2lfMSFCcOKyup4eupg== Date: Tue, 19 Nov 2013 22:02:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.145] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B5718615B25xmbrcdx05ciscoc_" MIME-Version: 1.0 Cc: "Lisa Huang \(yihuan\)" Subject: [OPSAWG] Stateless packet filters and ACLs 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, 19 Nov 2013 22:02:41 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B5718615B25xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We currently have an Internet draft for a YANG data model for configuration= of stateless packet filters (SPFs) and Access Control Lists (ACLs) - draft= -huang-netmod-acl-03.txt (http://datatracker.ietf.org/doc/draft-huang-netmo= d-acl/). The draft is currently under discussion in the NETMOD working gro= up; however, NETMOD's stance regarding the future development of YANG data = models is not clear and we are wondering whether this would be a candidate = for potential adoption in OPSAWG. The draft presents an extensible and modular framework for management of SP= Fs and ACLs, which are an important part of device configuration. They are= needed both by administrators and by applications, for example for dynamic= intrusion protection systems and applications that dynamically need to adj= ust firewall rules . Accordingly, many SDN-type applications involve contr= ol loops involving manipulation of stateless packet filters; in the context= of I2RS (which looks like it will leverage YANG) and Open Daylight (which = does today) this need been repeatedly stated. IP, MAC, and ARP are address= ed as initial SPF types, more can be defined. Clearly, standardization is = needed in this area, which we would like to see happen in IETF. Thoughts? Thank you --- Alex (also on behalf of Lisa, Andy) --_000_DBC595ED2346914F9F81D17DD5C32B5718615B25xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We currently have an Internet draft for a YANG data model=
 for configuration of stateless packet filters (SPFs) and Access Control Li=
sts (ACLs) - draft-huang-netmod-acl-03.txt (http://datatracker.ietf.org/doc/draft-=
huang-netmod-acl/).  The draft is currently under discussion in th=
e NETMOD working group; however, NETMOD’s stance regarding the future=
 development of YANG data models is not clear and we are wondering whether =
this would be a candidate for potential adoption in OPSAWG.  
 

The draft presents an extensible and modular framewo= rk for management of SPFs and ACLs, which are an important part of device c= onfiguration.  They are needed both by administrators and by applicati= ons, for example for dynamic intrusion protection systems and applications that dynamically need to adjust firewa= ll rules .  Accordingly, many SDN-type applications involve control lo= ops involving manipulation of stateless packet filters; in the context of I= 2RS (which looks like it will leverage YANG) and Open Daylight (which does today) this need been repeatedly state= d.  IP, MAC, and ARP are addressed as initial SPF types, more can be d= efined.  Clearly, standardization is needed in this area, which we wou= ld like to see happen in IETF.  

 

Thoughts?

 

Thank you

--- Alex (also on behalf of Lisa, Andy)

 

 

--_000_DBC595ED2346914F9F81D17DD5C32B5718615B25xmbrcdx05ciscoc_-- From reid@snmp.com Tue Nov 19 14:15:34 2013 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 1E99A1AE0B6 for ; Tue, 19 Nov 2013 14:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-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 4vQk90yM7tcY for ; Tue, 19 Nov 2013 14:15:32 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFCB1AE078 for ; Tue, 19 Nov 2013 14:15:31 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id RAA20304; Tue, 19 Nov 2013 17:15:25 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id RAA22351; Tue, 19 Nov 2013 17:14:09 -0500 (EST) Message-Id: <201311192214.RAA22351@adminfs.snmp.com> To: Johannes Merkle From: David Reid In-reply-to: Your message of Tue, 05 Nov 2013 17:00:26 +0100. <5279161A.7080703@secunet.com> Date: Tue, 19 Nov 2013 17:14:08 -0500 Sender: reid@snmp.com Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 22:15:34 -0000 > we have published a draft on a new authentication protocol for USM for SNMP. > > Abstract > > This memo specifies a new optional HMAC-SHA-256-128 authentication > protocol for the User-based Security Model (USM) for SNMPv3 defined > in RFC 3414. > > The new protocol is a straightforward adaptation of the protocols > HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the SHA-256 based HMAC > with truncation to 128 bits. Comments and suggestions are welcome. Would it be valuable to also add SHA-512? We actually implemented all 4 bit lengths of SHA2. I think that's overkill. But 512 might be valuable. -David Reid From loa@pi.nu Wed Nov 20 06:19:55 2013 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 996531ADFC3 for ; Wed, 20 Nov 2013 06:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525] 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 swY0LgvwIUnT for ; Wed, 20 Nov 2013 06:19:53 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 08DA01ADFCC for ; Wed, 20 Nov 2013 06:19:51 -0800 (PST) Received: from [172.20.9.41] (unknown [72.29.212.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 38B351802039; Wed, 20 Nov 2013 15:19:43 +0100 (CET) Message-ID: <528CC502.5000707@pi.nu> Date: Wed, 20 Nov 2013 09:19:46 -0500 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: opsawg@ietf.org Content-Type: multipart/mixed; boundary="------------040306080909010203080707" Cc: Lou Berger Subject: [OPSAWG] Non Working Group Forming BoF on scaling MPLS VPN's in London 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, 20 Nov 2013 14:19:55 -0000 This is a multi-part message in MIME format. --------------040306080909010203080707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Groups, We will run a non-Working Group forming BoF in London to discuss issues around Scaling of MPLS VPNs. Lou Berger and I have accepted to chair this BoF, Vero Zheng will take on the role as list admin and secretary. We plan to kick-off the discussion on a problem statement as soon as we have enough participants on the mailing list. We gave a heads up for this BoF in Vancouver - these slides were presented in the RTG Area Open Meeting. There have been some comments and they will be update during the BoF preparation. http://www.ietf.org/proceedings/88/slides/slides-88-rtgarea-5.pptx We have started to prepare the BoF, and the discussion on how we set it up will take place on a new mailing list: scale@ietf.org Please subscribe to this list through: https://www.ietf.org/mailman/listinfo/scale /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --------------040306080909010203080707 Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="non-wg-forming-bof-pa3.pptx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="non-wg-forming-bof-pa3.pptx" UEsDBBQABgAIAAAAIQD7GuhqAgIAAOYRAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIo oAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADMmM9u2zAMxu8D9g6GrkOspNu6dojTQ7ud 9qfA2gdQbSbRJkuCxGTN24+2k9YpkjqdIriXALTIjz/ZMT9D44v7UiVLcF4anbFROmQJ6NwU Us8ydnvzdXDGEo9CF0IZDRlbgWcXk7dvxjcrCz6hau0zNke0nzn3+RxK4VNjQdPK1LhSIIVu xq3I/4gZ8JPh8JTnRiNoHGClwSbjK5iKhcLkyz1dbkh+W5ix5LJJrHplTJaVQL3Ad9Y4UP5J jbBWyVwgrfOlLp6QDdZUKVXWOX4urX9HCXs6VCv7G6zrftLtdLKA5Fo4/CFKyuLWIrcOPNXV uenzSjtQzXQqcyhMviipJG2LlWorTEsh9WYT+2C8oovfhUd69O1gdGyylvZBTGuaOBwvITjp neB97wQfeif42DvBae8En3onOOuFQBsEv5lRreDos6Gl3cU0Jys0C9xQbYVH59pS7yKraq+d sT6Gt9TCXQRLCX+jEDwIdxEgfX9A8xv+MGqZzo7iTsEvXCk4+q5b0ge9q9/Eiv4s6ze2CeK4 aKP9v0xxfDWMKY7ThjHF8d4wpjhuHMYUx5/DmOI4dhhTHA8PYzp/hUyj4WuE6nOSt1w1fHgf 5qqPHcNHc2dHyqy/LnhuHLy83eYQoaoeWBICh/J5z37oSNLB+4PqfKKAYkdvXp/STP4BAAD/ /wMAUEsDBBQABgAIAAAAIQBo+HShAwEAAOICAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArJLbSgMxEIbvBd8hzH032yoi0mxvROidyPoAYzK7 G90cSKbSvr2h4GFhLYK9zMw/H98kWW/2bhTvlLINXsGyqkGQ18FY3yt4bh8WtyAyozc4Bk8K DpRh01xerJ9oRC5DebAxi0LxWcHAHO+kzHogh7kKkXzpdCE55HJMvYyo37AnuarrG5l+MqCZ MMXWKEhbcwWiPUT6H1s6YjTIKHVItIipTCe2ZRfRYuqJFZigH0s5HxNVIYOcF1qdV4iHnXvx aMcZla9e9Rqp/01o+Xeh0HVW033QO0ee57ymiW+nGFnGRLkUj+lTN3R9TiHaM3lD5vSjYYyf RnLyM5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGUzLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4Rc FPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCX I+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/ 2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQA BgAIAAAAIQBjXCO0wAAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJl bHOMz71qwzAQB/A90HcQt1eyO4QQLGUpBUOnkD7AIZ1tUVsSOrnEbx+NMXTIeF+/P9dd7sss /iizj0FDKxsQFGx0Powafm5f7ycQXDA4nGMgDRsxXMzbobvSjKUe8eQTi6oE1jCVks5KsZ1o QZYxUaiTIeYFSy3zqBLaXxxJfTTNUeVnA8zOFL3TkHvXgrhtiV6x4zB4S5/RrguF8k+E4tk7 +sYtrqWymEcqGqR87u+WWlkjQJlO7d41DwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey9AAAA NwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc4zPvQrCMBAH8F3wHcLt JtVBRJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2EtKxDkTbDOdxrut9Nq B4IzeotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKGNGIuZepURPPAjtSm qrYqfRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIGKb/7s6WNLBGg mlrN3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGUyLnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4Rc FPv2ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCX I+5dZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/ 2KFtnaFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQA BgAIAAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJl bHOMz70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMgXpTY Ba9hLSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE 8mXShjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiF Zy4spo6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey9AAAANwEA ACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNi54bWwucmVsc4zPvQrCMBAH8F3wHcLtJtVB RJq6iCA4iT7AkVzbYJuEXBT79ma04OB4X78/Vx/e4yBelNgFr2EtKxDkTbDOdxrut9NqB4Iz eotD8KRhIoZDs1zUVxowlyPuXWRRFM8a+pzjXik2PY3IMkTyZdKGNGIuZepURPPAjtSmqrYq fRvQzExxthrS2a5B3KZI/9ihbZ2hYzDPkXz+EaF4cJYuOIVnLiymjrIGKb/7s6WNLBGgmlrN 3m0+AAAA//8DAFBLAwQUAAYACAAAACEAS/U97L0AAAA3AQAAIAAAAHBwdC9zbGlkZXMvX3Jl bHMvc2xpZGU3LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0m1UFEmrqIIDiJPsCRXNtgm4RcFPv2 ZrTg4Hhfvz9XH97jIF6U2AWvYS0rEORNsM53Gu6302oHgjN6i0PwpGEihkOzXNRXGjCXI+5d ZFEUzxr6nONeKTY9jcgyRPJl0oY0Yi5l6lRE88CO1Kaqtip9G9DMTHG2GtLZrkHcpkj/2KFt naFjMM+RfP4RoXhwli44hWcuLKaOsgYpv/uzpY0sEaCaWs3ebT4AAAD//wMAUEsDBBQABgAI AAAAIQBL9T3svQAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTgueG1sLnJlbHOM z70KwjAQB/Bd8B3C7SbVQUSauoggOIk+wJFc22CbhFwU+/ZmtODgeF+/P1cf3uMgXpTYBa9h LSsQ5E2wznca7rfTageCM3qLQ/CkYSKGQ7Nc1FcaMJcj7l1kURTPGvqc414pNj2NyDJE8mXS hjRiLmXqVETzwI7Upqq2Kn0b0MxMcbYa0tmuQdymSP/YoW2doWMwz5F8/hGheHCWLjiFZy4s po6yBim/+7OljSwRoJpazd5tPgAAAP//AwBQSwMEFAAGAAgAAAAhAL3njJtYAQAArQgAAB8A CAFwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvJbNasMwEITvhb6D0b2R7fy2RMmlFHIolDZ9 ANVe/1BbMtImbd6+IinGNmHJQfio8Wr0aQYbr7e/dRUcwdhSK8GiScgCUIlOS5UL9rl/eVix wKJUqay0AsFOYNl2c3+3fodKottki7KxgXNRVrACsXni3CYF1NJOdAPKPcm0qSW6pcl5I5Nv mQOPw3DBTdeDbXqewS4VzOxSd/7+1MAt3jrLygSedXKoQeGVI7ityhScoTQ5oGDn5b+6nDg3 xq9DRFOfFMcSft6MdlduSVqJovAKQUQRUxDLkSAWZB+xT4rGgB300UoUhVcIIoqIjMI7xKu0 CGaAchF7EyTWYqRs5mQ2XsMp3FdQH3AYT08eTJERzUeKaEZG5JUC5VcFH3iqoPMudUSSJPRJ ojSCHVbVEXsTZE2zkWqaUhCPI0GsyIa8RoFub4fivLyIbR2895Ox+QMAAP//AwBQSwMEFAAG AAgAAAAhACeNwZJqAwAAYREAABQAAABwcHQvcHJlc2VudGF0aW9uLnhtbOyYXWvjOBSG7xf2 PxjdDqm/PxLqDM52vCx0IEy6P0Cx5cSMbBlJ6aRd9r/vkawkSlPCwPZqyFVlvee8lh5ZkU7v P+876jwTLlrW58i/85BD+orVbb/J0d9P5SRDjpC4rzFlPcnRCxHo8/z33+6H2cCJIL3EElId sOnFDOdoK+Uwc11RbUmHxR0bSA9aw3iHJTzyjVtz/APsO+oGnpe4HW57ZPL5z+Szpmkr8sCq XQevH004oXocYtsO4uA2/IybPYvzIQn8TFa7tSCyZL0UQAfNYdqC1l+xkIT/VT8K+abHaesc BX6URlmYRMCOz1QPKD5y5/fue+k9k0Rc67NMPOPyXs4WVont5PVey+swovfzYJzn7XFqaWrN KVAOZ3Jmy+GlbBOJLuRpYMnxpRxacnJpPrXk9DLbs+TsUvYteXpaLBvC6tWp9jma+lHkeWBX veQoyeJMP8iXAfaHqDghfbQ3c9frZNKOkSrt4KGjatLgHZVPZC9X8oWS+T1WfcslN61vS+5Q rLZkTSYPX/To7BD6TP0BYjDdwC6mMBNJcwSvauDLLXTnGguCVKwYqgVpTGtZSecZ69jR80wt GnklzqhmeN8JVz8gsH/GtzDa1mVLqX5Q24/8QfnoIffjp/cmSu3gXmNscAUonzhZ7yBTOl9X yBlaWW1L3LUU6IURUNxiDnvTDAnPCLZyP3X9hOBRqIQlFLzF9G3yyPKbYukeYRqugeLaYf6Y oyhO1fRulD+IskJrKIcnyuPOuFH+KMoKraEcnSj7YeonN8wfh1mxNZhjC3MGZ94N88dhVmwN 5uSEOQiyRB+tR8yQ9YTXq9fT78kBPMGP/YJ/V9c5R0/MPIIEN6EN3EyXu76S43Xv14SoyBmI qQUxjcLz8+0G8QpERc5AzE4QFcHz4+sG8QpERc5AnFoQkzg9P5xuEK9AVOR0uXJZRwwzaJsC BlrOjrc5+udLWZSLIAwnXhKWkyhYxJMMLgST6UMZlrG/KHyv+FcVu36syp4/d21NwORQVvvx RWHdtRVngjXyrmKdqdDdgf0gfGCtLtL9YCyrR9eNstSFFywb4y1U4ODJ+CugY0KV0IlaGRVa Uf2FCL5ZH9ekiIqw0PWjewzRLe379hXBwRSO4v9hqtsWDo0coB7+Hrrs/yjM/wMAAP//AwBQ SwMEFAAGAAgAAAAhAJcFZXspAwAA/AwAABUAAABwcHQvc2xpZGVzL3NsaWRlMi54bWzcV0tP GzEQvlfqf7B8ag+wIQ8IEQHxaKtKASIS2rPxTrIWXtuynZDw6zv2bhICKV0JRZF6Wb/GM983 Ho9nT85muSRTsE5o1aUH+zVKQHGdCjXu0vvh9702Jc4zlTKpFXTpHBw9O/386cR0nEwJ7lau w7o08950ksTxDHLm9rUBhWsjbXPmcWjHSWrZE2rNZVKv1Q6TnAlFy/22yn49GgkOV5pPclC+ UGJBMo/IXSaMW2gzVbQZCw7VxN1rkE6RGR/INLTODC1A6KnpD2sGpm/j8s20b4lI0V+UKJaj W2hSLpRicaimsZO82j5edFlnNrJ5aJEbmXUpOn8evkmYg5knvJjkq1me3W6Q5dm3DdLJwkDy wmhgVYDbQKfdbDQWlO6A47mPJZD6kt0CtzM9zR8dURp5FW7QlxlKw7m1+ikDlrowXbBfbixc ElqTET83aMULL6GUKxZjZ4W19KWfXeh0Hmw/YBsnWUc6P/BzCXFg4geZAOupC/sYYQVMGHT9 ieK+BMQ6kYJFSclClIPa+3FBSSqsj54jLveXEphautef/nRuAo7gPSCXWnGwygX3+ujkqA9U 2meW3b1W6567tN6s1d4xkETwyYpksjik94+q+faoGls8quB4isZnK/G/nNiG0G62jurBCeiA g1brqNFor0d5u14/PgwCIXqbrXrr+DCG3csYLlRvOxbuB5Q8xA3vRsTvjPnoGKJHxHEmUTVh Ng6F8oD5xZ+txUhxzC/AyamMdrYHciCeI6Bf/Zv1eN2Mpb5NLDeT/AEseXVtKqkrNQRHCw// BxN8gEZitnsyMUQ+RiWfSC84c3gf8LncOSP6ATZXIhQ7HHAd/BOAKiKOfIkc984HXyuk/Qo4 d5ALyqitlA22nDZDmvQZEAtMLnOn0Zg2qwTPVr103e8NiDPABVabuwaDB1URyz8xfChO35Ym sSmK41A1lPUyl/aamdtpJIyFN76Cl3HKIJ6ywFiJoFKR40LsqZ7zsdpgRaEzVIsCO53g74FQ KaZLhXeRkvCyMovUFOCPS6hnUhgWxWR+p7Uva5OoKSAvVIdeaS6AR8B/AAAA//8DAFBLAwQU AAYACAAAACEAozmHDMIDAAArDgAAFQAAAHBwdC9zbGlkZXMvc2xpZGUzLnhtbMxX724bNwz/ PmDvINznXc6J3dQx6hSxkxQF3NSI032XT7RPiP5Bki/2hgF7jb5en2SU7s5eEiOLUycYYFgU RZE/kpKO/PBxKQUpwTquVT85PGglBFSuGVfzfvLt5jLtJsR5qhgVWkE/WYFLPp7++ssH03OC EdytXI/2k8J708sylxcgqTvQBhSuzbSV1OPUzjNm6R1qlSI7arWOM0m5Sur99jn79WzGczjX +UKC8pUSC4J6RO4KblyjzTxHm7HgUE3cfQ/SKXqWTwQLozM3FiBQqvxkzcSMbVy+KseWcIbx SoiiEsOSZPVCLRanqoxE9mD7vCFpbzmzMozoG1n2Ewz+KvxngQdLT/KKmW+4efF1i2xeXGyR zhoD2b+MBq8qcFvc6Xba7cala8gx73MB5GjtXYPbmZHObx1RGv2qwqCHBUrDmbX6rgDKXGBX 3q83ViEJoymIXxm04rkXUMtVi5HYYK1j6ZcDzVbB9hTHyKQ94fzErwTEiYl/6AnQkRrY2wgr YMJDN16o3NeAaC+6YFFS0HDKQaWfBgmZxg2MWx/jR5z0QwFUrYPsT88tnXlHqLDo4IoY7Tyw 9HMItI/hjppBsTG19PqhAfdHPznqtFr/aSqLzmQbp7MmaU+nrvM4de1XSR1ny43ILlkjaiGH WqwzsT2BktpRjAtXDO9oJJ9KatS/uML3qQ5e5enjNH+b7JCFkNMr7YH4gjuCP4qKVpKqH39/ x4kxVi+5jA/Ib8RpCUTyeeERXQlkCqBw7hwwon0BllDGkJ6uAtfTWyDPODUB7wOU6+Pxcwd+ i+Zt/g+HZ1/G+wMqypj6VwTMwg1NHyB+njawNnK2aJ0BW92+SOkWZXtHl+dUmv8tuoXie8OG n0RQoVJx91S+4YUYtX8fXz1t/KWH3JXp5GKHQz53aWlU6nIqUPXrYNr14i0XqWgHVCXKLqhI 3WKqwL8luHt4LKg74DWmKZ+ngk5BvOxB2/6V3uXUvcXLuS9n9vQN/ik4jyugODQ1Ob4GI+dr iiws7yd/DgYnx0fD7iAdHHYu0875yfv07PL4XXr5rt3pDAfds2H74q9Q4x92ejlWceHr/blp Y5D5qHWQPLfa6Zk/yLWse5DM6DuwRvPYhhy26l6mpCFHre7JyftW6yhWXlnE1owRbSiq6vYi F/YLNV/LGCk05sEOI8tgZOv6ayOCweASFyKlas8NrerAG9X0I2yBT3FI2owr7iEh2Oh4ajFJ CrDPC+Ueg5uq9pbXWvsaZ9QUIl6pDlRtLgQdAf8DAAD//wMAUEsDBBQABgAIAAAAIQAFcQy/ HQMAAB8JAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTQueG1szFbfT9swEH6ftP/ByntIf8FKRUG0 UITEoIKyd2NfGwvHtmwTWqb97zs7CS1QNh4mjZfYsX1333138ZeDo2UhSQnWCa2GSXunlRBQ THOhFsPkdjZJ+wlxnipOpVYwTFbgkqPDr18OzMBJTtBauQEdJrn3ZpBljuVQULejDSjcm2tb UI+vdpFxSx/RayGzTqu1lxVUqKS2tx+x1/O5YHCi2UMByldOLEjqEbnLhXGNN/MRb8aCQzfR +gWkQ8yM3UgeRmdmFiDMVHlmzY2Z2rh9WU4tERz5SoiiBdKSZPVGfSy+qjJOslfmi2ZKB8u5 LcKIuZHlMEHyV+GZhTVYesKqRbZeZfnVlrMsP91yOmsCZBtBQ1YVuC3p9HvdbpPSNTCs+0IC 6Txn1+B25kKze0eUxrwqGvQ4x9NwbK1+zIFyF5ar7J8NK0rCaHLiVwajeOEl1OeqzThZY625 9MuR5qsQ+w7HuEgH0vkbv5IQX0x8YCZAL9TI3kdYARM23fRBMV8DooOYgsWTkoYuB5WejRJy Fw24sD7yR1zhxxKoeibZH55YOveOUGkxwRUx2nngJCXn54FrHxmPzkHxKbX0+nUM9zRMOr1W 66/RsphPts47a+r2fvWeKzfWymNvk6mkDHItOdiP1PBPxRJ8uT7y/+p0e/OGubo0F50f08sX Vago3IgnSxlN/03cbf3BQ3+kT8FpKjulUSmEhwOJ35IoIS0Ydf5zoHR8E6JGCZB09TmgWXpH OVWb+PC6notlSjni9MJBkIDPATanehNokasP3AXb+/i9jz4OjRKhLFw4X8/IgxXD5OdotL/X GfdH6ajdm6S9k/1v6fFkbzed7HZ7vfGofzzunv4KytbuDRjeXUH0zhvxxsU3glkIZrXTc7/D dFErb2b0I1ijRRTfdqtW8JIiz/udvV67v/+tviAQWTNGrOFaqSWVSfudmqsyUoOhPNhxXDJY mPoGWh9BKkSBG3Gm6rwNrS6+mWo0mD/gH4RQHHtECQ8JQXH31GKNFWDDBHXiMKv0prjW2tc4 o6fAd+U6zOpwgXIE/BsAAP//AwBQSwMEFAAGAAgAAAAhABz052DHAgAARAoAABUAAABwcHQv c2xpZGVzL3NsaWRlMS54bWzMVttu2zAMfR+wfxD8vNRZixWZ0bRYuqYYkLZGk11eFYmJjcqS ICmp3af9w/5wXzJKdpKtM9b0EmAvupKHhxRJ6OikLARZgrG5kv3o7V43IiCZ4rmc96PPk2Gn FxHrqORUKAn9qAIbnRy/fnWkEys4QW1pE9qPMud0EseWZVBQu6c0SLybKVNQh1szj7mht4ha iHi/2z2MC5rLqNE32+ir2Sxn8FGxRQHS1SAGBHXI3Ga5tis0vQ2aNmARJmj/QekYPWNjwf1s 9cQA+JVcnhs91qkJ15fL1JCcY7wiImmBYYni5qIRC1u5DIv4nvp8taRJOTOFn9E3UvYjDH7l x9ifQekIqw/Z5pRlVy2yLDtrkY5XBuLfjHqvanIt7hwe9N6tXLoGhu8+F0D2196teFs9UuzG EqnQrzoM6jRDafhgjLrNgHLrj2vv14p1SPysM+IqjVaYM5PcCWhE6/uw2NBtwunKgeKVNz/F ORzSRFg3dpWAsNFhQGeAjuTA3ARmnhbmXbqQzDWcaBK8MCgpqE90kJ3zQUR4blwIHrGFOxVA 5TrC7njMqEAcombER9aF+NY4jwe7SEdj8iW9tI+DqrXrpw2i04cV4rVUq6i960f7vW73AcKp UVpZ4ORSyc5XZW58KM6NWmgyxLLyu61caTMHxoSXajE7UMN7sCB5Sg29foIfcciQeJNJ8aoY /l0Sh3+XxMEOS8IupnVJIIFyo/Ifl8ans8nwBYqi9/75GC9A4+f3Hy+AMlKSK7ll8j6Qss9/ vkeW3bey3EU1c1o9GbYF7s1OWk5VJXd3HYqlNN196wlT/cnwXaH5dzBhLqi+Wgar+IFxYE7D kcbnbhrIRgRBc9+Aw0qOrAvdhNaNbCJXHxW+QJdzyWGWy9xhd8EfkKMGM0cCfgB9v+IwCR3I FddKuabvBCTPvIb2q8acJ4+EfwEAAP//AwBQSwMEFAAGAAgAAAAhAI0XX2lrAwAAMg4AABUA AABwcHQvc2xpZGVzL3NsaWRlNS54bWzsV99v2zYQfh+w/4HQuyL/SpoYdYrYSYoAaWPE6fZM k2eLCEUSJO3YHfa/70hJdutprZB56x72IlLk8e77vqOEu7fvNoUka7BOaDVKuiedhIBimgu1 HCWfnm7T84Q4TxWnUisYJVtwybvLn396a4ZOcoKnlRvSUZJ7b4ZZ5lgOBXUn2oDCvYW2BfX4 apcZt/QFvRYy63U6Z1lBhUqq87bNeb1YCAbXmq0KUL50YkFSj8hdLoyrvZk23owFh27i6a8g XSIzNpM8jM48WYAwU+v31szM1Mbtj+upJYKjXglRtEBZkqzaqMziq1rHSXZwfFlP6XCzsEUY kRvZjBIUfxueWViDjSesXGT7VZY/NNiy/KbBOqsDZF8EDaxKcA10zgf9fk3pERjmfSmB9Hbs atzO3Gv27IjSyKuUQU9ytIYra/VLDpS7sFyy3x0sJQmjyYnfGozihZdQ2ZWbcbLHWmnpN2PN tyH2HMe4SIfS+ZnfSogvJj6QCdB7NbbPEVbAhJduulLMV4DoMFKwaClpuOWg0vfjhMzjAS6s j/oRV/iJBKp2IvvLa0sX3hEqLRLcEqOdB05Scnd3F8T2UfLoHRSfUksfD4O4z6OkN+h0vhsu i4SyPfGsTtxfp2+XuolWHi83mUrKINeSg22TxG9lS/DN3uTHJerTrFWiPkzvZy0y0uBtJ/0X OOVaRqN/Di8PFys9QNzOG1gbVxq8WlAvIF7ltcHb0eEVRrqjgZuLZSrpHORXHn9YKqX4b8tV wJL+r1d7vaJUKRZC7Dnlwnkr5qtQOvyb6h1TsL+pUS3LUuo5lZU6R8CzcsCog0NMr/x3HyBw 63R20yrdH3956LfKbFPymsNUnsn3mLUDeRya019vjk2zKcwrOX+jCIpDXZpjnXzvfDUjKytG yW/j8cVZb3I+TsfdwW06uL54k17dnp2mt6f9wWAyPr+a9G9+D6V+dzBkWMyFT/mu7mZw8U8d RCGY1U4v/AnTRdWKZEa/gDVaxG6k26lamjVFzXoX3cFZ903ndFCVTIitHiPaUGhVXQaT9gM1 D+soDgbzYCdxyeB/oqrJ9iYohihwI85UxdzQshR8UnVbwlf4XQnFYSGU8JAQ7Hc8tfjLUYDt XijYOTyVJXjxqLWvcEZPQfHSdZhV4YLoCPgPAAAA//8DAFBLAwQUAAYACAAAACEA4eEQdmIG AAAhFQAAFQAAAHBwdC9zbGlkZXMvc2xpZGU3LnhtbNRY62/bNhD/PmD/A6FP2wdVki0/UXew /OgKpG0Qp+tnWqIjLhSpkZTjZNj/viMp+VUncZ9AE8CkyOPx7nfHuyNf/rEpGFoTqajgIy96 EXqI8FRklN+MvA/Xc7/vIaUxzzATnIy8e6K8P179+svLcqhYhmA1V0M88nKty2EQqDQnBVYv REk4zK2ELLCGT3kTZBLfAdeCBa0w7AYFptyr18tz1ovViqZkKtKqIFw7JpIwrEFyldNSNdzK c7iVkihgY1cfiPQKNEsXLDOtKq8lIabH169luSgvpZ1+t76UiGaAl4c4LgAWL6gnajL7yde2 Exwtv2m6eLhZycK0oBvajDwA/978BmaMbDRK3WC6G03z9ydo03x2gjpoNgj2NjVaOeFOqNOP 2+1GpSuSgt1vGEGtrXaN3Kq8EOmtQlyAXg4GMcmBmoylFHc5wZkyw0777UIHiWnLHOn7EnbR VDNS07lJ29nJWmOpN4nI7s3eS2jtIB4ypRf6nhH7Udof0ITgC57IWyuWkQmc7rLiqa4FwkOr ggRKho2XE+6/TjyUUaktcohIaRerQk8YwXwLs36ViLmBVVtwHZ9nmJ1ggi4lKbEEuaAnUqLU EU/Cs0ss8dUxV/Uw8lpxGD7BP7BABDvAgsbgT5s9/tTs7e9odmNEDzbf7Mgfsf6JYxJ3ei0D AgAQdTq9drt/eGL6rdagawjMSYg7rc6ga114/zw41t/brz4sPLS0C550iDHnAjgRpHOCnvWv U0y/0mXPlBNhBShIdo8UKoVSdMnIEe/lFzEPtgtPrt75/RlC/gahndGCcizvUU4kQZSjvzAk tQry3O8H8rrT8kNsfEX+qYgCBxVcS7qsbNr6IcI84RsLXaW3hJwTf86z4o9CM6koVB/jG5AU f0vhPy9wfmauPDtUNgFxPw6i5d1bkcFeuNLCO7d4GEQxnJttKLRxcz8SgtJS6ddEFMh0Rp4E TSx3vL5QusalJjHDXMwpYy5K8oOBoBkhqxUwcautJNBtZKokHXn/DsLBrD/rx37c6s78OJxO /fF8EvvdedTrTNvTyWQa/WekiOJhTrOMcLNHU2xG8ScFXkFTKZRY6RepKOpKsSk4obaLwqa2 A3MIRjPDzn6Y9WTCJFpjBtCmKdSEzigHlMGhJHYa1DnSKoIYlbQG/rzb7/nxPO74g17Y98No kEA+igfxdH6o1QXl5Ou1QndgZ8hyz6qnNydUw8OCagJnhRaQOUPz51zIuOiMZ+7AYcpcfw8J I/1pJMbzTtiL232/1+u0/bg9C/2kP5/440nU7fZmySSZHdl3Zn1GfRsTbx3Qno4KtFvk2R0c fePg7c6g5eIA5JSe0xdhdgNxINXSQ1Loj1TnixybOiV0oB7iuLxpyoktc4fDbt89mGrVdki5 1pE9XoiYSxmImwv5ABaWGOotDjcwD7E3XNUH20PaftiDDaLvzyz3Z3hVTASzARASIfCslXUf Ey3dxUEUJdYXfFGmhrSJDtebj1iWdXzQIPo7YdE5FSYcrQt7YwhUc1pPOqUeL64KLC+sENC5 sh22ZralHEDUtuvMxMB6ZHWNl4uHJsCB7tpRb1MO9FeQasd2yRIrgxzc9vhu+jAjOUszo7wT P71MtbN3tD0VNsbtKBKyOqZtyA5mxyvrio/Q1bPLChzsemNhWVaLh213DmpsP96BD9RHcrlD 3iG7zaa3VUEL8Td1ONokqNb+YuYqKaOOTYcGXPtbNb6loDS5JeZrYXvgEzvH4+b6zOgD+dMu Mpgyat4EjpLpU7nhC8LTYTqxNrSXiBVOYe+xpJihD5ymkBzRW8jzJeZCGalaYRJC2IW2+YdL Tkl1ms9xQRkkRHPrSXMsFQEH8KOWvUeYOsLhqV9NiaKSZAjOORwOopBYIYyeqKifRr7/0wK/ D8rxDWWv4HrG8X5e/R9xvC/3tub878B7vAS1TfMS1aQO26vzbQL1RWvST/wkiud+PB30oJ7q dvx5px3Hk6Q/nrRnJt+WkJRSSeyj15vm8a48N9mW4o7IUlD7+LYtPlyEjKJBvw3q2zeDwMrW tE2iax7VUibf4vL92voObAYZdGKHSpPJHemOBMAwd7kb2+O15iV2hfg1b17hsgpSmMkUK8qh nIF8AHctbBIoJ5BIjQ9l5Nq9OBVXQuhaTsvJIO5Ym169nQEdBP4fAAD//wMAUEsDBBQABgAI AAAAIQAPi9zfPQYAAEEWAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTgueG1s7Fjdb9s2EH8fsP+B 0NP2oEqy5U/ULSzZ7gqkbRCn6DMtUREXidRIynEy7H/fkZT8kTiJ2zXYCiwBTIo8Hu9+d8c7 8vXbTVmgNRGScjZxgle+gwhLeErZ1cT5fLlwhw6SCrMUF5yRiXNLpPP2zc8/va7GskgRrGZy jCdOrlQ19jyZ5KTE8hWvCIO5jIsSK/gUV14q8A1wLQuv4/t9r8SUOc16ccp6nmU0ITOe1CVh yjIRpMAKJJc5rWTLrTqFWyWIBDZm9YFIb0CzZFmkupXVpSBE99j6naiW1bkw0x/X5wLRFPBy EMMlwOJ4zURDZj7Z2nS8e8uv2i4ebzJR6hZ0Q5uJA+Df6l9Pj5GNQokdTHajSf7pCG2Sz49Q e+0G3t6mWisr3BF1hmG326p0QRKw+1VBUGerXSu3rM54ci0R46CXhYHHOVCTqRD8Jic4lXrY ar9daCHRbZUjdVvBLoqqgjR0dtJ0drI2WKpNxNNbvfcKWjOIx4VUS3VbEPNRmR/QhOAzFolr I5aWCZzuvGaJagTCY6OCAMoCay8nzH0XOSilQhnkEBHCLJaliguC2RZm9SbiCw2rMuBaPs8w O8IETa8IBBT6hdeqoIz8eo8lTJ5jgS/uM5V3E6cT+v4T7D2Dg7fDy2vt/bTVw4dW776g1bUN Hdh8syN/xPhHoiTsDToaBAAg6PUG3e7wMGCGnc6orwl0IIS9Tm/UNx68Hw6W9Uu71eelg1Zm wZP+cL53FqHgwBmsPfekKNaFYfhy0sQFFjS7BYboj5pIc7ye4KAncH+gzHdS4ol4Pd8h+2zc nogP6vznLfRSQD/nu93/kdnJMqMyqaWuq/4tCZZ1WWJx+z2D9+syy1fWEifnkjZj7CcKtLr5 wFPYC9eKO6cWV6MghIS6zRUmseynClBaSPWO8BLpzsQRoInhjtdnUjW4NCR6mPEFLQqbRtjB gNeOkCwDJna1kQS6rUy1oBPnz5E/mg/nw9ANO/25G/qzmTtdxKHbXwSD3qw7i+NZ8JeWIgjH OU1TwvQebTEehA8K4JImgkueqVcJL5tKui3IofYN/Lb2BXPwgqaanfnQ60lcCLTGELs4SSDW rVEOKL1DScw0qHNPqwCKl6gzchf94cANF2HPHQ38oesHowgSdjgKZ4tDrc6gOPrnWqEbsDOU Ac+qpzZHVMPjkioCsUJLKC18/WddSLvonKU21jAtbH8PCS39cSSmi54/CLtDdzDodd2wO/fd aLiI3Wkc9PuDeRRH83v2nRufkd/HxFsHNNFRg3bLPL2B0NcO3u2NOvYcgGJzYPVFuLiCcyBR wkGCqy9U5csc60LOt6Ae4ri6auutLXOLw27fPZga1XZI2daSPV6p6UsriJtzcQcWFhgKUgY3 VAcV75lsAttBynyYwAbR92dW+zOsLmNukxNmCfBslLUfsRL2YsXLCqsztqwSTdqeDpebL1hU zfmgQPSP3KBz7JiwtPbYm8JBtaDNpFXq8eoTDvIzIwR0LkzHZFNoKQMQlelaMxVgPZJd4tXy rj3gQHdlqbfZBvoZZ2pqlqyw1MhBFme76cNkZC1daOWt+Ml5oqy9g21UmDNuRxGR7D5tS3Yw O82MKz5C18yuanCwy42BZVUv77bdBaix/fgIPtCE5GqHvEV2m0iv65KW/HdqcTRJUK7d5dxe sbQ6Jh1qcM1v3fqWVIJeE/21ND3wiZ3jMf28UNA78ptZpDHVt7sHyfSp3PANx9NhOjE2NLes DCew91RQXKDPjCaQHNEHyPMVZlxqqTp+5MOxC237D7fAiqokX+CSFpAQ9bUwybGQBBzADTrm oqXrCIsn1DhEUkFSBHEOwUEk4hnC6IlL8tPID39Y4PdBQY8XXM843o+r/yOO9+3e1sb/DrzH S1DTtC91beowvSbfRlBfdOJh5EZBuHDD2WgA9VS/5y563TCMo+E07s51vq0gKSWCmMvM+/Zx szo12Vb8hoiKU/M4uS0+7Ak57A38sNtrHiKMbG3bJrr20TEpxAdcfVob34HNIIPGZqjSmdyS 7kgADFrChOmxRvMK20L8krWvlGkNKUxniowyKGcgH8DtCOsEyggkUu1DKbm0L3LlBeeqkdNw 0ohb1rrXbKdBB4H/BgAA//8DAFBLAwQUAAYACAAAACEAuyI0EDcGAACzEwAAFQAAAHBwdC9z bGlkZXMvc2xpZGU2LnhtbNRY227bOBB9X2D/gdC7YsmSr6hbWLLVLZC2QZyizzRFR9xIpEDS l2Sx/75DUvIlTVK33XaxCWBS5JCcOTOcM9KrN7uqRBsqFRN84oUXgYcoJyJn/HbifbrJ/KGH lMY8x6XgdOLdU+W9ef37b6/qsSpzBKu5GuOJV2hdjzsdRQpaYXUhasphbiVkhTU8yttOLvEW dq3KTjcI+p0KM+416+U568VqxQidCbKuKNduE0lLrEFzVbBatbvV5+xWS6pgG7v6RKXXYBlZ lLlpVX0jKTU9vnkr60V9Je30h82VRCwHvDzEcQWweJ1mohGzj3xjO51Hy2/bLh7vVrIyLdiG dhMPwL83vx0zRncaETdIDqOk+PiELCnmT0h32gM6R4caq5xyT5gzjKOoNemaEvD7bUlRd29d q7eqLwW5U4gLsMvBINICpOlUSrEtKM6VGXbW7xc6SExbF0jf13CKZrqkjZybtJ2Drg2WepeI /N6cvYTWDuJxqfRC35fUPtT2Byyh+JIn8s6qZXSCoLtac6IbhfDYmiBBssQmyin33yYeypnU FjmkKp2WFPM9vPr1jComaY7EWhNRUQOttgDbvSjPr7DE14+3VA8TrxsHwQubd6zinYOBndZB L7sp/tJN0U90kwHdg8N3B/FnvPVEWMe9QdeAAACEvd4gioanET7sdkd9I2AiN+51e6O+Dbnj +HVb/+w4+LTw0NIueDEaLpnSKJVMM4JLpOAH9kZMqTVVJ6HhvPtLdEpFVQkOmuh7tKR6SylH uqD/gXZ7hYQEGsGaIqAPdMfInQ9MIjXilFClsLxHWyHvEHOKEiElxDKqS0zoxRk37AxgfiH+ U2KoBL3TtDpF+QeV/7bU8I3Z++xk0F7545uOltv3Ioez8FoL71w6G4UxZMT9ZbeZ4fiug9FS 6bdUVMh0Jp4JCrs73lwq3eDSiJhhLjJWli4P8JOBTjtCVyvYxK22mkC31Wkt2cT7axSM5sP5 MPbjbn/ux8Fs5k+zNPb7WTjozaJZms7Cv40WYTwuWJ5Tbs5oy58w/qLkqBiRQomVvgC+aGqX tgSCaiMM2moD3CFKlpvt7INZT9NSog0uAVpCoEpxTjmR7JxqYqfBnEdWhcA+SXfkZ/3hwI+z uOePBsHQD8JRAhk3HsWz7NSqS8bpj1uFtuBnyONfNU/vnjANjyumKdwVVgE3BObPhZAJ0TnP 3YXDrHT9IySM9k8jMc16wSCOhv5g0Iv8OJoHfjLMUn+ahv3+YJ6kyfyRf+c2ZtS/4+J9ANrb sQbrFkW+hatvAjzqjbouD0C1MHD2IlzeQh4gWnpICv2Z6WJRYMPEgQP1FMflbUuY+80dDodz j2BqTDsg5Von9jzVmtcEULcQ8gE8LDFUFBzeCTxUvuOqudge0vbBXmxQ/XhmeTzD11UqSpsA MSewZ2Ose0i1dKWsqGqsL/miJka0zQ43u89Y1k1+0KD6B2HReSpNOFmX9qaQqDLWTDqjni8f KiwvrRLQubadclPalnEAUduuc1MJ3qOrG7xcPLQJDmzXTnpPOdBfCa6ndskSK4McvH/ww/Qp IzlPl8Z4pz65Anq0/g73t8LmuINEQlePZVuxk9npyobiM3LN7HINAXazs7As14uHfTcDM/YP HyAGmiu5PCDvkN2z6d26YpX4kzkcLQmqjb+YuxrZmGPp0IBrf9dtbCkt2R01Twvbg5g4BB43 L3Qle6B/2EUGU6h17CU5IdOXuOE70tMpnVgf2jJ5BYXLxJtKBkXhJ87gLZqi98DzNeZCGa26 QRJA2oW2/YcyvmaaFBmuWAmEaOp6UmCpKASAH3ZtpWzqCIfnFy8iCokVwigR2aOa40zkh/9b 4I9BQc8XXF8JvP+v/c8E3vdHW3v/D+A9X4Lapv020lKH7TV8m0B90U2HiZ+EcebHs9EA6ql+ z896URynyXCaRnPDtzWQEpHUfoZ5135Oqs8l21psqawFs5+D9sWHRTCK4iiMokGTJa1ubdsS XfuZh5TyPa4/bmzswGHAoKkdqg2TO9GDCIDBKpiwPd5YXmNXiN/w9rtQvgYKM0yxYhzKGeAD at9+IIQoEKmJoZzeuG8g1bUQutHT7mQQd1ubXnOcAR0U/gcAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG8AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0MTEu eG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyz f02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul 2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE 4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwA AAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnhtbC5yZWxz jM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8 hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmX SRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qF xdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwA AABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Mi54bWwucmVsc4zPvQrCMBAH 8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd 7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlX Ec0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/ tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDMueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Sat g4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYE Z/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66ra qPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U 7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALQAAAHBwdC9zbGlkZUxheW91 dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHB RfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnD mxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPF yWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD/ /wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDkueG1sLnJlbHOMz70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbb JOSi6Nub0YKD4339/lyzf02jeFJiF7yGWlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0Vxo xFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJF9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+ I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQU AAYACAAAACEA1dGS8bwAAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVM YXlvdXQ4LnhtbC5yZWxzjM+9CsIwEAfwXfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GC g+N9/f5cs39No3hSYhe8hlpWIMibYJ3vNdyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVR PGsYco47pdgMNCHLEMmXSRfShLmUqVcRzR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YO wTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAh ANXRkvG8AAAANwEAACwAAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54 bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2DiDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/ TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XY DDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti 0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs3fYDAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvAAA ADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDYueG1sLnJlbHOM z70KwjAQB/Bd8B3C7Satg4g0dRHBwUX0AY7k2gbbJOSi6Nub0YKD4339/lyzf02jeFJiF7yG WlYgyJtgne813K7H1RYEZ/QWx+BJw5sY9u1y0VxoxFyOeHCRRVE8axhyjjul2Aw0IcsQyZdJ F9KEuZSpVxHNHXtS66raqPRtQDszxclqSCdbg7i+I/1jh65zhg7BPCby+UeE4tFZOiNnSoXF 1FPWIOV3f7ZUyxIBqm3U7N32AwAA//8DAFBLAwQUAAYACAAAACEA1dGS8bwAAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzjM+9CsIwEAfw XfAdwu0mrYOINHURwcFF9AGO5NoG2yTkoujbm9GCg+N9/f5cs39No3hSYhe8hlpWIMibYJ3v Ndyux9UWBGf0FsfgScObGPbtctFcaMRcjnhwkUVRPGsYco47pdgMNCHLEMmXSRfShLmUqVcR zR17Uuuq2qj0bUA7M8XJakgnW4O4viP9Y4euc4YOwTwm8vlHhOLRWTojZ0qFxdRT1iDld3+2 VMsSAapt1Ozd9gMAAP//AwBQSwMEFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAABwcHQvc2xp ZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54bWwucmVsc4zPvQrCMBAH8F3wHcLtJq2D iDR1EcHBRfQBjuTaBtsk5KLo25vRgoPjff3+XLN/TaN4UmIXvIZaViDIm2Cd7zXcrsfVFgRn 9BbH4EnDmxj27XLRXGjEXI54cJFFUTxrGHKOO6XYDDQhyxDJl0kX0oS5lKlXEc0de1Lrqtqo 9G1AOzPFyWpIJ1uDuL4j/WOHrnOGDsE8JvL5R4Ti0Vk6I2dKhcXUU9Yg5Xd/tlTLEgGqbdTs 3fYDAAD//wMAUEsDBBQABgAIAAAAIQAMWsfzVQcAAA44AAAhAAAAcHB0L3NsaWRlTWFzdGVy cy9zbGlkZU1hc3RlcjEueG1s7JvNcts4EoDvWzXvwOIctxSZFP/kijxly85MqpyMN/bUnCES lLgGQQaEZDlTU5V32DfY07zC7t523yRPMt0AKFF/tpzElbWlHEyw0cTPh+5GE2Je/jDNmTWh osoK3rOdFwe2RXlcJBkf9uxfrl61ItuqJOEJYQWnPfuWVvYPR9/95WV5WLHkDakkFRa0watD 0rNHUpaH7XYVj2hOqhdFSTnUpYXIiYRbMWwngtxA2zlruwcHQTsnGbfN82Kb54s0zWJ6WsTj nHKpGxGUEQnjr0ZZWdWtldu0VgpaQTPq6YUhHcH84kuW4HUw1H8vxNFLclgVLEteZYypG2ya 9pmwJoT17MHQsdtHL9tLWjRNaSzPK4l1dUuqgA1X5ZWgFEt88qMoL0ushd7fTi6ElSWwKLbF SQ7ssW1VYdTULZ+oQnvp8WFdJIfTVOR4BXTWtGfDCt/i37Ya2lRasRbGc2k8+nmNbjw6W6Pd rjtoNzrFWenBrZnOgRvUM3oHXAgfMmq5s8nVw67K8yK+rixewLQ0haI/Am16LERxM6IkqVCs Jz97UBPBazmy5G0JvchMMmr0dKUqzIcKIxvcvCkS0CVjWdhrqHl+CNahcLihF3SiRX6R63YD rEcujuN1Dg4W6ZDDUlTyR1rkFhZ6toCpq47IxFjGXAXFvEDzUZ0wbt307K7v+uqBRk2eofux LIcRHOA/PSpkc8YTVZYkY7rcxpbU3HHGOHM5PSmSW9QawBUoQCCAoY0K8cG2bgQB7NX7MRHU tthrDrS7jufBJKW6UUhsSzRrBs0aPs77BVNLR3gMrfbsWIr6pi+FtqQiL4k855dljKo1qqvp r0SUBpYEzm+LyxEp6TpmWlfd6okoapW8lLeMKgql+gMzZBM2M2ilJlBIMNoltHV6BtEul31G CZ+pyaM+y96P6QerLMbCyiE4phlipxAZoQMrGVtgYoJi/1KNAk1MddqeQ1bc73WNcNU1Oo/o GojLhr6nc/Wv4CEOuAKWN7uIB8bcDdTM9i6y6CLyGTlIpT2kUi4CQ1S+AnsxKK9xluVRKIt8 wChO6Xia/e+PnFo8m1Ay3qILte08oIsrUWTVA/tQVv6APv42JlI8sA/voQuW8ffje/p4cOyK VmOXGtcjxa4EPKX6AL5IWGpimFrOrxPDAhdiFISThRjmOp3OPIaFgev/v+7yK1nnDgU0VZ4w x1hcQtN3ME80FccDeKoaUn6u7CglMRjEX3PeYtKspX5Ao6ybwXKj+dr75u2bsWkR5ckFEQS7 bXqi0fkM1+quupYyzUdyrRTTNASGlgDGZ9xL79ef714dx/Xu9q+o6+/96wn5l0XYkOu0/pm4 WgchL7la8IiuVrHk7Thf521q7/wCbwt8v7PfzZ6ht30zX0tZorzktyB0+44XHrfOun2v5b06 7bai7onfct3o1AtPzk7ds9Pf7ZmFZwkFkmqEy8mpfvnY2KM8+vTxX99/+vjveX6a4qnc5/i9 uuizNvRJc7oXM/GGlNZg6PRsJmGh5RRKyTWUBkMXZS7KXJRBicQx5RI0TKGWuLVkptOpJZ1a 4tUSr5b4tcSvJUEtCWxrxDJ+DcaMF9tKC/aTFtQlHZUggJyT22IsXydgVEsStVwuLJUXdQIf sghxiBLxOlGx6Q7dqKFrDuc26oYNXXNasVE3aOiat4ONun5D16Q7G3W9hq6J1xt1Ow3d8B5d t6GrDv3u0HUaut17dDHuzNZCxcDNyt7CwtW7yurCy6ny5EqV8dDzju3aElK96FuUnPMTca3K acHlsVIZkApiJu5oGR9ejHksUUFvffEJTU3pIpb66LveORZqj1N5h56pbcQxr45jdx2ygy+u O2RfDX1/N6EPYgVZqqDEHGlXSxVxdUewVEV3tzAei4ww2ORGRFRUDX4dH4Ri+HT2fFb5IBTD x9vzWeWDUAwff89nlQ9CMXwC5JMTcT4/rVpDa4nQswOCFAyQcA5EpfC7CQQpGCDRHIjTCfG3 mJ0kghgMkW6DSORG0Y4SQQz6xaiRG5bqlXMlUdS0Op7bRVgZhzc4aLdVCzQ99rXDs1ufB3wW 3MG4DwAUhZ796eM/dY7XQK6OQ+5HvvYjjs2v1iv5Jd+UX/Jt80tNPwTY+J4wo+9GfoiCp0D/ Hyv0XfS7r07/3lzU+L35JqMB040aofGpmbK7XfT4UpjLiauBaX7ff5ow11gmtv74MJezXA3T PfBDlbU8QZj//c+3Yrk+I3Z9x1Po7me59Wb/LHCtz5fdbuioZGiPa5tsWic/e1xbptqdKAq2 3CV2C9csD29k3uVhIUdUzPJweOJi4fMF/SMH5a1fLueNGpXFpL0JGHSuyODyw/zdeGUvcWxL jX2+tSxuJfonreavTSpkXFOBH4w/rYx68cRkl/msz5IXD1B2mc+GxHfxPGWXAa1PZpeOV3YZ 0IYMVW2Be0Cbc9LQ01+t7AFtyEJhuPsgfVfeGfjhPkgvZprN5FJ9GVN/KKC/I9D/j+/oTwAA AP//AwBQSwMEFAAGAAgAAAAhAGmiXyEVAQAAxwcAACwAAABwcHQvc2xpZGVNYXN0ZXJzL19y ZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TVTWrDMBAF4H2hdzCzjyU7iZOUyNmEQqCrkh5A WOMfaktGUkp9+4qWQgxhaCGgjcCS9ebjbbQ/fA598oHWdUYLyFIOCerKqE43At7Oz4stJM5L rWRvNAqY0MGhfHzYv2Ivfbjk2m50SUjRTkDr/fjEmKtaHKRLzYg6nNTGDtKHT9uwUVbvskGW c14we50B5SwzOSkB9qTC/PM04l+yTV13FR5NdRlQ+xsjmOs7hS9yMhcfYqVt0AtI0+v92U/b NIwAdlu2jClbUrJNTNmGkmX5PWk+3MUZ6nvnZ80ox10Z/20oJxuKKSM7K2LKCrKzuKWRra1j 0tZkazxqa5yyrWLSVpRsF1O2+5Wx2fNbfgEAAP//AwBQSwMEFAAGAAgAAAAhAFptTuypAgAA sggAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWzklu9O2zAQwL9P2jtY 2eeQtmsQVLQoTbt94Z8oPIAXO02E43i2G5qhSbzW9jg8yc520hZaBkJCmrQv8fl8d777+RLn 6HhZMFRRqfKSD73uXsdDlCclyfl86F1fffEPPKQ05gSzktOhV1PlHY8+fjgSA8XICa7LhUYQ g6sBHnqZ1mIQBCrJaIHVXikoh7W0lAXWMJXzgEh8C7ELFvQ6nf2gwDn3Gn/5Gv8yTfOETspk UVCuXRBJGdaQv8pyodpo4jXRhKQKwljvxynpWkC1OteMnnNWe8iaygqUXW8E1SczRhDHBSiu jBWyZmZFiStJqZF49VWKmbiQ1uGsupAoJyZA4+gFzUJjZqe8skLwxH3einiwTGVhRmCBlkMP jqw2z8Do6FKjxCmTtTbJznfYJtl0h3XQbhBsbGqqcsltl9Nry3Ecuquq2nyVOCmTG4V4CfWY 8l15KwtXsxlFtgm+sXOLVlgn08DSy3FJarPJNxitEg+Y0jNdM2onwjxsGhLyZdj0NeX+9Qz6 utAxo5ivgOhRzPLkBukSUZJrdIqVphLZZOAtgJCGjraMbEjKyQWW+PJJZEdR2KTbDIMW4fMg P7cgL2kCr9wcNu2/DBOkOANrGklZ3mYUE/U6xkQDgh/wmmCWepAA9EHXdcCzzC1d7kzc/IUj sHLFuo0voeml6+4NtZE3zO2B7bBvVFvICfUn07ci728jD98ReaqlY/59gSW0Vou99f1fsIfb 2PffETvcVGeLYif53j9PPoV7xjC760fTgyiOu34YhZHfn8SHfnQwHvvhOJpOJoedMOz0frY3 l2I5oRyKfvzlW53a33bUo4f7X58e7n+vv3aQxNu6wA7uPjSHNDNxYGTyFIvzym5X2K9sbFUC /g2a81ybmBjtv8boDwAAAP//AwBQSwMEFAAGAAgAAAAhALW4ZcooAwAAxgsAACIAAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MTAueG1s3JbdbtowFMfvJ+0drOyahq+yFhUqBmU3 /UBAd+8lDonq2J5tUtg0qa+1PU6fZMd2AuWjLXStNO0mdpzjv8/5HR/HJ6ezlKKMSJVw1vIq B2UPERbwMGGTlnc97peOPKQ0ZiGmnJGWNyfKO22/f3cimoqG53jOpxqBBlNN3PJirUXT91UQ kxSrAy4Ig28RlynW8ConfijxLWin1K+Wyw0/xQnz8vlyl/k8ipKA9HgwTQnTTkQSijX4r+JE qEJN7KImJFEgY2evuqTnAqIFMHo885C1kxmMVLw2hB6MaIgYTmFgnGhKEABCX8A4CTBFYzLT 1kyJsSTE9Fj2WYqRGEg7+zIbSJSERi1X8fz8Q25mX1lmO/7a9EnRxc1ZJFPTAhU0a3mQvLl5 +mYMnECBGwyWo0F8tcU2iM+2WPvFAv6DRU1UzrnNcKpFOA5KZRFV4a8S5zy4UYhxiMeE78Jb WLiYTSviPAXaSOV27qPtLJ3JYenZJx7OzSJfobWDuEmVHuk5JfZFmId1Q4K/FJsdTljpegQ7 PNVdSjBbANHtLk2CG6Q5ImGi0QVWmkhknYF6AElDR1tGVpKwcIAlHq4pO4rCOl146BcIHwdZ K0Cu7Ck0oDggMachuFJ9DbgGlYe4TKAI3G73YP3ZcvI+xM0xAioEG6cdxk3+wgDK6AL0X+bD ULHpUCv5cMzXl7RB7bHkiAQc6pqSjNAd5G1G9pAfx4ncXb22p3qfT6WOd5av7yufRFvVX7sS 6kUlDEkAv6EJlJ919emdD71uDNakIyW/jQkO1W4FEUIBqO/w68A0KkrBnYWP1oLd58yZuPdn DiPbz2glnxuSaOjO+QfDpv/AvMjVun0+tIE8JKXe2UuRH24iP3xD5JGWjvm3KZZQ1AX2Z46g /w57YxN74w2xw+3tcppuJW8Psn+afATXL8PsR6dT7XX7vU6pe1wvl+qVfqV03Kgflo665cpZ tV+rfawe/yxuc4omIWEQ9Ooht8jaUyvq9v3drw/3d7+Xpx048bJdYBt3MzRJGhkdaKm8wOIq s8ul9v/WtUMC7st5PpcmRqO4f7f/AAAA//8DAFBLAwQUAAYACAAAACEAFvxopSMEAABTEgAA IQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ5LnhtbNyYXXLbNhDH3zvTO3DYZ4Wk xC9rImVi2e6L42gi5wAwCYmcgCAKQrKUTmdyrfY4OUl3wS/RUlxGVtqZvogguPgBu4v9E+Lr N9uMGRsqizTnE9N5ZZsG5VEep3w1MT/e3wxC0ygU4TFhOacTc0cL8830559ei3HB4luyy9fK AAYvxmRiJkqJsWUVUUIzUrzKBeXwbJnLjCi4lSsrluQR2BmzhrbtWxlJuVmNl33G58tlGtGr PFpnlKsSIikjCtZfJKkoaproQxOSFoDRo7tLUjsB3oo0ut+ahjaTG+hwzCl4Hi1YbHCSQcc8 jdRaUuMxVYkxIwJJ2qYQ95JSbPHNr1IsxFzqoXebuTTSGFEVwrSqB5WZvuUb3bCeDF/VTTLe LmWGV4iIsZ2YkLgd/lrYR7fKiMrOqO2NkvdHbKPk+oi1VU9g7U2KXpWLO3RnWLtznypGDafx ql5vIW7z6FNh8Bz8QfdL9xqL0me8iqQKv0JUZVc+1I12MUcj4QQXw2EYah/dEFJqP4mK54a+ a1feer4fjMKnLpdoMVbbyzze4eAHuIKrhEdJDjv1oUSyQi3UjlHd3jBHoAlbQSkxE/tiuvwA XcVnCJCNUz7Unjf2ZXuPI/BHOyZhKCNYiZQPPi6gEjM1Y5TwJnlqOmNp9MlQuUHjVBnvSKGo NHTgoG6BiHSl59BIyuM5kQQXtU8uVyS077XPOgzPJ31UJ70ugzkjEU1yFsMihufYAlCBJkyF aX3RRvCdYRB4z+wD13Fws/TdCN/MfkbkrS6llMcgLdjUo9Z3oJ961N6eGA2bGZvdoJvDFuV6 AVr14g1bDypIxRu1vAvH1U734qFlw0NIxXNbnjMKHCyxfkAsggaIlAro7QFDSNppQKRUQL8F wibwdfF9PxApFTDYAwauztwJQKRUwLAFIq1/UjpApFTAiz2g7wUnJgUpxzUJ8WDQvmWOawmU 91zm+VJXwRPFOkVk3ObNgoW7rzCjcygM1rOp45AQtqzERmvXyWLjjeCdUr5UvqE2oQ135ST/ mtg4nWJ+udg4HfF6udg4nW14BrG5OLPWdHhnkJoO7wxK0+GdQWg6vDPoTIfXX2ZeeBTC+tMn oaJzFDpFibxaiT7QCP4TreCM5f6zBEFrloA1fStl/phQEhf9lClWB7rklBF8VpgYL02+V03a bPU4nx6xr7oO3goxHVxdnyr+/mHI9SnuB4V8qWQZ89/WRML2qcPe4/D5vwp7cBh2/weGvWDx 3To7Gvkeb+L/OPJLFuuY/W6PbFD/m8vBKJzNBu711c0gvPHsAfyxmDnXl1749sr+o/60ULAU FBOc7qpbk7XnZlTTr1/+/OXrl79aRYNFnLYL9KX8VIFJWiAHrky+I+L9Rk+XaSWd6S6R8lWV z9YEGfXHoOnfAAAA//8DAFBLAwQUAAYACAAAACEAqvmT2EoEAAC7EgAAIQAAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbNxY3ZLaNhS+70zfweNeE5D/lwlkdtmkN5vNTiAP oLUFdiPLriRYaKczea3mcfIkOZItfgwLhm2mnd7gg/zp0/nR+SR4/WaZU2tBuMgKNrDRq55t ERYXScZmA/vT5F0nsi0hMUswLRgZ2Csi7DfDn396XfYFTe7wqphLCziY6OOBnUpZ9rtdEack x+JVURIG76YFz7GEr3zWTTh+Au6cdp1eL+jmOGN2PZ+3mV9Mp1lMbot4nhMmKxJOKJbgv0iz Uhi2sg1byYkAGj171yW5KiHa4vG3ydK2NIwvYADZQ4g8HtPEYjiHgVHBJDBYT5lMrREuFZPG iHLCCVEWW/zKy3H5wPXU+8UDt7JEUdUUdrd+UcP0V7bQRrcxfWZM3F9Oea6ekBFrObChcCv1 2VVjZCmtuBqMN6Nx+uEANk7fHkB3zQLdrUVVVJVz++E4JpxJJimx0Doq468o74r4s7BYAfGo 8Kvw1ogqZvUs0zr9UlHVuOqlNjbOHMyE54dQSB2iE7o9v5ETt9eLXORWsSIUODViO+KKuezL 5U2RrNTsR3hCpJjFaQEb9bHipEKO5YoSbS8oKhWEzqCTqK3GEjL9CEPiD3Clp3x6NIGv8ZW9 xVOqDx0Xh6kUq0YkrPNpDI2YyxElmK1rJ4cjmsWfLVlYJMmk9R4LSbil8wZtC4yKXeo1NCVh yQPmWDm1zVx5VOrYTcw6Dcdr7pqamy54oDgmaUETcMJ52Q7IkuUG0r74rh/6qqDPVd9HCIXq vaq+H/kugq3QsvrPlbxRaVftvkaNtensY51oG2sAYLoHsN421gDA9A5g1W5bYw0ATP8U1gDA DE5hDQDM8BTWAMCMTmENAMyrU9gKcKiHVDMCYN0sL+wptYN0S4mdnqr6prmk3rhnLDkmccES i5IFoS3odW+dQT9JM96eXTfEGezvijmH068tvXcufTY9yP5Pq5m3PsFUqbelTCfkpYeZ0hBb b+AU06ldCZwu5KWnG/JcH1W98Mzx5gVXqBe8WOCsHPM7fT/IWAI6r0w9a34Pl0I9a6s/0Y5O NfSvpjJRtOLb0dOGRtZ8V8hTq7bj29GPho7WfMgNUdCW8OqI1hq+yImU1J/P19Djms9xokBf KM7ma2i24Qs9fWydz9fQ9ZpPkbUuyA5fQ/sNX+CHl9Xjv3E+nKdEvlGijySG314zuMxp0Twu QWCNUkCTa86Lp5TgRLRTpkTu6RKqMnhUmCirIJdfl1pchA/g66E98U9I5/btpeIf7Kfc/4Ep n0pe5fz3OeawfUzaW1x4/1dpD/fTHvzAtAua3M/zg5lvcRL/y5mf0kTn7M/gxr0ORmHUub32 bjqeEzmdCH4cdKLbyHXg8L+OUO8v8xeGoBkoJgS9q27rqh1bUQ6/ffn7l29fvm4UDZy4bBfo R/WXiCrSWPHAk/L3uPyw0MvlWklHeqjM2Kyu5waiOMyfTsPvAAAA//8DAFBLAwQUAAYACAAA ACEAn1KC8YAEAAAwHAAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ1LnhtbOyZ XXLbNhDH3zvTO3DYZ4XiN6WJlHEUuy+O7bGUA8AkaLIBARaAZKmdzuRazXFykgAgKeqDYmna nXZavYgQtPxhd7H4cyW9fbfOkLaClKUET3TzzVDXIA5JlOLHif5pcTUIdI1xgCOACIYTfQOZ /m764w9v8zFD0TXYkCXXBAOzMZjoCef52DBYmMAMsDckh1h8FhOaAS7e0kcjouBJsDNkWMOh Z2QgxXp5P+1yP4njNIQfSLjMIOYFhEIEuPCfJWnOKlrehZZTyARG3b3vEt/kIlr+RBbrxRO5 ffhF15QxXYlpU5+K+MM5ijQMMjExI1kOaMoIVp+wfEEhlCO8+pnm8/yOqhtuVndUSyMJKG/U jfKD0ky9xSs1MA5uf6yGYLyOaSavIhvaeqKLTdvIV0POwTXXwmIyrGfD5LbBNkwuG6yNagFj Z1EZVeHccThWFc4i5Qhq5jaqyl+WX5PwM9MwEfHI8IvwthZFzPKaJ1XqJaq0Kz5Ug9qZMll8 /Z5EG7nIg7iqSTBGjM/5BkE1XiGzdCOC8X2R2p1pOd4xz+WLsqYiOgTkOYB48GkuzkHGZwgC vE0fn85QGn7WONFglHLtI2AcUk25Lk6NIEo6V2soJMTRHaDg/oBceJSrEKt4jCrhp9Nub9Mu 9/wOgRAmBEXCA+s1dkDmUxcLrWvzExvRUJKO64vTpGrNdG3XNO396nSGztAMgqLqPHvke8rn 3dIryMc7rAEcJkSoxUOBbNhsLQP0WhV1iiNxwOVQAZY3QsXUXUUtaOw3Ub6O9PShCnOvZMTQ qoFVVJ2ow2OqRJVUu6aOTEd50IVqBsdUiSqpTk01bd/0OmOV5T5Wskqsu4MNrED50BcrWSXW q7GWFXgqYX2xklVi/R2s79idd6wJK1klNqixktl9yxqwklViRztYz/VftGWS1axochFhsJWu FyqcPMZK4NiewvVRMadSsRnBXES9J2RKNfoLmcxTAlBcylghMT1lzDJ9J/DdFhmzR64pDkdX HfvrJ1WtTqd0qUlzTqlNk5Kc0pCmWjslDK22B6e91fbgCLfaHpzLVtuDw9Zq++84QYdLqip/ xpJzGBIcaQiuIOqAV+fiGfhFktLu9PLJ35l+RZaUJ53xznPxadxIf+3uzD3ZnSmPX6c7kwX8 6xJQUVKlxqlsP0/jPMcdWm5rr2b6QvnOvdq5Vzv3av/nXs1r69VUa/SyXm1fypRO9payU/1a LWXnfu3cr537tXO/VmibX2nbPQy5wCHYpVETo1kirOEFpeQpgSBi3fq3iBfd287XU7Oo61bB Q7gw6S9SHX7+bLAvp45SHsHBh8u+KQ+OU97hIdI75TGnTR2z2eHXzf9U2kfHaff+xrQzFN0s s8bMd/hB5h/OfIwilbPfr0zP8n3vYmA7I3fgvLdng5F9cTUYOTPxjenSNmfBxR/V/0YMpaIp FEHvi9x219pW5NNvX/786duXr7XaCSf6VYG6FP9FyU2aS464IvoR5LcrtVymnm8zNZWn+LHc z9pEMqp/+qbfAQAA//8DAFBLAwQUAAYACAAAACEAm57OSFsCAABgBwAAIQAAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbORV3W7bIBS+n7R3sNh1ajt/SqImVZqku+naqOke gBocW8XAgLjxpkl9re1x+iQ7gN1kS1RVkypN2o05HL5z+M53MJyebQsWlFTpXPAxik8iFFCe CJLz9Rh9vr1oDVCgDeYEM8HpGFVUo7PJ+3encqQZucSV2JgAcnA9wmOUGSNHYaiTjBZYnwhJ OaylQhXYwFStQ6LwA+QuWNiOon5Y4JyjOl69Jl6kaZ7QuUg2BeXGJ1GUYQP8dZZL3WSTr8km FdWQxkX/TslUEqq9Y5jfo8DBVAmOGE2g8mTFSMBxAY5zh7BOLW8Vpdbi5UclV3KpHPaqXKog Jza2jkFhvVDD3JSXzgj/CF83Jh5tU1XYESQItmMEnarsN7Q+ujVB4p3Jzptk10ewSbY4gg6b DcK9TW1VntxhOe2mnBuawAFZMxp0nytrOGt5KZJ7HXABNXkJxCwDNJ0qJR4yiom2bl/5c6CX w44yq1tBDBzEr9BUzFIEBIB+7Ik3YGfseHsCjHuIn8uR2Z4LUtmVOxid5ADSZmUqRp1dsriO JTS98U3Zc1t7Dy7d5xBfuygnS6wwuAM4KPBLEdqaL2q9pWPWMHIkX5a8cyh57w0lT43ymn/Z YGWoamRvYv8X2buHsvffUHa4V682xVHl2/+88incjFazb8PBbDqcRRetzrATtbr9abs17A+i 1nTe7XWHUbzo9+LvzT2rWU4oh6JtCnXYtZd2NJOnxx8fnh5/Wp9xK0Di706BG/w1bpu0snlg ZOoTltel2w5eEmjIzLkkvGR1P3cQm6N5GSe/AAAA//8DAFBLAwQUAAYACAAAACEAzSVHx1cD AACmDAAAIgAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWzcV11v2jAUfZ+0 /2BlzywQwkdRoWpp2cv6oUL37iVOE9WxPdtksGlS/9b2c/pLdm0nUD6GaNdK016w49x7fO45 XCc5PJrlFBVEqoyzvtd4X/cQYRGPM3bb924mo1rXQ0pjFmPKGel7c6K8o8HbN4eip2j8Ec/5 VCPAYKqH+16qtej5vopSkmP1ngvC4F7CZY41XMpbP5b4K2Dn1A/q9baf44x5Zb7cJ58nSRaR Ux5Nc8K0A5GEYg38VZoJVaGJfdCEJApgbPYqJT0XUC0IoyeZpuSYxZOZh2y8LOBOwxuABNGY xojhHBY+QWgWYYpsPALF0ITMtA1TYiIJMTNWfJBiLK6kzb4oriTKYoNWonh+eaMMs5essBN/ Lf22muLeLJG5GUEdNOt7YOLc/PpmDUigyC1Gy9UovdwSG6VnW6L9agP/0aamKkdus5ygKmdN lMaivIq4Eh95dKcQ41CY0cHVuYhwxZtRpKUn2kB5iMsMnHMWlVku1E6WHLcK1G4HB2HdlR50 wnazu6pVUG917H2jQavbarSC1roSDlr09OyEx3OT/RlGUMAw6nsEm+IdLFV6rOeU2Athfiwp CcEUm0YjrHYzhkbL9ZASzBZ+6MGQZtEd0hyRONPoHCtNJLISQFsCpKGkLTELSVh8hSW+XkN2 1IXlXfG1Jez2sbnpo1HoiuKIpJzGQCV4CUuNcGuOwv6zZfL+zoatTrDD2Ha9cdB9TWOFUb6g Cwf/0mjD2/qsVox2Zq5vadV6wpZjEnE4pigpCN0D3lr9BPhJmsn90ZtPRB/xqdTp3vDhU+Gz ZCv6S7dYWLXYNYngMXsLfW2p7m4pmA1TiCbHUvKvKcGx2q/TYugs9Q0ejZgmVY+5M35nk1Hm Qv7UGivNYOcFbZS5MUmu3fPr0bKZPwqvvFqPL5c2JI9J7fTsuZK3NiW3Z8ArSZ5o6TT/MsUS mrqSfY+z7b+Svb0pe/sVZYe304tpvlV5e5D908on8FppNPve6QyD8PT0pHY8aoW1sN0d1U6O 62Ft2BwGo0azfhIMRz+qt1VFs5gwKHr1kFu4tmtHPXi4//nu4f7X8rQDEs/7F9jBvfEak8YG B0Yqz7G4LOx2uX2+De2SgO+B0s9liMGovi8GvwEAAP//AwBQSwMEFAAGAAgAAAAhAGYF41PC AwAA+w0AACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0My54bWzcl12O2zYQx98L 9A6C+uzow7IkG7GD1LttHzabRbw5AFeiV0IoiiVpx05RINdqj5OTdIaiLHnXu1XcBij6YtLU 8MeZ/5BD6eWrXcWcLZWqrPncDV74rkN5Vuclv5+7729/GqWuozThOWE1p3N3T5X7avH9dy/F TLH8iuzrjXaAwdWMzN1CazHzPJUVtCLqRS0oh2frWlZEw1957+WSfAR2xbzQ92OvIiV37Xw5 ZH69XpcZvaizTUW5biCSMqLBf1WUQrU0MYQmJFWAMbOPXdJ7AdEqmv1CSe46xlBuYShwFxB7 tmK5w0kFAyua4XQHDak0T5W4lZRij29/lmIlbqSZdL29kU6ZI8ROdj37wJqZv3xrOt6D6fdt l8x2a1lhC2o4u7kLSdvjr4djdKedrBnMutGseHvCNisuT1h77QJeb1GMqnHucThhG85tqRl1 gkNUrb9KXNXZB+XwGuLB8JvwDhZNzNiKwkqvEWXtmoem0zlzUokkDMfB2IQYRX489R+IkiRJ GPk22GAch34yeRhygxYzvfuxzvc4+w5aCJXwrKhhl+qGyZRe6T2jpr9lgUATdg/HiLk4ltP1 OxhSn8AXH9e8M4nPCChAGLPL2plNv0cU+GNClABhBM8j5aP3KziPlV4ySvghjXqxZGX2wdG1 Q/NSO2+I0lQ6RkI4vUBEujZrGCTl+Q2RBN3rkxuPhFGhjd4I8nz6x4f0o8w3jGS0qBkcBif8 N3YCqu/CQrvO/KwNEU79OIH+Mxti4vtBmnz1hrh7ekNURF6Z01XyHCoNdg1gcw3l1MzqbZMQ t8mDbWG6YYeKJkmI/g7hBWmfhxDLG3e8aRCZ+Afx4j4PIZYXdbxgnBizYUBc+gBEigVOesA0 TDGOM4BIscC4A4ZhGpvz+PVApFhg0gMm0Xh4To6ASLHAtAMibXhSjoBIscBpDxhPkjOTgpTT xQnxYHCoQv+wWOGJNLVKHRWrcwpS1Bakd3A3gzNQBaO/r0TQWxZgTV9LWX8s4DpXwwpUrl0j XEHYui1UjYLPVirGG5OnystTNaVL14Ab5IS9HXp0B+R0dHF57h0weSy5uVi/keRrLRvNf90Q CdunlX3ABfG/kj1+LHv8DWWHV/7rTXVSeXPV/6eVX8MrO2r2WzgJ4mkQJqPLNPFHkT8JRq8v xstRFE+CdBpG0yC+/P3wCcBKKJkQ9HF1O2TtuRX14svnP3748vnPrqKBE+ftAtM0nxWYpBVy oGXyDRFvt2a5ylTSpRkS8JFl89mZIKP9aFv8BQAA//8DAFBLAwQUAAYACAAAACEAnzGleZsD AABhEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbOxY247bNhB9L9B/ IJRnR77IsteIHew6674k2UXsfAAjUpYaimRJWmu3KJDfaj8nX9IhJdrry67tTYIAxb6YI+rw cOZwZiTr1etlwVBJlc4FHwatl80AUZ4IkvP5MPg4mzT6AdIGc4KZ4HQYrKgOXo9+/eWVHGhG 3uKVWBgEHFwP8DDIjJGDMNRJRgusXwpJOdxLhSqwgUs1D4nCd8BdsLDdbMZhgXMe1OvVKetF muYJfSOSRUG5qUgUZdiA/zrLpfZs8hQ2qagGGrd62yWzkhCtuRM3n34PkMOpEmZawQhCT6aM II4LmJjdCTQW3ACNu6XlTFFqLV7+puRU3iq34n15q1BOLEO9MgjrGzXMXfLSGeHO8rk38WCZ qsKOoARaDgM4sJX9De0cXRqUVJPJZjbJbg5gk+z6ADr0G4T3NrVRVc7th9P24cxywyhqraPy /mr5ViSfNeIC4rHhV+GtEVXMdpSZl91S1bjqpjM2ztRimeWVICu7yScY3SQeMG2mZsWou5D2 x7mhwF+GbVZT3vg4hawuzJhRzNeCmNGY5clnZASiJDfoHdaGKuScgRoASquOcRo5SsrJLVb4 ww5zpaJ0TnsPQy/hw0J2vJB1NqFbhhOaCUbAifa3yar/hGrALA1gp+UG/IC2B7Is6vagOFz6 tOJm09pbCRc1O/3YAmwiRd129yLu7KZTRX3k1JxdslbtBqGpldf63+5Xm4ZbADDbB7DRfawH gNk5gG3ex3oAmNE+trXlgweA2T2G9QAw42NYDwCzdwzrAWD2j2E9AMyLY9gKYO17B+OqSdp0 L9m6bL6xumwGueLSW9VVVdDuli5xz9hyShPBCWK0pOwEeldlZ9DPslydzu4K4gz2iVgok51M H51Ln6cH2b93X4se62tOk+/W19z5ndfX4qj/3NieG9tzY3tubOc2tq5vbB9oAv+Q5vCW6Fx9 vJ2BNc4ATS+VEncZxUSf9lJMTLD3Hlfl9aMNj/EK8vQmtdOaHiidXXw9tSc5oY0310+VPN6X vPsDJU+NqjT/Y4EVFLWX/YT35/+V7L192eMfKLtm5P2iOKj8CU/4n6x8yojT7K/J5CruXV2M G3E37jSiVu+ycdW/jhuTi/74sjuJmtft8d/+Q4NmOaEcgt5ucutTe2xHM/r65Z8XX7/8u+l2 4MTTssAN1QcMe0hTywMjU++wvCnddoV7vo3dlMz5vD7PDcRy+E9Do/8AAAD//wMAUEsDBBQA BgAIAAAAIQC9Hju8iQMAAKcNAAAhAAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDEu eG1s3Jfdbts2FMfvB+wdBO3alSXrK0btwnOT3aRpEKcPwEi0LZSiOJJ27Q4D+lrb4/RJdnhI WU7jZZ7QAMNuJIo6/PGc/yGPqNdvdjXztlSqquETP3w19D3Ki6as+Grif7i/GuS+pzThJWEN pxN/T5X/ZvrjD6/FWLHymuybjfaAwdWYTPy11mIcBKpY05qoV42gHN4tG1kTDY9yFZSSfAJ2 zYJoOEyDmlTcd+PlOeOb5bIq6Num2NSUawuRlBEN/qt1JVRLE+fQhKQKMDj6sUt6LyBaXWlG fQ/N5BY6Qn8KkRcLVnqc1NBxbyy8BatKiq+UuJeUmhbf/iLFQtxKHHGzvZVeVRqCG+kH7oUz w0e+xUbwzfBV2yTj3VLW5g5CeLuJD/nam2tg+uhOe4XtLLreYv3+hG2xvjxhHbQTBEeTmqis c0/DidpwrBDhIarWXyWum+Kj8ngD8ZjwbXgHCxuzuYu1U73QEmnO1L7HRufPSTHSPMmHNsoo HA3jKHmsS5ZlUWwMTLxhnA2H1uI4aosWY737uSn3ZvQD3DErZMyUXug9o/ggzAXdkCAGI2bH UD74sIAdU+s5o4Qf1NbTOauKj55uPFpW2ntHlKbSw/UF+wuQxgmNriCS8vKWSHL3Ddk6K9DT 1kN0+vksjdosLTYPds7oeyRKbR5somCSXTfk/ISFoyxMXcZGeZ7CBnycsRTShSnFjGVJZKz7 ZAzbWxaCrVcTeY3LvuIl7H5sErbiuPJ8BGxuoNohoKTLO7snDwDHijpWnGTG9T5AQ3HAUQe8 CGNcqD2AhuKAcQc8KN2DaDCOmBwR8yjH1PQgGowjph0xinJwsR/RYBwxOyJm8ahvYgzGEfOO aHB9M2MwjnhxREyTrG9mDMa2j5b5d6hLqi0TL1+a4rY03dECzhkrmDT+59oErfkarOlMyubT mpJSnVeySg0qfIazAWHLtmzZivJs3WLcmvzbWvO3FeRUzk7Yu64nkpd08Payr+TJU8nxM/hC ki9hGaPmv26IhNXVyn7G5+J/JXv6VPb0BWWH4/nNpj6pPH78/9PKL+GAbTT7LbxIkjgeDQdX 2SwaxPOri0EeX2WDWZ6P5rNZPMsuk9/b47oyx3AOQT8ufoesPTejnn798sdPX7/82VU7cKLf KsCb/Q8wSVoYDtyZfEfE+y1OV2OhnWOXgB8il8/OxDDaH6zpXwAAAP//AwBQSwMEFAAGAAgA AAAhABxWCUcMAwAAjwsAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWzc lutu2jAUx79P2jtY2WcaQilrUaGilO5LL6jQB3Bjh2R1bM82KXSa1NfaHqdPsmMngRZoC71I 077Elxz/fc7Px5f9g0nKUEaVTgRvecFW1UOUh4IkfNTyLofHlV0PaYM5wUxw2vKmVHsH7c+f 9mVTM3KCp2JsEGhw3cQtLzZGNn1fhzFNsd4SknL4FwmVYgNNNfKJwjegnTK/Vq02/BQn3CvG q3XGiyhKQnokwnFKuclFFGXYgP86TqQu1eQ6alJRDTJu9GOXzFRCtOLqu4eckcqgGXhtiDsc MII4TqFjmBhGEdBBXcENKDkDLYeKUlvj2TclB7Kv3LizrK9QQqxOMd7zix+FmWvyzFX8heGj soqbk0iltgQYaNLyYM2m9uvbPjoxKMw7w3lvGJ+vsA3j3gprv5zAfzCpjSp3bjmcWhlOjiOY RVX6q+WJCK814gLiseHn4c0s8phtKeOCvLFShV3+01XmzhSwzORQkKmd5ApK14mbTJuBmTLq GtJ+nBsK/GXYJjbllcsBJHZquoxiPgNi2l2WhNfICERJYtAp1oYq5JyBbQCSlo5xjJwk5aSP Fb5YUM4pSud06aFfInwa5HYJssgm1Gc4pLFgBJyovQ1rQiZzk3cgKm3IGZuheyNhm7YOsH5E OKe4OKULY4MpBzQUsEcZzShbQ96R3kB+GCdqffXtDdWPxViZeG35+qbySbRS/b1zu17m9gUN 4T4ZwYZyrj6f0VDrxmBNO0qJm5hiotc7P4iBaG/hDsAs8orkz0+3J7Pf5TnPTfL2C5vB1TMW FGMJjS7yk/tBt60/MC/XatG+6FpCTmjlqPda5DvLyHc+EHlkVM78xxgr2NQl9hcOnf8Oe2MZ e+MDscMz7GycriTvDrJ/mnwETynL7GdQDXbqtUa30v16HFTqvaBT6QRBr9ILtqu7tdper3O4 96t8lmmWEMoh6MeH3GzVnpvRtO/vfn+5v/szP+3AiddlgSvyt55dpIHVgZKpUyzPMzdd6u63 ruuS8PAt1nNuYjXKh3T7LwAAAP//AwBQSwMEFAAGAAgAAAAhAECPf283BwAAJTcAABQAAABw cHQvdGhlbWUvdGhlbWUxLnhtbOya3Y+bOBDA30+6/wHx3oaPQGDVbAUGdA9X3anb0z07CQl0 CURAt+1/f2ODCQ7EQJdte3chUmKcyfhrfp4ZkzdvvxwT6SnMizhL17L6WpGlMN1muzg9rOW/ PgSvLFkqSpzucJKl4Vr+Ghby2/tff3mD78ooPIYS/D4t7vBajsrydLdYFFuoxsXr7BSm8N0+ y4+4hNv8sNjl+DPoPSYLTVHMxRHHqSyl+AhqNwlOH+V7ptVP4C0tC1KxTfIHojNsi0oqFd49 quSjyA8blOTSE07WskIveXH/ZtEIJGVXLqBXLVcL7B61IX1UICm7cpZCXo0+KoC3WxhGt23X 9RVfr2VbQlWxq1uHy7Y5+ZZ+XTy2llBVXIrH2BKqikZH3nN8z+f1U6GqaHbkNU/zLIeTp0JR EqePPb2x7Wa0jcg+S37rFbdthJrOn6UWLdOpfp+WXUOiZnTEH7M8gO/p2uIyTqXy6ync4y2I OXmME6Id34W4VV9VbYuLqsWFumOczqr7rI6Olo2JjvDID/CP/T7ehnSE+zhJHsqvSfh7QTtS ZEm8C6CS3tAfNfN5iqBYN8fJHXJMy1KelX/HZfQQ4RM0U6F4KGrVh0I6ZQWsIq3u1U05j9Oy qjOY7YE0Lt9lu9rm2zbZqKF3B7oxsIZ0omBsY/rqeY2pleDI1lTatW5rzZB7W6Mf9WyCLUuY 7MWqqVVNS8UWJ+GOzHulgC3L7EtURHgX1mtExt0diErnbcS0WcOz1mrNJmqf0dqYRWo3t7zS HFu956wSU3BeJcLtBY5Jyt9Jn6FXhmbI0haf1vIe9g0oHk+gr0gPsoSTA3jrbVkPZRDmywH3 m6WqXB0w18QpL0oPF1H1K/oVc3vpuf+asSTzMM8Aenajcb3QLfUH9oJ+tJc23O/DbXml5nxb f5d9KsP8Idp9ljbJp/w9hn4TU4Xx7OKihClmNzkQSr+BO578moIeZ0/9dXKKcL0nEUTZCCtx Wm76QO9a3WvuLvr+jUOhyM80lLYZ/8+GQiw3TEN9RwMICANyLBEbXctZXkYZ7EKnKN4GOQQO tC3olwRYkC5JCUkBSF/Dp/O+VemoNrlDVL6PD1Iew05XRnkY/lnW4xxQpta7Yk1GrajeZ5ru FqfqcxM+hckHQq9Jxi9LEdtN6omgcpeLxt/Xk7E5EFB/1sinMpup4cG5oer3YxtrbfotV2A/ rwsTXW21Y3Wa04zRrvaEy0gib7Bxx/k2Oce3H7L3sPpSE1FKYIivqsBDIihWpQ30uaqsWiOq XjaMOi9B0+4LBp+tyW7CpYvJFjf37ZNdl7i5bttRz1QvuoiS8IglMvSucyKQbT5C2x4kRp+S sqiypy9ljhFL95hr5SpvZwm3s4S5zhLg5h0+SZuDupZhucH6v0AJDARs/qCROo3UaaQOSvWq rOW6wGo0VtPI6KxGZzVLVrNkNQarMViNyWpM8JWkx2uZfsgSGwIEv3WpHluXjbG0aD8dLbZJ XuNoCVwvMCbQEgS2bTLdPwEtgecjl++/kBZ/ZTkGGksLQrre9GYMLaZ5o0VIi/6v9i1kO7yw ZiEtCHXkfygtyPG1C/1CWlzbtf3VWFqIJ0WMrWFanMBcNZ250dJHy/LZtEAoYQbsZPR7+5au NQtpsTxkTqHFR4ET8NY5r2/p9l9Iyypw9fG0KIppTqBFURzr5luEtBiz+BaPRccz0LKi1wRa eOsZyFuId5nmW3w+z5mfFj4PGchbiHcZS0sQGIoxPhIjYeqNFiEtpoAWwzGsOSOxVoQloIVo a3LTAVpg91ya2nhaTM8MEE+XkBbHQQrirV9Ii+eQ13haHMe1XL4/QlpMzVy6y/G+pbUyY3xL EEykhfJAaaHcUFooN5QWys1/ipbVVVoMpJ4nbwZa6KHoCFq8wNNslvkO0MLlsSNocf2VbfLy QlqQ4sD1crT4GohP8C0OMj2DP6UQ+pbWvjNMi6c7msrEb7T00WIJfIuuN+dHM2X5zdoJaCF5 eEufkBbSw4vISkiLoriXkdKAbwHv8oK0OJ5r+bxvFNICM3jewQZpIXMzwbdA0LlSWAJ6o6WP FvsqLcQSW9b93c7EfN13W6cGA5FY5/mJkJalaTlLdxotL+lbQLl3QaOQFj1YeUv+xHlGWhSf POG/0SJ4Olk98O3DhUu3Z8DFtEzX8EaEYqqnImbSQ0fIiq1YExIXS7F9hyVjI3CBpNpx+dBn VlyQCS+2NYw5FNOtwOb7LwzFEGrCg2FcfNtDzRnCDZdeXK4/zddhm2+ehc2Bi8l5K2GePzYW MxXDXvHeQpznwzXlDBmycOslYzEXdhB3whmygQw0/gyZex41JhZrJTo3XHpxuf44X/M0RTXm w8XQdF87p0KCRB8pFvNCA7hYaOWuJiT6VmAE2hRcdCdw+NRoXu8CsLg87kJcLNUwtNF/fkHI Pf9rchgXC4Hr/T8GY50q9kc0+tez+38AAAD//wMAUEsDBBQABgAIAAAAIQDMvyJtTwYAAMYk AAAhAAAAcHB0L25vdGVzTWFzdGVycy9ub3Rlc01hc3RlcjEueG1s7Fnrbts2FP4/YO8gaD8H 17rZlo04RezYXYG0C+oU+01LlCWEIjWSdpwOBfpa2+P0SXZ4kW9JUy9xhqI1AkRHR4c85HfO d3jxyctlSZwF5qJgtO/6LzzXwTRhaUFnfff91bgRu46QiKaIMIr77i0W7svTn386qXqUSSze ICExd6AXKnqo7+ZSVr1mUyQ5LpF4wSpM4VvGeIkkvPJZM+XoBnovSTPwvHazRAV1bXu+T3uW ZUWCz1kyLzGVphOOCZIwA5EXlah7q/bpreJYQDe69daQTmGGyYSk6jmdmf+X/PQE9QQjRTou CNEvqms8JNxZINJ3pzPfbZ6eNHescJbhRF4Iqb7VPWlBdSyqK46xkujiFa8mlfoK3t8uLrlT pBAW16GoBPRV3/qDNdOvdKGF5k7zWS2i3jLjpXoCdM6y70KMb9X/ph7aUjqJUSZrbZL/fo9t ko/usW7WDpobTtWszODuTifyunE9o3eAC6Izgp1gNbl62KK6YMm1cCiDaRkU2DAHa3zGObvJ MUqFUpvJrxoaRNSzyh15W4GXPOWQxh/67p9zxCFfbRNjp4X1qGGQ05s3LIVmaC6Zuy+AQbfj x54FJmp1IJW20EG9igv5CrPSUULf5TB13Tta2MxYmyg1ZSp9tA9CnZu+220FLd1g40tZKPqR ouy74NwzPlFPYTOiqZYlKoiRm6qne/JRTVpNXi4HLL1VBlN4AhBQGGCgOeMfXOeGIwiCUAhi 1yGvKWDf9aMIZiz1i56z6/DNL9PNL3ReDhnRgUQ0gV77rqzFoeQmq1hZIXlBJ1WiDGvYrpZ/ IF5Z4CRA/pZNclTh+/AztvrVTEMjKORE3hKs5QXxbYqlOHsH81Sp4auA6c9QDKhOnAwlkAVn vEAERpYjLrBcJ71pa1Cte1TyhqdK/9t0ZYdpVJiml4gjNQKCVMHFtPF+YrtXM1iHREfpq7Tq 3qVV+Iy0SiF8RbpcGz+WUGEcR20/PNLqO6CVg8gMthJc9/E98csPQ799l2DRXgR7x+Q21UQF PTzAPlBfQUBGaaGtvk5GQdLX5cwSUi+mTyCk70ehynpFyHbcUgTcYqUhomVlGAVdS5HnoOX2 fovPpqvdlmZm7XfL7DH8XTF2n1rre6tN2ToVWs9YaxXntvcwJtK6vj8h0ja6KtBRCH+7kW5F cVspTf2FvLC5cCzA31QB1ojU5dCBerlaSLUZ3ymBkIaXnLFMj02Uckgwoqsm8nRIiuTakczB UH8ce8hT44PDIHgTahBSD8UUZeN5y71O6ke6n+CE0dQheIHJHq50tXukq6u84Pt70mx7pKcx m3OZ7+1KryuPdVVkD3j6j9tK3wvulrr2M5a6TO6c1kyl04A8+dQWQ8ELfBvH4ybzCTVuejy7 He7s5nvhXZJ1npFksF18Oy/v45nexRzoMHdk2/fAtm/oSJeRVBPmr67f9obncdAYeSOvEZ0P vcZgHEWNaNwdnI9GcXw+HH50V8lepBhA1YPdXUzN1umLHuXp509///L50z/rlTRT18KPKQH6 UV/2QmwgGlZy5ryAWQ0G3XYwjAeNgR+NYVbdTuNs3G41xq0wioaD+GwYjj6qu2k/6iUc62vr 12l94e1Hd668yyLhTLBMvoB8sXfnzYrdYF6xQl+f+569g9dHqqDT8VqduNvq2ioAY6uferSq rNhr8YTwN6hypjO/7xIJuSqXIKXXIE1ngdIFShcoHUgoSTCVYGGFWhPUmpVNWGvCWhPVmqjW tGpNq9a0aw0c0nNS0GsAQz1cJ2PkN6OoJVNY9S8YX0h2SF8u9S7aweiCDvi1ljNG5Zk2mCIB 7Fa1t6CzyzlVp3nDBlElA5xZ6TKRBll1nl6dVTctzjK5a7thZ7/uss65xlz9YFMz8KEfJSAs 952R9yItZDnasPm1pA2M7K8BYudDIh6guRYDhW+J+MWq7h/RPjDaCmKLdrhGWy8yR7QPjraC 2KIdrdH2ww6sTke4Dw63wtjC3dqAOw5ivZ88wn1YuBXGFu72Gu4giNv67ncFN7S6QtPJh3Wd uRMAWO31qNfx2MbfbGD/B6zUdIk8EEAKFQtQZwOgThRur20/LEAKFQtQvAZIobO9HP2wAClU LEDdDYDarc72AvLDAqRQMbcQG5v1+tVcTJ/+CwAA//8DAFBLAwQUAAYACAAAACEAk6p9mLkA AAAkAQAAMAAAAHBwdC9oYW5kb3V0TWFzdGVycy9fcmVscy9oYW5kb3V0TWFzdGVyMS54bWwu cmVsc4zPwQrCMAwG4LvgO5TcbTcFEVm3iwi7ynyA0mZdcWtLW8W9vYVdHHjwEkjC/4VUzXsa yQtDNM5yKGkBBK10yljN4d5ddycgMQmrxOgscpgxQlNvN9UNR5FyKA7GR5IVGzkMKfkzY1EO OIlInUebN70Lk0i5DZp5IR9CI9sXxZGFbwPqlUlaxSG0qgTSzR7/sV3fG4kXJ58T2vTjBEs5 ixkUQWPiQOkyWeqBZg9YXbHVb/UHAAD//wMAUEsDBBQABgAIAAAAIQC0z1gZuQAAACQBAAAs AAAAcHB0L25vdGVzTWFzdGVycy9fcmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHOMz8EKwjAM BuC74DuU3G23HURk7S4i7CrzAUqXdcWtLW0V9/YWdnHgwUsgCf8XUjfveSIvDNE4y6GkBRC0 yvXGag737no4AYlJ2l5OziKHBSM0Yr+rbzjJlENxND6SrNjIYUzJnxmLasRZRuo82rwZXJhl ym3QzEv1kBpZVRRHFr4NEBuTtD2H0PYlkG7x+I/thsEovDj1nNGmHydYylnMoAwaEwdK18la K5o9YKJmm9/EBwAA//8DAFBLAwQKAAAAAAAAACEAHPBZYNwYAADcGAAAFwAAAGRvY1Byb3Bz L3RodW1ibmFpbC5qcGVn/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwME BQgFBQQEBQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBD AQMEBAUEBQkFBQkUDQsNFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU FBQUFBQUFBQUFBT/wAARCADAAQADASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAEC AwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEI I0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZn aGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJ ytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAEC AwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKR obHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVm Z2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbH yMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9U6KKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACivn39tH46eMvg J4B8Nav4G0vTdZ1fUdeWwks9SikcSwCzurl1j2OpEp+zBVJyMtyDWX+1V+1Jqnwt+E/hbxL8 PoNN1i+18JqMLanG8kC6YI1eSfajqc5mtkHOAZ1zmjcD6Wor5uk+IHxk8efHT4oeEvBmseCt D0TwfLpsMZ1vQ7u8uJzc2aTsS8d3EoAYsB8vTFZ3w2/ak8U+LvEnw80HUtN0eG9v/FeveFdd uLDzJLaZ9OtZpVns2LZVHZFyH3EfMvUZoGfUVFeR/tO/F7Ufgv8ADuy1fSzplpc6hrFnpB1b XN/9naUs8m03dztZT5adPvKNzLlgMmqvwj134mt4oitfEGr+GPiJ4LvrB7m18YeGbYWIt7lX QfZ5YDczCRXVyyyRtx5bBgMqaFqI9morzPWviPq+gftDeF/Bt1FaDw14i0G+urO4EbfaP7Qt ZYS8Zbdt2NBMWA25zE3J6Dyr4T/tb6j4gtfinqviyy0+w0XQ9Nn8U+HpLMOr3miLNeQpJIWY gyE2e8lcDE8fHelfS4/I+oaK8B039qnTPB/g/wAJQePor668eXmgWut63pfhPQby/XTI5Uy0 kqRLKYYw25QXbJ2MQDiul1b9qL4fabqXhvT7XUL/AMQXviKwi1bTYfD+l3OoGayd9n2n9zG2 2NT95mxtyM9Rmra2J6XPWaK8Q+DP7R1n4y8N+GI/Ek9vF4u8QaprFpZ6ZpVtLIWgs7+4t/OZ RvMcYSKPdI5Cb2ABBYLUGm/tXeEdH8LeGptb1mbxDrXiA6m2mW3hrw/fPLqAs7owypDbASSb 49yBsn5truMIDhbq4z3aivIpP2qfh6vw+0jxdBf6hfWmrX0ml2OmWelXM2pz3sZcS2ws1TzR IhjfcCo2hck4wT0Pwn+NvhP412esXHhW7upzo95/Z+o299YT2c1rc7FdoXjmRWDKHAIxwcjt QB3lFeA6h8QPiT8WviX4u8MfDbUNB8J+H/CNxHp2peJNa02TU5bq/aJJmgt7dJoVVY0kjDu7 klnwq8E1p6X8Ztd+FngnxHqfxwgsdEi0PU4LCLxFosErWWqxTmNYZo4AZJYm3yiN0bcAykhi OgB7XRXjGrftZeCNFt9JE9j4rk1bUbaS+XQbfwxfy6nbWscrRNcXFqsRkhj3qQGcDdj5d1dh 4W+NXgzxtf8Ahy00LW49Uk8Q6TNrmmtBG5Se0ikijkfdtwpV541KNhskjHynAB29FeSeIf2q Ph14Z020vLrVbyf7bq99oNnbWWl3NxcXV/aSPHPbxxJGWZg6MBgYbHBI5rq/hf8AFfw78XtB uNU8Oz3LLaXT2N7Z39pLaXdlcoAXhnhlVXjcBlOCOQwIyCDQB2FFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAeP/tB+A9b8ca18IZtI0/7fb6H42ttW1I+YiCG0WzvI2kIYjd80sY2rk/N0wDXz vqn7MfxFuPhR8S/DkmjrdnR7BfC3gWBbyHdcaZ/aX2syklgI/wByLOHaxB/0LPRhX3RRQtBn y9a/slaD4+/aK+MXiv4heD4tT0vVZ9J/sO8lu2AljisEin+SKQEYkXHzgZxxkVpfFz4bah8P fEvwS1D4a/Dl9Y8PeC7/AFF59C8OyWdmYYp7GaFSizyxIcyS5POTyTkmvo+igDwjxb4y+KPj DwZHqGkfC2702Wx1KMan4S8S3WnSPrumtG6zRwSRTyxI6syOPMZQ2wqeGzXCfBr4YyN+0Bp3 jLwb8JNQ+CPheHTru31+2vTaWq65M/l/Z1WytZpIx5RV3847Sd20ZycfWVFAjwb9sHwF428V +A9I1n4aWS3vj7w/fvPpsbTpDlLi2ms5vnchQFS583GckwjHOBXB/Hb9l/W77TfhR4f8D2Sz 6Ja6fF4H8SN5scRXQTLaSSyEMRvIFmyBVy3+ktxjNfWtFC0Dc+cdYXxp8Ffjp8QPE+lfDrVv iFo3jW201rWTQbm0jlsrq2haDyJxcSx7YWG1xIu4KWfK9M437NPwB8W/Cnx54Pudcsbf7PY+ A59Nu7q1mRoYL6fVGu2tYxncVRX2htu0hBz2r6nooXcHqfGv7P8A+zz43+AvirRvGVlo9ze3 XiTVNT03xdo9xfxStbWb6jdT2F9bFpNqLGsgMkKNlhOW2l1Odb4C/A/xp4P8V/B+81rQ/skG gad4vh1CRriF/s8l7qkM1qMK5Lb4ldsrnGMNgnFfWlFC92y7A9b+Z8Tp4F8W/Cfx9oHik6Jb 6prK+P8AxZdWHhVtVtba71Ww1Ah1ntGkkEbSosav5bMrbGk6EV6N+yDrmqeLPF/x413VdGi0 G4uvGMcTWMN1HdCFotLskKNLGSjSAAbwpIV9y5OMn27x98NvCnxT0E6L4w8O6Z4m0rzBKLTV LVJ41cAgOoYHawBPzDnk1b8IeDNA+H/h+20Pwzoth4f0a2BENhptukEKZOSQigDJPJPUk5NC 0/L8v8geup8/ap4c8U/Bfxl8Tki8Bat8Rfhx4+uzqsqeGLuGLU9PupbaO2uYmSWaEtHIIkdZ In3ISwx0avNdC/Zz8aTeHfGNxYeDNQ8NaJrPifwneaX4V1jxD/aV5bWtjqEc15cSvJNIibkJ by1lc/uyOuAfuSihaWB6nzz4sj8X/CL9oDxP440vwFq3xC0LxXomnaft0Ge1W70+6tJLnCOl xLEPJkW5B3qx2shyvINeceCPhv8AET4D6p8MvFs/gW88Wypp/iO11nRfDN1bNNpk2p6nDfwo nnyRJJHGUMTMrYGNwyK+zaKNgPgu2tfHHwj174N3uteA57/xLd+O/GGrt4d0+9t5Z/Iuo7uf MEjOsbOI33AMylsbflJr6K/Z68L+If8AhJviX4+8RaFP4Tl8Z6rbXNpoN3LFJcW1tb2cVujz mJmRZZCjMVVm2jYCSQceral4Y0nWNY0jVb3T4LrUdIkklsLqRAXtmkjMblD2LIzKfYmtSmAU UUUgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAr5a/ai1zWbXWvHVnp97fIv /CI6W8NrbX8toDI+rNGxWRDmNmX5C68gfSvqWsPxB4F8N+LIr6LXPD+l6zHfWy2V0moWUc4u IAxcRSB1O5AxLbTxk5xS6r+ugzx74dfA2LUdM1qw8UeE9Y8L28zQPH9m+I+rak85XfnDmRGh C5HCnD7ufuivGbLwXcL8Cf2dJNITxB4i1bxhPY3OsWt1411K0bUH/sG9nbNz5rtCvmDzCsYC sUUEcDH1l4H+DfgD4Y3V1c+DvA/hzwpc3SCOebRNJt7N5UByFcxopYA84Nblt4T0SztdFtbf R7CC20Xb/ZcMdsipYYiaEeQAMR4id4/lx8rMvQkUxHkfiaG5+Ff7KfjG4SPUPB2p22jahcAx 6zNrc9jMUcJIlzcuC+Dsf5mVV9QATXgH2rxdpK3vw6nuLm21nUPEmiiDw/F44v7mykgnsrqZ 421p8XcAlNnNI0aRkhkiVVdZ2Y/dd1aw31tLb3MMdxbzIY5IZVDI6kYKkHggjjBrkLf4J/Dy z8JXfhW38B+GYPDF3L59zosej262c0mQd7whNjNwOSM8CgDg/gT431LSv2ebPUtQtNZ8Wapp t9fadPa2Eov7ovDqE0BijmkkBuEiChBM7BnSPewDEqO78GeOn+IkepWt14R8TeGI44wpbXLe O384PuBEbRyscjHPTGRiuo0XRdO8N6Ta6XpNha6XptrGIrezsoVhhhQdFRFACgegFXaAPlDw R4+1fVrXwv4A1PWrhdT+Ht3fz+LdQlndXmttNG2yad1+Y/ahNaXJ67limBByRXN6N+1P8S2e 90+STSbrUb210K80261DQJLGGIX+q29k7CD7Y00kOy43I0ghYlOQeQv19Z+E9E0/WNW1a10f T7bVdXWJdRvobVFnvRGpWMTOBukCqSq7icAkCue0L4IfDrwurDRvAPhjSQ0iykWOj28OXWVJ lY7UHIliikB7NGjdVBoW+oPbQ8Ysfix8SdT8WS/Ds+JPDWma/Z6nqkEvii50eQ29xDa2un3C Rra/aRtlYaj8x8wjZbSEDnK19O/aE8Z6lIPEcOueEbvw/ZeIdE8NTaNp1vJLJqRvkst13b3J mGFzeGSJPKYNFCSTlsp754k+FfgvxjZXVnr/AIQ0HW7S6uxfz2+pabDcRy3IRYxM6upDSBEV d552qBnAp7fDHwc3iiy8St4T0M+IrGEW9rq502H7XbxAYEccu3eqgEjAIGDQgPC2/aT8WX3h Hwne6RaaPqGtah4X1fxHd6bHG7PIbC6s0MMSiTKl0luEG7OJAnZWU43i79p7xx4h1LSovh7p sOpaR4gvtTOjalZWdtdSzWdgltHK2y6v7SNi9zLcYKyZEUGQhyXT6N0H4Y+DvCuuXus6L4T0 PSNYvmke61Cw06GC4nZyC5eRVDMWKqSSedoz0qDVfhH4F13wrZeGNS8F+H9Q8NWLK1ro91pc ElnbkZwY4WQopGT0A6mkB5p8Efit43+K3i6N9RbRNH0ay8PaXqF5p1nGt5JcXN3HOW8u6juG iESNCpXaJNwcjdwDXvFZ+m+HdK0aeSbT9Ms7GaSGK3eS2gSNmiiBESEgDKoGYKOi5OMZrQqm AUUUUgCiiigAooooAKKKKACiiigAooooAKKKKACiiigApksazRvG43I4KsPUHrT6xLfxt4eu rnSbeHXdNluNWEx0+JLpC155X+t8oZ+fZ/Ftzt74oA+fNN0W0+E1x8XPEeh6f9il0jxdplnH M4kmW20t7XR3vNqsSAgWS6kJA+U7j2Nc943/AGlPHizvP4dnsU0h7nVTpuoXUBWHUZIZ0S2t l+RmlDIxYLEPNlDAxnCnP1rpeqWetWEN9p93DfWUw3RXFvIJI3HTKsOCKI9VsptUuNNS7gfU beGO4mtFkBljikZ1jdl6hWMUoBPBMbY6GjrfyA+Wr/49+PbLxd4y0xrqF1tZnAe1sBPHo9oN StrdriZTsmjeO1mlmxIkkc3lNJG6xqVbi/FPx+8VfDvwbr95oHib+2rk3ut6lZX9zZIkGq+Q IDBEhbcX3Bm/dW8eZAS6vEo+b7jooWgzxzw58TtZb4oeJNB1u5t7LQ/DkUuoXeqTosUU1tdG NtPw54AUC9jY9c2yE/e55j9qa6FvqEQ1C71G0tP+EZ1ZtF/s+aaNn1sG3+yqnlkbrjG/ylOS cy4Bwa9m0LQfDN5a6vd6ZDZ31vrNxI9/OknnrcyIfKdWJJyFKFNnQYIwOa6SgSPkrw9qOv2f xxeCfVFt9QhvNSuPEesDUZy1tp5snaASWk0fkxRwym3CSZKvsLLu3zBavxA1DxCvirxSfC99 qlx8Tvt+p/ZYIZpWVtL/ALCmNo6xZ8vyTdfZiGAx55YZ3bhX1peatZadcWUF3eQW017Mbe1j mkCtPIEZyiAn5m2I7YHOEY9AaytE+IPhjxLrmo6NpPiLS9T1fTmZLyxs7yOWa2ZW2MJEUkqQ 3ynI4PFG4LQ8f+DOupY61rieBdP1TxP4GmfTo4rhr7cLa6Mb/a33XMgZsL9nLqmSJDJkb99b Xg/wvqV1rPxg0ebxPr/7/Vbd4tS89BcQo1lbu0cB2bI0+8g2KCMls78vXfx/FDwdLqmr6ani rRW1DR4pJ9StRfxeZZRpje8y7sxquRktgDIzWp4d8TaP4w0iHVdC1Sz1rTJiwjvNPuEnhcqx VgHUkHBBB54IIofvXCPunjPhfUtMf9mvwOPFuv31vDJ4T0mW/t0kkExytuGnmaMecI9x2ytk KEZyxAyR4lfalqS+AZorzUdQkurfSNaXwPd2NzdC3v8AVvtztam1y25wFa2SFJC/7pZdpePc x+xtW+IXhbQdJvNV1PxJpOn6ZZ3Js7m8ur2OOGGcEAxO5bCvkgbSc5qXWPHHh3w74bTxDqmu 6bp2gusbJql1dxx2zCQgRkSE7SGLLjnnIx1p315g6WNoZwM9aWuZT4neEJL7RbNfFOjNea3F 52l2/wBvi8y+j5+aFd2ZBweVz0rpqQBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFfKPiT4N/EDTda8W634d0iKfUfDF/8AavA4luYlFx9tuZrjU+rfuwVuTCA23/UccEGvq6ig D5Uh+DvxP8L/ABIsbDQNTvoPDWlxWFnot8j7rW3sobGOKSKeM3yqWaZJWP8AokpPmxkSDaPL o+Efgt4vvfE0Ut5onizQ7O5h8PW2sXN94oM0941t/ajXjJLHdPIIi9xB8oKbt5IQfNX1zRTD pY+R7f4Z/GWHxZ4Y8291n+zLFbWG3mW+M5tli1Ccym4Y6hF5m+2NuCzRXLMoKnawO5vhv4df FXT5NTg1fT/E2qeH21C1nvbdde8rUL+NTdCRIZRflCA720jOos/Mjj2GI/dH11RSA+MYfhn8 WtJ/4RG30rQNd0+00+8huQF1pZHjRtauJ7hZ2GoIhb7K0e5jDcGXeVyuDXqfwZ1rUbfVvFOo Xuo3ev8Ah3StVXwxos9tc/aEnWS7Z2nJLYfyhc29s7EllNjN6kV73RQB538RvAI8QePPht4h ttLhur7RNZkknvm2+ZbWr2F3G20sc4aWSEELyflJ4Xjifh/4M8QeH/FWpQ/2D4msfC7R38t/ Z32tQXKX19NqCTQz2eyUNEm1rlnBEORIgKuwbHvVFAHy/r3wv8aXU/iGw0PQ9ctdKknvtRvr PVtYt7my1iY6nFdxR2i+ZmHzEFwp3pEoEoV9+A6+i/Dnwz40j1zxFrUgtPDGka9r0moz6Dql kLm+EItLW3ULNBdeVCzPbySHiXiUZw2RXrdFAHzBqHwP1fQLPTV0nQNRh0TSvGt/qg0fw1eQ Wd1JZzWUsEcsLtIgUh5ASPMR9rPyfut0cnw/1Zfhb4O0/WvDWuanq+lR6a99H4d1S3sX3Rwz KBDiSOPdGzrv2GEHIZGOwJXvlFH/AAPwA+XbT4c/EW4eK31vRrjVr/Wm8OzS61JdWpOmpYak 9w0dyQ4Z5VhKYaFXV5XflR8x+oqKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKAP/2VBLAwQUAAYACAAAACEAT2WhBDYEAAAlEgAAJQAAAHBwdC9oYW5kb3V0TWFzdGVy cy9oYW5kb3V0TWFzdGVyMS54bWzsWN1u2zYUvh+wdxC4a0eWLNmyEbmInaQrkGRBnaLXtERZ QiiSI+m/FgP6Wtvj9El6SImxEwdb0DbAEORGPDo8/zwfKfH4zaam3opIVXGWouCoizzCMp5X bJGiDzfnnQR5SmOWY8oZSdGWKPRm/Osvx2JUApcv9SVWmkgP7DA1wikqtRYj31dZSWqsjrgg DOYKLmus4VUu/FziNdivqR92u32/xhVDrb58ij4viiojpzxb1oTpxogkFGvIQZWVUM6aeIo1 IYkCM1b7XkhjyDGb0dyM80XzvJbjYzxSnFb5eUWpfTGmyZRKb4VpiuaLAPnjY/+BFCkKkukL pc2cs2QJY1iJG0mIodjqrRQzYWbB+9XqWnpVDguDPIZrqL+xbSdaMfvKVpbwH6gvHIlHm0LW ZoTSeZsUwSpvzdO3oW20lzXMbMfNyj8ekc3Ks0ekfefA33NqsmqCO0yn1x1ELqP3UBfMFpR4 4V1yLmwlLnh2qzzGIa2mCnwKfbcgJ1LydUlwrgy7Sf5OsamIGUXp6a0AL2UuoZE/pejPJZbQ r61KI2eJXdQQ5Hx9yXNQw0vN0VMLGA4HQdJtCxPFA2ile9XBIyGVfkt47RkiRRJSt9bxqu2M nYhhM27ax/qgzFunaBiHsVXYm6krAz9a1SkC593GJx6Z2pyx3NIaV7ShfWPpkX40SZvk9WbC 860RmMMIhYCtAQItufyEvLXEsAjKVJAgj75jUPthEEWQsbYvNmfkyf2Z+f4MW9ZTTu1CYpaB 1RRpR061bLqK1wLrCzYTmRF0ZbvZfMRStIXTUPIrPiuxII/Vr5G1r00atoJKz/SWEkuvaNC2 WE6K95CnaY3ALJidhs2A2cYpcAZdcCIrTCGyEktF9K7pG92mqs6iofc8CfvYd9WG2bAIy6+x xCYCis2WS1jnw6w1bzLYLYldpf+EVXwIq94zwirX91EFYWx2mt+Lrl6SRP2g94qxF4AxD9MF fFlIa+OFga1/CLboGcFW6AdnWIM2e2z+8FmW9JM4DOxe8Yq2H0Lb/PVE+5kgGxyCLH5GkCma Xy3rx3BmsfGTTrVXtL0EtP2PzraC5hYwnydx3E+GwUknOZ0OOtFpdNoZDoOgE0yDqNeDMsaD s7/QXbNXOYGi2mDlIWT/zaMef/3y929fv/xjeNrOFOZn+Xu2ADu4X2BYG1iNlvKWsjJZTYb9 cJpMOpMgOoeshoPOyXk/7pzHvSiaTpKTaQ+yAp0gGmWS2J/5d7m7Bgiig4uAusokV7zQR9Av 7Y2CL/iaSMEre6kQdNubCftbH0TJIOiHgNp2F4DY3GijNdtKe1mQUXmJhTdfBCmiGnpVb4DK b4GaL0LDCw0vNDygcJYRpkGiJRwndJw7mZ7j9BwncpzIcWLHiR2n7zjwuVLSit1CMcyAvILT 3xuGo9rk7l3tjL8BAAD//wMAUEsDBBQABgAIAAAAIQB0sUijvgUAADIbAAAUAAAAcHB0L3Ro ZW1lL3RoZW1lMi54bWzsWU9v2zYUvw/YdyB0b/2vyeKgTpHYTrO2aYPE7dAjLdESY0oUSDqp b0N7HDBgWDfsMmC3HYZtBVpgl+7TZOuwdUC/wh4pWRZtOnGaFivQ2oBFUj++/+/pUb567UHM 0BERkvKk5dUuVz1EEp8HNAlb3t3e9qU1D0mFkwAznpCWNybSu7bx8UdX8bqKSEwQ7E/kOm55 kVLpeqUifVjG8jJPSQL3BlzEWMFUhJVA4GOgG7NKvVpdrcSYJh5KcAxk7wwG1Ceop0l6GxPi XQY/iZJ6wWfiQJMm+Q6DCoY1fZEi7LeZQEeYtbyq+XiVjauVAsDUPG7bfHJcDgiG9bPoGQBT 87i1qv4W9AwA+z7IP897a6tb7TZybAmUDedpN+DTbFr4Ev3G6bqVQNnwyuk6lkDZcGUO39ns dro2fQPKhqtz+Hqn3lnbtPAGFDGaDB3SNJuFtgVkwNmOE95sttuF8FNUpRQz2f5EWRGUxZyJ oxgfcrENAONcrGiC1DglA+wDro0Z7QuqGeB1gkt3siVfzi1pXkj6gqaq5d1IMcT5FPLq+c+v nj9Fr54/OXn47OThbyePHp08/NWxcQcnYXnjyx+/+vf7z9E/T394+fgbN16W8X/+8sUfv3/t Bqoy8MW3T/569uTFd1/+/dNjB3xT4H4Z3qMxkeg2OUb7PAbdHAxIX5xvRy/CtLxjMwklTrDe 40B3VWShb48xww7cFrEteE9QqGQO4PXRoSXwQSRGKne5BbwZxRZwl3O2xYVTp5uaV9kKoyR0 MxejMm4f4yMX7/aMf7ujFMKZuki2I2KJucfA5TgkCVFI3+NDQhzb7lNq2XWX+oJLPlDoPkVb mDpN0qN9K5qmm3ZoDH4ZuwQEf1u22b2Htjhzke+QIxsJWYGZiyRhlhmv45HCsVNiHLMy8hZW kUvIg7HwLYNLBZ4OCeOoGxApXXvuiLEl7k2oHm6377JxbCOFokMX8hbmvIzs8GE7wnHqlJkm URn7qRxCiGK0x5VTCG5niJ6DH3Cy0N33KLHcfXZu36WhJdI0QPSdkchLt1WEY5p8qMhLV+RN QZ0pMVuHF+Fmq2+bi4C++8W3g0fJHoF4/1B7P9Te97H2LsrnZSvutMia1nnSIBt68cJueUAZ O1BjRm5JU54lCB1sw6KZmE1Fc55GMMzZWbhQYDNGgqvPqIoOIpwCm5rhEMqcdChRyiUcCcyy k7Y5LVJQ3qytTA4ygMZqlwf5Aap8wCnImFlojpcTRg1NYFlmjU8uxqyWAZfkVjOizXMrVHZy M5fcmpANCOuDfW21nrGGiMGMBNruGYGJW964i2SEA5L7SOs9r0jN2G0Js62dbbUSt6YmewFu yzipzO7KAnYT713ESxMCUy/pvJ1JR5bYM3QMUq3UVzzk47TlDaCbgmGcAj2pCxBmYdLyfJWr cmYyzyrsDstadaHCFotUSNXBMsp2mVuTdyjJVP76yhVthzejgKMaLSdFY632P0phLmXXksGA +GrBynSa3+MjRcRBFByjPhuJfQxy61AFfQIq4ZlhYk1PBGSouQMzO/PzLHC8OTIvf1ga4bwm 6RSdaJjBzbiQwcxK4hWzGdlfUxWT8m9IlXIYv2eq6MiFtrURmEMVtAECIx2jLY8LFXGoQmlE /W0BjYPhBXIhSAstEmL6fbKWlRxN61ZGIytyYaT2aYgEhUqnIkHInsr1PINYLa+KeWbkhPI6 U4gr0+zaJ0eE9XT2rmr9PRRNqkluCIObdZo9z43RD3WivqudTxY2520Ppoyy/csyKxX90qOg eTERzvmozSrWHLv6ytKP2hQOH0j/QOGmwmfT/rbH98H7qOgoEQTipazxQDoVs1EfZM4WM26a 1Ntto6YuKPi+xeazZOyiXZox9unsXt/Y+ciydTmOHKauzKeobo8mBxkzm/tfifcPgXcHDkoj pmT2RukBHDXbk/8OgE7G0Wzd+A8AAP//AwBQSwMEFAAGAAgAAAAhAHSxSKO+BQAAMhsAABQA AABwcHQvdGhlbWUvdGhlbWUzLnhtbOxZT2/bNhS/D9h3IHRv/a/J4qBOkdhOs7Zpg8Tt0CMt 0RJjShRIOqlvQ3scMGBYN+wyYLcdhm0FWmCX7tNk67B1QL/CHilZFm06cZoWK9DagEVSP77/ 7+lRvnrtQczQERGS8qTl1S5XPUQSnwc0CVve3d72pTUPSYWTADOekJY3JtK7tvHxR1fxuopI TBDsT+Q6bnmRUul6pSJ9WMbyMk9JAvcGXMRYwVSElUDgY6Abs0q9Wl2txJgmHkpwDGTvDAbU J6inSXobE+JdBj+JknrBZ+JAkyb5DoMKhjV9kSLst5lAR5i1vKr5eJWNq5UCwNQ8btt8clwO CIb1s+gZAFPzuLWq/hb0DAD7Psg/z3trq1vtNnJsCZQN52k34NNsWvgS/cbpupVA2fDK6TqW QNlwZQ7f2ex2ujZ9A8qGq3P4eqfeWdu08AYUMZoMHdI0m4W2BWTA2Y4T3my224XwU1SlFDPZ /kRZEZTFnImjGB9ysQ0A41ysaILUOCUD7AOujRntC6oZ4HWCS3eyJV/OLWleSPqCpqrl3Ugx xPkU8ur5z6+eP0Wvnj85efjs5OFvJ48enTz81bFxBydheePLH7/69/vP0T9Pf3j5+Bs3Xpbx f/7yxR+/f+0GqjLwxbdP/nr25MV3X/7902MHfFPgfhneozGR6DY5Rvs8Bt0cDEhfnG9HL8K0 vGMzCSVOsN7jQHdVZKFvjzHDDtwWsS14T1CoZA7g9dGhJfBBJEYqd7kFvBnFFnCXc7bFhVOn m5pX2QqjJHQzF6Mybh/jIxfv9ox/u6MUwpm6SLYjYom5x8DlOCQJUUjf40NCHNvuU2rZdZf6 gks+UOg+RVuYOk3So30rmqabdmgMfhm7BAR/W7bZvYe2OHOR75AjGwlZgZmLJGGWGa/jkcKx U2IcszLyFlaRS8iDsfAtg0sFng4J46gbEClde+6IsSXuTagebrfvsnFsI4WiQxfyFua8jOzw YTvCceqUmSZRGfupHEKIYrTHlVMIbmeInoMfcLLQ3fcosdx9dm7fpaEl0jRA9J2RyEu3VYRj mnyoyEtX5E1BnSkxW4cX4Warb5uLgL77xbeDR8kegXj/UHs/1N73sfYuyudlK+60yJrWedIg G3rxwm55QBk7UGNGbklTniUIHWzDopmYTUVznkYwzNlZuFBgM0aCq8+oig4inAKbmuEQypx0 KFHKJRwJzLKTtjktUlDerK1MDjKAxmqXB/kBqnzAKciYWWiOlxNGDU1gWWaNTy7GrJYBl+RW M6LNcytUdnIzl9yakA0I64N9bbWesYaIwYwE2u4ZgYlb3riLZIQDkvtI6z2vSM3YbQmzrZ1t tRK3piZ7AW7LOKnM7soCdhPvXcRLEwJTL+m8nUlHltgzdAxSrdRXPOTjtOUNoJuCYZwCPakL EGZh0vJ8latyZjLPKuwOy1p1ocIWi1RI1cEyynaZW5N3KMlU/vrKFW2HN6OAoxotJ0VjrfY/ SmEuZdeSwYD4asHKdJrf4yNFxEEUHKM+G4l9DHLrUAV9AirhmWFiTU8EZKi5AzM78/MscLw5 Mi9/WBrhvCbpFJ1omMHNuJDBzEriFbMZ2V9TFZPyb0iVchi/Z6royIW2tRGYQxW0AQIjHaMt jwsVcahCaUT9bQGNg+EFciFICy0SYvp9spaVHE3rVkYjK3JhpPZpiASFSqciQcieyvU8g1gt r4p5ZuSE8jpTiCvT7NonR4T1dPauav09FE2qSW4Ig5t1mj3PjdEPdaK+q51PFjbnbQ+mjLL9 yzIrFf3So6B5MRHO+ajNKtYcu/rK0o/aFA4fSP9A4abCZ9P+tsf3wfuo6CgRBOKlrPFAOhWz UR9kzhYzbprU222jpi4o+L7F5rNk7KJdmjH26exe39j5yLJ1OY4cpq7Mp6hujyYHGTOb+1+J 9w+BdwcOSiOmZPZG6QEcNduT/w6ATsbRbN34DwAA//8DAFBLAwQUAAYACAAAACEA2P2Nj6wA AAC2AAAAEwAAAHBwdC90YWJsZVN0eWxlcy54bWwMzEkOgjAYQOG9iXdo/n0tQ1EkFMIgK3fq ASqUIelAaKMS491l+fKSL80/SqKXWOxkNAP/4AESujXdpAcGj3uDY0DWcd1xabRgsAoLebbf pTxxT3lzqxRX69CmaJtwBqNzc0KIbUehuD2YWejt9WZR3G25DKRb+HvTlSSB5x2J4pMG1Ime wTeqgiCitMCny+WIaUgDXHo0xnFU1tW5qf0qLH5Asj8AAAD//wMAUEsDBBQABgAIAAAAIQBW FNHNuwEAAIsEAAARAAAAcHB0L3ZpZXdQcm9wcy54bWyUVMFu2zAMvQ/YPwi6r5KT1suMOMWA Ybv0MCDZ7oKsOBpkSRDl1OnXj7KdNG59SG8m+fjeIyVr/dg1hhxVAO1sSbM7Tomy0lXa1iX9 s/v5ZUUJRGErYZxVJT0poI+bz5/Wvjhq9fw7ECSwUIiSHmL0BWMgD6oRcOe8sljbu9CIiGGo WRXEMxI3hi04z1kjtKVjf7il3+33WqofTraNsnEgCcqIiObhoD2c2fwtbD4oQJq+e2Jpg8PZ BDR/+xFTjNjogqqe1D4SeMFVPeT8gRLRRve9+tdCLCmn7Bq6c75HfrvPs/sZJHuvAkZX6jWU W1MNEQEr/M79CrpK3X1xrBxF2Eph8GyyPg8p2KxFAR3BI/2KJ4o9Ge81MXt6n2WXLl+4oGtt SYfF5Sqn5ITgxQgaJROsbtHpE8TLN8FG3CYu3oUXSryDki6yfNzJABmSq9VZ9JUkkV+GHQxN V+HaaLS93s3V1qYTL5dzE0+z8xPzftwz4KLAZuStiwp2qou3OEqiM5bepD/qacYCuBBVuMVS ns85mmY/auiteo23deuFxF+eyC7dI87xOZH9lUqfA8Xwjmz+AwAA//8DAFBLAwQUAAYACAAA ACEAgJu/+zkCAAB8BQAAEQAAAHBwdC9wcmVzUHJvcHMueG1srJRda9swFIbvB/sPwfeq9WXZ MU2KZCsw2MYY3Q/QbCUxky0jKW3H2H+f4nysoe0oo76RzNE553nfI3R989Cb2Z12vrPDIkFX MJnpobFtN2wWybfbFSiSmQ9qaJWxg14kP7VPbpbv312P5ei010NQIaZ+cbNYaPClWiTbEMYy TX2z1b3yV3bUQ4ytretViL9uk7ZO3ccGvUkxhCztVTckx3z3mny7XneNrm2z6yPAoYjTZiLx 2270p2rja6o91nGBtIwi/dbeR3H75bNybjoUfZpix8R0Omdabsy0jR0q45bXKh7wIW5nd8os EqfbJMbTvwfGUj+Ejz4cd7Od6xbJL1khlou6BgUqMKBc5IDLqgJSUEgk4UKQ/Pe+P6KlUV67 fYejXESfCO67xllv1+Gqsf3RuXS099qNtpvMQ/AkV5Xebb6fiVcrGL8D9KNmk4bIe4mNV7XA DOYA5QUFVEoBRD4vQC5FVhAmZV3wE/bezU+67VQVnPFvAn8gRkeHJ7rDOvmbnga5Z26M++R2 /1D7JMDYswEICamqZzMIORl3bvfCtHNWyTnlgEFSAYooBmIevWM1IjmM8jg+T7vtfKNc+6FX Gy3bLtQqqDc07wT8ZLQ1QRwyzEGcJweU4Dng+wsqBC8yxjDMEDwz6rXamTAx1mP3hngYvwi4 qjO54rwGUFYS0IxIMC8IApQJTISMC6EHwKxstsqFW6eaH/EF+qrXIt7q9oyZ/Q8mftHFyyt4 +WAu/wAAAP//AwBQSwMEFAAGAAgAAAAhAIVVevC2AgAAnAYAABAACAFkb2NQcm9wcy9hcHAu eG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFXf b9owEH6ftP/BylP7QENo11XIuGJUrJVKG4nQPbvOBawa27INLfvrd0kggzWdxnjhfnw5n798 d6HXb0tF1uC8NHoQJWfdiIAWJpd6Pohm2bhzFREfuM65MhoG0QZ8dM0+f6KpMxZckOAJltB+ EC1CsP049mIBS+7PMK0xUxi35AFdN49NUUgBN0aslqBD3Ot2L2N4C6BzyDu2KRjVFfvr8L9F cyPK/vxTtrFYj9EMllbxAOxZcf1C48anmQlcZXIJrNdNzi8w1QToD+Nyz5KvPRrXJh1aq6Tg AdliEymc8aYI5LFqgaTmFVxqpA403gciV+Cxt8obV62zR93xwgFoMl2YV3Jy0T8/pXELkKbc 8bnjduHZZYKQ3y6dKpmDZ1c03lr0wQT869K4NuitzHPQ2yyGD3w6mYyUtFViZ9Kp4ApGSB4r uPKApZsAvQVeCiPl0iFyHfprEME44uVPlMZlRJ65h5LyQbTmTnIdohpWO5WtrA+OjY0Onsw8 5DRugpW5j9235QU7rwBo/BVY18pQL3BE7eSI2hV9JJNBgT/iiKv2Iyqn4hHtQ4brIx4LfOeh hfCkt8941UTNd93PEA9QZKYljjOQyXS/1UNQayZz8LzCsQsfPbodpZZMKRm8BTEFmaT3U/KU PnhSDqTBF04ejO7gOL2UiO/OrCwppV5638y4td6d9yvcM7iFyMhoAU4f8N5YN44XKCuuHNK4 IXhcwMVy9+9Y0iF3x8I/wIOXDhFmFYQ5VGJj4XWRFbCoBLw88iPAt1+sRA7nuCc5OcGKSC6c vlPeTkN/qGZklpbrDRsqXEegOvcrAeWG2sXpvdQvfmYzc1MuxO3UHwbpdMHxNrhkm63QBOgt ys+pEj9acD2HfId5nyj351P9sWHJl7Mu/qpVuYuVG3D3FWC/AAAA//8DAFBLAwQUAAYACAAA ACEA5aFwfXABAACqAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfJLLbsIwEEX3lfoPkffBMa9SKxj1IboB qRK0VN1Z9gBWEzuyzevv6wQSQEVdxvfMyczY6WifZ9EWrFNGDxFpJSgCLYxUejVEH/NxPECR 81xLnhkNQ3QAh0bs/i4VBRXGwrs1BVivwEXBpB0VxRCtvS8oxk6sIeeuFQgdwqWxOffh065w wcUPXwFuJ0kf5+C55J7jUhgXjRGdlFI0ymJjs0ogBYYMctDeYdIi+Mx6sLm7WVAlF2Su/KGA m2gdNvTeqQbc7XatXadCQ/8Ef00ns2rUWOlyVwIQS6WgXvkM2OItmnnuNy7FzVmZCgvcG8um PAyro0+1MhsLm32F1WG55ow7Pw03slQgnw9sYnj0pGW4Mmd0iv8CZY2FrSqvlPXa/YppDtLT ho6/ABmFyehxD3Wy6Ly8zseIheEe4+QhJv05ITTp0nb/u+zuqv4szE8t/GsknZiQOCHzpEfb A9rpXhhrAas6vn5d7BcAAP//AwBQSwECLQAUAAYACAAAACEA+xroagICAADmEQAAEwAAAAAA AAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQBo+HShAwEA AOICAAALAAAAAAAAAAAAAAAAADsEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQBL9T3s vQAAADcBAAAgAAAAAAAAAAAAAAAAAG8HAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMy54bWwu cmVsc1BLAQItABQABgAIAAAAIQBjXCO0wAAAADcBAAAgAAAAAAAAAAAAAAAAAGoIAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcB AAAgAAAAAAAAAAAAAAAAAGgJAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNC54bWwucmVsc1BL AQItABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAAAGMKAABwcHQvc2xpZGVz L19yZWxzL3NsaWRlMi54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAA AAAAAAAAAAAAAF4LAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc1BLAQItABQA BgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAAAFkMAABwcHQvc2xpZGVzL19yZWxz L3NsaWRlNi54bWwucmVsc1BLAQItABQABgAIAAAAIQBL9T3svQAAADcBAAAgAAAAAAAAAAAA AAAAAFQNAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNy54bWwucmVsc1BLAQItABQABgAIAAAA IQBL9T3svQAAADcBAAAgAAAAAAAAAAAAAAAAAE8OAABwcHQvc2xpZGVzL19yZWxzL3NsaWRl OC54bWwucmVsc1BLAQItABQABgAIAAAAIQC954ybWAEAAK0IAAAfAAAAAAAAAAAAAAAAAEoP AABwcHQvX3JlbHMvcHJlc2VudGF0aW9uLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhACeNwZJq AwAAYREAABQAAAAAAAAAAAAAAAAA5xEAAHBwdC9wcmVzZW50YXRpb24ueG1sUEsBAi0AFAAG AAgAAAAhAJcFZXspAwAA/AwAABUAAAAAAAAAAAAAAAAAgxUAAHBwdC9zbGlkZXMvc2xpZGUy LnhtbFBLAQItABQABgAIAAAAIQCjOYcMwgMAACsOAAAVAAAAAAAAAAAAAAAAAN8YAABwcHQv c2xpZGVzL3NsaWRlMy54bWxQSwECLQAUAAYACAAAACEABXEMvx0DAAAfCQAAFQAAAAAAAAAA AAAAAADUHAAAcHB0L3NsaWRlcy9zbGlkZTQueG1sUEsBAi0AFAAGAAgAAAAhABz052DHAgAA RAoAABUAAAAAAAAAAAAAAAAAJCAAAHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBLAQItABQABgAI AAAAIQCNF19pawMAADIOAAAVAAAAAAAAAAAAAAAAAB4jAABwcHQvc2xpZGVzL3NsaWRlNS54 bWxQSwECLQAUAAYACAAAACEA4eEQdmIGAAAhFQAAFQAAAAAAAAAAAAAAAAC8JgAAcHB0L3Ns aWRlcy9zbGlkZTcueG1sUEsBAi0AFAAGAAgAAAAhAA+L3N89BgAAQRYAABUAAAAAAAAAAAAA AAAAUS0AAHBwdC9zbGlkZXMvc2xpZGU4LnhtbFBLAQItABQABgAIAAAAIQC7IjQQNwYAALMT AAAVAAAAAAAAAAAAAAAAAMEzAABwcHQvc2xpZGVzL3NsaWRlNi54bWxQSwECLQAUAAYACAAA ACEA1dGS8bwAAAA3AQAALQAAAAAAAAAAAAAAAAArOgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDExLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwA AAAAAAAAAAAAAAAAMjsAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxLnht bC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAAODwAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQyLnhtbC5yZWxzUEsBAi0AFAAGAAgA AAAhANXRkvG8AAAANwEAACwAAAAAAAAAAAAAAAAAPj0AAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQzLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG8AAAANwEAAC0A AAAAAAAAAAAAAAAARD4AAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQxMC54 bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAAEs/AABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0OS54bWwucmVsc1BLAQItABQABgAI AAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAAFFAAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0OC54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAs AAAAAAAAAAAAAAAAAFdBAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ny54 bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAAF1CAABw cHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0Ni54bWwucmVsc1BLAQItABQABgAI AAAAIQDV0ZLxvAAAADcBAAAsAAAAAAAAAAAAAAAAAGNDAABwcHQvc2xpZGVMYXlvdXRzL19y ZWxzL3NsaWRlTGF5b3V0NS54bWwucmVsc1BLAQItABQABgAIAAAAIQDV0ZLxvAAAADcBAAAs AAAAAAAAAAAAAAAAAGlEAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3NsaWRlTGF5b3V0NC54 bWwucmVsc1BLAQItABQABgAIAAAAIQAMWsfzVQcAAA44AAAhAAAAAAAAAAAAAAAAAG9FAABw cHQvc2xpZGVNYXN0ZXJzL3NsaWRlTWFzdGVyMS54bWxQSwECLQAUAAYACAAAACEAaaJfIRUB AADHBwAALAAAAAAAAAAAAAAAAAADTQAAcHB0L3NsaWRlTWFzdGVycy9fcmVscy9zbGlkZU1h c3RlcjEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAWm1O7KkCAACyCAAAIQAAAAAAAAAAAAAA AABiTgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDYueG1sUEsBAi0AFAAGAAgAAAAh ALW4ZcooAwAAxgsAACIAAAAAAAAAAAAAAAAASlEAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVM YXlvdXQxMC54bWxQSwECLQAUAAYACAAAACEAFvxopSMEAABTEgAAIQAAAAAAAAAAAAAAAACy VAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDkueG1sUEsBAi0AFAAGAAgAAAAhAKr5 k9hKBAAAuxIAACEAAAAAAAAAAAAAAAAAFFkAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlv dXQ4LnhtbFBLAQItABQABgAIAAAAIQCfUoLxgAQAADAcAAAhAAAAAAAAAAAAAAAAAJ1dAABw cHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54bWxQSwECLQAUAAYACAAAACEAm57OSFsC AABgBwAAIQAAAAAAAAAAAAAAAABcYgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcu eG1sUEsBAi0AFAAGAAgAAAAhAM0lR8dXAwAApgwAACIAAAAAAAAAAAAAAAAA9mQAAHBwdC9z bGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAUAAYACAAAACEAZgXjU8IDAAD7 DQAAIQAAAAAAAAAAAAAAAACNaAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDMueG1s UEsBAi0AFAAGAAgAAAAhAJ8xpXmbAwAAYRIAACEAAAAAAAAAAAAAAAAAjmwAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ0LnhtbFBLAQItABQABgAIAAAAIQC9Hju8iQMAAKcNAAAh AAAAAAAAAAAAAAAAAGhwAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQSwEC LQAUAAYACAAAACEAHFYJRwwDAACPCwAAIQAAAAAAAAAAAAAAAAAwdAAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDIueG1sUEsBAi0AFAAGAAgAAAAhAECPf283BwAAJTcAABQAAAAA AAAAAAAAAAAAe3cAAHBwdC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAMy/Im1P BgAAxiQAACEAAAAAAAAAAAAAAAAA5H4AAHBwdC9ub3Rlc01hc3RlcnMvbm90ZXNNYXN0ZXIx LnhtbFBLAQItABQABgAIAAAAIQCTqn2YuQAAACQBAAAwAAAAAAAAAAAAAAAAAHKFAABwcHQv aGFuZG91dE1hc3RlcnMvX3JlbHMvaGFuZG91dE1hc3RlcjEueG1sLnJlbHNQSwECLQAUAAYA CAAAACEAtM9YGbkAAAAkAQAALAAAAAAAAAAAAAAAAAB5hgAAcHB0L25vdGVzTWFzdGVycy9f cmVscy9ub3Rlc01hc3RlcjEueG1sLnJlbHNQSwECLQAKAAAAAAAAACEAHPBZYNwYAADcGAAA FwAAAAAAAAAAAAAAAAB8hwAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAA ACEAT2WhBDYEAAAlEgAAJQAAAAAAAAAAAAAAAACNoAAAcHB0L2hhbmRvdXRNYXN0ZXJzL2hh bmRvdXRNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQB0sUijvgUAADIbAAAUAAAAAAAAAAAA AAAAAAalAABwcHQvdGhlbWUvdGhlbWUyLnhtbFBLAQItABQABgAIAAAAIQB0sUijvgUAADIb AAAUAAAAAAAAAAAAAAAAAPaqAABwcHQvdGhlbWUvdGhlbWUzLnhtbFBLAQItABQABgAIAAAA IQDY/Y2PrAAAALYAAAATAAAAAAAAAAAAAAAAAOawAABwcHQvdGFibGVTdHlsZXMueG1sUEsB Ai0AFAAGAAgAAAAhAFYU0c27AQAAiwQAABEAAAAAAAAAAAAAAAAAw7EAAHBwdC92aWV3UHJv cHMueG1sUEsBAi0AFAAGAAgAAAAhAICbv/s5AgAAfAUAABEAAAAAAAAAAAAAAAAArbMAAHBw dC9wcmVzUHJvcHMueG1sUEsBAi0AFAAGAAgAAAAhAIVVevC2AgAAnAYAABAAAAAAAAAAAAAA AAAAFbYAAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEA5aFwfXABAACqAgAAEQAA AAAAAAAAAAAAAAABugAAZG9jUHJvcHMvY29yZS54bWxQSwUGAAAAADkAOQAiEQAAqLwAAAAA --------------040306080909010203080707-- From internet-drafts@ietf.org Wed Nov 20 09:16:19 2013 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 478F71AE091; Wed, 20 Nov 2013 09:16:19 -0800 (PST) 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 iVSMTlhnnv7y; Wed, 20 Nov 2013 09:16:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E92AD1AE0A4; Wed, 20 Nov 2013 09:16:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131120171617.11832.19433.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 09:16:17 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-05.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: Wed, 20 Nov 2013 17:16:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Author(s) : Edward Beili Filename : draft-ietf-opsawg-rfc5066bis-05.txt Pages : 7 Date : 2013-11-20 Abstract: This document updates RFC 5066. It amends that specification by informing the internet community about the transition of the EFM-CU- MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-rfc5066bis-05 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 Johannes.Merkle@secunet.com Wed Nov 20 09:32:31 2013 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 BEFA41AE4E2 for ; Wed, 20 Nov 2013 09:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.525] 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 mkeu6yn22GhS for ; Wed, 20 Nov 2013 09:32:29 -0800 (PST) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6A1AE4A8 for ; Wed, 20 Nov 2013 09:32:29 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id E10321A0079; Wed, 20 Nov 2013 18:32:21 +0100 (CET) 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 S602o6-AnLw3; Wed, 20 Nov 2013 18:32:20 +0100 (CET) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id C0D761A0066; Wed, 20 Nov 2013 18:32:20 +0100 (CET) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Nov 2013 18:32:10 +0100 Message-ID: <528CF219.9030408@secunet.com> Date: Wed, 20 Nov 2013 18:32:09 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: David Reid References: <201311192214.RAA22351@adminfs.snmp.com> In-Reply-To: <201311192214.RAA22351@adminfs.snmp.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2013 17:32:10.0248 (UTC) FILETIME=[7128A080:01CEE616] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 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, 20 Nov 2013 17:32:31 -0000 >> >> The new protocol is a straightforward adaptation of the protocols >> HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the SHA-256 based HMAC >> with truncation to 128 bits. Comments and suggestions are welcome. > > Would it be valuable to also add SHA-512? > > We actually implemented all 4 bit lengths of SHA2. I think that's overkill. > But 512 might be valuable. > HMAC-SHA-256-128 already provides a very high level of security. So I'm not sure if a SHA-512-based HMAC is really needed. The next thing I'm going to do is to write down the MIB spec. As soon as I find time for it... -- Johannes From reid@snmp.com Wed Nov 20 12:17:21 2013 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 411E81AE19A for ; Wed, 20 Nov 2013 12:17:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-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 FL-NvjhDH290 for ; Wed, 20 Nov 2013 12:17:19 -0800 (PST) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6E1AE1AD for ; Wed, 20 Nov 2013 12:17:19 -0800 (PST) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id PAA11044; Wed, 20 Nov 2013 15:17:12 -0500 (EST) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id PAA10611; Wed, 20 Nov 2013 15:15:56 -0500 (EST) Message-Id: <201311202015.PAA10611@adminfs.snmp.com> To: Johannes Merkle From: David Reid In-reply-to: Your message of Wed, 20 Nov 2013 18:32:09 +0100. <528CF219.9030408@secunet.com> Date: Wed, 20 Nov 2013 15:15:56 -0500 Sender: reid@snmp.com Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 20:17:21 -0000 > >> > >> The new protocol is a straightforward adaptation of the protocols > >> HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the SHA-256 based HMAC > >> with truncation to 128 bits. Comments and suggestions are welcome. > > > > Would it be valuable to also add SHA-512? > > > > We actually implemented all 4 bit lengths of SHA2. I think that's overkill. > > But 512 might be valuable. > > > > HMAC-SHA-256-128 already provides a very high level of security. So > I'm not sure if a SHA-512-based HMAC is really needed. That's fine with me. I have not specifically seen demand for 512, but wasn't sure what the broader market would want. > > The next thing I'm going to do is to write down the MIB spec. As soon > as I find time for it... OK. I'll be happy to review it when it's ready. -David Reid From ietfc@btconnect.com Thu Nov 21 06:14:50 2013 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 DE4BF1ADF44 for ; Thu, 21 Nov 2013 06:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_MED=-2.3] 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 iLzuUmmyx4ke for ; Thu, 21 Nov 2013 06:14:48 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id C35461ADF27 for ; Thu, 21 Nov 2013 06:14:48 -0800 (PST) Received: from mail154-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE015.bigfish.com (10.236.130.78) with Microsoft SMTP Server id 14.1.225.22; Thu, 21 Nov 2013 14:14:41 +0000 Received: from mail154-co9 (localhost [127.0.0.1]) by mail154-co9-R.bigfish.com (Postfix) with ESMTP id 408184A0211; Thu, 21 Nov 2013 14:14:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h304l1d11m1155h) Received: from mail154-co9 (localhost.localdomain [127.0.0.1]) by mail154-co9 (MessageSwitch) id 1385043279622339_12346; Thu, 21 Nov 2013 14:14:39 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.227]) by mail154-co9.bigfish.com (Postfix) with ESMTP id 9357112007F; Thu, 21 Nov 2013 14:14:39 +0000 (UTC) Received: from AM2PRD0710HT004.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 21 Nov 2013 14:14:39 +0000 Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.255.165.39) with Microsoft SMTP Server (TLS) id 14.16.383.1; Thu, 21 Nov 2013 14:14:30 +0000 Message-ID: <053d01cee6c3$9cd5edc0$4001a8c0@gateway.2wire.net> From: t.petch To: David Reid , Johannes Merkle References: <201311202015.PAA10611@adminfs.snmp.com> Date: Thu, 21 Nov 2013 14:10:27 +0000 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.248.133] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 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, 21 Nov 2013 14:14:51 -0000 ----- Original Message ----- From: "David Reid" To: "Johannes Merkle" Cc: Sent: Wednesday, November 20, 2013 8:15 PM Subject: Re: [OPSAWG] draft-hmac-sha-256-128-usm-snmp-00 > > >> > > >> The new protocol is a straightforward adaptation of the protocols > > >> HMAC-MD5-96 and HMAC-SHA-96 from RFC 3414 to the SHA-256 based HMAC > > >> with truncation to 128 bits. Comments and suggestions are welcome. > > > > > > Would it be valuable to also add SHA-512? > > > > > > We actually implemented all 4 bit lengths of SHA2. I think that's overkill. > > > But 512 might be valuable. > > > > > > > HMAC-SHA-256-128 already provides a very high level of security. So > > I'm not sure if a SHA-512-based HMAC is really needed. > > That's fine with me. I have not specifically seen demand for 512, but > wasn't sure what the broader market would want. SHA-384 is in Suite B, which is the argument I see advanced on the TLS list for its inclusion in ciphersuites (and which is where I learn most of my security:-( Separately, I have seen it stated that SHA-512 is no better than SHA-384. Tom Petch > > The next thing I'm going to do is to write down the MIB spec. As soon > > as I find time for it... > > OK. I'll be happy to review it when it's ready. > > -David Reid > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From haibin.song@huawei.com Thu Nov 21 18:17:14 2013 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 784941ADF60 for ; Thu, 21 Nov 2013 18:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 gKbg5mu87rh7 for ; Thu, 21 Nov 2013 18:17:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5E531ADF6E for ; Thu, 21 Nov 2013 18:17:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAO71292; Fri, 22 Nov 2013 02:17:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 02:16:47 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 02:17:00 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 22 Nov 2013 10:16:53 +0800 From: "Songhaibin (A)" To: Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] opsawg minutes uploaded Thread-Index: AQHO3p4G4/Qmq2oCtEmeYYkxxDuxfpowkvng Date: Fri, 22 Nov 2013 02:16:53 +0000 Message-ID: References: <5280698C.7010603@gmail.com> In-Reply-To: <5280698C.7010603@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [OPSAWG] opsawg minutes uploaded 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, 22 Nov 2013 02:17:14 -0000 Hi Melinda, Just read through the minutes, I believe the "Ning So (Huawei)" should be r= eplaced with "Ning Zong (Huawei)", cause I know both Ning Zong and Ning So = (Tata). And for my presentation part, "DPSI" is actually "ETSI". And I believe Dieg= o Lopez and Mehmet Ersue can be liaison to ETSI NFV as Diego is the technic= al manager and Mehmet is the MANO WG chair in ETSI NFV. Thanks, -Haibin > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Monday, November 11, 2013 1:22 PM > To: opsawg@ietf.org > Subject: [OPSAWG] opsawg minutes uploaded >=20 > Many thanks to Tom Taylor for his exceptionally good minutes, which we've > uploaded to http://www.ietf.org/proceedings/88/minutes/minutes-88-opsawg. >=20 > Over the next week or so we'll be following up on action items coming out= of > last weeks's session; in the meantime please review the minutes and let u= s > know of any corrections that need to be made, missing information, etc. >=20 > Again, many thanks to Tom for doing such a wonderful job on the minutes. >=20 > Melinda, Scott, Warren > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Thu Nov 21 19:21:41 2013 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 66FAB1AE2FF for ; Thu, 21 Nov 2013 19:21:41 -0800 (PST) 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 tNNY7c5d7zPV for ; Thu, 21 Nov 2013 19:21:40 -0800 (PST) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2C91AE2E7 for ; Thu, 21 Nov 2013 19:21:40 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id jt11so679707pbb.8 for ; Thu, 21 Nov 2013 19:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=oh6wdBXOhI4V57xq9jBLwOkqNCqikuyT5MmcmJGpLIo=; b=juStFK0niU9toIVU6MbV/6iVOOL32UkguRB7+vhYmM2XGGPygYxOqwE7lhyvzDB0g3 eF3Ssc/veYLEsp0S2DSkmFshVTfwmAS1J5k389o0b+cqe3BH/KADRhO3byypQmlQoTNW O6swbZp+rG9JoPtdj3XDd1bwcZ7JuIjaNqiO6znt2yWLSmBf84+UC/dTg8cFPwxi0SKj PFb7B2t6uFFUuRPx0OM0vL+9h8Z+RhukhLV60ZdVi31VlrbitfQDU+IEUpSC6yO6I9AU rD1Lrffi9xEdPC9ZsY6qIdYuoD7mcF32rLAGuBmKr8q2rvAzhye7yj2gGHmNh6t0BiG/ grxQ== X-Received: by 10.67.3.3 with SMTP id bs3mr9968411pad.46.1385090493328; Thu, 21 Nov 2013 19:21:33 -0800 (PST) Received: from spandex.local (63-140-91-14.dynamic.dsl.acsalaska.net. [63.140.91.14]) by mx.google.com with ESMTPSA id sg1sm49545060pbb.16.2013.11.21.19.21.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Nov 2013 19:21:32 -0800 (PST) Message-ID: <528ECDB8.8020507@gmail.com> Date: Thu, 21 Nov 2013 18:21:28 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Songhaibin (A)" References: <5280698C.7010603@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] opsawg minutes uploaded 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, 22 Nov 2013 03:21:41 -0000 Thanks, Haibin: I've updated the minutes to reflect your corrections. Melinda From warren@kumari.net Sat Nov 23 17:02:45 2013 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 D157A1AE267 for ; Sat, 23 Nov 2013 17:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, FRT_STRONG2=1.535, RP_MATCHES_RCVD=-0.525] 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 ES35oilB_kdi for ; Sat, 23 Nov 2013 17:02:44 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4D41AE0D2 for ; Sat, 23 Nov 2013 17:02:43 -0800 (PST) Received: from [192.168.0.187] (c-98-244-98-35.hsd1.va.comcast.net [98.244.98.35]) by vimes.kumari.net (Postfix) with ESMTPSA id 8E6BE1B400D3; Sat, 23 Nov 2013 20:02:35 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Warren Kumari In-Reply-To: <528CC502.5000707@pi.nu> Date: Sat, 23 Nov 2013 08:41:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <528CC502.5000707@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1510) Cc: opsawg@ietf.org, Lou Berger Subject: Re: [OPSAWG] Non Working Group Forming BoF on scaling MPLS VPN's in London 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, 24 Nov 2013 01:02:46 -0000 I'm sorry, but the subject line confuses me=85. Are MPLS VPN's in London special in any way? If so, why?! Do packets somehow know their geography? Can I use this for geolocation? W P.S: :-P On Nov 20, 2013, at 9:19 AM, Loa Andersson wrote: > Working Groups, >=20 > We will run a non-Working Group forming BoF in London to discuss > issues around Scaling of MPLS VPNs. >=20 > Lou Berger and I have accepted to chair this BoF, Vero Zheng will > take on the role as list admin and secretary. >=20 > We plan to kick-off the discussion on a problem statement as soon > as we have enough participants on the mailing list. >=20 > We gave a heads up for this BoF in Vancouver - these slides were > presented in the RTG Area Open Meeting. There have been some comments > and they will be update during the BoF preparation. >=20 > http://www.ietf.org/proceedings/88/slides/slides-88-rtgarea-5.pptx >=20 > We have started to prepare the BoF, and the discussion on how we set > it up will take place on a new mailing list: >=20 > scale@ietf.org >=20 > Please subscribe to this list through: >=20 > https://www.ietf.org/mailman/listinfo/scale >=20 > /Loa > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > = _____________________________________________= __ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg -- There were such things as dwarf gods. Dwarfs were not a naturally = religious species, but in a world where pit props could crack without = warning and pockets of fire damp could suddenly explode they'd seen the = need for gods as the sort of supernatural equivalent of a hard hat. = Besides, when you hit your thumb with an eight-pound hammer it's nice to = be able to blaspheme. It takes a very special and straong-minded kind of = atheist to jump up and down with their hand clasped under their other = armpit and shout, "Oh, random-fluctuations-in-the-space-time-continuum!" = or "Aaargh, primitive-and-outmoded-concept on a crutch!" -- Terry Pratchett From bclaise@cisco.com Mon Nov 25 09:21:48 2013 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 BBB021ADFAB for ; Mon, 25 Nov 2013 09:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 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.001, 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 iRZqzDN72mCn for ; Mon, 25 Nov 2013 09:21:46 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEA11ADF62 for ; Mon, 25 Nov 2013 09:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4930; q=dns/txt; s=iport; t=1385400106; x=1386609706; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ll63mkcf5iJOzfS+2tHTM1dcZFysg74gf6r7ZhFXRgg=; b=HYD3y2VhGsz2qJhKcl9PyUubKFdc2Qy7XzsCi3oJtyGqxVk3W67dV+HV yT3m0klTpMN+kFKuvPxkJcyL9ldw1ycW8n/7X6EWRf6h7iyWnZ6azO5CQ XqIYTOhwyqxKRVEQgvTQ2F70G+OyOPoxqPbgE2yeZmFwNZ22aLn1UpngC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkHANCGk1KQ/khL/2dsb2JhbAAXQoMHOIkos1GBKhZ0giYBAQRuCxAPHSUPAkYGDQEFAgEBh30NjxGufhePBweEMwOYFIEwhRSLToMpOw X-IronPort-AV: E=Sophos;i="4.93,769,1378857600"; d="scan'208,217";a="603239" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 25 Nov 2013 17:21:31 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAPHLPqM005510; Mon, 25 Nov 2013 17:21:26 GMT Message-ID: <52938715.40305@cisco.com> Date: Mon, 25 Nov 2013 18:21:25 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Edward Beili References: <528F93CB.7060604@cisco.com> In-Reply-To: <528F93CB.7060604@cisco.com> X-Forwarded-Message-Id: <528F93CB.7060604@cisco.com> Content-Type: multipart/alternative; boundary="------------080607070301090909040604" Cc: "opsawg@ietf.org" Subject: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 25 Nov 2013 17:21:48 -0000 This is a multi-part message in MIME format. --------------080607070301090909040604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please correct this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1 ]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The current revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1 ]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --------------080607070301090909040604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ed, all,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please correct this:
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. The header mentions incorrectly 'Standards Track' - this needs to be changed

Below is my AD review.

1.
OLD:
   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB module.  The current
   revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013
   [802.3.1].

NEW

   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB module [RFC5066].  The current
   revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013
   [802.3.1].
 
2.
   All further development of the EFM Copper Interfaces MIB will be done
   by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module.
   Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD
   be sent to the IEEE 803.3 working group.  Currently, the mailing list
   of the IEEE 802.3.1 task force, chartered with MIB development, is
   [stds-802-3-mib@listserv.ieee.org].
"SHOULD" is to be replaced by "should"
Justification: RFC 2119 section 6


Ed, how quickly can you produce a new version?

Regards, Benoit (OPS AD)



--------------080607070301090909040604-- From EdwardB@actelis.com Mon Nov 25 12:24:03 2013 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 A51131AE05C for ; Mon, 25 Nov 2013 12:24:03 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 k3eIZ135_jhy for ; Mon, 25 Nov 2013 12:24:00 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 603EC1AE062 for ; Mon, 25 Nov 2013 12:23:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,769,1378850400"; d="scan'208,217";a="2314974" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 25 Nov 2013 22:23:57 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Mon, 25 Nov 2013 22:23:58 +0200 From: Edward Beili To: Benoit Claise Date: Mon, 25 Nov 2013 22:23:56 +0200 Thread-Topic: AD review: draft-ietf-opsawg-rfc5066bis Thread-Index: Ac7qAtIK6wpEeS3SSsCFFJuK87mGEgAEbIDQ Message-ID: <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> In-Reply-To: <52938715.40305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Dilmail07act_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 25 Nov 2013 12:29:16 -0800 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 25 Nov 2013 20:24:03 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Dilmail07act_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical = or Workgroup summary: This document provides an updated security considerations section for IF-CA= P-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please c= orrect this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The curr= ent revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Dilmail07act_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Benoit,

I’ll = submit the new version in a couple of hours.

 

There’s one thing I would like you to consider for adding to the Tec= hnical or Workgroup summary:

 

This document= provides an updated security considerations section for IF-CAP-STACK-MIB

 

Regards,

-E.

 

Fr= om: Benoit Claise [mailto:bclaise@cisco.com]
Sen= t: Monday, November 25, 2013 19:21
To: Edward Beili
Cc:= opsawg@ietf.org; Romascanu, Dan (Dan)
Subject: AD review: dr= aft-ietf-opsawg-rfc5066bis

 

Ed, all,

First of al= l, as mentioned by Dan Romascanu in his write-up (https://d= atatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/),= please correct this:

(1) What type of R= FC is being requested (BCP, Proposed Standard, Internet Standard, Informati= onal, Experimental, or Historic)? Why is this the proper type of RFC? Is th= is type of RFC indicated in the title page header?

Proposed Standar= d. The header mentions incorrectly 'Standards Track' - this needs to be cha= nged


Below is my AD review.


1.
OLD:

 &nb=
sp; In 2011, the IEEE developed IEEE8023-EFM-CU-
 =
;  MIB module, based on the original EFM-CU-MIB module.  The curr=
ent
   revision of IEEE8023-EFM-CU-MIB is de=
fined in IEEE Std 802.3.1-2013
   [802.3.1].
 
NEW
 
 &nb=
sp; In 2011, the IEEE developed IEEE8023-EFM-CU-
 =
;  MIB module, based on the original EFM-CU-MIB module [RFC5066]. =
; The current
   revision of IEEE8023-EFM-CU=
-MIB, is defined in IEEE Std 802.3.1-2013
  =
 [802.3.1].
 =

2.

   Al=
l further development of the EFM Copper Interfaces MIB will be done
   by the IEEE 802.3 working group in the IEEE8023-=
EFM-CU-MIB module.
   Requests and comments =
pertaining to EFM Copper Interfaces MIB SHOULD
 &=
nbsp; be sent to the IEEE 803.3 working group.  Currently, the mailing=
 list
   of the IEEE 802.3.1 task force, cha=
rtered with MIB development, is
   [stds-802-3-mib@listserv.ieee.o=
rg].
 

"SHOULD" is to be replaced by "= ;should"
Justification: RFC 2119 section 6


Ed, how quic= kly can you produce a new version?

Regards, Benoit (OPS AD)

<= o:p>

 

= = --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Dilmail07act_-- From dromasca@avaya.com Mon Nov 25 13:29:06 2013 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 BD0251AE031 for ; Mon, 25 Nov 2013 13:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 fD5ELI5qsC5L for ; Mon, 25 Nov 2013 13:29:04 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8484D1ADFD3 for ; Mon, 25 Nov 2013 13:29:03 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUPAPu/k1KHCzI1/2dsb2JhbABZgkMjIThTpzAHjCSIT4EsFnSCJQEBAQEDEhtBCxACAQgNBAQBAQsdBzIUCQgCBAENBQgah18BDKMCmzwXjlYtBAYBgyCBEwOZRIU7iyeDKIIq X-IronPort-AV: E=Sophos;i="4.93,769,1378872000"; d="scan'208,217";a="33154911" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Nov 2013 16:29:01 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 25 Nov 2013 16:18:22 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Mon, 25 Nov 2013 22:28:58 +0100 From: "Romascanu, Dan (Dan)" To: Edward Beili , Benoit Claise Thread-Topic: AD review: draft-ietf-opsawg-rfc5066bis Thread-Index: AQHO6gLTdhH5L1It8Eq3AaSlUiTAk5o2uFMA//++KXA= Date: Mon, 25 Nov 2013 21:28:57 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12949650@AZ-FFEXMB04.global.avaya.com> References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA12949650AZFFEXMB04globa_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 25 Nov 2013 21:29:07 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA12949650AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical = or Workgroup summary: This document provides an updated security considerations section for IF-CA= P-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please c= orrect this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The curr= ent revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --_000_9904FB1B0159DA42B0B887B7FA8119CA12949650AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

 <= /p>

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit Claise
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,=

I’ll submit the new= version in a couple of hours.

 <= /p>

There’s one thing I= would like you to consider for adding to the Technical or Workgroup summar= y:

 <= /p>

This document provides= an updated security considerations section for IF-CAP-STACK-MIB=

 <= /p>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, November 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan)
Subject: AD review: draft-ietf-opsawg-rfc5066bis

 

Ed, all,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwri= teup/), please correct this:

(1) What type of RFC is being requested (BCP, Propos= ed Standard, Internet Standard, Informational, Experimental, or Historic)? = Why is this the proper type of RFC? Is this type of RFC indicated in the ti= tle page header?

Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed


Below is my AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module. =
; The current


   revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 80=
2.3.1-2013


   [802.3.1].=



 


NEW


 


   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module [RFC5=
066].  The current


   revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 8=
02.3.1-2013


   [802.3.1].=



 


2.


   All further development of the EFM Copper Interfaces MIB =
will be done


   by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MI=
B module.


   Requests and comments pertaining to EFM Copper Interfaces=
 MIB SHOULD


   be sent to the IEEE 803.3 working group.  Currently,=
 the mailing list


   of the IEEE 802.3.1 task force, chartered with MIB develo=
pment, is


   [stds=
-802-3-mib@listserv.ieee.org].


 


"SHOULD" is=
 to be replaced by "should"

Justification: RFC 2119 section 6 





Ed, how quickly can you produce a new version?



Regards, Benoit (OPS AD)

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA12949650AZFFEXMB04globa_-- From dromasca@avaya.com Mon Nov 25 13:29:48 2013 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 2D7941ADFDF for ; Mon, 25 Nov 2013 13:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 nkk933vPdpcK for ; Mon, 25 Nov 2013 13:29:45 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id E39031ADFD3 for ; Mon, 25 Nov 2013 13:29:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUPADzAk1KHCzI1/2dsb2JhbABZgkMjIThTpzAHjCSIT4EsFnSCJQEBAQEDEhtBCxACAQgNBAQBAQsdBzIUCQgCBAENBQgah18BDKMCmzwXjlYtBAYBgyCBEwOZRIU7iyeDKIIq X-IronPort-AV: E=Sophos;i="4.93,769,1378872000"; d="scan'208,217";a="38409634" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Nov 2013 16:29:44 -0500 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 25 Nov 2013 16:19:06 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0146.000; Mon, 25 Nov 2013 22:29:41 +0100 From: "Romascanu, Dan (Dan)" To: Edward Beili , Benoit Claise Thread-Topic: AD review: draft-ietf-opsawg-rfc5066bis Thread-Index: AQHO6gLTdhH5L1It8Eq3AaSlUiTAk5o2uFMA//++aVA= Date: Mon, 25 Nov 2013 21:29:40 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA12949661AZFFEXMB04globa_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 25 Nov 2013 21:29:48 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA12949661AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Ed's comment about the updated security considerations section= . Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical = or Workgroup summary: This document provides an updated security considerations section for IF-CA= P-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please c= orrect this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The curr= ent revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --_000_9904FB1B0159DA42B0B887B7FA8119CA12949661AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Ed’s c= omment about the updated security considerations section.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit Claise
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,=

I’ll submit the new= version in a couple of hours.

 <= /p>

There’s one thing I= would like you to consider for adding to the Technical or Workgroup summar= y:

 <= /p>

This document provides= an updated security considerations section for IF-CAP-STACK-MIB=

 <= /p>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, November 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan)
Subject: AD review: draft-ietf-opsawg-rfc5066bis

 

Ed, all,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwri= teup/), please correct this:

(1) What type of RFC is being requested (BCP, Propos= ed Standard, Internet Standard, Informational, Experimental, or Historic)? = Why is this the proper type of RFC? Is this type of RFC indicated in the ti= tle page header?

Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed


Below is my AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module. =
; The current


   revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 80=
2.3.1-2013


   [802.3.1].=



 


NEW


 


   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module [RFC5=
066].  The current


   revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 8=
02.3.1-2013


   [802.3.1].=



 


2.


   All further development of the EFM Copper Interfaces MIB =
will be done


   by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MI=
B module.


   Requests and comments pertaining to EFM Copper Interfaces=
 MIB SHOULD


   be sent to the IEEE 803.3 working group.  Currently,=
 the mailing list


   of the IEEE 802.3.1 task force, chartered with MIB develo=
pment, is


   [stds=
-802-3-mib@listserv.ieee.org].


 


"SHOULD" is=
 to be replaced by "should"

Justification: RFC 2119 section 6 





Ed, how quickly can you produce a new version?



Regards, Benoit (OPS AD)

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA12949661AZFFEXMB04globa_-- From bclaise@cisco.com Mon Nov 25 14:30:12 2013 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 2BF9B1AE078 for ; Mon, 25 Nov 2013 14:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 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.001, 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 GCmVQ2-1Zo_D for ; Mon, 25 Nov 2013 14:30:09 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0781AE06D for ; Mon, 25 Nov 2013 14:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15153; q=dns/txt; s=iport; t=1385418609; x=1386628209; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=eGPLdhB6y8KhvyEjNYmjutNojjphkyRPVKEDxsuX/Aw=; b=eL4S/suPaQ3QqS5aHzTy1TzvZcyQnBMQd6kk48s/8aUm8t8a7u0umBwB 9BSRREsfRPDAWDxMAPy6ajTT0gFltCItZtByidgvkDMOyQ7XoWIPtcDlE WhKXJEqphJYKsmWkf7kNrJspV0rzlzcls2QzIsJGEReTEtyYEAOdZtmJZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0HAEnOk1KQ/khL/2dsb2JhbAAXQoJDRDiJKLNVgSwWdIIlAQEBBC1BCgEQCxEEAQEKFggHCQMCAQIBNAkIBgEMAQUCAQGHfQ2PSa8NF48HBgGEMwOYFIEwhRSLToMpOw X-IronPort-AV: E=Sophos;i="4.93,770,1378857600"; d="scan'208,217";a="1224291" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 25 Nov 2013 22:30:07 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAPMTxvD025215; Mon, 25 Nov 2013 22:30:01 GMT Message-ID: <5293CF67.5050908@cisco.com> Date: Mon, 25 Nov 2013 23:29:59 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" , Edward Beili References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> Content-Type: multipart/alternative; boundary="------------050205070708050404050803" Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 25 Nov 2013 22:30:12 -0000 This is a multi-part message in MIME format. --------------050205070708050404050803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, The write-up has been updated. Regards, Benoit > > I agree with Ed's comment about the updated security considerations > section. > > Regards, > > Dan > > *From:*Edward Beili [mailto:EdwardB@actelis.com] > *Sent:* Monday, November 25, 2013 10:24 PM > *To:* Benoit Claise > *Cc:* opsawg@ietf.org; Romascanu, Dan (Dan) > *Subject:* RE: AD review: draft-ietf-opsawg-rfc5066bis > > Benoit, > > I'll submit the new version in a couple of hours. > > There's one thing I would like you to consider for adding to the > Technical or Workgroup summary: > > *This document provides an updated security considerations section for > IF-CAP-STACK-MIB* > > Regards, > > -E. > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Monday, November 25, 2013 19:21 > *To:* Edward Beili > *Cc:* opsawg@ietf.org ; Romascanu, Dan (Dan) > *Subject:* AD review: draft-ietf-opsawg-rfc5066bis > > Ed, all, > > First of all, as mentioned by Dan Romascanu in his write-up > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), > please correct this: > > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why is > this the proper type of RFC? Is this type of RFC indicated in the > title page header? > > Proposed Standard. The header mentions incorrectly 'Standards Track' - > this needs to be changed > > > Below is my AD review. > > > 1. > OLD: > > In 2011, the IEEE developed IEEE8023-EFM-CU- > MIB module, based on the original EFM-CU-MIB module. The current > revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 > [802.3.1 ]. > > NEW > > In 2011, the IEEE developed IEEE8023-EFM-CU- > MIB module, based on the original EFM-CU-MIB module [RFC5066]. The current > revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 > [802.3.1 ]. > > > 2. > > All further development of the EFM Copper Interfaces MIB will be done > by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. > Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD > be sent to the IEEE 803.3 working group. Currently, the mailing list > of the IEEE 802.3.1 task force, chartered with MIB development, is > [stds-802-3-mib@listserv.ieee.org ]. > > > "SHOULD" is to be replaced by "should" > Justification: RFC 2119 section 6 > > > Ed, how quickly can you produce a new version? > > Regards, Benoit (OPS AD) > --------------050205070708050404050803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

The write-up has been updated.

Regards, Benoit

I agree with Ed’s comment about the updated security considerations section.

 

Regards,

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit Claise
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,

I’ll submit the new version in a couple of hours.

 

There’s one thing I would like you to consider for adding to the Technical or Workgroup summary:

 

This document provides an updated security considerations section for IF-CAP-STACK-MIB

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, November 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subject: AD review: draft-ietf-opsawg-rfc5066bis

 

Ed, all,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please correct this:

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. The header mentions incorrectly 'Standards Track' - this needs to be changed


Below is my AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB module.  The current
   revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013
   [802.3.1].
 
NEW
 
   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB module [RFC5066].  The current
   revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013
   [802.3.1].
 

2.

   All further development of the EFM Copper Interfaces MIB will be done
   by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module.
   Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD
   be sent to the IEEE 803.3 working group.  Currently, the mailing list
   of the IEEE 802.3.1 task force, chartered with MIB development, is
   [stds-802-3-mib@listserv.ieee.org].
 

"SHOULD" is to be replaced by "should"
Justification: RFC 2119 section 6


Ed, how quickly can you produce a new version?

Regards, Benoit (OPS AD)

 


--------------050205070708050404050803-- From EdwardB@actelis.com Mon Nov 25 14:39:15 2013 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 6A03C1AE07C for ; Mon, 25 Nov 2013 14:39:15 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 5MCpzGvKDvyT for ; Mon, 25 Nov 2013 14:39:11 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 19FA61AE06A for ; Mon, 25 Nov 2013 14:39:10 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,770,1378850400"; d="scan'208,217";a="2315289" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 26 Nov 2013 00:39:10 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Tue, 26 Nov 2013 00:39:10 +0200 From: Edward Beili To: Benoit Claise , "Romascanu, Dan (Dan)" Date: Tue, 26 Nov 2013 00:39:07 +0200 Thread-Topic: AD review: draft-ietf-opsawg-rfc5066bis Thread-Index: Ac7qLebvsjxY2c4cRR2UquAHmY/zdwAAA8ng Message-ID: <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> In-Reply-To: <5293CF67.5050908@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Filmail07act_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 25 Nov 2013 14:43:24 -0800 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 25 Nov 2013 22:39:15 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Filmail07act_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan, Benoit, I'm having a little difficulty with the header, namely changing "Indented S= tatus" from "Standards Track" to "Proposed Standard". I'm using xml2rfc, which automatically converts to: Intended status: Standards Track I don't see a way to change that in the xml, except for fixing it manually = in the final .txt file, after xml2rfc conversion. Am I missing something in the xml? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, November 26, 2013 00:30 To: Romascanu, Dan (Dan); Edward Beili Cc: opsawg@ietf.org Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis Hi, The write-up has been updated. Regards, Benoit I agree with Ed's comment about the updated security considerations section= . Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical = or Workgroup summary: This document provides an updated security considerations section for IF-CA= P-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please c= orrect this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The curr= ent revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Filmail07act_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dan, Benoit,

I= 217;m having a little difficulty with the header, namely changing “In= dented Status” from “Standards Track” to “Proposed = Standard”.

&nbs= p;

I’m using xml2rfc, whi= ch automatically converts

=  

<rfc category=3D= "std" …>

 

to:

 

Intended status: Standards Track<= /span>

 

I don’t see a way to change that in the xml= , except for fixing it manually in the final .txt file, after xml2rfc conve= rsion.

 

Am I missing something in the xml?

 

<= p class=3DMsoNormal>Regards,

-E.

 <= /o:p>

From:= Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tue= sday, November 26, 2013 00:30
To: Romascanu, Dan (Dan); Edward Be= ili
Cc: opsawg@ietf.org
Subject: Re: AD review: draft-i= etf-opsawg-rfc5066bis

 

Hi,

The write-up has= been updated.

Regards, Benoit

I ag= ree with Ed’s comment about the updated security considerations secti= on.

 

Regards,

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit Claise
Cc:= opsawg@ietf.org; Romascanu, Dan= (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,

I’ll submit the new version in a couple of hours.

 

There’s one thing I would like you to consider for ad= ding to the Technical or Workgroup summary:

 

This document provides an updated security considerations section for I= F-CAP-STACK-MIB

&nbs= p;

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, Nove= mber 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subjec= t: AD review: draft-ietf-opsawg-rfc5066bis

<= /div>

 

Ed, all= ,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/sh= epherdwriteup/), please correct this:

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the prope= r type of RFC? Is this type of RFC indicated in the title page header?
=
Proposed Standard. The header mentions incorrectly 'Standards Track' - = this needs to be changed


Below is my= AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB mo=
dule.  The current
   revision of IEEE8=
023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013
&nb=
sp;  [802.3.1].
 
NEW
 
   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB modu=
le [RFC5066].  The current
   revision =
of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013
   [802.3.1].
 
2.
   All further development of the EFM Copper Interfaces MIB wi=
ll be done
   by the IEEE 802.3 working grou=
p in the IEEE8023-EFM-CU-MIB module.
   Requ=
ests and comments pertaining to EFM Copper Interfaces MIB SHOULD=

   be sent to the IEEE 803.3 working group.  Curr=
ently, the mailing list
   of the IEEE 802.3=
.1 task force, chartered with MIB development, is
&nbs=
p;  [stds-802-3-mi=
b@listserv.ieee.org].
 
"SHOULD" is to be =
replaced by "should"
Justification: RFC 2119 section 6 

Ed, how quickly can you produce a new version?

Regards, Benoit =
(OPS AD)

 

 

= --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D49Filmail07act_-- From ietfdbh@comcast.net Mon Nov 25 15:39:56 2013 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 B0B211AE081 for ; Mon, 25 Nov 2013 15:39:56 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 RF3SaA_tUv6e for ; Mon, 25 Nov 2013 15:39:53 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1C21ADFE1 for ; Mon, 25 Nov 2013 15:39:53 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta15.westchester.pa.mail.comcast.net with comcast id tzCk1m0061HzFnQ5FzftCZ; Mon, 25 Nov 2013 23:39:53 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta14.westchester.pa.mail.comcast.net with comcast id tzfr1m01e2yZEBF3azfs6d; Mon, 25 Nov 2013 23:39:53 +0000 From: "ietfdbh" To: "'Edward Beili'" , "'Benoit Claise'" , "'Romascanu, Dan \(Dan\)'" References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> Date: Mon, 25 Nov 2013 18:39:54 -0500 Message-ID: <018b01ceea37$a5187f30$ef497d90$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018C_01CEEA0D.BC4647C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0wkN7qRE4yc6eVe2Vf2Hxf7xhBAHbu670AoaAF/kDO+aaUAHD5qWDAey5NpCZkHM6kA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385422793; bh=/butFRgVW/ZYT0WVEfDN+UrEvaNZJGhGIKqhq2iMYCQ=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=kaPO5/S1wnYi09f9xWJ5sePfrLkQKLlJwCmPTztfoDmGSOj37DIMy4PRHywsCy6V2 dUN6nlsEsPAGnu+Hh2G1FEUUcwQYgtqdyhkPCezecqKe28+Ja9UvQ33hkp93Lq2M2k 6XPFYMHlNiyW7AcBtaH5fr28jVjJuZQHnW3n7c/faMZ7gdwLOEmRHvWyEAbJnHnlK7 jhZZ1wYlaTyPjJfqW7cIcxh9mNvhHG2yki7H08KARtLL6A8v5QtFbCaXXI+tyoBmmL kwwAhKXN+YojJcQOC0fEAEzS97uQF2nBvDxVg/EdgnfRkVm35oXFFQ5m1bpX/+xQ5X vqv9kqrL9gDuQ== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 25 Nov 2013 23:39:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018C_01CEEA0D.BC4647C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am of the impression that "standards track" is appropriate in the internet draft. The IESG telechat is used to tune this finer, and the RFC gets the appropriate status level. This hasn't changed, has it? David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili Sent: Monday, November 25, 2013 5:39 PM To: Benoit Claise; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Dan, Benoit, I'm having a little difficulty with the header, namely changing "Indented Status" from "Standards Track" to "Proposed Standard". I'm using xml2rfc, which automatically converts to: Intended status: Standards Track I don't see a way to change that in the xml, except for fixing it manually in the final .txt file, after xml2rfc conversion. Am I missing something in the xml? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, November 26, 2013 00:30 To: Romascanu, Dan (Dan); Edward Beili Cc: opsawg@ietf.org Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis Hi, The write-up has been updated. Regards, Benoit I agree with Ed's comment about the updated security considerations section. Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical or Workgroup summary: This document provides an updated security considerations section for IF-CAP-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwrite up/), please correct this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1 ]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The current revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1 ]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) ------=_NextPart_000_018C_01CEEA0D.BC4647C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am of the impression that “standards track” is = appropriate in the internet draft.

The IESG telechat is used to tune this finer, and the RFC gets the = appropriate status level.

This hasn’t changed, has it?

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward = Beili
Sent: Monday, November 25, 2013 5:39 PM
To: = Benoit Claise; Romascanu, Dan (Dan)
Cc: = opsawg@ietf.org
Subject: Re: [OPSAWG] AD review: = draft-ietf-opsawg-rfc5066bis

 

Dan, Benoit,

I’m having a little difficulty with the header, namely changing = “Indented Status” from “Standards Track” to = “Proposed Standard”.

 

I’m using xml2rfc, which automatically = converts

 

<rfc category=3D"std" = …>

 

to:

 

Intended status: Standards Track

 

I don’t see a way to change that in the xml, except for fixing = it manually in the final .txt file, after xml2rfc = conversion.

 

Am I missing something in the xml?

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com] =
Sent: Tuesday, November 26, 2013 00:30
To: = Romascanu, Dan (Dan); Edward Beili
Cc: opsawg@ietf.org
Subject: = Re: AD review: = draft-ietf-opsawg-rfc5066bis

 

Hi,

The write-up has been = updated.

Regards, Benoit

I agree with Ed’s comment about the updated security = considerations section.

 

Regards,

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB@actelis.com] =
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit = Claise
Cc: opsawg@ietf.org; Romascanu, Dan = (Dan)
Subject: RE: AD review: = draft-ietf-opsawg-rfc5066bis

 

Benoit,

I’ll submit the new version in a couple of = hours.

 

There’s one thing I would like you to consider for adding to = the Technical or Workgroup summary:

 

This document provides an updated security considerations section for = IF-CAP-STACK-MIB

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com] =
Sent: Monday, November 25, 2013 19:21
To: Edward = Beili
Cc: opsawg@ietf.org; Romascanu, Dan = (Dan)
Subject: AD review: = draft-ietf-opsawg-rfc5066bis

 

Ed, = all,

First of all, as mentioned by Dan Romascanu in his write-up = (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066= bis/shepherdwriteup/), please correct this:

(1) What type of RFC is being requested (BCP, Proposed = Standard, Internet Standard, Informational, Experimental, or Historic)? = Why is this the proper type of RFC? Is this type of RFC indicated in the = title page header?

Proposed Standard. The header mentions = incorrectly 'Standards Track' - this needs to be = changed


Below is my AD = review.


1.
OLD:

   In =
2011, the IEEE developed =
IEEE8023-EFM-CU-
   MIB module, based on =
the original EFM-CU-MIB module.  The =
current
   revision of =
IEEE8023-EFM-CU-MIB is defined in IEEE Std =
802.3.1-2013
   [802.3.1].
 
NEW
 
   =
In 2011, the IEEE developed =
IEEE8023-EFM-CU-
   MIB module, based on =
the original EFM-CU-MIB module [RFC5066].  The =
current
   revision of =
IEEE8023-EFM-CU-MIB, is defined in IEEE Std =
802.3.1-2013
   [802.3.1].
 
2.
   All further =
development of the EFM Copper Interfaces MIB will be =
done
   by the IEEE 802.3 working group =
in the IEEE8023-EFM-CU-MIB module.
   =
Requests and comments pertaining to EFM Copper Interfaces MIB =
SHOULD
   be sent to the IEEE 803.3 =
working group.  Currently, the mailing =
list
   of the IEEE 802.3.1 task force, =
chartered with MIB development, is
   [stds-802-3-mib@listserv.=
ieee.org].
 
"SHOULD" is =
to be replaced by "should"
Justification: RFC 2119 section =
6 


Ed, how quickly can you produce a new =
version?

Regards, Benoit (OPS AD)

 

 

------=_NextPart_000_018C_01CEEA0D.BC4647C0-- From internet-drafts@ietf.org Mon Nov 25 23:39:04 2013 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 EDDA31AE1B4; Mon, 25 Nov 2013 23:39:03 -0800 (PST) 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 IVIAhXnG4ACZ; Mon, 25 Nov 2013 23:39:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB08D1AE1AC; Mon, 25 Nov 2013 23:39:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126073902.9736.46046.idtracker@ietfa.amsl.com> Date: Mon, 25 Nov 2013 23:39:02 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-06.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, 26 Nov 2013 07:39:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operations and Management Area Working Gr= oup Working Group of the IETF. Title : Ethernet in the First Mile Copper (EFMCu) Interfaces MIB Author(s) : Edward Beili Filename : draft-ietf-opsawg-rfc5066bis-06.txt Pages : 7 Date : 2013-11-25 Abstract: This document updates RFC 5066. It amends that specification by informing the internet community about the transition of the EFM-CU- MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-rfc5066bis-06 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 EdwardB@actelis.com Tue Nov 26 00:03:00 2013 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 09C441A1F55 for ; Tue, 26 Nov 2013 00:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 VCT7Gr-cZYSp for ; Tue, 26 Nov 2013 00:02:55 -0800 (PST) Received: from mail2.actelis.com (mail2.actelis.com [212.150.9.5]) by ietfa.amsl.com (Postfix) with ESMTP id 87E101A1F3F for ; Tue, 26 Nov 2013 00:02:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,773,1378850400"; d="scan'208,217";a="2316076" Received: from unknown (HELO il-mail07.actelis.net) ([212.150.9.1]) by mail2.actelis.com with ESMTP; 26 Nov 2013 10:02:53 +0200 Received: from il-mail07.actelis.net ([10.0.0.60]) by il-mail07.actelis.net ([10.0.0.60]) with mapi; Tue, 26 Nov 2013 10:02:53 +0200 From: Edward Beili To: 'Benoit Claise' , "'Romascanu, Dan (Dan)'" Date: Tue, 26 Nov 2013 10:02:50 +0200 Thread-Topic: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Thread-Index: AQH0wkN7qRE4yc6eVe2Vf2Hxf7xhBAHbu670AoaAF/kDO+aaUAHD5qWDAey5NpCZkHM6kIAAh4yw Message-ID: <4087887712E5C648B9F72BB9D912FD4602F6D393D4AC@il-mail07.actelis.net> References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> <018b01ceea37$a5187f30$ef497d90$@comcast.net> In-Reply-To: <018b01ceea37$a5187f30$ef497d90$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4087887712E5C648B9F72BB9D912FD4602F6D393D4ACilmail07act_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 26 Nov 2013 08:03:00 -0000 --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D4ACilmail07act_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Benoit, Dan, I just posted the new versions with the following changes: 1. Modified according to the AD review comments from Benoit. 2. Changed the references names to start with a letter instead of a number,= i.e. instead of [802.3] and [802.3.1] use [IEEE802.3] and [IEEE802.3.1], d= ue to complaints from the newest version of xml2rfc, which has stricter che= cking of the xml. Also added a tag in the xml to appease xml2rfc. 3. Changed reference to 802.3 MIB Email reflector, using [LIST802.3.1] inst= ead of [stds-802-3-mib@listserv.ieee.org], since xml2rfc was complaining ab= out the @ character, besides the stds-802-3-mib@listserv.ieee.org address is really not the mailing list addr= ess, but rather the address of the list owner, used only for (un)subscripti= on. The relevant paragraph now looks as follows: OLD> All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. NEW> All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB should be sent to the IEEE 802.3.1 task force, currently chartered with MIB development, via its mailing list [LIST802.3.1]. 4. The "Intended Status" still says "Standards Track" in the draft, as per = the comment from David. I also looked at my previous RFCs - the Intended St= atus was always changed during publication, not by the author. Regards, -E. From: ietfdbh [mailto:ietfdbh@comcast.net] Sent: Tuesday, November 26, 2013 01:40 To: Edward Beili; 'Benoit Claise'; 'Romascanu, Dan (Dan)' Cc: opsawg@ietf.org Subject: RE: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis I am of the impression that "standards track" is appropriate in the interne= t draft. The IESG telechat is used to tune this finer, and the RFC gets the appropri= ate status level. This hasn't changed, has it? David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili Sent: Monday, November 25, 2013 5:39 PM To: Benoit Claise; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Dan, Benoit, I'm having a little difficulty with the header, namely changing "Indented S= tatus" from "Standards Track" to "Proposed Standard". I'm using xml2rfc, which automatically converts to: Intended status: Standards Track I don't see a way to change that in the xml, except for fixing it manually = in the final .txt file, after xml2rfc conversion. Am I missing something in the xml? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, November 26, 2013 00:30 To: Romascanu, Dan (Dan); Edward Beili Cc: opsawg@ietf.org Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis Hi, The write-up has been updated. Regards, Benoit I agree with Ed's comment about the updated security considerations section= . Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical = or Workgroup summary: This document provides an updated security considerations section for IF-CA= P-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please c= orrect this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The curr= ent revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D4ACilmail07act_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Benoit, Dan,

I ju= st posted the new versions with the following changes:

 

1. Modified according to the AD review comments from Benoit.=

 

2. Changed the references names to start with a l= etter instead of a number, i.e. instead of [802.3] and [802.3.1] use [IEEE8= 02.3] and [IEEE802.3.1], due to complaints from the newest version of xml2r= fc, which has stricter checking of the xml. Also added a <date/> tag = in the xml to appease xml2rfc.

 

3. Changed ref= erence to 802.3 MIB Email reflector, using [LIST802.3.1] instead of [stds-8= 02-3-mib@listserv.ieee.org], since xml2rfc was complaining about the @ char= acter, besides the stds= -802-3-mib@listserv.ieee.org address is really not the mailing list add= ress, but rather the address of the list owner, used only for (un)subscript= ion. The relevant paragraph now looks as follows:

 

OLD>

   = All further development of the EFM Copper Interfaces MIB will be done<= /o:p>

   by the IEEE 802.3 = working group in the IEEE8023-EFM-CU-MIB module.

   Requests and comments pertaining to EFM= Copper Interfaces MIB SHOULD

   be sent to the IEEE 803.3 working group.  Currently, = the mailing list

 &nb= sp; of the IEEE 802.3.1 task force, chartered with MIB development, is=

   [stds-802-3-mib@l= istserv.ieee.org].

&n= bsp;

NEW><= /p>

   All further development of the = EFM Copper Interfaces MIB will be done

   by the IEEE 802.3 working group in the IEEE8023-E= FM-CU-MIB module.

 &n= bsp; Requests and comments pertaining to EFM Copper Interfaces MIB should

   be sent to the= IEEE 802.3.1 task force, currently chartered with MIB

   development, via its mailing list= [LIST802.3.1].

 = ;

4. The “Intended Status= ” still says “Standards Track” in the draft, as per the c= omment from David. I also looked at my previous RFCs – the Intended S= tatus was always changed during publication, not by the author.<= /span>

 

Regards,

-E.

 

 

From: ietfdbh [mai= lto:ietfdbh@comcast.net]
Sent: Tuesday, November 26, 2013 01:40<= br>To: Edward Beili; 'Benoit Claise'; 'Romascanu, Dan (Dan)'
C= c: opsawg@ietf.org
Subject: RE: [OPSAWG] AD review: draft-iet= f-opsawg-rfc5066bis

<= o:p> 

I am of the impression that “standards track” is appropriate i= n the internet draft.

The IESG telechat is used to tune this finer, and the RFC get= s the appropriate status level.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>This hasn’t changed, has it?

 

D= avid Harrington

<= p class=3DMsoNormal>ietfdbh@comcast.net

+1-603-828-1401

From: OPSAW= G [mailto:opsawg-bounces@ietf.or= g] On Behalf Of Edward Beili
Sent: Monday, November 25= , 2013 5:39 PM
To: Benoit Claise; Romascanu, Dan (Dan)
Cc:<= /b> opsawg@ietf.org
Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis

 

Dan, Benoit,

I= 217;m having a little difficulty with the header, namely changing “In= dented Status” from “Standards Track” to “Proposed = Standard”.

&nbs= p;

I’m using xml2rfc, whi= ch automatically converts

=  

<rfc category=3D= "std" …>

 

to:

 

Intended status: Standards Track<= /span>

 

I don’t see a way to change that in the xml= , except for fixing it manually in the final .txt file, after xml2rfc conve= rsion.

 

Am I missing something in the xml?

 

<= p class=3DMsoNormal>Regards,

-E.

 <= /o:p>

From:= Benoit Claise [mailto:bc= laise@cisco.com]
Sent: Tuesday, November 26, 2013 00:30
<= b>To: Romascanu, Dan (Dan); Edward Beili
Cc: opsawg@ietf.org
Subject: Re: AD review: dr= aft-ietf-opsawg-rfc5066bis

 

Hi,

The write-u= p has been updated.

Regards, Benoit

= I agree with Ed’s comment about the updated security considerations s= ection.

 

Regards,

 

Dan

 <= /o:p>

 

 

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent= : Monday, November 25, 2013 10:24 PM
To: Benoit Claise
= Cc: opsawg@ietf.org; Romascanu, = Dan (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,

I’ll submit the new version in a couple of hours.=

 

There’s one thing I would like you to consider fo= r adding to the Technical or Workgroup summary:

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>This document provides an updated security considerations section for= IF-CAP-STACK-MIB

&nbs= p;

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, Nove= mber 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subjec= t: AD review: draft-ietf-opsawg-rfc5066bis

<= /div>

 

Ed, all= ,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/sh= epherdwriteup/), please correct this:

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the prope= r type of RFC? Is this type of RFC indicated in the title page header?
=
Proposed Standard. The header mentions incorrectly 'Standards Track' - = this needs to be changed


Below is my= AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB mo=
dule.  The current
   revision of IEEE8=
023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013
&nb=
sp;  [802.3.1].
 
NEW
 
   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB modu=
le [RFC5066].  The current
   revision =
of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013
   [802.3.1].
 
2.
   All further development of the EFM Copper Interfaces MIB wi=
ll be done
   by the IEEE 802.3 working grou=
p in the IEEE8023-EFM-CU-MIB module.
   Requ=
ests and comments pertaining to EFM Copper Interfaces MIB SHOULD=

   be sent to the IEEE 803.3 working group.  Curr=
ently, the mailing list
   of the IEEE 802.3=
.1 task force, chartered with MIB development, is
&nbs=
p;  [stds-802-3-mi=
b@listserv.ieee.org].
 
"SHOULD" is to be =
replaced by "should"
Justification: RFC 2119 section 6 

Ed, how quickly can you produce a new version?

Regards, Benoit =
(OPS AD)

 

 

= --_000_4087887712E5C648B9F72BB9D912FD4602F6D393D4ACilmail07act_-- From dromasca@avaya.com Tue Nov 26 02:10:05 2013 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 D4C3D1AE144 for ; Tue, 26 Nov 2013 02:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 RayHHGuK86as for ; Tue, 26 Nov 2013 02:10:01 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 65BA11AD698 for ; Tue, 26 Nov 2013 02:10:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgQAI9ylFLGmAcV/2dsb2JhbABWA4JDIyE4U6ccAwSMJIhPgSoWdIIlAQEBAQMSG0ELEAIBCA0EBAEBCxYBBgcyFAkIAgQBDQUIGodNAw8BDKNGkz4IiAwXjkUhDAQGARGDD4ETA4VWk26FO4smgyiCKg X-IronPort-AV: E=Sophos;i="4.93,773,1378872000"; d="scan'208,217";a="38486133" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Nov 2013 05:09:59 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 26 Nov 2013 05:03:16 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Tue, 26 Nov 2013 11:09:57 +0100 From: "Romascanu, Dan (Dan)" To: ietfdbh , 'Edward Beili' , 'Benoit Claise' Thread-Topic: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Thread-Index: AQHO6gLTdhH5L1It8Eq3AaSlUiTAk5o2uFMA//++aVCAAGTPgIAAAo2A//+sZwCAAL44YA== Date: Tue, 26 Nov 2013 10:09:56 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12949D96@AZ-FFEXMB04.global.avaya.com> References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> <018b01ceea37$a5187f30$ef497d90$@comcast.net> In-Reply-To: <018b01ceea37$a5187f30$ef497d90$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA12949D96AZFFEXMB04globa_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 26 Nov 2013 10:10:06 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA12949D96AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not sure. The IESG telechat can change the status, but the document ne= eds to be clear about what the authors (based on the consensus of the WG ) = are asking. In this case it does not matter, but for a document that obsole= tes a previous RFC (as 5066bis originally was written) 'Standards Track' is= ambiguous - do the authors intent to recycle at Proposed or do they plan t= o go to Internet Standard? As shepherd the text in the template did not provide me the option of 'Stan= dards Track': (1) What type of RFC is being requested (BCP, Proposed Standard, Internet= Standard, Informational, Experimental, or Historic)? Why is this the prope= r type of RFC? Is this type of RFC indicated in the title page header? One way or the other, there seems to be a lack of sync between xml2rfc and = the write-up template which should be corrected. Regards, Dan From: ietfdbh [mailto:ietfdbh@comcast.net] Sent: Tuesday, November 26, 2013 1:40 AM To: 'Edward Beili'; 'Benoit Claise'; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: RE: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis I am of the impression that "standards track" is appropriate in the interne= t draft. The IESG telechat is used to tune this finer, and the RFC gets the appropri= ate status level. This hasn't changed, has it? David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili Sent: Monday, November 25, 2013 5:39 PM To: Benoit Claise; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Dan, Benoit, I'm having a little difficulty with the header, namely changing "Indented S= tatus" from "Standards Track" to "Proposed Standard". I'm using xml2rfc, which automatically converts to: Intended status: Standards Track I don't see a way to change that in the xml, except for fixing it manually = in the final .txt file, after xml2rfc conversion. Am I missing something in the xml? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, November 26, 2013 00:30 To: Romascanu, Dan (Dan); Edward Beili Cc: opsawg@ietf.org Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis Hi, The write-up has been updated. Regards, Benoit I agree with Ed's comment about the updated security considerations section= . Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical = or Workgroup summary: This document provides an updated security considerations section for IF-CA= P-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please c= orrect this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The curr= ent revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --_000_9904FB1B0159DA42B0B887B7FA8119CA12949D96AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not sure. The IESG t= elechat can change the status, but the document needs to be clear about wha= t the authors (based on the consensus of the WG ) are asking. In this case it does not matter, but for a document that obsoletes a previ= ous RFC (as 5066bis originally was written) ‘Standards Track’ i= s ambiguous – do the authors intent to recycle at Proposed or do they= plan to go to Internet Standard?

 <= /p>

As shepherd the text in t= he template did not provide me the option of ‘Standards Track’:

 <= /p>

(1)   What type of RFC is being = requested (BCP, Proposed Standard, Internet Standard, Informational, Experi= mental, or Historic)? Why is this the proper type of RFC? Is this type of R= FC indicated in the title page header?

One way or the other, the= re seems to be a lack of sync between xml2rfc and the write-up template whi= ch should be corrected.  

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

From: ietfdbh [mailto:ietfdbh@comcast.net]
Sent: Tuesday, November 26, 2013 1:40 AM
To: 'Edward Beili'; 'Benoit Claise'; Romascanu, Dan (Dan)
Cc: opsawg@ietf.org
Subject: RE: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis

 

I am of the impression that “standards track” is appropriate= in the internet draft.

The IESG telechat is used= to tune this finer, and the RFC gets the appropriate status level.

This hasn’t changed= , has it?

 <= /p>

David Harrington

= ietfdbh@comcast.net

+1-603-828-1401<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili
Sent: Monday, November 25, 2013 5:39 PM
To: Benoit Claise; Romascanu, Dan (Dan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis

 

Dan, Benoit,

I’m having a little= difficulty with the header, namely changing “Indented Status” = from “Standards Track” to “Proposed Standard”.=

 <= /p>

I’m using xml2rfc, = which automatically converts

 <= /p>

<rfc category=3D"= std" …>

 <= /p>

to:

 <= /p>

Intended status: Standards Track

 

I don’t see a way t= o change that in the xml, except for fixing it manually in the final .txt f= ile, after xml2rfc conversion.

 <= /p>

Am I missing something in= the xml?

 <= /p>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, November 26, 2013 00:30
To: Romascanu, Dan (Dan); Edward Beili
Cc: opsawg@ietf.org
Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis

 

Hi,

The write-up has been updated.

Regards, Benoit

I agree with Ed’s c= omment about the updated security considerations section.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit Claise
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,=

I’ll submit the new= version in a couple of hours.

 <= /p>

There’s one thing I= would like you to consider for adding to the Technical or Workgroup summar= y:

 <= /p>

This document provides= an updated security considerations section for IF-CAP-STACK-MIB=

 <= /p>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, November 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan)
Subject: AD review: draft-ietf-opsawg-rfc5066bis

 

Ed, all,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwri= teup/), please correct this:

(1) What type of RFC is being requested (BCP, Propos= ed Standard, Internet Standard, Informational, Experimental, or Historic)? = Why is this the proper type of RFC? Is this type of RFC indicated in the ti= tle page header?

Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed


Below is my AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module. =
; The current


   revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 80=
2.3.1-2013


   [802.3.1].=



 


NEW


 


   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module [RFC5=
066].  The current


   revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 8=
02.3.1-2013


   [802.3.1].=



 


2.


   All further development of the EFM Copper Interfaces MIB =
will be done


   by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MI=
B module.


   Requests and comments pertaining to EFM Copper Interfaces=
 MIB SHOULD


   be sent to the IEEE 803.3 working group.  Currently,=
 the mailing list


   of the IEEE 802.3.1 task force, chartered with MIB develo=
pment, is


   [stds=
-802-3-mib@listserv.ieee.org].


 


"SHOULD" is=
 to be replaced by "should"

Justification: RFC 2119 section 6 





Ed, how quickly can you produce a new version?



Regards, Benoit (OPS AD)

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA12949D96AZFFEXMB04globa_-- From bclaise@cisco.com Tue Nov 26 02:10:17 2013 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 A3DD01AD698 for ; Tue, 26 Nov 2013 02:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 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.001, 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 usElLMDkJSiK for ; Tue, 26 Nov 2013 02:10:13 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id BEBF81AE164 for ; Tue, 26 Nov 2013 02:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25376; q=dns/txt; s=iport; t=1385460613; x=1386670213; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=6KMUztIBkJ5rmOXskB1MuqprnSLq07biD0fHXAN8CJc=; b=aYPWNheQrw2nJNj/ce1sI+GHDLx2wNBhFtR/E82BjawjZKyVYEz6zAoF OeTvOOUpyTpv8weYYIchqo4rJBBtm/2ucS2Ae4ezcXP5x904wkNYuKpGu xF6ozuT5imh5SFPd1HOUUqDktZX6RGGDbHVEYIaC+0NDdE8vKAx9atmhC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAGAERylFKQ/khN/2dsb2JhbAAXPwOCQ0Q4iSizQYEqFnSCJQEBAQQtQQoBEAsRBAEBChYBBwcJAwIBAgE0CQgGAQwBBQIBAYdrAw8Nj2+nHwiIDBeOZhAGARGEIgOFVpI+gTCFFItNgyk7 X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="scan'208,217";a="641956" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 26 Nov 2013 10:10:11 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAQAA4pD022159; Tue, 26 Nov 2013 10:10:06 GMT Message-ID: <5294737C.4080506@cisco.com> Date: Tue, 26 Nov 2013 11:10:04 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ietfdbh , "'Edward Beili'" , "'Romascanu, Dan (Dan)'" References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> <018b01ceea37$a5187f30$ef497d90$@comcast.net> In-Reply-To: <018b01ceea37$a5187f30$ef497d90$@comcast.net> Content-Type: multipart/alternative; boundary="------------090807020501030104060605" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 26 Nov 2013 10:10:17 -0000 This is a multi-part message in MIME format. --------------090807020501030104060605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David, Ed, After double-checking, David is right. Regards, Benoit > > I am of the impression that "standards track" is appropriate in the > internet draft. > > The IESG telechat is used to tune this finer, and the RFC gets the > appropriate status level. > > This hasn't changed, has it? > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > *From:*OPSAWG [mailto:opsawg-bounces@ietf.org] *On Behalf Of *Edward Beili > *Sent:* Monday, November 25, 2013 5:39 PM > *To:* Benoit Claise; Romascanu, Dan (Dan) > *Cc:* opsawg@ietf.org > *Subject:* Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis > > Dan, Benoit, > > I'm having a little difficulty with the header, namely changing > "Indented Status" from "Standards Track" to "Proposed Standard". > > I'm using xml2rfc, which automatically converts > > > > to: > > Intended status: *Standards Track* > > ** > > I don't see a way to change that in the xml, except for fixing it > manually in the final .txt file, after xml2rfc conversion. > > Am I missing something in the xml? > > Regards, > > -E. > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Tuesday, November 26, 2013 00:30 > *To:* Romascanu, Dan (Dan); Edward Beili > *Cc:* opsawg@ietf.org > *Subject:* Re: AD review: draft-ietf-opsawg-rfc5066bis > > Hi, > > The write-up has been updated. > > Regards, Benoit > > I agree with Ed's comment about the updated security > considerations section. > > Regards, > > Dan > > *From:*Edward Beili [mailto:EdwardB@actelis.com] > *Sent:* Monday, November 25, 2013 10:24 PM > *To:* Benoit Claise > *Cc:* opsawg@ietf.org ; Romascanu, Dan (Dan) > *Subject:* RE: AD review: draft-ietf-opsawg-rfc5066bis > > Benoit, > > I'll submit the new version in a couple of hours. > > There's one thing I would like you to consider for adding to the > Technical or Workgroup summary: > > *This document provides an updated security considerations section > for IF-CAP-STACK-MIB* > > Regards, > > -E. > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Monday, November 25, 2013 19:21 > *To:* Edward Beili > *Cc:* opsawg@ietf.org ; Romascanu, Dan (Dan) > *Subject:* AD review: draft-ietf-opsawg-rfc5066bis > > Ed, all, > > First of all, as mentioned by Dan Romascanu in his write-up > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), > please correct this: > > (1) What type of RFC is being requested (BCP, Proposed Standard, > Internet Standard, Informational, Experimental, or Historic)? Why > is this the proper type of RFC? Is this type of RFC indicated in > the title page header? > > Proposed Standard. The header mentions incorrectly 'Standards > Track' - this needs to be changed > > > Below is my AD review. > > > 1. > OLD: > > In 2011, the IEEE developed IEEE8023-EFM-CU- > > MIB module, based on the original EFM-CU-MIB module. The current > > revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 > > [802.3.1 ]. > > > > NEW > > > > In 2011, the IEEE developed IEEE8023-EFM-CU- > > MIB module, based on the original EFM-CU-MIB module [RFC5066]. The current > > revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 > > [802.3.1 ]. > > > > 2. > > All further development of the EFM Copper Interfaces MIB will be done > > by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. > > Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD > > be sent to the IEEE 803.3 working group. Currently, the mailing list > > of the IEEE 802.3.1 task force, chartered with MIB development, is > > [stds-802-3-mib@listserv.ieee.org ]. > > > > "SHOULD" is to be replaced by "should" > Justification: RFC 2119 section 6 > > > Ed, how quickly can you produce a new version? > > Regards, Benoit (OPS AD) > --------------090807020501030104060605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
David, Ed,

After double-checking, David is right.

Regards, Benoit

I am of the impression that “standards track” is appropriate in the internet draft.

The IESG telechat is used to tune this finer, and the RFC gets the appropriate status level.

This hasn’t changed, has it?

 

David Harrington

ietfdbh@comcast.net

+1-603-828-1401

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili
Sent: Monday, November 25, 2013 5:39 PM
To: Benoit Claise; Romascanu, Dan (Dan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis

 

Dan, Benoit,

I’m having a little difficulty with the header, namely changing “Indented Status” from “Standards Track” to “Proposed Standard”.

 

I’m using xml2rfc, which automatically converts

 

<rfc category="std" …>

 

to:

 

Intended status: Standards Track

 

I don’t see a way to change that in the xml, except for fixing it manually in the final .txt file, after xml2rfc conversion.

 

Am I missing something in the xml?

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, November 26, 2013 00:30
To: Romascanu, Dan (Dan); Edward Beili
Cc: opsawg@ietf.org
Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis

 

Hi,

The write-up has been updated.

Regards, Benoit

I agree with Ed’s comment about the updated security considerations section.

 

Regards,

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit Claise
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,

I’ll submit the new version in a couple of hours.

 

There’s one thing I would like you to consider for adding to the Technical or Workgroup summary:

 

This document provides an updated security considerations section for IF-CAP-STACK-MIB

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, November 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascanu, Dan (Dan)
Subject: AD review: draft-ietf-opsawg-rfc5066bis

 

Ed, all,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please correct this:

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard. The header mentions incorrectly 'Standards Track' - this needs to be changed


Below is my AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB module.  The current
   revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013
   [802.3.1].
 
NEW
 
   In 2011, the IEEE developed IEEE8023-EFM-CU-
   MIB module, based on the original EFM-CU-MIB module [RFC5066].  The current
   revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013
   [802.3.1].
 

2.

   All further development of the EFM Copper Interfaces MIB will be done
   by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module.
   Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD
   be sent to the IEEE 803.3 working group.  Currently, the mailing list
   of the IEEE 802.3.1 task force, chartered with MIB development, is
   [stds-802-3-mib@listserv.ieee.org].
 

"SHOULD" is to be replaced by "should"
Justification: RFC 2119 section 6


Ed, how quickly can you produce a new version?

Regards, Benoit (OPS AD)

 

 


--------------090807020501030104060605-- From dromasca@avaya.com Tue Nov 26 02:17:08 2013 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 4AA561AE189 for ; Tue, 26 Nov 2013 02:17:08 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 2-ym5zEn6aXO for ; Tue, 26 Nov 2013 02:17:05 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id BDA6B1ADF0F for ; Tue, 26 Nov 2013 02:17:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgQAP1zlFLGmAcV/2dsb2JhbABWA4JDIyE4U6ccAwSMJIhPgSoWdIIlAQEBAQMSG0ELEAIBCA0BAwQBAQsWBwcyFAkIAgQBDQUIARmHTQMPAQyjSpM/CIgMF45FIQwEBgERgw+BEwOFVpNuhTuLJoMogio X-IronPort-AV: E=Sophos;i="4.93,773,1378872000"; d="scan'208,217";a="38766004" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 Nov 2013 05:17:03 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 26 Nov 2013 05:10:19 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Tue, 26 Nov 2013 05:17:01 -0500 From: "Romascanu, Dan (Dan)" To: Benoit Claise , ietfdbh , "'Edward Beili'" Thread-Topic: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Thread-Index: AQHO6gLTdhH5L1It8Eq3AaSlUiTAk5o2uFMA//++aVCAAGTPgIAAAo2A//+sZwCAALARAIAAEY4w Date: Tue, 26 Nov 2013 10:17:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12949DBC@AZ-FFEXMB04.global.avaya.com> References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> <018b01ceea37$a5187f30$ef497d90$@comcast.net> <5294737C.4080506@cisco.com> In-Reply-To: <5294737C.4080506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA12949DBCAZFFEXMB04globa_" MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 26 Nov 2013 10:17:08 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA12949DBCAZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If so point (1) in the template at http://www.ietf.org/iesg/template/doc-wr= iteup.html needs to be changed as it does not list 'Standards Track'. Regards, Dan From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, November 26, 2013 12:10 PM To: ietfdbh; 'Edward Beili'; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis David, Ed, After double-checking, David is right. Regards, Benoit I am of the impression that "standards track" is appropriate in the interne= t draft. The IESG telechat is used to tune this finer, and the RFC gets the appropri= ate status level. This hasn't changed, has it? David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili Sent: Monday, November 25, 2013 5:39 PM To: Benoit Claise; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Dan, Benoit, I'm having a little difficulty with the header, namely changing "Indented S= tatus" from "Standards Track" to "Proposed Standard". I'm using xml2rfc, which automatically converts to: Intended status: Standards Track I don't see a way to change that in the xml, except for fixing it manually = in the final .txt file, after xml2rfc conversion. Am I missing something in the xml? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, November 26, 2013 00:30 To: Romascanu, Dan (Dan); Edward Beili Cc: opsawg@ietf.org Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis Hi, The write-up has been updated. Regards, Benoit I agree with Ed's comment about the updated security considerations section= . Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical = or Workgroup summary: This document provides an updated security considerations section for IF-CA= P-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatr= acker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwriteup/), please c= orrect this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The curr= ent revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) --_000_9904FB1B0159DA42B0B887B7FA8119CA12949DBCAZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If so point (1) in the te= mplate at http://www.i= etf.org/iesg/template/doc-writeup.html needs to be changed as it does n= ot list ‘Standards Track’.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, November 26, 2013 12:10 PM
To: ietfdbh; 'Edward Beili'; Romascanu, Dan (Dan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis

 

David, Ed,

After double-checking, David is right.

Regards, Benoit

I am of the impression that “standards track” is appropriate= in the internet draft.

The IESG telechat is used= to tune this finer, and the RFC gets the appropriate status level.<= o:p>

This hasn’t changed= , has it?

 <= /p>

David Harrington

= ietfdbh@comcast.net

+1-603-828-1401<= o:p>

From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili
Sent: Monday, November 25, 2013 5:39 PM
To: Benoit Claise; Romascanu, Dan (Dan)
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis=

 

Dan, Benoit,<= /o:p>

I’m having a little= difficulty with the header, namely changing “Indented Status” = from “Standards Track” to “Proposed Standard”.

 <= /p>

I’m using xml2rfc, = which automatically converts

 <= /p>

<rfc category=3D"= std" …>

 <= /p>

to:

 <= /p>

Intended status: Standards Track

 =

I don’t see a way t= o change that in the xml, except for fixing it manually in the final .txt f= ile, after xml2rfc conversion.

 <= /p>

Am I missing something in= the xml?

 <= /p>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, November 26, 2013 00:30
To: Romascanu, Dan (Dan); Edward Beili
Cc: opsawg@ietf.org
Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis

 

Hi,

The write-up has been updated.

Regards, Benoit

I agree with Ed’s c= omment about the updated security considerations section.

 <= /p>

Regards,

 <= /p>

Dan

 <= /p>

 <= /p>

 <= /p>

From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit Claise
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan)
Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis

 

Benoit,=

I’ll submit the new= version in a couple of hours.

 <= /p>

There’s one thing I= would like you to consider for adding to the Technical or Workgroup summar= y:

 <= /p>

This document provides= an updated security considerations section for IF-CAP-STACK-MIB=

 <= /p>

Regards,

-E.

 <= /p>

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Monday, November 25, 2013 19:21
To: Edward Beili
Cc: opsawg@ietf.org; Romascan= u, Dan (Dan)
Subject: AD review: draft-ietf-opsawg-rfc5066bis

 

Ed, all,

First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwri= teup/), please correct this:

(1) What type of RFC is being requested (BCP, Propos= ed Standard, Internet Standard, Informational, Experimental, or Historic)? = Why is this the proper type of RFC? Is this type of RFC indicated in the ti= tle page header?

Proposed Standard. The header mentions incorrectly 'Standards Track' - this= needs to be changed


Below is my AD review.


1.
OLD:

   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module. =
; The current


   revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 80=
2.3.1-2013


   [802.3.1].=



 


NEW


 


   In 2011, the IEEE developed IEEE8023-EFM-CU-

   MIB module, based on the original EFM-CU-MIB module [RFC5=
066].  The current


   revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 8=
02.3.1-2013


   [802.3.1].=



 


2.


   All further development of the EFM Copper Interfaces MIB =
will be done


   by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MI=
B module.


   Requests and comments pertaining to EFM Copper Interfaces=
 MIB SHOULD


   be sent to the IEEE 803.3 working group.  Currently,=
 the mailing list


   of the IEEE 802.3.1 task force, chartered with MIB develo=
pment, is


   [stds=
-802-3-mib@listserv.ieee.org].


 


"SHOULD" is=
 to be replaced by "should"

Justification: RFC 2119 section 6 





Ed, how quickly can you produce a new version?



Regards, Benoit (OPS AD)

 

 

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA12949DBCAZFFEXMB04globa_-- From ietfdbh@comcast.net Tue Nov 26 11:15:24 2013 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 407A81AE00B for ; Tue, 26 Nov 2013 11:15:24 -0800 (PST) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 FMjoyOXhbcBs for ; Tue, 26 Nov 2013 11:15:20 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBE01AE002 for ; Tue, 26 Nov 2013 11:15:20 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id uElz1m00j1vXlb853KFKf4; Tue, 26 Nov 2013 19:15:19 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta17.westchester.pa.mail.comcast.net with comcast id uKFK1m00G2yZEBF3dKFKxB; Tue, 26 Nov 2013 19:15:19 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , "'Edward Beili'" , "'Benoit Claise'" References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> <018b01ceea37$a5187f30$ef497d90$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12949D96@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12949D96@AZ-FFEXMB04.global.avaya.com> Date: Tue, 26 Nov 2013 14:15:21 -0500 Message-ID: <023801ceeadb$da034d70$8e09e850$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0239_01CEEAB1.F130C7E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH0wkN7qRE4yc6eVe2Vf2Hxf7xhBAHbu670AoaAF/kDO+aaUAHD5qWDAey5NpACZf1odQJi31KSmWt107A= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1385493319; bh=+52kD9jWk5BP6CMLvzMzdZ6SVr02rNSUhNjsQu+iDpw=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=cAQQRia2+ke1ujXQF9F3rwH5VoRZ/Hb6yYAQfARNSk2G8YXHG1yKT/WZVnM00MX4Q vOBsPssOHIApHQQ0QEKID378DFlhiAzITxykMODCq417P+5HncZP/YpSGF9gyo8CVy wPXg3s77PwcwUXeuOvyhxUzF7pv0fuHbeMpQRhkK9pGu9NUl/UejDNqFmL9nvJyMDL OhvDhcB0uUkQa/mXkREx7Bz6M11Q+khA0kr5iem/6xBXusXxk5DCfqwxCpmLS6QXmn eAps/KJKi8KhS49i4g7MgD0HrG594FQdHSkC64pOrlRHdiFj7ecB9yrlQNGc6HCOGw j7ALGyXk2/zng== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 26 Nov 2013 19:15:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0239_01CEEAB1.F130C7E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Dan, I see your point. I recommend asking the xml2rfc team to modify the xml2rfc directive. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, November 26, 2013 5:10 AM To: ietfdbh; 'Edward Beili'; 'Benoit Claise' Cc: opsawg@ietf.org Subject: RE: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis I am not sure. The IESG telechat can change the status, but the document needs to be clear about what the authors (based on the consensus of the WG ) are asking. In this case it does not matter, but for a document that obsoletes a previous RFC (as 5066bis originally was written) 'Standards Track' is ambiguous - do the authors intent to recycle at Proposed or do they plan to go to Internet Standard? As shepherd the text in the template did not provide me the option of 'Standards Track': (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? One way or the other, there seems to be a lack of sync between xml2rfc and the write-up template which should be corrected. Regards, Dan From: ietfdbh [mailto:ietfdbh@comcast.net] Sent: Tuesday, November 26, 2013 1:40 AM To: 'Edward Beili'; 'Benoit Claise'; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: RE: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis I am of the impression that "standards track" is appropriate in the internet draft. The IESG telechat is used to tune this finer, and the RFC gets the appropriate status level. This hasn't changed, has it? David Harrington ietfdbh@comcast.net +1-603-828-1401 From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili Sent: Monday, November 25, 2013 5:39 PM To: Benoit Claise; Romascanu, Dan (Dan) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis Dan, Benoit, I'm having a little difficulty with the header, namely changing "Indented Status" from "Standards Track" to "Proposed Standard". I'm using xml2rfc, which automatically converts to: Intended status: Standards Track I don't see a way to change that in the xml, except for fixing it manually in the final .txt file, after xml2rfc conversion. Am I missing something in the xml? Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, November 26, 2013 00:30 To: Romascanu, Dan (Dan); Edward Beili Cc: opsawg@ietf.org Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis Hi, The write-up has been updated. Regards, Benoit I agree with Ed's comment about the updated security considerations section. Regards, Dan From: Edward Beili [mailto:EdwardB@actelis.com] Sent: Monday, November 25, 2013 10:24 PM To: Benoit Claise Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis Benoit, I'll submit the new version in a couple of hours. There's one thing I would like you to consider for adding to the Technical or Workgroup summary: This document provides an updated security considerations section for IF-CAP-STACK-MIB Regards, -E. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Monday, November 25, 2013 19:21 To: Edward Beili Cc: opsawg@ietf.org; Romascanu, Dan (Dan) Subject: AD review: draft-ietf-opsawg-rfc5066bis Ed, all, First of all, as mentioned by Dan Romascanu in his write-up (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdwrite up/), please correct this: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard. The header mentions incorrectly 'Standards Track' - this needs to be changed Below is my AD review. 1. OLD: In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module. The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 [802.3.1 ]. NEW In 2011, the IEEE developed IEEE8023-EFM-CU- MIB module, based on the original EFM-CU-MIB module [RFC5066]. The current revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 [802.3.1 ]. 2. All further development of the EFM Copper Interfaces MIB will be done by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD be sent to the IEEE 803.3 working group. Currently, the mailing list of the IEEE 802.3.1 task force, chartered with MIB development, is [stds-802-3-mib@listserv.ieee.org]. "SHOULD" is to be replaced by "should" Justification: RFC 2119 section 6 Ed, how quickly can you produce a new version? Regards, Benoit (OPS AD) ------=_NextPart_000_0239_01CEEAB1.F130C7E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dan,

 

I see your point.

I recommend asking the xml2rfc team to modify the xml2rfc = directive.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: = Tuesday, November 26, 2013 5:10 AM
To: ietfdbh; 'Edward = Beili'; 'Benoit Claise'
Cc: opsawg@ietf.org
Subject: = RE: [OPSAWG] AD review: = draft-ietf-opsawg-rfc5066bis

 

I am not sure. The IESG telechat can change the status, but the = document needs to be clear about what the authors (based on the = consensus of the WG ) are asking. In this case it does not matter, but = for a document that obsoletes a previous RFC (as 5066bis originally was = written) ‘Standards Track’ is ambiguous – do the = authors intent to recycle at Proposed or do they plan to go to Internet = Standard?

 

As shepherd the text in the template did not provide me the option of = ‘Standards Track’:

 

(1)   = What type of RFC is being requested (BCP, = Proposed Standard, Internet Standard, Informational, Experimental, or = Historic)? Why is this the proper type of RFC? Is this type of RFC = indicated in the title page header?

One way or the other, there seems to be a lack of sync between = xml2rfc and the write-up template which should be corrected. =  

 

Regards,

 

Dan

 

 

From: ietfdbh [mailto:ietfdbh@comcast.net] =
Sent: Tuesday, November 26, 2013 1:40 AM
To: = 'Edward Beili'; 'Benoit Claise'; Romascanu, Dan (Dan)
Cc: opsawg@ietf.org
Subject: = RE: [OPSAWG] AD review: = draft-ietf-opsawg-rfc5066bis

 

I am of the impression that “standards track” is = appropriate in the internet draft.

The IESG telechat is used to tune this finer, and the RFC gets the = appropriate status level.

This hasn’t changed, has it?

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

 

Dan, Benoit,

I’m having a little difficulty with the header, namely changing = “Indented Status” from “Standards Track” to = “Proposed Standard”.

 

I’m using xml2rfc, which automatically = converts

 

<rfc category=3D"std" = …>

 

to:

 

Intended status: Standards Track

 

I don’t see a way to change that in the xml, except for fixing = it manually in the final .txt file, after xml2rfc = conversion.

 

Am I missing something in the xml?

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com] =
Sent: Tuesday, November 26, 2013 00:30
To: = Romascanu, Dan (Dan); Edward Beili
Cc: opsawg@ietf.org
Subject: = Re: AD review: = draft-ietf-opsawg-rfc5066bis

 

Hi,

The write-up has been = updated.

Regards, Benoit

I agree with Ed’s comment about the updated security = considerations section.

 

Regards,

 

Dan

 

 

 

From: Edward Beili [mailto:EdwardB@actelis.com] =
Sent: Monday, November 25, 2013 10:24 PM
To: Benoit = Claise
Cc: opsawg@ietf.org; Romascanu, Dan = (Dan)
Subject: RE: AD review: = draft-ietf-opsawg-rfc5066bis

 

Benoit,

I’ll submit the new version in a couple of = hours.

 

There’s one thing I would like you to consider for adding to = the Technical or Workgroup summary:

 

This document provides an updated security considerations section for = IF-CAP-STACK-MIB

 

Regards,

-E.

 

From: Benoit Claise [mailto:bclaise@cisco.com] =
Sent: Monday, November 25, 2013 19:21
To: Edward = Beili
Cc: opsawg@ietf.org; Romascanu, Dan = (Dan)
Subject: AD review: = draft-ietf-opsawg-rfc5066bis

 

Ed, = all,

First of all, as mentioned by Dan Romascanu in his write-up = (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066= bis/shepherdwriteup/), please correct this:

(1) What type of RFC is being requested (BCP, Proposed = Standard, Internet Standard, Informational, Experimental, or Historic)? = Why is this the proper type of RFC? Is this type of RFC indicated in the = title page header?

Proposed Standard. The header mentions = incorrectly 'Standards Track' - this needs to be = changed


Below is my AD = review.


1.
OLD:

   In =
2011, the IEEE developed =
IEEE8023-EFM-CU-
   MIB module, based on =
the original EFM-CU-MIB module.  The =
current
   revision of =
IEEE8023-EFM-CU-MIB is defined in IEEE Std =
802.3.1-2013
   [802.3.1].
 
NEW
 
   =
In 2011, the IEEE developed =
IEEE8023-EFM-CU-
   MIB module, based on =
the original EFM-CU-MIB module [RFC5066].  The =
current
   revision of =
IEEE8023-EFM-CU-MIB, is defined in IEEE Std =
802.3.1-2013
   [802.3.1].
 
2.
   All further =
development of the EFM Copper Interfaces MIB will be =
done
   by the IEEE 802.3 working group =
in the IEEE8023-EFM-CU-MIB module.
   =
Requests and comments pertaining to EFM Copper Interfaces MIB =
SHOULD
   be sent to the IEEE 803.3 =
working group.  Currently, the mailing =
list
   of the IEEE 802.3.1 task force, =
chartered with MIB development, is
   [stds-802-3-mib@listserv.=
ieee.org].
 
"SHOULD" is =
to be replaced by "should"
Justification: RFC 2119 section =
6 


Ed, how quickly can you produce a new =
version?

Regards, Benoit (OPS AD)

 

 

------=_NextPart_000_0239_01CEEAB1.F130C7E0-- From iesg-secretary@ietf.org Tue Nov 26 15:26:41 2013 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 C19D11AE05B; Tue, 26 Nov 2013 15:26:41 -0800 (PST) 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 BHvLgRH3p89J; Tue, 26 Nov 2013 15:26:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E181A1EF9; Tue, 26 Nov 2013 15:26:35 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20131126232635.3436.30321.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 15:26:35 -0800 Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (Ethernet in the First Mile Copper (EFMCu) Interfaces MIB) to Proposed Standard X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 23:26:42 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Ethernet in the First Mile Copper (EFMCu) Interfaces MIB' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-12-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates RFC 5066. It amends that specification by informing the internet community about the transition of the EFM-CU- MIB module from the concluded IETF Ethernet Interfaces and Hub MIB Working Group to the Institute of Electrical and Electronics Engineers (IEEE) 802.3 working group. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ballot/ No IPR declarations have been submitted directly on this I-D. From ietfc@btconnect.com Wed Nov 27 03:08:06 2013 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 12BF91AE176 for ; Wed, 27 Nov 2013 03:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y1FN_zdYe3B5 for ; Wed, 27 Nov 2013 03:07:58 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 95EEE1AE229 for ; Wed, 27 Nov 2013 02:46:48 -0800 (PST) Received: from mail147-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 27 Nov 2013 10:46:47 +0000 Received: from mail147-va3 (localhost [127.0.0.1]) by mail147-va3-R.bigfish.com (Postfix) with ESMTP id CE762C0103; Wed, 27 Nov 2013 10:46:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zz9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h304l1d11m1155h) Received: from mail147-va3 (localhost.localdomain [127.0.0.1]) by mail147-va3 (MessageSwitch) id 1385549205820024_23748; Wed, 27 Nov 2013 10:46:45 +0000 (UTC) Received: from VA3EHSMHS013.bigfish.com (unknown [10.7.14.246]) by mail147-va3.bigfish.com (Postfix) with ESMTP id C0E824007A; Wed, 27 Nov 2013 10:46:45 +0000 (UTC) Received: from DB3PRD0710HT003.eurprd07.prod.outlook.com (157.56.253.85) by VA3EHSMHS013.bigfish.com (10.7.99.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 27 Nov 2013 10:46:45 +0000 Received: from DB3PRD0411HT001.eurprd04.prod.outlook.com (157.56.253.53) by pod51017.outlook.com (10.255.75.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 27 Nov 2013 10:46:38 +0000 Message-ID: <01b701ceeb5d$8bc432a0$4001a8c0@gateway.2wire.net> From: t.petch To: ietfdbh , "'Romascanu, Dan (Dan)'" References: <528F93CB.7060604@cisco.com> <52938715.40305@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49D@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA12949661@AZ-FFEXMB04.global.avaya.com> <5293CF67.5050908@cisco.com> <4087887712E5C648B9F72BB9D912FD4602F6D393D49F@il-mail07.actelis.net> <018b01ceea37$a5187f30$ef497d90$@comcast.net> <9904FB1B0159DA42B0B887B7FA8119CA12949D96@AZ-FFEXMB04.global.avaya.com> <023801ceeadb$da034d70$8e09e850$@comcast.net> Date: Wed, 27 Nov 2013 10:43:06 +0000 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.253.53] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: opsawg@ietf.org Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis 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, 27 Nov 2013 11:08:06 -0000 ----- Original Message ----- From: "ietfdbh" To: "'Romascanu, Dan (Dan)'" ; "'Edward Beili'" ; "'Benoit Claise'" Cc: Sent: Tuesday, November 26, 2013 7:15 PM > Hi Dan, > > I see your point. > > I recommend asking the xml2rfc team to modify the xml2rfc directive. David I notice that the Last Call and the datatracker have got it right (Proposed Standard) despite what the Intended status says (Standards Track). I do not know how this is done, whether automatically from the write-up or from an independent action by the AD, but I would be careful about changing xml2rfc lest it upsets the part that works (even if I do not understand how it works:-) Tom Petch > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Tuesday, November 26, 2013 5:10 AM > To: ietfdbh; 'Edward Beili'; 'Benoit Claise' > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis > > > > I am not sure. The IESG telechat can change the status, but the document > needs to be clear about what the authors (based on the consensus of the WG ) > are asking. In this case it does not matter, but for a document that > obsoletes a previous RFC (as 5066bis originally was written) 'Standards > Track' is ambiguous - do the authors intent to recycle at Proposed or do > they plan to go to Internet Standard? > > > > As shepherd the text in the template did not provide me the option of > 'Standards Track': > > > > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? > > One way or the other, there seems to be a lack of sync between xml2rfc and > the write-up template which should be corrected. > > > > Regards, > > > > Dan > > > > > > From: ietfdbh [mailto:ietfdbh@comcast.net] > Sent: Tuesday, November 26, 2013 1:40 AM > To: 'Edward Beili'; 'Benoit Claise'; Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis > > > > I am of the impression that "standards track" is appropriate in the internet > draft. > > The IESG telechat is used to tune this finer, and the RFC gets the > appropriate status level. > > This hasn't changed, has it? > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Edward Beili > Sent: Monday, November 25, 2013 5:39 PM > To: Benoit Claise; Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] AD review: draft-ietf-opsawg-rfc5066bis > > > > Dan, Benoit, > > I'm having a little difficulty with the header, namely changing "Indented > Status" from "Standards Track" to "Proposed Standard". > > > > I'm using xml2rfc, which automatically converts > > > > > > > > to: > > > > Intended status: Standards Track > > > > I don't see a way to change that in the xml, except for fixing it manually > in the final .txt file, after xml2rfc conversion. > > > > Am I missing something in the xml? > > > > Regards, > > -E. > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Tuesday, November 26, 2013 00:30 > To: Romascanu, Dan (Dan); Edward Beili > Cc: opsawg@ietf.org > Subject: Re: AD review: draft-ietf-opsawg-rfc5066bis > > > > Hi, > > The write-up has been updated. > > Regards, Benoit > > I agree with Ed's comment about the updated security considerations section. > > > > > Regards, > > > > Dan > > > > > > > > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: Monday, November 25, 2013 10:24 PM > To: Benoit Claise > Cc: opsawg@ietf.org; Romascanu, Dan (Dan) > Subject: RE: AD review: draft-ietf-opsawg-rfc5066bis > > > > Benoit, > > I'll submit the new version in a couple of hours. > > > > There's one thing I would like you to consider for adding to the Technical > or Workgroup summary: > > > > This document provides an updated security considerations section for > IF-CAP-STACK-MIB > > > > Regards, > > -E. > > > > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, November 25, 2013 19:21 > To: Edward Beili > Cc: opsawg@ietf.org; Romascanu, Dan (Dan) > Subject: AD review: draft-ietf-opsawg-rfc5066bis > > > > Ed, all, > > First of all, as mentioned by Dan Romascanu in his write-up > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/shepherdw rite > up/), please correct this: > > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? > > Proposed Standard. The header mentions incorrectly 'Standards Track' - this > needs to be changed > > > Below is my AD review. > > > 1. > OLD: > > In 2011, the IEEE developed IEEE8023-EFM-CU- > MIB module, based on the original EFM-CU-MIB module. The current > revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std 802.3.1-2013 > [802.3.1 > ]. > > NEW > > In 2011, the IEEE developed IEEE8023-EFM-CU- > MIB module, based on the original EFM-CU-MIB module [RFC5066]. The > current > revision of IEEE8023-EFM-CU-MIB, is defined in IEEE Std 802.3.1-2013 > [802.3.1 > ]. > > > 2. > > All further development of the EFM Copper Interfaces MIB will be done > by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. > Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD > be sent to the IEEE 803.3 working group. Currently, the mailing list > of the IEEE 802.3.1 task force, chartered with MIB development, is > [stds-802-3-mib@listserv.ieee.org]. > > > "SHOULD" is to be replaced by "should" > Justification: RFC 2119 section 6 > > > Ed, how quickly can you produce a new version? > > Regards, Benoit (OPS AD) > > > > > > ------------------------------------------------------------------------ -------- > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From bclaise@cisco.com Thu Nov 28 08:05:56 2013 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 5D9B81AE173 for ; Thu, 28 Nov 2013 08:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.034 X-Spam-Level: X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_24=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 7nC1F9rpG-2N for ; Thu, 28 Nov 2013 08:05:40 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6228F1AE022 for ; Thu, 28 Nov 2013 08:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=442018; q=dns/txt; s=iport; t=1385654735; x=1386864335; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=gb7JGWnjZy//93KTc2rerLv+GCLJxaFmFRKzeJEucms=; b=UA3gCTiWsGUp+Quzc3MxMMviF1bJk9IKKFQPeza7WAbjGi6/1kPrQVKT fCbHi2jmvGDPcu+yWu7hSd9YTqJjapX6s8fDTxidmF4x7xcz622z6xo6d SUjFERAZ7V7zfWi7sg+6m9Kjglt2XV0Gw4/eMqv7t4dU8HbyXFZ9kzb2f M=; X-IronPort-AV: E=Sophos;i="4.93,791,1378857600"; d="scan'208,217";a="1386811" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 28 Nov 2013 16:05:33 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rASG5LML032031; Thu, 28 Nov 2013 16:05:23 GMT Message-ID: <529769C4.4050102@cisco.com> Date: Thu, 28 Nov 2013 17:05:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Tal Mizrahi , "draft-ietf-opsawg-oam-overview@tools.ietf.org" References: <52540CAB.5060907@cisco.com> <74470498B659FA4687F0B0018C19A89C01B87D71ADBE@IL-MB01.marvell.com> <529634EF.1050907@cisco.com> In-Reply-To: <529634EF.1050907@cisco.com> Content-Type: multipart/alternative; boundary="------------070707050609030101080201" Cc: "opsawg-chairs@tools.ietf.org" , "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-oam-overview status 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, 28 Nov 2013 16:05:56 -0000 This is a multi-part message in MIME format. --------------070707050609030101080201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, As you know, the IESG sent this document back to the WG (see http://www.ietf.org/mail-archive/web/opsawg/current/msg02931.html). I asked the authors to make sure that the feedback and concerns received so far were addressed. A new version has been posted . Good! Below is the feedback sent by Stewart Bryant on the new version, forwarded with permission to the WG: Stewart has been involved in OAM for some time now, is the routing AD, and was the DISCUSS holder when the draft was reviewed by the IESG in 2011). Note that the DISCUSS is gone now, since the document is back in the WG. I've been reviewing the new draft version, this email below, and had two conf. calls with Stewart today. Below is the outcome of our discussion. The draft improved. For example, I like the fact that the target audience is now in the abstract. However, one important point brought up by Stewart is: why audience do you target? Is the draft content useful for that audience? It seems that initially, it was the silicon designer. It's apparently not the case any longer. You list The target audience of this document includes network equipment vendors, network operators and standard development organizations, and can be used as an index to some of the main data plane OAM tools defined in the IETF. We believe that this draft is not complete enough for the network equipment vendor audience. It needs way more than this overview. Also you focus _only _on the data plane OAM. Regarding the network operators, your table in 4.10 might be a good output. However, it's buried into a subsection. Regarding "an index to some of the main data plane OAM tools defined in the IETF", the table in section 3.9 is buried into a subsection. Maybe you want to highlight those tables with they own section. Also, while the abstract and title mention "an index to some of the main _data plane_ OAM tools defined in the IETF" , the data plane adjective really limits the scope of what you're investigating. I only understood its implications way later in the draft. For example that FRR, RDI (remote defect indication), etc. were not included. This should be stressed upfront. This point points back to Stewart's point: think about your target audience and evaluate if the content is useful for the readers... Note that this is now a WG document, so we must get the OPSAWG community feedback. Also, Stewart has some good points below: path verification versus peer authentication, multipoint to point, etc. Regarding the WIKI, I'm actually in favor a collecting this information in a RFC. OAM has been growing over the years, up to a point where I'm not sure what it does NOT contain (FCAPS). So doing a one-time "overview of OAM tools" makes sense to me. Regards, Benoit > > Firstly, I should say I have been reviewing this work from > the point of view of someone who was on point when we designed > the MPLS-TP OAM, where we took object lesson after object lesson > on the scope and purpose of OAM from the ITU-T. > > I will say that the project you have embarked on is a very > difficult and challenging one, since this subject has > enormous breath and depth. > > In one communication earlier the stated purpose was to provide > an overview from the point of view of a silicon designer. I do > not think you get close to that. > > My view is still that you fail to ruthlessly identify the > target audience and the single mindedly deliver to that audience. > > The text is far too detailed in places for the broad brush overview > and lacks the rigor needed for a deeper academic introduction. > > If your goal is the former, I think you need to split the work > between an RFC and a Wiki, and delete a lot of the detail. > > If your goal is the latter, then I think you need to set > up a well defined, intellectually rigerous framework for OAM, > and then show how well, or how badly the solutions map to it. > > If your original goal is to talk about implementation, I would > have expected a lot of discussion on stack depth, queue and > process structure, performance bottlenecks, timestamping etc. > Indeed even in an introduction there needs to be some text on those > aspects of the problem. > > Now if I am the only AD that has any concerns about publishing > this text as an RFC, I am prepared to move to abstain and you > can publish this as it is. > > However I think that Benoit needs to understand that we have > sufficient real support in the IETF for the text amongst the > various OAM design teams that look after each protocol suite > discussed in the text. If there is not support, perhaps this > should go to the ISE as a personal statement on the subject. > > It might be a good idea if Benoit and I discussed this > on the telephone tomorrow. > > - Stewart > > > > > Abstract > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to a toolset for fault detection and isolation, and for > performance measurement. > > SB> No In MPLS-TP (which is in scope it does more, it is also a devolved > SB> control plane) > > Over the years various OAM tools have been > defined for various layers in the protocol stack. > > This document summarizes some of the data plane OAM tools defined in > the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for > the transport profile (MPLS-TP), and TRILL. > > SB> Since MPLS-TP is a subset of MPLS the ordering of the list is a > little curious > > > The target audience of this document includes network equipment > vendors, network operators and standard development organizations, > and can be used as an index to some of the main data plane OAM tools > defined in the IETF. > > ====== > > > 1. Introduction > > OAM is a general term that refers to a toolset for detecting, > isolating and reporting failures and for monitoring the network > performance. > > SB> See earlier comment > > There are several different interpretations to the "OAM" acronym. > This document refers to Operations, Administration and Maintenance, > as recommended in Section 3 of [RFC6291]. > > This document summarizes some of the data plane OAM tools defined in > the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for > the transport profile (MPLS-TP), and TRILL. > > SB> See earlier comment > > This document focuses on data plane OAM tools. Hence, control and > management aspects of OAM are outside the scope of this document. > This document focuses on tools for detecting and isolating failures > and for performance monitoring. Network repair functions such as Fast > Reroute (FRR) and protection switching, which are often triggered by > OAM protocols, are out of the scope of this document. > > SB> You need to be careful with the definition of OAM - In MPLS-TP (which > SB> you define as in scope) these are considered OAM functions. > > 1.1. Background > > OAM was originally used in traditional communication technologies > such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM > was probably the first technology to include inherent OAM support > from day one, while in other technologies OAM was typically defined > in an ad hoc manner after the technology was already defined and > deployed. Packet-based networks were traditionally considered > unreliable and best-effort, but as packet-based networks evolved, > they have become the common transport for both data and telephony, > replacing traditional transport protocols. Consequently, packet-based > networks were expected to provide a similar "carrier grade" > experience, and specifically to support OAM. > > As typical networks have a multi-layer architecture, the set of OAM > protocols similarly take a multi-layer structure; each layer has its > own OAM protocols. Moreover, OAM can be used at different levels of > hierarchy in the network to form a multi-layer OAM solution, as shown > in the example in Figure 1. > > Figure 1 illustrates a network in which IP traffic between two > customer edges is transported over an MPLS provider network. MPLS OAM > is used at the provider-level for monitoring the connection between > the two provider edges, while IP OAM is used at the customer-level > for monitoring the end-to-end connection between the two customer > edges. > > > > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 4] > > Internet-Draft Overview of OAM Tools October 2013 > > > |<-------------- Customer-level OAM -------------->| > IP OAM (Ping, Traceroute, OWAMP, TWAMP) > > |<- Provider-level OAM ->| > MPLS OAM (LSP Ping) > > +-----+ +----+ +----+ +-----+ > | | | |========================| | | | > | |-------| | MPLS | |-------| | > | | IP | | | | IP | | > +-----+ +----+ +----+ +-----+ > Customer Provider Provider Customer > Edge Edge Edge Edge > > Figure 1 Example: Multi-layer OAM > > 1.2. Target Audience > > The target audience of this document includes: > > o Standard development organizations - both IETF working groups and > non-IETF organizations can benefit from this document when > designing new OAM protocols, or when looking to reuse existing OAM > tools for new technologies. > > SB> Who do you have in mind outside the IETF? > SB> There are a lot of OAM expert groups out there. > > o Network equipment vendors and network operators - can use this > document as an index to some of the common IETF OAM tools. > > It should be noted that this document is not necessarily suitable for > beginners without any background in OAM. > > 1.3. OAM-related Work in the IETF > > This memo provides an overview of the different sets of OAM tools > defined by the IETF. The set of OAM tools described in this memo are > applicable to IP unicast, MPLS, pseudowires, MPLS for the transport > profile (MPLS-TP), and TRILL. While OAM tools that are applicable to > other technologies exist, they are beyond the scope of this memo. > > This document focuses on IETF documents that have been published as > RFCs, while other ongoing OAM-related work is outside the scope. > > The IETF has defined OAM protocols and tools in several different > contexts. We roughly categorize these efforts into a few sets of OAM- > related RFCs, listed in Table 1. Each category defines a logically- > > > Mizrahi, et al. Expires April 21, 2014 [Page 5] > > Internet-Draft Overview of OAM Tools October 2013 > > > coupled set of RFCs, although the sets are in some cases intertwined > by common tools and protocols. > > The discussion in this document is ordered according to these > categories. > > +--------------+------------+ > | Category | Transport | > | | Technology | > +--------------+------------+ > |IP Ping | IPv4/IPv6 | > +--------------+------------+ > |IP Traceroute | IPv4/IPv6 | > +--------------+------------+ > |BFD | generic | > +--------------+------------+ > |MPLS OAM | MPLS | > +--------------+------------+ > |MPLS-TP OAM | MPLS-TP | > +--------------+------------+ > |Pseudowire OAM| Pseudowires| > +--------------+------------+ > |OWAMP and | IPv4/IPv6 | > |TWAMP | | > +--------------+------------+ > |TRILL OAM | TRILL | > +--------------+------------+ > Table 1 Categories of OAM-related IETF Documents > > SB> Categories implies taxonomy, and those are not really > SB> taxonomy classes. Those are really IETF work packages. > > 1.4. Focusing on Data Plane OAM Tools > > OAM tools may, and quite often do, work in conjunction with a control > plane and/or management plane. At the data plane, OAM provides > instrumentation tools. > > SB> That is your definition of the purpose, not for example the > SB> transport world's definition. > SB> You might also consider implicit OAM tools such as router hellos > > OAM tools often use control plane functions, > e.g., to initialize OAM sessions and to exchange various parameters. > The OAM tools communicate with the management plane to raise alarms, > and often OAM tools may be activated by the management (as well as by > the control plane), e.g. to locate and localize problems. > > The considerations of the control plane maintenance tools and the > functionality of the management plane are out of scope for this > document, which concentrates on presenting the data plane tools that > are used for OAM. Network repair functions such as Fast Reroute (FRR) > > > > Mizrahi, et al. Expires April 21, 2014 [Page 6] > > Internet-Draft Overview of OAM Tools October 2013 > > > and protection switching, which are often triggered by OAM protocols, > are also out of the scope of this document. > > SB> I don't mind what you call your function, but this exclusion > SB> will not class the functionality as OAM within the shared IETF-ITU > SB> definition of OAM in the transport technology space. > > Since OAM protocols are used for monitoring the data plane, it is > imperative for OAM tools to be capable of testing the actual data > plane in as much accuracy as possible. Thus, it is important to > enforce fate-sharing between OAM traffic that monitors the data plane > and the data plane traffic it monitors. > > 2. Terminology > > 2.1. Abbreviations > > ACH Associated Channel Header > > AIS Alarm Indication Signal > > ATM Asynchronous Transfer Mode > > BFD Bidirectional Forwarding Detection > > CC Continuity Check > > CV Connectivity Verification > > DM Delay Measurement > > ECMP Equal Cost Multiple Paths > > FEC Forwarding Equivalence Class > > FRR Fast Reroute > > G-ACh Generic Associated Channel > > GAL Generic Associated Label > > ICMP Internet Control Message Protocol > > L2TP Layer Two Tunneling Protocol > > LCCE L2TP Control Connection Endpoint > > LDP Label Distribution Protocol > > LER Label Edge Router > > > > Mizrahi, et al. Expires April 21, 2014 [Page 7] > > Internet-Draft Overview of OAM Tools October 2013 > > > LM Loss Measurement > > LSP Label Switched Path > > LSR Label Switched Router > > ME Maintenance Entity > > MEG Maintenance Entity Group > > MEP MEG End Point > > MIP MEG Intermediate Point > > MP Maintenance Point > > MPLS Multiprotocol Label Switching > > MPLS-TP MPLS Transport Profile > > MTU Maximum Transmission Unit > > OAM Operations, Administration, and Maintenance > > PDH Plesiochronous Digital Hierarchy > > PE Provider Edge > > PW Pseudowire > > PWE3 Pseudowire Emulation Edge-to-Edge > > RBridge Routing Bridge > > RDI Remote Defect Indication > > SDH Synchronous Digital Hierarchy > > SONET Synchronous Optical Networking > > TRILL Transparent Interconnection of Lots of Links > > TTL Time To Live > > VCCV Virtual Circuit Connectivity Verification > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 8] > > Internet-Draft Overview of OAM Tools October 2013 > > > 2.2. Terminology used in OAM Standards > > 2.2.1. General Terms > > A wide variety of terms is used in various OAM standards. This > section presents a comparison of the terms used in various OAM > standards, without fully quoting the definition of each term. > > An interesting overview of the term OAM and its derivatives is > presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms > is presented in [TP-Term], and provides a good summary of some of the > OAM related terminology. > > 2.2.2. Operations, Administration and Maintenance > > The following definition of OAM is quoted from [OAM-Def]: > > The components of the "OAM" acronym (and provisioning) are defined as > follows: > > o Operations - Operation activities are undertaken to keep the > network (and the services that the network provides) up and > running. It includes monitoring the network and finding problems. > Ideally these problems should be found before users are affected. > > o Administration - Administration activities involve keeping track > of resources in the network and how they are used. It includes > all the bookkeeping that is necessary to track networking > resources and the network under control. > > o Maintenance - Maintenance activities are focused on facilitating > repairs and upgrades -- for example, when equipment must be > replaced, when a router needs a patch for an operating system > image, or when a new switch is added to a network. Maintenance > also involves corrective and preventive measures to make the > managed network run more effectively, e.g., adjusting device > configuration and parameters. > > SB> I think that the class of OAM that you explain is actually > SB> M == Measurement. Maint implies maint of service which includes > SB> protection switching which you have put out of scope. > > 2.2.3. Functions, Tools and Protocols > > OAM Function > > > > An OAM function is an instrumentation measurement type or diagnostic. > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 9] > > Internet-Draft Overview of OAM Tools October 2013 > > > OAM functions are the atomic building blocks of OAM, where each > function defines an OAM capability. > > Typical examples of OAM functions are presented in Section 3. > > OAM Protocol > > A protocol used for implementing one or more OAM functions. > > The OWAMP-Test [OWAMP] is an example of an OAM protocol. > > SB> Isn't your definition DP measurements? I am struggling to > SB> work out if OWAMP is a DP measurement, or a synthetic > SB> Transport measurement. > SB> I think that OWAMP is UDP isn't it, so is really measuring > SB> what the system does to UDP packets. > > OAM Tool > > An OAM tool is a specific means of applying one or more OAM > functions. > > In some cases an OAM protocol *is* an OAM tool, e.g., OWAMP-Test. In > other cases an OAM tool uses a set of protocols that are not strictly > OAM-related; for example, Traceroute (Section 4.2.) can be > implemented using UDP and ICMP messages, without using an OAM > protocol per se. > > 2.2.4. Data Plane, Control Plane and Management Plane > > Data Plane > > The data plane is the set of functions used to transfer data in the > stratum or layer under consideration [ITU-Terms]. > > . > > The Data Plane is also known as the Forwarding Plane or the User > Plane. > > SB> I am not sure that is quite right. > > Control Plane > > The control plane is the set of protocols and mechanisms that enable > routers to efficiently learn how to forward packets towards their > final destination (based on [Comp]). > > SB> Er no. The routers may not learn in the classic sense of learn. > SB> they may be told by the CP. > > > Management Plane > > The term Management Plane, as described in [Mng], is used to describe > the exchange of management messages through management protocols > (often transported by IP and by IP transport protocols) between > management applications and the managed entities such as network > nodes. > > > Mizrahi, et al. Expires April 21, 2014 [Page 10] > > Internet-Draft Overview of OAM Tools October 2013 > > > Data Plane vs. Control Plane vs. Management Plane > > The distinction between the planes is at times a bit vague. For > example, the definition of "Control Plane" above may imply that OAM > tools such as ping, BFD and others are in fact in the control plane. > > This document focuses on data plane OAM tools, i.e., tools used for > monitoring the data plane. While these tools could arguably be > considered to be in the control plane, these tools monitor the data > plane, and hence it is imperative to have fate-sharing between OAM > traffic that monitors the data plane and the data plane traffic it > monitors. > > Another potentially vague distinction is between the management plane > and control plane. The management plane should be seen as separate > from, but possibly overlapping with, the control plane (based on > [Mng]). > > 2.2.5. The Players > > An OAM tool is used between two (or more) "players". Various terms > are used in IETF documents to refer to the players that take part in > OAM. Table 2 summarizes the terms used in each of the categories > discussed in this document. > > +--------------------------+--------------------------+ > | Category | Terms | > +--------------------------+--------------------------+ > | Ping / Traceroute |-Host | > | ([ICMPv4], [ICMPv6], |-Node | > | [TCPIP-Tools]) |-Interface | > | |-Gateway | > + ------------------------ + ------------------------ + > | BFD [BFD] | System | > + ------------------------ + ------------------------ + > | MPLS OAM [MPLS-OAM-FW] | LSR | > + ------------------------ + ------------------------ + > | MPLS-TP OAM [TP-OAM-FW] |-End Point - MEP | > | |-Intermediate Point - MIP | > + ------------------------ + ------------------------ + > | Pseudowire OAM [VCCV] |-PE | > | |-LCCE | > + ------------------------ + ------------------------ + > | OWAMP and TWAMP |-Host | > > > Mizrahi, et al. Expires April 21, 2014 [Page 11] > > Internet-Draft Overview of OAM Tools October 2013 > > > | ([OWAMP], [TWAMP]) |-End system | > + ------------------------ + ------------------------ + > | TRILL OAM [TRILL-OAM] |-RBridge | > +--------------------------+--------------------------+ > Table 2 Maintenance Point Terminology > > SB> Shouldn't you start with a rigorous definition and then show > SB> how the less rigorous terms map to it? > > 2.2.6. Proactive and On-demand Activation > > The different OAM tools may be used in one of two basic types of > activation: > > Proactive > > Proactive activation - indicates that the tool is activated on a > continual basis, where messages are sent periodically, and errors are > detected when a certain number of expected messages are not received. > > On-demand > > On-demand activation - indicates that the tool is activated > "manually" to detect a specific anomaly. > > 2.2.7. Connectivity Verification and Continuity Checks > > Two distinct classes of failure management functions are used in OAM > protocols, connectivity verification and continuity checks. The > distinction between these terms is defined in [MPLS-TP-OAM], and is > used similarly in this document. > > Continuity Check > > Continuity checks are used to verify that a destination is reachable, > and are typically sent proactively, though they can be invoked on- > demand as well. > > Connectivity Verification > > SB> CV is surely about verifying that Bob is Bob? > SB> What you are about to describe is path verification. > > A connectivity verification function allows Alice to check whether > she is connected to Bob or not. This function also allows Alice to > verify that messages from Bob are received through the correct path, > thereby verifying not only that the two MPs are connected, but also > that they are connected through the expected path, allowing detection > of unexpected topology changes. It is noted that while the CV > function is performed in the data plane, the "expected path" is > > > Mizrahi, et al. Expires April 21, 2014 [Page 12] > > Internet-Draft Overview of OAM Tools October 2013 > > > predetermined either in the control plane or in the management plane. > A connectivity verification (CV) protocol typically uses a CV > message, followed by a CV reply that is sent back to the originator. > A CV function can be applied proactively or on-demand. > > Connectivity verification and continuity checks are considered > complementary mechanisms, and are often used in conjunction with each > other. > > 2.2.8. Connection Oriented vs. Connectionless Communication > > Connection Oriented > > In Connection Oriented technologies an end-to-end connection is > established (by a control protocol or provisioned by a management > system) prior to the transmission of data. > > Typically a connection identifier is used to identify the connection. > In connection oriented technologies it is often the case (although > not always) that all packets belonging to a specific connection use > the same route through the network. > > Connectionless > > In Connectionless technologies data is typically sent between end > points without prior arrangement. Packets are routed independently > based on their destination address, and hence different packets may > be routed in a different way across the network. > > Discussion > > The OAM tools described in this document include tools that support > connection oriented technologies, as well as tools for connectionless > technologies. > > In connection oriented technologies OAM is used to monitor a > *specific* connection; OAM packets are forwarded through the same > route as the data traffic and receive the same treatment. In > connectionless technologies, OAM is used between a source and > destination pair without defining a specific connection. Moreover, in > some cases the route of OAM packets may differ from the one of the > data traffic. For example, the connectionless IP Ping (Section 4.1.) > tests the reachability from a source to a given destination, while > the connection oriented LSP Ping (Section 4.4.) is used for > monitoring a specific LSP (connection), and provides the capability > to monitor all the available paths used by an LSP. > > > > Mizrahi, et al. Expires April 21, 2014 [Page 13] > > Internet-Draft Overview of OAM Tools October 2013 > > > It should be noted that in some cases connectionless protocols are > monitored by connection oriented OAM protocols. For example, while IP > is a connectionless protocol, it can monitored by BFD (Section 4.3. > ), which is connection oriented. > > 2.2.9. Point-to-point vs. Point-to-multipoint Services > > Point-to-point (P2P) > > A P2P service delivers data from a single source to a single > destination. > > Point-to-multipoint (P2MP) > > An P2MP service delivers data from a single source to a one or more > destinations (based on [Signal]). > > [Signal] also defines a MP2MP service as a service that delivers data > from more than one source to one or more receivers. > > SB> MP2P is a very interesting and important class - it is what > SB> a VPN service (such as RFC2547) looks like, and has some interesting > SB> instrumentation problems. > > Discussion > > The OAM tools described in this document include tools for P2P > services, as well as tools for P2MP services. > > The distinction between P2P services and P2MP services affects the > corresponding OAM tools. A P2P service is typically simpler to > monitor, as it consists of a single pair of end points. P2MP services > present several challenges. For example, in a P2MP service, the OAM > mechanism not only verifies that each of the destinations is > reachable from the source, but also verifies that the P2MP > distribution tree is intact and loop-free. Another challenge in P2MP > services is performance monitoring; while in P2P packet loss is > measured by maintaining packet counters at the two end-points, in > P2MP packet loss must be carefully measured by generating synthetic > traffic to each corresponding end-point and maintaining a separate > counter for each peer end-point. > > SB> Incorrect. You can monitor live traffic. Think counting I-frames > SB> as but one example. > > 2.2.10. Failures > > The terms Failure, Fault, and Defect are used interchangeably in the > standards, referring to a malfunction that can be detected by a > connectivity or a continuity check. In some standards, such as > 802.1ag [IEEE802.1Q] , there is no distinction between these terms, > while in other standards each of these terms refers to a different > type of malfunction. > > > > Mizrahi, et al. Expires April 21, 2014 [Page 14] > > Internet-Draft Overview of OAM Tools October 2013 > > > The terminology used in IETF MPLS-TP OAM is based on the ITU-T > terminology, which distinguishes between these three terms in > [ITU-T-G.806]; > > Fault > > The term Fault refers to an inability to perform a required action, > e.g., an unsuccessful attempt to deliver a packet. > > Defect > > The term Defect refers to an interruption in the normal operation, > such as a consecutive period of time where no packets are delivered > successfully. > > Failure > > The term Failure refers to the termination of the required function. > While a Defect typically refers to a limited period of time, a > failure refers to a long period of time. > > 3. OAM Functions > > This subsection provides a brief summary of the common OAM functions > used in OAM-related standards. These functions are used as building > blocks in the OAM standards described in this document. > > o Connectivity Verification (CV) and/or Continuity Checks (CC): > As defined in Section 2.2.7. > > o Path Discovery / Fault Localization: > This function can be used to trace the route to a destination, > i.e., to identify the nodes along the route to the destination. > When more than one route is available to a specific destination, > this function traces one of the available routes. When a failure > occurs, this function also allows to detect the location of the > failure. > Note that the term route tracing (or Traceroute) that is used in > the context of IP and MPLS, is sometimes referred to as path > tracing in the context of other protocols, such as TRILL. > > SB> What about path verification? > > o Performance Monitoring: > Typically refers to: > > o Loss Measurement (LM) - monitors the packet loss rate. > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 15] > > Internet-Draft Overview of OAM Tools October 2013 > > > o Delay Measurement (DM) - monitors the delay and delay > variation. > > 4. OAM Tools in the IETF - a Detailed Description > > This section presents a detailed description of the sets of OAM- > related tools in each of the categories in Table 1. > > 4.1. IP Ping > > Ping is a common network diagnosis application for IP networks that > uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for > Packet internet groper, although the term has been so commonly used > that it stands on its own. > > SB> I bet the true origin of the name lies with SONAR, and the rest > SB> is post-hoc justification > > As defined in [NetTerms], it is a program > used to test reachability of destinations by sending them an ICMP > echo request and waiting for a reply. > > The ICMP Echo request/reply exchange in Ping is used as a continuity > check function for the Internet Protocol. The originator transmits an > ICMP Echo request packet, and the receiver replies with an Echo > reply. ICMP ping is defined in two variants, [ICMPv4] is used for > IPv4, and [ICMPv6] is used for IPv6. > > Ping implementations typically use ICMP messages. UDP Ping is a > variant that uses UDP messages instead of ICMP echo messages. > > Ping is a single-ended continuity check, i.e., it allows the > *initiator* of the Echo request to test the reachability. If it is > desirable for both ends to test the reachability, both ends have to > invoke Ping independently. > > Note that since ICMP filtering is deployed in some routers and > firewalls, the usefulness of Ping is sometimes limited in the wider > internet. This limitation is equally relevant to Traceroute. > > 4.2. IP Traceroute > > Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows > users to discover a path between an IP source and an IP destination. > > The most common way to implement Traceroute [TCPIP-Tools] is > described as follows. Traceroute sends a sequence of UDP packets to > UDP port 33434 at the destination. By default, Traceroute begins by > sending three packets (the number of packets is configurable in most > Traceroute implementations), each with an IP Time-To-Live (or Hop > Limit in IPv6) value of one to the destination. These packets expire > as soon as they reach the first router in the path. Consequently, > > > Mizrahi, et al. Expires April 21, 2014 [Page 16] > > Internet-Draft Overview of OAM Tools October 2013 > > > that router sends three ICMP Time Exceeded Messages back to the > Traceroute application. Traceroute now sends another three UDP > packets, each with the TTL value of 2. These messages cause the > second router to return ICMP messages. This process continues, with > ever increasing values for the TTL field, until the packets actually > reach the destination. Because no application listens to port 33434 > at the destination, the destination returns ICMP Destination > Unreachable Messages indicating an unreachable port. This event > indicates to the Traceroute application that it is finished. The > Traceroute program displays the round-trip delay associated with each > of the attempts. > > While Traceroute is a tool that finds *a* path from A to B, it should > be noted that traffic from A to B is often forwarded through Equal > Cost Multiple Paths (ECMP). Paris Traceroute [Paris] is an extension > to Traceroute that attempts to discovers all the available paths from > A to B by scanning different values of header fields (such as UDP > ports) in the probe packets. > > It is noted that Traceroute is an application, and not a protocol. As > such, it has various different implementations. One of the most > common ones uses UDP probe packets, as described above. Other > implementations exist that use other types of probe messages, such as > ICMP or TCP. > > Note that IP routing may be asymmetric. While Traceroute discovers a > path between a source and destination, it does not reveal the reverse > path. > > A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in > the context of Traceroute. These documents define several extensions, > including extensions to the ICMP Destination Unreachable message, > that can be used by Traceroute applications. > > 4.3. Bidirectional Forwarding Detection (BFD) > > 4.3.1. Overview > > While multiple OAM tools have been defined for various protocols in > the protocol stack, Bidirectional Forwarding Detection [BFD], defined > by the IETF BFD working group, is a generic OAM tool that can be > deployed over various encapsulating protocols, and in various medium > types. The IETF has defined variants of the protocol for IP ([BFD- > IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD- > VCCV]. The usage of BFD in MPLS-TP is defined in [TP-CC-CV]. > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 17] > > Internet-Draft Overview of OAM Tools October 2013 > > > BFD includes two main OAM functions, using two types of BFD packets: > BFD Control packets, and BFD Echo packets. > > 4.3.2. Terminology > > BFD operates between two *systems*. The BFD protocol is run between > two systems after establishing a *session*. > > SB> Isn't there a P2MP BFD? > > 4.3.3. BFD Control > > BFD supports a bidirectional continuity check, using BFD control > packets, that are exchanged within a BFD session. BFD sessions > operate in one of two modes: > > o Asynchronous mode (i.e. proactive): in this mode BFD control > packets are sent periodically. When the receiver detects that no > BFD control packets have been received during a predetermined > period of time, a failure is detected. > > o Demand mode: in this mode, BFD control packets are sent on-demand. > Upon need, a system initiates a series of BFD control packets to > check the continuity of the session. BFD control packets are sent > independently in each direction. > > Each of the end-points (referred to as systems) of the monitored path > maintains its own session identification, called a Discriminator, > both of which are included in the BFD Control Packets that are > exchanged between the end-points. At the time of session > establishment, the Discriminators are exchanged between the two-end > points. In addition, the transmission (and reception) rate is > negotiated between the two end-points, based on information included > in the control packets. These transmission rates may be renegotiated > during the session. > > During normal operation of the session, i.e. no failures are > detected, the BFD session is in the Up state. If no BFD Control > packets are received during a period of time called the Detection > Time, the session is declared to be Down. The detection time is a > function of the pre-configured or negotiated transmission time, and a > parameter called Detect Mult. Detect Mult determines the number of > missing BFD Control packets that cause the session to be declared as > Down. This parameter is included in the BFD Control packet. > > 4.3.4. BFD Echo > > A BFD echo packet is sent to a peer system, and is looped back to the > originator. The echo function can be used proactively, or on-demand. > > > Mizrahi, et al. Expires April 21, 2014 [Page 18] > > Internet-Draft Overview of OAM Tools October 2013 > > > The BFD echo function has been defined in BFD for IPv4 and IPv6 > ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for > MPLS-TP. > > 4.4. MPLS OAM > > The IETF MPLS working group has defined OAM for MPLS LSPs. The > requirements and framework of this effort are defined in > [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM > tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for P2MP > services is defined in [MPLS-P2MP]. > > LSP Ping is modeled after the Ping/Traceroute paradigm and thus it > may be used in one of two modes: > > o "Ping" mode: In this mode LSP Ping is used for end-to-end > connectivity verification between two LERs. > > o "Traceroute" mode: This mode is used for hop-by-hop fault > isolation. > > LSP Ping extends the basic ICMP Ping operation (of data-plane > connectivity verification) with functionality to verify data-plane > vs. control-plane consistency for a Forwarding Equivalence Class > (FEC) and also Maximum Transmission Unit (MTU) problems. > > The challenge in MPLS networks is that the traffic of a given LSP may > be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping > monitors all the available paths of an LSP by monitoring its > different Forwarding Equivalence Classes (FEC). > SB> That is one challange, the real problem is that the labels > SB> are opaque at a mid-point and that the payload is not > SB> known at that point either. Also you do not have an automatic > SB> return path path other than MPLS-TP. It's not like IP where > SB> you can reverse the SA and DA into DA and SA. > > Conversely, MPLS-TP > does not use ECMP, and thus does not require OAM over multiple paths. > The Traceroute functionality may be used to isolate and localize the > MPLS faults, using the Time-to-live (TTL) indicator to incrementally > identify the sub-path of the LSP that is successfully traversed > before the faulty link or node. > > SB> Can't yo also do this in regular MPLS > > It should be noted that LSP Ping supports unique identification of > the LSP within an addressing domain. The identification is checked > using the full FEC identification. LSP Ping is easily extensible to > include additional information needed to support new functionality, > by use of Type-Length-Value (TLV) constructs. The usage of TLVs is > typically not easy to perform in hardware, and is thus typically > handled by the control plane. > > LSP Ping supports both asynchronous, as well as, on-demand > activation. > > > SB> You should get George Swallow to take a look at 4.4 > > Mizrahi, et al. Expires April 21, 2014 [Page 19] > > Internet-Draft Overview of OAM Tools October 2013 > > > 4.5. MPLS-TP OAM > > 4.5.1. Overview > > The MPLS working group has defined the OAM toolset that fulfills the > requirements for MPLS-TP OAM. The full set of requirements for MPLS- > TP OAM are defined in [MPLS-TP-OAM], and include both general > requirements for the behavior of the OAM tools and a set of > operations that should be supported by the OAM toolset. The set of > mechanisms required are further elaborated in [TP-OAM-FW], which > describes the general architecture of the OAM system as well as > giving overviews of the functionality of the OAM toolset. > > Some of the basic requirements for the OAM toolset for MPLS-TP are: > > o MPLS-TP OAM must be able to support both an IP based and non-IP > based environment. If the network is IP based, i.e. IP routing and > forwarding are available, then the MPLS-TP OAM toolset should rely > on the IP routing and forwarding capabilities. On the other hand, > in environments where IP functionality is not available, the OAM > tools must still be able to operate without dependence on IP > forwarding and routing. > > SB> "should rely on the IP routing and forwarding capabilities" That is > SB> rather ambiguous. As I recall this is only to get responses > SB> back from MIPs where the path is broken. > SB> -TP uses co-routed bidirectional channels and again as I recall > SB> the "normal" response is back via that. > > o OAM packets and the user traffic are required to be congruent > (i.e. OAM packets are transmitted in-band) and there is a need to > differentiate OAM packets from data plane ones. Inherent in this > requirement is the principle that MPLS-TP OAM be independent of > any existing control-plane, although it should not preclude use of > the control-plane functionality. > > SB> So you miss the key point in that we use L13 as an inband > SB> OAM discriminator. > > 4.5.2. Terminology > > Maintenance Entity (ME) > > The MPLS-TP OAM tools are designed to monitor and manage a > Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a > relationship between two points of a transport path to which > maintenance and monitoring operations apply. > > The term Maintenance Entity (ME) is used in ITU-T Recommendations > (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology > ([TP-OAM-FW]). > > Maintenance Entity Group (MEG) > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 20] > > Internet-Draft Overview of OAM Tools October 2013 > > > The collection of one or more MEs that belongs to the same transport > path and that are maintained and monitored as a group are known as a > Maintenance Entity Group (based on [TP-OAM-FW]). > > Maintenance Point (MP) > > A Maintenance Point (MP) is a functional entity that is defined at a > node in the network, and can initiate and/or react to OAM messages. > This document focuses on the data-plane functionality of MPs, while > MPs interact with the control plane and with the management plane as > well. > > The term MP is used in IEEE 802.1ag, and was similarly adopted in > MPLS-TP ([TP-OAM-FW]). > > Maintenance End Point (MEP) > > A Maintenance End Point (MEP) is one of the end points of an ME, and > can initiate OAM messages and respond to them (based on [TP-OAM-FW]). > > Maintenance Intermediate Point (MIP) > > In between MEPs, there are zero or more intermediate points, called > Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]). > > A Maintenance Intermediate Point (MIP) is an intermediate point that > does not generally initiate OAM frames (one exception to this is the > use of AIS notifications), but is able to respond to OAM frames that > are destined to it. A MIP in MPLS-TP identifies OAM packets destined > to it by the value of the TTL field in the OAM packet. The term > Maintenance Point is a general term for MEPs and MIPs. > > Up and Down MEPs > > The IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs > and Down MEPs. A MEP is a bridge interface that is monitored by an > OAM protocol either in the direction facing the network, or in the > direction facing the bridge. A Down MEP is a MEP that receives OAM > packets from, and transmits them to the direction of the network. An > Up MEP receives OAM packets from, and transmits them to the direction > of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar > distinction on the placement of the MEP - either at the ingress, > egress, or forwarding function of the node (Down / Up MEPs). This > placement is important for localization of a failure. > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 21] > > Internet-Draft Overview of OAM Tools October 2013 > > > The distinction between Up and Down MEPs was defined in [TP-OAM-FW], > but has not been used in other MPLS-TP RFCs, as of the writing of > this document. > > 4.5.3. Generic Associated Channel > > In order to address the requirement for in-band transmission of MPLS- > TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), > defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based > on the same concepts as the PWE3 ACH and VCCV mechanisms. However, > to address the needs of LSPs as differentiated from PW, the following > concepts were defined for [G-ACh]: > > o An Associated Channel Header (ACH), that uses a format similar to > the PW Control Word, is a 4-byte header that is prepended to OAM > packets. > > o A Generic Associated Label (GAL). The GAL is a reserved MPLS label > value (13) that indicates that the packet is an ACH packet and the > payload follows immediately after the label stack. > > It should be noted that while the G-ACh was defined as part of the > MPLS-TP definition effort, the G-ACh is a generic tool that can be > used in MPLS in general, and not only in MPLS-TP. > > SB> Whilst historically what you say is true WRT PWE3, I think the > SB> approach confuses the reader, particularly as they have not yet > SB> met PWE3 in this document. > > 4.5.4. MPLS-TP OAM Toolset > > To address the functionality that is required of the OAM toolset, the > MPLS WG conducted an analysis of the existing IETF and ITU-T OAM > tools and their ability to fulfill the required functionality. The > conclusions of this analysis are documented in [OAM-Analys]. The MPLS > working group currently plans to use a mixture of OAM tools that are > based on various existing standards, and adapt them to the > requirements of [MPLS-TP-OAM]. Some of the main building blocks of > this solution are based on: > > o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for > proactive continuity check and connectivity verification. > > o LSP Ping as defined in [LSP-Ping] for on-demand connectivity > verification. > > o New protocol packets, using G-ACH, to address different > functionality. > > o Performance measurement protocols that are based on the > functionality that is described in [ITU-T-Y1731]. > > > Mizrahi, et al. Expires April 21, 2014 [Page 22] > > Internet-Draft Overview of OAM Tools October 2013 > > > The following sub-sections describe the OAM tools defined for MPLS-TP > as described in [TP-OAM-FW]. > > 4.5.4.1. Continuity Check and Connectivity Verification > > Continuity Check and Connectivity Verification are presented in > Section 2.2.7. of this document. As presented there, these tools may > be used either proactively or on-demand. When using these tools > proactively, they are generally used in tandem. > > For MPLS-TP there are two distinct tools, the proactive tool is > defined in [TP-CC-CV] while the on-demand tool is defined in > [OnDemand-CV]. In on-demand mode, this function should support > monitoring between the MEPs and, in addition, between a MEP and MIP. > [TP-OAM-FW] highlights, when performing Connectivity Verification, > the need for the CC-V messages to include unique identification of > the MEG that is being monitored and the MEP that originated the > message. > > The proactive tool [TP-CC-CV] is based on extensions to BFD (see > Section 4.3.) with the additional limitation that the transmission > and receiving rates are based on configuration by the operator. The > on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see > Section 4.4.) for the required behavior of MPLS-TP. > > 4.5.4.2. Route Tracing > > [MPLS-TP-OAM] defines that there is a need for functionality that > would allow a path end-point to identify the intermediate and end- > points of the path. This function would be used in on-demand mode. > Normally, this path will be used for bidirectional PW, LSP, and > sections, however, unidirectional paths may be supported only if a > return path exists. The tool for this is based on the LSP Ping (see > Section 4.4.) functionality and is described in [OnDemand-CV]. > > 4.5.4.3. Lock Instruct > > The Lock Instruct function [Lock-Loop] is used to notify a transport > path end-point of an administrative need to disable the transport > path. This functionality will generally be used in conjunction with > some intrusive OAM function, e.g. Performance measurement, Diagnostic > testing, to minimize the side-effect on user data traffic. > > > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 23] > > Internet-Draft Overview of OAM Tools October 2013 > > > 4.5.4.4. Lock Reporting > > Lock Reporting is a function used by an end-point of a path to report > to its far-end end-point that a lock condition has been affected on > the path. > > 4.5.4.5. Alarm Reporting > > Alarm Reporting [TP-Fault] provides the means to suppress alarms > following detection of defect conditions at the server sub-layer. > Alarm reporting is used by an intermediate point of a path, that > becomes aware of a fault on the path, to report to the end-points of > the path. [TP-OAM-FW] states that this may occur as a result of a > defect condition discovered at a server sub-layer. This generates an > Alarm Indication Signal (AIS) that continues until the fault is > cleared. The consequent action of this function is detailed in > [TP-OAM-FW]. > > 4.5.4.6. Remote Defect Indication > > Remote Defect Indication (RDI) is used proactively by a path end- > point to report to its peer end-point that a defect is detected on a > bidirectional connection between them. [MPLS-TP-OAM] points out that > this function may be applied to a unidirectional LSP only if there a > return path exists. [TP-OAM-FW] points out that this function is > associated with the proactive CC-V function. > > 4.5.4.7. Client Failure Indication > > Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow > the propagation information from one edge of the network to the > other. The information concerns a defect to a client, in the case > that the client does not support alarm notification. > > 4.5.4.8. Performance Monitoring > > The definition of MPLS performance monitoring was motivated by the > MPLS-TP requirements [MPLS-TP-OAM], but was defined generically for > MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines a > performance monitoring profile for MPLS-TP. > > 4.5.4.8.1. Packet Loss Measurement (LM) > > Packet Loss Measurement is a function used to verify the quality of > the service. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM], > indicates the ratio of the number of user packets lost to the total > number of user packets sent during a defined time interval. > > > Mizrahi, et al. Expires April 21, 2014 [Page 24] > > Internet-Draft Overview of OAM Tools October 2013 > > > There are two possible ways of determining this measurement: > > o Using OAM packets, it is possible to compute the statistics based > on a series of OAM packets. This, however, has the disadvantage of > being artificial, and may not be representative since part of the > packet loss may be dependent upon packet sizes and upon the > implementation of the MEPs that take part in the protocol. > > o Sending delimiting messages for the start and end of a measurement > period during which the source and sink of the path count the > packets transmitted and received. After the end delimiter, the > ratio would be calculated by the path OAM entity. > > SB> This needs some references - To some of the early work and to the > SB> more recent work by TI. > SB> Note that this contradicts earlier statements about P2MP live > SB> traffic measurement. > > 4.5.4.8.2. Packet Delay Measurement (DM) > > Packet Delay Measurement is a function that is used to measure one- > way or two-way delay of a packet transmission between a pair of the > end-points of a path (PW, LSP, or Section). Where: > > o One-way packet delay, as defined in [IPPM-1DM], is the time > elapsed from the start of transmission of the first bit of the > packet by a source node until the reception of the last bit of > that packet by the destination node. Note that one-way delay > measurement requires the clocks of the two end-points to be > synchronized. > > o Two-way packet delay, as defined in [IPPM-2DM], is the time > elapsed from the start of transmission of the first bit of the > packet by a source node until the reception of the last bit of the > loop-backed packet by the same source node, when the loopback is > performed at the packet's destination node. Note that due to > possible path asymmetry, the one-way packet delay from one end- > point to another is not necessarily equal to half of the two-way > packet delay. > As opposed to one-way delay measurement, two-way delay measurement > does not require the two end-points to be synchronized. > > For each of these two metrics, the DM function allows the MEP to > measure the delay, as well as the delay variation. Delay measurement > is performed by exchanging timestamped OAM packets between the > participating MEPs. > > > > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 25] > > Internet-Draft Overview of OAM Tools October 2013 > > > 4.6. Pseudowire OAM > > 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification > (VCCV) > > VCCV, as defined in [VCCV], provides a means for end-to-end fault > detection and diagnostics tools to be extended for PWs (regardless of > the underlying tunneling technology). The VCCV switching function > provides a control channel associated with each PW. [VCCV] defines > three Control Channel (CC) types, i.e., three possible methods for > transmitting and identifying OAM messages: > > o CC Type 1: In-band VCCV, as described in [VCCV], is also referred > to as "PWE3 Control Word with 0001b as first nibble". It uses the > PW Associated Channel Header [PW-ACH]. > > o CC Type 2: Out-of-band VCCV [VCCV], is also referred to as "MPLS > Router Alert Label". In this case the control channel is created > by using the MPLS router alert label [RFC3032] immediately above > the PW label. > > o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as "MPLS PW > Label with TTL == 1", i.e., the control channel is identified when > the value of the TTL field in the PW label is set to 1. > > VCCV currently supports the following OAM tools: ICMP Ping, LSP Ping, > and BFD. ICMP and LSP Ping are IP encapsulated before being sent over > the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of > encapsulation - either IP/UDP encapsulated (with IP/UDP header) or > PW-ACH encapsulated (with no IP/UDP header) and provides support to > signal the AC status. The use of the VCCV control channel provides > the context, based on the MPLS-PW label, required to bind and > bootstrap the BFD session to a particular pseudo wire (FEC), > eliminating the need to exchange Discriminator values. > > VCCV consists of two components: (1) signaled component to > communicate VCCV capabilities as part of VC label, and (2) switching > component to cause the PW payload to be treated as a control packet. > > VCCV is not directly dependent upon the presence of a control plane. > The VCCV capability negotiation may be performed as part of the PW > signaling when LDP is used. In case of manual configuration of the > PW, it is the responsibility of the operator to set consistent > options at both ends. The manual option was created specifically to > handle MPLS-TP use cases where no control plane was a requirement. > However, new use cases such as pure mobile backhaul find this > functionality useful too. > > SB> There is a strange logic in the flow above - it is not depenent, > it uses > SB> the CP - it can be configured > > > Mizrahi, et al. Expires April 21, 2014 [Page 26] > > Internet-Draft Overview of OAM Tools October 2013 > > > The PWE3 working group has conducted an implementation survey of VCCV > [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in > practice. > > 4.6.2. Pseudowire OAM using G-ACh > > As mentioned above, VCCV enables OAM for PWs by using a control > channel for OAM packets. When PWs are used in MPLS-TP networks, > rather than the control channels defined in VCCV, the G-ACh can be > used as an alternative control channel. The usage of the G-ACh for > PWs is defined in [PW-G-ACh]. > > 4.6.3. Attachment Circuit - Pseudowire Mapping > > SB> Isn't this message mapping? > > The PWE3 working group has defined a mapping and notification of > defect states between a pseudowire (PW) and the Attachment Circuits > (ACs) of the end-to-end emulated service. This mapping is of key > importance to the end-to-end functionality. Specifically, the mapping > is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and > Section 5.3 of [ATM-L2] for ATM. > > 4.7. OWAMP and TWAMP > > 4.7.1. Overview > > SB> See my earlier note about whether his is measuring > SB> data plane performance or transport layer performance. > > The IPPM working group in the IETF defines common criteria and > metrics for measuring performance of IP traffic ([IPPM-FW]). Some of > the key RFCs published by this working group have defined metrics for > measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), > and packet loss [IPPM-1LM]. It should be noted that the work of the > IETF in the context of performance metrics is not limited to IP > networks; [PM-CONS] presents general guidelines for considering new > performance metrics. > > The IPPM working group has defined not only metrics for performance > measurement, but also protocols that define how the measurement is > carried out. The One-way Active Measurement Protocol [OWAMP] and the > Two-Way Active Measurement Protocol [TWAMP] define a method and > protocol for measuring performance metrics in IP networks. > > OWAMP [OWAMP] enables measurement of one-way characteristics of IP > networks, such as one-way packet loss and one-way delay. For its > proper operation OWAMP requires accurate time of day setting at its > end points. > > TWAMP [TWAMP] is a similar protocol that enables measurement of both > one-way and two-way (round trip) characteristics. > > > Mizrahi, et al. Expires April 21, 2014 [Page 27] > > Internet-Draft Overview of OAM Tools October 2013 > > > OWAMP and TWAMP are both comprised of two separate protocols: > > o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop > test sessions and to fetch their results. Continuity Check and > Connectivity Verification are tested and confirmed by establishing > the OWAMP/TWAMP Control Protocol TCP connection. > > o OWAMP-Test/TWAMP-Test: used to exchange test packets between two > measurement nodes. Enables the loss and delay measurement > functions, as well as detection of other anomalies, such as packet > duplication and packet reordering. > > It should be noted that while [OWAMP] and [TWAMP] define tools for > performance measurement, they do not define the accuracy of these > tools. The accuracy depends on scale, implementation and network > configurations. > > Alternative protocols for performance monitoring are defined, for > example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet > OAM [ITU-T-Y1731]. > > 4.7.2. Control and Test Protocols > > OWAMP and TWAMP control protocols run over TCP, while the test > protocols run over UDP. The purpose of the control protocols is to > initiate, start, and stop test sessions, and for OWAMP to fetch > results. The test protocols introduce test packets (which contain > sequence numbers and timestamps) along the IP path under test > according to a schedule, and record statistics of packet arrival. > Multiple sessions may be simultaneously defined, each with a session > identifier, and defining the number of packets to be sent, the amount > of padding to be added (and thus the packet size), the start time, > and the send schedule (which can be either a constant time between > test packets or exponentially distributed pseudo-random). Statistics > recorded conform to the relevant IPPM RFCs. > > OWAMP and TWAMP test traffic is designed with security in mind. Test > packets are hard to detect because they are simply UDP streams > between negotiated port numbers, with potentially nothing static in > the packets. OWAMP and TWAMP also include optional authentication > and encryption for both control and test packets. > > > 4.7.3. OWAMP > > OWAMP defines the following logical roles: Session-Sender, Session- > Receiver, Server, Control-Client, and Fetch-Client. The Session- > Sender originates test traffic that is received by the Session- > > > Mizrahi, et al. Expires April 21, 2014 [Page 28] > > Internet-Draft Overview of OAM Tools October 2013 > > > Receiver. The Server configures and manages the session, as well as > returning the results. The Control-Client initiates requests for > test sessions, triggers their start, and may trigger their > termination. The Fetch-Client requests the results of a completed > session. Multiple roles may be combined in a single host - for > example, one host may play the roles of Control-Client, Fetch-Client, > and Session-Sender, and a second playing the roles of Server and > Session-Receiver. > > In a typical OWAMP session the Control-Client establishes a TCP > connection to port 861 of the Server, which responds with a server > greeting message indicating supported security/integrity modes. The > Control-Client responds with the chosen communications mode and the > Server accepts the modes. The Control-Client then requests and fully > describes a test session to which the Server responds with its > acceptance and supporting information. More than one test session > may be requested with additional messages. The Control-Client then > starts a test session and the Server acknowledges. The Session- > Sender then sends test packets with pseudorandom padding to the > Session-Receiver until the session is complete or until the Control- > client stops the session. Once finished, the Fetch-Client sends a > fetch request to the server, which responds with an acknowledgement > and immediately thereafter the result data. > > 4.7.4. TWAMP > > TWAMP defines the following logical roles: session-sender, session- > reflector, server, and control-client. These are similar to the > OWAMP roles, except that the Session-Reflector does not collect any > packet information, and there is no need for a Fetch-Client. > > In a typical TWAMP session the Control-Client establishes a TCP > connection to port 862 of the Server, and mode is negotiated as in > OWAMP. The Control-Client then requests sessions and starts them. > The Session-Sender sends test packets with pseudorandom padding to > the Session-Reflector which returns them with insertion of > timestamps. > > 4.8. TRILL > > The requirements of OAM in TRILL are defined in [TRILL-OAM]. The > challenge in TRILL OAM, much like in MPLS networks, is that traffic > between RBridges RB1 and RB2 may be forwarded through more than one > path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able > to monitor all the available paths between the two RBridge. > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 29] > > Internet-Draft Overview of OAM Tools October 2013 > > > During the writing of this document the detailed definition of the > TRILL OAM tools are still work in progress. This subsection presents > the main requirements of TRILL OAM. > > The main requirements defined in [TRILL-OAM] are: > > o Continuity Checking (CC) - the TRILL OAM protocol must support a > function for CC between any two RBridges RB1 and RB2. > > o Connectivity Verification (CV) - connectivity between two RBridges > RB1 and RB2 can be verified on a per-flow basis. > > o Path Tracing - allows an RBridge to trace all the available paths > to a peer RBridge. > > o Performance monitoring - allows an RBridge to monitor the packet > loss and packet delay to a peer RBridge. > > 4.9. Summary of OAM Tools > > This subsection provides a short summary of each of the OAM tool > categories described in this document. > > A detailed list of the RFCs related to each category is given in > Appendix A.1. > > +-----------+------------------------------------------+------------+ > | Category | Description | Transport | > | | | Technology | > +-----------+------------------------------------------+------------+ > |IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 | > | | application for testing reachability that| | > | | uses ICMP Echo messages ([ICMPv4], | | > | | [ICMPv6]). | | > +-----------+------------------------------------------+------------+ > |IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | > |Traceroute | an application that allows users to trace| | > | | the path between an IP source and an IP | | > | | destination, i.e., to identify the nodes | | > | | along the path. If more than one path | | > | | exists between the source and destination| | > | | Traceroute traces *a* path. The most | | > | | common implementation of Traceroute | | > | | uses UDP probe messages, although there | | > > > Mizrahi, et al. Expires April 21, 2014 [Page 30] > > Internet-Draft Overview of OAM Tools October 2013 > > > | | are other implementations that use | | > | | different probes, such as ICMP or TCP. | | > +-----------+------------------------------------------+------------+ > |BFD | Bidirectional Forwarding Detection (BFD) | generic | > | | is defined in [BFD] as a framework for a | | > | | lightweight generic OAM tool. The | | > | | intention is to define a base tool | | > | | that can be used with various | | > | | encapsulation types, network | | > | | environments, and in various medium | | > | | types. | | > +-----------+------------------------------------------+------------+ > |MPLS OAM | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS | > | | [MPLS-OAM-FW] and [LSP-Ping], is an OAM | | > | | tool for point-to-point and | | > | | point-to-multipoint MLPS LSPs. | | > | | It includes two main functions: Ping and | | > | | Traceroute. | | > | | It is noted that while this category | | > | | focuses on LSP Ping, other OAM tools | | > | | can be used in MPLS networks, e.g., BFD. | | > +-----------+------------------------------------------+------------+ > |MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP | > | | The OAM requirements for MPLS Transport | | > | | Profile (MPLS-TP) are defined in | | > | | [MPLS-TP-OAM]. Each of the tools in the | | > | | OAM toolset is defined in its own RFC, as| | > | | specified in Section A.1. | | > +-----------+------------------------------------------+------------+ > |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire | > |OAM | channels that support the use of existing| | > | | IETF OAM tools to be used for a pseudo- | | > | | wire (PW). The control channels that are| | > | | defined in [VCCV] and [PW-G-ACh] may be | | > | | used in conjunction with ICMP Ping, LSP | | > | | Ping, and BFD to perform CC and CV | | > | | functionality. In addition the channels | | > | | support use of any of the MPLS-TP based | | > | | OAM tools for completing their respective| | > | | OAM functionality for a PW. | | > +-----------+------------------------------------------+------------+ > > > Mizrahi, et al. Expires April 21, 2014 [Page 31] > > Internet-Draft Overview of OAM Tools October 2013 > > > |OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 | > |TWAMP | (OWAMP) and the Two Way Active Measure- | | > | | ment Protocols (TWAMP) are two protocols | | > | | defined in the IP Performance Metrics | | > | | (IPPM) working group in the IETF. These | | > | | protocols allow various performance | | > | | metrics to be measured, such as packet | | > | | loss, delay and delay variation, | | > | | duplication and reordering. | | > +-----------+------------------------------------------+------------+ > |TRILL OAM | The requirements of OAM in TRILL are | TRILL | > | | defined in [TRILL-OAM]. These | | > | | requirements include continuity checking,| | > | | connectivity verification, path tracing | | > | | and performance monitoring. During the | | > | | writing of this document the detailed | | > | | definition of the TRILL OAM tools | | > | | is work in progress. | | > +-----------+------------------------------------------+------------+ > Table 3 Summary of OAM-related IETF Tools > > 4.10. Summary of OAM Functions > > Table 4 summarizes the OAM functions that are supported in each of > the categories that were analyzed in this section. The columns of > this tables are the typical OAM functions described in Section 1.3. > > +-----------+-------+--------+--------+-------+----------+ > | |Continu|Connecti|Path |Perform|Other | > | |ity |vity |Discover|ance |Function | > | |Check |Verifica|y |Monitor|s | > | Category | |tion | |ing | | > +-----------+-------+--------+--------+-------+----------+ > |IP Ping |Echo | | | | | > + --------- + ----- + ------ + ------ + ----- + -------- + > |IP | | |Tracerou| | | > |Traceroute | | |te | | | > + --------- + ----- + ------ + ------ + ----- + -------- + > |BFD |BFD |BFD | | |RDI usi- | > | |Control|Control | | |ng BFD | > | |/ Echo | | | |Control | > + --------- + ----- + ------ + ------ + ----- + -------- + > > > Mizrahi, et al. Expires April 21, 2014 [Page 32] > > Internet-Draft Overview of OAM Tools October 2013 > > > |MPLS OAM | |"Ping" |"Tracero| | | > |(LSP Ping) | |mode |ute" | | | > | | | |mode | | | > + --------- + ----- + ------ + ------ + ----- + -------- + > |MPLS-TP |CC |CV/pro- |Route |-LM |-Diagnos- | > |OAM | |active |Tracing |-DM | tic Test | > | | |or on- | | |-Lock | > | | |demand | | |-Alarm | > | | | | | |Reporting | > | | | | | |-Client | > | | | | | |Failure | > | | | | | |Indication| > | | | | | |-RDI | > + --------- + ----- + ------ + ------ + ----- + -------- + > |Pseudowire |BFD |-BFD |LSP-Ping| | | > |OAM | |-ICMP | | | | > | | | Ping | | | | > | | |-LSP- | | | | > | | | Ping | | | | > + --------- + ----- + ------ + ------ + ----- + -------- + > |OWAMP and | - control | |-Delay | | > |TWAMP | protocol | | measur| | > | | | | ement | | > | | | |-Packet| | > | | | | loss | | > | | | | measur| | > | | | | ement | | > + --------- + ----- + ------ + ------ + ----- + -------- + > |TRILL OAM |CC |CV |Path |-Delay | | > | | | |tracing | measur| | > | | | | | ement | | > | | | | |-Packet| | > | | | | | loss | | > | | | | | measur| | > | | | | | ement | | > +-----------+-------+--------+--------+-------+----------+ > Table 4 Summary of the OAM Functionality in IETF OAM Tools > > 5. Security Considerations > > This memo presents an overview of existing OAM tools, and proposes > no new OAM tools. Therefore, this document introduces no security > > > Mizrahi, et al. Expires April 21, 2014 [Page 33] > > Internet-Draft Overview of OAM Tools October 2013 > > > considerations. However, the OAM tools reviewed in this document can > and do present security issues. The reader is encouraged to review > the Security Considerations section of each document referenced by > this memo. > > 6. IANA Considerations > > There are no new IANA considerations implied by this document. > > 7. Acknowledgments > > The authors gratefully acknowledge Sasha Vainshtein, Carlos > Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other > members of the OPSAWG mailing list for their helpful comments. > > This document was prepared using 2-Word-v2.0.template.dot. > > 8. References > > 8.1. Informative References > > [ATM-L2] Singh, S., Townsley, M., and C. Pignataro, > "Asynchronous Transfer Mode (ATM) over Layer 2 > Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May > 2006. > > [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection > (BFD)", RFC 5880, June 2010. > > [BFD-Gen] Katz, D., Ward, D., "Generic Application of > Bidirectional Forwarding Detection (BFD)", RFC 5882, > June 2010. > > [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection > (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June > 2010. > > [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, > G., "Bidirectional Forwarding Detection (BFD) for MPLS > Label Switched Paths (LSPs)", RFC 5884, June 2010. > > [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection > (BFD) for Multihop Paths", RFC 5883, June 2010. > > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 34] > > Internet-Draft Overview of OAM Tools October 2013 > > > [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding > Detection (BFD) for the Pseudowire Virtual Circuit > Connectivity Verification (VCCV)", RFC 5885, June > 2010. > > [Comp] Bonaventure, O., "Computer Networking: Principles, > Protocols and Practice", 2008. > > [Cont] Dugal, D., Pignataro, C., Dunn, R., "Protecting the > Router Control Plane", RFC 6192, March 2011. > > [Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", > RFC 5560, May 2009. > > [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic > Associated Channel", RFC 5586, June 2009. > > [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP > Extensions for Multiprotocol Label Switching", RFC > 4950, August 2007. > > [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, > JR., "Extending ICMP for Interface and Next-Hop > Identification", RFC 5837, April 2010. > > [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., > "Extended ICMP to Support Multi-Part Messages", RFC > 4884, April 2007. > > [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, > RFC 792, September 1981. > > [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control > Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification", RFC 4443, March 2006. > > [IEEE802.1Q] IEEE 802.1Q, "IEEE Standard for Local and metropolitan > area networks - Media Access Control (MAC) Bridges and > Virtual Bridged Local Area Networks", October 2012. > > [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - > Local and metropolitan area networks - Carrier sense > multiple access with collision detection (CSMA/CD) > access method and physical layer specifications", > clause 57, December 2008. > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 35] > > Internet-Draft Overview of OAM Tools October 2013 > > > [IntHost] Braden, R., "Requirements for Internet Hosts -- > Communication Layers", RFC 1122, October 1989. > > [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way > Delay Metric for IPPM", RFC 2679, September 1999. > > [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way > Packet Loss Metric for IPPM", RFC 2680, September > 1999. > > [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip > Delay Metric for IPPM", RFC 2681, September 1999. > > [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring > Connectivity", RFC 2678, September 1999. > > [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., > "Framework for IP Performance Metrics", RFC 2330, May > 1998. > > [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, > Administration and Maintenance mechanism for MPLS-TP > in Packet Transport Network (PTN)", November 2012. > > [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, > administration and maintenance mechanisms for MPLS-TP > networks using the tools defined for MPLS", November > 2012. > > [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel > Type for ITU-T MPLS Transport Profile Operation, > Maintenance, and Administration (MPLS-TP OAM)", RFC > 6671, November 2012. > > [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of > transport equipment - Description methodology and > generic functionality", January 2009. > > [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance > mechanism for MPLS networks", February 2004. > > [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and > Mechanisms for Ethernet-based Networks", July 2011. > > [ITU-Terms] ITU-R/ITU-T Terms and Definitions, online, 2013. > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 36] > > Internet-Draft Overview of OAM Tools October 2013 > > > [L2TP-EC] McGill, N. and C. Pignataro, "Layer 2 Tunneling > Protocol Version 3 (L2TPv3) Extended Circuit Status > Values", RFC 5641, August 2009. > > [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, > M., Dai, X., "MPLS Transport Profile Lock Instruct and > Loopback Functions", RFC 6435, November 2011. > > [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol > Label Switched (MPLS) Data Plane Failures", RFC 4379, > February 2006. > > [Mng] Farrel, A., "Inclusion of Manageability Sections in > Path Computation Element (PCE) Working Group Drafts", > RFC 6123, February 2011. > > [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay > Measurement for MPLS Networks", RFC 6374, September > 2011. > > [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., > Matsushima, S., "Operations and Management (OAM) > Requirements for Multi-Protocol Label Switched (MPLS) > Networks", RFC 4377, February 2006. > > [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol > Label Switching (MPLS) Operations and Management > (OAM)", RFC 4378, February 2006. > > [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., > "Operations and Management (OAM) Requirements for > Point-to-Multipoint MPLS Networks", RFC 4687, > September 2006. > > [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for > OAM in MPLS Transport Networks", RFC 5860, May 2010. > > [NetTerms] Jacobsen, O., Lynch, D., "A Glossary of Networking > Terms", RFC 1208, March 1991. > > [NetTools] Enger, R., Reynolds, J., "FYI on a Network Management > Tool Catalog: Tools for Monitoring and Debugging > TCP/IP Internets and Interconnected Devices", RFC > 1470, June 1993. > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 37] > > Internet-Draft Overview of OAM Tools October 2013 > > > [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool > Set for MPLS based Transport Networks", RFC 6669, > July 2012. > > [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, > D., Mansfield, S., "Guidelines for the use of the OAM > acronym in the IETF ", RFC 6291, June 2011. > > [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for > Multiprotocol Label Switching Architecture (MPLS) > Operation and Maintenance (OAM) Functions", RFC 3429, > November 2002. > > [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS > On-Demand Connectivity Verification and Route > Tracing", RFC 6426, November 2011. > > [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and > Zekauskas, M., "A One-way Active Measurement Protocol > (OWAMP)", RFC 4656, September 2006. > > [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, > "Measuring Load-balanced Paths in the Internet", IMC, > 2007. > > [PM-CONS] Clark, A. and B. Claise, "Guidelines for Considering > New Performance Metric Development", BCP 170, RFC > 6390, October 2011. > > [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., > "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word > for Use over an MPLS PSN", RFC 4385, February 2006. > > [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the > Generic Associated Channel Label for Pseudowire in the > MPLS Transport Profile (MPLS-TP)", RFC 6423, November > 2011. > > [PW-MAP] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., > Nadeau, T., and Y(J). Stein, "Pseudowire (PW) > Operations, Administration, and Maintenance (OAM) > Message Mapping", RFC 6310, July 2011. > > [PW-Map] M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. > Nadeau, "Pseudowire (PW) Operations, Administration, > and Maintenance (OAM) Message Mapping", RFC 6310, July > 2011. > > > Mizrahi, et al. Expires April 21, 2014 [Page 38] > > Internet-Draft Overview of OAM Tools October 2013 > > > [Reorder] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, > S., and J. Perser, "Packet Reordering Metrics", RFC > 4737, November 2006. > > [Signal] Yasukawa, S., "Signaling Requirements for Point-to- > Multipoint Traffic-Engineered MPLS Label Switched > Paths (LSPs)", RFC 4461, April 2006. > > [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and > TCP/IP Tools and Utilities", RFC 2151, June 1997. > > [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive > Connectivity Verification, Continuity Check and Remote > Defect indication for MPLS Transport Profile", RFC > 6428, November 2011. > > [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., > "MPLS Fault Management Operations, Administration, and > Maintenance (OAM)", RFC 6427, November 2011. > > [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay > Measurement Profile for MPLS-Based Transport > Networks", RFC 6375, September 2011. > > [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and > Maintenance Framework for MPLS-based Transport > Networks ", RFC 6371, September 2011. > > [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A > Thesaurus for the Terminology used in Multiprotocol > Label Switching Transport Profile (MPLS-TP) > drafts/RFCs and ITU-T's Transport Network > Recommendations", work-in-progress, draft-ietf-mpls- > tp-rosetta-stone, July 2012. > > [TRILL-OAM] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve, > R., "Requirements for Operations, Administration, and > Maintenance (OAM) in Transparent Interconnection of > Lots of Links (TRILL)", RFC 6905, March 2013. > > [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and > Babiarz, J., "A Two-Way Active Measurement Protocol > (TWAMP)", RFC 5357, October 2008. > > [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit > Connectivity Verification (VCCV): A Control Channel > for Pseudowires", RFC 5085, December 2007. > > > Mizrahi, et al. Expires April 21, 2014 [Page 39] > > Internet-Draft Overview of OAM Tools October 2013 > > > [VCCV-SURVEY] Del Regno, N., Malis, A., "The Pseudowire (PW) & > Virtual Circuit Connectivity Verification (VCCV) > Implementation Survey Results", work-in-progress, > draft-ietf-pwe3-vccv-impl-survey-results, August 2013. > > > > Appendix A. List of OAM Documents > > SB> My feeling is that this material would be better locate don a Wiki > > A.1. List of IETF OAM Documents > > Table 5 summarizes the OAM related RFCs published by the IETF. > > It is important to note that the table lists various RFCs that are > different by nature. For example, some of these documents define OAM > tools or OAM protocols (or both), while others define protocols that > are not strictly OAM-related, but are used by OAM tools. The table > also includes RFCs that define the requirements or the framework of > OAM in a specific context (e.g., MPLS-TP). > > The RFCs in the table are categorized in a few sets as defined in > Section 1.3. > > +-----------+--------------------------------------+----------+ > | Category | Title | RFC | > +-----------+--------------------------------------+----------+ > |IP Ping | Requirements for Internet Hosts -- | RFC 1122 | > | | Communication Layers [IntHost] | | > | +--------------------------------------+----------+ > | | A Glossary of Networking Terms | RFC 1208 | > | | [NetTerms] | | > | +--------------------------------------+----------+ > | | Internet Control Message Protocol | RFC 792 | > | | [ICMPv4] | | > | +--------------------------------------+----------+ > | | Internet Control Message Protocol | RFC 4443 | > | | (ICMPv6) for the Internet Protocol | | > | | Version 6 (IPv6) Specification | | > | | [ICMPv6] | | > +-----------+--------------------------------------+----------+ > |IP | A Primer On Internet and TCP/IP | RFC 2151 | > |Traceroute | Tools and Utilities [TCPIP-Tools] | | > | +--------------------------------------+----------+ > | | FYI on a Network Management Tool | RFC 1470 | > > > Mizrahi, et al. Expires April 21, 2014 [Page 40] > > Internet-Draft Overview of OAM Tools October 2013 > > > | | Catalog: Tools for Monitoring and | | > | | Debugging TCP/IP Internets and | | > | | Interconnected Devices [NetTools] | | > | +--------------------------------------+----------+ > | | Internet Control Message Protocol | RFC 792 | > | | [ICMPv4] | | > | +--------------------------------------+----------+ > | | Internet Control Message Protocol | RFC 4443 | > | | (ICMPv6) for the Internet Protocol | | > | | Version 6 (IPv6) Specification | | > | | [ICMPv6] | | > | +--------------------------------------+----------+ > | | Extended ICMP to Support Multi-Part | RFC 4884 | > | | Messages [ICMP-MP] | | > | +--------------------------------------+----------+ > | | Extending ICMP for Interface and | RFC 5837 | > | | Next-Hop Identification [ICMP-Int] | | > +-----------+--------------------------------------+----------+ > |BFD | Bidirectional Forwarding Detection | RFC 5880 | > | | [BFD] | | > | +--------------------------------------+----------+ > | | Bidirectional Forwarding Detection | RFC 5881 | > | | (BFD) for IPv4 and IPv6 (Single Hop) | | > | | [BFD-IP] | | > | +--------------------------------------+----------+ > | | Generic Application of Bidirectional | RFC 5882 | > | | Forwarding Detection [BFD-Gen] | | > | +--------------------------------------+----------+ > | | Bidirectional Forwarding Detection | RFC 5883 | > | | (BFD) for Multihop Paths [BFD-Multi] | | > | +--------------------------------------+----------+ > | | Bidirectional Forwarding Detection | RFC 5884 | > | | for MPLS Label Switched Paths (LSPs) | | > | | [BFD-LSP] | | > | +--------------------------------------+----------+ > | | Bidirectional Forwarding Detection | RFC 5885 | > | | for the Pseudowire Virtual Circuit | | > | | Connectivity Verification (VCCV) | | > | | [BFD-VCCV] | | > +-----------+--------------------------------------+----------+ > |MPLS OAM | Operations and Management (OAM) | RFC 4377 | > > > Mizrahi, et al. Expires April 21, 2014 [Page 41] > > Internet-Draft Overview of OAM Tools October 2013 > > > | | Requirements for Multi-Protocol Label| | > | | Switched (MPLS) Networks [MPLS-OAM] | | > | +--------------------------------------+----------+ > | | A Framework for Multi-Protocol | RFC 4378 | > | | Label Switching (MPLS) Operations | | > | | and Management (OAM) [MPLS-OAM-FW] | | > | +--------------------------------------+----------+ > | | Detecting Multi-Protocol Label | RFC 4379 | > | | Switched (MPLS) Data Plane Failures | | > | | [LSP-Ping] | | > | +--------------------------------------+----------+ > | | Operations and Management (OAM) | RFC 4687 | > | | Requirements for Point-to-Multipoint | | > | | MPLS Networks [MPLS-P2MP] | | > | +--------------------------------------+----------+ > | | ICMP Extensions for Multiprotocol | RFC 4950 | > | | Label Switching [ICMP-Ext] | | > +-----------+--------------------------------------+----------+ > |MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 | > |OAM | [MPLS-TP-OAM] | | > | +--------------------------------------+----------+ > | | MPLS Generic Associated Channel | RFC 5586 | > | | [G-ACh] | | > | +--------------------------------------+----------+ > | | MPLS-TP OAM Framework | RFC 6371 | > | | [TP-OAM-FW] | | > | +--------------------------------------+----------+ > | | Proactive Connectivity Verification, | RFC 6428 | > | | Continuity Check, and Remote Defect | | > | | Indication for the MPLS Transport | | > | | Profile [TP-CC-CV] | | > | +--------------------------------------+----------+ > | | MPLS On-Demand Connectivity | RFC 6426 | > | | Verification and Route Tracing | | > | | [OnDemand-CV] | | > | +--------------------------------------+----------+ > | | MPLS Fault Management Operations, | RFC 6427 | > | | Administration, and Maintenance (OAM)| | > | | [TP-Fault] | | > | +--------------------------------------+----------+ > | | MPLS Transport Profile Lock Instruct | RFC 6435 | > > > Mizrahi, et al. Expires April 21, 2014 [Page 42] > > Internet-Draft Overview of OAM Tools October 2013 > > > | | and Loopback Functions [Lock-Loop] | | > | +--------------------------------------+----------+ > | | Packet Loss and Delay Measurement for| RFC 6374 | > | | MPLS Networks [MPLS-LM-DM] | | > | +--------------------------------------+----------+ > | | A Packet Loss and Delay Measurement | RFC 6375 | > | | Profile for MPLS-Based Transport | | > | | Networks [TP-LM-DM] | | > +-----------+--------------------------------------+----------+ > |Pseudowire | Pseudowire Virtual Circuit | RFC 5085 | > |OAM | Connectivity Verification (VCCV): | | > | | A Control Channel for Pseudowires | | > | | [VCCV] | | > | +--------------------------------------+----------+ > | | Bidirectional Forwarding Detection | RFC 5885 | > | | for the Pseudowire Virtual Circuit | | > | | Connectivity Verification (VCCV) | | > | | [BFD-VCCV] | | > | +--------------------------------------+----------+ > | | Using the Generic Associated Channel | RFC 6423 | > | | Label for Pseudowire in the MPLS | | > | | Transport Profile (MPLS-TP) | | > | | [PW-G-ACh] | | > | +--------------------------------------+----------+ > | | Pseudowire (PW) Operations, | RFC 6310 | > | | Administration, and Maintenance (OAM)| | > | | Message Mapping [PW-Map] | | > +-----------+--------------------------------------+----------+ > |OWAMP and | A One-way Active Measurement Protocol| RFC 4656 | > |TWAMP | [OWAMP] | | > | +--------------------------------------+----------+ > | | A Two-Way Active Measurement Protocol| RFC 5357 | > | | [TWAMP] | | > | +--------------------------------------+----------+ > | | Framework for IP Performance Metrics | RFC 2330 | > | | [IPPM-FW] | | > | +--------------------------------------+----------+ > | | IPPM Metrics for Measuring | RFC 2678 | > | | Connectivity [IPPM-Con] | | > | +--------------------------------------+----------+ > | | A One-way Delay Metric for IPPM | RFC 2679 | > > > Mizrahi, et al. Expires April 21, 2014 [Page 43] > > Internet-Draft Overview of OAM Tools October 2013 > > > | | [IPPM-1DM] | | > | +--------------------------------------+----------+ > | | A One-way Packet Loss Metric for IPPM| RFC 2680 | > | | [IPPM-1LM] | | > | +--------------------------------------+----------+ > | | A Round-trip Delay Metric for IPPM | RFC 2681 | > | | [IPPM-2DM] | | > | +--------------------------------------+----------+ > | | Packet Reordering Metrics | RFC 4737 | > | | [Reorder] | | > | +--------------------------------------+----------+ > | | A One-Way Packet Duplication Metric | RFC 5560 | > | | [Dup] | | > +-----------+--------------------------------------+----------+ > |TRILL OAM | Requirements for Operations, | RFC 6905 | > | | Administration, and Maintenance (OAM)| | > | | in Transparent Interconnection of | | > | | Lots of Links (TRILL) | | > +-----------+--------------------------------------+----------+ > Table 5 Summary of IETF OAM Related RFCs > > A.2. List of Selected Non-IETF OAM Documents > > In addition to the OAM tools defined by the IETF, the IEEE and ITU-T > have also defined various OAM tools that focus on Ethernet, and > various other transport network environments. These various tools, > defined by the three standard organizations, are often tightly > coupled, and have had a mutual effect on each other. The ITU-T and > IETF have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711] and > [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to > some extent linked to IETF OAM tools listed above and are mentioned > here only as reference material: > > o OAM tools for Layer 2 have been defined by the ITU-T in > [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802.1Q] . The IEEE > 802.3 standard defines OAM for one-hop Ethernet links > [IEEE802.3ah]. > > o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and > MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. > > It should be noted that these non-IETF documents deal in many cases > with OAM functions below the IP layer (Layer 2, Layer 2.5) and in > > > > Mizrahi, et al. Expires April 21, 2014 [Page 44] > > Internet-Draft Overview of OAM Tools October 2013 > > > some cases operators use a multi-layered OAM approach, which is a > function of the way their networks are designed. > > Table 6 summarizes some of the main OAM standards published by non- > IETF standard organizations. This document focuses on IETF OAM > standards, but these non-IETF standards are referenced in this > document where relevant. > > +-----------+--------------------------------------+---------------+ > | | Title |Standard/Draft | > +-----------+--------------------------------------+---------------+ > |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | > |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | > | +--------------------------------------+---------------+ > | | Assignment of the 'OAM Alert Label' | RFC 3429 | > | | for Multiprotocol Label Switching | | > | | Architecture (MPLS) Operation and | | > | | Maintenance (OAM) Functions | | > | | [OAM-Label] | | > | | | | > | | Note: although this is an IETF | | > | | document, it is listed as one of the| | > | | non-IETF OAM standards, since it | | > | | was defined as a complementary part | | > | | of ITU-T Y.1711. | | > +-----------+--------------------------------------+---------------+ > |ITU-T | Operations, administration and |ITU-T G.8113.2 | > |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | > | | networks using the tools defined for | | > | | MPLS [ITU-G8113.2] | | > | | | | > | | Note: this document describes the | | > | | OAM toolset defined by the IETF for | | > | | MPLS-TP, whereas ITU-T G.8113.1 | | > | | describes the OAM toolset defined | | > | | by the ITU-T. | | > | +--------------------------------------+---------------+ > | | Operations, Administration and |ITU-T G.8113.1 | > | | Maintenance mechanism for MPLS-TP in | | > | | Packet Transport Network (PTN) | | > | +--------------------------------------+---------------+ > | | Allocation of a Generic Associated | RFC 6671 | > > > Mizrahi, et al. Expires April 21, 2014 [Page 45] > > Internet-Draft Overview of OAM Tools October 2013 > > > | | Channel Type for ITU-T MPLS Transport| | > | | Profile Operation, Maintenance, and | | > | | Administration (MPLS-TP OAM) | | > | | [ITU-T-CT] | | > | | | | > | | Note: although this is an IETF | | > | | document, it is listed as one of the| | > | | non-IETF OAM standards, since it | | > | | was defined as a complementary part | | > | | of ITU-T G.8113.1. | | > +-----------+--------------------------------------+---------------+ > |ITU-T | OAM Functions and Mechanisms for | ITU-T Y.1731 | > |Ethernet | Ethernet-based Networks | | > |OAM | [ITU-T-Y1731] | | > +-----------+--------------------------------------+---------------+ > |IEEE | Connectivity Fault Management | IEEE 802.1ag | > |CFM | [IEEE802.1Q] | | > | | | | > | | Note: CFM was originally published | | > | | as IEEE 802.1ag, but is now | | > | | incorporated in the 802.1Q standard.| | > +-----------+--------------------------------------+---------------+ > |IEEE | Management of Data Driven and Data | IEEE 802.1ag | > |DDCFM | Dependent Connectivity Faults | | > | | [IEEE802.1Q] | | > | | | | > | | Note: DDCFM was originally published| | > | | as IEEE 802.1Qaw, but is now | | > | | incorporated in the 802.1Q standard.| | > +-----------+--------------------------------------+---------------+ > |IEEE | Media Access Control Parameters, | IEEE 802.3ah | > |802.3 | Physical Layers, and Management | | > |link level | Parameters for Subscriber Access | | > |OAM | Networks [IEEE802.3ah] | | > | | | | > | | Note: link level OAM was originally | | > | | defined in IEEE 802.3ah, and is now | | > | | incorporated in the 802.3 standard. | | > +-----------+--------------------------------------+---------------+ > Table 6 Non-IETF OAM Standards Mentioned in this Document > > > > Mizrahi, et al. Expires April 21, 2014 [Page 46] > > Internet-Draft Overview of OAM Tools October 2013 > > > > > Authors' Addresses > > Tal Mizrahi > Marvell > 6 Hamada St. > Yokneam, 20692 > Israel > > Email: talmi@marvell.com > > > Nurit Sprecher > Nokia Siemens Networks > 3 Hanagar St. Neve Ne'eman B > Hod Hasharon, 45241 > Israel > > Email: nurit.sprecher@nsn.com > > > Elisa Bellagamba > Ericsson > 6 Farogatan St. > Stockholm, 164 40 > Sweden > > Phone: +46 761440785 > Email: elisa.bellagamba@ericsson.com > > > Yaacov Weingarten > 34 Hagefen St. > Karnei Shomron, 4485500 > Israel > > Email: wyaacov@gmail.com > > > > > > > > > > > Mizrahi, et al. Expires April 21, 2014 [Page 47] > > > > > On 17/10/2013 22:46, Tal Mizrahi wrote: >> >> Hi Benoit, Stewart, >> >> Thanks foryour effort to review the draft and for the comments you >> sent.We highly appreciate it, and it has helped to significantly >> improve the document. >> >> We believe we resolved the most significant issue, which is to >> accurately and clearly define the scope and target audience, and to >> align the scope description to the actual content of the document. >> >> The main purpose of this mail is to make sure we resolvedyour >> comments before we re-submit the draft and proceed with the request >> for feedback from the OPSA WG and the routing area WG. >> >> Here is a list of modifications we made following your comments: >> >> 1.The most significant comment, from both Stewart and Benoit was >> about aligning expectations between the content of the document and >> the goal, target audience, and scope: >> We clarified the **scope** and the **target audience** in the >> abstract and at the very beginning of the Introduction. >> Scope: about 2 years ago we had a lot of discussions about the scope >> of the document, and based on Ron Bonica's advice we defined the >> current scope. Mainly, as Ron said, we had to draw the line >> **somewhere** and no matter where we drew the line someone would have >> objections. One of the things we decided then, based on feedback from >> Stewart/Sasha was to removed descriptions of ITU-T and IEEE OAM >> protocols. >> I agree with both your comments that the scope was not crystal clear >> so far, and thus we have clarified the scope in the current draft: >> >> -The draft does not include **all** OAM activity in the IETF, but >> only IP unicast, MPLS, pseudowires, MPLS-TP, and TRILL. >> >> -Focus on data-plane. >> >> 2.Following a comment from Stewart: we added a subsection about >> connection oriented vs. connectionless technologies, and point to >> point vs point to multipoint. >> >> 3.Following a comment from Stewart, Benoit: We clarified the text >> that explains the scope of OAM (in the introduction) based on RFC 6291. >> >> 4.Following a comment from Benoit: We added an explicit quote of the >> OAM definition from RFC 6291. >> >> 5.Following a comment from Stewart, Benoit: We changed the >> definitions of control plane and data plane with Stewart's help. >> >> 6.Following a comment from Stewart: we changed the definitions of OAM >> functions and OAM tools. >> Another comment from Stewart was that the terms 'tool' and >> 'mechanism' were used interchangeably in an inaccurate way. We >> replaced all the potentially confusing instances of 'mechanism' by >> 'tool'. >> >> 7.Following a comment from Benoit: you have commented about the term >> 'transport technology'. We completely removed this term from the >> document. >> >> We are sending a word document with tracked changes compared to the >> draft we sent you on the 17^th of September. >> >> We plan to submit an updated draft before the 21^st of October deadline. >> >> We will highly appreciate your comments. >> >> Thanks, >> >> Tal. >> >> *From:*Benoit Claise [mailto:bclaise@cisco.com] >> *Sent:* Tuesday, October 08, 2013 4:46 PM >> *To:* draft-ietf-opsawg-oam-overview@tools.ietf.org; Scott O. >> Bradner; opsawg-chairs@tools.ietf.org; Joel jaeggli >> *Cc:* Stewart Bryant; Adrian Farrel; me >> *Subject:* draft-ietf-opsawg-oam-overview status >> >> Dear all, >> >> Tal asked me to discuss the draft-ietf-opsawg-oam-overview draft status. >> >> For the sake of transparency, let me share my message with everybody. >> I copied the document authors, Scott Bradner as the document >> shepherd, the OPSAWG-chairs, and the routing ADs (Stewart and Adrian) >> >> Stewart, as the last DISCUSS holder (btw 2011) and Tal had a conf. call >> Five or six minor issues >> Two major issues: >> 1. Huge task, large scope going over all IETF protocols >> 2. Must speak with your responsible AD >> >> I sent back this document to the WG. See >> http://www.ietf.org/mail-archive/web/opsawg/current/msg02931.html >> >> Tal and I discussed: >> - The comparison with RFC6632, which is a overview with claear >> objectives and target audience >> The OAM document is somehow the companion document to RFC 6632 >> >> - This document has got a bigger task that the authors apparently >> thought it would be >> >> - The document goal and audience are not clearly defined (actually >> it's spread all over the place) >> Who will want to be reading this document? What for? >> >> Section 1 Introduction: >> This document summarizes the OAM tools and mechanisms defined in the >> IETF. This document focuses on data plane OAM tools. Hence, control >> and management aspects of OAM are outside the scope of this document. >> >> Section 1.2 Target Audience is key >> Section 1.3 OAM-related Work in the IETF >> >> This memo provides an overview of the different sets of OAM >> mechanisms defined by the IETF. The set of OAM mechanisms described >> in this memo are applicable to IP unicast, MPLS, pseudowires, MPLS >> for the transport profile (MPLS-TP), and TRILL. While OAM mechanisms >> that are applicable to other technologies exist, they are beyond the >> scope of this memo. >> >> Why not others? >> Section 1.4 Focusing on Data Plane OAM Tools >> >> The considerations of the control plane maintenance tools and the >> functionality of the management plane are out of scope for this >> document, which concentrates on presenting the data plane tools that >> are used for OAM. >> >> You see, it's not clear from the beginning (the abstract) what the >> focus is, who is the audience, and what the document goals are: there >> are pieces of it all over the place. >> >> The overview of all OAM protocols in the IETF is a moving target. >> You need a lot of energy to finish this document, and you must be >> quick (moving target) >> >> - Do you want to classify the different OAM techniques as we did for >> RFC 6632, based on different criteria s? We had a clear audience in >> mind when creating RFC 6632. For example, if you look which >> protocol(s) might be of interest to you, see >> >> A.1 . Protocols Classified by Standards Maturity in the IETF .....77 >> A.2 . Protocols Matched to Management Tasks ......................79 >> A.3 . Push versus Pull Mechanism .................................80 >> A.4 . Passive versus Active Monitoring ...........................80 >> A.5 . Supported Data Model Types and Their Extensibility ........81 >> >> >> >> - The advice is to present during the OPSAWG to get some feedback >> regarding the direction (focus, document goal, and target audience) >> for this document: reduce scope versus cover all the OAM features in >> the IETF? >> Also, the same talk should be done at the Routing Area (Stewart >> agreed to find some time for it). Actually, the feedback from the >> routing guys is even more important, as they are the guys specifying >> OAM techniques. So they will be the readers for this document (I guess) >> >> >> SOME MORE FEEDBACK >> >> >> +--------------+------------+ >> | Category | Transport | >> | | Technology | >> +--------------+------------+ >> |IP Ping | IPv4/IPv6 | >> +--------------+------------+ >> |IP Traceroute | IPv4/IPv6 | >> +--------------+------------+ >> |BFD | generic | >> +--------------+------------+ >> |MPLS OAM | MPLS | >> +--------------+------------+ >> |MPLS-TP OAM | MPLS-TP | >> +--------------+------------+ >> |Pseudowire OAM| Pseudowires| >> +--------------+------------+ >> |OWAMP and | IPv4/IPv6 | >> |TWAMP | | >> +--------------+------------+ >> |TRILL OAM | TRILL | >> +--------------+------------+ >> Table 1 Categories of OAM-related IETF Documents >> >> You should define what you mean by transport technology. It's not L4 >> >> - Terminology >> >> It's key to have an OAM definition. >> It's true that you mentioned earlier: >> >> There are several different interpretations to the "OAM" acronym. >> This document refers to Operations, Administration and Maintenance, >> as recommended in [OAM-Def]. >> >> However, cut and paste the definition. >> >> Same remark for some other definitions. For example >> >> Control Plane >> >> The Control Plane, as described in [Cont], is generally described as >> the hardware and software components for handling packets destined to >> the device itself as well as building and sending packets originated >> locally on the device. >> >> If it's a described in [cont], then copy it verbatim >> >> - It's good that a single document contains the definitions of >> control plane, data plane and management plane. >> >> - I stopped my review at the end of section 2 >> >> Regards, Benoit >> >> > > > -- > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > --------------070707050609030101080201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear authors,

As you know, the IESG sent this document back to the WG (see http://www.ietf.org/mail-archive/web/opsawg/current/msg02931.html).
I asked the authors to make sure that the feedback and concerns received so far were addressed. A new version has been posted. Good!

Below is the feedback sent by Stewart Bryant on the new version, forwarded with permission to the WG: Stewart has been involved in OAM for some time now, is the routing AD, and was the DISCUSS holder when the draft was reviewed by the IESG in 2011). Note that the DISCUSS is gone now, since the document is back in the WG.

I've been reviewing the new draft version, this email below, and had two conf. calls with Stewart today. Below is the outcome of our discussion.

The draft improved. For example, I like the fact that the target audience is now in the abstract.
However, one important point brought up by Stewart is: why audience do you target? Is the draft content useful for that audience?
It seems that initially, it was the silicon designer. It's apparently not the case any longer.
You list
   The target audience of this document includes network equipment
   vendors, network operators and standard development organizations,
   and can be used as an index to some of the main data plane OAM tools
   defined in the IETF.
We believe that this draft is not complete enough for the network equipment vendor audience. It needs way more than this overview. Also you focus only on the data plane OAM.
Regarding the network operators, your table in 4.10 might be a good output. However, it's buried into a subsection.
Regarding "an index to some of the main data plane OAM tools defined in the IETF", the table in section 3.9 is buried into a subsection.
Maybe you want to highlight those tables with they own section.

Also, while the abstract and title mention "an index to some of the main data plane OAM tools defined in the IETF" , the data plane adjective really limits the scope of what you're investigating. I only understood its implications way later in the draft. For example that FRR, RDI (remote defect indication), etc. were not included. This should be stressed upfront.

This point points back to Stewart's point: think about your target audience and evaluate if the content is useful for the readers... Note that this is now a WG document, so we must get the OPSAWG community feedback.

Also, Stewart has some good points below: path verification versus peer authentication, multipoint to point, etc.

Regarding the WIKI, I'm actually in favor a collecting this information in a RFC. OAM has been growing over the years, up to a point where I'm not sure what it does NOT contain (FCAPS). So doing a one-time "overview of OAM tools" makes sense to me.

Regards, Benoit


Firstly, I should say I have been reviewing this work from
the point of view of someone who was on point when we designed
the MPLS-TP OAM, where we took object lesson after object lesson
on the scope and purpose of OAM from the ITU-T.

I will say that the project you have embarked on is a very
difficult and challenging one, since this subject has
enormous breath and depth.

In one communication earlier the stated purpose was to provide
an overview from the point of view of a silicon designer. I do
not think you get close to that.

My view is still that you fail to ruthlessly identify the
target audience and the single mindedly deliver to that audience.

The text is far too detailed in places for the broad brush overview
and lacks the rigor needed for a deeper academic introduction.

If your goal is the former, I think you need to split the work
between an RFC and a Wiki, and delete a lot of the detail.

If your goal is the latter, then I think you need to set
up a well defined, intellectually rigerous  framework for OAM,
and then show how well, or how badly the solutions map to it.

If your original goal is to talk about implementation, I would
have expected a lot of discussion on stack depth, queue and
process structure, performance bottlenecks, timestamping etc.
Indeed even in an introduction there needs to be some text on those
aspects of the problem.

Now if I am the only AD that has any concerns about publishing
this text as an RFC, I am prepared to move to abstain and you
can publish this as it is.

However I think that Benoit needs to understand that we have
sufficient real support in the IETF for the text amongst the
various OAM design teams that look after each protocol suite
discussed in the text. If there is not support, perhaps this
should go to the ISE as a personal statement on the subject.

It might be a good idea if Benoit and I discussed this
on the telephone tomorrow.

- Stewart




Abstract

   Operations, Administration, and Maintenance (OAM) is a general term
   that refers to a toolset for fault detection and isolation, and for
   performance measurement.

SB> No In MPLS-TP (which is in scope it does more, it is also a devolved
SB> control plane)

   Over the years various OAM tools have been
   defined for various layers in the protocol stack.

   This document summarizes some of the data plane OAM tools defined in
   the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for
   the transport profile (MPLS-TP), and TRILL.

SB> Since MPLS-TP is a subset of MPLS the ordering of the list is a little curious


   The target audience of this document includes network equipment
   vendors, network operators and standard development organizations,
   and can be used as an index to some of the main data plane OAM tools
   defined in the IETF.

======


1. Introduction

   OAM is a general term that refers to a toolset for detecting,
   isolating and reporting failures and for monitoring the network
   performance.

SB> See earlier comment

   There are several different interpretations to the "OAM" acronym.
   This document refers to Operations, Administration and Maintenance,
   as recommended in Section 3 of [RFC6291].

   This document summarizes some of the data plane OAM tools defined in
   the IETF in the context of IP unicast, MPLS, pseudowires, MPLS for
   the transport profile (MPLS-TP), and TRILL.

SB> See earlier comment

   This document focuses on data plane OAM tools. Hence, control and
   management aspects of OAM are outside the scope of this document.
   This document focuses on tools for detecting and isolating failures
   and for performance monitoring. Network repair functions such as Fast
   Reroute (FRR) and protection switching, which are often triggered by
   OAM protocols, are out of the scope of this document.

SB> You need to be careful with the definition of OAM - In MPLS-TP (which
SB> you define as in scope) these are considered OAM functions.
 
1.1. Background

   OAM was originally used in traditional communication technologies
   such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM
   was probably the first technology to include inherent OAM support
   from day one, while in other technologies OAM was typically defined
   in an ad hoc manner after the technology was already defined and
   deployed. Packet-based networks were traditionally considered
   unreliable and best-effort, but as packet-based networks evolved,
   they have become the common transport for both data and telephony,
   replacing traditional transport protocols. Consequently, packet-based
   networks were expected to provide a similar "carrier grade"
   experience, and specifically to support OAM.

   As typical networks have a multi-layer architecture, the set of OAM
   protocols similarly take a multi-layer structure; each layer has its
   own OAM protocols. Moreover, OAM can be used at different levels of
   hierarchy in the network to form a multi-layer OAM solution, as shown
   in the example in Figure 1.

   Figure 1 illustrates a network in which IP traffic between two
   customer edges is transported over an MPLS provider network. MPLS OAM
   is used at the provider-level for monitoring the connection between
   the two provider edges, while IP OAM is used at the customer-level
   for monitoring the end-to-end connection between the two customer
   edges.








Mizrahi, et al.        Expires April 21, 2014                 [Page 4]
Internet-Draft          Overview of OAM Tools             October 2013


           |<-------------- Customer-level OAM -------------->|
                 IP OAM (Ping, Traceroute, OWAMP, TWAMP)

                        |<- Provider-level OAM ->|
                            MPLS OAM (LSP Ping)

     +-----+       +----+                        +----+       +-----+
     |     |       |    |========================|    |       |     |
     |     |-------|    |          MPLS          |    |-------|     |
     |     |  IP   |    |                        |    |  IP   |     |
     +-----+       +----+                        +----+       +-----+
     Customer     Provider                      Provider      Customer
       Edge         Edge                          Edge          Edge

                     Figure 1 Example: Multi-layer OAM

1.2. Target Audience

   The target audience of this document includes:

   o Standard development organizations - both IETF working groups and
      non-IETF organizations can benefit from this document when
      designing new OAM protocols, or when looking to reuse existing OAM
      tools for new technologies.

SB> Who do you have in mind outside the IETF?
SB> There are a lot of OAM expert groups out there.

   o Network equipment vendors and network operators - can use this
      document as an index to some of the common IETF OAM tools.

   It should be noted that this document is not necessarily suitable for
   beginners without any background in OAM.

1.3. OAM-related Work in the IETF

   This memo provides an overview of the different sets of OAM tools
   defined by the IETF. The set of OAM tools described in this memo are
   applicable to IP unicast, MPLS, pseudowires, MPLS for the transport
   profile (MPLS-TP), and TRILL. While OAM tools that are applicable to
   other technologies exist, they are beyond the scope of this memo.

   This document focuses on IETF documents that have been published as
   RFCs, while other ongoing OAM-related work is outside the scope.

   The IETF has defined OAM protocols and tools in several different
   contexts. We roughly categorize these efforts into a few sets of OAM-
   related RFCs, listed in Table 1. Each category defines a logically-


Mizrahi, et al.        Expires April 21, 2014                 [Page 5]
Internet-Draft          Overview of OAM Tools             October 2013


   coupled set of RFCs, although the sets are in some cases intertwined
   by common tools and protocols.

   The discussion in this document is ordered according to these
   categories.

                     +--------------+------------+
                     | Category     | Transport  |
                     |              | Technology |
                     +--------------+------------+
                     |IP Ping       | IPv4/IPv6  |
                     +--------------+------------+
                     |IP Traceroute | IPv4/IPv6  |
                     +--------------+------------+
                     |BFD           | generic    |
                     +--------------+------------+
                     |MPLS OAM      | MPLS       |
                     +--------------+------------+
                     |MPLS-TP OAM   | MPLS-TP    |
                     +--------------+------------+
                     |Pseudowire OAM| Pseudowires|
                     +--------------+------------+
                     |OWAMP and     | IPv4/IPv6  |
                     |TWAMP         |            |
                     +--------------+------------+
                     |TRILL OAM     | TRILL      |
                     +--------------+------------+
              Table 1 Categories of OAM-related IETF Documents

SB> Categories implies taxonomy, and those are not really
SB> taxonomy classes. Those are really IETF work packages.

1.4. Focusing on Data Plane OAM Tools

   OAM tools may, and quite often do, work in conjunction with a control
   plane and/or management plane.  At the data plane, OAM provides
   instrumentation tools.

SB> That is your definition of the purpose, not for example the
SB> transport world's definition.
SB> You might also consider implicit OAM tools such as router hellos

   OAM tools often use control plane functions,
   e.g., to initialize OAM sessions and to exchange various parameters.
   The OAM tools communicate with the management plane to raise alarms,
   and often OAM tools may be activated by the management (as well as by
   the control plane), e.g. to locate and localize problems.

   The considerations of the control plane maintenance tools and the
   functionality of the management plane are out of scope for this
   document, which concentrates on presenting the data plane tools that
   are used for OAM. Network repair functions such as Fast Reroute (FRR)



Mizrahi, et al.        Expires April 21, 2014                 [Page 6]
Internet-Draft          Overview of OAM Tools             October 2013


   and protection switching, which are often triggered by OAM protocols,
   are also out of the scope of this document.

SB> I don't mind what you call your function, but this exclusion
SB> will not class the functionality as OAM within the shared IETF-ITU
SB> definition of OAM in the transport technology space.

   Since OAM protocols are used for monitoring the data plane, it is
   imperative for OAM tools to be capable of testing the actual data
   plane in as much accuracy as possible. Thus, it is important to
   enforce fate-sharing between OAM traffic that monitors the data plane
   and the data plane traffic it monitors.

2. Terminology

2.1. Abbreviations

   ACH    Associated Channel Header

   AIS    Alarm Indication Signal

   ATM    Asynchronous Transfer Mode

   BFD    Bidirectional Forwarding Detection

   CC     Continuity Check

   CV     Connectivity Verification

   DM     Delay Measurement

   ECMP   Equal Cost Multiple Paths

   FEC    Forwarding Equivalence Class

   FRR    Fast Reroute

   G-ACh   Generic Associated Channel

   GAL    Generic Associated Label

   ICMP   Internet Control Message Protocol

   L2TP   Layer Two Tunneling Protocol

   LCCE   L2TP Control Connection Endpoint

   LDP    Label Distribution Protocol

   LER    Label Edge Router



Mizrahi, et al.        Expires April 21, 2014                 [Page 7]
Internet-Draft          Overview of OAM Tools             October 2013


   LM     Loss Measurement

   LSP    Label Switched Path

   LSR    Label Switched Router

   ME     Maintenance Entity

   MEG    Maintenance Entity Group

   MEP    MEG End Point

   MIP    MEG Intermediate Point

   MP     Maintenance Point

   MPLS   Multiprotocol Label Switching

   MPLS-TP MPLS Transport Profile

   MTU    Maximum Transmission Unit

   OAM    Operations, Administration, and Maintenance

   PDH    Plesiochronous Digital Hierarchy

   PE     Provider Edge

   PW     Pseudowire

   PWE3   Pseudowire Emulation Edge-to-Edge

   RBridge Routing Bridge

   RDI    Remote Defect Indication

   SDH    Synchronous Digital Hierarchy

   SONET   Synchronous Optical Networking

   TRILL   Transparent Interconnection of Lots of Links

   TTL    Time To Live

   VCCV   Virtual Circuit Connectivity Verification




Mizrahi, et al.        Expires April 21, 2014                 [Page 8]
Internet-Draft          Overview of OAM Tools             October 2013


2.2. Terminology used in OAM Standards

2.2.1. General Terms

   A wide variety of terms is used in various OAM standards. This
   section presents a comparison of the terms used in various OAM
   standards, without fully quoting the definition of each term.

   An interesting overview of the term OAM and its derivatives is
   presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms
   is presented in [TP-Term], and provides a good summary of some of the
   OAM related terminology.

2.2.2. Operations, Administration and Maintenance

   The following definition of OAM is quoted from [OAM-Def]:

   The components of the "OAM" acronym (and provisioning) are defined as
   follows:

   o Operations - Operation activities are undertaken to keep the
      network (and the services that the network provides) up and
      running.  It includes monitoring the network and finding problems.
      Ideally these problems should be found before users are affected.

   o Administration - Administration activities involve keeping track
      of resources in the network and how they are used.  It includes
      all the bookkeeping that is necessary to track networking
      resources and the network under control.

   o Maintenance - Maintenance activities are focused on facilitating
      repairs and upgrades -- for example, when equipment must be
      replaced, when a router needs a patch for an operating system
      image, or when a new switch is added to a network.  Maintenance
      also involves corrective and preventive measures to make the
      managed network run more effectively, e.g., adjusting device
      configuration and parameters.

SB> I think that the class of OAM that you explain is actually
SB> M == Measurement. Maint implies maint of service which includes
SB> protection switching which you have put out of scope.

2.2.3. Functions, Tools and Protocols

OAM Function



   An OAM function is an instrumentation measurement type or diagnostic.




Mizrahi, et al.        Expires April 21, 2014                 [Page 9]
Internet-Draft          Overview of OAM Tools             October 2013


   OAM functions are the atomic building blocks of OAM, where each
   function defines an OAM capability.

   Typical examples of OAM functions are presented in Section 3.

OAM Protocol

   A protocol used for implementing one or more OAM functions.

   The OWAMP-Test [OWAMP] is an example of an OAM protocol.

SB> Isn't your definition DP measurements? I am struggling to
SB> work out if OWAMP is a DP measurement, or a synthetic
SB> Transport measurement.
SB> I think that OWAMP is UDP isn't it, so is really measuring
SB> what the system does to UDP packets.

OAM Tool

   An OAM tool is a specific means of applying one or more OAM
   functions.

   In some cases an OAM protocol *is* an OAM tool, e.g., OWAMP-Test. In
   other cases an OAM tool uses a set of protocols that are not strictly
   OAM-related; for example, Traceroute (Section 4.2.) can be
   implemented using UDP and ICMP messages, without using an OAM
   protocol per se.

2.2.4. Data Plane, Control Plane and Management Plane

Data Plane

   The data plane is the set of functions used to transfer data in the
   stratum or layer under consideration [ITU-Terms].

   .

   The Data Plane is also known as the Forwarding Plane or the User
   Plane.

SB> I am not sure that is quite right.

Control Plane

   The control plane is the set of protocols and mechanisms that enable
   routers to efficiently learn how to forward packets towards their
   final destination (based on [Comp]).

SB> Er no. The routers may not learn in the classic sense of learn.
SB> they may be told by the CP.


Management Plane

   The term Management Plane, as described in [Mng], is used to describe
   the exchange of management messages through management protocols
   (often transported by IP and by IP transport protocols) between
   management applications and the managed entities such as network
   nodes.


Mizrahi, et al.        Expires April 21, 2014                [Page 10]
Internet-Draft          Overview of OAM Tools             October 2013


Data Plane vs. Control Plane vs. Management Plane

   The distinction between the planes is at times a bit vague. For
   example, the definition of "Control Plane" above may imply that OAM
   tools such as ping, BFD and others are in fact in the control plane.

   This document focuses on data plane OAM tools, i.e., tools used for
   monitoring the data plane. While these tools could arguably be
   considered to be in the control plane, these tools monitor the data
   plane, and hence it is imperative to have fate-sharing between OAM
   traffic that monitors the data plane and the data plane traffic it
   monitors.

   Another potentially vague distinction is between the management plane
   and control plane. The management plane should be seen as separate
   from, but possibly overlapping with, the control plane (based on
   [Mng]).

2.2.5. The Players

   An OAM tool is used between two (or more) "players". Various terms
   are used in IETF documents to refer to the players that take part in
   OAM. Table 2 summarizes the terms used in each of the categories
   discussed in this document.

          +--------------------------+--------------------------+
          | Category                 | Terms                    |
          +--------------------------+--------------------------+
          | Ping / Traceroute        |-Host                     |
          | ([ICMPv4], [ICMPv6],     |-Node                     |
          |  [TCPIP-Tools])          |-Interface                |
          |                          |-Gateway                  |
          + ------------------------ + ------------------------ +
          | BFD [BFD]                | System                   |
          + ------------------------ + ------------------------ +
          | MPLS OAM [MPLS-OAM-FW]   | LSR                      |
          + ------------------------ + ------------------------ +
          | MPLS-TP OAM [TP-OAM-FW]  |-End Point - MEP          |
          |                          |-Intermediate Point - MIP |
          + ------------------------ + ------------------------ +
          | Pseudowire OAM [VCCV]    |-PE                       |
          |                          |-LCCE                     |
          + ------------------------ + ------------------------ +
          | OWAMP and TWAMP          |-Host                     |


Mizrahi, et al.        Expires April 21, 2014                [Page 11]
Internet-Draft          Overview of OAM Tools             October 2013


          | ([OWAMP], [TWAMP])       |-End system               |
          + ------------------------ + ------------------------ +
          | TRILL OAM [TRILL-OAM]    |-RBridge                  |
          +--------------------------+--------------------------+
                   Table 2 Maintenance Point Terminology

SB> Shouldn't you start with a rigorous definition and then show
SB> how the less rigorous terms map to it?

2.2.6. Proactive and On-demand Activation

   The different OAM tools may be used in one of two basic types of
   activation:

Proactive

   Proactive activation - indicates that the tool is activated on a
   continual basis, where messages are sent periodically, and errors are
   detected when a certain number of expected messages are not received.

On-demand

   On-demand activation - indicates that the tool is activated
   "manually" to detect a specific anomaly.

2.2.7. Connectivity Verification and Continuity Checks

   Two distinct classes of failure management functions are used in OAM
   protocols, connectivity verification and continuity checks. The
   distinction between these terms is defined in [MPLS-TP-OAM], and is
   used similarly in this document.

Continuity Check

   Continuity checks are used to verify that a destination is reachable,
   and are typically sent proactively, though they can be invoked on-
   demand as well.

Connectivity Verification

SB> CV is surely about verifying that Bob is Bob?
SB> What you are about to describe is path verification.

   A connectivity verification function allows Alice to check whether
   she is connected to Bob or not. This function also allows Alice to
   verify that messages from Bob are received through the correct path,
   thereby verifying not only that the two MPs are connected, but also
   that they are connected through the expected path, allowing detection
   of unexpected topology changes. It is noted that while the CV
   function is performed in the data plane, the "expected path" is


Mizrahi, et al.        Expires April 21, 2014                [Page 12]
Internet-Draft          Overview of OAM Tools             October 2013


   predetermined either in the control plane or in the management plane.
   A connectivity verification (CV) protocol typically uses a CV
   message, followed by a CV reply that is sent back to the originator.
   A CV function can be applied proactively or on-demand.

   Connectivity verification and continuity checks are considered
   complementary mechanisms, and are often used in conjunction with each
   other.

2.2.8. Connection Oriented vs. Connectionless Communication

Connection Oriented

   In Connection Oriented technologies an end-to-end connection is
   established (by a control protocol or provisioned by a management
   system) prior to the transmission of data.

   Typically a connection identifier is used to identify the connection.
   In connection oriented technologies it is often the case (although
   not always) that all packets belonging to a specific connection use
   the same route through the network.

Connectionless

   In Connectionless technologies data is typically sent between end
   points without prior arrangement. Packets are routed independently
   based on their destination address, and hence different packets may
   be routed in a different way across the network.

Discussion

   The OAM tools described in this document include tools that support
   connection oriented technologies, as well as tools for connectionless
   technologies.

   In connection oriented technologies OAM is used to monitor a
   *specific* connection; OAM packets are forwarded through the same
   route as the data traffic and receive the same treatment. In
   connectionless technologies, OAM is used between a source and
   destination pair without defining a specific connection. Moreover, in
   some cases the route of OAM packets may differ from the one of the
   data traffic. For example, the connectionless IP Ping (Section 4.1.)
   tests the reachability from a source to a given destination, while
   the connection oriented LSP Ping (Section 4.4.) is used for
   monitoring a specific LSP (connection), and provides the capability
   to monitor all the available paths used by an LSP.



Mizrahi, et al.        Expires April 21, 2014                [Page 13]
Internet-Draft          Overview of OAM Tools             October 2013


   It should be noted that in some cases connectionless protocols are
   monitored by connection oriented OAM protocols. For example, while IP
   is a connectionless protocol, it can monitored by BFD (Section 4.3.
   ), which is connection oriented.

2.2.9. Point-to-point vs. Point-to-multipoint Services

Point-to-point (P2P)

   A P2P service delivers data from a single source to a single
   destination.

Point-to-multipoint (P2MP)

   An P2MP service delivers data from a single source to a one or more
   destinations (based on [Signal]).

   [Signal] also defines a MP2MP service as a service that delivers data
   from more than one source to one or more receivers.

SB> MP2P is a very interesting and important class - it is what
SB> a VPN service (such as RFC2547) looks like, and has some interesting
SB> instrumentation problems.

Discussion

   The OAM tools described in this document include tools for P2P
   services, as well as tools for P2MP services.

   The distinction between P2P services and P2MP services affects the
   corresponding OAM tools. A P2P service is typically simpler to
   monitor, as it consists of a single pair of end points. P2MP services
   present several challenges. For example, in a P2MP service, the OAM
   mechanism not only verifies that each of the destinations is
   reachable from the source, but also verifies that the P2MP
   distribution tree is intact and loop-free. Another challenge in P2MP
   services is performance monitoring; while in P2P packet loss is
   measured by maintaining packet counters at the two end-points, in
   P2MP packet loss must be carefully measured by generating synthetic
   traffic to each corresponding end-point and maintaining a separate
   counter for each peer end-point.

SB> Incorrect. You can monitor live traffic. Think counting I-frames
SB> as but one example.

2.2.10. Failures

   The terms Failure, Fault, and Defect are used interchangeably in the
   standards, referring to a malfunction that can be detected by a
   connectivity or a continuity check. In some standards, such as
   802.1ag [IEEE802.1Q] , there is no distinction between these terms,
   while in other standards each of these terms refers to a different
   type of malfunction.



Mizrahi, et al.        Expires April 21, 2014                [Page 14]
Internet-Draft          Overview of OAM Tools             October 2013


   The terminology used in IETF MPLS-TP OAM is based on the ITU-T
   terminology, which distinguishes between these three terms in
   [ITU-T-G.806];

Fault

   The term Fault refers to an inability to perform a required action,
   e.g., an unsuccessful attempt to deliver a packet.

Defect

   The term Defect refers to an interruption in the normal operation,
   such as a consecutive period of time where no packets are delivered
   successfully.

Failure

   The term Failure refers to the termination of the required function.
   While a Defect typically refers to a limited period of time, a
   failure refers to a long period of time.

3. OAM Functions

   This subsection provides a brief summary of the common OAM functions
   used in OAM-related standards. These functions are used as building
   blocks in the OAM standards described in this document.

   o Connectivity Verification (CV) and/or Continuity Checks (CC):
      As defined in Section 2.2.7.

   o Path Discovery / Fault Localization:
      This function can be used to trace the route to a destination,
      i.e., to identify the nodes along the route to the destination.
      When more than one route is available to a specific destination,
      this function traces one of the available routes. When a failure
      occurs, this function also allows to detect the location of the
      failure.
      Note that the term route tracing (or Traceroute) that is used in
      the context of IP and MPLS, is sometimes referred to as path
      tracing in the context of other protocols, such as TRILL.

SB> What about path verification?

   o Performance Monitoring:
      Typically refers to:

        o Loss Measurement (LM) - monitors the packet loss rate.




Mizrahi, et al.        Expires April 21, 2014                [Page 15]
Internet-Draft          Overview of OAM Tools             October 2013


        o Delay Measurement (DM) - monitors the delay and delay
          variation.

4. OAM Tools in the IETF - a Detailed Description

   This section presents a detailed description of the sets of OAM-
   related tools in each of the categories in Table 1.

4.1. IP Ping

   Ping is a common network diagnosis application for IP networks that
   uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for
   Packet internet groper, although the term has been so commonly used
   that it stands on its own.

SB> I bet the true origin of the name lies with SONAR, and the rest
SB> is post-hoc justification

   As defined in [NetTerms], it is a program
   used to test reachability of destinations by sending them an ICMP
   echo request and waiting for a reply.

   The ICMP Echo request/reply exchange in Ping is used as a continuity
   check function for the Internet Protocol. The originator transmits an
   ICMP Echo request packet, and the receiver replies with an Echo
   reply. ICMP ping is defined in two variants, [ICMPv4] is used for
   IPv4, and [ICMPv6] is used for IPv6.

   Ping implementations typically use ICMP messages. UDP Ping is a
   variant that uses UDP messages instead of ICMP echo messages.

   Ping is a single-ended continuity check, i.e., it allows the
   *initiator* of the Echo request to test the reachability. If it is
   desirable for both ends to test the reachability, both ends have to
   invoke Ping independently.

   Note that since ICMP filtering is deployed in some routers and
   firewalls, the usefulness of Ping is sometimes limited in the wider
   internet. This limitation is equally relevant to Traceroute.

4.2. IP Traceroute

   Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows
   users to discover a path between an IP source and an IP destination.

   The most common way to implement Traceroute [TCPIP-Tools] is
   described as follows. Traceroute sends a sequence of UDP packets to
   UDP port 33434 at the destination. By default, Traceroute begins by
   sending three packets (the number of packets is configurable in most
   Traceroute implementations), each with an IP Time-To-Live (or Hop
   Limit in IPv6) value of one to the destination. These packets expire
   as soon as they reach the first router in the path. Consequently,


Mizrahi, et al.        Expires April 21, 2014                [Page 16]
Internet-Draft          Overview of OAM Tools             October 2013


   that router sends three ICMP Time Exceeded Messages back to the
   Traceroute application. Traceroute now sends another three UDP
   packets, each with the TTL value of 2. These messages cause the
   second router to return ICMP messages. This process continues, with
   ever increasing values for the TTL field, until the packets actually
   reach the destination. Because no application listens to port 33434
   at the destination, the destination returns ICMP Destination
   Unreachable Messages indicating an unreachable port. This event
   indicates to the Traceroute application that it is finished.  The
   Traceroute program displays the round-trip delay associated with each
   of the attempts.

   While Traceroute is a tool that finds *a* path from A to B, it should
   be noted that traffic from A to B is often forwarded through Equal
   Cost Multiple Paths (ECMP). Paris Traceroute [Paris] is an extension
   to Traceroute that attempts to discovers all the available paths from
   A to B by scanning different values of header fields (such as UDP
   ports) in the probe packets.

   It is noted that Traceroute is an application, and not a protocol. As
   such, it has various different implementations. One of the most
   common ones uses UDP probe packets, as described above. Other
   implementations exist that use other types of probe messages, such as
   ICMP or TCP.

   Note that IP routing may be asymmetric. While Traceroute discovers a
   path between a source and destination, it does not reveal the reverse
   path.

   A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in
   the context of Traceroute. These documents define several extensions,
   including extensions to the ICMP Destination Unreachable message,
   that can be used by Traceroute applications.

4.3. Bidirectional Forwarding Detection (BFD)

4.3.1. Overview

   While multiple OAM tools have been defined for various protocols in
   the protocol stack, Bidirectional Forwarding Detection [BFD], defined
   by the IETF BFD working group, is a generic OAM tool that can be
   deployed over various encapsulating protocols, and in various medium
   types. The IETF has defined variants of the protocol for IP ([BFD-
   IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD-
   VCCV]. The usage of BFD in MPLS-TP is defined in [TP-CC-CV].




Mizrahi, et al.        Expires April 21, 2014                [Page 17]
Internet-Draft          Overview of OAM Tools             October 2013


   BFD includes two main OAM functions, using two types of BFD packets:
   BFD Control packets, and BFD Echo packets.

4.3.2. Terminology

   BFD operates between two *systems*. The BFD protocol is run between
   two systems after establishing a *session*.

SB> Isn't there a P2MP BFD?

4.3.3. BFD Control

   BFD supports a bidirectional continuity check, using BFD control
   packets, that are exchanged within a BFD session. BFD sessions
   operate in one of two modes:

   o Asynchronous mode (i.e. proactive): in this mode BFD control
      packets are sent periodically. When the receiver detects that no
      BFD control packets have been received during a predetermined
      period of time, a failure is detected.

   o Demand mode: in this mode, BFD control packets are sent on-demand.
      Upon need, a system initiates a series of BFD control packets to
      check the continuity of the session. BFD control packets are sent
      independently in each direction.

   Each of the end-points (referred to as systems) of the monitored path
   maintains its own session identification, called a Discriminator,
   both of which are included in the BFD Control Packets that are
   exchanged between the end-points.  At the time of session
   establishment, the Discriminators are exchanged between the two-end
   points.  In addition, the transmission (and reception) rate is
   negotiated between the two end-points, based on information included
   in the control packets.  These transmission rates may be renegotiated
   during the session.

   During normal operation of the session, i.e. no failures are
   detected, the BFD session is in the Up state.  If no BFD Control
   packets are received during a period of time called the Detection
   Time, the session is declared to be Down. The detection time is a
   function of the pre-configured or negotiated transmission time, and a
   parameter called Detect Mult. Detect Mult determines the number of
   missing BFD Control packets that cause the session to be declared as
   Down. This parameter is included in the BFD Control packet.

4.3.4. BFD Echo

   A BFD echo packet is sent to a peer system, and is looped back to the
   originator. The echo function can be used proactively, or on-demand.


Mizrahi, et al.        Expires April 21, 2014                [Page 18]
Internet-Draft          Overview of OAM Tools             October 2013


   The BFD echo function has been defined in BFD for IPv4 and IPv6
   ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for
   MPLS-TP.

4.4. MPLS OAM

   The IETF MPLS working group has defined OAM for MPLS LSPs. The
   requirements and framework of this effort are defined in
   [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM
   tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for P2MP
   services is defined in [MPLS-P2MP].

   LSP Ping is modeled after the Ping/Traceroute paradigm and thus it
   may be used in one of two modes:

   o "Ping" mode: In this mode LSP Ping is used for end-to-end
      connectivity verification between two LERs.

   o "Traceroute" mode: This mode is used for hop-by-hop fault
      isolation.

   LSP Ping extends the basic ICMP Ping operation (of data-plane
   connectivity verification) with functionality to verify data-plane
   vs. control-plane consistency for a Forwarding Equivalence Class
   (FEC) and also Maximum Transmission Unit (MTU) problems.

   The challenge in MPLS networks is that the traffic of a given LSP may
   be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping
   monitors all the available paths of an LSP by monitoring its
   different Forwarding Equivalence Classes (FEC).
SB> That is one challange, the real problem is that the labels
SB> are opaque at a mid-point and that the payload is not
SB> known at that point either. Also you do not have an automatic
SB> return path path other than MPLS-TP. It's not like IP where
SB> you can reverse the SA and DA into DA and SA.

   Conversely, MPLS-TP
   does not use ECMP, and thus does not require OAM over multiple paths.
   The Traceroute functionality may be used to isolate and localize the
   MPLS faults, using the Time-to-live (TTL) indicator to incrementally
   identify the sub-path of the LSP that is successfully traversed
   before the faulty link or node.

SB> Can't yo also do this in regular MPLS

   It should be noted that LSP Ping supports unique identification of
   the LSP within an addressing domain. The identification is checked
   using the full FEC identification. LSP Ping is easily extensible to
   include additional information needed to support new functionality,
   by use of Type-Length-Value (TLV) constructs. The usage of TLVs is
   typically not easy to perform in hardware, and is thus typically
   handled by the control plane.

   LSP Ping supports both asynchronous, as well as, on-demand
   activation.


SB> You should get George Swallow to take a look at 4.4

Mizrahi, et al.        Expires April 21, 2014                [Page 19]
Internet-Draft          Overview of OAM Tools             October 2013


4.5. MPLS-TP OAM

4.5.1. Overview

   The MPLS working group has defined the OAM toolset that fulfills the
   requirements for MPLS-TP OAM. The full set of requirements for MPLS-
   TP OAM are defined in [MPLS-TP-OAM], and include both general
   requirements for the behavior of the OAM tools and a set of
   operations that should be supported by the OAM toolset.  The set of
   mechanisms required are further elaborated in [TP-OAM-FW], which
   describes the general architecture of the OAM system as well as
   giving overviews of the functionality of the OAM toolset.

   Some of the basic requirements for the OAM toolset for MPLS-TP are:

   o MPLS-TP OAM must be able to support both an IP based and non-IP
      based environment. If the network is IP based, i.e. IP routing and
      forwarding are available, then the MPLS-TP OAM toolset should rely
      on the IP routing and forwarding capabilities. On the other hand,
      in environments where IP functionality is not available, the OAM
      tools must still be able to operate without dependence on IP
      forwarding and routing.

SB> "should rely on the IP routing and forwarding capabilities" That is
SB> rather ambiguous. As I recall this is only to get responses
SB> back from MIPs where the path is broken.
SB> -TP uses co-routed bidirectional channels and again as I recall
SB> the "normal" response is back via that.

   o OAM packets and the user traffic are required to be congruent
      (i.e. OAM packets are transmitted in-band) and there is a need to
      differentiate OAM packets from data plane ones. Inherent in this
      requirement is the principle that MPLS-TP OAM be independent of
      any existing control-plane, although it should not preclude use of
      the control-plane functionality.

SB> So you miss the key point in that we use L13 as an inband
SB> OAM discriminator.

4.5.2. Terminology

Maintenance Entity (ME)

   The MPLS-TP OAM tools are designed to monitor and manage a
   Maintenance Entity (ME).  An ME, as defined in [TP-OAM-FW], defines a
   relationship between two points of a transport path to which
   maintenance and monitoring operations apply.

   The term Maintenance Entity (ME) is used in ITU-T Recommendations
   (e.g. [ITU-T-Y1731]), as well as in the MPLS-TP terminology
   ([TP-OAM-FW]).

Maintenance Entity Group (MEG)





Mizrahi, et al.        Expires April 21, 2014                [Page 20]
Internet-Draft          Overview of OAM Tools             October 2013


   The collection of one or more MEs that belongs to the same transport
   path and that are maintained and monitored as a group are known as a
   Maintenance Entity Group (based on [TP-OAM-FW]).

Maintenance Point (MP)

   A Maintenance Point (MP) is a functional entity that is defined at a
   node in the network, and can initiate and/or react to OAM messages.
   This document focuses on the data-plane functionality of MPs, while
   MPs interact with the control plane and with the management plane as
   well.

   The term MP is used in IEEE 802.1ag, and was similarly adopted in
   MPLS-TP ([TP-OAM-FW]).

Maintenance End Point (MEP)

   A Maintenance End Point (MEP) is one of the end points of an ME, and
   can initiate OAM messages and respond to them (based on [TP-OAM-FW]).

Maintenance Intermediate Point (MIP)

   In between MEPs, there are zero or more intermediate points, called
   Maintenance Entity Group Intermediate Points  (based on [TP-OAM-FW]).

   A Maintenance Intermediate Point (MIP) is an intermediate point that
   does not generally initiate OAM frames (one exception to this is the
   use of AIS notifications), but is able to respond to OAM frames that
   are destined to it. A MIP in MPLS-TP identifies OAM packets destined
   to it by the value of the TTL field in the OAM packet. The term
   Maintenance Point is a general term for MEPs and MIPs.

Up and Down MEPs

   The IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs
   and Down MEPs. A MEP is a bridge interface that is monitored by an
   OAM protocol either in the direction facing the network, or in the
   direction facing the bridge. A Down MEP is a MEP that receives OAM
   packets from, and transmits them to the direction of the network. An
   Up MEP receives OAM packets from, and transmits them to the direction
   of the bridging entity. MPLS-TP ([TP-OAM-FW]) uses a similar
   distinction on the placement of the MEP - either at the ingress,
   egress, or forwarding function of the node (Down / Up MEPs).  This
   placement is important for localization of a failure.





Mizrahi, et al.        Expires April 21, 2014                [Page 21]
Internet-Draft          Overview of OAM Tools             October 2013


   The distinction between Up and Down MEPs was defined in [TP-OAM-FW],
   but has not been used in other MPLS-TP RFCs, as of the writing of
   this document.

4.5.3. Generic Associated Channel

   In order to address the requirement for in-band transmission of MPLS-
   TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh),
   defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based
   on the same concepts as the PWE3 ACH and VCCV mechanisms.  However,
   to address the needs of LSPs as differentiated from PW, the following
   concepts were defined for [G-ACh]:

   o An Associated Channel Header (ACH), that uses a format similar to
      the PW Control Word, is a 4-byte header that is prepended to OAM
      packets.

   o A Generic Associated Label (GAL). The GAL is a reserved MPLS label
      value (13) that indicates that the packet is an ACH packet and the
      payload follows immediately after the label stack.

   It should be noted that while the G-ACh was defined as part of the
   MPLS-TP definition effort, the G-ACh is a generic tool that can be
   used in MPLS in general, and not only in MPLS-TP.

SB> Whilst historically what you say is true WRT PWE3, I think the
SB> approach confuses the reader, particularly as they have not yet
SB> met PWE3 in this document.

4.5.4. MPLS-TP OAM Toolset

   To address the functionality that is required of the OAM toolset, the
   MPLS WG conducted an analysis of the existing IETF and ITU-T OAM
   tools and their ability to fulfill the required functionality.  The
   conclusions of this analysis are documented in [OAM-Analys]. The MPLS
   working group currently plans to use a mixture of OAM tools that are
   based on various existing standards, and adapt them to the
   requirements of [MPLS-TP-OAM]. Some of the main building blocks of
   this solution are based on:

   o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for
      proactive continuity check and connectivity verification.

   o LSP Ping as defined in [LSP-Ping] for on-demand connectivity
      verification.

   o New protocol packets, using G-ACH, to address different
      functionality.

   o Performance measurement protocols that are based on the
      functionality that is described in [ITU-T-Y1731].


Mizrahi, et al.        Expires April 21, 2014                [Page 22]
Internet-Draft          Overview of OAM Tools             October 2013


   The following sub-sections describe the OAM tools defined for MPLS-TP
   as described in [TP-OAM-FW].

4.5.4.1. Continuity Check and Connectivity Verification

   Continuity Check and Connectivity Verification are presented in
   Section 2.2.7. of this document.  As presented there, these tools may
   be used either proactively or on-demand.  When using these tools
   proactively, they are generally used in tandem.

   For MPLS-TP there are two distinct tools, the proactive tool is
   defined in [TP-CC-CV] while the on-demand tool is defined in
   [OnDemand-CV]. In on-demand mode, this function should support
   monitoring between the MEPs and, in addition, between a MEP and MIP.
   [TP-OAM-FW] highlights,  when performing Connectivity Verification,
   the need for the CC-V messages to include unique identification of
   the MEG that is being monitored and the MEP that originated the
   message.

   The proactive tool [TP-CC-CV] is based on extensions to BFD (see
   Section 4.3.) with the additional limitation that the transmission
   and receiving rates are based on configuration by the operator.  The
   on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see
   Section 4.4.) for the required behavior of MPLS-TP.

4.5.4.2. Route Tracing

   [MPLS-TP-OAM] defines that there is a need for functionality that
   would allow a path end-point to identify the intermediate and end-
   points of the path. This function would be used in on-demand mode.
   Normally, this path will be used for bidirectional PW, LSP, and
   sections, however, unidirectional paths may be supported only if a
   return path exists.  The tool for this is based on the LSP Ping (see
   Section 4.4.) functionality and is described in [OnDemand-CV].

4.5.4.3. Lock Instruct

   The Lock Instruct function [Lock-Loop] is used to notify a transport
   path end-point of an administrative need to disable the transport
   path.  This functionality will generally be used in conjunction with
   some intrusive OAM function, e.g. Performance measurement, Diagnostic
   testing, to minimize the side-effect on user data traffic.







Mizrahi, et al.        Expires April 21, 2014                [Page 23]
Internet-Draft          Overview of OAM Tools             October 2013


4.5.4.4. Lock Reporting

   Lock Reporting is a function used by an end-point of a path to report
   to its far-end end-point that a lock condition has been affected on
   the path.

4.5.4.5. Alarm Reporting

   Alarm Reporting [TP-Fault] provides the means to suppress alarms
   following detection of defect conditions at the server sub-layer.
   Alarm reporting is used by an intermediate point of a path, that
   becomes aware of a fault on the path, to report to the end-points of
   the path. [TP-OAM-FW] states that this may occur as a result of a
   defect condition discovered at a server sub-layer. This generates an
   Alarm Indication Signal (AIS) that continues until the fault is
   cleared. The consequent action of this function is detailed in
   [TP-OAM-FW].

4.5.4.6. Remote Defect Indication

   Remote Defect Indication (RDI) is used proactively by a path end-
   point to report to its peer end-point that a defect is detected on a
   bidirectional connection between them. [MPLS-TP-OAM] points out that
   this function may be applied to a unidirectional LSP only if there a
   return path exists.  [TP-OAM-FW] points out that this function is
   associated with the proactive CC-V function.

4.5.4.7. Client Failure Indication

   Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow
   the propagation information from one edge of the network to the
   other. The information concerns a defect to a client, in the case
   that the client does not support alarm notification.

4.5.4.8. Performance Monitoring

   The definition of MPLS performance monitoring was motivated by the
   MPLS-TP requirements [MPLS-TP-OAM], but was defined generically for
   MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines a
   performance monitoring profile for MPLS-TP.

4.5.4.8.1. Packet Loss Measurement (LM)

   Packet Loss Measurement is a function used to verify the quality of
   the service. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM],
   indicates the ratio of the number of user packets lost to the total
   number of user packets sent during a defined time interval.


Mizrahi, et al.        Expires April 21, 2014                [Page 24]
Internet-Draft          Overview of OAM Tools             October 2013


   There are two possible ways of determining this measurement:

   o Using OAM packets, it is possible to compute the statistics based
      on a series of OAM packets. This, however, has the disadvantage of
      being artificial, and may not be representative since part of the
      packet loss may be dependent upon packet sizes and upon the
      implementation of the MEPs that take part in the protocol.

   o Sending delimiting messages for the start and end of a measurement
      period during which the source and sink of the path count the
      packets transmitted and received. After the end delimiter, the
      ratio would be calculated by the path OAM entity.

SB> This needs some references - To some of the early work and to the
SB> more recent work by TI.
SB> Note that this contradicts earlier statements about P2MP live
SB> traffic measurement.

4.5.4.8.2. Packet Delay Measurement (DM)

   Packet Delay Measurement is a function that is used to measure one-
   way or two-way delay of a packet transmission between a pair of the
   end-points of a path (PW, LSP, or Section). Where:

   o One-way packet delay, as defined in [IPPM-1DM], is the time
      elapsed from the start of transmission of the first bit of the
      packet by a source node until the reception of the last bit of
      that packet by the destination node. Note that one-way delay
      measurement requires the clocks of the two end-points to be
      synchronized.

   o Two-way packet delay, as defined in [IPPM-2DM], is the time
      elapsed from the start of transmission of the first bit of the
      packet by a source node until the reception of the last bit of the
      loop-backed packet by the same source node, when the loopback is
      performed at the packet's destination node. Note that due to
      possible path asymmetry, the one-way packet delay from one end-
      point to another is not necessarily equal to half of the two-way
      packet delay.
      As opposed to one-way delay measurement, two-way delay measurement
      does not require the two end-points to be synchronized.

   For each of these two metrics, the DM function allows the MEP to
   measure the delay, as well as the delay variation. Delay measurement
   is performed by exchanging timestamped OAM packets between the
   participating MEPs.








Mizrahi, et al.        Expires April 21, 2014                [Page 25]
Internet-Draft          Overview of OAM Tools             October 2013


4.6. Pseudowire OAM

4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification
   (VCCV)

   VCCV, as defined in [VCCV], provides a means for end-to-end fault
   detection and diagnostics tools to be extended for PWs (regardless of
   the underlying tunneling technology). The VCCV switching function
   provides a control channel associated with each PW. [VCCV] defines
   three Control Channel (CC) types, i.e., three possible methods for
   transmitting and identifying OAM messages:

   o CC Type 1: In-band VCCV, as described in [VCCV], is also referred
      to as "PWE3 Control Word with 0001b as first nibble".  It uses the
      PW Associated Channel Header [PW-ACH].

   o CC Type 2: Out-of-band VCCV [VCCV], is also referred to as "MPLS
      Router Alert Label". In this case the control channel is created
      by using the MPLS router alert label [RFC3032] immediately above
      the PW label.

   o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as "MPLS PW
      Label with TTL == 1", i.e., the control channel is identified when
      the value of the TTL field in the PW label is set to 1.

   VCCV currently supports the following OAM tools: ICMP Ping, LSP Ping,
   and BFD. ICMP and LSP Ping are IP encapsulated before being sent over
   the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of
   encapsulation - either IP/UDP encapsulated (with IP/UDP header) or
   PW-ACH encapsulated (with no IP/UDP header) and provides support to
   signal the AC status. The use of the VCCV control channel provides
   the context, based on the MPLS-PW label, required to bind and
   bootstrap the BFD session to a particular pseudo wire (FEC),
   eliminating the need to exchange Discriminator values.

   VCCV consists of two components: (1) signaled component to
   communicate VCCV capabilities as part of VC label, and (2) switching
   component to cause the PW payload to be treated as a control packet.

   VCCV is not directly dependent upon the presence of a control plane.
   The VCCV capability negotiation may be performed as part of the PW
   signaling when LDP is used. In case of manual configuration of the
   PW, it is the responsibility of the operator to set consistent
   options at both ends. The manual option was created specifically to
   handle MPLS-TP use cases where no control plane was a requirement.
   However, new use cases such as pure mobile backhaul find this
   functionality useful too.

SB> There is a strange logic in the flow above - it is not depenent, it uses
SB> the CP - it can be configured


Mizrahi, et al.        Expires April 21, 2014                [Page 26]
Internet-Draft          Overview of OAM Tools             October 2013


   The PWE3 working group has conducted an implementation survey of VCCV
   [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in
   practice.

4.6.2. Pseudowire OAM using G-ACh

   As mentioned above, VCCV enables OAM for PWs by using a control
   channel for OAM packets. When PWs are used in MPLS-TP networks,
   rather than the control channels defined in VCCV, the G-ACh can be
   used as an alternative control channel. The usage of the G-ACh for
   PWs is defined in [PW-G-ACh].

4.6.3. Attachment Circuit - Pseudowire Mapping

SB> Isn't this message mapping?

   The PWE3 working group has defined a mapping and notification of
   defect states between a pseudowire (PW) and the Attachment Circuits
   (ACs) of the end-to-end emulated service. This mapping is of key
   importance to the end-to-end functionality. Specifically, the mapping
   is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and
   Section 5.3 of [ATM-L2] for ATM.

4.7. OWAMP and TWAMP

4.7.1. Overview

SB> See my earlier note about whether his is measuring
SB> data plane performance or transport layer performance.

   The IPPM working group in the IETF defines common criteria and
   metrics for measuring performance of IP traffic ([IPPM-FW]). Some of
   the key RFCs published by this working group have defined metrics for
   measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]),
   and packet loss [IPPM-1LM]. It should be noted that the work of the
   IETF in the context of performance metrics is not limited to IP
   networks; [PM-CONS] presents general guidelines for considering new
   performance metrics.

   The IPPM working group has defined not only metrics for performance
   measurement, but also protocols that define how the measurement is
   carried out. The One-way Active Measurement Protocol [OWAMP] and the
   Two-Way Active Measurement Protocol [TWAMP] define a method and
   protocol for measuring performance metrics in IP networks.

   OWAMP [OWAMP] enables measurement of one-way characteristics of IP
   networks, such as one-way packet loss and one-way delay.  For its
   proper operation OWAMP requires accurate time of day setting at its
   end points.

   TWAMP [TWAMP] is a similar protocol that enables measurement of both
   one-way and two-way (round trip) characteristics.


Mizrahi, et al.        Expires April 21, 2014                [Page 27]
Internet-Draft          Overview of OAM Tools             October 2013


   OWAMP and TWAMP are both comprised of two separate protocols:

   o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop
      test sessions and to fetch their results. Continuity Check and
      Connectivity Verification are tested and confirmed by establishing
      the OWAMP/TWAMP Control Protocol TCP connection.

   o OWAMP-Test/TWAMP-Test: used to exchange test packets between two
      measurement nodes. Enables the loss and delay measurement
      functions, as well as detection of other anomalies, such as packet
      duplication and packet reordering.

   It should be noted that while [OWAMP] and [TWAMP] define tools for
   performance measurement, they do not define the accuracy of these
   tools. The accuracy depends on scale, implementation and network
   configurations.

   Alternative protocols for performance monitoring are defined, for
   example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet
   OAM [ITU-T-Y1731].

4.7.2. Control and Test Protocols

   OWAMP and TWAMP control protocols run over TCP, while the test
   protocols run over UDP.  The purpose of the control protocols is to
   initiate, start, and stop test sessions, and for OWAMP to fetch
   results.  The test protocols introduce test packets (which contain
   sequence numbers and timestamps) along the IP path under test
   according to a schedule, and record statistics of packet arrival.
   Multiple sessions may be simultaneously defined, each with a session
   identifier, and defining the number of packets to be sent, the amount
   of padding to be added (and thus the packet size), the start time,
   and the send schedule (which can be either a constant time between
   test packets or exponentially distributed pseudo-random). Statistics
   recorded conform to the relevant IPPM RFCs.

   OWAMP and TWAMP test traffic is designed with security in mind. Test
   packets are hard to detect because they are simply UDP streams
   between negotiated port numbers, with potentially nothing static in
   the packets.  OWAMP and TWAMP also include optional authentication
   and encryption for both control and test packets.


4.7.3. OWAMP

   OWAMP defines the following logical roles: Session-Sender, Session-
   Receiver, Server, Control-Client, and Fetch-Client.  The Session-
   Sender originates test traffic that is received by the Session-


Mizrahi, et al.        Expires April 21, 2014                [Page 28]
Internet-Draft          Overview of OAM Tools             October 2013


   Receiver.  The Server configures and manages the session, as well as
   returning the results.  The Control-Client initiates requests for
   test sessions, triggers their start, and may trigger their
   termination.  The Fetch-Client requests the results of a completed
   session.  Multiple roles may be combined in a single host - for
   example, one host may play the roles of Control-Client, Fetch-Client,
   and Session-Sender, and a second playing the roles of Server and
   Session-Receiver.

   In a typical OWAMP session the Control-Client establishes a TCP
   connection to port 861 of the Server, which responds with a server
   greeting message indicating supported security/integrity modes. The
   Control-Client responds with the chosen communications mode and the
   Server accepts the modes.  The Control-Client then requests and fully
   describes a test session to which the Server responds with its
   acceptance and supporting information.  More than one test session
   may be requested with additional messages.  The Control-Client then
   starts a test session and the Server acknowledges.  The Session-
   Sender then sends test packets with pseudorandom padding to the
   Session-Receiver until the session is complete or until the Control-
   client stops the session.  Once finished, the Fetch-Client sends a
   fetch request to the server, which responds with an acknowledgement
   and immediately thereafter the result data.

4.7.4. TWAMP

   TWAMP defines the following logical roles: session-sender, session-
   reflector, server, and control-client.  These are similar to the
   OWAMP roles, except that the Session-Reflector does not collect any
   packet information, and there is no need for a Fetch-Client.

   In a typical TWAMP session the Control-Client establishes a TCP
   connection to port 862 of the Server, and mode is negotiated as in
   OWAMP.  The Control-Client then requests sessions and starts them.
   The Session-Sender sends test packets with pseudorandom padding to
   the Session-Reflector which returns them with insertion of
   timestamps.

4.8. TRILL

   The requirements of OAM in TRILL are defined in [TRILL-OAM]. The
   challenge in TRILL OAM, much like in MPLS networks, is that traffic
   between RBridges RB1 and RB2 may be forwarded through more than one
   path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able
   to monitor all the available paths between the two RBridge.




Mizrahi, et al.        Expires April 21, 2014                [Page 29]
Internet-Draft          Overview of OAM Tools             October 2013


   During the writing of this document the detailed definition of the
   TRILL OAM tools are still work in progress. This subsection presents
   the main requirements of TRILL OAM.

   The main requirements defined in [TRILL-OAM] are:

   o Continuity Checking (CC) - the TRILL OAM protocol must support a
      function for CC between any two RBridges RB1 and RB2.

   o Connectivity Verification (CV) - connectivity between two RBridges
      RB1 and RB2 can be verified on a per-flow basis.

   o Path Tracing - allows an RBridge to trace all the available paths
      to a peer RBridge.

   o Performance monitoring - allows an RBridge to monitor the packet
      loss and packet delay to a peer RBridge.

4.9. Summary of OAM Tools

   This subsection provides a short summary of each of the OAM tool
   categories described in this document.

   A detailed list of the RFCs related to each category is given in
   Appendix A.1.

   +-----------+------------------------------------------+------------+
   | Category  | Description                              | Transport  |
   |           |                                          | Technology |
   +-----------+------------------------------------------+------------+
   |IP Ping    | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6  |
   |           | application for testing reachability that|            |
   |           | uses ICMP Echo messages ([ICMPv4],       |            |
   |           | [ICMPv6]).                               |            |
   +-----------+------------------------------------------+------------+
   |IP         | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6  |
   |Traceroute | an application that allows users to trace|            |
   |           | the path between an IP source and an IP  |            |
   |           | destination, i.e., to identify the nodes |            |
   |           | along the path. If more than one path    |            |
   |           | exists between the source and destination|            |
   |           | Traceroute traces *a* path. The most     |            |
   |           | common implementation of Traceroute      |            |
   |           | uses UDP probe messages, although there  |            |


Mizrahi, et al.        Expires April 21, 2014                [Page 30]
Internet-Draft          Overview of OAM Tools             October 2013


   |           | are other implementations that use       |            |
   |           | different probes, such as ICMP or TCP.   |            |
   +-----------+------------------------------------------+------------+
   |BFD        | Bidirectional Forwarding Detection (BFD) | generic    |
   |           | is defined in [BFD] as a framework for a |            |
   |           | lightweight generic OAM tool.  The       |            |
   |           | intention is to define a base tool       |            |
   |           | that can be used with various            |            |
   |           | encapsulation types, network             |            |
   |           | environments, and in various medium      |            |
   |           | types.                                   |            |
   +-----------+------------------------------------------+------------+
   |MPLS OAM   | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS       |
   |           | [MPLS-OAM-FW] and [LSP-Ping], is an OAM  |            |
   |           | tool for point-to-point and              |            |
   |           | point-to-multipoint MLPS LSPs.           |            |
   |           | It includes two main functions: Ping and |            |
   |           | Traceroute.                              |            |
   |           | It is noted that while this category     |            |
   |           | focuses on LSP Ping, other OAM tools     |            |
   |           | can be used in MPLS networks, e.g., BFD. |            |
   +-----------+------------------------------------------+------------+
   |MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP    |
   |           | The OAM requirements for MPLS Transport  |            |
   |           | Profile (MPLS-TP) are defined in         |            |
   |           | [MPLS-TP-OAM]. Each of the tools in the  |            |
   |           | OAM toolset is defined in its own RFC, as|            |
   |           | specified in Section A.1.                |            |
   +-----------+------------------------------------------+------------+
   |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire |
   |OAM        | channels that support the use of existing|            |
   |           | IETF OAM tools to be used for a pseudo-  |            |
   |           | wire (PW).  The control channels that are|            |
   |           | defined in [VCCV] and [PW-G-ACh] may be  |            |
   |           | used in conjunction with ICMP Ping, LSP  |            |
   |           | Ping, and BFD to perform CC and CV       |            |
   |           | functionality.  In addition the channels |            |
   |           | support use of any of the MPLS-TP based  |            |
   |           | OAM tools for completing their respective|            |
   |           | OAM functionality for a PW.              |            |
   +-----------+------------------------------------------+------------+


Mizrahi, et al.        Expires April 21, 2014                [Page 31]
Internet-Draft          Overview of OAM Tools             October 2013


   |OWAMP and  | The One Way Active Measurement Protocol  | IPv4/IPv6  |
   |TWAMP      | (OWAMP) and the Two Way Active Measure-  |            |
   |           | ment Protocols (TWAMP) are two protocols |            |
   |           | defined in the IP Performance Metrics    |            |
   |           | (IPPM) working group in the IETF. These  |            |
   |           | protocols allow various performance      |            |
   |           | metrics to be measured, such as packet   |            |
   |           | loss, delay and delay variation,         |            |
   |           | duplication and reordering.              |            |
   +-----------+------------------------------------------+------------+
   |TRILL OAM  | The requirements of OAM in TRILL are     | TRILL      |
   |           | defined in [TRILL-OAM]. These            |            |
   |           | requirements include continuity checking,|            |
   |           | connectivity verification, path tracing  |            |
   |           | and performance monitoring. During the   |            |
   |           | writing of this document the detailed    |            |
   |           | definition of the TRILL OAM tools        |            |
   |           | is work in progress.                     |            |
   +-----------+------------------------------------------+------------+
                 Table 3 Summary of OAM-related IETF Tools

4.10. Summary of OAM Functions

   Table 4 summarizes the OAM functions that are supported in each of
   the categories that were analyzed in this section. The columns of
   this tables are the typical OAM functions described in Section 1.3.

       +-----------+-------+--------+--------+-------+----------+
       |           |Continu|Connecti|Path    |Perform|Other     |
       |           |ity    |vity    |Discover|ance   |Function  |
       |           |Check  |Verifica|y       |Monitor|s         |
       | Category  |       |tion    |        |ing    |          |
       +-----------+-------+--------+--------+-------+----------+
       |IP Ping    |Echo   |        |        |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |IP         |       |        |Tracerou|       |          |
       |Traceroute |       |        |te      |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |BFD        |BFD    |BFD     |        |       |RDI usi-  |
       |           |Control|Control |        |       |ng BFD    |
       |           |/ Echo |        |        |       |Control   |
       + --------- + ----- + ------ + ------ + ----- + -------- +


Mizrahi, et al.        Expires April 21, 2014                [Page 32]
Internet-Draft          Overview of OAM Tools             October 2013


       |MPLS OAM   |       |"Ping"  |"Tracero|       |          |
       |(LSP Ping) |       |mode    |ute"    |       |          |
       |           |       |        |mode    |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |MPLS-TP    |CC     |CV/pro- |Route   |-LM    |-Diagnos- |
       |OAM        |       |active  |Tracing |-DM    | tic Test |
       |           |       |or on-  |        |       |-Lock     |
       |           |       |demand  |        |       |-Alarm    |
       |           |       |        |        |       |Reporting |
       |           |       |        |        |       |-Client   |
       |           |       |        |        |       |Failure   |
       |           |       |        |        |       |Indication|
       |           |       |        |        |       |-RDI      |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |Pseudowire |BFD    |-BFD    |LSP-Ping|       |          |
       |OAM        |       |-ICMP   |        |       |          |
       |           |       | Ping   |        |       |          |
       |           |       |-LSP-   |        |       |          |
       |           |       | Ping   |        |       |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |OWAMP and  | - control      |        |-Delay |          |
       |TWAMP      |   protocol     |        | measur|          |
       |           |                |        | ement |          |
       |           |                |        |-Packet|          |
       |           |                |        | loss  |          |
       |           |                |        | measur|          |
       |           |                |        | ement |          |
       + --------- + ----- + ------ + ------ + ----- + -------- +
       |TRILL OAM  |CC     |CV      |Path    |-Delay |          |
       |           |       |        |tracing | measur|          |
       |           |       |        |        | ement |          |
       |           |       |        |        |-Packet|          |
       |           |       |        |        | loss  |          |
       |           |       |        |        | measur|          |
       |           |       |        |        | ement |          |
       +-----------+-------+--------+--------+-------+----------+
         Table 4 Summary of the OAM Functionality in IETF OAM Tools

5. Security Considerations

   This memo presents an overview of existing OAM tools, and proposes
   no new OAM tools. Therefore, this document introduces no security


Mizrahi, et al.        Expires April 21, 2014                [Page 33]
Internet-Draft          Overview of OAM Tools             October 2013


   considerations. However, the OAM tools reviewed in this document can
   and do present security issues. The reader is encouraged to review
   the Security Considerations section of each document referenced by
   this memo.

6. IANA Considerations

   There are no new IANA considerations implied by this document.

7. Acknowledgments

   The authors gratefully acknowledge Sasha Vainshtein, Carlos
   Pignataro, David Harrington, Dan Romascanu, Ron Bonica and other
   members of the OPSAWG mailing list for their helpful comments.

   This document was prepared using 2-Word-v2.0.template.dot.

8. References

8.1. Informative References

   [ATM-L2]      Singh, S., Townsley, M., and C. Pignataro,
                 "Asynchronous Transfer Mode (ATM) over Layer 2
                 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May
                 2006.

   [BFD]         Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD)", RFC 5880, June 2010.

   [BFD-Gen]     Katz, D., Ward, D., "Generic Application of
                 Bidirectional Forwarding Detection (BFD)", RFC 5882,
                 June 2010.

   [BFD-IP]      Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
                 2010.

   [BFD-LSP]     Aggarwal, R., Kompella, K., Nadeau, T., and Swallow,
                 G., "Bidirectional Forwarding Detection (BFD) for MPLS
                 Label Switched Paths (LSPs)", RFC 5884, June 2010.

   [BFD-Multi]   Katz, D., Ward, D., "Bidirectional Forwarding Detection
                 (BFD) for Multihop Paths", RFC 5883, June 2010.






Mizrahi, et al.        Expires April 21, 2014                [Page 34]
Internet-Draft          Overview of OAM Tools             October 2013


   [BFD-VCCV]    Nadeau, T., Pignataro, C., "Bidirectional Forwarding
                 Detection (BFD) for the Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV)", RFC 5885, June
                 2010.

   [Comp]        Bonaventure, O., "Computer Networking: Principles,
                 Protocols and Practice", 2008.

   [Cont]        Dugal, D., Pignataro, C., Dunn, R., "Protecting the
                 Router Control Plane", RFC 6192, March 2011.

   [Dup]         Uijterwaal, H., "A One-Way Packet Duplication Metric",
                 RFC 5560, May 2009.

   [G-ACh]       Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic
                 Associated Channel", RFC 5586, June 2009.

   [ICMP-Ext]    Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP
                 Extensions for Multiprotocol Label Switching", RFC
                 4950, August 2007.

   [ICMP-Int]    Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers,
                 JR., "Extending ICMP for Interface and Next-Hop
                 Identification", RFC 5837, April 2010.

   [ICMP-MP]     Bonica, R., Gan, D., Tappan, D., Pignataro, C.,
                 "Extended ICMP to Support Multi-Part Messages", RFC
                 4884, April 2007.

   [ICMPv4]      Postel, J., "Internet Control Message Protocol", STD 5,
                 RFC 792, September 1981.

   [ICMPv6]      Conta, A., Deering, S., and M. Gupta, "Internet Control
                 Message Protocol (ICMPv6) for the Internet Protocol
                 Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [IEEE802.1Q]  IEEE 802.1Q, "IEEE Standard for Local and metropolitan
                 area networks - Media Access Control (MAC) Bridges and
                 Virtual Bridged Local Area Networks", October 2012.

   [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology -
                 Local and metropolitan area networks - Carrier sense
                 multiple access with collision detection (CSMA/CD)
                 access method and physical layer specifications",
                 clause 57, December 2008.




Mizrahi, et al.        Expires April 21, 2014                [Page 35]
Internet-Draft          Overview of OAM Tools             October 2013


   [IntHost]     Braden, R., "Requirements for Internet Hosts --
                 Communication Layers", RFC 1122, October 1989.

   [IPPM-1DM]    Almes, G., Kalidindi, S., Zekauskas, M., "A One-way
                 Delay Metric for IPPM", RFC 2679, September 1999.

   [IPPM-1LM]    Almes, G., Kalidindi, S., Zekauskas, M., "A One-way
                 Packet Loss Metric for IPPM", RFC 2680, September
                 1999.

   [IPPM-2DM]    Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip
                 Delay Metric for IPPM", RFC 2681, September 1999.

   [IPPM-Con]    Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring
                 Connectivity", RFC 2678, September 1999.

   [IPPM-FW]     Paxson, V., Almes, G., Mahdavi, J., and Mathis, M.,
                 "Framework for IP Performance Metrics", RFC 2330, May
                 1998.

   [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations,
                 Administration and Maintenance mechanism for MPLS-TP
                 in Packet Transport Network (PTN)", November 2012.

   [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations,
                 administration and maintenance mechanisms for MPLS-TP
                 networks using the tools defined for MPLS", November
                 2012.

   [ITU-T-CT]    Betts, M., "Allocation of a Generic Associated Channel
                 Type for ITU-T MPLS Transport Profile Operation,
                 Maintenance, and Administration (MPLS-TP OAM)", RFC
                 6671, November 2012.

   [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of
                 transport equipment - Description methodology and
                 generic functionality", January 2009.

   [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance
                 mechanism for MPLS networks", February 2004.

   [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and
                 Mechanisms for Ethernet-based Networks", July 2011.

   [ITU-Terms]   ITU-R/ITU-T Terms and Definitions, online, 2013.




Mizrahi, et al.        Expires April 21, 2014                [Page 36]
Internet-Draft          Overview of OAM Tools             October 2013


   [L2TP-EC]     McGill, N. and C. Pignataro, "Layer 2 Tunneling
                 Protocol Version 3 (L2TPv3) Extended Circuit Status
                 Values", RFC 5641, August 2009.

   [Lock-Loop]   Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux,
                 M., Dai, X., "MPLS Transport Profile Lock Instruct and
                 Loopback Functions", RFC 6435, November 2011.

   [LSP-Ping]    Kompella, K., Swallow, G., "Detecting Multi-Protocol
                 Label Switched (MPLS) Data Plane Failures", RFC 4379,
                 February 2006.

   [Mng]         Farrel, A., "Inclusion of Manageability Sections in
                 Path Computation Element (PCE) Working Group Drafts",
                 RFC 6123, February 2011.

   [MPLS-LM-DM]  Frost, D., Bryant, S., "Packet Loss and Delay
                 Measurement for MPLS Networks", RFC 6374, September
                 2011.

   [MPLS-OAM]    Nadeau, T., Morrow, M., Swallow, G., Allan, D.,
                 Matsushima, S., "Operations and Management (OAM)
                 Requirements for Multi-Protocol Label Switched (MPLS)
                 Networks", RFC 4377, February 2006.

   [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol
                 Label Switching (MPLS) Operations and Management
                 (OAM)", RFC 4378, February 2006.

   [MPLS-P2MP]   Yasukawa, S., Farrel, A., King, D., Nadeau, T.,
                 "Operations and Management (OAM) Requirements for
                 Point-to-Multipoint MPLS Networks", RFC 4687,
                 September 2006.

   [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for
                 OAM in MPLS Transport Networks", RFC 5860, May 2010.

   [NetTerms]    Jacobsen, O., Lynch, D., "A Glossary of Networking
                 Terms", RFC 1208, March 1991.

   [NetTools]    Enger, R., Reynolds, J., "FYI on a Network Management
                 Tool Catalog: Tools for Monitoring and Debugging
                 TCP/IP Internets and Interconnected Devices", RFC
                 1470, June 1993.





Mizrahi, et al.        Expires April 21, 2014                [Page 37]
Internet-Draft          Overview of OAM Tools             October 2013


   [OAM-Analys]  Sprecher, N., Fang, L., "An Overview of the OAM Tool
                 Set for  MPLS based Transport Networks", RFC 6669,
                 July 2012.

   [OAM-Def]     Andersson, L., Van Helvoort, H., Bonica, R., Romascanu,
                 D., Mansfield, S., "Guidelines for the use of the OAM
                 acronym in the IETF ", RFC 6291, June 2011.

   [OAM-Label]   Ohta, H., "Assignment of the 'OAM Alert Label' for
                 Multiprotocol Label Switching Architecture (MPLS)
                 Operation and Maintenance (OAM) Functions", RFC 3429,
                 November 2002.

   [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS
                 On-Demand Connectivity Verification and Route
                 Tracing", RFC 6426, November 2011.

   [OWAMP]       Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
                 Zekauskas, M., "A One-way Active Measurement Protocol
                 (OWAMP)", RFC 4656, September 2006.

   [PARIS]       Brice Augustin, Timur Friedman and Renata Teixeira,
                 "Measuring Load-balanced Paths in the Internet", IMC,
                 2007.

   [PM-CONS]     Clark, A. and B. Claise, "Guidelines for Considering
                 New Performance Metric Development", BCP 170, RFC
                 6390, October 2011.

   [PW-ACH]      Bryant, S., Swallow, G., Martini, L., McPherson, D.,
                 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
                 for Use over an MPLS PSN", RFC 4385, February 2006.

   [PW-G-ACh]    Li, H., Martini, L., He, J., Huang, F., "Using the
                 Generic Associated Channel Label for Pseudowire in the
                 MPLS Transport Profile (MPLS-TP)", RFC 6423, November
                 2011.

   [PW-MAP]      Aissaoui, M., Busschbach, P., Martini, L., Morrow, M.,
                 Nadeau, T., and Y(J). Stein, "Pseudowire (PW)
                 Operations, Administration, and Maintenance (OAM)
                 Message Mapping", RFC 6310, July 2011.

   [PW-Map]      M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.
                 Nadeau, "Pseudowire (PW) Operations, Administration,
                 and Maintenance (OAM) Message Mapping", RFC 6310, July
                 2011.


Mizrahi, et al.        Expires April 21, 2014                [Page 38]
Internet-Draft          Overview of OAM Tools             October 2013


   [Reorder]     Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
                 S., and J. Perser, "Packet Reordering Metrics", RFC
                 4737, November 2006.

   [Signal]      Yasukawa, S., "Signaling Requirements for Point-to-
                 Multipoint Traffic-Engineered MPLS Label Switched
                 Paths (LSPs)", RFC 4461, April 2006.

   [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and
                 TCP/IP Tools and Utilities", RFC 2151, June 1997.

   [TP-CC-CV]    Allan, D., Swallow, G., Drake, J., "Proactive
                 Connectivity Verification, Continuity Check and Remote
                 Defect indication for MPLS Transport Profile", RFC
                 6428, November 2011.

   [TP-Fault]    Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S.,
                 "MPLS Fault Management Operations, Administration, and
                 Maintenance (OAM)", RFC 6427, November 2011.

   [TP-LM-DM]    Frost, D., Bryant, S., "A Packet Loss and Delay
                 Measurement Profile for MPLS-Based Transport
                 Networks", RFC 6375, September 2011.

   [TP-OAM-FW]   Busi, I., Allan, D., "Operations, Administration and
                 Maintenance Framework for MPLS-based Transport
                 Networks ", RFC 6371, September 2011.

   [TP-Term]     Van Helvoort, H., Andersson, L., Sprecher, N., "A
                 Thesaurus for the Terminology used in Multiprotocol
                 Label Switching Transport Profile (MPLS-TP)
                 drafts/RFCs and ITU-T's Transport Network
                 Recommendations", work-in-progress, draft-ietf-mpls-
                 tp-rosetta-stone, July 2012.

   [TRILL-OAM]   Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve,
                 R., "Requirements for Operations, Administration, and
                 Maintenance (OAM) in Transparent Interconnection of
                 Lots of Links (TRILL)", RFC 6905, March 2013.

   [TWAMP]       Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
                 Babiarz, J., "A Two-Way Active Measurement Protocol
                 (TWAMP)", RFC 5357, October 2008.

   [VCCV]        Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit
                 Connectivity Verification (VCCV): A Control Channel
                 for Pseudowires", RFC 5085, December 2007.


Mizrahi, et al.        Expires April 21, 2014                [Page 39]
Internet-Draft          Overview of OAM Tools             October 2013


   [VCCV-SURVEY] Del Regno, N., Malis, A., "The Pseudowire (PW) &
                 Virtual Circuit Connectivity Verification (VCCV)
                 Implementation Survey Results", work-in-progress,
                 draft-ietf-pwe3-vccv-impl-survey-results, August 2013.



Appendix A.                 List of OAM Documents

SB> My feeling is that this material would be better locate don a Wiki

A.1. List of IETF OAM Documents

   Table 5 summarizes the OAM related RFCs published by the IETF.

   It is important to note that the table lists various RFCs that are
   different by nature. For example, some of these documents define OAM
   tools or OAM protocols (or both), while others define protocols that
   are not strictly OAM-related, but are used by OAM tools. The table
   also includes RFCs that define the requirements or the framework of
   OAM in a specific context (e.g., MPLS-TP).

   The RFCs in the table are categorized in a few sets as defined in
   Section 1.3.

   +-----------+--------------------------------------+----------+
   | Category  | Title                                | RFC      |
   +-----------+--------------------------------------+----------+
   |IP Ping    | Requirements for Internet Hosts --   | RFC 1122 |
   |           | Communication Layers [IntHost]       |          |
   |           +--------------------------------------+----------+
   |           | A Glossary of Networking Terms       | RFC 1208 |
   |           | [NetTerms]                           |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 792  |
   |           | [ICMPv4]                             |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 4443 |
   |           | (ICMPv6) for the Internet Protocol   |          |
   |           | Version 6 (IPv6) Specification       |          |
   |           | [ICMPv6]                             |          |
   +-----------+--------------------------------------+----------+
   |IP         | A Primer On Internet and TCP/IP      | RFC 2151 |
   |Traceroute | Tools and Utilities [TCPIP-Tools]    |          |
   |           +--------------------------------------+----------+
   |           | FYI on a Network Management Tool     | RFC 1470 |


Mizrahi, et al.        Expires April 21, 2014                [Page 40]
Internet-Draft          Overview of OAM Tools             October 2013


   |           | Catalog: Tools for Monitoring and    |          |
   |           | Debugging TCP/IP Internets and       |          |
   |           | Interconnected Devices [NetTools]    |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 792  |
   |           | [ICMPv4]                             |          |
   |           +--------------------------------------+----------+
   |           | Internet Control Message Protocol    | RFC 4443 |
   |           | (ICMPv6) for the Internet Protocol   |          |
   |           | Version 6 (IPv6) Specification       |          |
   |           | [ICMPv6]                             |          |
   |           +--------------------------------------+----------+
   |           | Extended ICMP to Support Multi-Part  | RFC 4884 |
   |           | Messages [ICMP-MP]                   |          |
   |           +--------------------------------------+----------+
   |           | Extending ICMP for Interface and     | RFC 5837 |
   |           | Next-Hop Identification [ICMP-Int]   |          |
   +-----------+--------------------------------------+----------+
   |BFD        | Bidirectional Forwarding Detection   | RFC 5880 |
   |           | [BFD]                                |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5881 |
   |           | (BFD) for IPv4 and IPv6 (Single Hop) |          |
   |           | [BFD-IP]                             |          |
   |           +--------------------------------------+----------+
   |           | Generic Application of Bidirectional | RFC 5882 |
   |           | Forwarding Detection [BFD-Gen]       |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5883 |
   |           | (BFD) for Multihop Paths [BFD-Multi] |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5884 |
   |           | for MPLS Label Switched Paths (LSPs) |          |
   |           | [BFD-LSP]                            |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5885 |
   |           | for the Pseudowire Virtual Circuit   |          |
   |           | Connectivity Verification (VCCV)     |          |
   |           | [BFD-VCCV]                           |          |
   +-----------+--------------------------------------+----------+
   |MPLS OAM   | Operations and Management (OAM)      | RFC 4377 |


Mizrahi, et al.        Expires April 21, 2014                [Page 41]
Internet-Draft          Overview of OAM Tools             October 2013


   |           | Requirements for Multi-Protocol Label|          |
   |           | Switched (MPLS) Networks [MPLS-OAM]  |          |
   |           +--------------------------------------+----------+
   |           | A Framework for Multi-Protocol       | RFC 4378 |
   |           | Label Switching (MPLS) Operations    |          |
   |           | and Management (OAM) [MPLS-OAM-FW]   |          |
   |           +--------------------------------------+----------+
   |           | Detecting Multi-Protocol Label       | RFC 4379 |
   |           | Switched (MPLS) Data Plane Failures  |          |
   |           | [LSP-Ping]                           |          |
   |           +--------------------------------------+----------+
   |           | Operations and Management (OAM)      | RFC 4687 |
   |           | Requirements for Point-to-Multipoint |          |
   |           | MPLS Networks [MPLS-P2MP]            |          |
   |           +--------------------------------------+----------+
   |           | ICMP Extensions for Multiprotocol    | RFC 4950 |
   |           | Label Switching [ICMP-Ext]           |          |
   +-----------+--------------------------------------+----------+
   |MPLS-TP    | Requirements for OAM in MPLS-TP      | RFC 5860 |
   |OAM        | [MPLS-TP-OAM]                        |          |
   |           +--------------------------------------+----------+
   |           | MPLS Generic Associated Channel      | RFC 5586 |
   |           | [G-ACh]                              |          |
   |           +--------------------------------------+----------+
   |           | MPLS-TP OAM Framework                | RFC 6371 |
   |           | [TP-OAM-FW]                          |          |
   |           +--------------------------------------+----------+
   |           | Proactive Connectivity Verification, | RFC 6428 |
   |           | Continuity Check, and Remote Defect  |          |
   |           | Indication for the MPLS Transport    |          |
   |           | Profile [TP-CC-CV]                   |          |
   |           +--------------------------------------+----------+
   |           | MPLS On-Demand Connectivity          | RFC 6426 |
   |           | Verification and Route Tracing       |          |
   |           | [OnDemand-CV]                        |          |
   |           +--------------------------------------+----------+
   |           | MPLS Fault Management Operations,    | RFC 6427 |
   |           | Administration, and Maintenance (OAM)|          |
   |           | [TP-Fault]                           |          |
   |           +--------------------------------------+----------+
   |           | MPLS Transport Profile Lock Instruct | RFC 6435 |


Mizrahi, et al.        Expires April 21, 2014                [Page 42]
Internet-Draft          Overview of OAM Tools             October 2013


   |           | and Loopback Functions [Lock-Loop]   |          |
   |           +--------------------------------------+----------+
   |           | Packet Loss and Delay Measurement for| RFC 6374 |
   |           | MPLS Networks [MPLS-LM-DM]           |          |
   |           +--------------------------------------+----------+
   |           | A Packet Loss and Delay Measurement  | RFC 6375 |
   |           | Profile for MPLS-Based Transport     |          |
   |           | Networks [TP-LM-DM]                  |          |
   +-----------+--------------------------------------+----------+
   |Pseudowire | Pseudowire Virtual Circuit           | RFC 5085 |
   |OAM        | Connectivity Verification (VCCV):    |          |
   |           | A Control Channel for Pseudowires    |          |
   |           | [VCCV]                               |          |
   |           +--------------------------------------+----------+
   |           | Bidirectional Forwarding Detection   | RFC 5885 |
   |           | for the Pseudowire Virtual Circuit   |          |
   |           | Connectivity Verification (VCCV)     |          |
   |           | [BFD-VCCV]                           |          |
   |           +--------------------------------------+----------+
   |           | Using the Generic Associated Channel | RFC 6423 |
   |           | Label for Pseudowire in the MPLS     |          |
   |           | Transport Profile (MPLS-TP)          |          |
   |           | [PW-G-ACh]                           |          |
   |           +--------------------------------------+----------+
   |           | Pseudowire (PW) Operations,          | RFC 6310 |
   |           | Administration, and Maintenance (OAM)|          |
   |           | Message Mapping [PW-Map]             |          |
   +-----------+--------------------------------------+----------+
   |OWAMP and  | A One-way Active Measurement Protocol| RFC 4656 |
   |TWAMP      | [OWAMP]                              |          |
   |           +--------------------------------------+----------+
   |           | A Two-Way Active Measurement Protocol| RFC 5357 |
   |           | [TWAMP]                              |          |
   |           +--------------------------------------+----------+
   |           | Framework for IP Performance Metrics | RFC 2330 |
   |           | [IPPM-FW]                            |          |
   |           +--------------------------------------+----------+
   |           | IPPM Metrics for Measuring           | RFC 2678 |
   |           | Connectivity [IPPM-Con]              |          |
   |           +--------------------------------------+----------+
   |           | A One-way Delay Metric for IPPM      | RFC 2679 |


Mizrahi, et al.        Expires April 21, 2014                [Page 43]
Internet-Draft          Overview of OAM Tools             October 2013


   |           | [IPPM-1DM]                           |          |
   |           +--------------------------------------+----------+
   |           | A One-way Packet Loss Metric for IPPM| RFC 2680 |
   |           | [IPPM-1LM]                           |          |
   |           +--------------------------------------+----------+
   |           | A Round-trip Delay Metric for IPPM   | RFC 2681 |
   |           | [IPPM-2DM]                           |          |
   |           +--------------------------------------+----------+
   |           | Packet Reordering Metrics            | RFC 4737 |
   |           | [Reorder]                            |          |
   |           +--------------------------------------+----------+
   |           | A One-Way Packet Duplication Metric  | RFC 5560 |
   |           | [Dup]                                |          |
   +-----------+--------------------------------------+----------+
   |TRILL OAM  | Requirements for Operations,         | RFC 6905 |
   |           | Administration, and Maintenance (OAM)|          |
   |           | in Transparent Interconnection of    |          |
   |           | Lots of Links (TRILL)                |          |
   +-----------+--------------------------------------+----------+
                 Table 5 Summary of IETF OAM Related RFCs

A.2. List of Selected Non-IETF OAM Documents

   In addition to the OAM tools defined by the IETF, the IEEE and ITU-T
   have also defined various OAM tools that focus on Ethernet, and
   various other transport network environments. These various tools,
   defined by the three standard organizations, are often tightly
   coupled, and have had a mutual effect on each other. The ITU-T and
   IETF have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711] and
   [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to
   some extent linked to IETF OAM tools listed above and are mentioned
   here only as reference material:

   o OAM tools for Layer 2 have been defined by the ITU-T in
      [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802.1Q] . The IEEE
      802.3 standard defines OAM for one-hop Ethernet links
      [IEEE802.3ah].

   o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and
      MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2].

   It should be noted that these non-IETF documents deal in many cases
   with OAM functions below the IP layer (Layer 2, Layer 2.5) and in



Mizrahi, et al.        Expires April 21, 2014                [Page 44]
Internet-Draft          Overview of OAM Tools             October 2013


   some cases operators use a multi-layered OAM approach, which is a
   function of the way their networks are designed.

   Table 6 summarizes some of the main OAM standards published by non-
   IETF standard organizations. This document focuses on IETF OAM
   standards, but these non-IETF standards are referenced in this
   document where relevant.

   +-----------+--------------------------------------+---------------+
   |           | Title                                |Standard/Draft |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | Operation & Maintenance mechanism    | ITU-T Y.1711  |
   |MPLS OAM   | for MPLS networks [ITU-T-Y1711]      |               |
   |           +--------------------------------------+---------------+
   |           | Assignment of the 'OAM Alert Label'  | RFC 3429      |
   |           | for Multiprotocol Label Switching    |               |
   |           | Architecture (MPLS) Operation and    |               |
   |           | Maintenance (OAM) Functions          |               |
   |           | [OAM-Label]                          |               |
   |           |                                      |               |
   |           |  Note: although this is an IETF      |               |
   |           |  document, it is listed as one of the|               |
   |           |  non-IETF OAM standards, since it    |               |
   |           |  was defined as a complementary part |               |
   |           |  of ITU-T Y.1711.                    |               |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | Operations, administration and       |ITU-T G.8113.2 |
   |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP   |               |
   |           | networks using the tools defined for |               |
   |           | MPLS [ITU-G8113.2]                   |               |
   |           |                                      |               |
   |           |  Note: this document describes the   |               |
   |           |  OAM toolset defined by the IETF for |               |
   |           |  MPLS-TP, whereas ITU-T G.8113.1     |               |
   |           |  describes the OAM toolset defined   |               |
   |           |  by the ITU-T.                       |               |
   |           +--------------------------------------+---------------+
   |           | Operations, Administration and       |ITU-T G.8113.1 |
   |           | Maintenance mechanism for MPLS-TP in |               |
   |           | Packet Transport Network (PTN)       |               |
   |           +--------------------------------------+---------------+
   |           | Allocation of a Generic Associated   | RFC 6671      |


Mizrahi, et al.        Expires April 21, 2014                [Page 45]
Internet-Draft          Overview of OAM Tools             October 2013


   |           | Channel Type for ITU-T MPLS Transport|               |
   |           | Profile Operation, Maintenance, and  |               |
   |           | Administration (MPLS-TP OAM)         |               |
   |           | [ITU-T-CT]                           |               |
   |           |                                      |               |
   |           |  Note: although this is an IETF      |               |
   |           |  document, it is listed as one of the|               |
   |           |  non-IETF OAM standards, since it    |               |
   |           |  was defined as a complementary part |               |
   |           |  of ITU-T G.8113.1.                  |               |
   +-----------+--------------------------------------+---------------+
   |ITU-T      | OAM Functions and Mechanisms for     | ITU-T Y.1731  |
   |Ethernet   | Ethernet-based Networks              |               |
   |OAM        | [ITU-T-Y1731]                        |               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Connectivity Fault Management        | IEEE 802.1ag  |
   |CFM        | [IEEE802.1Q]                         |               |
   |           |                                      |               |
   |           |  Note: CFM was originally published  |               |
   |           |  as IEEE 802.1ag, but is now         |               |
   |           |  incorporated in the 802.1Q standard.|               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Management of Data Driven and Data   | IEEE 802.1ag  |
   |DDCFM      | Dependent Connectivity Faults        |               |
   |           | [IEEE802.1Q]                         |               |
   |           |                                      |               |
   |           |  Note: DDCFM was originally published|               |
   |           |  as IEEE 802.1Qaw, but is now        |               |
   |           |  incorporated in the 802.1Q standard.|               |
   +-----------+--------------------------------------+---------------+
   |IEEE       | Media Access Control Parameters,     | IEEE 802.3ah  |
   |802.3      | Physical Layers, and Management      |               |
   |link level | Parameters for Subscriber Access     |               |
   |OAM        | Networks [IEEE802.3ah]               |               |
   |           |                                      |               |
   |           |  Note: link level OAM was originally |               |
   |           |  defined in IEEE 802.3ah, and is now |               |
   |           |  incorporated in the 802.3 standard. |               |
   +-----------+--------------------------------------+---------------+
         Table 6 Non-IETF OAM Standards Mentioned in this Document



Mizrahi, et al.        Expires April 21, 2014                [Page 46]
Internet-Draft          Overview of OAM Tools             October 2013




Authors' Addresses

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692
   Israel

   Email: talmi@marvell.com


   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Email: nurit.sprecher@nsn.com


   Elisa Bellagamba
   Ericsson
   6 Farogatan St.
   Stockholm,   164 40
   Sweden

   Phone: +46 761440785
   Email: elisa.bellagamba@ericsson.com


   Yaacov Weingarten
   34 Hagefen St.
   Karnei Shomron,   4485500
   Israel

   Email: wyaacov@gmail.com










Mizrahi, et al.        Expires April 21, 2014                [Page 47]



On 17/10/2013 22:46, Tal Mizrahi wrote:

Hi Benoit, Stewart,

 

Thanks for your effort to review the draft and for the comments you sent. We highly appreciate it, and it has helped to significantly improve the document.

 

We believe we resolved the most significant issue, which is to accurately and clearly define the scope and target audience, and to align the scope description to the actual content of the document.

The main purpose of this mail is to make sure we resolved your comments before we re-submit the draft and proceed with the request for feedback from the OPSA WG and the routing area WG.

 

Here is a list of modifications we made following your comments:

1.       The most significant comment, from both Stewart and Benoit was about aligning expectations between the content of the document and the goal, target audience, and scope:
We clarified the *scope* and the *target audience* in the abstract and at the very beginning of the Introduction.
Scope: about 2 years ago we had a lot of discussions about the scope of the document, and based on Ron Bonica’s advice we defined the current scope. Mainly, as Ron said, we had to draw the line *somewhere* and no matter where we drew the line someone would have objections. One of the things we decided then, based on feedback from Stewart/Sasha was to removed descriptions of ITU-T and IEEE OAM protocols.
I agree with both your comments that the scope was not crystal clear so far, and thus we have clarified the scope in the current draft:

-          The draft does not include *all* OAM activity in the IETF, but only IP unicast, MPLS, pseudowires, MPLS-TP, and TRILL.

-          Focus on data-plane.

2.       Following a comment from Stewart: we added a subsection about connection oriented vs. connectionless technologies, and point to point vs point to multipoint.

3.       Following a comment from Stewart, Benoit: We clarified the text that explains the scope of OAM (in the introduction) based on RFC 6291.

4.       Following a comment from Benoit: We added an explicit quote of the OAM definition from RFC 6291.

5.       Following a comment from Stewart, Benoit: We changed the definitions of control plane and data plane with Stewart’s help.

6.       Following a comment from Stewart: we changed the definitions of OAM functions and OAM tools.
Another comment from Stewart was that the terms ‘tool’ and ‘mechanism’ were used interchangeably in an inaccurate way. We replaced all the potentially confusing instances of ‘mechanism’ by ‘tool’.

7.       Following a comment from Benoit: you have commented about the term ‘transport technology’. We completely removed this term from the document.

 

We are sending a word document with tracked changes compared to the draft we sent you on the 17th of September.

We plan to submit an updated draft before the 21st of October deadline.

 

We will highly appreciate your comments.

 

Thanks,

Tal.

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, October 08, 2013 4:46 PM
To: draft-ietf-opsawg-oam-overview@tools.ietf.org; Scott O. Bradner; opsawg-chairs@tools.ietf.org; Joel jaeggli
Cc: Stewart Bryant; Adrian Farrel; me
Subject: draft-ietf-opsawg-oam-overview status

 

Dear all,

Tal asked me to discuss the draft-ietf-opsawg-oam-overview draft status.

For the sake of transparency, let me share my message with everybody.
I copied the document authors, Scott Bradner as the document shepherd, the OPSAWG-chairs, and the routing ADs (Stewart and Adrian)

Stewart, as the last DISCUSS holder (btw 2011) and Tal had a conf. call
    Five or six minor issues
    Two major issues:
        1. Huge task, large scope going over all IETF protocols
        2. Must speak with your responsible AD

I sent back this document to the WG. See http://www.ietf.org/mail-archive/web/opsawg/current/msg02931.html

Tal and I discussed:
- The comparison with RFC6632, which is a overview with claear objectives and target audience
   The OAM document is somehow the companion document to RFC 6632

- This document has got a  bigger task that the authors apparently thought it would be

- The document goal and audience are not clearly defined (actually it's spread all over the place)
  Who will want to be reading this document? What for?

Section 1 Introduction:
   This document summarizes the OAM tools and mechanisms defined in the
   IETF. This document focuses on data plane OAM tools. Hence, control
   and management aspects of OAM are outside the scope of this document.  

Section 1.2 Target Audience is key
Section 1.3 OAM-related Work in the IETF 

   This memo provides an overview of the different sets of OAM
   mechanisms defined by the IETF. The set of OAM mechanisms described
   in this memo are applicable to IP unicast, MPLS, pseudowires, MPLS
   for the transport profile (MPLS-TP), and TRILL. While OAM mechanisms
   that are applicable to other technologies exist, they are beyond the
   scope of this memo.

Why not others?
Section 1.4 Focusing on Data Plane OAM Tools 

   The considerations of the control plane maintenance tools and the
   functionality of the management plane are out of scope for this
   document, which concentrates on presenting the data plane tools that
   are used for OAM.

You see, it's not clear from the beginning (the abstract) what the focus is, who is the audience, and what the document goals are: there are pieces of it all over the place.

 The overview of all OAM protocols in the IETF is a moving target.
 You need a lot of energy to finish this document, and you must be quick (moving target)

- Do you want to classify the different OAM techniques as we did for RFC 6632, based on different criteria s?  We had a clear audience in mind when creating RFC 6632. For example, if you look which protocol(s) might be of interest to you, see

     A.1. Protocols Classified by Standards Maturity in the IETF .....77
     A.2. Protocols Matched to Management Tasks ......................79
     A.3. Push versus Pull Mechanism .................................80
     A.4. Passive versus Active Monitoring ...........................80
     A.5. Supported Data Model Types and Their Extensibility  ........81



- The advice is to present during the OPSAWG to get some feedback regarding the direction (focus, document goal, and target audience) for this document: reduce scope versus cover all the OAM features in the IETF?
Also, the same talk should be done at the Routing Area (Stewart agreed to find some time for it). Actually, the feedback from the routing guys is even more important, as they are the guys specifying OAM techniques. So they will be the readers for this document (I guess)
   

SOME MORE FEEDBACK

 
                     +--------------+------------+
                     | Category     | Transport  |
                     |              | Technology |
                     +--------------+------------+
                     |IP Ping       | IPv4/IPv6  |
                     +--------------+------------+
                     |IP Traceroute | IPv4/IPv6  |
                     +--------------+------------+
                     |BFD           | generic    |
                     +--------------+------------+
                     |MPLS OAM      | MPLS       |
                     +--------------+------------+
                     |MPLS-TP OAM   | MPLS-TP    |
                     +--------------+------------+
                     |Pseudowire OAM| Pseudowires|
                     +--------------+------------+
                     |OWAMP and     | IPv4/IPv6  |
                     |TWAMP         |            |
                     +--------------+------------+
                     |TRILL OAM     | TRILL      |
                     +--------------+------------+
              Table 1 Categories of OAM-related IETF Documents

You should define what you mean by transport technology. It's not L4

- Terminology
 
It's key to have an OAM definition.
It's true that you mentioned earlier:

   There are several different interpretations to the "OAM" acronym.
   This document refers to Operations, Administration and Maintenance,
   as recommended in [OAM-Def].

However, cut and paste the definition.

Same remark for some other definitions. For example

   Control Plane
 
   The Control Plane, as described in [Cont], is generally described as
   the hardware and software components for handling packets destined to
   the device itself as well as building and sending packets originated
   locally on the device.

If it's a described in [cont], then copy it verbatim

- It's good that a single document contains the definitions of control plane, data plane and management plane.
 
- I stopped my review at the end of section 2

Regards, Benoit


    



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

--------------070707050609030101080201--