From j.schoenwaelder@jacobs-university.de Wed Jun 1 02:24:27 2011 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 95BFBE06B0 for ; Wed, 1 Jun 2011 02:24:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCfBoGzZ48Fl for ; Wed, 1 Jun 2011 02:24: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 08DD1E06AF for ; Wed, 1 Jun 2011 02:24:27 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3903120BF4 for ; Wed, 1 Jun 2011 11:24:26 +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 oyix1458Ps6M; Wed, 1 Jun 2011 11:24: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 9063C20BEE; Wed, 1 Jun 2011 11:24:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9CB4318D2512; Wed, 1 Jun 2011 11:24:22 +0200 (CEST) Date: Wed, 1 Jun 2011 11:24:22 +0200 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20110601092422.GA48402@elstar.local> Mail-Followup-To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [OPSAWG] draft-ietf-opsawg-automated-network-configuration-01.txt ready for WG last call 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, 01 Jun 2011 09:24:27 -0000 Hi, I posted draft-ietf-opsawg-automated-network-configuration-01.txt and this revision has mostly editorial changes. I added a pointer to a recent "call home" proposal for SSH and removed the open issue concerning VPN usage during bootstrapping (the only pointer for any real-world usage I had were aruba controllers / remote access points and I believe these are rather special cases since they use VPNs as a primary means to separate the air interface from the centralized controller). I believe the document is complete and I like to ask the chairs to issue a WG last call. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Jun 1 04:51:05 2011 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 695D5E07E1 for ; Wed, 1 Jun 2011 04:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYiBxdF1fzxN for ; Wed, 1 Jun 2011 04:51:04 -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 6113BE074A for ; Wed, 1 Jun 2011 04:51:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYGABQm5k2HCzI1/2dsb2JhbABTmBGOE3eoIYNaApsRhiAElTWKTQ X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="249240972" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jun 2011 07:51:03 -0400 X-IronPort-AV: E=Sophos;i="4.65,303,1304308800"; d="scan'208";a="658355439" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Jun 2011 07:51:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2011 13:51:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AD review of draft-ietf-opsawg-mib-floats-01.txt Thread-Index: AcwgUi0qJ9/ZVfGeQXmvxYJu0L79vA== From: "Romascanu, Dan (Dan)" To: Subject: [OPSAWG] AD review of draft-ietf-opsawg-mib-floats-01.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, 01 Jun 2011 11:51:05 -0000 Hi,=20 Please find below the AD review of draft-ietf-opsawg-mib-floats-01.txt. The document is in good shape and I am sending it to IETF Last Call. Please consider the comments below together with the other IETF LC comments.=20 Technical comments are marked T and Editorial comments are marked E.=20 E1.=20 mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; Add -- RFC 2758 and -- RFC 2759 for each of the imports, so that the source RFC number can be available if the MIB module us used extracted from the RFC.=20 E2. The name of the IEEE standard referenced in the document is 'IEEE Standard for Floating-Point Arithmetic' and not 'IEEE Standard for Binary Floating-Point Arithmetic' as written in the REFERENCE clauses and in the Normative References section - see http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D4610935&tag=3D1 Thanks and Regards, Dan=20 From iesg-secretary@ietf.org Wed Jun 1 07:04:14 2011 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 1CFBBE0878; Wed, 1 Jun 2011 07:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.444 X-Spam-Level: X-Spam-Status: No, score=-101.444 tagged_above=-999 required=5 tests=[AWL=-1.011, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCykWWMtDUoq; Wed, 1 Jun 2011 07:04:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB88DE0807; Wed, 1 Jun 2011 07:04:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110601140413.26256.2075.idtracker@ietfa.amsl.com> Date: Wed, 01 Jun 2011 07:04:13 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] Last Call: (Textual Conventions for the Representation of Floating-Point Numbers) to Proposed Standard X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 14:04:14 -0000 The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Textual Conventions for the Representation of Floating-Point Numbers' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsawg-mib-floats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsawg-mib-floats/ No IPR declarations have been submitted directly on this I-D. From randy_presuhn@mindspring.com Wed Jun 1 11:49:20 2011 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 21592E06BC for ; Wed, 1 Jun 2011 11:49:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRTmTH5WxcvV for ; Wed, 1 Jun 2011 11:49:19 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id EE173E07B3 for ; Wed, 1 Jun 2011 11:48:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=TttAGyYWGF0wih2o2msMmoWE4zP/Wbz4yode6JgRGf6pq2C2No223FdbJlzrAj9A; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.238.178] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QRqSW-0003C2-2y; Wed, 01 Jun 2011 14:48:00 -0400 Message-ID: <001301cc208c$eea67b60$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Romascanu, Dan \(Dan\)" , References: Date: Wed, 1 Jun 2011 11:51:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b382a5f529d21720b8a02bf38644f2c852ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.238.178 Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mib-floats-01.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, 01 Jun 2011 18:49:20 -0000 Hi - > From: "Romascanu, Dan (Dan)" > To: > Sent: Wednesday, June 01, 2011 4:51 AM > Subject: [OPSAWG] AD review of draft-ietf-opsawg-mib-floats-01.txt > > > > Hi, > > Please find below the AD review of draft-ietf-opsawg-mib-floats-01.txt. > The document is in good shape and I am sending it to IETF Last Call. > Please consider the comments below together with the other IETF LC > comments. Both as editor and as a technical contributor, I think all of these items are non-contentious. > Technical comments are marked T and Editorial comments are marked E. > > E1. > > mib-2 FROM SNMPv2-SMI > TEXTUAL-CONVENTION FROM SNMPv2-TC; > > Add -- RFC 2758 and -- RFC 2759 for each of the imports, so that the > source RFC number can be available if the MIB module us used extracted > from the RFC. Fixed in the editor's copy. > E2. The name of the IEEE standard referenced in the document is 'IEEE > Standard for Floating-Point Arithmetic' and not 'IEEE Standard for > Binary Floating-Point Arithmetic' as written in the REFERENCE clauses > and in the Normative References section - see > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4610935&tag=1 Also fixed in the editor's copy. These changes will show up with the next I-D, which will probably be at the close of the last call. Randy From dromasca@avaya.com Thu Jun 2 03:22:44 2011 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 946BAE075E for ; Thu, 2 Jun 2011 03:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.189 X-Spam-Level: X-Spam-Status: No, score=-102.189 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9cpHxj15KCv for ; Thu, 2 Jun 2011 03:22:43 -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 00401E0751 for ; Thu, 2 Jun 2011 03:22:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQBAA9j503GmAcF/2dsb2JhbABTl1eOWnetPgKbM4YhBJVJilA X-IronPort-AV: E=Sophos;i="4.65,308,1304308800"; d="scan'208";a="282845752" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Jun 2011 06:22:21 -0400 X-IronPort-AV: E=Sophos;i="4.65,308,1304308800"; d="scan'208";a="628722565" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Jun 2011 06:22:20 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Jun 2011 11:15:17 +0200 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <001301cc208c$eea67b60$6801a8c0@oemcomputer> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] AD review of draft-ietf-opsawg-mib-floats-01.txt Thread-Index: AcwgjHUsddZTLLc5Ra2qxEmAWZveBAAeQc0g References: <001301cc208c$eea67b60$6801a8c0@oemcomputer> From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mib-floats-01.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, 02 Jun 2011 10:22:44 -0000 Hi Randy,=20 Thanks for addressing the comments. Please include the changes in the post-IETFLC version.=20 Regards, Dan=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Wednesday, June 01, 2011 9:52 PM > To: Romascanu, Dan (Dan); opsawg@ietf.org > Subject: Re: [OPSAWG] AD review of draft-ietf-opsawg-mib-floats-01.txt >=20 > Hi - >=20 > > From: "Romascanu, Dan (Dan)" > > To: > > Sent: Wednesday, June 01, 2011 4:51 AM > > Subject: [OPSAWG] AD review of draft-ietf-opsawg-mib-floats-01.txt > > > > > > > > Hi, > > > > Please find below the AD review of draft-ietf-opsawg-mib-floats- > 01.txt. > > The document is in good shape and I am sending it to IETF Last Call. > > Please consider the comments below together with the other IETF LC > > comments. >=20 > Both as editor and as a technical contributor, > I think all of these items are non-contentious. >=20 > > Technical comments are marked T and Editorial comments are marked E. > > > > E1. > > > > mib-2 FROM SNMPv2-SMI > > TEXTUAL-CONVENTION FROM SNMPv2-TC; > > > > Add -- RFC 2758 and -- RFC 2759 for each of the imports, so that the > > source RFC number can be available if the MIB module us used > extracted > > from the RFC. >=20 > Fixed in the editor's copy. >=20 > > E2. The name of the IEEE standard referenced in the document is 'IEEE > > Standard for Floating-Point Arithmetic' and not 'IEEE Standard for > > Binary Floating-Point Arithmetic' as written in the REFERENCE clauses > > and in the Normative References section - see > > = http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=3D4610935&tag=3D1 >=20 > Also fixed in the editor's copy. >=20 > These changes will show up with the next I-D, which will probably be at > the > close of the last call. >=20 > Randy From gash5107@yahoo.com Thu Jun 2 10:32:56 2011 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 0A83FE06FB for ; Thu, 2 Jun 2011 10:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.684 X-Spam-Level: X-Spam-Status: No, score=-100.684 tagged_above=-999 required=5 tests=[AWL=1.914, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPW6kVXjqfvJ for ; Thu, 2 Jun 2011 10:32:51 -0700 (PDT) Received: from nm18-vm1.bullet.mail.ne1.yahoo.com (nm18-vm1.bullet.mail.ne1.yahoo.com [98.138.91.64]) by ietfa.amsl.com (Postfix) with SMTP id 9DE65E05D3 for ; Thu, 2 Jun 2011 10:32:49 -0700 (PDT) Received: from [98.138.90.48] by nm18.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jun 2011 17:32:46 -0000 Received: from [98.138.89.254] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 02 Jun 2011 17:32:46 -0000 Received: from [127.0.0.1] by omp1046.mail.ne1.yahoo.com with NNFMP; 02 Jun 2011 17:32:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 259699.19761.bm@omp1046.mail.ne1.yahoo.com Received: (qmail 68765 invoked by uid 60001); 2 Jun 2011 17:32:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307035966; bh=BAKTtKV8DrDrcsFlGPdxr1HKo2R0KFdSFXVkjoEf0G4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=pFtT/YZ2XeCIZUZbzNouLJ25BjN346afY29RNkFqRGyEMq9Zo88lYWDf3mfPFbmn/Xeirh03nva7qmdyYjV2hq94I+MpBfmjjjSElAhQQD1ShvDZrDLaLezYUNJ0gPNOh6ExAzV045jR4TfS779QBptTYtAM0LFEe6TyqJDQglc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=0TO9fmGaqEmB1D27Zd1ftZKuVws6GQuTvYa3JhWtqcDJnJpcjUeQmNEOFFj6zGL2SeASfLKjkgGwPuLO9Qgq8UMSe62PYKp+RgMCv9YlAF8v/WrQGIEFYOJ+6w6+hT+8hQEYkOMZ+2NU3taneAR9ZN83Jg8tJcYdN0mCPUHwVHs=; Message-ID: <165236.66015.qm@web125909.mail.ne1.yahoo.com> X-YMail-OSG: anJUhwsVM1k4pMoD2Ejxs8He1431LBUNww4FRVNHQsb3snd 5Q9SAj_S5FidOBf2nNRy73hU5wuD88CA9_7KMBjYarZzHpaOuWmE6JOimDi_ YPSH_4AbhVgGjxjzJd219TLQJFXOQAVFUNVcVMtKblF2Wc_Py4e20xjA53We qJhqEN1hGUZ9JGCuKYrElO1v8LTeYdvQqwO7_cXUYNcFw69j1kF7fkFZdAaQ KlmUqXPeqFHYSmMsvHnlkB0mGsUTQf8q2a54lXB4O5xWcDDPivc3b.NqaClB OwZmXTb.UWh6ed_CoBuTQKEmKn.FExum2uE7548KlF3nVlvt8kUwqwPe2qf9 q94uuVkAzwyxP5sWHX9E.AJ3fzA-- Received: from [71.233.102.170] by web125909.mail.ne1.yahoo.com via HTTP; Thu, 02 Jun 2011 10:32:46 PDT X-Mailer: YahooMailClassic/14.0.1 YahooMailWebService/0.8.111.303096 Date: Thu, 2 Jun 2011 10:32:46 -0700 (PDT) From: Gerald Ash To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2021109322-1307035966=:66015" Subject: [OPSAWG] Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks 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 Jun 2011 17:32:56 -0000 --0-2021109322-1307035966=:66015 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi, =A0 Adrian has suggested that the=A0OPSAWG review=A0the draft "Generic Connecti= on Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", = available=A0at =A0http://www.ietf.org/id/draft-ash-gcac-algorithm-spec-00.t= xt=A0(abstract=A0below). =A0 The underlying goal of the work is to specify an optional GCAC algorithm fo= r IP/MPLS networks,=A0to be adopted and implemented by vendors and service = providers, that interoperates between vendor equipment and across multiple = service provider domains.=A0 This would be analogous to the PNNI GCAC that = was widely adopted and=A0helped promote=A0interoperability of ATM networks.= =A0 In addition, the approach: o=A0is=A0based on=A0CSPF, widely implemented by vendors o=A0does=A0NOT include aspects of CAC that might be considered vendor propr= ietary implementations, such as detailed path selection mechanisms o relies on=A0available standard mechanisms for MPLS based networks, such a= s RSVP, DSTE, PCE... =A0 Comments appreciated. =A0 Thanks, Jerry =A0 From: Internet-Drafts@ietf.org=A0 To: i-d-announce@ietf.org=A0 Reply-to: Internet-Drafts@ietf.org=A0 Subject: I-D ACTION:draft-ash-gcac-algorithm-spec-00.txt=A0 X-RSN: 1/0/935/34473/37870=A0 =A0 A New Internet-Draft is available from the on-line Internet-Drafts =A0 directories. =A0 Title : Generic Connection Admission Control (GCAC) Algorithm Specification= for IP/MPLS Networks=A0 Author(s) : G. Ash, D. McDysan=A0 Filename : draft-ash-gcac-algorithm-spec-00.txt=A0 Pages : 23=A0 Date : 2011-1-11=A0 =A0 This document presents a generic connection admission control (GCAC)=A0 reference model and algorithm for IP/MPLS-based networks. Service=A0 provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for=A0 example, to reject voice over Internet Protocol (VoIP) calls when=A0 additional calls would adversely affect calls already in progress.=A0 =A0 Without MPLS GCAC, connections on congested links will suffer=A0 degraded quality. The MPLS GCAC algorithm can be optionally=A0 implemented in vendor equipment and deployed by service providers.=A0 MPLS GCAC interoperates between vendor equipment and across multiple=A0 service provider domains. The MPLS GCAC algorithm uses available=A0 standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE,=A0 NSIS, DiffServ, and OSPF. The MPLS GCAC algorithm does not include=A0 aspects of CAC that might be considered vendor proprietary=A0 implementations, such as detailed path selection mechanisms. MPLS=A0 GCAC functions are implemented in a distributed manner to deliver the=A0 objective QoS for specified QoS constraints. The source is able to=A0 compute a source route with high likelihood that MPLS GCAC via=A0 elements along the selected path will in fact admit the request.=A0 MPLS GCAC is applicable to any service or flow that must meet an=A0 objective QoS (delay, jitter, packet loss rate) for a specified=A0 quantity of traffic.=A0 =A0 A URL for this Internet-Draft is:=A0 http://www.ietf.org/internet-drafts/draft-ash-gcac-algorithm-spec-00.txt =A0 Internet-Drafts are also available by anonymous FTP at:=A0 ftp://ftp.ietf.org/internet-drafts/ =A0 Below is the data which will enable a MIME compliant mail reader=A0 implementation to automatically retrieve the ASCII version of the=A0 Internet-Draft.=A0 _______________________________________________=A0 I-D-Announce mailing list=A0 I-D-Announce@ietf.org=A0 https://www.ietf.org/mailman/listinfo/i-d-announce=A0 Internet-Draft directories: http://www.ietf.org/shadow.html=A0 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=A0 =A0 *****=A0 Click below to download the attachment(s) in this message:=A0 Attachment: draft_ash_gcac_algorithm_spec_00= .txt (1K)=A0 --0-2021109322-1307035966=:66015 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
 
