From dromasca@avaya.com Wed May 1 02:01:04 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 856FB21F8EBE for ; Wed, 1 May 2013 02:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 gipBrOLqdVJF for ; Wed, 1 May 2013 02:00:58 -0700 (PDT) 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 BB68221F8EBD for ; Wed, 1 May 2013 02:00:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAK3YgFGHCzI1/2dsb2JhbABTgmYhv0x/FnSCHwEBAQEDEgsdPwwEAgEIDQQEAQEBChQJBzIUCQgCBA4FCAwOh2oBo12bCheOaDEHBoJpYQOTV4oFineDDYIn X-IronPort-AV: E=Sophos;i="4.87,587,1363147200"; d="scan'208";a="7488753" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2013 05:00:56 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 May 2013 04:57:33 -0400 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.02.0328.009; Wed, 1 May 2013 05:00:54 -0400 From: "Romascanu, Dan (Dan)" To: Melinda Shore , "George, Wes" Thread-Topic: [OPSAWG] Call for adoption, two capwap-related documents Thread-Index: AQHORcZzf1wSc0his0C82CBTDnDVhZjvUoYAgAAf4ICAAJPKYA== Date: Wed, 1 May 2013 09:00:53 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0D987D@AZ-FFEXMB04.global.avaya.com> References: <5166CA78.1070504@gmail.com> <2671C6CDFBB59E47B64C10B3E0BD59230430C292B2@PRVPEXVS15.corp.twcable.com> <517FFC51.1030704@gmail.com> <2671C6CDFBB59E47B64C10B3E0BD59230430C29F4E@PRVPEXVS15.corp.twcable.com> <51802301.2080208@gmail.com> In-Reply-To: <51802301.2080208@gmail.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for adoption, two capwap-related documents 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, 01 May 2013 09:01:04 -0000 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Tuesday, April 30, 2013 11:01 PM > To: George, Wes > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Call for adoption, two capwap-related documents >=20 > On 4/30/13 10:07 AM, George, Wes wrote: > > I guess someone needs to decide if this is truly considered a > > small-scale extension and enough of the former CAPWAP participants are > > involved in OpsAWG such that we get the right level of review. If the > > answer to those questions is yes, I'd be fine with adopting this one. >=20 > Well, I think the "someone" is us as a group. Taking off my chair hat, > I think that this is pretty clearly not a major revision of capwap and > would not merit a 'bis' > document. There's also been a considerable amount of outreach to former > capwap participants and to the IEEE 802.11n community, which may have > not been visible to working group participants. >=20 > Melinda >=20 [[DR]] All the above is correct. I also believe that the type of extensions= defined by the proposed work fits within the charter of OPSAWG, with suffi= cient support. And here is the issue - and to explain my concern I need to = share some of my experience from the time I was the shepherding AD for CAPW= AP. This WG started in big rooms at the BOF phase, continued in reasonably-= sized rooms when the work started, and ended in small rooms, with a handful= of active participants in the editing of the latest documents. Out of the = people expressing interest to do or supporting this new work there is I saw= (and I may have missed messages) only one of the co-authors of RFC 5415 (D= orothy Stanley - who is also the liaison of IEEE 802.11 to the IETF). In or= der to avoid the situation of having a work approved but not enough hands a= nd eyes to do it, the chairs need to make sure that the folks who expressed= support are also willing and have the time to contribute as editors, revie= wers and implementers.=20 Regards, Dan =20 From denghui02@gmail.com Wed May 1 03:12:15 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 3567D21F8C08 for ; Wed, 1 May 2013 03:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[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 p3qxdnT+fd7g for ; Wed, 1 May 2013 03:12:07 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C821F8BE9 for ; Wed, 1 May 2013 03:12:06 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id x7so798897qeu.20 for ; Wed, 01 May 2013 03:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LSQw+2iI3Fhl7liXgmb9Rdyjll2bNKr/yPZUc8nyFbg=; b=tTNwesbDGzJpzT8fRPpqdXiQTKOEVCPfuIZKsgqrnjiGFTeyV4VN8QLs/rnoc76q/O Ban/njO+Z6hN9/Jepk6DOu852Pez4WZ9Sy3P+7i4AjhupnASWy5+beqjjL8o9q6S793a exSvKc4wgscXbIvubwXG0omuzzDq2rFKvRY5PVGevOhm06jdX8ggpZVtyqd/krnbLPZt 1n3txW/zDOgtNV6rNRvo5gC2djRAeA+c97XuXGAGTK27N1tOVYoHw0dbffiVp1Nr3jg1 6FibxyqGaPt3KtOZJPwWQSEWdnrJV8IgdMwzvaqsAlxTrG4vmI+LJ6l+rCol1jU/BRgO /9VQ== MIME-Version: 1.0 X-Received: by 10.229.155.201 with SMTP id t9mr702608qcw.155.1367403126163; Wed, 01 May 2013 03:12:06 -0700 (PDT) Received: by 10.49.103.134 with HTTP; Wed, 1 May 2013 03:12:05 -0700 (PDT) In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA0D987D@AZ-FFEXMB04.global.avaya.com> References: <5166CA78.1070504@gmail.com> <2671C6CDFBB59E47B64C10B3E0BD59230430C292B2@PRVPEXVS15.corp.twcable.com> <517FFC51.1030704@gmail.com> <2671C6CDFBB59E47B64C10B3E0BD59230430C29F4E@PRVPEXVS15.corp.twcable.com> <51802301.2080208@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA0D987D@AZ-FFEXMB04.global.avaya.com> Date: Wed, 1 May 2013 18:12:05 +0800 Message-ID: From: Hui Deng To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=f46d0447890d99ac1b04dba559c2 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Call for adoption, two capwap-related documents 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, 01 May 2013 10:12:15 -0000 --f46d0447890d99ac1b04dba559c2 Content-Type: text/plain; charset=ISO-8859-1 I agreed with what Dan said here, it is sad that the protocol invented by IETF hasn't been widely supported before. Here I just want to mention that quite recently, SP wifi (Carrier grade wifi) has re-rised up again in WBA/WFA/IEEE. and today there are three chiense operators are and planning to deploy CAPWAP solution which is IETF standard protocol, China Mobile has more than 4 million APs deployed, this number will continue to grow, almost all of them are based on capwap, China Telecom an China Unicom also has more than millions AP using capwap. This work has also got two other quite large opeartor's support. This could prove IETF's work is standard based and benefit for the Internet. Time is very urgent to support standard work other than propritary solution. I have seen many vendors who is implementing capwap showing their support in the ML. As Dan's talk here, we respect Dorothy's pioneer work, that's the reason why we follow her advice and have further talk with her about EAP's draft to make better understanding, not rush for the immeidately adoption, we will continue work with her about this document. Thanks a lot for your advice. Best regards, -Hui 2013/5/1 Romascanu, Dan (Dan) > > > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > > Of Melinda Shore > > Sent: Tuesday, April 30, 2013 11:01 PM > > To: George, Wes > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] Call for adoption, two capwap-related documents > > > > On 4/30/13 10:07 AM, George, Wes wrote: > > > I guess someone needs to decide if this is truly considered a > > > small-scale extension and enough of the former CAPWAP participants are > > > involved in OpsAWG such that we get the right level of review. If the > > > answer to those questions is yes, I'd be fine with adopting this one. > > > > Well, I think the "someone" is us as a group. Taking off my chair hat, > > I think that this is pretty clearly not a major revision of capwap and > > would not merit a 'bis' > > document. There's also been a considerable amount of outreach to former > > capwap participants and to the IEEE 802.11n community, which may have > > not been visible to working group participants. > > > > Melinda > > > > [[DR]] All the above is correct. I also believe that the type of > extensions defined by the proposed work fits within the charter of OPSAWG, > with sufficient support. And here is the issue - and to explain my concern > I need to share some of my experience from the time I was the shepherding > AD for CAPWAP. This WG started in big rooms at the BOF phase, continued in > reasonably-sized rooms when the work started, and ended in small rooms, > with a handful of active participants in the editing of the latest > documents. Out of the people expressing interest to do or supporting this > new work there is I saw (and I may have missed messages) only one of the > co-authors of RFC 5415 (Dorothy Stanley - who is also the liaison of IEEE > 802.11 to the IETF). In order to avoid the situation of having a work > approved but not enough hands and eyes to do it, the chairs need to make > sure that the folks who expressed support are also willing and have the > time to contribute as editors, reviewers and implem > enters. > > Regards, > > Dan > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > --f46d0447890d99ac1b04dba559c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agreed with what Dan said here, it is sad that the = protocol invented by IETF hasn't been widely supported before.
=A0
Here I just want to mention that quite recently, SP wifi (C= arrier grade wifi) has re-rised up again in WBA/WFA/IEEE. and today there a= re three chiense operators are and planning to deploy CAPWAP solution which= is IETF standard protocol, China Mobile has more than 4 million APs deploy= ed, this number will continue to grow, almost all of them are based on capw= ap, China Telecom an China Unicom also has more than millions AP using capw= ap. This work has also got two other quite large opeartor's support. Th= is could prove IETF's work is standard based and benefit for the Intern= et. Time is very urgent to support standard work other than propritary solu= tion. I have seen many vendors who is implementing capwap showing their sup= port in the ML.
=A0
As Dan's talk here, we respect Dorothy's pioneer= work, that's the reason why=A0we follow her advice and have further ta= lk with her about EAP's draft to make better understanding, not rush fo= r the immeidately adoption, we will continue work with her about this docum= ent.
=A0
Thanks a lot for your advice.
Best regards,
=A0
-Hui


2013/5/1 Romascanu, Dan (Dan) &l= t;dromasca@avaya.co= m>




> -----Original Message-----
> From: opsawg-bounces@ietf.o= rg [mailto:opsawg-bounces@ie= tf.org] On Behalf
> Of Melinda Shore
> Sent: Tuesday, April 30, 2013 11:01 PM
> To: George, Wes
> Cc: opsawg@ietf.org
> Subject: Re: [OPSAWG] Call for adoption, two capwap-related documents<= br> >
> On 4/30/13 10:07 AM, George, Wes wrote:
> > I guess someone needs to decide if this is truly considered a
> > small-scale extension and enough of the former CAPWAP participant= s are
> > involved in OpsAWG such that we get the right level of review. If= the
> > answer to those questions is yes, I'd be fine with adopting t= his one.
>
> Well, I think the "someone" is us as a group. =A0Taking off = my chair hat,
> I think that this is pretty clearly not a major revision of capwap and=
> would not merit a 'bis'
> document. =A0There's also been a considerable amount of outreach t= o former
> capwap participants and to the IEEE 802.11n community, which may have<= br> > not been visible to working group participants.
>
> Melinda
>

[[DR]] All the above is correct. I also believe that the type of exte= nsions defined by the proposed work fits within the charter of OPSAWG, with= sufficient support. And here is the issue - and to explain my concern I ne= ed to share some of my experience from the time I was the shepherding AD fo= r CAPWAP. This WG started in big rooms at the BOF phase, continued in reaso= nably-sized rooms when the work started, and ended in small rooms, with a h= andful of active participants in the editing of the latest documents. Out o= f the people expressing interest to do or supporting this new work there is= I saw (and I may have missed messages) only one of the co-authors of RFC 5= 415 (Dorothy Stanley - who is also the liaison of IEEE 802.11 to the IETF).= In order to avoid the situation of having a work approved but not enough h= ands and eyes to do it, the chairs need to make sure that the folks who exp= ressed support are also willing and have the time to contribute as editors,= reviewers and implem
=A0enters.

Regards,

Dan

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

--f46d0447890d99ac1b04dba559c2-- From bclaise@cisco.com Thu May 2 12:22: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 274E221F8E4E for ; Thu, 2 May 2013 12:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 uCV3p80Fi6Ng for ; Thu, 2 May 2013 12:22:38 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2821F8EC6 for ; Thu, 2 May 2013 12:22:34 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r42JMT4t004889; Thu, 2 May 2013 21:22:29 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r42JLrsX029829; Thu, 2 May 2013 21:22:09 +0200 (CEST) Message-ID: <5182BCD1.4030209@cisco.com> Date: Thu, 02 May 2013 21:21:53 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Edward Beili Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: [OPSAWG] draft-ietf-opsawg-rfc5066bis: status 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, 02 May 2013 19:22:42 -0000 Ed, We just had an IEEE/IESG coordination call, and we discussed draft-ietf-opsawg-rfc5066bis. The situation is that IEEE 802.3.1 draft ballot ended 2 days ago. The IEEE document currently contains a pointer to the draft-ietf-opsawg-rfc5066bis draft. The IEEE document should be finalized by mid June. If this draft-ietf-opsawg-rfc5066bis would be a RFC by this time, the pointer will be replaced by the correct RFC. This is the ideal situation. So there is some sort of urgency publishing this RFC5066bis document. Regards, Benoit Below is some background information. Regards, Benoit 7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3 7.1. Description In the transition process between the IETF and the IEEE the following documents were taken over by IEEE 802.3: RFC 2108 - Ethernet Repeater Devices RFC 3621 - Power Ethernet MIB RFC 3635 - Ethernet-like Interface Types RFC 3637 - Ethernet WAN Interface Sublayer RFC 4836 - Ethernet Medium Attachment Units (MAUs) RFC 4837 - Ethernet Passive Optical Networks (EPON) RFC 4878 - Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF proposed to continue to be maintained by the IETF in a separate new document The IEEE 802.3 proposed to create an RFC that documents the issues related to the transition of the Ethernet MIB work to IEEE 802.3 similar to RFC 4663 which documents the transition of the Bridge MIB work to IEEE 802.1 - The OPSAWG was rechartered in October 2012 to include the two relevant documents - Status 4/30/13: draft-ietf-opsawg-rfc5066bis received a number of substantial comments in the OPSAWG review which resulted in the need for substantial edits, revised version is still in progress. The second I-D was not submitted yet. The IEEE 802.3.1 completes Recirculation Sponsor Ballot on 4/30. Dan submitted an Approve ballot, the document is expected to be released in June, probably with reference to the Internet-Draft. 7.2. Relevant Documents - IEEE 802.3.1 Draft - http://datatracker.ietf.org/wg/opsawg/charter/ - https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ 7.3. Owners - Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE 802.3) 7.4. Action Items - Dan Romascanu will enter the Sponsor Ballot pool and enter a comment suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB from their document and refer the IF-CAP-STACK-MIB instead - in progress, Sponsor Ballot started, comments need to be submitted until 1/13 - Done - Ed Beili will write an I-D targeting standards track that obsoletes RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording emphasizing the generic nature of this module - now on the OPSAWG charter, CRITICAL TIMING issue initial I-D to be submitted by 12/28, to become an OPSAWG document before 1/25 - done - Ed Beili will write an I-D targeting informational RFC, similar to RFC 4663, with: a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 b) A table mapping the old IETF MIB names with the corresponding new IEEE ones c) Clarifications/rules on the IETF-IEEE interactions, mailing lists, reviews d) Clarifications on the intellectual property considerations The first version will be posted by Ed. Then Dan Romascanu and Howard Frazier will add IETF-IEEE interactions chapter. - Now on OPSAWG charter - Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB document, to explain the situation - Done - Dan Romascanu will submit an Approve Ballot in the Recirculation Sponsor Ballot (if all related issues are addressed) - Done From internet-drafts@ietf.org Thu May 2 22:35:52 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 6F10D21F9323; Thu, 2 May 2013 22:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.145, 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 N6Hp4pVBEiQr; Thu, 2 May 2013 22:35:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C09321F85C3; Thu, 2 May 2013 22:35:51 -0700 (PDT) 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.44.p4 Message-ID: <20130503053551.14141.50405.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2013 22:35:51 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-02.txt 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, 03 May 2013 05:35:52 -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-02.txt Pages : 7 Date : 2013-05-02 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 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsawg-rfc5066bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dromasca@avaya.com Mon May 6 04:58:30 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 ED63121F85E8 for ; Mon, 6 May 2013 04:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 76eqiEglPi0v for ; Mon, 6 May 2013 04:58:25 -0700 (PDT) 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 1569F21F84A6 for ; Mon, 6 May 2013 04:58:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAHmZh1HGmAcF/2dsb2JhbABQgmYhN78CgQUWdIIfAQEBAQMSKDQCCQwEAgEIDQQEAQELFAkHMhQJCAIEAQ0FCBqHagELpHGaGxeNZByBADEHBoJsYQOYVIUUinqDDYIn X-IronPort-AV: E=Sophos;i="4.87,621,1363147200"; d="scan'208";a="8077731" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 May 2013 07:58:22 -0400 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 May 2013 07:54:04 -0400 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.02.0328.009; Mon, 6 May 2013 07:58:20 -0400 From: "Romascanu, Dan (Dan)" To: Edward Beili , Benoit Claise Thread-Topic: draft-ietf-opsawg-rfc5066bis: status Thread-Index: AQHOR2pmqLDT4UWdd0mffl8n2EDP/pjzNzWAgATbdfA= Date: Mon, 6 May 2013 11:58:19 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1625B0@AZ-FFEXMB04.global.avaya.com> References: <5182BCD1.4030209@cisco.com> <4087887712E5C648B9F72BB9D912FD4602AC8B851DC1@il-mail07.actelis.net> In-Reply-To: <4087887712E5C648B9F72BB9D912FD4602AC8B851DC1@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , "hfrazier@broadcom.com" Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis: status 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, 06 May 2013 11:58:31 -0000 Hi Ed, I believe that it's better for the IEEE 802.3.1 to point to rfc5066bis beca= use of the updated Security Considerations section.=20 Thanks and Regards, Dan > -----Original Message----- > From: Edward Beili [mailto:EdwardB@actelis.com] > Sent: Friday, May 03, 2013 8:46 AM > To: Benoit Claise > Cc: opsawg@ietf.org; Romascanu, Dan (Dan) > Subject: RE: draft-ietf-opsawg-rfc5066bis: status >=20 > Benoit, > I've just submitted the next draft of the rfc5066bis, my apologies for > the delay. >=20 > Please note that we have agreed to remove the IF-CAP-STACK-MIB from the > draft, leaving it defined in the RFC 5066, which means that the 802.3.1 > shall be pointing to RFC 5066 as the source for IF-CAP-STACK-MIB. >=20 > Regards, > -E. >=20 > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Thursday, May 02, 2013 22:22 > To: Edward Beili > Cc: opsawg@ietf.org; Romascanu, Dan (Dan) > Subject: draft-ietf-opsawg-rfc5066bis: status >=20 > Ed, >=20 > We just had an IEEE/IESG coordination call, and we discussed draft-ietf- > opsawg-rfc5066bis. >=20 > The situation is that IEEE 802.3.1 draft ballot ended 2 days ago. > The IEEE document currently contains a pointer to the draft-ietf-opsawg- > rfc5066bis draft. > The IEEE document should be finalized by mid June. If this draft-ietf- > opsawg-rfc5066bis would be a RFC by this time, the pointer will be > replaced by the correct RFC. This is the ideal situation. > So there is some sort of urgency publishing this RFC5066bis document. >=20 > Regards, Benoit >=20 >=20 > Below is some background information. >=20 > Regards, Benoit >=20 > 7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3 7.1. Description In the > transition process between the IETF and the IEEE the following documents > were taken over by IEEE 802.3: > RFC 2108 - Ethernet Repeater Devices > RFC 3621 - Power Ethernet MIB > RFC 3635 - Ethernet-like Interface Types RFC 3637 - Ethernet WAN > Interface Sublayer RFC 4836 - Ethernet Medium Attachment Units (MAUs) > RFC 4837 - Ethernet Passive Optical Networks (EPON) RFC 4878 - > Operations, Administration, and Maintenance (OAM) Functions on Ethernet- > Like Interfaces RFC 5066 - Ethernet in the First Mile Copper (EFMCu) > Interfaces MIB The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF > proposed to continue to be maintained by the IETF in a separate new > document The IEEE 802.3 proposed to create an RFC that documents the > issues related to the transition of the Ethernet MIB work to IEEE 802.3 > similar to RFC 4663 which documents the transition of the Bridge MIB > work to IEEE 802.1 > - The OPSAWG was rechartered in October 2012 to include the two relevant > documents > - Status 4/30/13: draft-ietf-opsawg-rfc5066bis received a number of > substantial comments in the OPSAWG review which resulted in the need for > substantial edits, revised version is still in progress. The second I-D > was not submitted yet. The IEEE 802.3.1 completes Recirculation Sponsor > Ballot on 4/30. Dan submitted an Approve ballot, the document is > expected to be released in June, probably with reference to the > Internet-Draft. >=20 > 7.2. Relevant Documents > - IEEE 802.3.1 Draft > - http://datatracker.ietf.org/wg/opsawg/charter/ > - https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ >=20 > 7.3. Owners > - Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE > 802.3) >=20 > 7.4. Action Items > - Dan Romascanu will enter the Sponsor Ballot pool and enter a comment > suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB > from their document and refer the IF-CAP-STACK-MIB instead - in > progress, Sponsor Ballot started, comments need to be submitted until > 1/13 - Done > - Ed Beili will write an I-D targeting standards track that obsoletes > RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording > emphasizing the generic nature of this module - now on the OPSAWG > charter, CRITICAL TIMING issue initial I-D to be submitted by 12/28, to > become an OPSAWG document before 1/25 - done > - Ed Beili will write an I-D targeting informational RFC, similar to RFC > 4663, with: > a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 > b) A table mapping the old IETF MIB names with the corresponding new > IEEE ones > c) Clarifications/rules on the IETF-IEEE interactions, mailing lists, > reviews > d) Clarifications on the intellectual property considerations The first > version will be posted by Ed. Then Dan Romascanu and Howard Frazier will > add IETF-IEEE interactions chapter. - Now on OPSAWG charter > - Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB > document, to explain the situation - Done > - Dan Romascanu will submit an Approve Ballot in the Recirculation > Sponsor Ballot (if all related issues are addressed) - Done >=20 >=20 From dromasca@avaya.com Mon May 6 05:17: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 C2C3B21F8F11 for ; Mon, 6 May 2013 05:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 writBngw0IBp for ; Mon, 6 May 2013 05:17:30 -0700 (PDT) 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 B3A6321F8F0C for ; Mon, 6 May 2013 05:17:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFACueh1GHCzI1/2dsb2JhbABQgmYhN78CgQUWdIIfAQEBAQMBAQEPKDQCCQwEAgEIDQQEAQELFAkHJwsUCQgCBAENBQgah2oBC6R6mhoXjWQcgQAxBwaCbGEDmFSFFIp6gw2CJw X-IronPort-AV: E=Sophos;i="4.87,621,1363147200"; d="scan'208";a="8081513" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 May 2013 08:17:27 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 May 2013 08:08:51 -0400 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.02.0328.009; Mon, 6 May 2013 08:12:22 -0400 From: "Romascanu, Dan (Dan)" To: Edward Beili , Benoit Claise Thread-Topic: draft-ietf-opsawg-rfc5066bis: status Thread-Index: AQHOR2pmqLDT4UWdd0mffl8n2EDP/pjzNzWAgATbdfCAAAQA0A== Date: Mon, 6 May 2013 12:12:21 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA162649@AZ-FFEXMB04.global.avaya.com> References: <5182BCD1.4030209@cisco.com> <4087887712E5C648B9F72BB9D912FD4602AC8B851DC1@il-mail07.actelis.net> <9904FB1B0159DA42B0B887B7FA8119CA1625B0@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1625B0@AZ-FFEXMB04.global.avaya.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 Cc: "opsawg@ietf.org" , "hfrazier@broadcom.com" Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis: status 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, 06 May 2013 12:17:35 -0000 A couple of more quick comments:=20 - [rfc5066] must be Normative Reference - there is a typo in the document header (the word Interfaces is mis-spelle= d) Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Romascanu, Dan (Dan) > Sent: Monday, May 06, 2013 2:58 PM > To: Edward Beili; Benoit Claise > Cc: opsawg@ietf.org; hfrazier@broadcom.com > Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis: status >=20 > Hi Ed, >=20 > I believe that it's better for the IEEE 802.3.1 to point to rfc5066bis > because of the updated Security Considerations section. >=20 > Thanks and Regards, >=20 > Dan >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Edward Beili [mailto:EdwardB@actelis.com] > > Sent: Friday, May 03, 2013 8:46 AM > > To: Benoit Claise > > Cc: opsawg@ietf.org; Romascanu, Dan (Dan) > > Subject: RE: draft-ietf-opsawg-rfc5066bis: status > > > > Benoit, > > I've just submitted the next draft of the rfc5066bis, my apologies for > > the delay. > > > > Please note that we have agreed to remove the IF-CAP-STACK-MIB from > > the draft, leaving it defined in the RFC 5066, which means that the > > 802.3.1 shall be pointing to RFC 5066 as the source for IF-CAP-STACK- > MIB. > > > > Regards, > > -E. > > > > -----Original Message----- > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Thursday, May 02, 2013 22:22 > > To: Edward Beili > > Cc: opsawg@ietf.org; Romascanu, Dan (Dan) > > Subject: draft-ietf-opsawg-rfc5066bis: status > > > > Ed, > > > > We just had an IEEE/IESG coordination call, and we discussed > > draft-ietf- opsawg-rfc5066bis. > > > > The situation is that IEEE 802.3.1 draft ballot ended 2 days ago. > > The IEEE document currently contains a pointer to the > > draft-ietf-opsawg- rfc5066bis draft. > > The IEEE document should be finalized by mid June. If this draft-ietf- > > opsawg-rfc5066bis would be a RFC by this time, the pointer will be > > replaced by the correct RFC. This is the ideal situation. > > So there is some sort of urgency publishing this RFC5066bis document. > > > > Regards, Benoit > > > > > > Below is some background information. > > > > Regards, Benoit > > > > 7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3 7.1. Description In the > > transition process between the IETF and the IEEE the following > > documents were taken over by IEEE 802.3: > > RFC 2108 - Ethernet Repeater Devices > > RFC 3621 - Power Ethernet MIB > > RFC 3635 - Ethernet-like Interface Types RFC 3637 - Ethernet WAN > > Interface Sublayer RFC 4836 - Ethernet Medium Attachment Units (MAUs) > > RFC 4837 - Ethernet Passive Optical Networks (EPON) RFC 4878 - > > Operations, Administration, and Maintenance (OAM) Functions on > > Ethernet- Like Interfaces RFC 5066 - Ethernet in the First Mile Copper > > (EFMCu) Interfaces MIB The IF-CAP-STACK-MIB in RFC 5066 is generic and > > the IETF proposed to continue to be maintained by the IETF in a > > separate new document The IEEE 802.3 proposed to create an RFC that > > documents the issues related to the transition of the Ethernet MIB > > work to IEEE 802.3 similar to RFC 4663 which documents the transition > > of the Bridge MIB work to IEEE 802.1 > > - The OPSAWG was rechartered in October 2012 to include the two > > relevant documents > > - Status 4/30/13: draft-ietf-opsawg-rfc5066bis received a number of > > substantial comments in the OPSAWG review which resulted in the need > > for substantial edits, revised version is still in progress. The > > second I-D was not submitted yet. The IEEE 802.3.1 completes > > Recirculation Sponsor Ballot on 4/30. Dan submitted an Approve ballot, > > the document is expected to be released in June, probably with > > reference to the Internet-Draft. > > > > 7.2. Relevant Documents > > - IEEE 802.3.1 Draft > > - http://datatracker.ietf.org/wg/opsawg/charter/ > > - https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/ > > > > 7.3. Owners > > - Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE > > 802.3) > > > > 7.4. Action Items > > - Dan Romascanu will enter the Sponsor Ballot pool and enter a comment > > suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB > > from their document and refer the IF-CAP-STACK-MIB instead - in > > progress, Sponsor Ballot started, comments need to be submitted until > > 1/13 - Done > > - Ed Beili will write an I-D targeting standards track that obsoletes > > RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording > > emphasizing the generic nature of this module - now on the OPSAWG > > charter, CRITICAL TIMING issue initial I-D to be submitted by 12/28, > > to become an OPSAWG document before 1/25 - done > > - Ed Beili will write an I-D targeting informational RFC, similar to > > RFC 4663, with: > > a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011 > > b) A table mapping the old IETF MIB names with the corresponding new > > IEEE ones > > c) Clarifications/rules on the IETF-IEEE interactions, mailing lists, > > reviews > > d) Clarifications on the intellectual property considerations The > > first version will be posted by Ed. Then Dan Romascanu and Howard > > Frazier will add IETF-IEEE interactions chapter. - Now on OPSAWG > > charter > > - Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB > > document, to explain the situation - Done > > - Dan Romascanu will submit an Approve Ballot in the Recirculation > > Sponsor Ballot (if all related issues are addressed) - Done > > > > >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From ramk@Brocade.com Tue May 7 08:56: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 0333D21F8F3C for ; Tue, 7 May 2013 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 hwbdjTz4Yen4 for ; Tue, 7 May 2013 08:56:49 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 44CFA21F8616 for ; Tue, 7 May 2013 08:56:48 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r47FqVrQ002566; Tue, 7 May 2013 08:56:45 -0700 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1c6t05rak8-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 May 2013 08:56:45 -0700 Received: from HQ1WP-EXHUB02.corp.brocade.com (10.70.38.14) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 7 May 2013 08:56:45 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::8c73:93bf:41b4:1443]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Tue, 7 May 2013 08:56:43 -0700 From: ramki Krishnan To: Brian E Carpenter , Randy Bush , "opsawg@ietf.org" Date: Tue, 7 May 2013 08:56:36 -0700 Thread-Topic: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/ Thread-Index: Ac5BRG+tH5tuj+AET4GRklqm4l2x8QAAJDzQAn1vIXA= Message-ID: References: <51656616.4070003@gmail.com> <51781D07.1040308@bogus.com> <51786C36.2060308@gmail.com> In-Reply-To: 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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626, 1.0.431, 0.0.0000 definitions=2013-05-07_06:2013-05-07, 2013-05-07, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1305070143 Cc: Sanjay Khanna , "bhumip.khasnabish@zteusa.com" , "ning.so@tatacommunications.com" Subject: Re: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-load-balancing/ 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, 07 May 2013 15:56:54 -0000 All, Based on expert advice from Brian/Randy, we have removed all IPR related im= plementation detail from the latest version of the draft -- see below. http://datatracker.ietf.org/doc/draft-krishnan-opsawg-large-flow-load-balan= cing/ We have also updated the IPR disclosure (other notes section) to reflect th= is -- see below. https://datatracker.ietf.org/ipr/2063/ Thanks, Ramki (on behalf of the co-authors) -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= ramki Krishnan Sent: Wednesday, April 24, 2013 4:40 PM To: Brian E Carpenter; Randy Bush Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-l= oad-balancing/ Thanks Brian, agreed. Thanks, Ramki -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of= Brian E Carpenter Sent: Wednesday, April 24, 2013 4:35 PM To: Randy Bush Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Call for adoption, draft-krishnan-opsawg-large-flow-l= oad-balancing/ On 25/04/2013 10:09, Randy Bush wrote: >> I came to the attention of the Chairs and the ADs during the call for=20 >> adoption that an IPR disclosure was likely pending on this draft. It=20 >> has since transpired. >> >> The disclosure can be reviewed here. >> >> http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_docu= ment_tag=3Ddraft-krishnan-opsawg-large-flow-load-balancing. >> >> In my opinion this is bit late frankly but short of 6701 remedy=20 >> territory. I have asked the chairs to extend the current call for=20 >> additional time (which they should chime in on), and I would ask that=20 >> if the disclosure alters you opinion of the document that you please=20 >> make your concerns known. >> >> I'd like to thank the authors for their candor, and the chairs for=20 >> bringing this to our attention. >=20 > i sent a concerned private email to some folk. one replied >=20 > The authors have indicated that the stuff on which they've filed the > patent application is not the only mechanism that can be used for > large flow detection - i.e. this can be implemented without using > their to-be-encumbered technology. >=20 > if this is the case, why not simply remove the to-be-encumbered=20 > technology from the document? I agree; it's not worth the pain, for an example algorithm in an Informatio= nal document. (The same goes for draft-krishnan-ipfix-flow-aware-packet-sampling.) Brian >=20 > otherwise, we potentially will waste a lot of time over this ipr claim. >=20 > randy > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From Tina.Tsou.Zouting@huawei.com Tue May 7 13:31: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 C081121F8E2C for ; Tue, 7 May 2013 13:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 kD4GSdEd68Or for ; Tue, 7 May 2013 13:31:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4121F8618 for ; Tue, 7 May 2013 13:31:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASN55192; Tue, 07 May 2013 20:31:30 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 21:31:23 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 8 May 2013 04:31:26 +0800 Received: from DFWEML513-MBS.china.huawei.com ([169.254.4.156]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Tue, 7 May 2013 13:31:21 -0700 From: Tina TSOU To: "opsawg@ietf.org" Thread-Topic: vm mib notifications Thread-Index: AQHOQXXy0YRIB8mlvEen0Vvm8MpO0JjnpA0AgAvRWYCABcIggIABB57A Date: Tue, 7 May 2013 20:31:20 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.98] Content-Type: multipart/mixed; boundary="_002_C0E0A32284495243BDE0AC8A066631A816648B12dfweml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OPSAWG] FW: vm mib notifications 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, 07 May 2013 20:31:37 -0000 --_002_C0E0A32284495243BDE0AC8A066631A816648B12dfweml513mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBNaWNoYWVsIGV0IGFsLA0KSSBtb3ZlIHRoZSBkaXNjdXNzaW9uIG92ZXIgdG8gT1BTQVdH IG1haWxpbmcgbGlzdC4NCkJhc2VkIG9uIHRoZSBmZWVkYmFjayBJIGdvdCBmcm9tIHNvbWUgcmVh ZGVycywgSSB0aGluayB3ZSBuZWVkIHRvIGNsYXJpZnkgd2hldGhlciB0aGlzIGRyYWZ0IHN1cHBv cnRzIG9ubHkgdHlwZSAxIGh5cGVydmlzb3IgKGRpcmVjdGx5IG9uIGJlYXIgbWV0YWwpIG9yIGlm IGl0IGRvZXMgdHlwZSAyIGh5cGVydmlzb3IgKGluZGlyZWN0bHkpIGFzIHdlbGwsIGFuZCBpZiB0 aGUgZHJhZnQgd2FzIHdyaXR0ZW4gd2l0aCBib3RoIHR5cGVzIG9mIGh5cGVydmlzb3JzLg0KDQpU aGFuayB5b3UsDQpUaW5hDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBNaWNoYWVsIE1hY0ZhZGVuIFttYWlsdG86bXJtQHZtd2FyZS5jb21dDQo+IFNlbnQ6IDIwMTPl ubQ15pyINuaXpSAxNDo0Mg0KPiBUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+IENjOiBkcmFm dC1hc2FpLXZtbS1taWJAdG9vbHMuaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IHZtIG1pYiBub3Rp ZmljYXRpb25zDQo+IA0KPiANCj4gQXR0YWNoZWQgcGxlYXNlIGZpbmQgbXkgc3VnZ2VzdGVkIHBh dGNoIHRvIHRoZSBkcmFmdC1hc2FpLXZtbS1taWItMDMudHh0DQo+IA0KPiBJbiBzaG9ydDoNCj4g DQo+IDEuIEludHJvZHVjZSBhIG5ldyBUQyBjYWxsZWQgVmlydHVhbE1hY2hpbmVMaXN0LiBJdA0K PiAgICBpcyBhIGNsb25lIG9mIFEtQlJJREdFLU1JQiBQb3J0TGlzdA0KPiANCj4gMi4gSW50cm9k dWNlIGEgbmV3IG1hbmFnZWQgb2JqZWN0LCB2bUJ1bGtOb3RpZmljYXRpb25zRW5hYmxlZCwgdG8g cmVwb3J0DQo+IHdoaWNoIHR5cGUNCj4gICAgb2YgZXZlbnRzIHRvIHJlY2VpdmUsIGVpdGhlciBi dWxrIG9yIGV4aXN0aW5nIHBlciB2bSBub3RpZmljYXRpb25zLg0KPiANCj4gMy4gQWRkcyBhIHBh cmFsbGVsIHNldCBvZiBub3RpZmljYXRpb25zIHRvIG1hdGNoOiB2bVJ1bmluZywgdm1TaHV0ZG93 biwNCj4gdm1QYXVzZWQsIHZtU3VzcGVuZGVkLCB2bUNyYXNoZWQsIHZtRGVsZXRlZCB0aGF0IG9u bHkgc2VuZCBhIG5ldw0KPiBhY2Nlc3NpYmxlLWZvci1ub3RpZnkgdmFyaWFibGUgdm1BZmZlY3Rl ZFZNcyB1c2luZyBTWU5UQVgNCj4gVmlydHVhbE1hY2hpbmVMaXN0Lg0KPiANCj4gTGFzdGx5LCAg SSd2ZSBhZGRlZCBzb21lIGNvbW1lbnRzIChncmVwIG1ybSkgYWJvdXQgd2hhdCBjbGllbnRzIHNo b3VsZA0KPiBleHBlY3Qgd2l0aCB2bU5hbWUsIHZtVVVJRCwgdm1JbmRleCBiYXNlZCBvbiBteSBw cmlvciBkZXBsb3ltZW50DQo+IGV4cGVyaWVuY2Ugd2l0aCB0aGUgc2ltaWxhcmx5IHN0cnVjdHVy ZWQgVk1XQVJFLVZNSU5GTy1NSUIuDQo+IA0KPiBPbmNlIHBhdGNoZWQsIHRoZSBWTS1NSUIgc2hv dWxkIGJlIHN5bnRhY3RpY2FsbHkgY29ycmVjdCB0byBzbWlsaW50IC1sOS4NCj4gSGVyZSBhcmUg dGhlIHByZS1leGlzdGluZyBkaWFnbm9zdGljcyBiZWZvcmUvYWZ0ZXIgdGhlIHBhdGNoLg0KPiAN Cj4gJHNtaWxpbnQgLWwgOSAuL1VVSUQtVEMtTUlCIC4vVk0tTUlCDQo+IC4vVVVJRC1UQy1NSUI6 NzE6IHdhcm5pbmc6IGN1cnJlbnQgdHlwZSBgVVVJRCcgaXMgbm90IHJlZmVyZW5jZWQgaW4gdGhp cw0KPiBtb2R1bGUNCj4gLi9VVUlELVRDLU1JQjo4Mjogd2FybmluZzogY3VycmVudCB0eXBlIGBV VUlEb3JaZXJvJyBpcyBub3QgcmVmZXJlbmNlZCBpbg0KPiB0aGlzIG1vZHVsZQ0KPiANCj4gDQo+ IFRoYW5rcw0KPiBNaWtlIE1hY0ZhZGVuDQo+IA0KDQo= --_002_C0E0A32284495243BDE0AC8A066631A816648B12dfweml513mbschi_ Content-Type: text/plain; name="vm-mib-03-patch.txt" Content-Description: vm-mib-03-patch.txt Content-Disposition: attachment; filename="vm-mib-03-patch.txt"; size=10567; creation-date="Mon, 06 May 2013 21:42:39 GMT"; modification-date="Mon, 06 May 2013 21:42:39 GMT" Content-ID: <85A8979174926F41AD3554D013DAF654@huawei.com> Content-Transfer-Encoding: base64 LS0tIGRyYWZ0LWFzYWktdm1tLW1pYi0wMy50eHQJMjAxMy0wNS0wNiAwOTo1Nzo1NS4wMDA0ODcw MDAgLTA3MDAKKysrIGRyYWZ0LW1ybS12bW0tbWliLTAxLnR4dAkyMDEzLTA1LTA2IDEzOjEyOjAx LjAwMDA4NjAwMCAtMDcwMApAQCAtNTIwLDcgKzUyMCw3IEBACiAgICAgICAgICAgIEZST00gU05N UHYyLVNNSQogICAgICAgIE9CSkVDVC1HUk9VUCwgTU9EVUxFLUNPTVBMSUFOQ0UsIE5PVElGSUNB VElPTi1HUk9VUAogICAgICAgICAgICBGUk9NIFNOTVB2Mi1DT05GCi0gICAgICAgVEVYVFVBTC1D T05WRU5USU9OLCBQaHlzQWRkcmVzcworICAgICAgIFRFWFRVQUwtQ09OVkVOVElPTiwgUGh5c0Fk ZHJlc3MsIFRydXRoVmFsdWUKICAgICAgICAgICAgRlJPTSBTTk1QdjItVEMKICAgICAgICBTbm1w QWRtaW5TdHJpbmcKICAgICAgICAgICAgRlJPTSBTTk1QLUZSQU1FV09SSy1NSUIKQEAgLTk0Myw2 ICs5NDMsMjMgQEAKICAgICAgICAgICAgICAgIG9mIHRoZSB2aXJ0dWFsIG1hY2hpbmUgdG8gdGhl IG5leHQgcmUtaW5pdGlhbGl6YXRpb24uIgogICAgICAgICBTWU5UQVggICAgICBJbnRlZ2VyMzIg KDEuLjIxNDc0ODM2NDcpCiAKKyAgIFZpcnR1YWxNYWNoaW5lTGlzdCA6Oj0gVEVYVFVBTC1DT05W RU5USU9OCisgICAgICAgRElTUExBWS1ISU5UICIxeCIKKyAgICAgICBTVEFUVVMgICAgICAgY3Vy cmVudAorICAgICAgIERFU0NSSVBUSU9OCisgICAgICAgICJFYWNoIG9jdGV0IHdpdGhpbiB0aGlz IHZhbHVlIHNwZWNpZmllcyBhIHNldCBvZiBlaWdodAorICAgICAgICBWaXJ0dWFsIE1hY2hpbmUg dm1JbmRleCwgd2l0aCB0aGUgZmlyc3Qgb2N0ZXQgc3BlY2lmeWluZworICAgICAgICBWaXJ0dWFs IE1hY2hpbmUgMSB0aHJvdWdoIDgsIHRoZSBzZWNvbmQgb2N0ZXQgc3BlY2lmeWluZworICAgICAg ICBWaXJ0dWFsIE1hY2hpbmUgOSB0aHJvdWdoIDE2LCBldGMuCisgICAgICAgIFdpdGhpbiBlYWNo IG9jdGV0LCB0aGUgbW9zdCBzaWduaWZpY2FudCBiaXQgcmVwcmVzZW50cworICAgICAgICB0aGUg bG93ZXN0IG51bWJlcmVkIHZtSW5kZXgsIGFuZCB0aGUgbGVhc3Qgc2lnbmlmaWNhbnQgYml0Cisg ICAgICAgIHJlcHJlc2VudHMgdGhlIGhpZ2hlc3QgbnVtYmVyZWQgdm1JbmRleC4gIFRodXMsIGVh Y2ggVmlydHVhbAorICAgICAgICBNYWNoaW5lIG9mIHRoZSBob3N0IGlzIHJlcHJlc2VudGVkIGJ5 IGEgc2luZ2xlIGJpdCB3aXRoaW4gdGhlCisgICAgICAgIHZhbHVlIG9mIHRoaXMgb2JqZWN0LiAg SWYgdGhhdCBiaXQgaGFzIGEgdmFsdWUgb2YgJzEnLAorICAgICAgICB0aGVuIHRoYXQgVmlydHVh bCBNYWNoaW5lIGlzIGluY2x1ZGVkIGluIHRoZSBzZXQgb2YgVmlydHVhbCBNYWNoaW5lczsKKyAg ICAgICAgdGhlIFZpcnR1YWwgTWFjaGluZSBpcyBub3QgaW5jbHVkZWQgaWYgaXRzIGJpdCBoYXMg YSB2YWx1ZSBvZiAnMCcuIgorICAgICAgICBTWU5UQVggICAgICBPQ1RFVCBTVFJJTkcKKyAgICAg ICAgCiAKICAgIC0tIFRoZSBoeXBlcnZpc29yIGdyb3VwCiAgICAtLQpAQCAtMTA5Miw3ICsxMTA5 LDEwIEBACiAgICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQKICAgICAgICBERVNDUklQVElPTgog ICAgICAgICAgICAgICAgIkEgdW5pcXVlIHZhbHVlLCBncmVhdGVyIHRoYW4gemVybywgaWRlbnRp ZnlpbmcgdGhlCi0gICAgICAgICAgICAgICB2aXJ0dWFsIG1hY2hpbmUuIgorICAgICAgICAgICAg ICAgdmlydHVhbCBtYWNoaW5lLiBUaGUgdmFsdWUgYXNzaWduZWQgdG8gYSBnaXZlbiBWaXJ0dWFs CisgICAgICAgICAgICAgICBtYWNoaW5lIG1heSBub3QgcGVyc2lzdCBhY3Jvc3MgYSByZWJvb3Qu IEEgY29tbWFuZCBnZW5lcmF0b3IKKyAgICAgICAgICAgICAgIG11c3QgdXNlIHRoZSB2bVVVSUQg dG8gaWRlbnRpZnkgYSBnaXZlbiBWaXJ0dWFsIE1hY2hpbmUgb2YKKyAgICAgICAgICAgICAgIGlu dGVyZXN0LiAobXJtIC1ub3RlLSBzYW1lIGRlc2lnbiBhcyBJRi1NSUIvaWZJbmRleCkiCiAgICAg ICAgOjo9IHsgdm1FbnRyeSAxIH0KIAogICAgdm1OYW1lIE9CSkVDVC1UWVBFCkBAIC0xMTA5LDcg KzExMjksMTAgQEAKICAgICAgICBTVEFUVVMgICAgICAgY3VycmVudAogICAgICAgIERFU0NSSVBU SU9OCiAgICAgICAgICAgICAgICAiVGhlIHZpcnR1YWwgbWFjaGluZSdzIDEyOC1iaXQgVVVJRCBv ciB0aGUgemVyby1sZW5ndGgKLSAgICAgICAgICAgICAgIHN0cmluZyB3aGVuIGEgVVVJRCBpcyBu b3QgYXZhaWxhYmxlLiIKKyAgICAgICAgICAgICAgIHN0cmluZyB3aGVuIGEgVVVJRCBpcyBub3Qg YXZhaWxhYmxlLiBUaGUgVVVJRCBpZiBzZXQKKyAgICAgICAgICAgICAgIG11c3QgdW5pcXVlbHkg aWRlbnRpZnkgYSBWTSBmcm9tIGFsbCBvdGhlciBWaXJ0dWFsIE1hY2hpbmVzCisgICAgICAgICAg ICAgICBpbiBhbiBhZG1pbmlzdHJhdGl2ZSByZWdpb24uICgqbXJtIC1ub3RlLSBleHBsYWluCisg ICAgICAgICAgICAgICBjYXNlIHdoZW4gdGhpcyB2YWx1ZSBtYXkgYmUgZW1wdHkuIgogICAgICAg IDo6PSB7IHZtRW50cnkgMyB9CiAKICAgIHZtT1NUeXBlIE9CSkVDVC1UWVBFCkBAIC0xNzAyLDYg KzE3MjUsMjUgQEAKIAogCiAgICAtLSBOb3RpZmljYXRpb24gZGVmaW5pdGlvbnM6CisKKyAgIHZt QnVsa05vdGlmaWNhdGlvbnNFbmFibGVkIE9CSkVDVC1UWVBFCisgICAgICAgU1lOVEFYICAgICAg IFRydXRoVmFsdWUKKyAgICAgICBNQVgtQUNDRVNTICAgcmVhZC1vbmx5CisgICAgICAgU1RBVFVT ICAgICAgIGN1cnJlbnQKKyAgICAgICBERVNDUklQVElPTgorICAgICAgICAgICAgICAgIkluZGlj YXRlcyBpZiBub3RpZmljYXRpb24gZ2VuZXJhdG9yIHdpbGwgc2VuZCBub3RpZmljYXRpb25zCisg ICAgICAgICAgICAgICAgcGVyIFZNIG9yIHBlciBzZXQgb2YgVk1zLiIKKyAgICAgICA6Oj0geyB2 bU9iamVjdHMgMTAwIH0KKyAgIAorICAgdm1BZmZlY3RlZFZNcyBPQkpFQ1QtVFlQRQorICAgICAg IFNZTlRBWCAgICAgICBWaXJ0dWFsTWFjaGluZUxpc3QKKyAgICAgICBNQVgtQUNDRVNTICAgYWNj ZXNzaWJsZS1mb3Itbm90aWZ5CisgICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQKKyAgICAgICBE RVNDUklQVElPTgorICAgICAgICAgICAgICAgIkEgY29tcGxldGUgbGlzdCBvZiBWaXJ0dWFsIE1h Y2hpbmVzIHdob3NlIHN0YXRlIGhhcyBjaGFuZ2VkLgorICAgICAgICAgICAgICAgIFRoaXMgb2Jq ZWN0IGlzIHRoZSBvbmx5IG9iamVjdCBzZW50IHdpdGggYnVsayBub3RpZmljYXRpb25zLiIKKyAg ICAgICA6Oj0geyB2bU9iamVjdHMgMTAxIH0KKyAgICAgIAogICAgdm1SdW5uaW5nIE5PVElGSUNB VElPTi1UWVBFCiAgICAgICAgT0JKRUNUUyAgICAgIHsKICAgICAgICAgICAgICAgICAgICAgICAg dm1OYW1lLApAQCAtMTcxMCwxNSArMTc1MiwyOSBAQAogICAgICAgICAgICAgICAgICAgICB9CiAg ICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQKICAgICAgICBERVNDUklQVElPTgotICAgICAgICAg ICAgICAgIlRoaXMgbm90aWZpY2F0aW9uIGlzIGdlbmVyYXRlZCB3aGVuIHRoZSBvcGVyYXRpb25h bAorICAgICAgICAgICAgICAiVGhpcyBub3RpZmljYXRpb24gaXMgZ2VuZXJhdGVkIHdoZW4gdGhl IG9wZXJhdGlvbmFsCiAgICAgICAgICAgICAgICBzdGF0ZSBvZiBhIHZpcnR1YWwgbWFjaGluZSBo YXMgYmVlbiBjaGFuZ2VkIHRvCiAgICAgICAgICAgICAgICBgcnVubmluZycgZnJvbSBzb21lIG90 aGVyIHN0YXRlLiAgVGhlIG90aGVyIHN0YXRlIGlzCiAgICAgICAgICAgICAgICBpbmRpY2F0ZWQg YnkgdGhlIGluY2x1ZGVkIHZhbHVlIG9mIHZtT3BlclN0YXRlLiIKICAgICAgICA6Oj0geyB2bU5v dGlmaWNhdGlvbnMgMSB9CiAKKyAgIHZtc1J1bm5pbmcgTk9USUZJQ0FUSU9OLVRZUEUKKyAgICAg ICBPQkpFQ1RTICAgICAgeworICAgICAgICAgICAgICAgICAgICAgICB2bUFmZmVjdGVkVk1zCisg ICAgICAgICAgICAgICAgICAgIH0KKyAgICAgICBTVEFUVVMgICAgICAgY3VycmVudAorICAgICAg IERFU0NSSVBUSU9OCisgICAgICAgICAgICAgICAiVGhpcyBub3RpZmljYXRpb24gaXMgZ2VuZXJh dGVkIHdoZW4gdGhlIG9wZXJhdGlvbmFsCisgICAgICAgICAgICAgICAgc3RhdGUgb2Ygb25lIG9y IG1vcmUgdmlydHVhbCBtYWNoaW5lIGhhcyBiZWVuIGNoYW5nZWQgdG8KKyAgICAgICAgICAgICAg ICBgcnVubmluZycgZnJvbSBhIGFsbCBwcmlvciBzdGF0ZXMgZXhjZXB0IGZvciAncnVubmluZy4n CisgICAgICAgICAgICAgICAgTWFuYWdlbWVudCBzdGF0aW9ucyBhcmUgZW5jb3VyYWdlZCB0byBz dWJzZXF1ZW50bHkKKyAgICAgICAgICAgICAgICBwb2xsIHRoZSBzdWJzZXQgb2YgVk1zIG9mIGlu dGVyZXN0IGZvciB2bU9wZXJTdGF0ZS4iCisgICAgICAgOjo9IHsgdm1Ob3RpZmljYXRpb25zIDEw IH0KKyAgICAgICAKKwogICAgdm1TaHV0ZG93biBOT1RJRklDQVRJT04tVFlQRQogICAgICAgIE9C SkVDVFMgICAgICB7Ci0gICAgICAgICAgICAgICAgICAgICAgIHZtTmFtZSwKKyAgICAgICAgICAg ICAgICAgICAgICAgdm1OYW1lLCAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgdm1VVUlE LAogICAgICAgICAgICAgICAgICAgICAgICB2bU9wZXJTdGF0ZQogICAgICAgICAgICAgICAgICAg ICB9CkBAIC0xNzMwLDYgKzE3ODYsMTggQEAKICAgICAgICAgICAgICAgIGluZGljYXRlZCBieSB0 aGUgaW5jbHVkZWQgdmFsdWUgb2Ygdm1PcGVyU3RhdGUuIgogICAgICAgIDo6PSB7IHZtTm90aWZp Y2F0aW9ucyAyIH0KIAorICAgdm1zU2h1dGRvd24gTk9USUZJQ0FUSU9OLVRZUEUKKyAgICAgICBP QkpFQ1RTICAgICAgeworICAgICAgICAgICAgICAgICAgICAgIHZtQWZmZWN0ZWRWTXMKKyAgICAg ICAgICAgICAgICAgICAgfQorICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50CisgICAgICAgREVT Q1JJUFRJT04KKyAgICAgICAgICAgICAgICJUaGlzIG5vdGlmaWNhdGlvbiBpcyBnZW5lcmF0ZWQg d2hlbiB0aGUgb3BlcmF0aW9uYWwKKyAgICAgICAgICAgICAgIHN0YXRlIG9mIG9uZSBvciBtb3Jl IHZpcnR1YWwgbWFjaGluZSBoYXMgYmVlbiBjaGFuZ2VkIHRvCisgICAgICAgICAgICAgICBgc2h1 dGRvd24nIGZyb20gYSBzdGF0ZSBvdGhlciB0aGFuIGBzaHV0ZG93bmAuCisgICAgICAgICAgICAg ICAgTWFuYWdlbWVudCBzdGF0aW9ucyBhcmUgZW5jb3VyYWdlZCB0byBzdWJzZXF1ZW50bHkKKyAg ICAgICAgICAgICAgICBwb2xsIHRoZSBzdWJzZXQgb2YgVk1zIG9mIGludGVyZXN0IGZvciB2bU9w ZXJTdGF0ZS4iCisgICAgICAgOjo9IHsgdm1Ob3RpZmljYXRpb25zIDIwIH0KIAogCiAKQEAgLTE3 NTIsNiArMTgyMCwxOSBAQAogICAgICAgICAgICAgICAgaW5kaWNhdGVkIGJ5IHRoZSBpbmNsdWRl ZCB2YWx1ZSBvZiB2bU9wZXJTdGF0ZS4iCiAgICAgICAgOjo9IHsgdm1Ob3RpZmljYXRpb25zIDMg fQogCisgICB2bXNQYXVzZWQgTk9USUZJQ0FUSU9OLVRZUEUKKyAgICAgICBPQkpFQ1RTICAgICAg eworICAgICAgICAgICAgICAgICAgICAgICB2bUFmZmVjdGVkVk1zCisgICAgICAgICAgICAgICAg ICAgIH0KKyAgICAgICBTVEFUVVMgICAgICAgY3VycmVudAorICAgICAgIERFU0NSSVBUSU9OCisg ICAgICAgICAgICAgICAiVGhpcyBub3RpZmljYXRpb24gaXMgZ2VuZXJhdGVkIHdoZW4gdGhlIG9w ZXJhdGlvbmFsCisgICAgICAgICAgICAgICBzdGF0ZSBvZiBvbmUgb3IgbW9yZSB2aXJ0dWFsIG1h Y2hpbmVzIGhhdmUgYmVlbiBjaGFuZ2VkIHRvCisgICAgICAgICAgICAgICBgcGF1c2VkJyBmcm9t IGEgc3RhdGUgb3RoZXIgdGhhbiBgcGF1c2VkLmAKKyAgICAgICAgICAgICAgICBNYW5hZ2VtZW50 IHN0YXRpb25zIGFyZSBlbmNvdXJhZ2VkIHRvIHN1YnNlcXVlbnRseQorICAgICAgICAgICAgICAg IHBvbGwgdGhlIHN1YnNldCBvZiBWTXMgb2YgaW50ZXJlc3QgZm9yIHZtT3BlclN0YXRlLiIKKyAg ICAgICA6Oj0geyB2bU5vdGlmaWNhdGlvbnMgMzAgfQorICAgICAgIAogICAgdm1TdXNwZW5kZWQg Tk9USUZJQ0FUSU9OLVRZUEUKICAgICAgICBPQkpFQ1RTICAgICAgewogICAgICAgICAgICAgICAg ICAgICAgICB2bU5hbWUsCkBAIC0xNzY2LDYgKzE4NDcsMTkgQEAKICAgICAgICAgICAgICAgIGlu ZGljYXRlZCBieSB0aGUgaW5jbHVkZWQgdmFsdWUgb2Ygdm1PcGVyU3RhdGUuIgogICAgICAgIDo6 PSB7IHZtTm90aWZpY2F0aW9ucyA0IH0KIAorICAgdm1zU3VzcGVuZGVkIE5PVElGSUNBVElPTi1U WVBFCisgICAgICAgT0JKRUNUUyAgICAgIHsKKyAgICAgICAgICAgICAgICAgICAgICAgdm1BZmZl Y3RlZFZNcworICAgICAgICAgICAgICAgICAgICB9CisgICAgICAgU1RBVFVTICAgICAgIGN1cnJl bnQKKyAgICAgICBERVNDUklQVElPTgorICAgICAgICAgICAgICAgIlRoaXMgbm90aWZpY2F0aW9u IGlzIGdlbmVyYXRlZCB3aGVuIHRoZSBvcGVyYXRpb25hbAorICAgICAgICAgICAgICAgc3RhdGUg b2Ygb25lIG9yIG1vcmUgdmlydHVhbCBtYWNoaW5lcyBoYXZlIGJlZW4gY2hhbmdlZCB0bworICAg ICAgICAgICAgICAgYHN1c3BlbmRlZCcgZnJvbSBhIHN0YXRlIG90aGVyIHRoYW4gJ3N1c3BlbmRl ZC4nIAorICAgICAgICAgICAgICAgIE1hbmFnZW1lbnQgc3RhdGlvbnMgYXJlIGVuY291cmFnZWQg dG8gc3Vic2VxdWVudGx5CisgICAgICAgICAgICAgICAgcG9sbCB0aGUgc3Vic2V0IG9mIFZNcyBv ZiBpbnRlcmVzdCBmb3Igdm1PcGVyU3RhdGUuIgorICAgICAgIDo6PSB7IHZtTm90aWZpY2F0aW9u cyA0MCB9CisgICAgICAgCiAgICB2bUNyYXNoZWQgTk9USUZJQ0FUSU9OLVRZUEUKICAgICAgICBP QkpFQ1RTICAgICAgewogICAgICAgICAgICAgICAgICAgICAgICB2bU5hbWUsCkBAIC0xNzgwLDYg KzE4NzQsMTggQEAKICAgICAgICAgICAgICAgIHZtT3BlclN0YXRlLiIKICAgICAgICA6Oj0geyB2 bU5vdGlmaWNhdGlvbnMgNSB9CiAKKyAgIHZtc0NyYXNoZWQgTk9USUZJQ0FUSU9OLVRZUEUKKyAg ICAgICBPQkpFQ1RTICAgICAgeworICAgICAgICAgICAgICAgICAgICAgICB2bUFmZmVjdGVkVk1z CisgICAgICAgICAgICAgICAgICAgIH0KKyAgICAgICBTVEFUVVMgICAgICAgY3VycmVudAorICAg ICAgIERFU0NSSVBUSU9OCisgICAgICAgICAgICAgICAiVGhpcyBub3RpZmljYXRpb24gaXMgZ2Vu ZXJhdGVkIHdoZW4gb25lIG9yIG1vcmUgdmlydHVhbAorICAgICAgICAgICAgICAgIG1hY2hpbmVz IGhhdmUgYmVlbiBjcmFzaGVkLiAKKyAgICAgICAgICAgICAgICBNYW5hZ2VtZW50IHN0YXRpb25z IGFyZSBlbmNvdXJhZ2VkIHRvIHN1YnNlcXVlbnRseQorICAgICAgICAgICAgICAgIHBvbGwgdGhl IHN1YnNldCBvZiBWTXMgb2YgaW50ZXJlc3QgZm9yIHZtT3BlclN0YXRlLiIKKyAgICAgICA6Oj0g eyB2bU5vdGlmaWNhdGlvbnMgNTAgfQorICAgICAgIAogICAgdm1EZWxldGVkIE5PVElGSUNBVElP Ti1UWVBFCiAgICAgICAgT0JKRUNUUyAgICAgIHsKICAgICAgICAgICAgICAgICAgICAgICAgdm1O YW1lLApAQCAtMTc5OCwxMSArMTkwNCwyNCBAQAogICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50 CiAgICAgICAgREVTQ1JJUFRJT04KICAgICAgICAgICAgICAgICJUaGlzIG5vdGlmaWNhdGlvbiBp cyBnZW5lcmF0ZWQgd2hlbiBhIHZpcnR1YWwgbWFjaGluZQotICAgICAgICAgICAgICAgaGFzIGJl ZW4gZGVsZXRlZC4gVGhlIHByZXZpb3Mgc3RhdGUgb2YgdGhlIHZpcnR1YWwKKyAgICAgICAgICAg ICAgIGhhcyBiZWVuIGRlbGV0ZWQuIFRoZSBwcmlvciBzdGF0ZSBvZiB0aGUgdmlydHVhbAogICAg ICAgICAgICAgICAgbWFjaGluZSBpcyBpbmRpY2F0ZWQgYnkgdGhlIGluY2x1ZGVkIHZhbHVlIG9m CiAgICAgICAgICAgICAgICB2bU9wZXJTdGF0ZS4iCiAgICAgICAgOjo9IHsgdm1Ob3RpZmljYXRp b25zIDYgfQogCisgICB2bXNEZWxldGVkIE5PVElGSUNBVElPTi1UWVBFCisgICAgICAgT0JKRUNU UyAgICAgIHsKKyAgICAgICAgICAgICAgICAgICAgICAgdm1BZmZlY3RlZFZNcworICAgICAgICAg ICAgICAgICAgICB9CisgICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQKKyAgICAgICBERVNDUklQ VElPTgorICAgICAgICAgICAgICAgIlRoaXMgbm90aWZpY2F0aW9uIGlzIGdlbmVyYXRlZCB3aGVu IG9uZSBvciBtb3JlCisgICAgICAgICAgICAgICAgdmlydHVhbCBtYWNoaW5lcyBoYXZlIGJlZW4g ZGVsZXRlZC4KKyAgICAgICAgICAgICAgICBNYW5hZ2VtZW50IHN0YXRpb25zIGFyZSBlbmNvdXJh Z2VkIHRvIHN1YnNlcXVlbnRseQorICAgICAgICAgICAgICAgIHBvbGwgdGhlIHN1YnNldCBvZiBW TXMgb2YgaW50ZXJlc3QgZm9yIHZtT3BlclN0YXRlLiIKKworICAgICAgIDo6PSB7IHZtTm90aWZp Y2F0aW9ucyA2MCB9CisgICAgICAgCiAgICAtLSBDb21wbGlhbmNlIGRlZmluaXRpb25zOgogICAg dm1Hcm91cHMgICAgICAgT0JKRUNUIElERU5USUZJRVIgOjo9IHsgdm1Db25mb3JtYW5jZSAxIH0K ICAgIHZtQ29tcGxpYW5jZXMgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IHZtQ29uZm9ybWFuY2Ug MiB9CkBAIC0xODIyLDYgKzE5NDEsMTMgQEAKICAgICAgICAgICAgdm1OZXR3b3JrR3JvdXAsCiAg ICAgICAgICAgIHZtTm90aWZpY2F0aW9uR3JvdXAKICAgICAgICB9CisgICAgICAgR1JPVVAgdm1C dWxrTm90aWZpY2F0aW9uc1ZhcmlhYmxlc0dyb3VwCisgICAgICAgREVTQ1JJUFRJT04KKyAgICAg ICAgICAgICJOZWNlc3Nhcnkgb25seSBpZiB2bU5vdGlmaWNhdGlvbk9wdGlvbmFsR3JvdXAgaXMg aW1wbGVtZW50ZWQuIgorICAgICAgIEdST1VQICB2bU5vdGlmaWNhdGlvbk9wdGlvbmFsR3JvdXAK KyAgICAgICBERVNDUklQVElPTgorICAgICAgICAgICAgIlN1cHBvcnQgZm9yIGJ1bGsgbm90aWZp Y2F0aW9ucyBpcyBvcHRpb25hbC4gSWYgbm90CisgICAgICAgICAgICAgaW1wbGVtZW50ZWQgdGhl biB2bUJ1bGtOb3RpZmljYXRpb25zRW5hYmxlZCBtdXN0IHJlcG9ydCBmYWxzZSgyKSIKICAgICAg ICA6Oj0geyB2bUNvbXBsaWFuY2VzIDEgfQogCiAgICB2bVJlYWRPbmx5Q29tcGxpYW5jZXMgTU9E VUxFLUNPTVBMSUFOQ0UKQEAgLTE4OTEsNyArMjAxNyw4IEBACiAgICAgICAgICAgIHZtSHZPYmpl Y3RJRCwKICAgICAgICAgICAgdm1IdlVwVGltZSwKICAgICAgICAgICAgdm1OdW1iZXIsCi0gICAg ICAgICAgIHZtVGFibGVMYXN0Q2hhbmdlCisgICAgICAgICAgIHZtVGFibGVMYXN0Q2hhbmdlLAor ICAgICAgICAgICB2bUJ1bGtOb3RpZmljYXRpb25zRW5hYmxlZAogICAgICAgIH0KICAgICAgICBT VEFUVVMgICAgICAgY3VycmVudAogICAgICAgIERFU0NSSVBUSU9OCkBAIC0yMDEwLDE3ICsyMTM3 LDQyIEBACiAgICAgICAgfQogICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50CiAgICAgICAgREVT Q1JJUFRJT04KLQorICAgICAgICAgICJBIGNvbGxlY3Rpb24gb2Ygbm90aWZpY2F0aW9ucyBmb3Ig dmlydHVhbCBtYWNoaW5lcworICAgICAgICAgICBjb250cm9sbGVkIGJ5IGEgaHlwZXJ2aXNvci4i CisgICAgICAgOjo9IHsgdm1Hcm91cHMgNyB9CiAKIAogQXNhaSwgZXQgYWwuICAgICAgICAgICAg RXhwaXJlcyBPY3RvYmVyIDEyLCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMzZdCiAMCiBJbnRl cm5ldC1EcmFmdCAgICAgICBWaXJ0dWFsIE1hY2hpbmUgTW9uaXRvcmluZyBNSUIgICAgICAgICAg IEFwcmlsIDIwMTMKIAorICAgdm1CdWxrTm90aWZpY2F0aW9uc1ZhcmlhYmxlc0dyb3VwIE9CSkVD VC1HUk9VUAorICAgT0JKRUNUUyB7CisgICAgICAgdm1BZmZlY3RlZFZNcworICAgfQorICAgU1RB VFVTICAgICAgIGN1cnJlbnQKKyAgIERFU0NSSVBUSU9OCisgICAgICAgIlRoZSB2YXJpYWJsZXMg dXNlZCBpbiB2bU5vdGlmaWNhdGlvbk9wdGlvbmFsR3JvdXAKKyAgICAgICAgdmlydHVhbCBuZXR3 b3JrIGludGVyZmFjZXMgY29udHJvbGxlZCBieSBhIGh5cGVydmlzb3IuIgorICAgIDo6PSB7IHZt R3JvdXBzIDggfQorCisKKyAgIHZtTm90aWZpY2F0aW9uT3B0aW9uYWxHcm91cCBOT1RJRklDQVRJ T04tR1JPVVAKKyAgICBOT1RJRklDQVRJT05TIHsgICAKKyAgICAgICAgICAgdm1zUnVubmluZywK KyAgICAgICAgICAgdm1zU2h1dGRvd24sCisgICAgICAgICAgIHZtc1BhdXNlZCwKKyAgICAgICAg ICAgdm1zU3VzcGVuZGVkLAorICAgICAgICAgICB2bXNDcmFzaGVkLAorICAgICAgICAgICB2bXNE ZWxldGVkCisgICAgICAgfQorICAgICAgIFNUQVRVUyAgICAgICBjdXJyZW50CisgICAgICAgREVT Q1JJUFRJT04KKyAgICAgICAgICAiQSBjb2xsZWN0aW9uIG9mIG5vdGlmaWNhdGlvbnMgZm9yIGJ1 bGsgbm90aWZpY2F0aW9uCisgICAgICAgICAgIG9mIGNoYW5nZXMgdG8gdmlydHVhbCBtYWNoaW5l IHN0YXRlICh2bU9wZXJTdGF0ZSkgYXMKKyAgICAgICAgICAgcmVwb3J0ZWQgYnkgYSBnaXZlbiBo eXBlcnZpc29yLiIKKyAgICAgICA6Oj0geyB2bUdyb3VwcyA5IH0KIAotICAgICAgICAgICAgICAg IkEgY29sbGVjdGlvbiBvZiBub3RpZmljYXRpb25zIGZvciB2aXJ0dWFsIG1hY2hpbmVzCi0gICAg ICAgICAgICAgICBjb250cm9sbGVkIGJ5IGEgaHlwZXJ2aXNvci4iCi0gICAgICAgOjo9IHsgdm1H cm91cHMgNyB9CiAKICAgIEVORAogCg== --_002_C0E0A32284495243BDE0AC8A066631A816648B12dfweml513mbschi_-- From j.schoenwaelder@jacobs-university.de Wed May 8 00:42:30 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 2B7D721F8F53 for ; Wed, 8 May 2013 00:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[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 v2S9UQdaMPyc for ; Wed, 8 May 2013 00:42:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 27ACF21F81FE for ; Wed, 8 May 2013 00:42:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 845FF20BE4; Wed, 8 May 2013 09:42:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id u5akah064Lyi; Wed, 8 May 2013 09:42:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BDD420BD8; Wed, 8 May 2013 09:42:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C1CE1260C4F6; Wed, 8 May 2013 09:42:20 +0200 (CEST) Date: Wed, 8 May 2013 09:42:20 +0200 From: Juergen Schoenwaelder To: Tina TSOU Message-ID: <20130508074220.GA61836@elstar.local> Mail-Followup-To: Tina TSOU , "opsawg@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] FW: vm mib notifications 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: Wed, 08 May 2013 07:42:30 -0000 On Tue, May 07, 2013 at 08:31:20PM +0000, Tina TSOU wrote: > Based on the feedback I got from some readers, I think we need to > clarify whether this draft supports only type 1 hypervisor (directly > on bear metal) or if it does type 2 hypervisor (indirectly) as well, > and if the draft was written with both types of hypervisors. Tina, can you please clarify what you mean by type 1 hypervisor (directly on bear metal) or if it does type 2 hypervisor (indirectly)? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From david.black@emc.com Wed May 8 08:37: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 2679621F92EF for ; Wed, 8 May 2013 08:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LwDr00DFo1H8 for ; Wed, 8 May 2013 08:37:50 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3881D21F90B9 for ; Wed, 8 May 2013 08:37:49 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r48FbiXM005167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 May 2013 11:37:47 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 8 May 2013 11:37:26 -0400 Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r48Fao44026127; Wed, 8 May 2013 11:37:25 -0400 Received: from mx15a.corp.emc.com ([169.254.1.105]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Wed, 8 May 2013 11:36:37 -0400 From: "Black, David" To: Juergen Schoenwaelder Date: Wed, 8 May 2013 11:36:37 -0400 Thread-Topic: [OPSAWG] FW: vm mib notifications Thread-Index: Ac5LwCxfIwtgbQtPSf+JuSg7PcWJywAQT/Lg Message-ID: <8D3D17ACE214DC429325B2B98F3AE712953BA091@MX15A.corp.emc.com> References: <20130508074220.GA61836@elstar.local> In-Reply-To: <20130508074220.GA61836@elstar.local> 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 X-EMM-MHVC: 1 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] FW: vm mib notifications 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, 08 May 2013 15:37:54 -0000 A type 1 hypervisor is effectively an Operating System - it runs directly o= n the hardware. A type 2 hypervisor is effectively an application - it runs on an OS that r= uns on hardware. More explanation and diagrams here: https://en.wikipedia.org/wiki/Hyperviso= r Thanks, --David > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf = Of > Juergen Schoenwaelder > Sent: Wednesday, May 08, 2013 3:42 AM > To: Tina TSOU > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] FW: vm mib notifications >=20 > On Tue, May 07, 2013 at 08:31:20PM +0000, Tina TSOU wrote: >=20 > > Based on the feedback I got from some readers, I think we need to > > clarify whether this draft supports only type 1 hypervisor (directly > > on bear metal) or if it does type 2 hypervisor (indirectly) as well, > > and if the draft was written with both types of hypervisors. >=20 > Tina, >=20 > can you please clarify what you mean by type 1 hypervisor (directly on > bear metal) or if it does type 2 hypervisor (indirectly)? >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Wed May 8 10:21:36 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 6A33321F8F50 for ; Wed, 8 May 2013 10:21:36 -0700 (PDT) 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 ulkDFgTF6pEB for ; Wed, 8 May 2013 10:21:29 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1746721F8EB1 for ; Wed, 8 May 2013 10:21:28 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id u10so1385427pdi.33 for ; Wed, 08 May 2013 10:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=qOHPW2iIogtdOlM3I1hQ8O/joAKplOXbAjPwlcbHCik=; b=a03PmL962J5+nc9dZamKhEf4fJh7uMuC58FwBv+Y3EPZQsQay3X/6sNEM/Vht7wCNP LYutQ8oUb7BcmlRhFTYYRImfy9NSIcUyVzSIjwIFNV/AJJVd5+OV3ZgVg8TUNc6ktk2Y ZYKMmzv1T28s6dQQMtRPs5eqYskpuM0uVfHtXmvie/35BLS4KrZVFVJDiKw6p9wAQ2h/ GECwOExm5NFas92HH/KC0RqsWrTz8CKIakmhgNI4172a4u8GRi1Bia3hxXthaGcl1DK2 FRSa0ATrQRBOTorFxIZAjjT72nL22pMkR+teyeJReXNAJZaOyTX8Zs+XwNTjtx95t5KY QLUg== X-Received: by 10.66.232.129 with SMTP id to1mr9042398pac.144.1368033677504; Wed, 08 May 2013 10:21:17 -0700 (PDT) Received: from spandex.local (216-67-41-253-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.253]) by mx.google.com with ESMTPSA id dg5sm33351473pbc.29.2013.05.08.10.21.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 10:21:16 -0700 (PDT) Message-ID: <518A8989.9020701@gmail.com> Date: Wed, 08 May 2013 09:21:13 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: ramki Krishnan , "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] draft-krishnan-opsawg-large-flow-load-balancing 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, 08 May 2013 17:21:36 -0000 The working group has consensus to adopt draft-krishnan-opsawg-large-flow-load-balancing as a working group draft. Many thanks for working with us on sorting out the IPR issues. Please resubmit the draft under the name "draft-ietf-opsawg-large-flow-load-balancing." Melinda From melinda.shore@gmail.com Wed May 8 10:24: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 4BDC721F9253 for ; Wed, 8 May 2013 10:24:47 -0700 (PDT) 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 aAXPhNq0mzp6 for ; Wed, 8 May 2013 10:24:46 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDE21F91CB for ; Wed, 8 May 2013 10:24:46 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa7so1360894pbc.25 for ; Wed, 08 May 2013 10:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=W/r50LCcbumOVn4M8qFf1wVCv8JgqArMTZqKwYJe2pU=; b=CYMG/rihbY/JTxSY6qTjOJjmd5j9saHkhZnmBG4n2L7CxY3fbcj9MNbVsJZVJfC7JM JfCw6nZdSHfcKTKcFBujM7BAMGdZUDj/GHJo1ZQEvDRMtMru0lkh5rl2I6gTbZQ2NEy5 N55fezoc0TyhwJdsZtPRFiDG8lMMjKFuPEna2kOOfHei/8cJiKLT4Ek5r6tGauJ88wg7 XQDMlnMebVMtbuZ7pXpTRoFAdaOkm9XvQvkeIGEM1Qqdx+th5aAmU6pYm96zoa8O/Qqf J5lWNKyfx+hx2bkFB6dVnbwI1SYG4Hd8KaCwotnIajFwrHxmyZyAFohIrX0FgDDYLql8 8igg== X-Received: by 10.68.164.98 with SMTP id yp2mr8427585pbb.214.1368033886288; Wed, 08 May 2013 10:24:46 -0700 (PDT) Received: from spandex.local (216-67-41-253-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.253]) by mx.google.com with ESMTPSA id gc5sm33378132pbb.19.2013.05.08.10.24.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 10:24:45 -0700 (PDT) Message-ID: <518A8A5B.2030703@gmail.com> Date: Wed, 08 May 2013 09:24:43 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Hui Deng , shaochunju@chinamobile.com, farooq.bari@att.com, zhangr@gsta.com, satoru.matsushima@g.softbank.co.jp, "opsawg@ietf.org" , "opsawg-chairs@tools.ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] draft-shao-opsawg-capwap-hybridmac 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, 08 May 2013 17:24:47 -0000 The opsawg has consensus to adopt draft-shao-opsawg-capwap-hybridmac as a working group draft. Please resubmit with the name draft-ietf-opsawg-capwap-hybridmac. Many thanks, Melinda From internet-drafts@ietf.org Wed May 8 15:21: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 E7A1F21F8506; Wed, 8 May 2013 15:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.102, 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 KX0wgzAcjFlL; Wed, 8 May 2013 15:21:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B55DD21F8F0A; Wed, 8 May 2013 15:20:34 -0700 (PDT) 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.44.p7 Message-ID: <20130508222034.14977.88561.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2013 15:20:34 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-large-flow-load-balancing-00.txt 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, 08 May 2013 22:21:10 -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 : Mechanisms for Optimal LAG/ECMP Component Link Utilizati= on in Networks Author(s) : Ram Krishnan Sanjay Khanna Lucy Yong Anoop Ghanwani Ning So Bhumip Khasnabish Filename : draft-ietf-opsawg-large-flow-load-balancing-00.txt Pages : 18 Date : 2013-05-08 Abstract: Demands on networking infrastructure are growing exponentially; the drivers are bandwidth hungry rich media applications, inter-data center communications, etc. In this context, it is important to optimally use the bandwidth in wired networks that extensively use LAG/ECMP techniques for bandwidth scaling. This draft explores some of the mechanisms useful for achieving this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-large-flow-load-balancing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-large-flow-load-balancing-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From melinda.shore@gmail.com Wed May 8 15:33:25 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 B4BA821F90C3 for ; Wed, 8 May 2013 15:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 7fnN+O6w51CG for ; Wed, 8 May 2013 15:33:25 -0700 (PDT) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE9B21F909A for ; Wed, 8 May 2013 15:33:25 -0700 (PDT) Received: by mail-pb0-f43.google.com with SMTP id md12so1555763pbc.16 for ; Wed, 08 May 2013 15:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=83wRk4PCbZcA/jg3Q+H+gDzV+sEIG+Gc3/XnueRAjfk=; b=BuoKWRUomDO0LJ6pv5QqJugm8V4Ue/cZTh5eLdui8aTFwD6NTuamxrT3Kgus/dclOt QRFm3dYUe6bG6e8r8kHAIz/08hKqiVykV+DrR80WDBCN6c1qMwv6VfwJR4IB54UNT4hz Knu8NjC17kQkiBKRjwrb/5Z2gqx3GH2d8kkoTJTD4Nh3b7R2uyhcak1LBbVbI99HV+4v Ky/ffph4WQonQm6X0VAueTKP8fhbTdF+P9dWMdnB+k+oO8lcJ7y9OVknR8x+aV/vp+Sg tgQx85qv1Y2yznkKePvbfDkJcktrRt86tMcY3xqw95WJ45h4clu2e4zI+NBJ2g46HzEs IPcA== X-Received: by 10.68.253.230 with SMTP id ad6mr9363899pbd.182.1368052405067; Wed, 08 May 2013 15:33:25 -0700 (PDT) Received: from spandex.local (216-67-41-253-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.253]) by mx.google.com with ESMTPSA id aj6sm397165pbd.14.2013.05.08.15.33.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 15:33:24 -0700 (PDT) Message-ID: <518AD2B1.50901@gmail.com> Date: Wed, 08 May 2013 14:33:21 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Planning for IETF 87 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, 08 May 2013 22:33:25 -0000 It's time to start planning for IETF 87. We've requested a two- hour slot to be shared with opsarea, and we're planning on having a technology presentation (details later). We also have the following working group documents: draft-ietf-opsawg-lsn-deployment draft-ietf-opsawg-large-flow-load-balancing two capwap drafts firewalls draft draft-ietf-opsawg-rfc5066bis Please let us know if you'd like time on the agenda. As always, we've got a strong preference for giving time to documents that have had discussion on the opsawg mailing list, and as always, the time is not to be used for document presentation, but to discuss issues that were not resolved on the mailing list or that need real-time, face-to-face discussion. Melinda From j.schoenwaelder@jacobs-university.de Wed May 8 15:54:17 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 8AE3821F9048 for ; Wed, 8 May 2013 15:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[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 8WCczyWCUmrw for ; Wed, 8 May 2013 15:54:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2765A21F8F05 for ; Wed, 8 May 2013 15:54:13 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 104CD20BE8; Thu, 9 May 2013 00:54:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rXA1kwHNifcf; Thu, 9 May 2013 00:54:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64B8C20BE0; Thu, 9 May 2013 00:54:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4BCD2260FEBA; Thu, 9 May 2013 00:54:08 +0200 (CEST) Date: Thu, 9 May 2013 00:54:08 +0200 From: Juergen Schoenwaelder To: "Black, David" Message-ID: <20130508225407.GA65178@elstar.local> Mail-Followup-To: "Black, David" , "opsawg@ietf.org" References: <20130508074220.GA61836@elstar.local> <8D3D17ACE214DC429325B2B98F3AE712953BA091@MX15A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712953BA091@MX15A.corp.emc.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] FW: vm mib notifications 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: Wed, 08 May 2013 22:54:17 -0000 Thanks. I do not think the MIB module makes any assumptions that make it specific to type 1 or type 2 hypervisors and reading the wiki page, it seems the boundary between the two types is somewhat fuzzy anyway. One of the goals is to allow implementation based on libvirt and I leave it as an exercise to the readers to classify the virtualization systems supported by libvirt as type 1 or type 2. ;-) http://libvirt.org/ /js On Wed, May 08, 2013 at 11:36:37AM -0400, Black, David wrote: > A type 1 hypervisor is effectively an Operating System - it runs directly on the hardware. > A type 2 hypervisor is effectively an application - it runs on an OS that runs on hardware. > > More explanation and diagrams here: https://en.wikipedia.org/wiki/Hypervisor > > Thanks, > --David > > > -----Original Message----- > > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of > > Juergen Schoenwaelder > > Sent: Wednesday, May 08, 2013 3:42 AM > > To: Tina TSOU > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] FW: vm mib notifications > > > > On Tue, May 07, 2013 at 08:31:20PM +0000, Tina TSOU wrote: > > > > > Based on the feedback I got from some readers, I think we need to > > > clarify whether this draft supports only type 1 hypervisor (directly > > > on bear metal) or if it does type 2 hypervisor (indirectly) as well, > > > and if the draft was written with both types of hypervisors. > > > > Tina, > > > > can you please clarify what you mean by type 1 hypervisor (directly on > > bear metal) or if it does type 2 hypervisor (indirectly)? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Wed May 8 20:35: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 BBE7C21F937A; Wed, 8 May 2013 20:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.112 X-Spam-Level: X-Spam-Status: No, score=-102.112 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, 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 40svJOuHOxZq; Wed, 8 May 2013 20:35:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEFF21F925B; Wed, 8 May 2013 20:35:23 -0700 (PDT) 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.44.p7 Message-ID: <20130509033523.29725.27454.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2013 20:35:23 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-hybridmac-00.txt 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, 09 May 2013 03:35:23 -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 : Hybrid-MAC Model for CAPWAP Author(s) : Chunju Shao Hui Deng Farooq Bari Rong Zhang Satoru Matsushima Filename : draft-ietf-opsawg-capwap-hybridmac-00.txt Pages : 8 Date : 2013-05-08 Abstract: The CAPWAP protocol supports two modes of operation: Split and Local MAC (medium access control), which has been described in [RFC5415].There are many functions in IEEE 802l.11 MAC layer that have not yet been clearly defined whether they belong to either the WTP (Wireless Termination Points) or the AC (Access Controller)in the Split and Local modes. Because different vendors have their own definition of these two models, depending upon the vendor many MAC layer functions continue to be mapped differently to either the WTP or AC. If there is no clear definition of split MAC and local MAC, then operators will not only need to perform vendor specific configurations in their network but will continue to experience difficulty in interoperating WTPs and ACs from different vendors. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-hybridmac-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dromasca@avaya.com Wed May 8 23:51: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 5C07421F8E59 for ; Wed, 8 May 2013 23:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.072 X-Spam-Level: X-Spam-Status: No, score=-103.072 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, 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 pI435b0mB+BV for ; Wed, 8 May 2013 23:51:30 -0700 (PDT) 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 DEB9921F869A for ; Wed, 8 May 2013 23:51:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMhGi1GHCzI1/2dsb2JhbABSgmYhN79AfRZ0gh8BAQEBAwEBAQ8oNBcEAgEIDQQEAQELFAkHJwsUCQgCBAESCBqHagELpTmbLBMEjnc4BoJuYQOdZYp8gw+CJw X-IronPort-AV: E=Sophos;i="4.87,639,1363147200"; d="scan'208";a="10720801" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 09 May 2013 02:51:12 -0400 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 May 2013 02:47:34 -0400 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.02.0328.009; Thu, 9 May 2013 02:51:11 -0400 From: "Romascanu, Dan (Dan)" To: Melinda Shore , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Planning for IETF 87 Thread-Index: AQHOTDwQnC/oYCu/B0K5fRRSC5r2uJj8adIg Date: Thu, 9 May 2013 06:51:10 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1680E5@AZ-FFEXMB04.global.avaya.com> References: <518AD2B1.50901@gmail.com> In-Reply-To: <518AD2B1.50901@gmail.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Planning for IETF 87 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, 09 May 2013 06:51:35 -0000 Hi Melinda,=20 I very much hope that draft-ietf-opsawg-rfc5066bis will be well beyond WG b= y the time we shall meet in Berlin. As you know the publication of the IEEE= 802.3.1 standard is scheduled for June, and that standard has a reference = to this document. What are your (WG chairs) plans with this document? Maybe= a (short) 2nd WG Last Call - I think we need one because of the consistent= changes in the document, but it can be a quick one. Thanks and Regards, Dan =20 > -----Original Message----- > From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf > Of Melinda Shore > Sent: Thursday, May 09, 2013 1:33 AM > To: opsawg@ietf.org > Subject: [OPSAWG] Planning for IETF 87 >=20 > It's time to start planning for IETF 87. We've requested a two- hour > slot to be shared with opsarea, and we're planning on having a > technology presentation (details later). We also have the following > working group documents: >=20 > draft-ietf-opsawg-lsn-deployment > draft-ietf-opsawg-large-flow-load-balancing > two capwap drafts > firewalls draft > draft-ietf-opsawg-rfc5066bis >=20 > Please let us know if you'd like time on the agenda. As always, we've > got a strong preference for giving time to documents that have had > discussion on the opsawg mailing list, and as always, the time is not to > be used for document presentation, but to discuss issues that were not > resolved on the mailing list or that need real-time, face-to-face > discussion. >=20 > Melinda > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Wed May 8 23:58: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 7712721F849C for ; Wed, 8 May 2013 23:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.622, 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 r1EoBFsR7Ei6 for ; Wed, 8 May 2013 23:57:55 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id A723721F8E97 for ; Wed, 8 May 2013 23:57:55 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb10so1905513pad.9 for ; Wed, 08 May 2013 23:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xmkB1I6kHfSnGPmJsB9+YMTkwJqmyZCdYfzHyN8pJQA=; b=Ehr+0zayyP/4ETFLUj5xhBdBQVSGARaT0jv1lhHeYsh8rIRBuy80RUv6uOvJSt2phl rru9yVqCgCSd9SK4HToPV5+hKfP2w4m3Th8am+5s83EBog/3fvgnldTDCNWXQdlUmIxk zEyiADTi+t5WYh70ys4B+utb0FLJpVWWWXbqz0dlDcCRH6Q7o8A8wkN5C+m8FynTJjBE 9O++t5+i/uC9BVSsABAFNKmbZF9f/M+KAzc/i/pLgv8qMjh+r2ktrh3HrLoSECnKRPLy galj85ZpTuk88saZtHseWVE46pIDEf/3Ty/rKzJk2N4mluwY/Z4rfsLklh2/joil+cbt 6sSA== X-Received: by 10.66.121.202 with SMTP id lm10mr11612977pab.138.1368082675333; Wed, 08 May 2013 23:57:55 -0700 (PDT) Received: from spandex.local (216-67-41-253-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.253]) by mx.google.com with ESMTPSA id sa6sm1866810pbb.26.2013.05.08.23.57.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 23:57:54 -0700 (PDT) Message-ID: <518B48F0.2090606@gmail.com> Date: Wed, 08 May 2013 22:57:52 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <518AD2B1.50901@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA1680E5@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1680E5@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Planning for IETF 87 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, 09 May 2013 06:58:01 -0000 On 5/8/13 10:51 PM, Romascanu, Dan (Dan) wrote: > I very much hope that draft-ietf-opsawg-rfc5066bis will be well > beyond WG by the time we shall meet in Berlin. As you know the > publication of the IEEE 802.3.1 standard is scheduled for June, and > that standard has a reference to this document. What are your (WG > chairs) plans with this document? Maybe a (short) 2nd WG Last Call - > I think we need one because of the consistent changes in the > document, but it can be a quick one. Do you consider the -02 draft ready to be sent into wg last call? It seems pretty straightforward to me, with the main section wanting scrutiny being the security considerations. Melinda From dromasca@avaya.com Wed May 8 23:59:44 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 02FB121F8E97 for ; Wed, 8 May 2013 23:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 XFbyq0XCBhlI for ; Wed, 8 May 2013 23:59:37 -0700 (PDT) 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 40B1F21F849C for ; Wed, 8 May 2013 23:59:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJVIi1GHCzI1/2dsb2JhbABSgmYhv3Z9FnSCHwEBAQEDEig/DAQCAQgNBAQBAQEKFAkHIREUCQgCBA4FCBqHWAMPAaVMkxANiBAXjFKCJTEHBoJuYQOVRwGIHYVahSKDD4In X-IronPort-AV: E=Sophos;i="4.87,639,1363147200"; d="scan'208";a="8562632" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 09 May 2013 02:59:35 -0400 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 May 2013 02:55:56 -0400 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.02.0328.009; Thu, 9 May 2013 02:59:33 -0400 From: "Romascanu, Dan (Dan)" To: Melinda Shore Thread-Topic: [OPSAWG] Planning for IETF 87 Thread-Index: AQHOTDwQnC/oYCu/B0K5fRRSC5r2uJj8adIggABF0AD//70NUA== Date: Thu, 9 May 2013 06:59:32 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1681BD@AZ-FFEXMB04.global.avaya.com> References: <518AD2B1.50901@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA1680E5@AZ-FFEXMB04.global.avaya.com> <518B48F0.2090606@gmail.com> In-Reply-To: <518B48F0.2090606@gmail.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Planning for IETF 87 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, 09 May 2013 06:59:44 -0000 > -----Original Message----- > From: Melinda Shore [mailto:melinda.shore@gmail.com] > Sent: Thursday, May 09, 2013 9:58 AM > To: Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Planning for IETF 87 >=20 > On 5/8/13 10:51 PM, Romascanu, Dan (Dan) wrote: > > I very much hope that draft-ietf-opsawg-rfc5066bis will be well beyond > > WG by the time we shall meet in Berlin. As you know the publication of > > the IEEE 802.3.1 standard is scheduled for June, and that standard has > > a reference to this document. What are your (WG > > chairs) plans with this document? Maybe a (short) 2nd WG Last Call - I > > think we need one because of the consistent changes in the document, > > but it can be a quick one. >=20 > Do you consider the -02 draft ready to be sent into wg last call? It > seems pretty straightforward to me, with the main section wanting > scrutiny being the security considerations. >=20 > Melinda [[DR]] Yes, I think so. The LC would give other people the opportunity to c= omment and raise issues.=20 Regards, Dan From melinda.shore@gmail.com Thu May 9 00:07: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 74EFE21F8E4C for ; Thu, 9 May 2013 00:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.081 X-Spam-Level: X-Spam-Status: No, score=-3.081 tagged_above=-999 required=5 tests=[AWL=0.518, 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 1RkscUDhg90a for ; Thu, 9 May 2013 00:07:23 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id A2E9221F8F3C for ; Thu, 9 May 2013 00:07:23 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id rl6so1937858pac.14 for ; Thu, 09 May 2013 00:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rZJ5GLwiJ7klH18LDKY7w4o9AfbN9TQyAleJknde2Xc=; b=b1euoN9jWcc4Fo8ta+T0rZDqonRdeqdxMMQY4NK4gSDvqHSXLSIydB0/JgU0isPs4q HA6adIFrm5WOLZkc4rlYLpBBxaUE6ivgEvNaehKc3ahYYArw/VMQMU5cPMz4OmORD0dM M9dKTFA4N+uYPA0M5uVaoYX8Y70ch0IlXw6VcMrwBQo/7pvYaVgUs8Sk9NWH8rgIDBu0 wcRP61RHqflABsYHw2I0CddPxko2nmjr8VN/sZ5uJnSA2YWShmP8SNLVtSAyIHEJ8/uk 7gYFUeEZ3hlISj8Dpt1VhHLkk8U7PhOyoeWKA9QwPQZ9rxjvf/nbcYiKA7KcGzg/p0m2 A+Dg== X-Received: by 10.68.172.65 with SMTP id ba1mr11258767pbc.166.1368083243149; Thu, 09 May 2013 00:07:23 -0700 (PDT) Received: from spandex.local (216-67-41-253-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.253]) by mx.google.com with ESMTPSA id k2sm2485552pat.7.2013.05.09.00.07.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 May 2013 00:07:22 -0700 (PDT) Message-ID: <518B4B28.5010907@gmail.com> Date: Wed, 08 May 2013 23:07:20 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <518AD2B1.50901@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA1680E5@AZ-FFEXMB04.global.avaya.com> <518B48F0.2090606@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA1681BD@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA1681BD@AZ-FFEXMB04.global.avaya.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Planning for IETF 87 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, 09 May 2013 07:07:29 -0000 On 5/8/13 10:59 PM, Romascanu, Dan (Dan) wrote: > [[DR]] Yes, I think so. The LC would give other people the > opportunity to comment and raise issues. Should this be regarded as a request for working group last call? Melinda From dromasca@avaya.com Thu May 9 00:08:57 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 3DCE321F8FB3 for ; Thu, 9 May 2013 00:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.537 X-Spam-Level: X-Spam-Status: No, score=-103.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 YUN0V3jUCybT for ; Thu, 9 May 2013 00:08:50 -0700 (PDT) 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 872CB21F8E4C for ; Thu, 9 May 2013 00:08:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAH/ZlHGmAcF/2dsb2JhbABQgmUhwX6BBxZ0gh8BAQEBAxIoPwwEAgEIDQQEAQEBChQJByERFAkIAgQOBQgah2ADDwGgR5M5DYlGF4xDgiImCwcGglphA5UeAYgKhUyFHIMLgig X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="10404391" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 May 2013 03:08:49 -0400 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 May 2013 03:04:22 -0400 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.02.0328.009; Thu, 9 May 2013 03:08:48 -0400 From: "Romascanu, Dan (Dan)" To: Melinda Shore Thread-Topic: [OPSAWG] Planning for IETF 87 Thread-Index: AQHOTDwQnC/oYCu/B0K5fRRSC5r2uJj8adIggABF0AD//70NUIAARZgA//+9KpA= Date: Thu, 9 May 2013 07:08:47 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA1681D4@AZ-FFEXMB04.global.avaya.com> References: <518AD2B1.50901@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA1680E5@AZ-FFEXMB04.global.avaya.com> <518B48F0.2090606@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA1681BD@AZ-FFEXMB04.global.avaya.com> <518B4B28.5010907@gmail.com> In-Reply-To: <518B4B28.5010907@gmail.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" , Edward Beili Subject: Re: [OPSAWG] Planning for IETF 87 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, 09 May 2013 07:08:57 -0000 I think that you need to ask Ed Beili about this.=20 Ed?=20 Dan > -----Original Message----- > From: Melinda Shore [mailto:melinda.shore@gmail.com] > Sent: Thursday, May 09, 2013 10:07 AM > To: Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] Planning for IETF 87 >=20 > On 5/8/13 10:59 PM, Romascanu, Dan (Dan) wrote: > > [[DR]] Yes, I think so. The LC would give other people the opportunity > > to comment and raise issues. >=20 > Should this be regarded as a request for working group last call? >=20 > Melinda From internet-drafts@ietf.org Thu May 9 08:52:11 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 2965821F918C; Thu, 9 May 2013 08:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.168, 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 mZo1jBBLQHnY; Thu, 9 May 2013 08:52:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E200721F8FDB; Thu, 9 May 2013 08:52:06 -0700 (PDT) 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.44.p7 Message-ID: <20130509155206.6908.55199.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 08:52:06 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-capwap-extension-00.txt 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, 09 May 2013 15:52:14 -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 : CAPWAP Extension for 802.11n and Power/channel Reconfigu= ration Author(s) : Yifan Chen Dapeng Liu Hui Deng Lei Zhu Filename : draft-ietf-opsawg-capwap-extension-00.txt Pages : 15 Date : 2013-05-09 Abstract: CAPWAP binding for 802.11 is specified by RFC5416 and it was based on IEEE 802-11.2007 standard. After RFC5416 was published in 2009, there was several new amendent of 802.11 has been published. 802.11n is one of those amendent and it has been widely used in real deployment. This document extends the CAPWAP binding for 802.11 to support 802.11n. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-extension There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-capwap-extension-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From melinda.shore@gmail.com Fri May 10 18:40: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 244CA21F85C0 for ; Fri, 10 May 2013 18:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.21 X-Spam-Level: X-Spam-Status: No, score=-3.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 9Eyq1DB19he8 for ; Fri, 10 May 2013 18:40:48 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD8321F846C for ; Fri, 10 May 2013 18:40:48 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp6so3294493pab.21 for ; Fri, 10 May 2013 18:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=JHci2/CiRaxTyo2a7IBRLZZqjXOXllLv2Yk1V4w2YSo=; b=aJPkWQ5l43kcmCvP9TznyTxKkG15Ho+6JcBCtZpDdpYeA1vk8cssap0e5hqNmcgP7j GSF+f0jPnHR95t2GOgYNlVyshaE6jB0Cq0BK7cZlRjHTCcSkHsGZkOmGebFpuBPvceKg 22ICH8UBSWyDFmfCcyLQRCAeFWtMGngEAHjRUE1eTSed5xCGlp1t//l2BONWMin+Ygvf E2SNEI3b2GYB+p4DYiCjSwV0pbRfbqFu9cF0/D6OZ0S5Z9WYieIebZx0pRSTTCYSXQZt YrOtqPGVFlq8pdlhTwiZUiTFbN+EkVAv3+VUvSciadBYecGubAXBSstI0QTN50N8xmEW V7jg== X-Received: by 10.66.155.39 with SMTP id vt7mr19911110pab.99.1368236448206; Fri, 10 May 2013 18:40:48 -0700 (PDT) Received: from spandex.local (216-67-41-253-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.253]) by mx.google.com with ESMTPSA id br2sm4510612pbc.46.2013.05.10.18.40.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 May 2013 18:40:47 -0700 (PDT) Message-ID: <518DA19D.2040709@gmail.com> Date: Fri, 10 May 2013 17:40:45 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "opsawg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] draft-ietf-opsawg-rfc5066bis 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, 11 May 2013 01:40:53 -0000 By way of an update, because of issues around staying in sync with IEEE 802.3's schedule, draft-ietf-opsawg-rfc5066bis is on an expedited schedule. It's my understanding that the authors will want to move this document into working group last call rather soon, so I'd like to ask people to take a look at the document (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/) and get comments and questions posted to the mailing list. Many thanks, Melinda From j.schoenwaelder@jacobs-university.de Fri May 10 23:01: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 961D221F86DD for ; Fri, 10 May 2013 23:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.174 X-Spam-Level: X-Spam-Status: No, score=-103.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 MDh4vVBFF9dy for ; Fri, 10 May 2013 23:01:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0032B21F8624 for ; Fri, 10 May 2013 23:01:19 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D9E8720C55; Sat, 11 May 2013 08:01:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QsuO6MmOjNJ2; Sat, 11 May 2013 08:01:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A08520C52; Sat, 11 May 2013 08:01:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 36238261F54F; Sat, 11 May 2013 08:01:09 +0200 (CEST) Date: Sat, 11 May 2013 08:01:05 +0200 From: Juergen Schoenwaelder To: Melinda Shore Message-ID: <20130511060100.GA74663@elstar.local> Mail-Followup-To: Melinda Shore , "opsawg@ietf.org" References: <518DA19D.2040709@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <518DA19D.2040709@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] draft-ietf-opsawg-rfc5066bis 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: Sat, 11 May 2013 06:01:24 -0000 On Fri, May 10, 2013 at 05:40:45PM -0800, Melinda Shore wrote: > By way of an update, because of issues around staying in > sync with IEEE 802.3's schedule, draft-ietf-opsawg-rfc5066bis > is on an expedited schedule. It's my understanding that the > authors will want to move this document into working group > last call rather soon, so I'd like to ask people to take a > look at the document > (https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis/) > and get comments and questions posted to the mailing list. I have read draft-ietf-opsawg-rfc5066bis-02 and I have no major issues. I was, however, wondering why there is a new security considerations sections. Since the I-D does not provide a reasoning (and I did not follow mailing list discussions), I ended up pulling RFC 5066 to see what was going on. I arrived at the conclusion that security considerations for the IF-CAP-STACK-MIB were simply missing in RFC 5066. Perhaps this reason for 'updated' security considerations can be simply stated upfront at the end of the Introduction so readers like me do not have to dig through other documents to find out what is going on. Another nit is to perhaps change The IF-CAP-STACK-MIB remains under IETF jurisdiction and is maintained by the [OPSAWG] working group. to The IF-CAP-STACK-MIB remains under IETF jurisdiction and is currently maintained by the [OPSAWG] working group. since WG structures and responsibilities of course may change in the IETF. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From keiichi.shima.1016@gmail.com Sun May 12 22:40:03 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 4544621F8FDB for ; Sun, 12 May 2013 22:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 3VZv6-rbK6Gt for ; Sun, 12 May 2013 22:40:02 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5698421F8F53 for ; Sun, 12 May 2013 22:40:02 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id md4so1103797pbc.7 for ; Sun, 12 May 2013 22:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=FX0krmzHqqYJynQIdhzQTwCRnN2VqDemvGdDYcGxLzQ=; b=W667Ion7ng38S9SuFI38U1GZaYUfwwB5PjJQEHzd3onE7zIsJvu4ObD3OXPAtmqlHa CPobRcfyIr5Ze5Xy2gW1i5EM+vOVT2lWlO2KxxbiPoZlJlFUbI5Ks7jbKk39h0Srphyf rHgWDIdpKJufUSvfDzL7hLpkkTg5pJuFAByxl1Qm6Fi5QXtUIV4gtvXkQ5pobl5bLWb/ 3Xo+0UgVGFLIEEQ9PuT4Dzncs/IrH3gYufy0tVwddrdqRllShwFciBxfb3S/V3rSxmWQ viN9uFgi83dCHjGpdtmKN+T2cYERw8ekSeZYAp6PExpCVG9mV8j8YPQHoRhNWaAwD/eb MOjw== X-Received: by 10.68.14.6 with SMTP id l6mr28018979pbc.202.1368423602072; Sun, 12 May 2013 22:40:02 -0700 (PDT) Received: from ?IPv6:2001:240:11e:c01:59b2:6791:5bb3:c226? ([2001:240:11e:c01:59b2:6791:5bb3:c226]) by mx.google.com with ESMTPSA id qb1sm12587434pbb.33.2013.05.12.22.39.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 12 May 2013 22:40:00 -0700 (PDT) Sender: Keiichi SHIMA Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Keiichi SHIMA In-Reply-To: <20130508225407.GA65178@elstar.local> Date: Mon, 13 May 2013 14:39:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130508074220.GA61836@elstar.local> <8D3D17ACE214DC429325B2B98F3AE712953BA091@MX15A.corp.emc.com> <20130508225407.GA65178@elstar.local> To: opsawg@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [OPSAWG] vm mib notifications 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, 13 May 2013 05:40:03 -0000 Hello all, On 2013/05/09, at 7:54, Juergen Schoenwaelder = wrote: > I do not think the MIB module makes any assumptions that make it > specific to type 1 or type 2 hypervisors and reading the wiki page, it > seems the boundary between the two types is somewhat fuzzy anyway. I also don't think we need to distinguish type 1 and 2 in the draft. = Both types can cover the information items defined in our MIB draft. This discussion reminds me of one another topic, a container, such as = LXC. It is a kind of virtualization system well deployed recently, but = we don't consider the type deeply at this moment in the draft. In my = opinion, I want to put the third type of virtualization monitor system = aside, since it has a slightly different properties compared to the type = 1 and 2 monitors. --- Keiichi SHIMA (=E5=B3=B6 =E6=85=B6=E4=B8=80) WIDE project Research Laboratory, IIJ Innovation Institute, Inc On 2013/05/09, at 7:54, Juergen Schoenwaelder = wrote: > Thanks. >=20 > I do not think the MIB module makes any assumptions that make it > specific to type 1 or type 2 hypervisors and reading the wiki page, it > seems the boundary between the two types is somewhat fuzzy anyway. >=20 > One of the goals is to allow implementation based on libvirt and I > leave it as an exercise to the readers to classify the virtualization > systems supported by libvirt as type 1 or type 2. ;-) >=20 > http://libvirt.org/ >=20 > /js >=20 > On Wed, May 08, 2013 at 11:36:37AM -0400, Black, David wrote: >> A type 1 hypervisor is effectively an Operating System - it runs = directly on the hardware. >> A type 2 hypervisor is effectively an application - it runs on an OS = that runs on hardware. >>=20 >> More explanation and diagrams here: = https://en.wikipedia.org/wiki/Hypervisor >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On = Behalf Of >>> Juergen Schoenwaelder >>> Sent: Wednesday, May 08, 2013 3:42 AM >>> To: Tina TSOU >>> Cc: opsawg@ietf.org >>> Subject: Re: [OPSAWG] FW: vm mib notifications >>>=20 >>> On Tue, May 07, 2013 at 08:31:20PM +0000, Tina TSOU wrote: >>>=20 >>>> Based on the feedback I got from some readers, I think we need to >>>> clarify whether this draft supports only type 1 hypervisor = (directly >>>> on bear metal) or if it does type 2 hypervisor (indirectly) as = well, >>>> and if the draft was written with both types of hypervisors. >>>=20 >>> Tina, >>>=20 >>> can you please clarify what you mean by type 1 hypervisor (directly = on >>> bear metal) or if it does type 2 hypervisor (indirectly)? >>>=20 >>> /js >>>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >>> Fax: +49 421 200 3103 >>> _______________________________________________ >>> OPSAWG mailing list >>> OPSAWG@ietf.org >>> https://www.ietf.org/mailman/listinfo/opsawg >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From melinda.shore@gmail.com Mon May 13 14:28: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 CC82221F9545 for ; Mon, 13 May 2013 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 1PPucqv9aFZX for ; Mon, 13 May 2013 14:28:26 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7187821F955E for ; Mon, 13 May 2013 14:28:18 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so4976572pad.30 for ; Mon, 13 May 2013 14:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=Jnw8aQCSYBwsW5cOjGZ6J/+4g/SZgeQlDz9LjRCj2Dw=; b=yS4zGvnVCqCdKwAWWtEmdXUsy7QHb/wtLfm2i00s2R58NapF86zMNuQOXZX+6m3Bq4 kw9diOYj9/28R6WRuo3k/zw9jtLSItELD16el5uL5bHYgowLBvenFg/pNaLv0LfC5IF9 9d6IlzrIN4vXpb07PevXcFCD1G4rNTPSb0f1R4PC5Jc2zPu9T7oktfh9mvPKA8VioB6M nCiVoFz0MDrWyH5wFYthsHBYKULbvmIsQOm2YXO5iwEE8K119s5r5d3qiQv4fZXm6Buu efwAxMss5Wzb8DwEXgjL9qo92YsjKxXWXTDFkNdMVqBOaPjSllIlfgId/eV/2eWo7rNs YuSQ== X-Received: by 10.66.150.168 with SMTP id uj8mr30523345pab.34.1368480498126; Mon, 13 May 2013 14:28:18 -0700 (PDT) Received: from spandex.local (216-67-41-253-rb1.fai.dsl.dynamic.acsalaska.net. [216.67.41.253]) by mx.google.com with ESMTPSA id lq4sm10377782pab.19.2013.05.13.14.28.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 14:28:16 -0700 (PDT) Message-ID: <51915AEC.8010406@gmail.com> Date: Mon, 13 May 2013 13:28:12 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <7ABACB5F-A36C-4F07-801E-585FFEA50CD5@verisign.com> In-Reply-To: <7ABACB5F-A36C-4F07-801E-585FFEA50CD5@verisign.com> X-Forwarded-Message-Id: <7ABACB5F-A36C-4F07-801E-585FFEA50CD5@verisign.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: NomCom 2013-2014 Call for Volunteers 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, 13 May 2013 21:28:33 -0000 It's that time! Please give some thought to participating in this year's NomCom. This is a terrific way to contribute to the IETF. Melinda -------- Original Message -------- Subject: NomCom 2013-2014 Call for Volunteers Date: Mon, 13 May 2013 21:08:59 +0000 From: Mankin, Allison To: ietf-announce@ietf.org The IETF nominating committee (nomcom) process for 2010-11 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF! I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all volunteer mail (and any questions/comments you may have) to the address given. From melinda.shore@gmail.com Mon May 20 11:28: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 209EF21F961B for ; Mon, 20 May 2013 11:28:22 -0700 (PDT) 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 IQtGb2oPZg9j for ; Mon, 20 May 2013 11:28:20 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 63F6521F8648 for ; Mon, 20 May 2013 11:28:20 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id z17so4054516dal.27 for ; Mon, 20 May 2013 11:28:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=ZU0ajRQyNWKx/rD1q313+XMoiyu7E0eZZ20G8kaIBJc=; b=KqvtqG9gSt1MbMeU5g0v6cGM/Vo/EMIfJ534HJj4bqNqQrdCWfB7k0pR6nlzwQ054E kvon1nsj5wkVgTLzKLDqr+N3zaYRq6kGwXYhIPV+0fOYhzZLHCnp7tefoF6WSoXOFF3L mSmcxZueEnlZePNwCl+zthp47v1vlMm3XQMrU+KH+I6Ty7W14xFP3fHrBn52S7vDGuC8 qozEunbPMMW9tls90ERaPLqxn0mvkthjGL5s8uEEJp0jhOhkQaIvdvnHIThW8MRXnrCA /EO91wqiTmVbqovek9KNPKunX5QbGi7E0qV25PnXOVIeOLBVlUYk2yJjmLEzFBivYdO4 XwAg== X-Received: by 10.66.217.226 with SMTP id pb2mr62231496pac.109.1369074499871; Mon, 20 May 2013 11:28:19 -0700 (PDT) Received: from spandex.local (66-230-84-243-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.243]) by mx.google.com with ESMTPSA id b7sm25050691pba.39.2013.05.20.11.28.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 11:28:18 -0700 (PDT) Message-ID: <519A6B40.2000602@gmail.com> Date: Mon, 20 May 2013 10:28:16 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <20130520141358.GS582@mournblade.imrryr.org> In-Reply-To: <20130520141358.GS582@mournblade.imrryr.org> X-Forwarded-Message-Id: <20130520141358.GS582@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: [dane] Discussion: New draft: DANE ops 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, 20 May 2013 18:28:22 -0000 Possibly of interest. Melinda -------- Original Message -------- Subject: [dane] Discussion: New draft: DANE ops Date: Mon, 20 May 2013 14:13:58 +0000 From: Viktor Dukhovni Reply-To: dane@ietf.org To: dane@ietf.org https://tools.ietf.org/id/draft-dukhovni-dane-ops-00.html This draft covers the operational guidance from lessons learned while implementing DANE TLSA support for Postfix. This is not claimed to be comprehensive, and would likely benefit from additional contributions. -- Viktor. _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From melinda.shore@gmail.com Mon May 20 11:28: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 B6A1821F9617 for ; Mon, 20 May 2013 11:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 xQ33L1Ae6hHG for ; Mon, 20 May 2013 11:28:45 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A43521F960B for ; Mon, 20 May 2013 11:28:45 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id lj1so5931399pab.18 for ; Mon, 20 May 2013 11:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=FmeOyjLAcVX72TML9kVRfhtEpVEGFMroItgKJWlRov0=; b=IV1R1FG2aZaX+vy/utDKd0Rq8T0jTR5LR7velfBw+c8QpIZsYckZRa/XeUZJ14HYmB hwn3n0+MaWS9HpaLWNqUkLaNDnblRXXsHEx8+5KyDCy6uNwiNYzGvkVQMQfb9HvKZVtd cRK1TBoAGWXrZ2Xhw3NAXIuUQjs4C6Fc8OW4TtEspcVVTfX8gAur9G4PJnp1dvvhMOh4 z5sKdZv3XWIZVfBS4fEzt+eu2998UyZ5Ou6gvlgFopYr8oCt01ZDHCBD7YmxSz9XqnLi DvIlntzeKxdCChpqoJA6j6zp6tlRQJUht6u+hFySCwq4pf6WRJjDYZb/78dS3J6oVEH9 DsXA== X-Received: by 10.68.163.132 with SMTP id yi4mr61765907pbb.64.1369074524751; Mon, 20 May 2013 11:28:44 -0700 (PDT) Received: from spandex.local (66-230-84-243-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.84.243]) by mx.google.com with ESMTPSA id fn9sm26860396pab.2.2013.05.20.11.28.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 May 2013 11:28:43 -0700 (PDT) Message-ID: <519A6B59.4040000@gmail.com> Date: Mon, 20 May 2013 10:28:41 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <519A36D1.4000109@gmail.com> In-Reply-To: <519A36D1.4000109@gmail.com> X-Forwarded-Message-Id: <519A36D1.4000109@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: [domainrep] Working Group Last Call on Operational Considerations Regarding Reputation Services 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, 20 May 2013 18:28:49 -0000 Also, this. Melinda -------- Original Message -------- Subject: [domainrep] Working Group Last Call on Operational Considerations Regarding Reputation Services Date: Mon, 20 May 2013 07:44:33 -0700 From: Dave Crocker To: domainrep@ietf.org Folks, This is to announce the start of a WG last call on: Operational Considerations Regarding Reputation Services http://datatracker.ietf.org/doc/draft-ietf-repute-considerations/ It is intended for publication as an Informational RFC. Please provide any feedback by the 3 June 2013. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ domainrep mailing list domainrep@ietf.org https://www.ietf.org/mailman/listinfo/domainrep From ietfdbh@comcast.net Mon May 20 14:14: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 4AFBF21F842A for ; Mon, 20 May 2013 14:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 RTxiuG0av2Kf for ; Mon, 20 May 2013 14:14:23 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0E721F9662 for ; Mon, 20 May 2013 14:14:23 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id eDDj1l00827AodY5CMENJR; Mon, 20 May 2013 21:14:22 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta19.westchester.pa.mail.comcast.net with comcast id eMEN1l00E2yZEBF3fMENH1; Mon, 20 May 2013 21:14:22 +0000 From: "ietfdbh" To: , Date: Mon, 20 May 2013 17:14:12 -0400 Message-ID: <009101ce559e$fa534d00$eef9e700$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5VnuvxqfWW0pimSzi4DbiXwxgawA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369084462; bh=xEZV5u/6lnWGzERAEs1GxcQxhuKeoqS+upOZeSlGZz4=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=rts52TM7gVlx0WRkj0nfbEa4wZaBP/qNbdzWlKwg704x9hpM1SXT7O2zA8bBDGwYm XyTVCVpqZ0rBUSRQIB1oGcoTtEFSoK3b02YuDrPvxbjkMQU29QMbfkr5Wh5T6r55nP EnipUb1wUKD+hYLKeFe8cYdmVSG8g921bWXjwUI0+j2WUihaT27/p03DTFv6Q/u8xw OKDnehpk6NutAHho41UV6VJQJldhfxMivASG1+lAT59jZwQdegtfr5RbjvyCXI+9QU O+z/G8by1H5tQLdq7lqG7zNC2ORhtGcaT5CF1rXlq/L5X6iepirTjl33D1J0AnTXzU s1tx3k3yA9ivA== Subject: [OPSAWG] [domainrep] Working Group Last Call on Operational Considerations Regarding Reputation Services 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, 20 May 2013 21:14:28 -0000 Hi, A few comments: 1) s/This document includes a collection of the best advice available/This document includes a collection of advice/ Since this is not being published as a BCP, I think this change is called for. Some text discusses "recent proposals", which I suspect have not risen to "best advice available". 2) This document would benefit from a more definitive listing of the points of advice. Quite a few points are made simply by examples, and some "suggestions" of things to consider. This is only Informational, and contains operational **considerations**, but it feels awfully loose to me. It feels like the musings of the author, rather than a peer-reviewed, WG-approved, considerations document. 3) While I don't question the technical merits of the document, I think this document is not ready for publication, for quality reasons. Much of the text could be significantly tightened up; it rambles a bit. There are spelling and grammar errors that should have been caught during earlier WG reviews. This makes me question how thoroughly the WG has reviewed this document. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of Melinda Shore Sent: Monday, May 20, 2013 2:29 PM To: opsawg@ietf.org Subject: [OPSAWG] Fwd: [domainrep] Working Group Last Call on Operational Considerations Regarding Reputation Services Also, this. Melinda -------- Original Message -------- Subject: [domainrep] Working Group Last Call on Operational Considerations Regarding Reputation Services Date: Mon, 20 May 2013 07:44:33 -0700 From: Dave Crocker To: domainrep@ietf.org Folks, This is to announce the start of a WG last call on: Operational Considerations Regarding Reputation Services http://datatracker.ietf.org/doc/draft-ietf-repute-considerations/ It is intended for publication as an Informational RFC. Please provide any feedback by the 3 June 2013. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ domainrep mailing list domainrep@ietf.org https://www.ietf.org/mailman/listinfo/domainrep _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From mrm@vmware.com Mon May 20 17:51: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 672AB21F9748 for ; Mon, 20 May 2013 17:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 pfO3y6lLKFhz for ; Mon, 20 May 2013 17:51:24 -0700 (PDT) Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0919421F9744 for ; Mon, 20 May 2013 17:51:23 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 87AAC28A79; Mon, 20 May 2013 17:51:23 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id 85150B0B2E; Mon, 20 May 2013 17:51:23 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 68903E00D4; Mon, 20 May 2013 17:51:23 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Mon, 20 May 2013 17:51:23 -0700 (PDT) Date: Mon, 20 May 2013 17:51:23 -0700 (PDT) From: Michael MacFaden To: Randy Presuhn Message-ID: <1580225649.5006750.1369097483192.JavaMail.root@vmware.com> In-Reply-To: <002001ce37a8$db221380$6b01a8c0@oemcomputer> References: <00f101ce373a$0cce4a80$6b01a8c0@oemcomputer> <20130412063647.GA14310@elstar.local> <002001ce37a8$db221380$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: draft-asai-vmm-mib: Issues on notifications Thread-Index: LtgQzqUjNNjKIctIVPyyJO7/2LY3yg== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] draft-asai-vmm-mib: Issues on notifications 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, 21 May 2013 00:51:29 -0000 Have since posted my edits. My thinking is that having the set of VMs in the notification is useful the mgmt app, If we go with only the hypervisor in the notification, then would think we'd need to provide an alternate indexing scheme such as TimeFilter make polling for changes since last poll simpler. Having used TimeFilter in the past, that experienc was downright well painful. Hence the solution above borrowing from RFC 2674. Thanks, Mike ----- Original Message ----- > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Thursday, April 11, 2013 11:36 PM > > Subject: Re: [OPSAWG] draft-asai-vmm-mib: Issues on notifications > ... > > > > o Issue 1-1) Scalability issue on notifications: The number of > ... > > I think Michael wanted to post notification definitions that help > > reduce the number of notifications emitted if for example all virtual > > machines of a hypervisor change state at about the same time (e.g., > > because the physical server is restarted). This may be a good thing > > since it reduces the number of notifications at the source and as > > such works independently of RFCs 3014 or 3877. > > For that specific use case, a notifcation identifying the hypervisor > to which those VMs belong, rather than the individual virtual machines, > would seem a better way to go. One might even argue that the > coldStart notification type could be sufficient to do the job. > > Randy > > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From j.schoenwaelder@jacobs-university.de Tue May 21 01:57: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 A9B0C21F97C7 for ; Tue, 21 May 2013 01:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.141 X-Spam-Level: X-Spam-Status: No, score=-103.141 tagged_above=-999 required=5 tests=[AWL=0.108, 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 BbSoloM8+B+f for ; Tue, 21 May 2013 01:57:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 35FCC21F97A0 for ; Tue, 21 May 2013 01:57:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 915E620C13; Tue, 21 May 2013 10:57:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id lRVNh8t2rTNF; Tue, 21 May 2013 10:57:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D8BDA20C12; Tue, 21 May 2013 10:57:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B9D9F265B5BB; Tue, 21 May 2013 10:57:36 +0200 (CEST) Date: Tue, 21 May 2013 10:57:36 +0200 From: Juergen Schoenwaelder To: Michael MacFaden Message-ID: <20130521085736.GC8637@elstar.local> Mail-Followup-To: Michael MacFaden , opsawg@ietf.org References: <20130425052946.GA31100@elstar.local> <1387501794.10777455.1366910270075.JavaMail.root@vmware.com> <20130503054559.GB4048@elstar.local> <877135605.1243086.1367876525799.JavaMail.root@vmware.com> <884302919.2139141.1367951225248.JavaMail.root@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <884302919.2139141.1367951225248.JavaMail.root@vmware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] suggested updates to draft-asai-vmm-mib-03.txt 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, 21 May 2013 08:57:51 -0000 On Tue, May 07, 2013 at 11:27:05AM -0700, Michael MacFaden wrote: > > Juergen wrote: > >can you please send this message to the OPSAWG mailing list? We need > >to move discussions over to the list. > > Attached please find my suggested patch to the draft-asai-vmm-mib-03.txt > > In short: > > 1. Introduce a new TC called VirtualMachineList. It > is a clone of Q-BRIDGE-MIB PortList > > 2. Introduce a new managed object, vmBulkNotificationsEnabled, to report which type > of events to receive, either bulk or existing per vm notifications. > > 3. Adds a parallel set of notifications to match: vmRuning, vmShutdown, vmPaused, > vmSuspended, vmCrashed, vmDeleted that only send a new accessible-for-notify > variable vmAffectedVMs using SYNTAX VirtualMachineList. Thanks Michael. I am wondering whether we should really have two sets of notifications. I know that we discussed this before but lets me ask again: How large is the number of VMs per hypervisor going to be we have to plan for? I am asking so that I can get an idea what the length of vmAffectedVMs might be - I guess we are fine but I just thought I ask. And of course, with your notification design, it makes a lot of sense to assign small VirtualMachineIndex values (right now, I can choose 2147483647 as vmIndex but that would be a really bad choice for your new notifications). The old notifications carry more information. Hence, if we would move to the new notifications, a management application may send subsequent read requests to obtain that information. But perhaps this is OK since this is under the control of the management application (while a notification blast is not). > Lastly, I've added some comments (grep mrm) about what clients > should expect with vmName, vmUUID, vmIndex based on my prior > deployment experience with the similarly structured VMWARE-VMINFO-MIB. These make sense to me. /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 May 21 15:24:07 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 8A2011F0D48 for ; Tue, 21 May 2013 15:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Y4DM5wZkoIKt for ; Tue, 21 May 2013 15:24:00 -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 E971E1F0D3A for ; Tue, 21 May 2013 15:24:00 -0700 (PDT) Received: from sc9-mailhost2.vmware.com (sc9-mailhost2.vmware.com [10.113.161.72]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id AA1A628275; Tue, 21 May 2013 15:24:00 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id A6408B0824; Tue, 21 May 2013 15:24:00 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 933F1E0107; Tue, 21 May 2013 15:24:00 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Tue, 21 May 2013 15:24:00 -0700 (PDT) Date: Tue, 21 May 2013 15:24:00 -0700 (PDT) From: Michael MacFaden To: Juergen Schoenwaelder Message-ID: <577102858.5948575.1369175040206.JavaMail.root@vmware.com> In-Reply-To: <20130521085736.GC8637@elstar.local> References: <20130425052946.GA31100@elstar.local> <1387501794.10777455.1366910270075.JavaMail.root@vmware.com> <20130503054559.GB4048@elstar.local> <877135605.1243086.1367876525799.JavaMail.root@vmware.com> <884302919.2139141.1367951225248.JavaMail.root@vmware.com> <20130521085736.GC8637@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: suggested updates to draft-asai-vmm-mib-03.txt Thread-Index: hIOo/T/36FMzJiXZF4K7DZgBbkdAag== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] suggested updates to draft-asai-vmm-mib-03.txt 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, 21 May 2013 22:24:07 -0000 > > Juergen wrote: > Thanks Michael. I am wondering whether we should really have two sets > of notifications. Indeed. Let's discuss how the application would be expected to use either notification. > I know that we discussed this before but lets me ask again: How large > is the number of VMs per hypervisor going to be we have to plan for? 1000 virtual machines per hypervisor, 100 hypervisors per mgmt controller system is the present design points is where we are today. > am asking so that I can get an idea what the length of vmAffectedVMs > might be - I guess we are fine but I just thought I ask. Sure. > And of course, with your notification design, it makes a lot of sense to > assign small VirtualMachineIndex values (right now, I can choose > 2147483647 as vmIndex but that would be a really bad choice for your > new notifications). Yes, and starting a simple index from 1 remains a strong SNMP convention since RFC 1213 through RFC 2863 for ifIndex. > The old notifications carry more information. Hence, if we would move > to the new notifications, a management application may send subsequent > read requests to obtain that information. The value of the additional information for a mgmt system that uses notifications for trap-directed polling is redundant. The procedure I had in mind for the mgmt app would be as follows: 1. poll the entire vm table say every X minutes. 2. any traps received would trigger an ad-hoc poll to update only those indicies using get or get bulk. 3. lather, rinse and repeat Now if a hypervisor boots with 1000 vms, then you've got 1000 notifications instead of one and the initial state isn't going to be very useful, mgmt system knows the hypervisor just booted if it was either polling it sysUptime and/or got a coldStart notification > But perhaps this is OK since > this is under the control of the management application (while a > notification blast is not). Right, if the design for the mgmt app is something like: 1. do an initial poll the agent vm table and collect all state 2. from then on mgmt uses the notifications to maintain state 3. reload agent table based on a consistency check or agent cold|warmStart/sysUptime rollover A consistency check is typically done by: + comparing a sequence number varbind in the event to the last one received + comparing a scalar lastChange varbind to a regular get of lastChange.0 on the vm table As you can see from my patch, by including the managed object vmBulkNotificationsEnabled, I believe both models merit inclusion in the standard. Cheers, Mike MacFaden From j.schoenwaelder@jacobs-university.de Wed May 22 00:20: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 120F421F9195 for ; Wed, 22 May 2013 00:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.158 X-Spam-Level: X-Spam-Status: No, score=-103.158 tagged_above=-999 required=5 tests=[AWL=0.091, 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 93HL5SyXDTfg for ; Wed, 22 May 2013 00:20:27 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D088021F9180 for ; Wed, 22 May 2013 00:20:26 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02BC020BF3; Wed, 22 May 2013 09:20:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id g4mc6oCl2oIY; Wed, 22 May 2013 09:20:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DB1C20BF0; Wed, 22 May 2013 09:20:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3B424265ECF0; Wed, 22 May 2013 09:20:23 +0200 (CEST) Date: Wed, 22 May 2013 09:20:22 +0200 From: Juergen Schoenwaelder To: Michael MacFaden Message-ID: <20130522072022.GA14773@elstar.local> Mail-Followup-To: Michael MacFaden , opsawg@ietf.org References: <20130425052946.GA31100@elstar.local> <1387501794.10777455.1366910270075.JavaMail.root@vmware.com> <20130503054559.GB4048@elstar.local> <877135605.1243086.1367876525799.JavaMail.root@vmware.com> <884302919.2139141.1367951225248.JavaMail.root@vmware.com> <20130521085736.GC8637@elstar.local> <577102858.5948575.1369175040206.JavaMail.root@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <577102858.5948575.1369175040206.JavaMail.root@vmware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] suggested updates to draft-asai-vmm-mib-03.txt 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: Wed, 22 May 2013 07:20:32 -0000 On Tue, May 21, 2013 at 03:24:00PM -0700, Michael MacFaden wrote: > > And of course, with your notification design, it makes a lot of sense to > > assign small VirtualMachineIndex values (right now, I can choose > > 2147483647 as vmIndex but that would be a really bad choice for your > > new notifications). > > Yes, and starting a simple index from 1 remains a strong SNMP > convention since RFC 1213 through RFC 2863 for ifIndex. We better be explicit if we adopt your notifications. I have seen boxes with rather large ifIndex values that seemed to resemble memory locations of device drivers. > As you can see from my patch, by including the managed object > vmBulkNotificationsEnabled, I believe both models merit inclusion in > the standard. Yes, but whether an application is fine with bulk notifications or prefers separate notifications is actually a function of the application behind the notification receiver. In other words, I can see situations where some notification receivers prefer bulk notifications while others prefer the other type of notifications. In principle, SNMPv3 has a mechanism to deal with this, namely the notification filtering mechanism described in section 6 of RFC 3413. So perhaps the way to go is to have two 'enable' objects that enable the generation of the two classes of notifications (so you can enable both, only one of them, or none) and to add explicit text how RFC 3413 notification filtering can be used to control which notification receiver receives certain notifications. Makes sense? /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 Wed May 22 14:46:58 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 4E4E311E813A for ; Wed, 22 May 2013 14:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 em4-u-6LJgJV for ; Wed, 22 May 2013 14:46:53 -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 22A1611E8123 for ; Wed, 22 May 2013 14:46:53 -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 A1D2628B90; Wed, 22 May 2013 14:46:52 -0700 (PDT) Received: from zcs-prod-mta-1.vmware.com (zcs-prod-mta-1.vmware.com [10.113.163.63]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 9D689189A6; Wed, 22 May 2013 14:46:52 -0700 (PDT) Received: from zcs-prod-mta-1 (localhost.localdomain [127.0.0.1]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP id 889BFE00FE; Wed, 22 May 2013 14:46:52 -0700 (PDT) Received: from zcs-prod-mbox-9.vmware.com (lbv-sc9-t2prod2-int.vmware.com [10.113.160.246]) by zcs-prod-mta-1.vmware.com (Postfix) with ESMTP; Wed, 22 May 2013 14:46:52 -0700 (PDT) Date: Wed, 22 May 2013 14:46:52 -0700 (PDT) From: Michael MacFaden To: Juergen Schoenwaelder Message-ID: <1071309284.6899982.1369259212240.JavaMail.root@vmware.com> In-Reply-To: <20130522072022.GA14773@elstar.local> References: <20130425052946.GA31100@elstar.local> <1387501794.10777455.1366910270075.JavaMail.root@vmware.com> <20130503054559.GB4048@elstar.local> <877135605.1243086.1367876525799.JavaMail.root@vmware.com> <884302919.2139141.1367951225248.JavaMail.root@vmware.com> <20130521085736.GC8637@elstar.local> <577102858.5948575.1369175040206.JavaMail.root@vmware.com> <20130522072022.GA14773@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.113.163.67] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - GC23 (Mac)/8.0.3_GA_5664) Thread-Topic: suggested updates to draft-asai-vmm-mib-03.txt Thread-Index: 5ATsnGGlujLu6QPdXHMvfpsFVKaTug== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] suggested updates to draft-asai-vmm-mib-03.txt 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, 22 May 2013 21:46:58 -0000 Juergen writes: > Yes, but whether an application is fine with bulk notifications or > prefers separate notifications is actually a function of the > application behind the notification receiver. In other words, I can > see situations where some notification receivers prefer bulk > notifications while others prefer the other type of notifications. At scale per-vm notifications require more resources to avoid classic producer-consumer issues. Having both will be unlikely to exist for long in a given operator's IT system as it grows however I do concede that it will happen. An CSP (cloud service provider) will not use both because: a) at scale if they did enable both they'd quickly discover that notifications (from this mib module and others) were being dropped as multiple hypervisors would pummel their notification receivers with per-vm notifications and so would quickly shut off/filter out per-vm notifications. b) CSP would not deploy two applications that do the same thing The case that where both might exist will happen in the enterprise account or maybe a small CSP where the shop scale ranges from say tens of hypervisors to hundreds of VMs (eg not Verizon). Again CSP don't deploy multiple monitoring solutions for the same thing but I have seen multiple solutions deployed in the enterprise IT systems, typically where monitoring is less, shall we say, a core competency. > In principle, SNMPv3 has a mechanism to deal with this, namely the > notification filtering mechanism described in section 6 of RFC 3413. This is true in practice as well. Most agents have a way to allow operators to configure their agents to filter out particular notifications they don't want. In VMware ESXi 5.1 its (esxcli system snmp set -n ,...) > So perhaps the way to go is to have two 'enable' objects that enable > the generation of the two classes of notifications (so you can enable > both, only one of them, or none) and to add explicit text how RFC 3413 > notification filtering can be used to control which notification > receiver receives certain notifications. > > Makes sense? Yes it does. And I'd leave the defaults as to which is enabled to the vendors particular implementations as anyone who remembers the pain of some product thinking it knew best about what to enable by default, cisco ios enabling proxy-arp by default comes to mind. Cheers, Mike MacFaden From melinda.shore@gmail.com Thu May 30 00:48: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 BD49421F975C for ; Thu, 30 May 2013 00:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 QGRmK1r8w96o for ; Thu, 30 May 2013 00:48:49 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 054D121F974F for ; Thu, 30 May 2013 00:48:48 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so10610023pbb.13 for ; Thu, 30 May 2013 00:48:48 -0700 (PDT) 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:references :in-reply-to:x-forwarded-message-id:content-type :content-transfer-encoding; bh=e1O0EcNoZFbR3IEylEaF1+EJmGJo19lqgCxVnr31QSI=; b=uMOuxhgovxB9+4aFvirmwgozrb1i3NILDqxm91ZoARpZdBKr2i+kYoNLeVrR5cfPSA vCpWnSOHtPi/ccim5M265OtO0iJZ3Nos/mWUAEG/cOPMnee67ae/mxS9oia1TETSFMpi EEvn2RRG3qZGJG3SBXIoO7auqYdVCvk0Bz5hPt1q8VIY2WcoK8p+GXBMATBE3lqUMHkP OrQ0V9+BPikxik7gRmTK9GKvwSRkgZzjlOQw5FpI2PsKuPgOWj3+BIuErF1pRNiPM9Pe 7w9LWZKCvjLC56DWJkQzez+Jw3DjIBLcsEILsshE/bO3sTREFb/5d8zWu4GL50/9Z2/E xySQ== X-Received: by 10.66.121.202 with SMTP id lm10mr7185333pab.138.1369900128793; Thu, 30 May 2013 00:48:48 -0700 (PDT) Received: from spandex.local (66-230-82-15-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.82.15]) by mx.google.com with ESMTPSA id fr1sm40810704pbb.26.2013.05.30.00.48.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 May 2013 00:48:48 -0700 (PDT) Message-ID: <51A7045E.4010203@gmail.com> Date: Wed, 29 May 2013 23:48:46 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "opsawg@ietf.org" References: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> In-Reply-To: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> X-Forwarded-Message-Id: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Fwd: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call 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, 30 May 2013 07:48:49 -0000 Second call for nomcom volunteers. Please give this some consideration. If you've been wondering how to contribute to the work of the IETF, this is an excellent opportunity. Melinda -------- Original Message -------- Subject: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call Date: Wed, 29 May 2013 21:08:56 +0000 From: Mankin, Allison Reply-To: Mankin, Allison To: ietf-announce@ietf.org CC: Sorry - my eye was on entering the reply-to field and then I forgot....apologies in advance for pain that may result from this lapse. On May 29, 2013, at 5:04 PM, "Mankin, Allison" wrote: > Hi, everyone, > > Remember that I'm challenging the IETF to come up with 200 volunteers for > the upcoming nomcom. You can volunteer just by hitting Reply to this email. > > What are you waiting for?? The more volunteers we get, the better chance we > have of choosing a random yet representative cross section of the IETF > population. Respond to the 200-volunteer challenge and hit Reply right now. > (Well, much as I want you to do this, please look below at the posts being > filled and be sure you are willing to forgo trying for any of them this year). > > The official information: > The IETF nominating committee (nomcom) process for 2013-14 is under way. The > IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, > and the IESG. Ten voting members for the nomcom are selected in a verifiably > random way from a pool of volunteers. > > The details of the selection and operation of the nomcom can be found > in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, > 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. > > Volunteers must have attended 3 of the past 5 IETF meetings. As specified in > RFC 3777, that means three out of the five past meetings up to the time this > email announcement goes out to start the solicitation of volunteers. The five > meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. > > If you qualify, reply to this email and volunteer. > > The list of people and posts whose terms end with the March 2014 IETF > meeting, and thus the positions for which this nomcom is responsible, are > IAOC: > Chris Griffiths > > IAB: > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig > > IESG: > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) > > The primary activity for this nomcom will begin in July 2013 and should be > completed in January 2014. Being a nomcom member will require some time > commitment - there will be interviews with candidates at meetings, regularly > scheduled conference calls to ensure progress, collection and review of > requirements from the commitment, review of candidate questionnaires and > of community feedback. A more detailed timetable for the nomcom tasks > will appear soon. > > Please respond to this email before 11:59 pm EDT (UTC -4 hours) > June 16, 2013. In the body include: > 1. your Given Name as you enter it when you register for the IETF > 2. your Family Name as you enter it when you register for the IETF > 3. your current primary affilation (the information you enter into the Company field) > 4. any/all email addresses you've used to register for IETF meetings > 5. which email address you prefer > 6. your phone number (for our use in confirming you if selected). > > You should expect an email response from me within 3 business days stating > whether or not you are qualified (and added to the list). If you don't receive this > response, please re-send your email adding the tag "RESEND" to the subject line. > > Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. > Please help us meet the 200-volunteer challenge by hitting Reply to this message today. > > Allison > > Allison Mankin > Nomcom Chair 2013-2014 From ssenthil@cisco.com Fri May 31 07:51:05 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 50A0F21F8D31 for ; Fri, 31 May 2013 07:51:05 -0700 (PDT) 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 5oQjWdolY+Qz for ; Fri, 31 May 2013 07:50:59 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 12FAE21F86D5 for ; Fri, 31 May 2013 07:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22781; q=dns/txt; s=iport; t=1370011859; x=1371221459; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=8as8NwCAsh3ft6GlxlTbn13W49ONrVlWnqo7SWlooqg=; b=X7vRPEJaI+ujkFLN+9maHzzfJxE0s8HXW/oycLtf1pP1Px0amZnlLDPF ia550HV/OhA0CBB9EqrNaFdgUZmIg0oUfj/yowPSUhmgp3+kqcX4yrO+X YixqrSHpQmjUw/Qr/In1B+5+g3XhivIyaeOEkTMQdIvM9GgVscZ2QZHE6 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFALa3qFGtJXG//2dsb2JhbABagkVEvxqBAhZ0giMBAQEEeRIBCBEDAQILFgc5FAkIAgQBDQUIiAW6YY5rIBEHBoJwYQOTbZURgw+CJw X-IronPort-AV: E=Sophos;i="4.87,779,1363132800"; d="scan'208,217";a="217319890" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 31 May 2013 14:50:58 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4VEowcj019427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 14:50:58 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.94]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Fri, 31 May 2013 09:50:58 -0500 From: "Senthil Sivakumar (ssenthil)" To: "Senthil Sivakumar (ssenthil)" , "opsawg@ietf.org" Thread-Topic: [OPSAWG] Comments on draft-ietf-opsawg-firewalls-01 Thread-Index: AQHOFnppkdk5QJkALUmQ3JMQOfkiuZkgAFCA Date: Fri, 31 May 2013 14:50:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [64.102.83.112] Content-Type: multipart/alternative; boundary="_000_CB1B483277FEC94E9B58357040EE5D0232592556xmbrcdx15ciscoc_" MIME-Version: 1.0 Cc: "paul.hoffman@vpnc.org" Subject: Re: [OPSAWG] Comments on draft-ietf-opsawg-firewalls-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: Fri, 31 May 2013 14:51:06 -0000 --_000_CB1B483277FEC94E9B58357040EE5D0232592556xmbrcdx15ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Is there going to be a new revision of this draft? It appears the draft has= expired. I didn=92t see any response to the comments I made a few months a= go. Senthil From: Senthil Sivakumar > Date: Friday, March 1, 2013 8:43 AM To: "opsawg@ietf.org" > Subject: [OPSAWG] Comments on draft-ietf-opsawg-firewalls-01 At a very high level, it is not clear what this document is set out to achi= eve and what it really delivers. Particularly section 2, I really cant tell what value that this section add= s. The document says it is a BCP, so should it have a set of requirements from= a firewall vendor and operator to be effective. Without a set of requirements, this looks more like an informational docume= nt than a BCP. Specific comments below: Section 1: I would add the following about the generic nature of firewalls. "Firewalls generally operate under the notion of trusted and untrusted netw= ork domains. For example, an enterprise that employs the firewall will be considered a t= rusted domain. Flows that are originated from the trusted domain is considered as untruste= d. The packets are filtered using static and dynamic policies as defined or le= arned " Nit: An application-layer gateway (ALG) in front of a server creates a perimeter between that server and the network it is connected to. The ALG blocks some of the flows in the application protocol based on policies such as "do not all traffic from this network" and "do not allow the client to send a message of this type". s/do not all/do not allow/ Layer 4: Most firewalls can filter based on TCP and UDP ports. Many (but, frustratingly, not all) firewalls can also filter based on transports other than TCP and UDP. - Most L4 firewalls filter packets based on TCP sequence and ack numbers. T= his essentially makes the firewall a single point of failure and hence preventing asymmetric rout= ing. - Firewalls handle out of order fragments and in some cases reassembling th= e fragments to be able to inspect the L7 payload. - When a firewall suspects an attack, it sends a reset to both ends to clea= n up the connection. I personally don=92t like that, but firewalls spoof th= ese resets. "Note that many firewall devices can only create policies at one or two of = the layers." Can you please add some text on why that is the case or basis for the abov= e. Section 3.2: The section introduces the outside and inside terminology without defining = what they are. A terminology section may be necessary or some context of what outside and = inside are. I would rather prefer trusted and untrusted instead of inside and outside, = respectively. Section 4. I would highlight the inability of firewall to do Deep Packet Inspection on= encrypted traffic and hence Firewalls that look deep into the payload to make decisions are ineffective= . There are a lot of firewall capabilities that are useful to the operators l= ike: - Syn attacks can be avoided Tiny fragment attacks Should have logs turned on for major events. Section 5 I think it is pretty useful to require the firewall vendors to align the ti= meouts between NAT & Firewall, as they are deployed together. Similarly a device that has both NAT & firewall should work in tandem when = the ALGs are deployed otherwise the applications wont work. This can be in the section 4 too, as it requires the operators to understan= d that these ALGs should be enabled for both NAT & Firewall. Provide firewall logging facility of suspected attacks. I don=92t believe there is a standard firewall MIB, but that would be a use= ful one to suggest too. Firewalls do handle fragmented traffic and deal with out of order fragments= . It seems both sections 4 & 5 need some focused text on what the requirement= s are from a vendor and from an operator. Appendix A: Their security is a side-effect of their design. [[[ MORE HERE about the history and why some operators mistake the security policy of NATs with firewalls. ]]] I would suggest the following text for appendix A: "Many NAT devices implement End-point dependent mapping [as defined in RFC = 4787] and as a result, only the flows that are originated from a trusted or inside domain, will re= sult in a NAT mapping creation. This mapping Will have the destination address & port information, unless the return tra= ffic comes from the same destination address & port, NAT will drop the packet. This is not because of a security policy but sinc= e NAT's mapping database cannot find a matching entry. This gives an illusion that NAT is a security feature by disallowing traffi= c that was originated from outside. For traffic originated from the untrusted domain, the NATs most likely wont= have a matching mapping entry to allow the traffic through and hence the traffic is dropped." --_000_CB1B483277FEC94E9B58357040EE5D0232592556xmbrcdx15ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4681C0E42D00554192788A7D841A0F1A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Is there going to be a new revision of this draft? It appears the draf= t has expired. I didn=92t see any response to the comments I made a few mon= ths ago.

Senthil

From: Senthil Sivakumar <ssenthil@cisco.com>
Date: Friday, March 1, 2013 8:43 AM=
To: "opsawg@ietf.org" <= opsawg@ietf.org>
Subject: [OPSAWG] Comments on draft= -ietf-opsawg-firewalls-01

At =
a very high level, it is not clear what this document is set out to achieve=
 and what it really delivers. 
Part=
icularly section 2, I really cant tell what value that this section adds.
The document says it is a BCP, so sh=
ould it have a set of requirements from a firewall vendor and operator to b=
e effective.
Without a set of requi=
rements, this looks more like an informational document than a BCP. =

Specific comments below:

Sectio= n 1:
I would add the following abou= t the generic nature of firewalls.
=
"Firewalls generally oper= ate under the notion of trusted and untrusted network domains.
=
For example, an enterprise that employs the fir= ewall will be considered a trusted domain. 
Flows that are originated from the trusted domain is consider= ed as untrusted.
The packets are fi= ltered using static and dynamic policies as defined or learned "

Nit:
An application-layer gate= way (ALG) in front of a server creates a perimeter between that server and the network it is connected to. The ALG blocks some of the flows in the application protocol based on policies such as "do not all traffic from this network" = and "do not allow the client to send a message of this type". 

s/do not=
 all/do not allow/

Layer 4:=
 Most firewalls can filter based on TCP and UDP ports.
      Many (but, frustratingly, not all) firewalls can also filter based
      on transports other than TCP and UDP.

- Most L=
4 firewalls filter packets based on TCP sequence and ack numbers. This esse=
ntially makes 
the fire=
wall a single point of failure and hence preventing asymmetric routing.&nbs=
p;
- Firewa=
lls handle out of order fragments and in some cases reassembling the fragme=
nts to be able to inspect the 
L7 paylo=
ad. 
- When a=
 firewall suspects an attack, it sends a reset to both ends to clean up the=
 connection. I personally don=92t like that, but firewalls spoof these rese=
ts.

"No=
te that many firewall devices can only create policies at one or two of the=
 layers."

 Can you please add some text=
 on why that is the case or basis for the above.

Section =
3.2:

The sect=
ion introduces the outside and inside terminology without defining what the=
y are. 
A termin=
ology section may be necessary or some context of what outside and inside a=
re.
I would =
rather prefer trusted and untrusted instead of inside and outside, respecti=
vely. 

Section =
4.
I would =
highlight the inability of firewall to do Deep Packet Inspection on encrypt=
ed traffic and hence 
Firewall=
s that look deep into the payload to make decisions are ineffective.=


There ar=
e a lot of firewall capabilities that are useful to the operators like:
- Syn at=
tacks can be avoided
Tiny  fr=
agment attacks

Should h=
ave logs turned on for major events.

Section 5
I think it is pretty useful t=
o require the firewall vendors to align the timeouts between NAT & Fire=
wall, as they are deployed together.
Similarly a device that has b=
oth NAT & firewall should work in tandem when the ALGs are deployed oth=
erwise the applications wont work.
This can be in the section 4 =
too, as it requires the operators to understand that these ALGs should be e=
nabled for both NAT & Firewall.
Provide firewall logging faci=
lity of suspected attacks.
I don=92t believe there is a =
standard firewall MIB, but that would be a useful one to suggest too.
Firewalls do handle fragmente=
d traffic and deal with out of order fragments. 

It seems both sections 4 &=
; 5 need some focused text on what the requirements are from a vendor and f=
rom an operator.

Appendix A:
 Their=
 security is a side-effect of their design. [[[ MORE HERE about
   the history and why some operators mistake the security policy of
   NATs with firewalls. ]]]

I would suggest the following text for appendix A:

"Many NAT devices implement End-point dependen=
t mapping [as defined in RFC 4787] and as a result,
only the flows that are originated from=
 a trusted or inside domain, will result in a NAT mapping creation. This ma=
pping
Will have t=
he destination address & port information, unless the return traffic co=
mes from the same destination address & port,
NAT will drop the packet. This is not beca=
use of a security policy but since NAT's mapping database cannot find a mat=
ching entry. 
This gives an illusion that NAT is a security feature by disallowing traf=
fic that was originated from outside. 
For traffic originated from the untrusted domain=
, the NATs most likely wont have a matching mapping entry to allow the traf=
fic through and
 =
hence the traffic is dropped."











 --_000_CB1B483277FEC94E9B58357040EE5D0232592556xmbrcdx15ciscoc_--