Adrian has suggested that the OPSAWG review the draft "Gener= ic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks", available at &= nbsp;http://www.ietf.org/id/draft-ash-gcac-algorithm= -spec-00.txt (abstract below).
 
The underlying goal of the work is to specify an optional GCAC algorit= hm for IP/MPLS networks, to be adopted and implemented by vendors and = service providers, that interoperates between vendor equipment and across m= ultiple service provider domains.  This would be analogous to the PNNI= GCAC that was widely adopted and helped promote interoperability= of ATM networks.  In addition, the approach:
o is based on CSPF, widely implemented by vendors
o does NOT include aspects of CAC that might be considered v= endor proprietary implementations, such as detailed path selection mechanis= ms
o relies on available standard mechanisms for MPLS based networks= , such as RSVP, DSTE, PCE...
 
Comments appreciated.
 
Thanks,
Jerry
 
From: Internet-Drafts@ietf.org 
To: i-d-announce@ietf.org 
Reply-to: Internet-Drafts@ietf.org 
Subject: I-= D ACTION:draft-ash-gcac-algorithm-spec-00.txt 
X-RSN: 1/0/935/34473= /37870 
 
A New Internet-Draft is available from the on-lin= e Internet-Drafts  
directories.
 
Title : Generic Conne= ction Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks 
Author(s) : G. Ash, D. McDysan 
Filename : draft= -ash-gcac-algorithm-spec-00.txt 
Pages : 23 
Date : 2011-1-= 11 
 
This document presents a generic connection admission= control (GCAC) 
reference model and algorithm for IP/MPLS-base= d networks. Service 
provider (SP) IP/MPLS networks need an MPL= S GCAC mechanism, for 
example, to reject voice over Internet Proto= col (VoIP) calls when 
additional calls would adversely affect call= s already in progress. 
 
Without MPLS GCAC, connections on= congested links will suffer 
degraded quality. The MPLS GCAC algor= ithm can be optionally 
implemented in vendor equipment and deployed by ser= vice providers. 
MPLS GCAC interoperates between vendor equipment a= nd across multiple 
service provider domains. The MPLS GCAC algorit= hm uses available 
standard mechanisms for MPLS based networks, suc= h as RSVP, DSTE, PCE, 
NSIS, DiffServ, and OSPF. The MPLS GCAC algo= rithm does not include 
aspects of CAC that might be considered ven= dor proprietary 
implementations, such as detailed path selection m= echanisms. MPLS 
GCAC functions are implemented in a distributed ma= nner to deliver the 
objective QoS for specified QoS constraints. T= he source is able to 
compute a sour= ce route with high likelihood that MPLS GCAC via 
eleme= nts along the selected path will in fact admit the request. 
MPLS G= CAC is applicable to any service or flow that must meet an 
objecti= ve QoS (delay, jitter, packet loss rate) for a specified 
quant= ity of traffic. 
 
A URL for this Internet-Draft is: <= BR>http://www.ietf.org/internet-drafts/= draft-ash-gcac-algorithm-spec-00.txt
 
Internet-Drafts are also available by anonymous FTP at: = ;
ftp://ftp.ietf.org/internet-drafts/
 
Below is the data which will enable a MIME compliant mail re= ader 
implementation to automatically retrieve the ASCII version of= the 
Internet-Draft. 
____________________________________= ___________ 
I-D-Announce mailing list 
I-D-Announce@ietf.o= rg 
https://www.ietf.org/mailman/listinfo/i-d-announc= e 
Internet-Draft directories: http://www.ietf.org/shadow.ht= ml 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
 
***** 
Click below to download the att= achment(s) in this message: 
<A HREF=3D"http://www.ietf.org/ibin/= c5i?mid=3D6&gid=3D0&rid=3D8&k1=3D935&file=3Di-d-announce.37= 870.1.txt">Attachment: draft_ash_gcac_algorithm_spec_00.txt&l= t;/A> (1K) 
--0-2021109322-1307035966=:66015-- From wwwrun@rfc-editor.org Thu Jun 2 17:16:29 2011 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 1AF12E0674; Thu, 2 Jun 2011 17:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.013 X-Spam-Level: X-Spam-Status: No, score=-102.013 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1nl4oSJJr1i; Thu, 2 Jun 2011 17:16:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 897DCE07B6; Thu, 2 Jun 2011 17:16:24 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 845C9E0787; Thu, 2 Jun 2011 17:16:24 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110603001624.845C9E0787@rfc-editor.org> Date: Thu, 2 Jun 2011 17:16:24 -0700 (PDT) X-Mailman-Approved-At: Fri, 03 Jun 2011 01:34:38 -0700 Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 5343 on Simple Network Management Protocol (SNMP) Context EngineID Discovery 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 Jun 2011 00:16:29 -0000 This document is now a Draft Standard Protocol. RFC 5343 Title: Simple Network Management Protocol (SNMP) Context EngineID Discovery Author: J. Schoenwaelder Status: Standards Track Stream: IETF Date: September 2008 Mailbox: j.schoenwaelder@jacobs-university.de Pages: 9 Characters: 19938 Updates: RFC3411 I-D Tag: draft-ietf-opsawg-snmp-engineid-discovery-03.txt URL: http://www.rfc-editor.org/rfc/rfc5343.txt The Simple Network Management Protocol (SNMP) version three (SNMPv3) requires that an application know the identifier (snmpEngineID) of the remote SNMP protocol engine in order to retrieve or manipulate objects maintained on the remote SNMP entity. This document introduces a well-known localEngineID and a discovery mechanism that can be used to learn the snmpEngineID of a remote SNMP protocol engine. The proposed mechanism is independent of the features provided by SNMP security models and may also be used by other protocol interfaces providing access to managed objects. This document updates RFC 3411. [STANDARDS-TRACK] This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Draft Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From peng.yonglin@zte.com.cn Wed Jun 8 20:45:28 2011 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 5673021F8533 for ; Wed, 8 Jun 2011 20:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.19 X-Spam-Level: X-Spam-Status: No, score=-90.19 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d354hVGoTRpM for ; Wed, 8 Jun 2011 20:45:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6918821F8484 for ; Wed, 8 Jun 2011 20:45:27 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48641390076507; Thu, 9 Jun 2011 11:44:58 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 15366.1390076507; Thu, 9 Jun 2011 11:43:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p593hq13048813 for ; Thu, 9 Jun 2011 11:43:52 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn) To: opsawg@ietf.org MIME-Version: 1.0 X-KeepSent: 28B3E6A8:812EF3E1-482578AA:0013B597; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.yonglin@zte.com.cn Date: Thu, 9 Jun 2011 11:43:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-09 11:43:52, Serialize complete at 2011-06-09 11:43:52 Content-Type: multipart/alternative; boundary="=_alternative 001489EB482578AA_=" X-MAIL: mse01.zte.com.cn p593hq13048813 X-Mailman-Approved-At: Thu, 09 Jun 2011 01:03:48 -0700 Cc: hao.zhenwu@zte.com.cn Subject: [OPSAWG] =?gb2312?b?V2UgaGF2ZSBzdWJtaXR0ZWQgYSBkcmFmdHMgb24gU05N?= =?gb2312?b?UCB1c2FnZXMgZm9yIFAyUCBuZXR3b3Jrcy4gV2Ugd291bGQgbGlrZSB0byBn?= =?gb2312?b?ZXQgc29tZSBzdWdnZXN0aW9ucyBmcm9tIFNOTVAgZXhwZXJ0cyBvbiB0aGUg?= =?gb2312?b?c2NlbmFyaW8gYW5kIGRlc2lnbiBmb3IgUDJQIG5ldHdvcmsgbWFuYWdlbWVu?= =?gb2312?b?dC4gVGhlIGxpbmsgdG8gdGhlIGRyYWZ0IGlzIGluIHRoZSBib2R5IG9mIHRo?= =?gb2312?b?aXMgZW1haWwuIHRoYW5rc6Oh?= 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 Jun 2011 03:45:28 -0000 This is a multipart message in MIME format. --=_alternative 001489EB482578AA_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXBlbmctcDJwc2lwLXNubXAtMDEudHh0IA0K DQoNCg0KDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQrTyiC8/qO6cGVuZy55b25nbGluQHp0ZS5jb20uY24NCsTaIM/fo7o4MTU0Mw0KzeIgz9+jujAy NS01Mjg3MTU0Mw0KytYgu/qjujEzNzc2NjM3Mjc0DQq0qyDV5qO6MDI1LTUyODcyMTg3DQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIA0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0 byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 001489EB482578AA_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXBlbmctcDJwc2lw LXNubXAtMDEudHh0Ij48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48 dT5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtcGVuZy1wMnBzaXAtc25tcC0wMS50eHQ8 L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPtPKILz+o7pwZW5nLnlvbmdsaW5A enRlLmNvbS5jbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+xNog z9+jujgxNTQzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj7N4iDP 36O6MDI1LTUyODcxNTQzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij7K1iC7+qO6MTM3NzY2MzcyNzQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPrSrINXmo7owMjUtNTI4NzIxODc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKio8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGJy PjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTom bmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFp bCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNp cGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNw O3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90 Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRl bnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3Ro ZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0 cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZu YnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7 dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkm bmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNw O0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWls Jm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNw O29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7 dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7 YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5k ZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5i c3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZu YnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 001489EB482578AA_=-- From randy_presuhn@mindspring.com Thu Jun 9 10:12:42 2011 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 1413E11E81CD for ; Thu, 9 Jun 2011 10:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp6x0DZBgr20 for ; Thu, 9 Jun 2011 10:12:41 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 50C8011E817A for ; Thu, 9 Jun 2011 10:12:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d0V9Wz7ygz+3OCnOJaVKskO3M8xuZShlJuXaFBrf5tYa8HmhPOUA24fTLeWkQKyN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.227.199] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1QUime-0003ER-3H for opsawg@ietf.org; Thu, 09 Jun 2011 13:12:40 -0400 Message-ID: <006201cc26c8$f9595e00$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Thu, 9 Jun 2011 10:16:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b3826892f10d3f3a38a6cdbc8efb626ce5bd350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.227.199 Subject: Re: [OPSAWG] =?utf-8?q?We_have_submitted_a_drafts_on_SNMP_usages_for_?= =?utf-8?q?P2P_networks=2E_We_would_like_to_get_some_suggestions_fr?= =?utf-8?q?om_SNMP_experts_on_the_scenario_and_design_for_P2P_netwo?= =?utf-8?q?rk_management=2E_The_link_to_the_draft_is_in_the_body_of?= =?utf-8?q?_this_email=2E_thanks=EF=BC=81?= 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 Jun 2011 17:12:42 -0000 Hi - > From: > To: > Cc: > Sent: Wednesday, June 08, 2011 8:43 PM > Subject: [OPSAWG] We have submitted a drafts on SNMP usages for P2P networks. We would like to get some suggestions from SNMP experts on the scenario and design for P2P network management. The link to the draft is in the body of this email. thanks！ > > http://tools.ietf.org/id/draft-peng-p2psip-snmp-01.txt ... Skimming the draft, it was unclear to me how a few details would work in this approach. I think it would be helpful to explicitly talk about (1) how notifications are intended to work (2) key provisioning (indeed, provisioning in general) (3) what security model is in use I *think* it might be helpful to treat this as a new transport model, but you'll need to think through just how authentication and privacy are to be handled (e.g., is it just USM atop RELOAD, or does RELOAD provide the security services?). This decision may interract with how, for example, notification and Disman targets are configured. In particular, consider whether you need to support the case where only *some* of the SNMP interractions between two systems are carried via RELOAD. Randy From tena@huawei.com Mon Jun 13 09:22:43 2011 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 ACFBA21F84CF for ; Mon, 13 Jun 2011 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.152 X-Spam-Level: X-Spam-Status: No, score=-105.152 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_SPLIT_HR2=0.183, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4SeGFXxcKHQ for ; Mon, 13 Jun 2011 09:22:42 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1A30621F84CB for ; Mon, 13 Jun 2011 09:22:39 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMQ00I2HLHNN7@szxga04-in.huawei.com> for opsawg@ietf.org; Tue, 14 Jun 2011 00:22:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMQ004NZLHNYP@szxga04-in.huawei.com> for opsawg@ietf.org; Tue, 14 Jun 2011 00:22:35 +0800 (CST) Received: from [192.35.167.6] (iPad.dhcp.nanog.merit.net [192.35.167.6]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0LMQ0003YLHJGX@szxml11-in.huawei.com>; Tue, 14 Jun 2011 00:22:35 +0800 (CST) Date: Mon, 13 Jun 2011 10:23:43 -0600 From: Tina Tsou To: "opsawg@ietf.org" Message-id: <53CE128E-F099-4C4F-B525-D77ADDC925F0@huawei.com> MIME-version: 1.0 X-Mailer: iPad Mail (8J3) Content-type: multipart/alternative; boundary="Boundary_(ID_5z9N/mT6/aLcs2KPA7fThw)" Subject: [OPSAWG] Comments are welcome on http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/ 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 Jun 2011 16:22:43 -0000 --Boundary_(ID_5z9N/mT6/aLcs2KPA7fThw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Comments are welcome on http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/ The problem statement I-D is very 'drafty'. Service management may be a subject by itself, and it is not necessarily related to data centers. The network management is critical for carrier providers. The authors would encourage the interested people to join us for more work and discussions (on the list or off-list) and consistent submissions. A better focus, maybe by breaking the overall problem into smaller pieces could also help. Best regards, Tina TSOU http://tinatsou.weebly.com/ --Boundary_(ID_5z9N/mT6/aLcs2KPA7fThw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 7BIT
Hi all,
Comments are welcome on http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/

The problem statement I-D is very 'drafty'. Service management may be a subject by itself, and it
is not necessarily related to data centers. The network management is critical for carrier providers.

The authors would encourage the interested people to join us for more work and discussions (on the list or off-list) and consistent submissions. A better focus, maybe by breaking the overall problem into smaller pieces could also help. 


Best regards,
Tina TSOU
In-reply-to: <53CE128E-F099-4C4F-B525-D77ADDC925F0@huawei.com> X-Originating-IP: [10.138.41.104] To: 'Tina Tsou' , opsawg@ietf.org Message-id: <006801cc2a77$8ef5a5c0$ace0f140$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qHiVSKEznP5bkHg3f9d30w)" Content-language: zh-cn Thread-index: Acwp57sYXHQqPK3xRuW5jzxEQwvP7AAcI2FQ References: <53CE128E-F099-4C4F-B525-D77ADDC925F0@huawei.com> Subject: Re: [OPSAWG] Comments are welcome on http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/ 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, 14 Jun 2011 09:42:09 -0000 --Boundary_(ID_qHiVSKEznP5bkHg3f9d30w) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Hi Tina and all, This is an interesting draft, which concludes many aspects of challenges = to Virtualization DC operation and management. Except for the aspects described in the draft, I would like to introduce = the following aspects into discussion. 1) One additional challenge is VM provision mechanism. This is not = about monitoring of VM software and hardware, instead, it=E2=80=99s = about how to networking and where to initiate the VMs in order to = guarantee customers=E2=80=99 performance and security requirements. For = example, customers may request that their VMs be deployed at different = pods so that their service can be available to maximum level when = network performance degrades. This is only a very simple example. = Customers requirements may be more complex. 2) Interaction between network side and server side. There might be = separated VM managers and network mangers, or the two mangers are merged = into a single manger. For either case, interaction is necessary.=20 =20 >From server side to network side, an interaction example is VM migration = which implies network policies being migrated correspondingly. This has = been introduced in the draft in section 5.1.=20 >From network side to server side, an interaction example is that mangers = adjust VMs upon network status monitoring.=20 =20 I have submitted a draft describing this in detail. You can find it at = http://datatracker.ietf.org/doc/draft-gu-opsa-policies-migration/ =20 =20 3) As I said above, there might be separated VM managers and network = mangers. In this case, interactive programmatic interfaces are needed to = support network managers to obtain VM status, feedback network = performance, and other possible operations. =20 =20 =20 _____ =20 Best Regards Gu Yingjie =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: opsawg-bounces@ietf.org = [mailto:opsawg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Tina Tsou =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B46=E6=9C=8814=E6=97=A5 = =E4=B9=90=E4=B9=900:24 =E6=94=B6=E4=BB=B6=E4=BA=BA: opsawg@ietf.org =E4=B8=BB=E9=A2=98: [OPSAWG] Comments are welcome on = http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/ =20 Hi all, Comments are welcome on = http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/ The problem statement I-D is very 'drafty'. Service management may be a = subject by itself, and it is not necessarily related to data centers. The network management is = critical for carrier providers. The authors would encourage the interested people to join us for more = work and discussions (on the list or off-list) and consistent = submissions. A better focus, maybe by breaking the overall problem into = smaller pieces could also help.=20 Best regards, Tina TSOU

Hi Tina and = all,

This is an = interesting draft, which concludes many aspects of challenges to = Virtualization DC operation and management.

Except for the = aspects described in the draft, I would like to introduce the following = aspects into discussion.

1)    One = additional challenge is VM provision mechanism. This is not about = monitoring of VM software and hardware, instead, it=E2=80=99s about how = to networking and where to initiate the VMs in order to guarantee = customers=E2=80=99 performance and security requirements. For example, = customers may request that their VMs be deployed at different pods so = that their service can be available to maximum level when network = performance degrades. =C2=A0This is only a very simple example. = Customers requirements may be more complex.

2)    Interaction = between network side and server side. There might be separated VM = managers and network mangers, or the two mangers are merged into a = single manger. For either case, interaction is necessary. =

 

From server side = to network side, an interaction example is VM migration which implies = network policies being migrated correspondingly. This has been = introduced in the draft in section 5.1.

From network side = to server side, an interaction example is that mangers adjust VMs upon = network status monitoring.

 

I have submitted a = draft describing this in detail. You can find it at http://datatracker.ietf.org/doc/draft-gu-opsa-policies-migration/<= /p>

 

 

3)    As I = said above, there might be separated VM managers and network mangers. In = this case, interactive programmatic interfaces are needed to support = network managers to obtain VM status, feedback network performance, and = other possible operations.

 

 

 

=

B= est Regards
Gu Yingjie

 

=E5=8F=91=E4=BB=B6=E4=BA=BA: opsawg-bounces@ietf.org = [mailto:opsawg-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Tina Tsou
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B46=E6=9C=8814=E6=97=A5 = =E4=B9=90=E4=B9=900:24
=E6=94=B6=E4=BB=B6=E4=BA=BA: = opsawg@ietf.org
=E4=B8=BB=E9=A2=98: [OPSAWG] Comments are = welcome on = http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/

 

Hi all,
Comments are welcome on http://datatracker.ietf.org/doc/draft-tsou-vrom-problem-statement/=

The problem statement I-D is very = 'drafty'. Service management may be a subject by itself, and = it
is not necessarily related to data = centers. The network management is critical for carrier = providers.

The authors = would encourage the interested people to join us for more work and = discussions (on the list or off-list) and consistent submissions. A = better focus, maybe by breaking the overall problem into smaller = pieces could also help. 


Best regards,
Tina TSOU
<a = href=3D"http:/ /tinatso = atsou.weebly.com/

= --Boundary_(ID_qHiVSKEznP5bkHg3f9d30w)-- From Michael@huaweisymantec.com Tue Jun 14 20:58:59 2011 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 9CF3021F84D3 for ; Tue, 14 Jun 2011 20:58:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdxKrZgyWleH for ; Tue, 14 Jun 2011 20:58:58 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by ietfa.amsl.com (Postfix) with ESMTP id C556E21F8462 for ; Tue, 14 Jun 2011 20:58:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LMT00KQ7CE5G020@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 15 Jun 2011 11:58:53 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LMT00LC8CF8BA20@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Wed, 15 Jun 2011 11:59:32 +0800 (CST) Received: from [67.116.243.238] by hstml01-in.huaweisymantec.com (mshttpd) ; Tue, 14 Jun 2011 20:59:32 -0700 From: MichaelKo To: opsawg@ietf.org, opsawg@ietf.org Message-id: Date: Tue, 14 Jun 2011 20:59:32 -0700 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: en X-Accept-Language: en Priority: normal Subject: [OPSAWG] Problem statement on setting up dynamic virtual network 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, 15 Jun 2011 03:58:59 -0000 I have submitted a new IETF draft titled "Problem Statement for Setting Up Dynamic Virtual Networks". Link to the draft is here: http://datatracker.ietf.org/doc/draft-ko-dvn-problem-statement/ The abstract is as follows: "This document examines the problems and challenges associated with the process of setting up secure virtual network connections among authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Setting up a secure virtual network in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination." Some background information: At the OPSAWG meeting in IETF 79, Margaret Wasserman presented materials related to the IETF drafts (*) that she co-authored. She was subsequently asked to produce a problem statement and to continue the work within OPSAWG. This IETF draft is a continuation of that work. Your comments and suggestions are most welcome. Mike (*) "Dynamic Virtual Network Engine (DVNE) Protocol" (draft-mrw-dvne-prot-00) and "Dynamic Virtual Network Engine (DVNE) Framework" (draft-mrw-dvne-fw-00) From tena@huawei.com Tue Jun 14 23:16:22 2011 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 407FA11E8076 for ; Tue, 14 Jun 2011 23:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0qHZLkaKr4L for ; Tue, 14 Jun 2011 23:16:20 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfa.amsl.com (Postfix) with ESMTP id BB22C11E8096 for ; Tue, 14 Jun 2011 23:16:20 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMT005DEIR7VD@usaga01-in.huawei.com> for opsawg@ietf.org; Wed, 15 Jun 2011 01:16:19 -0500 (CDT) Received: from TingZousc1 ([38.109.210.2]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMT00793IR65J@usaga01-in.huawei.com> for opsawg@ietf.org; Wed, 15 Jun 2011 01:16:19 -0500 (CDT) Date: Wed, 15 Jun 2011 00:16:18 -0600 From: Tina Tsou In-reply-to: To: 'MichaelKo' , opsawg@ietf.org Message-id: <01e901cc2b23$bd94d840$38be88c0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwrEMWB+rCSeGPfRSOdXtqtu3MS1gAEsuZw References: Subject: Re: [OPSAWG] Problem statement on setting up dynamic virtual network 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, 15 Jun 2011 06:16:22 -0000 Michael, Let me know whether this draft targeted to Routing Area is relevant to yours. https://datatracker.ietf.org/doc/draft-yu-ircat-problem-statement/ We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of MichaelKo Sent: Tuesday, June 14, 2011 10:00 PM To: opsawg@ietf.org; opsawg@ietf.org Subject: [OPSAWG] Problem statement on setting up dynamic virtual network I have submitted a new IETF draft titled "Problem Statement for Setting Up Dynamic Virtual Networks". Link to the draft is here: http://datatracker.ietf.org/doc/draft-ko-dvn-problem-statement/ The abstract is as follows: "This document examines the problems and challenges associated with the process of setting up secure virtual network connections among authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Setting up a secure virtual network in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination." Some background information: At the OPSAWG meeting in IETF 79, Margaret Wasserman presented materials related to the IETF drafts (*) that she co-authored. She was subsequently asked to produce a problem statement and to continue the work within OPSAWG. This IETF draft is a continuation of that work. Your comments and suggestions are most welcome. Mike (*) "Dynamic Virtual Network Engine (DVNE) Protocol" (draft-mrw-dvne-prot-00) and "Dynamic Virtual Network Engine (DVNE) Framework" (draft-mrw-dvne-fw-00) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From internet-drafts@ietf.org Wed Jun 15 12:40:30 2011 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 A2D6221F867E; Wed, 15 Jun 2011 12:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.516 X-Spam-Level: X-Spam-Status: No, score=-101.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t0M7SKfR6qm; Wed, 15 Jun 2011 12:40:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439CE21F85CE; Wed, 15 Jun 2011 12:40:30 -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: 3.55 Message-ID: <20110615194030.17028.14297.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 12:40:30 -0700 Cc: opsawg@ietf.org Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mib-floats-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: Wed, 15 Jun 2011 19:40:30 -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 Workin= g Group Working Group of the IETF. Title : Textual Conventions for the Representation of Floating-P= oint Numbers Author(s) : Randy Presuhn Filename : draft-ietf-opsawg-mib-floats-02.txt Pages : 8 Date : 2011-06-15 This memo defines a Management Information Base (MIB) module containing textual conventions (TCs) to represent floating-point numbers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-mib-floats-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsawg-mib-floats-02.txt From Michael@huaweisymantec.com Wed Jun 15 16:18:09 2011 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 7AAE911E8161 for ; Wed, 15 Jun 2011 16:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeO1L-oo4dKd for ; Wed, 15 Jun 2011 16:18:08 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2022611E8080 for ; Wed, 15 Jun 2011 16:18:01 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_1aLnF4tlvxIfgYPJfcbhQQ)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LMU004BNU1YE0A0@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 16 Jun 2011 07:17:59 +0800 (CST) Received: from KOALA ([69.199.248.19]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LMU00M6SU1WR110@hstml02-in.huaweisymantec.com> for opsawg@ietf.org; Thu, 16 Jun 2011 07:17:58 +0800 (CST) Message-id: <9BC6F10427584D2C85B461C4B5080965@KOALA> From: Michael Ko To: Tina Tsou , opsawg@ietf.org References: <01e901cc2b23$bd94d840$38be88c0$@com> Date: Wed, 15 Jun 2011 16:18:00 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Subject: Re: [OPSAWG] Problem statement on setting up dynamic virtual network 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, 15 Jun 2011 23:18:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_1aLnF4tlvxIfgYPJfcbhQQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Tina, If I understand it correctly, the "IRCAT Problem Statement" draft discusses the problem of forming a cooperative router group from heterogeneous routers so that routers from different companies can interoperate. The emphasis is the need for a protocol to manage and coordinate this cooperative router group. My draft deals with the problem on setting up dynamic virtual networks among authorized network nodes. Conceptually, a relevant model is the iSNS which defines a protocol and a server to coodinate the setting up of connections among storage nodes by emulating Fibre Channel fabric services. This is the model which would be useful for setting up connections among authorized network nodes from a scalability viewpoint. Mike ----- Original Message ----- From: Tina Tsou To: 'MichaelKo' ; opsawg@ietf.org Sent: Tuesday, June 14, 2011 11:16 PM Subject: RE: [OPSAWG] Problem statement on setting up dynamic virtual network Michael, Let me know whether this draft targeted to Routing Area is relevant to yours. https://datatracker.ietf.org/doc/draft-yu-ircat-problem-statement/ We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of MichaelKo Sent: Tuesday, June 14, 2011 10:00 PM To: opsawg@ietf.org; opsawg@ietf.org Subject: [OPSAWG] Problem statement on setting up dynamic virtual network I have submitted a new IETF draft titled "Problem Statement for Setting Up Dynamic Virtual Networks". Link to the draft is here: http://datatracker.ietf.org/doc/draft-ko-dvn-problem-statement/ The abstract is as follows: "This document examines the problems and challenges associated with the process of setting up secure virtual network connections among authorized network nodes. The network nodes can be located anywhere in a private or public network, directly connected or behind one or more levels of NAT. Setting up a secure virtual network in this environment entails the resolution of various issues such as authentication, peer discovery, virtual network address management, and connection parameters determination." Some background information: At the OPSAWG meeting in IETF 79, Margaret Wasserman presented materials related to the IETF drafts (*) that she co-authored. She was subsequently asked to produce a problem statement and to continue the work within OPSAWG. This IETF draft is a continuation of that work. Your comments and suggestions are most welcome. Mike (*) "Dynamic Virtual Network Engine (DVNE) Protocol" (draft-mrw-dvne-prot-00) and "Dynamic Virtual Network Engine (DVNE) Framework" (draft-mrw-dvne-fw-00) _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_1aLnF4tlvxIfgYPJfcbhQQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Tina,
 
If I understand it correctly, the "IRCAT Problem Statement" draft discusses the problem of forming a cooperative router group from heterogeneous routers so that routers from different companies can interoperate.  The emphasis is the need for a protocol to manage and coordinate this cooperative router group.
 
My draft deals with the problem on setting up dynamic virtual networks among authorized network nodes.  Conceptually, a relevant model is the iSNS which defines a protocol and a server to coodinate the setting up of connections among storage nodes by emulating Fibre Channel fabric services.  This is the model which would be useful for setting up connections among authorized network nodes from a scalability viewpoint.
 
Mike
----- Original Message -----
From: Tina Tsou
Sent: Tuesday, June 14, 2011 11:16 PM
Subject: RE: [OPSAWG] Problem statement on setting up dynamic virtual network

Michael,
Let me know whether this draft targeted to Routing Area is relevant to
yours.
https://datatracker.ietf.org/doc/draft-yu-ircat-problem-statement/



We keep our promises with one another - no matter what!

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html


-----Original Message-----
From: opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] On Behalf Of
MichaelKo
Sent: Tuesday, June 14, 2011 10:00 PM
To: opsawg@ietf.org; opsawg@ietf.org
Subject: [OPSAWG] Problem statement on setting up dynamic virtual network

I have submitted a new IETF draft titled "Problem Statement for Setting Up
Dynamic Virtual Networks".

Link to the draft is here:
http://datatracker.ietf.org/doc/draft-ko-dvn-problem-statement/

The abstract is as follows:

"This document examines the problems and challenges associated with the
process of setting up secure virtual network connections among authorized
network nodes.  The network nodes can be located anywhere in a private or
public network, directly connected or behind one or more levels of NAT.
Setting up a secure virtual network in this environment entails the
resolution of various issues such as authentication, peer discovery, virtual
network address management, and connection parameters determination."

Some background information:  At the OPSAWG meeting in IETF 79, Margaret
Wasserman presented materials related to the IETF drafts (*) that she
co-authored.  She was subsequently asked to produce a problem statement and
to continue the work within OPSAWG.  This IETF draft is a continuation of
that work.

Your comments and suggestions are most welcome.

Mike

(*) "Dynamic Virtual Network Engine (DVNE) Protocol"
(draft-mrw-dvne-prot-00) and "Dynamic Virtual Network Engine (DVNE)
Framework" (draft-mrw-dvne-fw-00)
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
--Boundary_(ID_1aLnF4tlvxIfgYPJfcbhQQ)-- From wwwrun@rfc-editor.org Fri Jun 17 09:53:14 2011 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 4AB2A11E8202; Fri, 17 Jun 2011 09:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aphKFL+lepsl; Fri, 17 Jun 2011 09:53:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3E411E8200; Fri, 17 Jun 2011 09:53:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8379E98C516; Fri, 17 Jun 2011 09:53:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110617165313.8379E98C516@rfc-editor.org> Date: Fri, 17 Jun 2011 09:53:13 -0700 (PDT) Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] BCP 161, RFC 6291 on Guidelines for the Use of the "OAM" Acronym in the IETF 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, 17 Jun 2011 16:53:14 -0000 A new Request for Comments is now available in online RFC libraries. BCP 161 RFC 6291 Title: Guidelines for the Use of the "OAM" Acronym in the IETF Author: L. Andersson, H. van Helvoort, R. Bonica, D. Romascanu, S. Mansfield Status: Best Current Practice Stream: IETF Date: June 2011 Mailbox: loa.andersson@ericsson.com, huub.van.helvoort@huawei.com, rbonica@juniper.net, dromasca@avaya.com, scott.mansfield@ericsson.com Pages: 9 Characters: 16696 See Also: BCP0161 I-D Tag: draft-ietf-opsawg-mpls-tp-oam-def-10.txt URL: http://www.rfc-editor.org/rfc/rfc6291.txt At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. This document is a product of the Operations and Management Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sob@harvard.edu Sat Jun 18 08:08:10 2011 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 95E5311E80FB for ; Sat, 18 Jun 2011 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_20=-0.74, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7typjzM0HHms for ; Sat, 18 Jun 2011 08:08:10 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9D11E809F for ; Sat, 18 Jun 2011 08:08:10 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id E08A4C0A5CC; Sat, 18 Jun 2011 11:08:08 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20110618150808.E08A4C0A5CC@newdev.eecs.harvard.edu> Date: Sat, 18 Jun 2011 11:08:08 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] agenda items for the opsawg session in Quebec City 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, 18 Jun 2011 15:08:10 -0000 this is a call for agenda items for the opsawg session in Quebec City. the session time will be shared with the open ops area meeting (as it was last time) but this time the sessions will be one after the other rather than intermingled - thanks Scott From j.schoenwaelder@jacobs-university.de Sat Jun 18 08:14:12 2011 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 CF48011E811A for ; Sat, 18 Jun 2011 08:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.177 X-Spam-Level: X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZkMtXDDhsEG for ; Sat, 18 Jun 2011 08:14:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A90D11E809F for ; Sat, 18 Jun 2011 08:14:12 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 62F3620BEE for ; Sat, 18 Jun 2011 17:14:11 +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 NnnLJDqfhGs4; Sat, 18 Jun 2011 17:14:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E38B20BDD; Sat, 18 Jun 2011 17:14:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CA116191DE9A; Sat, 18 Jun 2011 17:14:09 +0200 (CEST) Date: Sat, 18 Jun 2011 17:14:09 +0200 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20110618151409.GA47075@elstar.local> Mail-Followup-To: opsawg@ietf.org References: <20110601092422.GA48402@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110601092422.GA48402@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [OPSAWG] draft-ietf-opsawg-automated-network-configuration-01.txt ready for WG last call 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, 18 Jun 2011 15:14:12 -0000 On Wed, Jun 01, 2011 at 11:24:22AM +0200, Juergen Schoenwaelder wrote: > > I believe the document is complete and I like to ask the chairs to > issue a WG last call. > Chairs, any idea when you will find time to process this request? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From sob@harvard.edu Mon Jun 20 03:38:54 2011 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 7426E11E812E for ; Mon, 20 Jun 2011 03:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhUE6LDCdcQ7 for ; Mon, 20 Jun 2011 03:38:54 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0654611E8123 for ; Mon, 20 Jun 2011 03:38:53 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 0B197C1608E; Mon, 20 Jun 2011 06:38:42 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20110620103842.0B197C1608E@newdev.eecs.harvard.edu> Date: Mon, 20 Jun 2011 06:38:42 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] WGLC on draft-ietf-opsawg-automated-network-configuration-01.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: Mon, 20 Jun 2011 10:38:54 -0000 this starts a WGLC on draft-ietf-opsawg-automated-network-configuration-01.txt please read the ID and let the list know if you think the ID is ready for publication as an informational RFC thanks Scott From sob@harvard.edu Mon Jun 20 04:52:39 2011 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 EEDAA11E810F for ; Mon, 20 Jun 2011 04:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK8zRL4FuK2A for ; Mon, 20 Jun 2011 04:52:39 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 78C7211E807A for ; Mon, 20 Jun 2011 04:52:39 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 0AA63C16343; Mon, 20 Jun 2011 07:52:38 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20110620115239.0AA63C16343@newdev.eecs.harvard.edu> Date: Mon, 20 Jun 2011 07:52:38 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] ps on WGLC on draft-ietf-opsawg-automated-network-configuration-01.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: Mon, 20 Jun 2011 11:52:40 -0000 the WGLC ends on July 4th Scott From Michael@huaweisymantec.com Mon Jun 20 12:08:27 2011 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 54FC211E80FC for ; Mon, 20 Jun 2011 12:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ahYOcQPgFXY for ; Mon, 20 Jun 2011 12:08:26 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by ietfa.amsl.com (Postfix) with ESMTP id E5C0611E80A5 for ; Mon, 20 Jun 2011 12:08:25 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_aBwT39RUeXE/lwnRlgZuaA)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LN30061ERTZE850@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Tue, 21 Jun 2011 03:08:23 +0800 (CST) Received: from KOALA ([69.199.248.19]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LN3001G8RUWGK00@hstml01-in.huaweisymantec.com> for opsawg@ietf.org; Tue, 21 Jun 2011 03:09:02 +0800 (CST) Message-id: <7EA8A773784746FD9808EF69D7A20A45@KOALA> From: Michael Ko To: "Scott O. Bradner" , opsawg@ietf.org References: <20110618150808.E08A4C0A5CC@newdev.eecs.harvard.edu> Date: Mon, 20 Jun 2011 12:08:21 -0700 X-Priority: 3 X-MSMail-priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: Re: [OPSAWG] agenda items for the opsawg session in Quebec City 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 Jun 2011 19:08:27 -0000 This is a multi-part message in MIME format. --Boundary_(ID_aBwT39RUeXE/lwnRlgZuaA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT I am requesting time at the opsawg session to discuss the problem statement on setting up dynamic virtual network (draft-ko-dvn-problem-statement-00). This is a follow-up on the presentation by Margaret Wasserman at IETF 79 related to the protocol for dynamic virtual networks (draft-mrw-dvne-prot-00 and draft-mrw-dvne-fw-00). I want to determine if there is interest in pursuing the protocol work and if so, whether it should be done at opsawg or a separate wg. Mike ----- Original Message ----- From: Scott O. Bradner To: opsawg@ietf.org Sent: Saturday, June 18, 2011 8:08 AM Subject: [OPSAWG] agenda items for the opsawg session in Quebec City this is a call for agenda items for the opsawg session in Quebec City. the session time will be shared with the open ops area meeting (as it was last time) but this time the sessions will be one after the other rather than intermingled - thanks Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_aBwT39RUeXE/lwnRlgZuaA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
I am requesting time at the opsawg session to discuss the problem statement on setting up dynamic virtual network (draft-ko-dvn-problem-statement-00).  This is a follow-up on the presentation by Margaret Wasserman at IETF 79 related to the protocol for dynamic virtual networks (draft-mrw-dvne-prot-00 and draft-mrw-dvne-fw-00).  I want to determine if there is interest in pursuing the protocol work and if so, whether it should be done at opsawg or a separate wg.
 
Mike
----- Original Message -----
Sent: Saturday, June 18, 2011 8:08 AM
Subject: [OPSAWG] agenda items for the opsawg session in Quebec City


this is a call for agenda items for the opsawg session in Quebec City.

the session time will be shared with the open ops area meeting (as it
was last time) but this time the sessions will be one after the other
rather than intermingled -

thanks

Scott
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
--Boundary_(ID_aBwT39RUeXE/lwnRlgZuaA)-- From sob@harvard.edu Mon Jun 20 12:11:20 2011 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 1D00A11E80FC for ; Mon, 20 Jun 2011 12:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.733 X-Spam-Level: X-Spam-Status: No, score=-102.733 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xpc4f3r6nmk for ; Mon, 20 Jun 2011 12:11:19 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1D611E808E for ; Mon, 20 Jun 2011 12:11:19 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 9D040C17C9A; Mon, 20 Jun 2011 15:11:18 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20110620191118.9D040C17C9A@newdev.eecs.harvard.edu> Date: Mon, 20 Jun 2011 15:11:18 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] dynamic virtual networks 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 Jun 2011 19:11:20 -0000 please review & comment on these IDs - thanks Scott ------ From: Michael Ko To: "Scott O. Bradner" , opsawg@ietf.org References: <20110618150808.E08A4C0A5CC@newdev.eecs.harvard.edu> Subject: Re: [OPSAWG] agenda items for the opsawg session in Quebec City Date: Mon, 20 Jun 2011 12:08:21 -0700 I am requesting time at the opsawg session to discuss the problem statement on setting up dynamic virtual network (draft-ko-dvn-problem-statement-00). This is a follow-up on the presentation by Margaret Wasserman at IETF 79 related to the protocol for dynamic virtual networks (draft-mrw-dvne-prot-00 and draft-mrw-dvne-fw-00). I want to determine if there is interest in pursuing the protocol work and if so, whether it should be done at opsawg or a separate wg. Mike ----- Original Message ----- From: Scott O. Bradner To: opsawg@ietf.org Sent: Saturday, June 18, 2011 8:08 AM Subject: [OPSAWG] agenda items for the opsawg session in Quebec City this is a call for agenda items for the opsawg session in Quebec City. the session time will be shared with the open ops area meeting (as it was last time) but this time the sessions will be one after the other rather than intermingled - thanks Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From shao.weixiang@zte.com.cn Tue Jun 21 21:03:47 2011 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 9098911E8122 for ; Tue, 21 Jun 2011 21:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.929 X-Spam-Level: X-Spam-Status: No, score=-88.929 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, CN_BODY_46=0.256, HTML_FONT_FACE_BAD=0.884, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4FpJIpMs-em for ; Tue, 21 Jun 2011 21:03:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A680B11E811C for ; Tue, 21 Jun 2011 21:03:38 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 131321390076507; Wed, 22 Jun 2011 12:01:30 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 86887.1390076507; Wed, 22 Jun 2011 12:03:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p5M4354B073860 for ; Wed, 22 Jun 2011 12:03:06 +0800 (GMT-8) (envelope-from shao.weixiang@zte.com.cn) To: opsawg@ietf.org MIME-Version: 1.0 X-KeepSent: 1B75E507:8F2DB51C-482578B7:0015F80A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: shao.weixiang@zte.com.cn Date: Wed, 22 Jun 2011 12:03:03 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-06-22 12:03:07 Content-Type: multipart/mixed; boundary="=_mixed 001646A9482578B7_=" X-MAIL: mse02.zte.com.cn p5M4354B073860 X-Mailman-Approved-At: Tue, 21 Jun 2011 23:38:53 -0700 Subject: [OPSAWG] draft-shao-opsawg-cloud-service-broker 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 Jun 2011 04:03:47 -0000 --=_mixed 001646A9482578B7_= Content-Type: multipart/related; boundary="=_related 001646AA482578B7_=" --=_related 001646AA482578B7_= Content-Type: multipart/alternative; boundary="=_alternative 001646AA482578B7_=" --=_alternative 001646AA482578B7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8sIEFsbA0KDQpJIGFtIFNoYW8gd2VpeGlhbmcgZnJvbSBaVEUgQ29ycG9yYXRpb24sIEkg dXBsb2FkIGFuIGluZGl2aWR1YWwgZHJhZnQuIA0KUGxlYXNlIHRha2UgYSBsb29rLg0KDQoNCmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2hhby1vcHNhd2ctY2xvdWQtc2Vy dmljZS1icm9rZXIvP2luY2x1ZGVfdGV4dD0xDQoNCkZpbGVuYW1lOiAgICAgICAgICAgICAgICAg ZHJhZnQtc2hhby1vcHNhd2ctY2xvdWQtc2VydmljZS1icm9rZXINClJldmlzaW9uOiAgICAgICAg ICAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDbG91ZCBTZXJ2 aWNlIEJyb2tlcg0KQ3JlYXRpb24gZGF0ZTogICAgICAgICAgICAyMDExLTA2LTIyDQpXRyBJRDog ICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIg b2YgcGFnZXM6IDg0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEg Q2xvdWQgU2VydmljZSBCcm9rZXIgKENTQikgZW50aXR5IHRvDQogICBwcm92aWRlIGJyb2tlcmlu ZyBmdW5jdGlvbnMgYmV0d2VlbiBkaWZmZXJlbnQgQ2xvdWQgU2VydmljZSBQcm92aWRlcnMNCiAg IGFuZCBDbG91ZCBTZXJ2aWNlIGNvbnN1bWVycy4NCg0KDQoNCg0KDQoNClNoYW8gV2VpeGlhbmcg ydvOsM/oDQpTdGFuZGFyZCBEZXZlbG9wbWVudCBBbmQgSW5kdXN0cnkgUmVsYXRpb25zIERlcHQu DQoNClByb2R1Y3QgUiZEIFN5c3RlbSANCrL6xrfR0LeizOXPtQ0KRTMwNSxOby44ODksQmlibyBS ZCxaaGFuZ2ppYW5nIEhpLVRlY2ggUGFyayxQdWRvbmcsU2hhbmdoYWkgDQpQLlIuQ2hpbmEsIDIw MTIwMw0KVGVsOis4Ni0yMS02ODg5Njk3Ng0KTW9iaWxlOis4Ni0xMzkxNjYxNTgxNw0KRW1haWw6 c2hhby53ZWl4aWFuZ0B6dGUuY29tLmNuIA0KDQoNCiANCg== --=_alternative 001646AA482578B7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvLCBBbGw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gU2hhbyB3ZWl4aWFu ZyBmcm9tIFpURSBDb3Jwb3JhdGlvbiwNCkkgdXBsb2FkIGE8L2ZvbnQ+PHR0Pjxmb250IHNpemU9 Mj5uIGluZGl2aWR1YWw8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ DQpkcmFmdC4gUGxlYXNlIHRha2UgYSBsb29rLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zaGFvLW9wc2F3Zy1jbG91ZC1zZXJ2aWNlLWJyb2tlci8/aW5jbHVkZV90ZXh0PTE8 L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5GaWxlbmFtZTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQt c2hhby1vcHNhd2ctY2xvdWQtc2VydmljZS1icm9rZXI8YnI+DQpSZXZpc2lvbjogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7MDA8 YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCkNsb3VkIFNlcnZpY2UgQnJva2VyPGJyPg0KQ3JlYXRpb24gZGF0 ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7MjAxMS0wNi0yMjxicj4NCldHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KSW5kaXZpZHVhbCBTdWJtaXNz aW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiA4NDxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiAm bmJzcDsgVGhpcyBkb2N1bWVudCBpbnRyb2R1Y2VzIGEgQ2xvdWQgU2VydmljZSBCcm9rZXIgKENT QikgZW50aXR5IHRvPGJyPg0KICZuYnNwOyBwcm92aWRlIGJyb2tlcmluZyBmdW5jdGlvbnMgYmV0 d2VlbiBkaWZmZXJlbnQgQ2xvdWQgU2VydmljZSBQcm92aWRlcnM8YnI+DQogJm5ic3A7IGFuZCBD bG91ZCBTZXJ2aWNlIGNvbnN1bWVycy48YnI+DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPGRpdiBh bGlnbj1jZW50ZXI+PGltZyBzcmM9Y2lkOl8yXzA3REIzNkQ4MDdEQjMyRjAwMDE2NDZBNTQ4MjU3 OEI3PjwvZGl2Pg0KPHRkPg0KPGJyPjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0cj4NCjx0ZCBjb2xzcGFuPTI+PGZvbnQgc2l6ZT0zIGZhY2U9IruqzsS3 wsvOIj48Yj48aT5TaGFvIDwvaT48L2I+PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ PGI+PGk+V2VpeGlhbmc8L2k+PC9iPjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iu6rOxLfCy84i PjxiPjxpPg0KydvOsM/oPC9pPjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFy aWFsIj5TdGFuZGFyZCBEZXZlbG9wbWVudCBBbmQgSW5kdXN0cnkgUmVsYXRpb25zDQpEZXB0Ljwv Zm9udD4NCjx0cj4NCjx0ZCByb3dzcGFuPTI+PGltZyBzcmM9Y2lkOl8yXzA3REI1QzU4MDdEQjU4 OUMwMDE2NDZBNTQ4MjU3OEI3Pg0KPHRkPjxmb250IHNpemU9MSBjb2xvcj0jOTA5MDkwIGZhY2U9 IkFyaWFsIj48Yj5Qcm9kdWN0IFImYW1wO0QgU3lzdGVtIDwvYj48L2ZvbnQ+DQo8dHI+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGNvbG9yPSM5MDkwOTAgZmFjZT0iQXJpYWwiPjxiPrL6xrfR0LeizOXPtTwv Yj48L2ZvbnQ+DQo8dHI+DQo8dGQgY29sc3Bhbj0yPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ RTMwNSxOby44ODksQmlibyBSZCxaaGFuZ2ppYW5nDQpIaS1UZWNoIFBhcmssUHVkb25nLFNoYW5n aGFpIDxicj4NClAuUi5DaGluYSwgMjAxMjAzPGJyPg0KVGVsOis4Ni0yMS02ODg5Njk3Njxicj4N Ck1vYmlsZTorODYtMTM5MTY2MTU4MTc8YnI+DQpFbWFpbDpzaGFvLndlaXhpYW5nQHp0ZS5jb20u Y24gPC9mb250PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj48Zm9udCBzaXplPTEg ZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCg== --=_alternative 001646AA482578B7_=-- --=_related 001646AA482578B7_= Content-Type: image/jpeg Content-ID: <_2_07DB36D807DB32F0001646A5482578B7> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCACEAIkDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gBKa8iRxs7sFVRkknAFUdW1ez0Wwe8vZQka9B3Y+gHc14t4q8X6j4lkaIs9tp4PyW6HBcf7Z7/Su ihhpVXpsZVKqgjY134l6rpniC6g026sr+xDAoxQgqT1XI649am034uald3dvaPokUssziNRFMQSS fcV51HZvPMlvBE8kjcJHGMk/hXe/Czw6Z9Yn1e5jxHaZiiDD/lp3P4dK9KrRoU6d2tUcMKlWc9Hu ewISUBYbWwMjrink4oyByTgVBJeW0X+snjX6sK8Wzex6ZIz1Cz00ajYvwLqEn/eFTBYZRlSrD1U5 pSjIV77EHmsv3Wx9act4BxIMe4oltm6o2fY1Ql3xnawwfesZScdRNtGwrq4ypyPWnVgpcPC25G57 jsa07S9S5GPuuOqmqhUUtAUky3RRRWpQUUUUAJVTUNQg0yxlu7lwkUYyff2q3Xl3jTWW1XUDaQt/ otsSOOjv6/hWtGn7SViJy5Vc5rxDrN34hv2ubg7Y1OIYc8Rj+pqLRfDl7r979ntF2ouPNmb7sY/q farml6NPq2oR2kHDNyzkcIvrXrVpaWHhvSBFGBHBGMk93b19ya9CrXVGPJDc5o0+d80irofhrS/D FqWhUebjMlxJjc349h7Cqr6zBaB4NJtUVWcsz4wCxPJx3qheahPq82XykAPyRD+Z9TU9taZA4rk5 X8U9WOVTpArzS313zPcSMD2BwPyqo9gDywz9ea6ZNObZkrhfWkaxXptzVKpFaIhwk9zkJtPT+7+l UytzaNvtriWI/wCwxFdlcWG0ZZMehNZNzZDnitoVE9GYTUobFSy8calYSBL+IXUI6sBtcf412mma xpuv2pe2lEgH3424ZD7ivOL2zxnisTzLnTbxbuyleGdD95e49CO4onhYVFeOgU8ZKLtM9bvrN7cF 1+eL9VrOEzRsrKcOvQ1L4S8W2/iO2aCUCK/iH72Lsw/vL6inatZfZG3pzA3GP7prwsTQlTfod11J c8TY07UFvYsHiReGFXq4iC7e1uFnQ/MOo9RXY206XMCTRnKMMiroVudWe5cJ8ysT0UUV0GhjeJNQ OnaPLIhxLJ+7T6nvXl5hxyfxPcmu18XTGa+htx92JdxHuelZGkacL7V7eFhlA29/oP8A69d9C1On zMxn7zsdR4S0ZdL0wSyLi5uAHcnqB2H5Vh61qratqJiQ/wCiwthR/ePr/hXQeK9TOnaK4jOJZj5a Y7ep/KuO0uMEqMcCopRc26kjHEVOX3EbNlB0zXQWtuEUOwxnoO9U9LthJukf7i8n3NaSvvbd0HQD 0FZVJ3diqUNLssAO4G48e1MdWU8GpUbApkhFYHT0IpJhIuyRc+9UZrCOcHyW+YfwnrVmTFRNG8sZ ePO9O464q07bGUlzaM5u+s2Qsrrhh1Brl9StMAkCvSfNgvl+z3eFk6K49a5XWtOe2laOQe6kdGFd dCtrZnm4ijZXR559pudI1GK/s3MdxC25T2I7qfUEV7do2qWvinw/FeRj5Jlw6d0buPzrxrVoNu41 tfCzWjZeILjR5G/c3amSMHoJAOfzFdGMoqpT510FgazjLkfU6e7ia1uJIH+8hwT6j1rW8M3+JpLN zw3zpn9ab4rttphu17/u2/pXO2l2bW/guAcbXGfpmvkXL2FY7XLkmemUtNRgyhh0IzTq9dHYcPqy mbVLlzz820fhV/wvbBbm4mI5ChRUNzETdTE93J/WtbQE2Qz+pYfyrrnL93YhLU5Lx5eGTXLW0B+W GLeR7k/4CmaPGzyKqjJIrJ8WTF/Gt4rfwBFH0x/9eup8GvEZnVgN+3IJ7Ct5Lkoqx51+evZm+6i1 torZfvYyx96WNuwpt6yveYXk4Ap6MsOP4n/QV57Z3LctIjEZY7R70rPCnT5jVUyu/wB459u1NLVH MXzdiZ7k/wAKIPwpkd6yygP908YAxUDGoJDRzIhye4l+Qs7q8SEHkdqZGkWrQNZTkh1GY3PUVPqQ 3QwTf3htNY0jvEd6MVccgjtVxlqY1HyvU4/xJp7WNzJBJ94d/UetcfYXjaZ4i0+8U7TDcISR1xnB /Q13/iWX7dFHcv8Afb9259CK801D5ZGYdVOR+de1QbnTszynaNZOJ9F+IohcaDcEc7VDg/rXnUj5 U+4/Wu81HUre28PRJcEq1xbBV+UkEleledM+Bj8PWvisyklUVj0cVJXVj1fR5vtGkWkpPLRir9cx 4R1W1m062sFkLXMaZdQpwoye+MV09eph5qdNNHbTkpRTRg3MGLiT/ezVvSV2eavrg1NcQ5lz6022 Xy5/Zhg11uV42KtqeUeNwbbx1c56SxxuPfjH9K3PC1wEFzL3WLiqvxXsWhvNO1VBhSDA59+o/rUP g0TXkN75S5VYhuNdzfNQTPLknDENHcWjtLZBhgzqvPrilWQVi6XqLRyiRfvZ5HqPSt2eFZoftVr8 yHlkHUHvXmTi07HVCfMroBJ70GSqXm0hmFZ8o/aItmQetRtIDVUy00y+9DiJ1DUuSG0aJu6vj+dY VycKSa0riYDRYV7tIawb642x7Ryx4A96qKbehnWkhunaVDqtvqLXMhSKJcjno2DzXk92nnXiQp8x eQIPfLAV2+qXkljDLbJKVaRC0wU8HjgVheDtNOseN7CHbujhfz5PZV6frivYoXhBzZxJKc4xSPdL rS4b7SFsZl+URgA91IHBry670y8t9VOnNGXuC21AOjj+99K9h5qFrSBrlLlokM6qVVyOQK+cxeEj XaezPUrYdVLGd4e0SLRbJYwA078yvjqf8K2aQZpa6qcIwiox2NoxUVZCMobrUZi9KloqyjD8U6Iv iHw9dWB4kZd0TH+Fx0P51434Z1i90i7ntSxhd8wzRnqDyK9/ry74jeEZBOfEOnRFiMG7iTqwH8Y9 x3rswtVa05bM4sXSbXPHdFCwv9p2MeQcE+9dNp2rvbuGQ5B4ZT0YVyOqaro2oQ2VxpC+XOV2zpja M4H61HBqDpgOCp962nQc1fY89VXTla56Q622pKZbRgk/Vo24yaypmeCQpIpRveuei1MghgxBHQg4 NaSeJHeMR3KJOnTLcEfjXN9XkjV4mE99CyZ6a09VRd2N0wW389JG/gVd3Nbmm+HZZ8S3blYuoUjB I96iUFHcceab90p39yRHa2yDfIqZ2jk5NZl/KmkQ+bOQ94w/dxddnuav65rljotxLBYx+Zdt9+Zu QvtXnuo6i88jyOxZ2OSSckmuihh3J3aIr1FF2vdlTUrxm812bczdT3r0b4TaCbPSJtZuEKzXxxHn qIgePz61xPhLwvN4s1UGRSumQMDPJ0Dn+4P617siJBEkUahUUBVVegGK0xlRRXso/M3wNJ/xGT0U g6UteaemFFFFABRRRQA3cBTGkjwQzLg9QTWP4qspLzQpxCzrLGPMXaSCcdq8qimkdvmlkP1Y13YX BfWIuSlax4+YZo8JUUHC9zoPFXw+WSeXUPDuxmb5prMNwx9V9DXExX9xaytb3CEOhw0Uy4K16H4b 12HSkaGa3yrnJlXlvx9a6K+0rw/4rhBnSKZwOHU7ZF/HrXT7WdB8lVXj3Mowp4qPPTdpdjyuHUrM 8yWPP+xIRV+LWNJi5/skyEdpJjitm++FkqMW03Usr2S4XP4bhWRN4A8RwE7beGUDoUmHP4EVtGph pr4jCWHxFN/D+paTxpcwr5en2Nnaj+8q5IHvWfd+KdSlJ/0+Uk/ebOAfYDsKkj8D+JpV2ixjjB/v TAVpWnwv1OYg3t/DAncRAufzNJvCw1uhqni56Wf5HE3N8WLOzZLHk9ya3fDngPUfEMiXF6slnp5w SWGJJR6D0Hua9D0rwToOhMJjF9ouB/y1uDuOfYdq3Hvdw2xDCjjca56uMuuWivmddDAqD5qrv5BY 2Vpo9lHZWcKxQxjCov8AnmrCkkknrVVOeevqatxIT8x6V58lbVnqRd9ETL0paKKzNAooooAKKKKA GMoZSCOCMV58fAtxJcXjpKsYEpNupGQw68/yr0Okwa2o4idG/I9zkxODpYm3tFex5Pcadeac+y6g dDnhuoP41JCzIQyMVI6FTivUZIUlQpKgdT1DDIrIufC2nTksiNC3rGePyrujmEZK1RHmvKpU3ekz nrXWdQhAAuXZR2cA1ox+IL3HzCNvfBFOfwnKh/dXKsPR15po8O3y9DC3vk/4VMpYeWprCGJho7k4 1y7boI1+goOoXUo+aUgHqF4pI9Cu+5jH41ci0SQf6yYfgKzbox2OiMa0tyopJOScnuTzVuCNpD8q 5/lV2HToY8ZBc+rGraqFGFGBWMqq2R0QovdkENqEwW5PpVjtS0Vg23ubpJKyCiiikMKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/9k= --=_related 001646AA482578B7_= Content-Type: image/jpeg Content-ID: <_2_07DB5C5807DB589C001646A5482578B7> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAAjAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDqvEut +OLbxHew6ZFeGyVwISlmHUjA77TnnNUfCXjXxFqfiqxsbu+8yCR2EiCFQThWPYeor0Dxrq/9ieFb y4RsTSL5MPrubj9Bk/hXCfCTR/NvrvWJFysA8iIn+8cFj+AwPxrvhKLoSlKK00MGmppJmXe+MvHG nEG8muLZXJCGa0Vd2PTK1r6D4k8YXMd7cX7XAtF0+aeKVrYKhcLlSGxz/WrXxj/499H/AN+X+S10 Vv8A8knH/YJP/ounKUXSjLlWoknzNX2PObPxl431EN9iuLm5KY3eTaq+3OeuFr0Pwvrt1b+GTe+L LtbKU3LRiS92wDHG0c4HrXnngPxbZ+FjfG8guJftATb5IBxt3dcketWfjJrdv4i+EMOoW0ckcTai ihZAAeA47ZqcWuXRRsu46Tvrct/Fv4lnStCsJvCXiKxe6e5KzfZpIpzs2nqOcc4ruNL8ceHJdLsn ufEmk/aXgQyBryMHeVGeM8c181+MPh7Z+G/APh/xFBfTzTaosZeJ1AVN0e/jHNS+P/h7Z+C9N8OX lte3Fw2pqXdZVACYCHjH++a4Tc99v/iLBa/EE+DvsjxXUtsXtrqY4jkmIyq/7p5GfUYx3rH+G3xD vde8M+ILnX2jF/pEkkkwVQoWPaWAx7FWHc8CuV+M+o6FeeIdEex1q3tNe0u7WKYyI48lPvhiQvO0 gdM/erk/EOs6LpEfjC80TxBb3sniGTyks7eGRfLjZ97uxYAD+JQBnh85oA9r+FHjLVPGvhN9Q1W3 hjminaASRcCXAU529uv/AOqu2vXaOxuJEOGSNip9CAa4L4PX2g/8IVaaPpOoRXVzZRLJe+WjDbJI Sx5IGecj/gNd5qP/ACDbr/ri/wDI0AfMHjvxJBcXekz60L66vJLDJkhn8oFRPKBwMc8Gis7xlpVn fHRZbjxBpunuNP2iK6juGYjz5vmHlxOMc4654PHTJWiqNKxyTwVOcnJt6+bPWPi1rBuNWtdIhJK2 6+bIo7u3Qfl/6FXonhLR/wCwvDVnZFcShN8vu7ct/h+Fed+Ifh94jv8AxFfX0HkTRzzGSNzLtYDs Me3H5VNoPgzxbZeIbC6vJibaKZWlH2wtkfTvXXNU5UVGMlp+ZaclNtotfGP/AI99HP8A00l/ktdD b/8AJJh/2CT/AOi6qfEXwzqfiSLT001I3MDOX3ybcZAx/I1t2mj3A8Dx6PMVjuTZG3Yg7grbcVk5 x9jBX1TL5Xzs82+Gfh/S9eOpjU7QXHkiPy9zEYzuz0I9BWr8WfCMs3w0GleHdOkk8m7Sf7PDl2x8 24gHk8sKwovhz4vti3keXHng+Xd7c/livSfA+lano+gta6s5a5M7OCZfM+U4xz+dXi7SfMp38hUr rRo+Y/F2reNJvC2k6P4i0qay02xKx2rS2bRElU2gbj1+Wr2vN8RPGdnpEOoeHL57axUC2aHT3UFS FGc454Uc17V8ZvB+s+M9A0+z0aCOWaC6MriSQIAuwjv9a77SoJLXR7K3mAEkUEcbgHOCFANcRseF /G7QfCOjGTVZUuJvEOpSq6wifChRgMxXsMDA9z7GqXj/AOHnhjwx4CttfsdH1Ez3Dw7457j/AI9w 3zEPgf8AAfqfwrvJvhMupfFa68U6rdfabAMktvauxYlwBw2f4FIyB+HQc+iavpNnrWlXWnX0Qltb mMxyIe4P9R1HoaAOQ+F/hvwrpmjHWfCzTmDUo0LiabftK5+X2ILEGu11H/kG3X/XF/5GuF+GHw9u fATazFLftcW1xOptlDEAIAfmK9A5zg/7oru71GewuERSWaNgAO5waAPjr4if8fWh/wDYM/8Abiei r3xL0y4sNR0a2voJLe4TTRujbGRmeY/1orvpZbXqQU42s/MlzSPr+iiiuAoKKKKACiiigAooooAK KKKACiiigDmfEXw+8L+K9Qjvtb0z7VcxxCFX+0SphASQMKwHVj+dFFFaxr1Yqyk0vVisj//Z --=_related 001646AA482578B7_=-- --=_mixed 001646A9482578B7_= Content-Type: text/plain; name="draft-shao-opsawg-cloud-service-broker-00.txt" Content-Disposition: attachment; filename="draft-shao-opsawg-cloud-service-broker-00.txt" Content-Transfer-Encoding: quoted-printable =0A=0A=0Aopsawg Weixiang= . Shao=0AInternet-Draft J= ie. Hu=0AIntended status: Standards Track Bhumip. Khas= nabish=0AExpires: December 24, 2011 ZTE Corpo= ration=0A June 22= , 2011=0A=0A=0A Cloud Service Broker=0A = draft-shao-opsawg-cloud-service-broker-00=0A=0AAbstract=0A=0A This do= cument introduces a Cloud Service Broker (CSB) entity to=0A provide broke= ring functions between different Cloud Service Providers=0A and Cloud Ser= vice consumers.=0A=0AStatus of this Memo=0A=0A This Internet-Draft is sub= mitted in full conformance with the=0A provisions of BCP 78 and BCP 79.= =0A=0A Internet-Drafts are working documents of the Internet Engineering= =0A Task Force (IETF). Note that other groups may also distribute=0A w= orking documents as Internet-Drafts. The list of current Internet-=0A Dr= afts is at http://datatracker.ietf.org/drafts/current/.=0A=0A Internet-Dr= afts are draft documents valid for a maximum of six months=0A and may be = updated, replaced, or obsoleted by other documents at any=0A time. It is= inappropriate to use Internet-Drafts as reference=0A material or to cite= them other than as "work in progress."=0A=0A This Internet-Draft will ex= pire on December 24, 2011.=0A=0ACopyright Notice=0A=0A Copyright (c) 2011= IETF Trust and the persons identified as the=0A document authors. All r= ights reserved.=0A=0A This document is subject to BCP 78 and the IETF Tru= st's Legal=0A Provisions Relating to IETF Documents=0A (http://trustee.= ietf.org/license-info) in effect on the date of=0A publication of this do= cument. Please review these documents=0A carefully, as they describe you= r rights and restrictions with respect=0A to this document. Code Compone= nts extracted from this document must=0A include Simplified BSD License t= ext as described in Section 4.e of=0A the Trust Legal Provisions and are = provided without warranty as=0A described in the Simplified BSD License.= =0A=0A=0A=0A=0AShao, et al. Expires December 24, 2011 = [Page 1]=0A=0C=0AInternet-Draft Cloud Service Broker = June 2011=0A=0A=0ATable of Contents=0A=0A 1. Introduction . . .= . . . . . . . . . . . . . . . . . . . . . . 3=0A 2. Conventions and Te= rminology . . . . . . . . . . . . . . . . . 5=0A 3. CSB Architecture .= . . . . . . . . . . . . . . . . . . . . . . 6=0A 3.1. Cloud service = publish interface . . . . . . . . . . . . . 6=0A 3.2. Cloud Service = Consumer Interface . . . . . . . . . . . . . 7=0A 3.3. Cloud service = process . . . . . . . . . . . . . . . . . . 7=0A 3.4. Cloud service = adapter . . . . . . . . . . . . . . . . . . 8=0A 4. CSB Interface Defi= nitions . . . . . . . . . . . . . . . . . . 11=0A 4.1. Cloud Service = Publish Interface . . . . . . . . . . . . . 11=0A 4.1.1. HTTP Publi= sh Interface Usage . . . . . . . . . . . . . 11=0A 4.1.2. Publish in= terface Message Package Definition . . . . . 12=0A 4.2. Cloud Service = Consumer Interface . . . . . . . . . . . . . 27=0A 4.2.1. HTTP Consu= mer Interface Usage . . . . . . . . . . . . 28=0A 4.2.2. Consumer i= nterface Message Package Definition . . . . 28=0A 5. Examples . . . . .= . . . . . . . . . . . . . . . . . . . . . . 41=0A 5.1. Publish Exampl= e . . . . . . . . . . . . . . . . . . . . . 41=0A 5.2. Consumer Examp= le . . . . . . . . . . . . . . . . . . . . . 45=0A 6. Cloud Service Publ= ish Interface XML Schema . . . . . . . . . . 49=0A 7. Cloud Service Cons= umer Interface XML Schema . . . . . . . . . 64=0A 8. Security Considera= tions . . . . . . . . . . . . . . . . . . . 78=0A 9. IANA Consideration= s . . . . . . . . . . . . . . . . . . . . . 79=0A 9.1. application/cs= b-publish+xml MIME Type . . . . . . . . . . 79=0A 9.2. application/cs= b-consumer+xml MIME Type . . . . . . . . . . 80=0A 9.3. URN Sub-Namesp= ace Registration for csb-publish . . . . . 81=0A 9.4. URN Sub-Namesp= ace Registration for csb-consumer . . . . . 81=0A 9.5. XML Schema Reg= istration for csb-publish . . . . . . . . . 81=0A 9.6. XML Schema Reg= istration for csb-consumer . . . . . . . . . 81=0A 10. References . . . .= . . . . . . . . . . . . . . . . . . . . . . 82=0A 10.1. Normative Refe= rences . . . . . . . . . . . . . . . . . . . 82=0A 10.2. Informative Re= ferences . . . . . . . . . . . . . . . . . . 83=0A Authors' Addresses . .= . . . . . . . . . . . . . . . . . . . . . . 84=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0AShao, et al. Expires December 24, = 2011 [Page 2]=0A=0C=0AInternet-Draft Cloud Service= Broker June 2011=0A=0A=0A1. Introduction=0A=0A As speci= fied in the NIST Reference Architecture [NIST RA]document,=0A Cloud Broke= r is an entity manages the use, performance and delivery=0A of cloud serv= ices, and negotiates relationships between Cloud=0A Providers and Cloud C= onsumers.=0A=0A As specified in the CSAguide [CSAguide] document, Cloud s= ervice=0A broker offers intermediation, monitoring, transformation/portab= ility,=0A governance, provisioning, and integration services and negotiat= e=0A relationships between various cloud providers and consumers. Cloud= =0A service broker will emerge as an important component in the overall= =0A cloud ecosystem. It will abstract these possibly incompatible=0A c= apabilities and interfaces on behalf of consumers to provide proxy=0A in = advance of the arrival of common, open and standardized ways of=0A solvin= g the problem longer term with a semantic capability that=0A allows fluid= ity and agility in a Consumer being able to take=0A advantage of the mode= l that works best for their particular needs.=0A=0A As specified in the C= CUCWP [CCUCWP] document, A broker has no cloud=0A resources of its own, b= ut matches consumers and providers based on=0A the SLA required by the co= nsumer. The consumer has no knowledge that=0A the broker does not contro= l the resources.=0A=0A The simplest deployment view is illustrated in Fig= ure 1.=0A=0A=0A +---+-----+---+ +--= -+-----+---+=0A | cloud | | = public |=0A | |<-----+ +---->| = cloud |=0A +-------------+ | | +--= -----------+=0A | |=0A = +---+-----+---+ | | +---+-----+---+=0A = | WEB | | | | Private |=0A = | Service |<-----+ +---+-----+---+ +---->| cloud |=0A = +-------------+ | | cloud | | +-------------+=0A = |---| service |-----|=0A +---+-----+---+ = | | broker | | +---+-----+---+=0A | Application | = | +-------------+ +---->| Community |=0A | |<---= --+ | | cloud |=0A +-------------+ = | | +---+-----+---+=0A = | |=0A +---+-----+---+ | = | +---+-----+---+=0A | user | | = +---->| Hybid |=0A | |<-----+ = | cloud |=0A +-------------+ = +---+-----+---+=0A=0A=0A=0A=0A=0AShao, et al. Expire= s December 24, 2011 [Page 3]=0A=0C=0AInternet-Draft = Cloud Service Broker June 2011=0A=0A=0A = Figure 1: Basic Architecture=0A=0A A Cloud Service Broker (CSB) can = provide brokering service for=0A different Cloud Service Providers which = can base on private cloud,=0A community cloud, public cloud and hybrid cl= oud. CSB offers=0A intermediation, proxy, monitoring, transformation, po= rtability,=0A governance,provisioning, screening, substitution, security,= =0A composition services and negotiate relationships between various=0A = Cloud Service Providers and Cloud Service Requesters(consumers).=0A Clou= d Service Requesters (consumers) can be any web services,=0A applications= , users (e.g. enterprise users or public consume users),=0A even a cloud.= A cloud can through CSB to interworking with other=0A clouds.=0A=0A A= CSB can alliance with different clouds, the CSB integrates and=0A compos= es cloud services by orchestrating the cloud resources and=0A services ac= ross various cloud domain and Cloud Service Providers,=0A offers guarante= ed cloud services to consumers with SLA.=0A=0A In the cloud ecosystem, th= e Cloud Service Requesters(consumers) can=0A through CSB to access cloud = computing services and resources of Cloud=0A Service Providers. When CSB= receives the cloud service consumer=0A requests from Cloud Service Reque= sters, it will select appropriate=0A cloud computing services and resourc= es by Cloud Service Providers and=0A specific function pattern to execute= related cloud service operations=0A such as intermediation,proxy,monitor= ing, transformation/portability,=0A governance, provisioning, screening, = substitution, security,=0A composition services. CSB will invoke and ada= pt to the concrete=0A cloud services and resources from various Cloud Ser= vice Providers,=0A and return consumer response to Cloud Service Requeste= rs.=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AShao, = et al. Expires December 24, 2011 [Page 4]=0A=0C=0A= Internet-Draft Cloud Service Broker June 2011=0A= =0A=0A2. Conventions and Terminology=0A=0A In this document, BCP 14/RFC = 2119 [RFC2119] defines the key words=0A "MUST", "MUST NOT", "REQUIRED", "= SHALL", "SHALL NOT", "SHOULD",=0A "SHOULD NOT", "RECOMMENDED", "NOT RECOM= MENDED", "MAY", and=0A "OPTIONAL".=0A=0A CSAguide [CSAguide]Cloud Servi= ce Broker (CSB): A logical entity that=0A is responsible for offering int= ermediation, monitoring,=0A transformation, portability, governance, prov= isioning, and=0A integration services and negotiate relationships between= various=0A cloud providers and consumers.=0A=0A NIST Reference Archite= cture [NIST RA] Cloud Broker:An entity manages=0A the use, performance an= d delivery of cloud services, and negotiates=0A relationships between Clo= ud Providers and Cloud Consumers.=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0AShao, et = al. Expires December 24, 2011 [Page 5]=0A=0C=0AInt= ernet-Draft Cloud Service Broker June 2011=0A=0A= =0A3. CSB Architecture=0A=0A +--+-----+----+ +---------------+------= ---+ +------+------+=0A |Cloud Service| | Cloud Service Broker = | |Cloud Service|=0A | Requesters | | |= | Providers |=0A | (consumers) | | +---+-----+ +---+-----+ | = | |=0A | +---+-----+ | |-+-|Cloud | |Cloud |-+--| = | +---+---+-+ |=0A | | Cloud | | | | |Service | |Service | | | |= | IaaS | |=0A | | | | | | |consumer | |publish | | | | |= | |=0A | +---------+ | | | |interface| |interface| | | | +--= -------+ |=0A | | | | +--+------+ +----+----+ | | | = |=0A | +---+-----+ | | | | | | | | +---+--= -+-+ |=0A | | WEB | | | | |------+------| | | | | PaaS = | |=0A | | Service | | | | | | | | | |= |=0A | +---------+ |-| | +---------+-----------+ | |--| +---------+ |= =0A | | | |Cloud Service process| | | | |= =0A | +---+-----+ | | | | | | | +---+---+-+ |= =0A | |Applicat | | | +---------------------+ | | | | SaaS | |= =0A | |ion | | | | | | | | | |= =0A | +---------+ | | +---------+-----------+ | | | +---------+ |= =0A | | | |Cloud Service adapter| +--| | | |= =0A | +---+---+-+ | | | | | | +---+---+-+ |= =0A | | user | | | +---------------------+ | | | DSaaS | |= =0A | | | | | | | | | |= =0A | +---------+ | | | | +---------+ |= =0A | | | | | |= =0A +-+---------+-+ +-------------------------+ +-------------+= =0A=0A Figure 2: Cloud Service Broker Functional Architecture=0A= =0A CSB reference architecture functional groups consists of cloud=0A s= ervice consumer interface module, cloud service publish interface=0A modu= le, cloud service orchestration module and cloud service adapter=0A modul= e.=0A=0A3.1. Cloud service publish interface=0A=0A Cloud service publish= interface is used to provide different cloud=0A computing service and re= source information for CSB. Through cloud=0A service publish interface, = the CSB can subscribe different cloud=0A computing service and resource i= nformation from Cloud Service=0A Providers on demand by sending cloud ser= vice subscription request and=0A receiving cloud service notification fro= m Cloud Service Providers to=0A get these information. The published inf= ormation can be any=0A Infrastructure as a Service(IaaS) information, Pla= tform as a=0A service(PaaS) information, Software as a service(SaaS) info= rmation=0A and Data Storage as a service(DSaaS) information. Cloud Servi= ce=0A Providers (e.g. private cloud, community cloud, public cloud and=0A= =0A=0A=0AShao, et al. Expires December 24, 2011 [P= age 6]=0A=0C=0AInternet-Draft Cloud Service Broker = June 2011=0A=0A=0A hybrid cloud) can notify their published informatio= n to CSB.=0A=0A The subscription/notification can synchronize with the cl= oud service=0A consumer requests. In dynamic composition service functio= n pattern,=0A when CSB receives the cloud service consumer requests from = Cloud=0A Service Requesters, CSB can first subscribe the actual cloud ser= vice=0A from Cloud Service Providers based on the abstract service logic,= =0A then transfer to the concrete service logic to find the concrete=0A = services that can fulfil the requirements to replace the service=0A clas= ses and create invoking information for these services. Then the=0A CSB = executes the concrete service logic and gets the results of these=0A conc= rete services. The CSB then produces the final result and=0A returns it = to Cloud Service Requesters. The subscription/=0A notification can also = asynchronous working with the CSB other=0A operations.=0A=0A3.2. Cloud S= ervice Consumer Interface=0A=0A The Cloud Service Requesters (consumers l= ike web services,=0A applications, users, cloud) can through CSB Cloud Se= rvice Consumer=0A Interface to access Cloud Service Providers' cloud comp= uting services=0A and resources. It can receive cloud service consumer r= equests from=0A Cloud Service Requesters and return cloud service consume= r responses=0A to Cloud Service Requesters.=0A=0A3.3. Cloud service proc= ess=0A=0A The cloud service process module is used to process the cloud s= ervice=0A consumer requests from Cloud Service Requesters. It can receiv= e the=0A requests by Cloud Service Consumer Interface, analysis the reque= sted=0A cloud services, select appropriate service logics and function=0A= patterns based on CSB database information from subscription or=0A int= ernal integration, execute related operations, then invoke and=0A adapt t= o the concrete cloud services and resources from various Cloud=0A Service= Providers through cloud service adapters by sending cloud=0A service ada= ptation requests to Cloud Service Providers and receiving=0A cloud servic= e adaptation responses from Cloud Service Providers.=0A=0A The cloud serv= ice process module basic function pattern is=0A transformation/ translati= on, that is transfer or translate between=0A the Cloud Service Requesters= ' cloud service consumer requests/=0A responses and cloud service adaptat= ion requests/ responses for Cloud=0A Service Providers. CSB can provide = proxy service or Service=0A Intermediation which is defined in NIST Refe= rence Architecture [NIST=0A RA].=0A=0A Upon the basic function pattern,= the cloud service process module can=0A provide advanced function patter= ns, such as security service, QoS/SLA=0A=0A=0A=0AShao, et al. Ex= pires December 24, 2011 [Page 7]=0A=0C=0AInternet-Draft = Cloud Service Broker June 2011=0A=0A=0A control ser= vice, screening service, substitution service, and=0A composition service= . For composition service, the cloud service=0A process module make stat= ic service composition and dynamic service=0A composition. The static se= rvice composition is equal to Service=0A Aggregation and the dynamic serv= ice composition is equal to Service=0A Arbitrage specified in the NIST Re= ference Architecture [NIST RA].=0A=0A3.4. Cloud service adapter=0A=0A Th= e cloud service adapter module is used to adapt cloud services and=0A res= ources from Cloud Service Providers according to the cloud service=0A con= suming requests from CSRs, it will transfer and map protocols and=0A form= ats supported by Cloud Service Providers' services and resources=0A inclu= ding APIs, parameters and transmission protocols. The cloud=0A service a= dapter module consists of IaaS adapter module, DSaaS adapter=0A module, P= aaS adapter module, SaaS adapter module.=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= Shao, et al. Expires December 24, 2011 [Page 8]=0A= =0C=0AInternet-Draft Cloud Service Broker June 2= 011=0A=0A=0A +------------------------------+----------------------------= --+=0A | Cloud Service adapter |=0A= | +------------+-------------+ +------------+-------------+ |=0A | |= IaaS adapter | | DsaaS adapter | |=0A | | +----= +----+ +----+----+ | | +----+----+ +----+----+ | |=0A | | |common |= |CSP1 | | | |common | |CSP1 | | |=0A | | |IaaS | |Iaa= S | | | |DSaaS | |DSaaS | | |=0A | | |adapter | |adapter = | | | |adapter | |adapter | | |=0A | | +---------+ +---------+ | = | +---------+ +---------+ | |=0A | | | | = | |=0A | | +----+----+ +----+----+ | | +----+----= + +----+----+ | |=0A | | |CSP2 | |CSP3 | | | |CSP2 | |CS= P3 | | |=0A | | |IaaS | |IaaS | | | |DSaaS | |DSaaS = | | |=0A | | |adapter | |adapter | | | |adapter | |adapter | | |= =0A | | +---------+ +---------+ | | +---------+ +---------+ | |=0A = | +--------------------------+ +--------------------------+ |=0A | = |=0A | +---------= ---+-------------+ +------------+-------------+ |=0A | | PaaS ad= apter | | SaaS adapter | |=0A | | +----+----+ +----+-= ---+ | | +----+----+ +----+----+ | |=0A | | |common | |CSP1 | |= | |common | |CSP1 | | |=0A | | |PaaS | |PaaS | | | |= SaaS | |SaaS | | |=0A | | |adapter | |adapter | | | |adapte= r | |adapter | | |=0A | | | | | | | | | | = | | | |=0A | | +---------+ +---------+ | | +---------+ +-----= ----+ | |=0A | | | | = | |=0A | | +----+----+ +----+----+ | | +----+----+ +----+----+ | |=0A= | | |CSP2 | |CSP3 | | | |CSP2 | |CSP3 | | |=0A | |= |PaaS | |PaaS | | | |SaaS | |SaaS | | |=0A | | |adap= ter | |adapter | | | |adapter | |adapter | | |=0A | | +---------+= +---------+ | | +---------+ +---------+ | |=0A | +------------------= --------+ +--------------------------+ |=0A | = |=0A +--------------------------------= -----------------------------+=0A=0A=0A Figure 3: cloud se= rvice adapter module=0A=0A IaaS adapter module includes common IaaS adapt= er module and=0A proprietary IaaS adapter modules. Common IaaS adapter m= odule should=0A support general IaaS protocols mapping: DMTF OVF [DMTF OV= F], OGF OCCI=0A [OGF OCCI].=0A=0A DSaaS adapter module includes common = DSaaS adapter module and=0A proprietary DSaaS adapter modules. Common DS= aaS adapter module=0A should support general DSaaS protocols mapping: SNI= A CDMI [SNIA=0A CDMI].=0A=0A=0A=0A=0AShao, et al. Expires Dece= mber 24, 2011 [Page 9]=0A=0C=0AInternet-Draft Clou= d Service Broker June 2011=0A=0A=0A PaaS adapter module i= ncludes common PaaS adapter module and=0A proprietary PaaS adapter module= s.=0A=0A SaaS adapter module includes common SaaS adapter module and=0A = proprietary SaaS adapter modules.=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A= =0A=0A=0A=0A=0A=0A=0A=0A=0AShao, et al. Expires December 24, 201= 1 [Page 10]=0A=0C=0AInternet-Draft Cloud Service Br= oker June 2011=0A=0A=0A4. CSB Interface Definitions=0A=0A = As discussed in previous sections in this document, the intention is=0A = to provide a toolkit for a variety of deployment architectures where=0A = Cloud Service broker can take place. As a result, two main=0A interfaces= are required to support the differing requirements. The=0A two interfac= es are described in the remainder of this section and=0A have been named = the 'Cloud Service Publish' and 'Cloud Service=0A Consumer' interfaces. = These two interfaces have extremely differing=0A responsibilities and usa= ges which is reflected in the choice of=0A solutions.=0A=0A This includ= es interpreting the data for the Cloud Service Consumer=0A interface and = the Cloud Service Publish interface. It is, however,=0A important that t= he two interfaces are complimentary so that=0A development of appropriate= CSB functionality is supported.=0A=0A4.1. Cloud Service Publish Interface= =0A=0A The Cloud Service Publish interface is responsible for providing a= n=0A CSB with appropriate Cloud Service and resource information.=0A=0A = Service flow of cloud service subscription include: CSB send cloud=0A se= rvice subscription request to Cloud Service Providers using Publish=0A in= terface message Package within request message for subscription of=0A clo= ud services from Cloud Service Providers. CSB receive response=0A reply = by Cloud Service Providers for acceptance or fail reasons.=0A=0A Service = flow of cloud service notification include: Cloud Service=0A Providers se= nd notification to CSB using Publish interface message=0A Package within = notification message for publishing cloud services.=0A CSB return respons= e to Cloud Service Providers for acceptance or fail=0A reasons.=0A=0A4.1.= 1. HTTP Publish Interface Usage=0A=0A The following description will des= cribe the use of HTTP [RFC2616] and=0A HTTPS [RFC2818] as transport for a= subscription/notification and the=0A appropriate response.=0A=0A The c= loud service subscription request, as defined by the=0A ele= ment of element from Section 6, MUST be=0A carried in the bo= dy of an HTTP/HTTPS request. The MIME type=0A contained in the HTTP/HTTP= S request/response MUST be 'application/=0A csb-publish+xml'. This value= MUST be reflected in the appropriate=0A HTTP headers like 'Content-Type'= and 'Accept'. The body of the HTTP/=0A HTTPS request MUST only contain = the 'csbrequest' element as defined=0A in Section 6. The 'csbrequest' el= ement is the primary container of=0A=0A=0A=0AShao, et al. Expire= s December 24, 2011 [Page 11]=0A=0C=0AInternet-Draft = Cloud Service Broker June 2011=0A=0A=0A information rel= ated to a Cloud service subscription request.=0A=0A The Cloud service sub= scription response, as defined by the=0A element from Secti= on 6, MUST be carried in the body of=0A an HTTP/HTTPS 200 response to the= original HTTP/HTTPS request. The=0A MIME type contained in the HTTP/HTT= PS request/response MUST be=0A 'application/csb-publish+xml'. This value= MUST be reflected in the=0A appropriate HTTP headers like 'Content-Type'= and 'Accept'. The body=0A of the HTTP/HTTPS 200 response MUST only cont= ain the 'csbresponse'=0A element as defined in Section 6. The 'csbrespon= se' element is the=0A primary container of information related to a Cloud= service=0A subscription response.=0A=0A The cloud service notification= , as defined by the=0A element from Section 6, MUST be c= arried in the body=0A of an HTTP/HTTPS request. The MIME type contained = in the HTTP/HTTPS=0A request/response MUST be 'application/csb-publish+xm= l'. This value=0A MUST be reflected in the appropriate HTTP headers like= 'Content-Type'=0A and 'Accept'. The body of the HTTP/HTTPS request MUST= only contain=0A the 'csbnotification' element as defined in Section 6. = The=0A 'csbnotification' element is the primary container of information= =0A related to a Cloud service notification.=0A=0A CSB can map existing= HTTP verbs to operation for accessing and=0A controling an appropriate C= loud Service and resource. POST map to=0A Create operation, GET map to R= etrieve operation, PUT map to Create or=0A Update operation, DELETE map t= o Delete operation.=0A=0A4.1.2. Publish interface Message Package Definiti= on=0A=0A This Publish interface Message package is uesd for cloud service= s=0A information publishing between Cloud Service Providers and Cloud=0A = Service Requesters by CSB.=0A=0A4.1.2.1. Element Definitions=0A=0A Thi= s section defines the XML elements for the Publish interface=0A message p= ackage defined in Section 4.1. The formal XML schema=0A definition for t= he Publish interface can be found in Section 6.=0A=0A The root element is= . All other XML elements (request,=0A response, notificatio= n) are contained within it. The CSB Publish=0A interface request element= is detailed in Section 4.1.2.2. The CSB=0A Publish interface notificati= on element is detailed in=0A Section 4.1.2.3. CSB Publish interface resp= onse element is contained=0A in Section 4.1.2.4.=0A=0A The = element has the following attributes:=0A=0A=0A=0AShao, et al. E= xpires December 24, 2011 [Page 12]=0A=0C=0AInternet-Draft = Cloud Service Broker June 2011=0A=0A=0A version: = a token specifying the csb-publish package version. The=0A value is f= ixed as '1.0' for this version of the package. The=0A attribute MUST = be present.=0A=0A The element has the following child elemen= t, only one of=0A which is allowed to occur in a request.=0A=0A for sending an CSB request. See Section 4.1.2.2.=0A=0A for sending an CSB response. See Section 4.1.2.4.=0A=0A for sending an CSB notification. See=0A Section 4.1.2.3= .=0A=0A4.1.2.2. =0A=0A This section defines the = element used to initiate=0A requests from an CSB to a Cloud Service Prov= ider. The element is a=0A container for information relevant for the int= errogation of a Cloud=0A Service Provider.=0A=0A The eleme= nt has no defined attributes.=0A=0A The element has the foll= owing sub-elements which are=0A defined in the remainder of this section:= =0A=0A for initiating a subscription to a Cloud Service= =0A Provider from an CSB. See Section 4.1.2.2.1.=0A=0A4.1.2.2.1. =0A=0A The element is included in a request fro= m an CSB to a=0A Cloud Service Provider to provide the details relating t= o the cloud=0A service and resource information. This element can be use= d either to=0A request a new subscription or to update an existing one (e= .g., to=0A change the frequency of the updates), and to remove ongoing=0A= subscriptions as well (e.g., to stop an indefinite update). The CSB=0A = will inform the Cloud Service Provider how long it wishes to receive=0A = updates for and the frequency that updates should be sent. Updates=0A r= elated to the subscription are sent using the =0A elemen= t.=0A=0A The element has the following attributes:=0A=0A = id: indicates a unique token representing the subscription session=0A = between the csb and the Cloud Service Provider. The attribute=0A MU= ST be present.=0A=0A=0A=0A=0AShao, et al. Expires December 24, 2= 011 [Page 13]=0A=0C=0AInternet-Draft Cloud Service = Broker June 2011=0A=0A=0A seqnumber: indicates a sequenc= e number to be used in conjunction=0A with the subscrition session id = to identify a specific=0A subscription command. The first subscriptio= n MUST have 1 as=0A 'seqnumber', and following subscriptions MUST incr= ement by 1 the=0A previous 'seqnumber' value. The attribute MUST be p= resent.=0A=0A action: provides the operation that should be carried out = on the=0A subscription:=0A=0A * The value of 'create' instructs = the Cloud Service Provider to=0A attempt to setup a new subscriptio= n.=0A=0A * The value of 'update' instructs the Cloud Service Provider= to=0A attempt to update an existing subscription.=0A=0A * Th= e value of 'remove' instructs the Cloud Service Provider to=0A atte= mpt to remove an existing subscription and consequently=0A stop any= ongoing related notification.=0A=0A The attribute MUST be present.=0A= =0A The element has the following child elements:=0A=0A = expires: Provides the amount of time in seconds that a subscription=0A = should be installed for notifications at the Cloud Service=0A Provi= der. Once the amount of time has passed, the subscription=0A expires = and the csb has to subscribe again in case it is still=0A interested i= n receiving notifications from the Cloud Service=0A Provider. The ele= ment MAY be present.=0A=0A frequency: Provides the frequency in seconds= that the csb wishes to=0A receive notifications from the Cloud Servic= e Provider. The=0A element MAY be present.=0A=0A Please note that t= hese two optional pieces of information provided by=0A the csb only act a= s a suggestion: the Cloud Service Provider MAY=0A change the proposed val= ues if it considers the suggestions=0A unacceptable (e.g., if the csb has= requested a too high notification=0A frequency). In such case, the requ= est would not fail, but the=0A updated, acceptable values would be report= ed in the =0A accordingly.=0A=0A4.1.2.3. = =0A=0A The element is included in a request from a Clou= d=0A Service Provider to an csb to provide the details relating current= =0A status. The Cloud Service Provider will inform the csb of its=0A c= urrent status as defined by the information in the =0A=0A=0A= =0AShao, et al. Expires December 24, 2011 [Page 14]= =0A=0C=0AInternet-Draft Cloud Service Broker Jun= e 2011=0A=0A=0A element. Updates are sent using the el= ement=0A contained in an element.=0A=0A The element has the following attributes:=0A=0A id: indicates a unique t= oken representing the session between the=0A csb and the Cloud Service= Provider and is the same as the one=0A appearing in the element. The attribute MUST be=0A present.=0A=0A seqnumber: indi= cates a sequence number to be used in conjunction=0A with the subscrip= tion session id to identify a specific=0A notification update. The fi= rst notification MUST have 1 as=0A 'seqnumber', and following notifica= tions MUST increment by 1 the=0A previous 'seqnumber' value. The attr= ibute MUST be present.=0A=0A The element has the follow= ing child elements:=0A=0A for Cloud Service P= rovider information.=0A See Section 4.1.2.3.1.=0A=0A for specific Cloud Service information. See=0A Section 4.1.2.3.2.= =0A=0A for whether use encryption or not. See=0A= Section 4.1.2.3.3.=0A=0A