From dromasca@avaya.com Thu Oct 1 01:51:56 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4413A685E for ; Thu, 1 Oct 2009 01:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGdU48+BSe37 for ; Thu, 1 Oct 2009 01:51:55 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 14DFC3A67A1 for ; Thu, 1 Oct 2009 01:51:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,486,1249272000"; d="scan'208";a="175256195" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Oct 2009 04:53:00 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Oct 2009 04:52:59 -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: Thu, 1 Oct 2009 10:52:41 +0200 Message-ID: In-Reply-To: <02a201ca41ee$9ee2b540$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR thread-index: AcpB5d6EcK+Myu+RTbKv7bB9SwU76wABp6+AACHUtiA= References: <4ABCE564.20101@cisco.com><0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <02a201ca41ee$9ee2b540$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Wes Hardaker" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 08:51:56 -0000 Hi, See in-line.=20 Regards, Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, September 30, 2009 6:54 PM > To: 'Wes Hardaker'; Romascanu, Dan (Dan) > Cc: paduffy@cisco.com; opsawg@ietf.org > Subject: RE: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR >=20 > Hi, >=20 > I don't think you can assume all deployemnts use one vendor's=20 > tools just because there are no standard PIBs. > My research showed support in the Juniper/Netscreen products,=20 > and in Huawei/HuaweiSymantec products. > I have no reason to believe all deployments use exclusively=20 > one or the other's tools or PIBs. What I meant to say is that in a given deployments, in the absence of standards PIBs the agents and managers are probably originating from the same vendor and using proprietary PIBs. Of course there may be more than one such vendor in the market.=20 >=20 > It is safe to assume they may not interoperate across vendor=20 > implementations, if that was your point. But that is our=20 > fault, when we as a community decided not to allow PIBs onto=20 > the standards-track, and effectively told the COPS-PR=20 > developers to just go home. >=20 I would probably agree even before the first beer, but I am not sure if this discussion is useful right now. We are trying to determine whether to reclassify COPS-PR to Historic, we are not trying to make a post-mortem.=20 =20 > In the absence of standard YANG models, any netconf=20 > deployments are not all based on one vendor's tools. > In the absence of standard YANG models, the Netconf=20 > deployments using equipment from different vendors and=20 > vendor-specific data models are also not interoperable.=20 >=20 > Is that the point you wanted to make? That interoperability=20 > is hindered by not having standards-track models? >=20 Yes.=20 > dbh >=20 > > -----Original Message----- > > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > > Sent: Wednesday, September 30, 2009 11:51 AM > > To: Romascanu, Dan (Dan) > > Cc: David Harrington; paduffy@cisco.com; opsawg@ietf.org > > Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR > >=20 > > >>>>> On Wed, 30 Sep 2009 13:14:14 +0200, "Romascanu, Dan > > (Dan)" said: > >=20 > > DR> In the absence of standards PIBs I suspect that the > > majority or all > > DR> the deployments use one vendor tools > >=20 > > I don't think you can safely make that argument. =20 > Personally, I have=20 > > no knowledge about how well COPS or COPS-PR or=20 > implementations of MIBs=20 > > are/were used. But I think since the IETF functionally=20 > made all the=20 > > COPS folks mad by refusing to let them standardize their work (I'm > not > > saying whether this was right or wrong; it's simply fact) the end=20 > > result was all the COPS folks left the IETF. If PIBs were indeed=20 > > written they certainly wouldn't have been standardized within the=20 > > IETF. Maybe > the > > IETFs push-back did really cause the technology to become=20 > unused. I=20 > > don't know. But I don't think you can use any metrics affected by=20 > > IETF actions to decide that. > > -- > > Wes Hardaker > > Cobham Analytic Solutions > >=20 >=20 >=20 From dromasca@avaya.com Thu Oct 1 01:54:28 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A273A67A1 for ; Thu, 1 Oct 2009 01:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qovUX7W0Q83Q for ; Thu, 1 Oct 2009 01:54:27 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 8924E3A659A for ; Thu, 1 Oct 2009 01:54:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,486,1249272000"; d="scan'208";a="175256519" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 01 Oct 2009 04:55:52 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Oct 2009 04:55:51 -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: Thu, 1 Oct 2009 10:55:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR thread-index: AcpB8IcsQre4Xw5iQI+kPynvO4vrcQAhBupw References: <4ABCE564.20101@cisco.com><0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "Wes Hardaker" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 08:54:28 -0000 =20 > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net]=20 > Sent: Wednesday, September 30, 2009 7:07 PM > To: Romascanu, Dan (Dan) > Cc: Wes Hardaker; David Harrington; paduffy@cisco.com; opsawg@ietf.org > Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR >=20 > >>>>> On Wed, 30 Sep 2009 18:01:04 +0200, "Romascanu, Dan=20 > (Dan)" said: >=20 > DR> I am not sure that I understand the point that you are making. >=20 > The point I was making was that your statement: >=20 > DR> In the absence of standards PIBs I suspect that the=20 > majority or all=20 > DR> the deployments use one vendor tools and agents >=20 > I don't think is safe to say. Unless you're saying there are=20 > no standard PIBs anywhere (I don't know, personally). There=20 > aren't any in the IETF because the IETF chose not to publish=20 > them and actively discouraged their use. So if there are=20 > standard PIBs, we likely wouldn't know about them. > -- > Wes Hardaker > Cobham Analytic Solutions Hi,=20 I hope that I clarified what I meant to say already. Sorry for not being clear enough. If there are standard PIBs developped out of the IETF hopefully we shall learn now something about them.=20 Dan From ietfdbh@comcast.net Thu Oct 1 06:54:15 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B058E3A6947 for ; Thu, 1 Oct 2009 06:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB+Vj1iB-ias for ; Thu, 1 Oct 2009 06:54:15 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 04B773A6405 for ; Thu, 1 Oct 2009 06:54:09 -0700 (PDT) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA05.westchester.pa.mail.comcast.net with comcast id nQAK1c00417dt5G55RvbGk; Thu, 01 Oct 2009 13:55:35 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA13.westchester.pa.mail.comcast.net with comcast id nRvb1c00H284sdk3ZRvb6V; Thu, 01 Oct 2009 13:55:35 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Wes Hardaker'" References: <4ABCE564.20101@cisco.com><0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> Date: Thu, 1 Oct 2009 09:55:34 -0400 Message-ID: <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpB8IcsQre4Xw5iQI+kPynvO4vrcQAhBupwAAppWWA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 13:54:15 -0000 > Hi, > > I hope that I clarified what I meant to say already. Sorry > for not being > clear enough. If there are standard PIBs developped out of the IETF > hopefully we shall learn now something about them. > > Dan > I personally know of no PIBs developed inside or outside the IETF that are used by multiple vendors. I don't know if the IETF Informational PIBs are used, or just proprietary PIBs. Maybe we can get implementers to contribute some helpful implementation and deployment information. That would help IETF make a more informed decision. dbh From wjhns1@hardakers.net Thu Oct 1 07:27:58 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219F13A6855 for ; Thu, 1 Oct 2009 07:27:58 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3diUDkz0EQNs for ; Thu, 1 Oct 2009 07:27:57 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 4BB7E3A6821 for ; Thu, 1 Oct 2009 07:27:57 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id E0BF99839B; Thu, 1 Oct 2009 07:29:21 -0700 (PDT) From: Wes Hardaker To: "Romascanu\, Dan \(Dan\)" Organization: Sparta References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <02a201ca41ee$9ee2b540$0600a8c0@china.huawei.com> Date: Thu, 01 Oct 2009 07:29:21 -0700 In-Reply-To: (Dan Romascanu's message of "Thu, 1 Oct 2009 10:52:41 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 14:27:58 -0000 >>>>> On Thu, 1 Oct 2009 10:52:41 +0200, "Romascanu, Dan (Dan)" said: DR> We are trying to determine whether to reclassify COPS-PR to DR> Historic, we are not trying to make a post-mortem. Trying to do a post-mortem without a body is difficult. Trying to determine if we should go historical based on conversations on an IETF list for a protocol that was pushed out of the IETF is not likely to be a complete source of information. I suggest someone who desires to make it historical and wants to put in the work to make it happen should go ask operators at a bunch of operator conventions to see if anyone is using it. -- Wes Hardaker Cobham Analytic Solutions From khchan@huawei.com Thu Oct 1 07:42:22 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAA903A67F1 for ; Thu, 1 Oct 2009 07:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LXWSh9eHjD0 for ; Thu, 1 Oct 2009 07:42:22 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DBAE43A6A77 for ; Thu, 1 Oct 2009 07:42:21 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQU00K9KBKZ9C@usaga04-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 09:43:47 -0500 (CDT) Received: from K73911.huawei.com ([10.192.21.57]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0KQU00EW9BKUFR@usaga04-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 09:43:47 -0500 (CDT) Date: Thu, 01 Oct 2009 10:43:42 -0400 From: Kwok Ho Chan In-reply-to: <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> To: David Harrington Message-id: <0KQU00EWIBKWFR@usaga04-in.huawei.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 14:42:23 -0000 Hi: I know of COPS-PR work inside ITU-T (see ITU-T Y.2111). I believe Juniper may be using COPS-PR in some of their products, maybe using private PIBs. CableLab have their way of using COPS in DOCSIS, which I believe uses both push and pull models. I don't believe they call it COPS-PR, but DOCSIS uses some of the COPS-PR features. Does IETF provide an alternative Policy Management Protocol? Should IETF be the leader for Policy Management Protocol? Personally I believe Policy Management is important. -- Kwok -- At 09:55 AM 10/1/2009, David Harrington wrote: > > Hi, > > > > I hope that I clarified what I meant to say already. Sorry > > for not being > > clear enough. If there are standard PIBs developped out of the IETF > > hopefully we shall learn now something about them. > > > > Dan > > > >I personally know of no PIBs developed inside or outside the IETF that >are used by multiple vendors. > >I don't know if the IETF Informational PIBs are used, or just >proprietary PIBs. >Maybe we can get implementers to contribute some helpful >implementation and deployment information. >That would help IETF make a more informed decision. > >dbh > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From khchan@huawei.com Thu Oct 1 08:10:47 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859323A6783 for ; Thu, 1 Oct 2009 08:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbb3MTPaSZ+J for ; Thu, 1 Oct 2009 08:10:46 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id A60303A684B for ; Thu, 1 Oct 2009 08:10:46 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQU00KYNCWB5U@usaga02-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 08:12:11 -0700 (PDT) Received: from K73911.huawei.com ([10.192.21.57]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0KQU00LQ6CW9UD@usaga02-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 08:12:10 -0700 (PDT) Date: Thu, 01 Oct 2009 11:12:08 -0400 From: Kwok Ho Chan In-reply-to: <0KQU00EWIBKWFR@usaga04-in.huawei.com> To: Kwok Ho Chan Message-id: <0KQU00LQ8CWAUD@usaga02-in.huawei.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> <0KQU00EWIBKWFR@usaga04-in.huawei.com> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 15:10:47 -0000 I would like to add that Huawei uses COPS-PR. -- Kwok -- At 10:43 AM 10/1/2009, Kwok Ho Chan wrote: >Hi: >I know of COPS-PR work inside ITU-T (see ITU-T Y.2111). > >I believe Juniper may be using COPS-PR in some of their products, >maybe using private PIBs. > >CableLab have their way of using COPS in DOCSIS, which I believe >uses both push and pull models. I don't believe they call it COPS-PR, >but DOCSIS uses some of the COPS-PR features. > >Does IETF provide an alternative Policy Management Protocol? > >Should IETF be the leader for Policy Management Protocol? > >Personally I believe Policy Management is important. > >-- Kwok -- > > > >At 09:55 AM 10/1/2009, David Harrington wrote: > >> > Hi, >> > >> > I hope that I clarified what I meant to say already. Sorry >> > for not being >> > clear enough. If there are standard PIBs developped out of the IETF >> > hopefully we shall learn now something about them. >> > >> > Dan >> > >> >>I personally know of no PIBs developed inside or outside the IETF that >>are used by multiple vendors. >> >>I don't know if the IETF Informational PIBs are used, or just >>proprietary PIBs. >>Maybe we can get implementers to contribute some helpful >>implementation and deployment information. >>That would help IETF make a more informed decision. >> >>dbh >> >>_______________________________________________ >>OPSAWG mailing list >>OPSAWG@ietf.org >>https://www.ietf.org/mailman/listinfo/opsawg > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg From dromasca@avaya.com Thu Oct 1 08:18:36 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBF5328C15E for ; Thu, 1 Oct 2009 08:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVQ+Bu0jXAWO for ; Thu, 1 Oct 2009 08:18:35 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C44EF28C154 for ; Thu, 1 Oct 2009 08:18:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,488,1249272000"; d="scan'208";a="185286465" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Oct 2009 11:20:01 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Oct 2009 11:20:00 -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: Thu, 1 Oct 2009 17:19:40 +0200 Message-ID: In-Reply-To: <0KQU00LQ8CWAUD@usaga02-in.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR thread-index: AcpCqZDRXXFd1hvxTIC6qzQeUBBp7QAAIrnA References: <4ABCE564.20101@cisco.com><0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com><037b01ca429e$d908d0a0$0600a8c0@china.huawei.com><0KQU00EWIBKWFR@usaga04-in.huawei.com> <0KQU00LQ8CWAUD@usaga02-in.huawei.com> From: "Romascanu, Dan (Dan)" To: "Kwok Ho Chan" Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 15:18:36 -0000 Thanks,=20 Can you provide any details about the functionality, what devices and what applications implement it, do they use proprietary PIBs, was interoperability with other vendors devices and applications ever tested?=20 Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org=20 > [mailto:opsawg-bounces@ietf.org] On Behalf Of Kwok Ho Chan > Sent: Thursday, October 01, 2009 5:12 PM > To: Kwok Ho Chan > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR >=20 > I would like to add that Huawei uses COPS-PR. > -- Kwok -- >=20 > At 10:43 AM 10/1/2009, Kwok Ho Chan wrote: > >Hi: > >I know of COPS-PR work inside ITU-T (see ITU-T Y.2111). > > > >I believe Juniper may be using COPS-PR in some of their=20 > products, maybe=20 > >using private PIBs. > > > >CableLab have their way of using COPS in DOCSIS, which I=20 > believe uses=20 > >both push and pull models. I don't believe they call it=20 > COPS-PR, but=20 > >DOCSIS uses some of the COPS-PR features. > > > >Does IETF provide an alternative Policy Management Protocol? > > > >Should IETF be the leader for Policy Management Protocol? > > > >Personally I believe Policy Management is important. > > > >-- Kwok -- > > > > > > > >At 09:55 AM 10/1/2009, David Harrington wrote: > > > >> > Hi, > >> > > >> > I hope that I clarified what I meant to say already.=20 > Sorry for not=20 > >> > being clear enough. If there are standard PIBs developped out of=20 > >> > the IETF hopefully we shall learn now something about them. > >> > > >> > Dan > >> > > >> > >>I personally know of no PIBs developed inside or outside=20 > the IETF that=20 > >>are used by multiple vendors. > >> > >>I don't know if the IETF Informational PIBs are used, or just=20 > >>proprietary PIBs. > >>Maybe we can get implementers to contribute some helpful=20 > >>implementation and deployment information. > >>That would help IETF make a more informed decision. > >> > >>dbh > >> > >>_______________________________________________ > >>OPSAWG mailing list > >>OPSAWG@ietf.org > >>https://www.ietf.org/mailman/listinfo/opsawg > > > >_______________________________________________ > >OPSAWG mailing list > >OPSAWG@ietf.org > >https://www.ietf.org/mailman/listinfo/opsawg >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From khchan@huawei.com Thu Oct 1 08:39:52 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470B03A6853 for ; Thu, 1 Oct 2009 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJtN8A74Bech for ; Thu, 1 Oct 2009 08:39:51 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by core3.amsl.com (Postfix) with ESMTP id 649DA3A6833 for ; Thu, 1 Oct 2009 08:39:51 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQU009SWE8RCQ@usaga02-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 08:41:16 -0700 (PDT) Received: from K73911.huawei.com ([10.192.21.57]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0KQU00LDWE8QUD@usaga02-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 08:41:15 -0700 (PDT) Date: Thu, 01 Oct 2009 11:41:13 -0400 From: Kwok Ho Chan To: "Romascanu, Dan (Dan)" Message-id: <0KQU00LDYE8RUD@usaga02-in.huawei.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> <0KQU00EWIBKWFR@usaga04-in.huawei.com> <0KQU00LQ8CWAUD@usaga02-in.huawei.com> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 15:39:52 -0000 I believe Huawei follows the ITU-T functionality requirements for Policy Management. Which are available from ITU-T. -- Kwok -- At 11:19 AM 10/1/2009, Romascanu, Dan (Dan) wrote: >Thanks, > >Can you provide any details about the functionality, what devices and >what applications implement it, do they use proprietary PIBs, was >interoperability with other vendors devices and applications ever >tested? > >Regards, > >Dan > > > > -----Original Message----- > > From: opsawg-bounces@ietf.org > > [mailto:opsawg-bounces@ietf.org] On Behalf Of Kwok Ho Chan > > Sent: Thursday, October 01, 2009 5:12 PM > > To: Kwok Ho Chan > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR > > > > I would like to add that Huawei uses COPS-PR. > > -- Kwok -- > > > > At 10:43 AM 10/1/2009, Kwok Ho Chan wrote: > > >Hi: > > >I know of COPS-PR work inside ITU-T (see ITU-T Y.2111). > > > > > >I believe Juniper may be using COPS-PR in some of their > > products, maybe > > >using private PIBs. > > > > > >CableLab have their way of using COPS in DOCSIS, which I > > believe uses > > >both push and pull models. I don't believe they call it > > COPS-PR, but > > >DOCSIS uses some of the COPS-PR features. > > > > > >Does IETF provide an alternative Policy Management Protocol? > > > > > >Should IETF be the leader for Policy Management Protocol? > > > > > >Personally I believe Policy Management is important. > > > > > >-- Kwok -- > > > > > > > > > > > >At 09:55 AM 10/1/2009, David Harrington wrote: > > > > > >> > Hi, > > >> > > > >> > I hope that I clarified what I meant to say already. > > Sorry for not > > >> > being clear enough. If there are standard PIBs developped out of > > >> > the IETF hopefully we shall learn now something about them. > > >> > > > >> > Dan > > >> > > > >> > > >>I personally know of no PIBs developed inside or outside > > the IETF that > > >>are used by multiple vendors. > > >> > > >>I don't know if the IETF Informational PIBs are used, or just > > >>proprietary PIBs. > > >>Maybe we can get implementers to contribute some helpful > > >>implementation and deployment information. > > >>That would help IETF make a more informed decision. > > >> > > >>dbh > > >> > > >>_______________________________________________ > > >>OPSAWG mailing list > > >>OPSAWG@ietf.org > > >>https://www.ietf.org/mailman/listinfo/opsawg > > > > > >_______________________________________________ > > >OPSAWG mailing list > > >OPSAWG@ietf.org > > >https://www.ietf.org/mailman/listinfo/opsawg > > > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > > From dromasca@avaya.com Thu Oct 1 08:40:52 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789DF3A6853 for ; Thu, 1 Oct 2009 08:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.526 X-Spam-Level: X-Spam-Status: No, score=-0.526 tagged_above=-999 required=5 tests=[AWL=-1.824, BAYES_00=-2.599, FRT_PRICE=3.897] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdA40-9DCCmp for ; Thu, 1 Oct 2009 08:40:50 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 6D7F03A6833 for ; Thu, 1 Oct 2009 08:40:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,488,1249272000"; d="scan'208";a="185290358" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Oct 2009 11:42:15 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Oct 2009 11:42:15 -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: Thu, 1 Oct 2009 17:42:12 +0200 Message-ID: In-Reply-To: <029e01ca41eb$c39bd450$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] Present day reality of COPS-PR thread-index: AcpB1edsKKHaekbpROuR+Fz4bdcJ9QACWkLgAC/3dmA= References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <027001ca41c8$a74b8750$0600a8c0@china.huawei.com> <4AC363B0.4050909@cisco.com> <029e01ca41eb$c39bd450$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 15:40:52 -0000 One aspect of this discussion is surprising me a little :-)=20 For the record, since I am an AD (March 2006) I have never received a request for chartering a new PIB work in the IETF. Neither have I received any legacy instructions from my predecessor Bert Wijnen about new COPS-PR or PIB being a taboo. I think that I know his position, but this is not necessarily the same as mine. If I ever had received such a request I would have considered it without prejudice. It's still true even now. Probably everybody knows by now that I am not a 'one protocol fits all' adept.=20 Dan > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Wednesday, September 30, 2009 6:34 PM > To: paduffy@cisco.com; Romascanu, Dan (Dan) > Cc: opsawg@ietf.org > Subject: RE: [OPS-AREA] Present day reality of COPS-PR >=20 > Hi=20 >=20 > > -----Original Message----- > > From: Paul Duffy [mailto:paduffy@cisco.com] > > Sent: Wednesday, September 30, 2009 9:57 AM > > To: Romascanu, Dan (Dan) > > Cc: David Harrington; opsawg@ietf.org > > Subject: Re: [OPS-AREA] Present day reality of COPS-PR > >=20 > > Appreciate the investigation, but also agree it needs to be vetted=20 > > (academic versus real world deployments). >=20 > I absolutely agree that the list needs vetting. > I suspect the claims I have seen might blur the distinction=20 > between COPS-PR and "COPS with some COPS-PR-like proprietary=20 > extensions" >=20 > >=20 > > For example... > >=20 > > - AFAIK COPS, not COPS-PR, is used for DOCSIS/PacketCable=20 > DQoS. Hope=20 > > the rest of the list correctly makes this distinction. >=20 > I seem to recall vaguely that COPS-PR was in DOCSIS 1.0, but=20 > removed from 2.0, IIRC. > (Or was that SNMPv3?) > I don't work with DOCSIS standards, so I cannot vet this myself. >=20 > > - I've not been able to locate any open source community > > - I've located a single vendor, Trillium, that offers support=20 > > (embedded in an IMS suite). >=20 > I searched the web and found more than just Trillium. YMMV. >=20 > > - the word from my colleagues @ Cisco is that its time has passed. >=20 > Certainly Cisco pulled the plug on it a long time ago. >=20 > > - etc. > >=20 > > Its pretty clear its not massively deployed. >=20 > Neither is Netconf and YANG. > And if the IESG refused to allow any YANG models to advance=20 > to standards track, because the contents would duplicate MIB=20 > content, YANG probably will never get wide deployment. > Should we declare Netconf and YANG Historic as well? > Let's use consistent comparisons if Netconf and YANG are the=20 > replacement for COPS-PR. >=20 > Please understand. Up until recently I was fully convinced=20 > COPS-PR was dead. I didn't think declaring it Historic would=20 > make any difference because as far as I knew NOBODY was using=20 > it anyway. >=20 > COPS-PR only came up when Washam Fan wrote a LOCK-MIB that=20 > included a table for COPS-PR locks (which, as far as I knew,=20 > nobody would ever use). It was there for completeness;=20 > COPS-PR is an IETF standard that has a lock, and so is=20 > Netconf. So they should both be included in the LOCK-MIB. We=20 > have LOTS of things in MIB modules that are never used, so=20 > having a potential COPS-PR lock represented was largely=20 > meaningless and certainly not harmful. >=20 > But the Netconf community stepped up and said "Hey wait!=20 > ****we**** have the only IETF-BLESSED solution for=20 > configuration. We need to make sure this other thing gets=20 > declared Historic so nobody will be tempted to use it instead=20 > our solution." I don't think that's the best justification=20 > for declaring something Historic. >=20 > At the same time, this WG has been developing a guidelines=20 > document, and during IETF Last Call it was made very clear=20 > that the OPS-approach to management seems too oriented toward=20 > routers and device management, and that approach is NOT=20 > IETF-BLESSED as the only approach to management. Netconf and=20 > YANG very much follow that approach. So it seems apparent=20 > that the Netconf/YANG approach is not IETF-BLESSED as the=20 > ONLY way to do configuration management. In fact, the charter=20 > for YANG was required to say that it was ONE language, but=20 > not the only language, that could be used with netconf. And=20 > other areas are working on alternative approaches to configuration. >=20 > So I have a real problem with the desire to declare COPS-PR=20 > Historic because Netconf and YANG are BLESSED by the whole=20 > IETF to replace COPS-PR. As the editor for the Guidleines=20 > document, I had to deal directly with the feedback we got,=20 > and I do not believe Netconf and YANG are the BLESSED=20 > protocols for doing all configuration in the IETF. >=20 > If you look at COPS-PR, you will also see that COPS-PR does=20 > MUCH more than Netconf. The COPS-PR approach is very oriented=20 > toward policy-based management, with its policy decision=20 > points and policy enforcement points and policy-server=20 > discovery and so on. Netconf doesn't provide those features at all. >=20 > I have a history or questioning claims made by the netconf community. > I actually support netconf and YANG, but I think they really=20 > need to stop making inflated claims about what they can do. I=20 > think netconf has standardized some very important aspects of=20 > configuration, and I think YANG may be a very expressive=20 > langugae for data modeling. But they are still unproven in=20 > the marketplace. They do not have wide deployment yet. Cisco=20 > doesn't seem at all committed to YANG. Huawei implemented=20 > Netconf, but have no intention that I am aware of to implement YANG.=20 >=20 > I question whether Netconf and YANG replace the functionality=20 > found in COPS-PR. I think it does not. I was around when=20 > COPS-PR came out, and there were aspects that I thought would=20 > be useful for management purposes. My background is in NMS=20 > systems, and having to poll whole ranges of IP addresses to=20 > try to find the devices to manage is a horrible design;=20 > letting the devices come to the manager and ask to be managed=20 > makes tremendous sense to me. COPS-PR has that; SNMP and=20 > Netconf do not. >=20 > I don't want to throw out the baby with the bathwater in this=20 > rush to declare COPS-PR Historic. There are features in=20 > COPS-PR that we should be looking at to consider what might=20 > be good to keep. Declaring the whole thing Historic is not=20 > the right way to do that. >=20 > Technologies are converging. I think COPS-PR is more-telco=20 > oriented than Netconf is. The OPS area and the IETF in=20 > general are in the midst of a debate about allowing multiple=20 > protocols to be used to manage networks, rather than trying=20 > to force one protocol to be used for all purposes. We are=20 > having a discussion of what OAM means in different=20 > environments. When COPS-PR came out, we had a philosophy of=20 > SNMP-to-do-all-management, and "write a MIB" for all IETF=20 > standard protocols. We have grown significantly in our=20 > viewpoints since then, and are moving toward a "pick the tool=20 > that best does the job you need done". I don't think that=20 > declaring COPS-PR Historic at this point in time helps that.=20 > Maybe if we allowed PIBs to be standardized, COPS-PR would=20 > actually get implemented and deployed on a wider basis. I=20 > wouldn't bet on it, but we would be no worse off than we are now.=20 >=20 > I don't see the problem inherent in allowing COPS-PR and SPPI=20 > to remain standards, and allowing PIBs to be standards-track,=20 > as long as WGs are not required to write them. We are already=20 > allowing WGs to > "pick the tool that best does the job you need done" - including > SNMP, Netconf, Syslog, IPFIX, and others that are being=20 > developed in other areas. Maybe WGs would find COPS-PR to be=20 > a valuable tool for managing Internet resources, such as=20 > applications and services, where Netconf may not be "the best=20 > tool". Maybe if PIBs were allowed to be standards-track,=20 > somebody would be willing to make the changes to COPS-PR to=20 > make it more Netconf-compatible. >=20 > I just feel like we are trying to declare this Historic for=20 > the wrong reasons. >=20 > dbh >=20 > >=20 > >=20 > > Romascanu, Dan (Dan) wrote: > > > We can write a short cal for input about implementations > > and deployments > > > of COPS-PR on the general IETF list, pointing to the > > discussion going on > > > in OPSAWG. Certainly such input may also arrive at the time > > of the IETF > > > LC but it would be better to know about it earlier.=20 > > > > > > Dan > > > > > > > > > =20 > > >> -----Original Message----- > > >> From: David Harrington [mailto:ietfdbh@comcast.net] > > >> Sent: Wednesday, September 30, 2009 2:22 PM > > >> To: Romascanu, Dan (Dan); paduffy@cisco.com > > >> Cc: opsawg@ietf.org > > >> Subject: RE: [OPS-AREA] Present day reality of COPS-PR > > >> > > >> Hi, > > >> > > >> These claims were gathered by me from co-workers familiar with=20 > > >> COPS-PR. > > >> I have not checked any of the claims. > > >> > > >> The most interesting to me are the claims of deployment in FIOS,=20 > > >> FT-Orange, and Comcast. > > >> We should seek out people knowledgeable about the=20 > technologies used=20 > > >> in these networks, and ask about COPS-PR. > > >> Does anybody have contacts within the IT departments of these=20 > > >> companies? > > >> > > >> dbh > > >> > > >> =20 > > >>> -----Original Message----- > > >>> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > >>> Sent: Wednesday, September 30, 2009 7:14 AM > > >>> To: David Harrington; paduffy@cisco.com > > >>> Cc: opsawg@ietf.org > > >>> Subject: RE: [OPS-AREA] Present day reality of COPS-PR > > >>> > > >>> =20 > > >>> (moving the discussion to OPSAWG).=20 > > >>> > > >>> =20 > > >>>> -----Original Message----- > > >>>> From: ops-area-bounces@ietf.org > > >>>> [mailto:ops-area-bounces@ietf.org] On Behalf Of David > Harrington > > >>>> > > >>>> =20 > > >>>>> - there are few, if any, significant deployments. > > >>>>> > > >>>>> AFAIK, there is minimal commercial or open source support. > > >>>>> =20 > > >>>> I have not been able to research these claims, but I am > > told that > > >>>> COPS-PR is actually in use in a number of places. Here > > >>>> =20 > > >> are some of > > >> =20 > > >>>> the claims I have heard: > > >>>> > > >>>> 1) Juniper uses COPS-PR for their resource allocation, > > using both > > >>>> push and pull methods, at least in the access and aggregation=20 > > >>>> network. > > >>>> 2) COPS-PR may be deployed in the Verizon FIOS (FTTH) > > >>>> =20 > > >> access network > > >> =20 > > >>>> in the US. > > >>>> 3) COPS-PR may be deployed in the FT-Orange IPTV access > > >>>> =20 > > >>> network in UK. > > >>> =20 > > >>>> 4) Comcast uses a mix of COPS and COPS-PR in cable TV video QoS >=20 > > >>>> control. > > >>>> 5) COPS-PR is in DOCSIS 1.0 QoS, which may still be used > > in cable > > >>>> deployments > > >>>> 6) Huawei uses both COPS and COPS-PR in their Quidway RM9000=20 > > >>>> Resource Manager and their Multi-Service Control Gateway > > solution > > >>>> (public documents show COPS, but I have not found > > >>>> =20 > > >> explicit mention > > >> =20 > > >>>> of COPS-PR; I am checking further) > > >>>> 7) ITU-T has a proposal being considered that is based on > COPS-PR > > >>>> > > >>>> Searching the Web I found some additional information that > might=20 > > >>>> bear further research (many items have no associated dates): > > >>>> 8) MultiService Forum has an Implementation Agreement > > for Dynamic > > >>>> Policy Control Using COPS-PR (2005) > > >>>> > > >>>> =20 > > >>=20 > > > http://www.msforum.org/techinfo/approved/MSF-IA-COPS-PR.001-FINAL.pdf > > >> =20 > > >>>> 9) IEEE Xplore has a paper that apparently was presented > > >>>> =20 > > >> at ICT 2008 > > >> =20 > > >>>> comparing the performance of COPS-PR and Netconf. > > >>>> The paper might identify some equipment that has COPS-PR > support. > > >>>> 10) A 2006 paper was published in the Proceedings of the IEEE=20 > > >>>> International Workshop on Policies for Distributed Systems and=20 > > >>>> Networks. The paper considers substituting Netconf and/or > > >>>> =20 > > >> SOAP for > > >> =20 > > >>>> COPS-PR > > >>>> 11) I found discussion of COPS-PR in JUNOSe and the SAE > > >>>> =20 > > >> on the web, > > >> =20 > > >>>> apparently for the SDX line (dated 2008). Was this from > > >>>> =20 > > >> the Juniper > > >> =20 > > >>>> acquisition of netscreen and neoteris? > > >>>> 12) Sejong University apparently has developed a COPS-PR lite > > >>>> > > >>>> =20 > > >> > http://ietcom.oxfordjournals.org/cgi/content/abstract/E90-B/11/3024 > > >> =20 > > >>>> 13) EION has an implementation > > >>>> http://www.eion.com/protocols/protocols_traffic_cops.html > > >>>> 14) Cisco Catalyst has an implementation > > >>>> 15) Wireshark apparently implements it > > >>>> 16) ACSE Networks implements COPS-PR in their NeuTrans product > > >>>> =20 > > >> line > > >> =20 > > >>>> 17) ZNYX Networks implements COPS-PR in the ZX4900 > > >>>> 18) libsmi implemented it > > >>>> 19) Operax AB implemented it > > >>>> 20) MIB Smithy implemented it > > >>>> 21) GridNet has implemented it in its products for managing > > >>>> =20 > > >> utility > > >> =20 > > >>>> (power) grids > > >>>> 22) GE apparently embeds the GridNet implementation in its > WiMax=20 > > >>>> SmartMeter and SmartGrid Router family of products > > >>>> 23) COPS-PR has been the subject of a tremendous number > > >>>> =20 > > >> of academic > > >> =20 > > >>>> papers > > >>>> > > >>>> =20 > > >>> There claims need to be examined carefully. We need to > > >>> =20 > > >> differentiate > > >> =20 > > >>> between academic papers, code implementation and > > deployment. It is > > >>> probably true that a number of open source packages and tools=20 > > >>> implemented COPS-PR after it was put on standards track, but the >=20 > > >>> question is to what extent this code was also used and deployed. > > >>> =20 > > >> Same > > >> =20 > > >>> for the vendors implementations - was COPS-PR deployed > > and how? In > > >>> the absence of standards PIBs I suspect that the majority > > >>> =20 > > >> or all the > > >> =20 > > >>> deployments use one vendor tools and agents, but we need to give >=20 > > >>> enough time for these vendors to step ahead and explain in case=20 > > >>> interoperability is impacted by the proposed standards action. > > >>> > > >>> Dan > > >>> > > >>> =20 > > >> =20 > > > > > > =20 > >=20 > >=20 >=20 >=20 From paduffy@cisco.com Thu Oct 1 10:02:17 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A353A692C for ; Thu, 1 Oct 2009 10:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibrzyww6KAbt for ; Thu, 1 Oct 2009 10:02:16 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 933713A6ABB for ; Thu, 1 Oct 2009 10:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=251; q=dns/txt; s=rtpiport02001; t=1254416622; x=1255626222; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Duffy=20|Reply-To:=20p aduffy@cisco.com|Subject:=20Re:=20[OPSAWG]=20[OPS-AREA] =20Present=20day=20reality=20of=20COPS-PR|Date:=20Thu,=20 01=20Oct=202009=2013:03:40=20-0400|Message-ID:=20<4AC4E0E C.7000503@cisco.com>|To:=20Kwok=20Ho=20Chan=20|CC:=20David=20Harrington=20 ,=20opsawg@ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<0KQU00 EWIBKWFR@usaga04-in.huawei.com>|References:=20<4ABCE564.2 0101@cisco.com>=09<0c0801ca3e2d$e5bf7260$0600a8c0@china.h uawei.com>=09=09=09=09=09=09<037b01ca429e$d908d0a0$0600a8c0@c hina.huawei.com>=20<0KQU00EWIBKWFR@usaga04-in.huawei.com>; bh=sHmFdFC/jWz26flYT1r7T0sE5JDPSFianbygn/jueVs=; b=fUQSc+PsabNuZl0A4Ow9HIp/u21MczG4C4Aqe5Qu2b+/VPdrn5XgniQ8 WN33O2CvaTHuo/fC2SN8aE6QC2oaxt6TdhxwqgcVlo09ERJfowslXlGSJ 6FykPtGnhruGjVdYMCNNyCLFKgjLLxze709eeYD45ktZcvzrt4ljU2uXe I=; Authentication-Results: rtp-iport-2.cisco.com; dkim=pass (signature verified [TEST]) header.i=paduffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYEAN99xEpAZnme/2dsb2JhbACba6NvgRgIAYc6AY9OBoQp X-IronPort-AV: E=Sophos;i="4.44,488,1249257600"; d="scan'208";a="60964285" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Oct 2009 17:03:41 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91H3fM7020226; Thu, 1 Oct 2009 13:03:41 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n91H3fSt011265; Thu, 1 Oct 2009 17:03:41 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 13:03:41 -0400 Received: from [161.44.65.120] ([161.44.65.120]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 13:03:41 -0400 Message-ID: <4AC4E0EC.7000503@cisco.com> Date: Thu, 01 Oct 2009 13:03:40 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kwok Ho Chan References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> <0KQU00EWIBKWFR@usaga04-in.huawei.com> In-Reply-To: <0KQU00EWIBKWFR@usaga04-in.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2009 17:03:41.0140 (UTC) FILETIME=[20473140:01CA42B9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=251; t=1254416621; x=1255280621; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paduffy@cisco.com; z=From:=20Paul=20Duffy=20 |Subject:=20Re=3A=20[OPSAWG]=20[OPS-AREA]=20Present=20day=2 0reality=20of=20COPS-PR |Sender:=20 |To:=20Kwok=20Ho=20Chan=20; bh=sHmFdFC/jWz26flYT1r7T0sE5JDPSFianbygn/jueVs=; b=ZA2QrJs8c19xBnqQPdfjJVcBtjBJrvUGzfi4GeurEEv4qcKpU3FsoQDJSF 8/nb0Oabp25DjGBsTSkGwmbAS3wrlX9tzx8YuEfAuqa98dUG5ftvXnvOpgJb uPtXKfj9o1; Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:02:17 -0000 > > CableLab have their way of using COPS in DOCSIS, which I believe > uses both push and pull models. I don't believe they call it COPS-PR, > but DOCSIS uses some of the COPS-PR features. CableLabs does not use COPS-PR, but they do use COPS. From khchan@huawei.com Thu Oct 1 10:30:58 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7B428C180 for ; Thu, 1 Oct 2009 10:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkqcuzxSM88T for ; Thu, 1 Oct 2009 10:30:56 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 75D9228C0CF for ; Thu, 1 Oct 2009 10:30:56 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KQU00850JDXO3@usaga04-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 12:32:22 -0500 (CDT) Received: from K73911.huawei.com ([10.192.21.57]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0KQU00AB3JDVPH@usaga04-in.huawei.com> for opsawg@ietf.org; Thu, 01 Oct 2009 12:32:21 -0500 (CDT) Date: Thu, 01 Oct 2009 13:32:18 -0400 From: Kwok Ho Chan In-reply-to: <4AC4E0EC.7000503@cisco.com> To: paduffy@cisco.com Message-id: <0KQU00ABAJDWPH@usaga04-in.huawei.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> <0KQU00EWIBKWFR@usaga04-in.huawei.com> <4AC4E0EC.7000503@cisco.com> Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 17:30:58 -0000 Does CableLabs usage of COPS include the usage of the Push Model, the Pull Model, Both? Thanks! -- Kwok -- At 01:03 PM 10/1/2009, Paul Duffy wrote: >>CableLab have their way of using COPS in DOCSIS, which I believe >>uses both push and pull models. I don't believe they call it COPS-PR, >>but DOCSIS uses some of the COPS-PR features. >CableLabs does not use COPS-PR, but they do use COPS. > From paduffy@cisco.com Thu Oct 1 11:05:09 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EF43A68C7 for ; Thu, 1 Oct 2009 11:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.487, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNDFLtYBC3Hv for ; Thu, 1 Oct 2009 11:05:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0A6E33A69AA for ; Thu, 1 Oct 2009 11:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=583; q=dns/txt; s=sjiport01001; t=1254420395; x=1255629995; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Paul=20Duffy=20|Reply-To:=20p aduffy@cisco.com|Subject:=20Re:=20[OPSAWG]=20[OPS-AREA] =20Present=20day=20reality=20of=20COPS-PR|Date:=20Thu,=20 01=20Oct=202009=2014:06:34=20-0400|Message-ID:=20<4AC4EFA A.6030906@cisco.com>|To:=20Kwok=20Ho=20Chan=20|CC:=20David=20Harrington=20 ,=20opsawg@ietf.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<0KQU00 ABAJDWPH@usaga04-in.huawei.com>|References:=20<4ABCE564.2 0101@cisco.com>=20<0c0801ca3e2d$e5bf7260$0600a8c0@china.h uawei.com>=20=20=20=20=20=20<037b01ca429e$d908d0a0$0600a8c0@c hina.huawei.com>=20<0KQU00EWIBKWFR@usaga04-in.huawei.com> =20<4AC4E0EC.7000503@cisco.com>=20<0KQU00ABAJDWPH@usaga04 -in.huawei.com>; bh=TC42m26IA/atLPYcvYbdNg1H2bY9mQLcLrHpxyh88PA=; b=MsDaQzjQatHKhUo5UX1mBDTvisVYRjI/BZDAzxGXHmol9q7vuaqVCATf eTgB12QtcYLggj564NaI/gqQGWuJSB0eQURmlXjr5/vVSK8PgVFmLUyTr wvrBTmT1osIUO+Mp2fG3mLf8yQLJslkT86rE76uIM2k6bZ7QAyKnv1Ems g=; Authentication-Results: sj-iport-1.cisco.com; dkim=pass (signature verified [TEST]) header.i=paduffy@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABuNxEqrR7MV/2dsb2JhbAC/QoEYCAGHOgGPSQaEKQ X-IronPort-AV: E=Sophos;i="4.44,488,1249257600"; d="scan'208";a="249776636" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 01 Oct 2009 18:06:35 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n91I6Y3l015380; Thu, 1 Oct 2009 11:06:34 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n91I6SNL003240; Thu, 1 Oct 2009 18:06:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 14:06:33 -0400 Received: from [161.44.65.120] ([161.44.65.120]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Oct 2009 14:06:33 -0400 Message-ID: <4AC4EFAA.6030906@cisco.com> Date: Thu, 01 Oct 2009 14:06:34 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kwok Ho Chan References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <037b01ca429e$d908d0a0$0600a8c0@china.huawei.com> <0KQU00EWIBKWFR@usaga04-in.huawei.com> <4AC4E0EC.7000503@cisco.com> <0KQU00ABAJDWPH@usaga04-in.huawei.com> In-Reply-To: <0KQU00ABAJDWPH@usaga04-in.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2009 18:06:33.0211 (UTC) FILETIME=[E89B8CB0:01CA42C1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=583; t=1254420394; x=1255284394; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=paduffy@cisco.com; z=From:=20Paul=20Duffy=20 |Subject:=20Re=3A=20[OPSAWG]=20[OPS-AREA]=20Present=20day=2 0reality=20of=20COPS-PR |Sender:=20; bh=TC42m26IA/atLPYcvYbdNg1H2bY9mQLcLrHpxyh88PA=; b=koA0zQX95HfwBRvLeQnqPfpciL1J2YTk7TtryavytH4ySvKk17WxRazJ71 vWFyLBwLco0hpl+LpyCFlXrB9PWFx/1vYToi5AEH6MjOwuQKmyMKh22PUdcu QloHLkpPlCa64ohJW8MJ0SnNY5jraL7LERNd8lRSwcQ30ZezsL2FA=; Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 18:05:10 -0000 I believe its pull See http://www.cablelabs.com/specifications/PKT-SP-DQOS-C01-071129.pdf, section 5 Cheers Kwok Ho Chan wrote: > Does CableLabs usage of COPS include the usage of the Push Model, > the Pull Model, Both? > Thanks! > -- Kwok -- > > At 01:03 PM 10/1/2009, Paul Duffy wrote: > > >>> CableLab have their way of using COPS in DOCSIS, which I believe >>> uses both push and pull models. I don't believe they call it COPS-PR, >>> but DOCSIS uses some of the COPS-PR features. >> CableLabs does not use COPS-PR, but they do use COPS. >> > > From andy@netconfcentral.com Thu Oct 1 11:05:10 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6233A68C7 for ; Thu, 1 Oct 2009 11:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4iPdAe9h9Xw for ; Thu, 1 Oct 2009 11:05:10 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by core3.amsl.com (Postfix) with SMTP id 000F33A69AA for ; Thu, 1 Oct 2009 11:05:09 -0700 (PDT) Received: (qmail 66632 invoked from network); 1 Oct 2009 18:06:33 -0000 Received: from unknown (HELO ?192.168.0.10?) (andy@68.120.81.206 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 1 Oct 2009 18:06:33 -0000 X-YMail-OSG: VuwSRKAVM1m2qx6rNq.DQPE0m0kVVkZ4yxgUR4_20CEBvXb3gyP8XjDHGcrRqD3b7HADo4VphB9hpdOc9524R3sfNwPtdo8hplDBAdqBEe_.lD.VFR_jE0vW6THtt6becx98qFjLVSz8dmamLEkf6V1Kqwi0r9c0B3vfFWRdtgsVmHBB0LYP3NLeKJ6q98lcsBORNrBoN7CRgTzLobJ5hTNnqMcK1r7QVm53HduIhRiX9qsXD42CxzW_jwsXuWPdt6oq_RYBsBGno29vOO2u8A_LDacUQJ9JAVXFb3RumY_tZ.T8lL.6Rbw5KCFz0pwJdA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AC4EFF3.90206@netconfcentral.com> Date: Thu, 01 Oct 2009 11:07:47 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4ABCE564.20101@cisco.com> <0c0801ca3e2d$e5bf7260$0600a8c0@china.huawei.com> <027001ca41c8$a74b8750$0600a8c0@china.huawei.com> <4AC363B0.4050909@cisco.com> <029e01ca41eb$c39bd450$0600a8c0@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 18:05:10 -0000 Romascanu, Dan (Dan) wrote: > One aspect of this discussion is surprising me a little :-) > > For the record, since I am an AD (March 2006) I have never received a > request for chartering a new PIB work in the IETF. Neither have I > received any legacy instructions from my predecessor Bert Wijnen about > new COPS-PR or PIB being a taboo. I think that I know his position, but > this is not necessarily the same as mine. If I ever had received such a > request I would have considered it without prejudice. It's still true > even now. Probably everybody knows by now that I am not a 'one protocol > fits all' adept. > There doesn't seem to be complete consensus to move this RFC to historic. I don't really care, but COPS-PR seems to be in use in places, so we should just go back to ignoring it in the IETF, and not changing the standards track status at all. > Dan Andy From sumanth@cablelabs.com Thu Oct 1 12:28:36 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5160728C1D4 for ; Thu, 1 Oct 2009 12:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUcHppzSnP8A for ; Thu, 1 Oct 2009 12:28:35 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 612FC28C1CE for ; Thu, 1 Oct 2009 12:28:35 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.3/8.14.3) with SMTP id n91JTcjq029261; Thu, 1 Oct 2009 13:29:38 -0600 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Thu, 1 Oct 2009 13:29:38 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) Received: from 10.4.0.46 ([10.4.0.46]) by srvxchg3.cablelabs.com ([10.5.0.25]) with Microsoft Exchange Server HTTP-DAV ; Thu, 1 Oct 2009 19:29:38 +0000 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Thu, 01 Oct 2009 13:29:37 -0600 From: Sumanth Channabasappa To: , Kwok Ho Chan Message-ID: Thread-Topic: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR Thread-Index: AcpCzYMtbAO7A4kXwUGHLSk4l6rg1g== In-Reply-To: <4AC4EFAA.6030906@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Approved: ondar Cc: opsawg@ietf.org, Karthik Sundaresan Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 19:28:36 -0000 A few clarifications regarding the usage of COPS within CableLabs specifications (thanks to Karthik Sundaresan, cc-ed). CableLabs does not reference COPS within the DOCSIS specification suite. Instead it utilizes COPS within two different PacketCable specification efforts: - PacketCable 1.5 Dynamic Quality of Service (DQoS); and, - PacketCable Multimedia. Within these specifications COPS is used in conjunction with DOCSIS to provide Quality of Service to PacketCable components. Both the specifications mentioned above specify the use of COPS messages, and normatively reference COPS and COPS-PR. The COPS objects used are according to COPS. In addition the PCMM specification also aligns with COPS-PR. To clarify the usage: = PacketCable 1.5 DQoS uses a hybrid push-pull model. = PacketCable Multimedia uses the Push model. References: http://www.cablelabs.com/specifications/PKT-SP-DQOS1.5-I04-090624.pdf http://www.cablelabs.com/specifications/PKT-SP-MM-I04-080522.pdf - S On 10/1/09 12:06 PM, "Paul Duffy" wrote: > I believe its pull > > See > http://www.cablelabs.com/specifications/PKT-SP-DQOS-C01-071129.pdf, > section 5 > > Cheers > > > Kwok Ho Chan wrote: >> Does CableLabs usage of COPS include the usage of the Push Model, >> the Pull Model, Both? >> Thanks! >> -- Kwok -- >> >> At 01:03 PM 10/1/2009, Paul Duffy wrote: >> >> >>>> CableLab have their way of using COPS in DOCSIS, which I believe >>>> uses both push and pull models. I don't believe they call it COPS-PR, >>>> but DOCSIS uses some of the COPS-PR features. >>> CableLabs does not use COPS-PR, but they do use COPS. >>> >> >> > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From dromasca@avaya.com Fri Oct 2 03:31:01 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F0728B23E; Fri, 2 Oct 2009 03:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khkkMGcGyhqb; Fri, 2 Oct 2009 03:31:00 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 7316428C0D8; Fri, 2 Oct 2009 03:30:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,493,1249272000"; d="scan'208";a="158655251" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 02 Oct 2009 06:32:23 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 02 Oct 2009 06:32:22 -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: Fri, 2 Oct 2009 12:32:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for WebEx at IETF 76 thread-index: AcpC62cK+Vp4d9meScWEUESp+2mT7QAXlQ/Q From: "Romascanu, Dan (Dan)" To: , "OPS Area (E-mail)" , "radext mailing list" , , , , "IETF IPFIX Working Group" Subject: [OPSAWG] FW: Need for WebEx at IETF 76 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 10:31:01 -0000 =20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Alexa Morris Sent: Friday, October 02, 2009 1:03 AM To: The IESG Subject: Need for WebEx at IETF 76 I'd like to know if any of you might need to use WebEx for any working group sessions taking place at IETF 76. Please note that at present I'm looking more for a "I need WebEx because one of my key presenters will not be physically present"=20 From banshimin@h3c.com Fri Oct 2 06:11:40 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C0828C0D9 for ; Fri, 2 Oct 2009 06:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWrEQ6-98wHI for ; Fri, 2 Oct 2009 06:11:40 -0700 (PDT) Received: from huawei-3com.com (unknown [60.191.123.50]) by core3.amsl.com (Postfix) with ESMTP id 119DD28B797 for ; Fri, 2 Oct 2009 06:11:38 -0700 (PDT) Received: from huawei-3com.com (localhost [127.0.0.1]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KQW00J1921TZR@h3cml01-in.huawei-3com.com> for opsawg@ietf.org; Fri, 02 Oct 2009 21:13:05 +0800 (CST) Received: from huawei-3com.com ([172.25.15.135]) by h3cml01-in.huawei-3com.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0KQW00FJG21TNW@h3cml01-in.huawei-3com.com> for opsawg@ietf.org; Fri, 02 Oct 2009 21:13:05 +0800 (CST) Received: from [172.25.15.126] (Forwarded-For: [222.128.148.18]) by h3cmc02-in.huawei-3com.com (mshttpd); Fri, 02 Oct 2009 21:13:05 +0800 Date: Fri, 02 Oct 2009 21:13:05 +0800 From: banshimin 01376 To: opsawg@ietf.org Message-id: <62f2c62622.6262262f2c@huawei-3com.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: Re: [OPSAWG] New Version Notification for draft-shimin-opsawg-snmp-backuprestore-mib-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 13:11:41 -0000 Hi all, I have posted a draft as below. Your suggestion is welcomed. Thanks in advance! http://tools.ietf.org/html/draft-shimin-opsawg-snmp-backuprestore-mib-00 A new version of I-D, draft-shimin-opsawg-snmp-backuprestore-mib-00.txt has been successfuly submitted by Ban Shimin and posted to the IETF repository. Filename: draft-shimin-opsawg-snmp-backuprestore-mib Revision: 00 Title: Backup and Restore MIBs Creation_date: 2009-10-02 WG ID: Independent Submission Number_of_pages: 53 Abstract: This memo defines a portion of the Management Information Base (MIB) for transferring files between a device and servers and managing the system files, specially image and configuration files. In particular, the managed objects can be used for configuration backup/restore and agent upgrade. Currently, there are several enterprise-specific MIBs for tranfering or managing files. The purpose of this memo is to define a standards-based solution to enable interoperability. Best regards. Ban From tena@huawei.com Tue Oct 6 05:36:31 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAF7C28C183 for ; Tue, 6 Oct 2009 05:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.485 X-Spam-Level: X-Spam-Status: No, score=-92.485 tagged_above=-999 required=5 tests=[AWL=5.409, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbkw2-bEWLVW for ; Tue, 6 Oct 2009 05:36:31 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id AC1143A68D2 for ; Tue, 6 Oct 2009 05:36:30 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR3002N4F392A@szxga02-in.huawei.com> for opsawg@ietf.org; Tue, 06 Oct 2009 20:37:57 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KR300GHNF38J7@szxga02-in.huawei.com> for opsawg@ietf.org; Tue, 06 Oct 2009 20:37:57 +0800 (CST) Received: from [192.168.5.102] (70.73.35.121.broad.sz.gd.dynamic.163data.com.cn [121.35.73.70]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KR30008CF37GQ@szxml02-in.huawei.com>; Tue, 06 Oct 2009 20:37:56 +0800 (CST) Date: Tue, 06 Oct 2009 20:37:54 +0800 From: Tina TSOU In-reply-to: To: Sumanth Channabasappa , Karthik Sundaresan , opsawg@ietf.org, paduffy@cisco.com, Kwok Ho Chan Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: multipart/alternative; boundary="Boundary_(ID_E5oYjdrBMSE1nhG8uFiDEQ)" References: Cc: Tom Taylor Subject: Re: [OPSAWG] [OPS-AREA] Present day reality of COPS-PR X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 12:36:32 -0000 --Boundary_(ID_E5oYjdrBMSE1nhG8uFiDEQ) Content-type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable Hi, ITU-T COPS-PR PIB is in ITU-T Q.3303.1. Tom was the editor. I was the rapporteur, and am the working party =20 vice chair and rapporteur. The link is below. http://www.itu.int/ITU-T/recommendations/index_sg.aspx?sg=3D11 Q.3303.1 (08/2007) Q SERIES: SWITCHING AND SIGNALLING Signalling requirements and protocols for the NGN - Resource control =20 protocols Title:=09 Resource control protocol No. 3 =96 Protocol at the interface between a =20= Policy Decision Physical Entity (PD-PE) and a Policy Enforcement =20 Physical Entity (PE-PE): COPS alternative Provisional name: Q.rcp3.1 Approval date: 2007-08-06 Status: In force Maintenance responsibility: ITU-T study group 11 B. R. Tina http://tinatsou.weebly.com/contact.html --Boundary_(ID_E5oYjdrBMSE1nhG8uFiDEQ) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: quoted-printable
Hi,
ITU-T = COPS-PR PIB is in ITU-T Q.3303.1. 
Tom was the editor. I = was the rapporteur, and am the working party vice chair and = rapporteur.
The link is below.





= --Boundary_(ID_E5oYjdrBMSE1nhG8uFiDEQ)-- From leo.vegoda@icann.org Tue Oct 6 05:51:18 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09EB93A69BF for ; Tue, 6 Oct 2009 05:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.176 X-Spam-Level: X-Spam-Status: No, score=-5.176 tagged_above=-999 required=5 tests=[AWL=-0.991, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD5kgUFpk948 for ; Tue, 6 Oct 2009 05:51:17 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id B0CFF3A696C for ; Tue, 6 Oct 2009 05:51:16 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 6 Oct 2009 05:52:54 -0700 From: Leo Vegoda To: "opsawg@ietf.org" Date: Tue, 6 Oct 2009 05:52:52 -0700 Thread-Topic: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document Thread-Index: Aco9NFP6aW6MbOMCskmkVsE4NZskywJT5ZgZ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2009 12:51:18 -0000 Hi, There hasn't been much discussion about whether this draft should be accepted as a WG item. Do people support it being adopted as a WG item? If so - or if not - I would be grateful if you could publicly state your support or the reason you object. Thanks, Leo On 24/09/2009 9:30, "Leo Vegoda" wrote: > Dear OPSAREA WG, >>=20 > Leo Vegoda and I wrote this draft in response to an increasing rate of > questions about the possibility of creating new private IPv4 address spa= ce. > We would like to have it adopted as a WG document. >>=20 > Abstract >=20 > When a private network or internetwork grows very large it is > sometimes not possible to address it using private IPv4 address > space. This document describes the problems faced by those networks= , > the available options and the issues involved in assigning a new > block of private IPv4 address space. >=20 > http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-is= sues- > 01 >=20 > Many thanks, >=20 > Marla Azinger & > Leo Vegoda >=20 From patara@lacnic.net Wed Oct 7 11:00:27 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6143128C1BB for ; Wed, 7 Oct 2009 11:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnA6F7FimJpO for ; Wed, 7 Oct 2009 11:00:26 -0700 (PDT) Received: from mail.lacnic.net (mail.lacnic.net [IPv6:2001:13c7:7002:4000::11]) by core3.amsl.com (Postfix) with ESMTP id 3656428C195 for ; Wed, 7 Oct 2009 11:00:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.lacnic.net (Postfix) with ESMTP id 83318BC88; Wed, 7 Oct 2009 15:02:05 -0300 (BRT) X-Virus-Scanned: amavisd-new at lacnic.net Received: from mail.lacnic.net ([127.0.0.1]) by localhost (mail.lacnic.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amsNp07OUQuy; Wed, 7 Oct 2009 15:02:02 -0300 (BRT) Received: from [IPv6:::1] (mail.lacnic.net [IPv6:2001:13c7:7002:4000::11]) by mail.lacnic.net (Postfix) with ESMTP id B444FBC84; Wed, 7 Oct 2009 15:02:02 -0300 (BRT) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Ricardo Patara In-Reply-To: Date: Wed, 7 Oct 2009 15:02:02 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <598F4EB4-1466-4128-B3D4-DDFCB79FD1A6@lacnic.net> References: To: opsawg@ietf.org X-Mailer: Apple Mail (2.1076) Subject: Re: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 18:00:27 -0000 Hi Leo, how are you? Speaking for myself here. I read the document and it states that there is a problem with large =20 networks that use private address from RFC1918. Then, it points to =20 Available option on the chapter 4. Each of those options have its =20 drawback (some of then not related with each other). Then, it has separate chapter: 5. Options and Consequences for Defining New Private Use Space Giving the idea to the reader that this is the best way to solve the =20 problem. Am I right on reading it this way? Was it the idea of the authors? If so, I am personally against this document. It is stated that big networks might need this kind of solution. The =20 way I see, big networks that has Internet as main business are already =20= thinking/planing a long term solution. There are a couple of cases of big networks deeply involved with IPv6 =20= and mid term solution for some problems stated on the document. best regards Ricardo Patara -- Em 06/10/2009, =E0s 09:52, Leo Vegoda escreveu: > Hi, > > There hasn't been much discussion about whether this draft should be > accepted as a WG item. Do people support it being adopted as a WG =20 > item? If > so - or if not - I would be grateful if you could publicly state your > support or the reason you object. > > Thanks, > > Leo > > On 24/09/2009 9:30, "Leo Vegoda" wrote: > >> Dear OPSAREA WG, >>> >> Leo Vegoda and I wrote this draft in response to an increasing =20 >> rate of >> questions about the possibility of creating new private IPv4 =20 >> address space. >> We would like to have it adopted as a WG document. >>> >> Abstract >> >> When a private network or internetwork grows very large it is >> sometimes not possible to address it using private IPv4 address >> space. This document describes the problems faced by those =20 >> networks, >> the available options and the issues involved in assigning a new >> block of private IPv4 address space. >> >> = http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-space-iss= ues- >> 01 >> >> Many thanks, >> >> Marla Azinger & >> Leo Vegoda >> > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From ietfdbh@comcast.net Wed Oct 7 12:09:35 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6763A6950 for ; Wed, 7 Oct 2009 12:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.553, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w63FVBhUkmJZ for ; Wed, 7 Oct 2009 12:09:34 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 0C4AB3A672F for ; Wed, 7 Oct 2009 12:09:33 -0700 (PDT) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id pn9B1c0030SCNGk5BvBF9A; Wed, 07 Oct 2009 19:11:15 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA09.westchester.pa.mail.comcast.net with comcast id pvBE1c00L284sdk3VvBFt2; Wed, 07 Oct 2009 19:11:15 +0000 From: "David Harrington" To: References: <20091007133003.3732A3A68E9@core3.amsl.com> Date: Wed, 7 Oct 2009 15:11:13 -0400 Message-ID: <00b701ca4781$f0435be0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpHUoeE4OwyDN96TkaynzO0AQxySAAKbU0A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20091007133003.3732A3A68E9@core3.amsl.com> Subject: Re: [OPSAWG] I-D Action:draft-mizrahi-opsawg-oam-overview-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 19:09:35 -0000 Hi, Interesting that none of the IETF standards developed in the Operations and Management Area have even been mentioned in this document. I would think that, at least, a discussion of why they are not included would be called for in an OPSAWG document. Don't mistake my intent here. I think a document that describes OAM from the perspectives of other SDOs - and other areas in the IETF - could be very helpful to people in the IETF, especially those working in the OPS area. But the selection of IETF OAM technologies presented are not the primary IETF style for Internet Operations and Management, so this document seems misleading when it claims: This document presents an overview of the OAM mechanisms that have been defined and are currently being defined by the IETF, as well as a comparison to other OAM mechanisms that have been defined by the IEEE and ITU-T. I think that, at a minimum, RFC1052 "IAB recommendations for the development of Internet network management standards" which documents the basis for the SNMP/MIB approach, and RFC3410 "Introduction and Applicability Statements for Internet-Standard Management Framework" which documents the Internet Standard Management Framework, and RFC3535 "Overview of the 2002 IAB Network Management Workshop" which documents the basis for standardized configuration, in the style of netconf, deserve to be mentioned. And these three don't include discussion of AAA, flow monitoring, system logging, etc., all of which are important to IETF-style operations and management. I repeat my opinion - a discussion of why none of these are included is called for in an OPSAWG document. (and I do not find the informative reference to the oam-defs document that asserts "OAM and management are different" to be sufficient.) At a minimum, if the defs document is going to redefine how the IETF approaches O&M, then the defs document needs much more work and it needs to be a normative, not an informative, reference in this document. dbh > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, October 07, 2009 9:30 AM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-mizrahi-opsawg-oam-overview-00.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : An Overview of Operations, > Administration, and Maintenance (OAM) Mechanisms > Author(s) : T. Mizrahi > Filename : draft-mizrahi-opsawg-oam-overview-00.txt > Pages : 22 > Date : 2009-10-07 > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to detecting and reporting link failures. OAM mechanisms > have been defined for various layers in the protocol stack, and are > used with a variety of protocols. > > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF, as well as > a comparison to other OAM mechanisms that have been defined by the > IEEE and ITU-T. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mizrahi-opsawg-oam-o > verview-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 reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From leo.vegoda@icann.org Wed Oct 7 14:38:04 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5953A69A5 for ; Wed, 7 Oct 2009 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.567 X-Spam-Level: X-Spam-Status: No, score=-5.567 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RcdFeZwt0ry for ; Wed, 7 Oct 2009 14:38:03 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 86A7D3A686B for ; Wed, 7 Oct 2009 14:38:03 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 7 Oct 2009 14:39:44 -0700 From: Leo Vegoda To: Ricardo Patara , "opsawg@ietf.org" Date: Wed, 7 Oct 2009 14:39:40 -0700 Thread-Topic: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document Thread-Index: AcpHeFRRocYt1FKLR3uymAINcuAArQAHlhIX Message-ID: In-Reply-To: <598F4EB4-1466-4128-B3D4-DDFCB79FD1A6@lacnic.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 21:38:04 -0000 Hi Ricardo, On 07/10/2009 11:02, "Ricardo Patara" wrote: [...] > Then, it has separate chapter: > 5. Options and Consequences for Defining New Private Use Space >=20 > Giving the idea to the reader that this is the best way to solve the > problem. > Am I right on reading it this way? Was it the idea of the authors? No, we did not intend to present the options described in section 5 as preferred outcomes. We just wanted to describe the pros and cons for each o= f those options. Was there specific language that implied we supported these options, or was it something else that gave you that impression? Many thanks, Leo From brian.e.carpenter@gmail.com Wed Oct 7 15:05:20 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9153A68DB for ; Wed, 7 Oct 2009 15:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8n0AZdIBqN4 for ; Wed, 7 Oct 2009 15:05:19 -0700 (PDT) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 482BC3A69B4 for ; Wed, 7 Oct 2009 15:05:19 -0700 (PDT) Received: by pzk6 with SMTP id 6so32965pzk.29 for ; Wed, 07 Oct 2009 15:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=V/+q0adWPLqD9J5EH3EJ8BkmlAzZbS3WvpwUfL9bDD4=; b=jTEQM1U78CaHntkAExJNYNjOX//WS1G87ti2Hza7f+8HBTcffgyMYEjJtSTh8nCWIS jPF2DzRrdo9kqWp/DVVg0NOe6t9Ve1Mk0Osk+9JyYdq+thhPam2HnWEtRV2qSN4dfVKe bYKZhLFvmDkKUkpF8+mJhys2K9WWjwsduc0bQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=kMAu/iczPo4sRy0AcmK246FskTCmEEjT/vWi+4fiwAV2HpjyRDxlUv+oxjTJJCdD/P 4xj2H0TRTSzaZcmuLdl5mz6VJisM3gXtfQ0O82V6a1qkHLNWGB48o4p76iHy2gdvl0+v IPJyQh9jz8lfB/agtrHnKfFy7cKqC6sjzTpXE= Received: by 10.114.162.4 with SMTP id k4mr726831wae.149.1254953216653; Wed, 07 Oct 2009 15:06:56 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm381884pxi.2.2009.10.07.15.06.54 (version=SSLv3 cipher=RC4-MD5); Wed, 07 Oct 2009 15:06:56 -0700 (PDT) Message-ID: <4ACD10FD.3030108@gmail.com> Date: Thu, 08 Oct 2009 11:06:53 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Leo Vegoda References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2009 22:05:20 -0000 Leo, I certainly didn't read it as Ricardo did, perhaps because of my strong belief that expanding "private" space would be a blunder of historic proportions. But if even one person can read it that way, the language clearly needs to be clarified. That said, I think this is a useful document and should help to prevent the blunder being made, so I'd like to see it adopted. Regards Brian On 2009-10-08 10:39, Leo Vegoda wrote: > Hi Ricardo, > > On 07/10/2009 11:02, "Ricardo Patara" wrote: > > [...] > >> Then, it has separate chapter: >> 5. Options and Consequences for Defining New Private Use Space >> >> Giving the idea to the reader that this is the best way to solve the >> problem. >> Am I right on reading it this way? Was it the idea of the authors? > > No, we did not intend to present the options described in section 5 as > preferred outcomes. We just wanted to describe the pros and cons for each of > those options. Was there specific language that implied we supported these > options, or was it something else that gave you that impression? > > Many thanks, > > Leo > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From ford@isoc.org Thu Oct 8 02:55:57 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DD23A6A69 for ; Thu, 8 Oct 2009 02:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.479 X-Spam-Level: X-Spam-Status: No, score=-103.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib7YRvDreKh2 for ; Thu, 8 Oct 2009 02:55:55 -0700 (PDT) Received: from smtp148.iad.emailsrvr.com (smtp148.iad.emailsrvr.com [207.97.245.148]) by core3.amsl.com (Postfix) with ESMTP id CF6B43A6A5D for ; Thu, 8 Oct 2009 02:55:54 -0700 (PDT) Received: from relay24.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay24.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 32A311B403E; Thu, 8 Oct 2009 05:57:36 -0400 (EDT) Received: by relay24.relay.iad.mlsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id 761E21B4010; Thu, 8 Oct 2009 05:57:35 -0400 (EDT) Message-ID: <4ACDB78D.2030501@isoc.org> Date: Thu, 08 Oct 2009 10:57:33 +0100 From: Matthew Ford User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Leo Vegoda References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" , "marla.azinger@frontiercorp.com" Subject: Re: [OPSAWG] [Int-area] draft-azinger-additional-private-ipv4-space-issues (OPSAREA WG) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 09:55:57 -0000 Hi Leo, On 30/09/2009 19:28, Leo Vegoda wrote: > On 25/09/2009 6:45, "Matthew Ford" wrote: >> Section 3 - Where are these residential and corporate networks where >> 'peer to peer communication is not needed'? > > It is not uncommon for some network operators to restrict the use of > peer-to-peer technologies either within their own network or across its > borders. In enterprises this is sometimes part of a security policy. For > instance some financial companies are required to record all incoming and > outgoing voice calls and so disallow peer-to-peer VoIP services. > > In ISP networks there is sometimes a policy or technology that restricts > peer-to-peer technologies, whether for revenue protection reasons or > otherwise, forcing most IP traffic via proxies and caches. One example of > this is the image compression used by many cellular data networks. Understood. So I think this text should be clarified, perhaps as follows: Replace 'For instance, it is often technically feasible to use NAT or even multiple layers of NAT within the networks operated by residential users or corporations where peer to peer communication is not needed.' with 'For instance, it is often technically feasible to use NAT or even multiple layers of NAT within networks where peer-to-peer technologies are prohibited by fiat and where users cannot expect to use any unsupported services or applications.' >> Section 5.2 - I'm struggling to understand why it's 'likely' that there >> will be networks consuming whole /8s in 12 month periods for private >> addressing purposes. If there were networks with that much need for >> private addressing, we'd have been hearing complaints about how net10 is >> too small way before now, right? > > We have both spoken to network operators who know that they have a need for > very large amounts of address space over short time frames but are sitting > on the requests for as long as possible. That being said, it is not unknown > for networks to be allocated whole /8s in one go. For instance, APNIC > allocated 126.0.0.0/8 to Softbank. That was nearly five years ago. Have Softbank asked for more since? The text currently says it is 'likely' that there will be networks consuming whole /8s for private addressing in a 12 month period. I'd replace 'It is possible and even likely that a single network could consume a whole IPv4 /8 in a year. ' with 'Very large networks could consume multiple IPv4 /8s over time.' > Another example of a statement of need is the recent (now abandoned) APNIC > policy proposal (prop-058-v001) "Proposal to create IPv4 shared use address > space among LIRs". > >> This wording in section 4.1 on solving the problem with IPv6 is rather coy: >> "In some cases implementing a new network protocol on a very large >> network takes more time than is available, based on network growth and >> the proportion of private space that has already been used. In these >> cases, there is a call for additional private address space that can be >> shared by all network operators." >> >> Let's be clear about this: >> >> 'Some network operators are complaining today that they do not have time >> to implement IPv6 on their network before they run out of private space. >> These operators are calling for additional private address space to be >> made available...' > > We could change the wording to something more direct but I would personally > prefer not to use the word "complaining" as I don't think I have heard any > complaints, just proposals and concerns. That's fair. How about 'Some network operators are concerned that they do not have sufficient time to implement IPv6 on their network before they run out of private space. These operators are calling for additional private address space to be made available...' Mat From marla.azinger@frontiercorp.com Mon Oct 12 09:57:02 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60B028C28B for ; Mon, 12 Oct 2009 09:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHl07TU0Hioc for ; Mon, 12 Oct 2009 09:57:01 -0700 (PDT) Received: from frontiercorp.com (mail04.frontiercorp.com [66.133.172.21]) by core3.amsl.com (Postfix) with ESMTP id 925803A63C9 for ; Mon, 12 Oct 2009 09:57:01 -0700 (PDT) Received: from ([10.160.69.53]) by mail04.frontiercorp.com with ESMTP with TLS id 4440448.46592693; Mon, 12 Oct 2009 12:56:36 -0400 Received: from ROCH-EXCH1.corp.pvt ([10.160.69.50]) by nyrofcs03exht02 ([10.160.69.53]) with mapi; Mon, 12 Oct 2009 12:56:15 -0400 From: "Azinger, Marla" To: Leo Vegoda , "roque@lacnic.net" , "opsawg@ietf.org" Date: Mon, 12 Oct 2009 12:56:34 -0400 Thread-Topic: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document Thread-Index: Aco9cmzW9DD5t8xkSRGMEYn0MpAQiQN6WQ0w Message-ID: <2E2FECEBAE57CC4BAACDE67638305F104851559911@ROCH-EXCH1.corp.pvt> References: <46D99521-F178-4109-ADF8-9725B9EB1C1D@lacnic.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2E2FECEBAE57CC4BAACDE67638305F104851559911ROCHEXCH1corp_" MIME-Version: 1.0 X-esp: ESP<13>= SHA:<0> SHA_FLAGS:<0> UHA:<13> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<0> SIG:<> DSC:<0> TRU_scam_spam: <0> TRU_urllinks: <0> TRU_phish_spam: <0> TRU_spam2: <0> TRU_embedded_image_spam: <0> TRU_profanity_spam: <0> TRU_legal_spam: <0> TRU_stock_spam: <0> TRU_watch_spam: <0> TRU_money_spam: <0> TRU_ru_spamsubj: <0> TRU_marketing_spam: <0> TRU_playsites: <0> TRU_spam1: <0> TRU_lotto_spam: <0> TRU_medical_spam: <0> TRU_html_image_spam: <0> TRU_freehosting: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> URL Real-Time Signatures: <0> Subject: Re: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv4-space-issues as a WG document X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2009 16:57:03 -0000 --_000_2E2FECEBAE57CC4BAACDE67638305F104851559911ROCHEXCH1corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roque The OPSAWG description of work includes items that do not necessarily fall = into any particular group and/or include documents of a BCP that will provi= de guidance for authors and reference for reviewers. In addition Int Area = is not a WG and its documents are only AD sponsored submissions. We believe that this document covers an unwritten BCP that should be mainta= ined and the details surrounding that BCP. In the recent past such a docum= ent has been requested due to an increase in interest of the subject matter= however no such document exists. We wish to fill in this gap. Thank you Marla Azinger From: Roque Gagliano > Date: September 24, 2009 4:30:55 PM PDT To: Leo Vegoda > Cc: "opsawg@ietf.org" > Subject: Re: [OPSAWG] Request to adopt draft-azinger-additional-private-ipv= 4-space-issues as a WG document Leo, The issue of NAT44 and additional private or "inter ISP" address space has = been discussed in several IETF meeting at the INT AREA WG. Why would this i= ssue be hosted in the OPS area instead of the INT area? Regards, Roque. On Sep 24, 2009, at 1:30 PM, Leo Vegoda wrote: Dear OPSAREA WG, Leo Vegoda and I wrote this draft in response to an increasing rate of que= stions about the possibility of creating new private IPv4 address space. W= e would like to have it adopted as a WG document. Abstract When a private network or internetwork grows very large it is sometimes not possible to address it using private IPv4 address space. This document describes the problems faced by those networks, the available options and the issues involved in assigning a new block of private IPv4 address space. http://tools.ietf.org/html/draft-azinger-additional-private-ipv4-spa= ce-issues-01 Many thanks, Marla Azinger & Leo Vegoda _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/= listinfo/opsawg ------------------------------------------------------------- Roque Gagliano LACNIC roque@lacnic.net GPG Fingerprint: E929 06F4 D8CD 2AD8 9365 DB72 9E4F 964A 01E9 6CEE --_000_2E2FECEBAE57CC4BAACDE67638305F104851559911ROCHEXCH1corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Roque
 
The OP= SAWG=20 description of work includes items that do not necessarily fall into any=20 particular group and/or include documents of a BCP that will provide guidan= ce=20 for authors and reference for reviewers.  In addition Int Area is not a WG and its documen= ts are=20 only AD sponsored submissions.

We believe that this document covers an unwritten BCP that = should=20 be maintained and the details surrounding that BCP.  In the recent pas= t=20 such a document has been requested due to an increase in interest of the su= bject=20 matter however no such document exists.  We wish to fill in this=20 gap.
 
 
Th= ank=20 you
Ma= rla=20 Azinger


From: Roque Gagliano <roque@lacnic.net>
Date:= =20 September 24, 2009 4:30:55 PM PDT
To: Leo Vegoda <leo.vegoda@icann.org>
C= c:=20 "opsawg@ietf.org" <opsawg@ietf.org>
Subject:=20 Re: [OPSAWG] Request to adopt=20 draft-azinger-additional-private-ipv4-space-issues as a WG=20 document

Leo,

The issue of NAT44 and additional private or "inter ISP" addres= s=20 space has been discussed in several IETF meeting at the INT AREA WG. Why = would=20 this issue be hosted in the OPS area instead of the INT area?

Regards,

Roque.


On Sep 24, 2009, at 1:30 PM, Leo Vegoda wrote:
Dear= OPSAREA=20 WG,

Leo Vegoda and = I wrote=20 this draft in  response to an increasing rate of questions about t= he=20 possibility of creating  new private IPv4 address space. We would = like=20 to have it adopted as a WG  document.

Abstract

   When a priv= ate=20 network or  internetwork grows very large it=20 is
   sometimes not  possible to address it usin= g=20 private IPv4 address
   space.   This docum= ent=20 describes the problems faced by those=20  networks,
   the available options and the issu= es=20 involved  in assigning a new
   block of private= IPv4=20 address  space.

http://tools.ietf.org/html/draft-azinger-additional-priv= ate-ipv4-space-issues-01

Many=20  thanks,

Marla Azinger &
Leo=20 Vegoda
_________________________________________= ______
OPSAWG=20 mailing list
OPSAWG@ietf.org
https://www.ietf.= org/mailman/listinfo/opsawg

-----------------------------------------------------= --------
Roque Gagliano
LACNIC
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9= =20 6CEE

--_000_2E2FECEBAE57CC4BAACDE67638305F104851559911ROCHEXCH1corp_-- From dromasca@avaya.com Wed Oct 14 04:04:09 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D4423A692B for ; Wed, 14 Oct 2009 04:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIVgDnGkXqff for ; Wed, 14 Oct 2009 04:04:08 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 11D1B3A683C for ; Wed, 14 Oct 2009 04:04:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,557,1249272000"; d="scan'208";a="186887709" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 14 Oct 2009 07:03:59 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Oct 2009 07:03:59 -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, 14 Oct 2009 13:03:38 +0200 Message-ID: In-Reply-To: <00b701ca4781$f0435be0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] I-D Action:draft-mizrahi-opsawg-oam-overview-00.txt thread-index: AcpHUoeE4OwyDN96TkaynzO0AQxySAAKbU0AAVBRiYA= References: <20091007133003.3732A3A68E9@core3.amsl.com> <00b701ca4781$f0435be0$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , Subject: Re: [OPSAWG] I-D Action:draft-mizrahi-opsawg-oam-overview-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 11:04:09 -0000 I am even more surprised by the non-inclusion of the MPLS OAM work which was developped in the Routing Area - RFC 3429, RFC 4377, RFC 4388, RFC 4687, as well as of the more recent OAM work for MPLS-TP.=20 Maybe this is just a temporary omission and these will be added later. May I ask the author what are his plans and proposals related to this document?=20 Thanks and Regards, Dan > -----Original Message----- > From: opsawg-bounces@ietf.org=20 > [mailto:opsawg-bounces@ietf.org] On Behalf Of David Harrington > Sent: Wednesday, October 07, 2009 9:11 PM > To: opsawg@ietf.org > Subject: Re: [OPSAWG] I-D=20 > Action:draft-mizrahi-opsawg-oam-overview-00.txt >=20 > Hi, >=20 > Interesting that none of the IETF standards developed in the=20 > Operations and Management Area have even been mentioned in=20 > this document. I would think that, at least, a discussion of=20 > why they are not included would be called for in an OPSAWG document. >=20 > Don't mistake my intent here. I think a document that=20 > describes OAM from the perspectives of other SDOs - and other=20 > areas in the IETF - could be very helpful to people in the=20 > IETF, especially those working in the OPS area.=20 >=20 > But the selection of IETF OAM technologies presented are not=20 > the primary IETF style for Internet Operations and=20 > Management, so this document seems misleading when it claims: >=20 > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF,=20 > as well as > a comparison to other OAM mechanisms that have been defined by the > IEEE and ITU-T. >=20 > I think that, at a minimum, RFC1052 "IAB recommendations for=20 > the development of Internet network management standards"=20 > which documents the basis for the SNMP/MIB approach, and=20 > RFC3410 "Introduction and Applicability Statements for=20 > Internet-Standard Management Framework" > which documents the Internet Standard Management Framework, and > RFC3535 "Overview of the 2002 IAB Network Management=20 > Workshop" which documents the basis for standardized=20 > configuration, in the style of netconf, deserve to be mentioned. >=20 > And these three don't include discussion of AAA, flow=20 > monitoring, system logging, etc., all of which are important=20 > to IETF-style operations and management. >=20 > I repeat my opinion - a discussion of why none of these are=20 > included is called for in an OPSAWG document. (and I do not=20 > find the informative reference to the oam-defs document that=20 > asserts "OAM and management are different" to be sufficient.)=20 > At a minimum, if the defs document is going to redefine how=20 > the IETF approaches O&M, then the defs document needs much=20 > more work and it needs to be a normative, not an informative,=20 > reference in this document. >=20 > dbh=20 >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > > Internet-Drafts@ietf.org > > Sent: Wednesday, October 07, 2009 9:30 AM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-mizrahi-opsawg-oam-overview-00.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > > Title : An Overview of Operations,=20 > > Administration, and Maintenance (OAM) Mechanisms > > Author(s) : T. Mizrahi > > Filename : draft-mizrahi-opsawg-oam-overview-00.txt > > Pages : 22 > > Date : 2009-10-07 > >=20 > > Operations, Administration, and Maintenance (OAM) is a general term=20 > > that refers to detecting and reporting link failures. OAM=20 > mechanisms=20 > > have been defined for various layers in the protocol stack, and are=20 > > used with a variety of protocols. > >=20 > > This document presents an overview of the OAM mechanisms that have=20 > > been defined and are currently being defined by the IETF,=20 > as well as a=20 > > comparison to other OAM mechanisms that have been defined=20 > by the IEEE=20 > > and ITU-T. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-mizrahi-opsawg-oam-o > > verview-00.txt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From dromasca@avaya.com Thu Oct 15 07:14:06 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F2D3A696C for ; Thu, 15 Oct 2009 07:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ee+t29Uv8C-S for ; Thu, 15 Oct 2009 07:14:05 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 177A13A6903 for ; Thu, 15 Oct 2009 07:14:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,566,1249272000"; d="scan'208";a="160383944" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 15 Oct 2009 10:13:51 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Oct 2009 10:13:51 -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: Thu, 15 Oct 2009 16:13:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Approval of draft-ietf-opsawg-operations-and-management thread-index: AcpNobHP+sL4VrFZTIeScGOg1YV44g== From: "Romascanu, Dan (Dan)" To: Subject: [OPSAWG] Approval of draft-ietf-opsawg-operations-and-management X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 14:14:06 -0000 The IESG approved draft-ietf-opsawg-operations-and-management as Informational RFC. Thanks to David Harrington for driving this work, and to the WG for completing this important charter item.=20 Dan From tena@huawei.com Sun Oct 18 20:49:50 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D63F3A6407 for ; Sun, 18 Oct 2009 20:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.891 X-Spam-Level: X-Spam-Status: No, score=-99.891 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pKwP2FT2ren for ; Sun, 18 Oct 2009 20:49:49 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E0E0E3A6358 for ; Sun, 18 Oct 2009 20:49:44 -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 <0KRQ00GWVTASOG@szxga04-in.huawei.com> for opsawg@ietf.org; Mon, 19 Oct 2009 11:49:40 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRQ00LU3TASY3@szxga04-in.huawei.com> for opsawg@ietf.org; Mon, 19 Oct 2009 11:49:40 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRQ00F1TTASSD@szxml04-in.huawei.com> for opsawg@ietf.org; Mon, 19 Oct 2009 11:49:40 +0800 (CST) Date: Mon, 19 Oct 2009 11:49:40 +0800 From: Tina TSOU To: opsawg@ietf.org, opsawg-chairs@tools.ietf.org Message-id: <008301ca506f$2fc9d9b0$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_gGq9PYBTUwa9vtjo66vfaQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [OPSAWG] Apply a presentation for draft-tsou-network-configuration-problem-statement-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 03:49:50 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gGq9PYBTUwa9vtjo66vfaQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi Scott, May I apply a presentation in Hiroshima for OPSA WG meeting? http://www.ietf.org/id/draft-tsou-network-configuration-problem-statement-00.txt B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: IETF I-D Submission Tool To: tena@huawei.com Sent: Monday, October 19, 2009 11:37 AM Subject: New Version Notification for draft-tsou-network-configuration-problem-statement-00 A new version of I-D, draft-tsou-network-configuration-problem-statement-00.txt has been successfuly submitted by Tina Tsou (Ting ZOU) and posted to the IETF repository. Filename: draft-tsou-network-configuration-problem-statement Revision: 00 Title: Network configuration problem statement Creation_date: 2009-10-19 WG ID: Independent Submission Number_of_pages: 8 Abstract: In LTE (Long Term Evolution) bearer network, there will be a large number of network elements and service tunnels which will bring a lot of configuration work. The cost will be very high if all these work is performed manually. In order to reduce the workload of configuration to minimum, the following questions should be considered: o How to establish the DCN (Data Communication Network) connections automatically to avoid making configuration locally? o How to establish the DCN connections automatically between different vendors' network elements or how to pass through different service providers' network? o How to get network element and link information of the real network based on the information from network planning? o How to generate configuration scripts to setup network and service links automatically in order to reduce configuration design workload. LTE is a typical scenario which involves large number of network elements and service tunnels. Other scenarios like IPTV may also have network configuration problems discussed in this document. This document discusses problems related to lightening network configuration workload and better transmission tunnel setup between network elements and NMS (Network Management System). The IETF Secretariat. --Boundary_(ID_gGq9PYBTUwa9vtjo66vfaQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Hi Scott,
May I apply a presentation in Hiroshima = for OPSA WG=20 meeting?
http://www.ietf.org/id/draft-tsou-network-configuration-= problem-statement-00.txt
 
 
B. R.
Tina
http://tinatsou.weebly.c= om/contact.html
----- Original Message -----=20
From: IETF = I-D=20 Submission Tool
Sent: Monday, October 19, 2009 11:37 AM
Subject: New Version Notification for=20 draft-tsou-network-configuration-problem-statement-00


A new version of I-D,=20 draft-tsou-network-configuration-problem-statement-00.txt has been = successfuly=20 submitted by Tina Tsou (Ting ZOU) and posted to the IETF=20 repository.

Filename:=20 draft-tsou-network-configuration-problem-statement
Revision: = 00
Title:=20 Network configuration problem statement
Creation_date: = 2009-10-19
WG ID:=20 Independent Submission
Number_of_pages: 8

Abstract:
In LTE = (Long=20 Term Evolution) bearer network, there will be a large
number of = network=20 elements and service tunnels which will bring a lot
of configuration = work.=20 The cost will be very high if all these work
is performed = manually.

In=20 order to reduce the workload of configuration to minimum, = the
following=20 questions should be considered:

o How to establish the DCN (Data=20 Communication Network) connections

automatically to avoid making=20 configuration locally?

o How to establish the DCN connections=20 automatically between

different vendors' network elements or how = to pass=20 through

different service providers' network?

o How to get = network=20 element and link information of the real

network based on the = information=20 from network planning?

o How to generate configuration scripts to = setup=20 network and service

links automatically in order to reduce = configuration=20 design

workload.

LTE is a typical scenario which involves = large=20 number of network
elements and service tunnels. Other scenarios like = IPTV may=20 also have
network configuration problems discussed in this=20 document.

This document discusses problems related to lightening=20 network
configuration workload and better transmission tunnel setup=20 between
network elements and NMS (Network Management=20 System).
          &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =           =20


The IETF Secretariat.

--Boundary_(ID_gGq9PYBTUwa9vtjo66vfaQ)-- From rfc-editor@rfc-editor.org Mon Oct 19 17:13:17 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1090D3A69E4; Mon, 19 Oct 2009 17:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.892 X-Spam-Level: X-Spam-Status: No, score=-16.892 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9pSaIi3aAWb; Mon, 19 Oct 2009 17:13:16 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 57E193A69E8; Mon, 19 Oct 2009 17:13:16 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id BE5BE34C9BF; Mon, 19 Oct 2009 17:10:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091020001058.BE5BE34C9BF@bosco.isi.edu> Date: Mon, 19 Oct 2009 17:10:58 -0700 (PDT) X-Mailman-Approved-At: Tue, 20 Oct 2009 08:13:40 -0700 Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 5675 on Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 00:13:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5675 Title: Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages Author: V. Marinov, J. Schoenwaelder Status: Standards Track Date: October 2009 Mailbox: v.marinov@jacobs-university.de, j.schoenwaelder@jacobs-university.de Pages: 15 Characters: 34379 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-syslog-snmp-05.txt URL: http://www.rfc-editor.org/rfc/rfc5675.txt This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG messages. [STANDARDS TRACK] This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed 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 USC/Information Sciences Institute From rfc-editor@rfc-editor.org Mon Oct 19 17:13:32 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F356328C17C; Mon, 19 Oct 2009 17:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.898 X-Spam-Level: X-Spam-Status: No, score=-16.898 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGPso1ig5we4; Mon, 19 Oct 2009 17:13:31 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 41F5B28C0FA; Mon, 19 Oct 2009 17:13:31 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id A852634C9C1; Mon, 19 Oct 2009 17:11:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091020001113.A852634C9C1@bosco.isi.edu> Date: Mon, 19 Oct 2009 17:11:13 -0700 (PDT) X-Mailman-Approved-At: Tue, 20 Oct 2009 08:13:40 -0700 Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 5676 on Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 00:13:32 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5676 Title: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Author: J. Schoenwaelder, A. Clemm, A. Karmakar Status: Standards Track Date: October 2009 Mailbox: j.schoenwaelder@jacobs-university.de, alex@cisco.com, akarmaka@cisco.com Pages: 22 Characters: 43160 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-syslog-msg-mib-06.txt URL: http://www.rfc-editor.org/rfc/rfc5676.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a mapping of SYSLOG messages to Simple Network Management Protocol (SNMP) notifications. [STANDARDS TRACK] This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed 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 USC/Information Sciences Institute From rbonica@juniper.net Tue Oct 20 12:24:43 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D593928C138 for ; Tue, 20 Oct 2009 12:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5hLPYl8d2aq for ; Tue, 20 Oct 2009 12:24:43 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id D51613A68D0 for ; Tue, 20 Oct 2009 12:24:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSt4Of36jdaYkGafTH8EmLjttKY7+aZQ8@postini.com; Tue, 20 Oct 2009 12:24:51 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Oct 2009 12:24:28 -0700 Received: from [172.28.134.12] (172.28.134.12) by p-emfe01-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Oct 2009 15:24:27 -0400 Message-ID: <4ADE0E6A.1030206@juniper.net> Date: Tue, 20 Oct 2009 15:24:26 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "opsawg@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [OPSAWG] draft-mizrahi-opsawg-oam-overview-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 19:24:44 -0000 Tal, What is the intent of this document? If it is merely to exchange information between SDO's, that's fine. However, I think that you could take this document a step further. You could use this document to frame a conversation about which OAM capabilities the IETF should develop and which they should avoid. For example, in Section 3.2.4, you distinguish between a failure, a fault and a defect. In a connection oriented-environment, like SONET, where bandwidth is reserved even when it is not being used, it makes sense to manage all three. It also makes sense for the OAM mechanism to be built into the protocol, as they are in SONET. However, it is possible that neither assumption is true for statistically multiplexed, connectionless environments like IP or Ethernet. If you want to broaden the scope of your document, you might want to explore these issues. Ron /speaking as individual contributor > > Title : An Overview of Operations, > Administration, and Maintenance (OAM) Mechanisms > Author(s) : T. Mizrahi > Filename : draft-mizrahi-opsawg-oam-overview-00.txt > Pages : 22 > Date : 2009-10-07 > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to detecting and reporting link failures. OAM mechanisms > have been defined for various layers in the protocol stack, and are > used with a variety of protocols. > > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF, as well as > a comparison to other OAM mechanisms that have been defined by the > IEEE and ITU-T. From tena@huawei.com Tue Oct 20 18:36:40 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF9043A6839 for ; Tue, 20 Oct 2009 18:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.7 X-Spam-Level: X-Spam-Status: No, score=-98.7 tagged_above=-999 required=5 tests=[AWL=-1.102, BAYES_00=-2.599, FAKE_REPLY_C=2.012, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azTNnKqOPAid for ; Tue, 20 Oct 2009 18:36:39 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 5D35E3A67A7 for ; Tue, 20 Oct 2009 18:36:39 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU008CXCH0JD@szxga01-in.huawei.com> for opsawg@ietf.org; Wed, 21 Oct 2009 09:36:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRU00A6LCH004@szxga01-in.huawei.com> for opsawg@ietf.org; Wed, 21 Oct 2009 09:36:36 +0800 (CST) Received: from z24109b ([10.70.39.142]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRU00H52CGZAU@szxml04-in.huawei.com> for opsawg@ietf.org; Wed, 21 Oct 2009 09:36:36 +0800 (CST) Date: Wed, 21 Oct 2009 09:36:35 +0800 From: Tina TSOU To: lsc@info.fundp.ac.be Message-id: <007201ca51ee$ede53bd0$8e27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/alternative; boundary="Boundary_(ID_9PVkWEcoUYYuzRjrbO6YOA)" X-Priority: 3 X-MSMail-priority: Normal Cc: opsawg@ietf.org Subject: Re: [OPSAWG] Your IETF draft on LTE network configuration X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 01:36:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_9PVkWEcoUYYuzRjrbO6YOA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi Laurent, Thanks for your questions. Replies in line... I cc opsawg for clarification, hope you don't mind. B. R. Tina http://tinatsou.weebly.com/contact.html ----- Original Message ----- From: Laurent Schumacher To: tena@huawei.com Sent: Monday, October 19, 2009 2:56 PM Subject: Your IETF draft on LTE network configuration Dear editor of draft-tsou-network-configuration-problem-statement, Two quick questions, if you allow me to: * Where is this draft discussed? NetConf working group mailing list? It is proposed to be discussed in OPSAWG rather than the NetConf. The scope discussed is wider and it is for the whole network instead of an interface. * Could middlebox configuration (draft-ietf-nsis-nslp-natfw) as considered in Next Steps In Signalling (draft-ietf-nsis-ext) provide any relief for the automatic generation of network configuration? One of the most interesting features of this framework could be the automatic discovery of NSIS peers through GIST. This however has the pre-requisite of IP connectivity. The middlebox configuration is used for traversing NAT/firewall. The problem stated is to automatically configure related parameters for the tunnel between NMS and network device in order to setup the session tunnel. This configuration exists before the IP connectivity is setup. Best regards, LS -- Laurent Schumacher Faculty of Computer Science, UCLouvain, Namur Campus ------------------------------------------------------------ Web page: http://www.info.fundp.ac.be/~lsc/ ------------------------------------------------------------ --Boundary_(ID_9PVkWEcoUYYuzRjrbO6YOA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Hi Laurent,
Thanks for your questions.
Replies in line...
I cc opsawg for clarification, hope you = don't=20 mind.
 
 
B. R.
Tina
http://tinatsou.weebly.c= om/contact.html

 
----- Original Message -----=20
From: Laurent=20 Schumacher
Sent: Monday, October 19, 2009 2:56 PM
Subject: Your IETF draft on LTE network = configuration

Dear editor of=20 draft-tsou-network-configuration-problem-statement,

Two quick=20 questions, if you allow me to:

    * Where is = this draft=20 discussed? NetConf working group mailing list?

It=20 is proposed to be discussed in OPSAWG rather than the NetConf.=20

The=20 scope discussed is wider and it is for the whole network instead of an = interface.


    * = Could middlebox configuration=20 (draft-ietf-nsis-nslp-natfw) as
      = considered=20 in Next Steps In Signalling=20 (draft-ietf-nsis-ext)
      provide any = relief for=20 the automatic generation of network
     =20 configuration? One of the most interesting features of=20 this
      framework could be the = automatic=20 discovery of NSIS peers through
      = GIST. This=20 however has the pre-requisite of IP connectivity.
 

The=20 middlebox configuration is used for traversing NAT/firewall.=20

The=20 problem stated is to automatically configure related parameters for=20 the tunnel between NMS and network device in order to setup=20 the session tunnel. This configuration exists before = the IP=20 connectivity is setup.


Best=20 regards,
LS

--
Laurent Schumacher <laurent.schumacher@ieee.org>
Faculty=20 of Computer Science, UCLouvain, Namur=20 = Campus
------------------------------------------------------------       =20 Web page: http://www.info.fundp.ac.be/~l= sc/
------------------------------------------------------------
--Boundary_(ID_9PVkWEcoUYYuzRjrbO6YOA)-- From Quittek@nw.neclab.eu Tue Oct 20 21:17:37 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBEF28C17A for ; Tue, 20 Oct 2009 21:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1oqJNg+R5C1 for ; Tue, 20 Oct 2009 21:17:36 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CF4F128C1A3 for ; Tue, 20 Oct 2009 21:17:15 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A3FDB2C017B2E for ; Wed, 21 Oct 2009 06:17:23 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV6WdZk5kzhq for ; Wed, 21 Oct 2009 06:17:23 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 6FAE52C0004D6 for ; Wed, 21 Oct 2009 06:17:18 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Oct 2009 04:17:00 +0000 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3338965738_2104620" Content-class: urn:content-classes:message Date: Wed, 21 Oct 2009 06:17:01 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: monitoring power state and energy consumption thread-index: AcpR7dxiHOEy0PMUXUKrGN5it54J9Q== From: "Juergen Quittek" To: Subject: [OPSAWG] monitoring power state and energy consumption X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 04:17:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3338965738_2104620 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear all, At the session in Stockholm we discussed monitoring of power states and energy consumption in the network. After the positive feedback received there, we wrote an I-D sketching requirements. The draft concludes with a proposal to develop a Power MIB module for monitoring of power states and total power consumption. It also suggest defining information elements for reporting time series of energy consumption measurements with the IPFX protocol. Please find it at http://www.ietf.org/id/draft-quittek-power-monitoring-requirements-00.txt While the MIB module is rather targeted at communications network management, the IPFIX information elements would also be applicable to smart meters in smart power grids. Your comments are highly appreciated. Thanks, Juergen --B_3338965738_2104620 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQYP4KUMAMyWCtNKIUU KxH3qHafRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjEwMTI4NThaMA0GCSqGSIb3DQEBAQUABIIBABnxdvWUVaM6Gqe/0cw9wTlLeO1FsTKnXUrb TmQ7VYSRhyRFpArxpjh7evW2HFFBe6QZYCfosoxQCfEcbWgpSGkt3+94koZPVUZygCchyT8j dU8Y1UbmMmOKZygbUu+aU3JyvPhfnowl6JIl9H6pdwL5oxLXrKdYH9rxyjj7/iysymtxhl+F N5CzEX3L8sseAFHP7NI7f4MFxbw6IGrgM8nBe6gt1VEZ9es8t6EGKPhsvyhmBKQzzD+/n6/z t+6u35DKR4TihFgq98a2gQQdslblUYly6CIYivtPXM9BDZzfQ5i10ASmKlWakY6V1iHYe0WN +MnBrRt9f4zx1Suz9yo= --B_3338965738_2104620-- From hideki.okita.pf@hitachi.com Wed Oct 21 01:33:58 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27823A682D for ; Wed, 21 Oct 2009 01:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOE-B19VXhUn for ; Wed, 21 Oct 2009 01:33:58 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by core3.amsl.com (Postfix) with ESMTP id EFE963A67A1 for ; Wed, 21 Oct 2009 01:33:57 -0700 (PDT) Received: from mlsv2.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 03B5333CC4 for ; Wed, 21 Oct 2009 17:34:05 +0900 (JST) Received: from mfilter1.hitachi.co.jp by mlsv2.hitachi.co.jp (8.13.1/8.13.1) id n9L8Y4kB006659; Wed, 21 Oct 2009 17:34:04 +0900 Received: from hitachi.com (mfbcchk2.hitachi.co.jp [10.201.6.151]) by mfilter1.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id n9L3P37p018840 for ; Wed, 21 Oct 2009 17:34:04 +0900 Received: from vshuts4.hitachi.co.jp ([vshuts4.hitachi.co.jp [10.201.6.80]]) by mfbcchk2.hitachi.co.jp with RELAY id n9L8Y4TX002118 ; Wed, 21 Oct 2009 17:34:04 +0900 X-AuditID: b753bd60-ab846ba000006009-f6-4adec77bd149 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts4.hitachi.co.jp (Symantec Mail Security) with ESMTP id D74742042BC for ; Wed, 21 Oct 2009 17:34:03 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id n9L8Y3D25833528; Wed, 21 Oct 2009 17:34:03 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Wed, 21 Oct 2009 17:33:47 +0900 References: <20091021023314.557B53A6817@core3.amsl.com> Priority: normal Importance: normal X400-Content-Identifier: X4ADEC75100000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28091021173321PTN] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-FMFTCR: RANGEC Subject: [OPSAWG] Fw:New Version Notification for draft-okita-ops-vnetmodel-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 08:33:59 -0000 Dear all, I submitted an I-D about virtual network operations. Based on the comments to my presentation at the Stockholm meeting, I updated the I-D. Submitted I-D: http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt This I-D proposes an UML-based information model for virtual networks. It describes the structure of physical network devices and virtual network devices and the relationship between them. This information model is used as the base of actual datamodels like MIBs or XML-based datamodels. > Scott I'd like to take a presentation and discuss this topic at the opsawg meeting in Hiroshima. Could you assign me a slot? Regards, Hideki Okita >A new version of I-D, draft-okita-ops-vnetmodel-01.txt has been successfuly submitted by Hideki Okita and posted to the IETF repository. > >Filename: draft-okita-ops-vnetmodel >Revision: 01 >Title: Virtual Network Management Information Model >Creation_date: 2009-10-21 >WG ID: Independent Submission >Number_of_pages: 25 > >Abstract: >Virtual switches on server virtualization platforms cause a problem >in managing data center networks containing several hundred switches. >Accordingly, a management information model for the network structure >of data center networks containing virtual switches is proposed. The >proposed model consists of a physical layer (which represents >connections between physical switches) and a virtual layer (which >represents connections between virtual switches). These layers also >represent the association of the virtual switch with the >corresponding physical switch. The model shortens the virtual LAN >(VLAN) configuration time taken by operators of data center networks >by a maximum of 35%. This result shows that the proposed model is >effective in reducing the management time of data center networks >containing virtual switches. > > > >The IETF Secretariat. From sob@harvard.edu Wed Oct 21 04:58:23 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC673A691D for ; Wed, 21 Oct 2009 04:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.082 X-Spam-Level: X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljok3XEwUw5E for ; Wed, 21 Oct 2009 04:58:23 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id DF0823A68F5 for ; Wed, 21 Oct 2009 04:58:22 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 4E2041B524A; Wed, 21 Oct 2009 07:58:31 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20091021115831.4E2041B524A@newdev.eecs.harvard.edu> Date: Wed, 21 Oct 2009 07:58:31 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 11:58:23 -0000 please send requests for agenda time slots for the opsawq session in Hiroshima to the opsawg list asap Scott From leo.vegoda@icann.org Wed Oct 21 11:35:39 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773273A6A0E for ; Wed, 21 Oct 2009 11:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NIbtjX2sU9r for ; Wed, 21 Oct 2009 11:35:38 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 6AF6A3A685C for ; Wed, 21 Oct 2009 11:35:38 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 21 Oct 2009 11:35:47 -0700 From: Leo Vegoda To: Matthew Ford Date: Wed, 21 Oct 2009 11:35:45 -0700 Thread-Topic: [Int-area] draft-azinger-additional-private-ipv4-space-issues (OPSAREA WG) Thread-Index: AcpIASIvHKcfyHycQWWFoV4Zxj6WXQKfCrX+ Message-ID: In-Reply-To: <4ACDB78D.2030501@isoc.org> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] [Int-area] draft-azinger-additional-private-ipv4-space-issues (OPSAREA WG) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 18:35:39 -0000 Dear Mat, Thank you very much for your comments. We think they fall into two categories: the tone of the language used and the likelihood of an ISP to need a whole /8 in a very short period. On the first point, we think we should try to keep the language dispassionate. Phrases like "prohibited by fiat" carry some emotional baggage with them and might be seen as a judgment on whether the network operator's policy is appropriate. As authors, we don't want to take a position on whether a policy is appropriate or not; we want to document tha= t these policies exist. On the second issue, the point we are trying to document is the possibility that large networks may grow at a rate and to a level where they are unable to use private address space for large parts of their network and so have t= o use unique addresses. This statement is based on conversations with the network architects at several of the largest consumer ISPs. Also, we need t= o bear in mind that after one of these very large ISPs has had to move to unique addresses for part of their network, there is a competitive pressure on other ISPs to do the same. We hope these explanations make our reasoning clear. Kind regards, Marla & Leo On 08/10/2009 2:57, "Matthew Ford" wrote: > Hi Leo, >=20 > On 30/09/2009 19:28, Leo Vegoda wrote: >> On 25/09/2009 6:45, "Matthew Ford" wrote: >>> Section 3 - Where are these residential and corporate networks where >>> 'peer to peer communication is not needed'? >>=20 >> It is not uncommon for some network operators to restrict the use of >> peer-to-peer technologies either within their own network or across its >> borders. In enterprises this is sometimes part of a security policy. For >> instance some financial companies are required to record all incoming an= d >> outgoing voice calls and so disallow peer-to-peer VoIP services. >>=20 >> In ISP networks there is sometimes a policy or technology that restricts >> peer-to-peer technologies, whether for revenue protection reasons or >> otherwise, forcing most IP traffic via proxies and caches. One example o= f >> this is the image compression used by many cellular data networks. >=20 > Understood. So I think this text should be clarified, perhaps as follows: >=20 > Replace >=20 > 'For instance, it is often technically feasible to use NAT or even > multiple layers of NAT within the networks operated by residential users > or corporations where peer to peer communication is not needed.' >=20 > with >=20 > 'For instance, it is often technically feasible to use NAT or even > multiple layers of NAT within networks where peer-to-peer technologies > are prohibited by fiat and where users cannot expect to use any > unsupported services or applications.' >=20 >>> Section 5.2 - I'm struggling to understand why it's 'likely' that there >>> will be networks consuming whole /8s in 12 month periods for private >>> addressing purposes. If there were networks with that much need for >>> private addressing, we'd have been hearing complaints about how net10 i= s >>> too small way before now, right? >>=20 >> We have both spoken to network operators who know that they have a need = for >> very large amounts of address space over short time frames but are sitti= ng >> on the requests for as long as possible. That being said, it is not unkn= own >> for networks to be allocated whole /8s in one go. For instance, APNIC >> allocated 126.0.0.0/8 to Softbank. >=20 > That was nearly five years ago. Have Softbank asked for more since? The > text currently says it is 'likely' that there will be networks consuming > whole /8s for private addressing in a 12 month period. >=20 > I'd replace >=20 > 'It is possible and even likely that a single > network could consume a whole IPv4 /8 in a year. ' >=20 > with >=20 > 'Very large networks could consume multiple IPv4 /8s over time.' >=20 >> Another example of a statement of need is the recent (now abandoned) APN= IC >> policy proposal (prop-058-v001) "Proposal to create IPv4 shared use addr= ess >> space among LIRs". >>=20 >>> This wording in section 4.1 on solving the problem with IPv6 is rather = coy: >>> "In some cases implementing a new network protocol on a very large >>> network takes more time than is available, based on network growth and >>> the proportion of private space that has already been used. In these >>> cases, there is a call for additional private address space that can be >>> shared by all network operators." >>>=20 >>> Let's be clear about this: >>>=20 >>> 'Some network operators are complaining today that they do not have tim= e >>> to implement IPv6 on their network before they run out of private space= . >>> These operators are calling for additional private address space to be >>> made available...' >>=20 >> We could change the wording to something more direct but I would persona= lly >> prefer not to use the word "complaining" as I don't think I have heard a= ny >> complaints, just proposals and concerns. >=20 > That's fair. How about >=20 > 'Some network operators are concerned that they do not have sufficient > time to implement IPv6 on their network before they run out of private > space. These operators are calling for additional private address space > to be made available...' >=20 > Mat >=20 From ford@isoc.org Thu Oct 22 03:41:08 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9CB128C100 for ; Thu, 22 Oct 2009 03:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.705 X-Spam-Level: X-Spam-Status: No, score=-102.705 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTozJK9xhqz1 for ; Thu, 22 Oct 2009 03:41:06 -0700 (PDT) Received: from smtp188.iad.emailsrvr.com (smtp188.iad.emailsrvr.com [207.97.245.188]) by core3.amsl.com (Postfix) with ESMTP id 5428628C10A for ; Thu, 22 Oct 2009 03:41:06 -0700 (PDT) Received: from relay8.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay8.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 9E515202E5D; Thu, 22 Oct 2009 06:41:14 -0400 (EDT) Received: by relay8.relay.iad.mlsrvr.com (Authenticated sender: ford-AT-isoc.org) with ESMTPSA id AF61920292B; Thu, 22 Oct 2009 06:41:13 -0400 (EDT) Message-ID: <4AE036C8.5010907@isoc.org> Date: Thu, 22 Oct 2009 11:41:12 +0100 From: Matthew Ford User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4 MIME-Version: 1.0 To: Leo Vegoda References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] [Int-area] draft-azinger-additional-private-ipv4-space-issues (OPSAREA WG) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 10:41:09 -0000 Hi Leo, On 21/10/2009 19:35, Leo Vegoda wrote: > Dear Mat, > > Thank you very much for your comments. We think they fall into two > categories: the tone of the language used and the likelihood of an ISP to > need a whole /8 in a very short period. > > On the first point, we think we should try to keep the language > dispassionate. Phrases like "prohibited by fiat" carry some emotional > baggage with them and might be seen as a judgment on whether the network > operator's policy is appropriate. As authors, we don't want to take a > position on whether a policy is appropriate or not; we want to document that > these policies exist. Actually, I don't read any emotion into that phrase, but if you don't like it, just drop the 'by fiat'. > On the second issue, the point we are trying to document is the possibility > that large networks may grow at a rate and to a level where they are unable > to use private address space for large parts of their network and so have to > use unique addresses. This statement is based on conversations with the > network architects at several of the largest consumer ISPs. Also, we need to > bear in mind that after one of these very large ISPs has had to move to > unique addresses for part of their network, there is a competitive pressure > on other ISPs to do the same. I don't think the replacement text I'm suggesting is at odds with that - I'm simply trying to have the text reflect what you're explaining to be your meaning. > We hope these explanations make our reasoning clear. Yes, they do, thanks. I guess as I'm wordsmithing already, that means I'd like to see this adopted by the WG :) Mat > > Kind regards, > > Marla& Leo > > > > On 08/10/2009 2:57, "Matthew Ford" wrote: > >> Hi Leo, >> >> On 30/09/2009 19:28, Leo Vegoda wrote: >>> On 25/09/2009 6:45, "Matthew Ford" wrote: >>>> Section 3 - Where are these residential and corporate networks where >>>> 'peer to peer communication is not needed'? >>> >>> It is not uncommon for some network operators to restrict the use of >>> peer-to-peer technologies either within their own network or across its >>> borders. In enterprises this is sometimes part of a security policy. For >>> instance some financial companies are required to record all incoming and >>> outgoing voice calls and so disallow peer-to-peer VoIP services. >>> >>> In ISP networks there is sometimes a policy or technology that restricts >>> peer-to-peer technologies, whether for revenue protection reasons or >>> otherwise, forcing most IP traffic via proxies and caches. One example of >>> this is the image compression used by many cellular data networks. >> >> Understood. So I think this text should be clarified, perhaps as follows: >> >> Replace >> >> 'For instance, it is often technically feasible to use NAT or even >> multiple layers of NAT within the networks operated by residential users >> or corporations where peer to peer communication is not needed.' >> >> with >> >> 'For instance, it is often technically feasible to use NAT or even >> multiple layers of NAT within networks where peer-to-peer technologies >> are prohibited by fiat and where users cannot expect to use any >> unsupported services or applications.' >> >>>> Section 5.2 - I'm struggling to understand why it's 'likely' that there >>>> will be networks consuming whole /8s in 12 month periods for private >>>> addressing purposes. If there were networks with that much need for >>>> private addressing, we'd have been hearing complaints about how net10 is >>>> too small way before now, right? >>> >>> We have both spoken to network operators who know that they have a need for >>> very large amounts of address space over short time frames but are sitting >>> on the requests for as long as possible. That being said, it is not unknown >>> for networks to be allocated whole /8s in one go. For instance, APNIC >>> allocated 126.0.0.0/8 to Softbank. >> >> That was nearly five years ago. Have Softbank asked for more since? The >> text currently says it is 'likely' that there will be networks consuming >> whole /8s for private addressing in a 12 month period. >> >> I'd replace >> >> 'It is possible and even likely that a single >> network could consume a whole IPv4 /8 in a year. ' >> >> with >> >> 'Very large networks could consume multiple IPv4 /8s over time.' >> >>> Another example of a statement of need is the recent (now abandoned) APNIC >>> policy proposal (prop-058-v001) "Proposal to create IPv4 shared use address >>> space among LIRs". >>> >>>> This wording in section 4.1 on solving the problem with IPv6 is rather coy: >>>> "In some cases implementing a new network protocol on a very large >>>> network takes more time than is available, based on network growth and >>>> the proportion of private space that has already been used. In these >>>> cases, there is a call for additional private address space that can be >>>> shared by all network operators." >>>> >>>> Let's be clear about this: >>>> >>>> 'Some network operators are complaining today that they do not have time >>>> to implement IPv6 on their network before they run out of private space. >>>> These operators are calling for additional private address space to be >>>> made available...' >>> >>> We could change the wording to something more direct but I would personally >>> prefer not to use the word "complaining" as I don't think I have heard any >>> complaints, just proposals and concerns. >> >> That's fair. How about >> >> 'Some network operators are concerned that they do not have sufficient >> time to implement IPv6 on their network before they run out of private >> space. These operators are calling for additional private address space >> to be made available...' >> >> Mat >> > From Quittek@nw.neclab.eu Thu Oct 22 07:58:28 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097BD3A6891 for ; Thu, 22 Oct 2009 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ksrk4TdBFN3Z for ; Thu, 22 Oct 2009 07:58:27 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 05B293A6858 for ; Thu, 22 Oct 2009 07:58:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 84DB02C019174 for ; Thu, 22 Oct 2009 16:58:36 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiaWEkg2s0Sf for ; Thu, 22 Oct 2009 16:58:36 +0200 (CEST) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 518092C01898B for ; Thu, 22 Oct 2009 16:58:31 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Oct 2009 14:58:31 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3339100643_4458824" Date: Thu, 22 Oct 2009 16:57:23 +0200 Message-ID: In-Reply-To: <20091021115831.4E2041B524A@newdev.eecs.harvard.edu> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] call for opsawg agenda time requests thread-index: AcpTJ/YHSl1c/2uUaESF9JzQLFsDig== From: "Juergen Quittek" To: Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 14:58:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339100643_4458824 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I would like to have a slot for presenting the draft on requirements for monitoring of power states and energy consumption http://www.ietf.org/id/draft-quittek-power-monitoring-requirements-00.txt Thanks, Juergen On 21.10.09 20:58 "Scott O. Bradner" wrote: > please send requests for agenda time slots for the opsawq session in Hiroshima > to the opsawg list asap --B_3339100643_4458824 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSy2Jd459ECgeqiHGvT nFJDwWgGjzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjIxNDU3MjNaMA0GCSqGSIb3DQEBAQUABIIBACVIvr0gOSBXvYtBa/5WJspY7fILbjLHfNEp w4UDYxGkG7ZB02EFL2G6fT0KvftuhtZ1LseH9ZIBC2kXMdNJC4X27UHNoExadEMkao9reqa4 pPC3d9EM2GtZaN+Dqut+MTZjKWLUM51uhzUYd0m1qkyxDrAuR5BWUn+4F1Ntgx6UduRfeqeq ioeLc4O+sfpcHn/vLeJpn3WTIoo9XBP7Y6KlO+6X+s6L5QlSXACxdth9EMRa1HZTNshmg65N nJQf35ABUhqAbbG6oIaGFF5LaSwOAvWelWkNxCFjhU13gbfCCKAGM1QmD+qQY59vOrevVvP+ Q5WY7T7GolP70AvGmKI= --B_3339100643_4458824-- From tena@huawei.com Thu Oct 22 08:10:16 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C19E3A67D7 for ; Thu, 22 Oct 2009 08:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.013 X-Spam-Level: X-Spam-Status: No, score=-101.013 tagged_above=-999 required=5 tests=[AWL=-0.518, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1b1XDEWdqqo for ; Thu, 22 Oct 2009 08:10:14 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BF3CB3A677D for ; Thu, 22 Oct 2009 08:10:14 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRX00L058T1A1@szxga01-in.huawei.com> for opsawg@ietf.org; Thu, 22 Oct 2009 23:10:14 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRX00H7K8T11P@szxga01-in.huawei.com> for opsawg@ietf.org; Thu, 22 Oct 2009 23:10:13 +0800 (CST) Received: from [192.168.1.4] (183.83.35.121.broad.sz.gd.dynamic.163data.com.cn [121.35.83.183]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRX00LFJ8T136@szxml02-in.huawei.com>; Thu, 22 Oct 2009 23:10:13 +0800 (CST) Date: Thu, 22 Oct 2009 23:10:12 +0800 From: Tina TSOU In-reply-to: To: Juergen Quittek Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.930.3) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT References: Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2009 15:10:16 -0000 > I would like to have a slot for presenting the draft on > Network configuration problem statement > http://www.ietf.org/id/draft-tsou-network-configuration-problem-statement-00.txt B. R. Tina http://tinatsou.weebly.com/contact.html On Oct 22, 2009, at 10:57 PM, Juergen Quittek wrote: > I would like to have a slot for presenting the draft on > requirements for monitoring of power states and energy consumption > http://www.ietf.org/id/draft-quittek-power-monitoring-requirements-00.txt > > Thanks, > > Juergen > > On 21.10.09 20:58 "Scott O. Bradner" wrote: > >> please send requests for agenda time slots for the opsawq session >> in Hiroshima >> to the opsawg list asap > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From j.schoenwaelder@jacobs-university.de Fri Oct 23 12:59:12 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA52E3A699D for ; Fri, 23 Oct 2009 12:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZNPSC3MP42p for ; Fri, 23 Oct 2009 12:59:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9D75E3A6995 for ; Fri, 23 Oct 2009 12:59:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E6D5C0012; Fri, 23 Oct 2009 21:59:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WBDVH7GgyKoJ; Fri, 23 Oct 2009 21:59:21 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F468C000E; Fri, 23 Oct 2009 21:59:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 35A02D54CA6; Fri, 23 Oct 2009 21:59:18 +0200 (CEST) Date: Fri, 23 Oct 2009 21:59:18 +0200 From: Juergen Schoenwaelder To: RFC Errata System Message-ID: <20091023195918.GC10858@elstar.local> Mail-Followup-To: RFC Errata System , "alex@cisco.com" , "akarmaka@cisco.com" , "dromasca@avaya.com" , "rbonica@juniper.net" , "sob@harvard.edu" , "ted.a.seely@sprint.com" , "ah@TR-Sys.de" , "opsawg@ietf.org" References: <200910231836.n9NIaO14012178@boreas.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910231836.n9NIaO14012178@boreas.isi.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "ah@TR-Sys.de" , "akarmaka@cisco.com" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [Editorial Errata Reported] RFC5676 (1927) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 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: Fri, 23 Oct 2009 19:59:13 -0000 On Fri, Oct 23, 2009 at 08:36:24PM +0200, RFC Errata System wrote: > > The following errata report has been submitted for RFC5676, > "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1927 > > -------------------------------------- > Type: Editorial > Reported by: Alfred Hoenes > > Section: 4, 3rd para > > Original Text > ------------- > The MIB module is organized into a group of scalars and two tables. > The syslogMsgControl group contains two scalars controlling the > | maximum size of SYSLOG messages recorded in the tables and also > controlling whether SNMP notifications are generated for SYSLOG > messages. > > > Corrected Text > -------------- > The MIB module is organized into a group of scalars and two tables. > The syslogMsgControl group contains two scalars controlling the > | maximum number of SYSLOG messages recorded in the tables and also > controlling whether SNMP notifications are generated for SYSLOG > messages. > > > Notes > ----- > Rationale: possible confusion. > > "maximum size of SYSLOG messages recorded" conceptionally would > relate to the SIZE of syslogMsgMsg OCTET STRING instances or the > maximum value for syslogMsgSDParams instances, but the DESCRIPTION > clause for the syslogMsgTableMaxSize OBJECT-TYPE in the MIB module > in Section 7 clarifies that this object indicates the maximum > *number* of entries in the syslogMsgTable and does not describe > some filtering criterion (by size) of the SYSLOG messages recorded. Yes, this is a typo in the text and the DESCRIPTION clause has it correct. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From web-usrn@ISI.EDU Fri Oct 23 11:37:09 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0C493A697A for ; Fri, 23 Oct 2009 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.197 X-Spam-Level: X-Spam-Status: No, score=-17.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbI3TZajkmLh for ; Fri, 23 Oct 2009 11:37:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 177883A6856 for ; Fri, 23 Oct 2009 11:37:09 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9NIaQuv012201; Fri, 23 Oct 2009 11:36:26 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n9NIaO14012178; Fri, 23 Oct 2009 11:36:24 -0700 (PDT) Date: Fri, 23 Oct 2009 11:36:24 -0700 (PDT) Message-Id: <200910231836.n9NIaO14012178@boreas.isi.edu> To: j.schoenwaelder@jacobs-university.de, alex@cisco.com, akarmaka@cisco.com, dromasca@avaya.com, rbonica@juniper.net, sob@harvard.edu, ted.a.seely@sprint.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Sun, 25 Oct 2009 00:22:43 -0700 Cc: ah@TR-Sys.de, opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] [Editorial Errata Reported] RFC5676 (1927) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 18:37:10 -0000 The following errata report has been submitted for RFC5676, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1927 -------------------------------------- Type: Editorial Reported by: Alfred Hoenes Section: 4, 3rd para Original Text ------------- The MIB module is organized into a group of scalars and two tables. The syslogMsgControl group contains two scalars controlling the | maximum size of SYSLOG messages recorded in the tables and also controlling whether SNMP notifications are generated for SYSLOG messages. Corrected Text -------------- The MIB module is organized into a group of scalars and two tables. The syslogMsgControl group contains two scalars controlling the | maximum number of SYSLOG messages recorded in the tables and also controlling whether SNMP notifications are generated for SYSLOG messages. Notes ----- Rationale: possible confusion. "maximum size of SYSLOG messages recorded" conceptionally would relate to the SIZE of syslogMsgMsg OCTET STRING instances or the maximum value for syslogMsgSDParams instances, but the DESCRIPTION clause for the syslogMsgTableMaxSize OBJECT-TYPE in the MIB module in Section 7 clarifies that this object indicates the maximum *number* of entries in the syslogMsgTable and does not describe some filtering criterion (by size) of the SYSLOG messages recorded. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5676 (draft-ietf-opsawg-syslog-msg-mib-06) -------------------------------------- Title : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Publication Date : October 2009 Author(s) : J. Schoenwaelder, A. Clemm, A. Karmakar Category : PROPOSED STANDARD Source : Operations and Management Area Working Group Area : Operations and Management Stream : IETF Verifying Party : IESG From web-usrn@ISI.EDU Fri Oct 23 12:40:49 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E7E3A67F4 for ; Fri, 23 Oct 2009 12:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.21 X-Spam-Level: X-Spam-Status: No, score=-17.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRV-gDzgGFKY for ; Fri, 23 Oct 2009 12:40:48 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id 91C593A679F for ; Fri, 23 Oct 2009 12:40:48 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n9NJdnI9006580; Fri, 23 Oct 2009 12:39:50 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n9NJdmMr006579; Fri, 23 Oct 2009 12:39:48 -0700 (PDT) Date: Fri, 23 Oct 2009 12:39:48 -0700 (PDT) Message-Id: <200910231939.n9NJdmMr006579@boreas.isi.edu> To: j.schoenwaelder@jacobs-university.de, alex@cisco.com, akarmaka@cisco.com, dromasca@avaya.com, rbonica@juniper.net, sob@harvard.edu, ted.a.seely@sprint.com From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu X-Mailman-Approved-At: Sun, 25 Oct 2009 00:22:43 -0700 Cc: ah@TR-Sys.de, opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2009 19:40:49 -0000 The following errata report has been submitted for RFC5676, "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1928 -------------------------------------- Type: Technical Reported by: Alfred Hoenes Section: 7, pg. 7 Original Text ------------- SyslogTimeStamp ::= TEXTUAL-CONVENTION ! DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d" STATUS current DESCRIPTION "A date-time specification. This type is similar to the DateAndTime type defined in the SNMPv2-TC, except the subsecond granulation is microseconds instead of deciseconds and a zero-length string can be used to indicate a missing value. field octets contents range ----- ------ -------- ----- | 1 1-2 year* 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) ! 7 8-10 microseconds* 0..999999 8 11 direction from UTC '+' / '-' 9 12 hours from UTC* 0..13 10 13 minutes from UTC 0..59 * Notes: - the value of year is in network-byte order | - the value of microseconds is in network-byte order - daylight saving time in New Zealand is +13 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as: 1992-5-26,13:30:15.0,-4:0 Note that if only local time is known, then timezone information (fields 11-13) is not present." SYNTAX OCTET STRING (SIZE (0 | 10 | 13)) Corrected Text -------------- (a) upper part of the table: field octets contents range ----- ------ -------- ----- | 1 1-2 year* 0..32767 ... (b) "*Notes:" part: << see Notes below -- one possibility to address the issue is amending the text as follows; verifiers might do better >> * Notes: - the value of year is in network-byte order | - the value of microseconds is in network-byte order; | users of network management applications following | the DISPLAY-HINT specified above should be aware of | the unusual appearance of the apparent 'fractional part' | displayed: RFC 2579 requires the leading zeros to be | omitted; thus a time component diaplayed as '13:30:15.50' | does not indicate 50 centiseconds, but 50 microseconds | past the full second! - daylight saving time in New Zealand is +13 Notes ----- (a) Section 3.1 of RFC 2579 (on page 21) states, regarding numerical conversion descriptor components in DISPLAY-HINTS: [...] For all types, when rendering a value, leading zeros are omitted, and for negative values, a minus sign is rendered immediately before the digits. [...] Arguably, this means that substrings of OCTET STRING type are interpreted as *signed* values (in network byte order). Therefore, the range restriction for the 'year' part specified informally in the DESCRIPTION clause does not make proper sense; an upper bound of 65536 is nonsensical anyway since a 2-octet substring cannot assme 65537 different values; to avoid issues with different interpretation of RFC 2579, the 'safe' range 0..32767 is recommended -- this should not be a serious restriction in practice. (b) WARNING: According to Section 3.1 of RFC 2579, the components of the DISPLAY-HINTS string describe the *independent* formatting of substrings of the OCTET STRING (in this case). Thus, the display instructions for the conceptional 'seconds' part of the OCTET STRING, "1d.3d", actually describes the independent formatting of a 1-octet and a 3-octet substring (in network byte order) as decimal integers without leading zeros, separated by a literal period ('.') -- a "display separator character" in RFC 2579 terms --, and not the human-friendly formatting of a single fixed-point fractional number; there is no concept of a decimal fraction representation in this notation. So the presentation format will be very different from common practice for human beings. See the example below. The "fixed-point with decimal sign" representation from RFC 2579 is only available for INTEGER values, for cases with scaled values, where the conceptual integer and fractional part are stored as a single integer in units of the specified fractional part; it is not applicable to display formats for OCTET STRING objects. Elaborating on a slight variant of the example from the RFC, ... Tuesday May 26, 1992 at 1:30:15.008 PM EDT (8 milliseconds past the full 15 seconds), the 'seconds' part would be represented as 15 seconds 8000 microseconds in four octets containing 0x0F, 0x00, 0x1F, 0x40, which, together with the other components, would be rendered as: 1992-5-26,13:30:15.8000,-4:0 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5676 (draft-ietf-opsawg-syslog-msg-mib-06) -------------------------------------- Title : Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications Publication Date : October 2009 Author(s) : J. Schoenwaelder, A. Clemm, A. Karmakar Category : PROPOSED STANDARD Source : Operations and Management Area Working Group Area : Operations and Management Stream : IETF Verifying Party : IESG From Washam.Fan@huaweisymantec.com Sun Oct 25 01:17:41 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A083A6942 for ; Sun, 25 Oct 2009 01:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEjasVGfFcUf for ; Sun, 25 Oct 2009 01:17:41 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id EFB983A68E6 for ; Sun, 25 Oct 2009 01:17:40 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pH0UM7VAPx6txI+x29PU5w)" 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 <0KS200MDT9P6ZC50@hstga02-in.huaweisymantec.com> for opsawg@ietf.org; Sun, 25 Oct 2009 16:17:31 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KS200E9H9P6MN10@hstml02-in.huaweisymantec.com> for opsawg@ietf.org; Sun, 25 Oct 2009 16:17:30 +0800 (CST) Received: from [117.79.65.106] by hstml02-in.huaweisymantec.com (mshttpd); Sun, 25 Oct 2009 16:17:30 +0800 From: WashamFan To: opsawg@ietf.org Message-id: Date: Sun, 25 Oct 2009 16:17:30 +0800 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] Fwd: New Version Notification for draft-meng-fan-lock-mib-02 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2009 08:17:41 -0000 This is a multi-part message in MIME format. --Boundary_(ID_pH0UM7VAPx6txI+x29PU5w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Hi, I just submitted a new version of lock-mib draft, I think it has addressed all raised concerns. Any comments, suggestions and clarifications are more than welcome. Compare to -01, 1. I rephrased section 1 hoping make the intent and scope more clearer. 2. I added subsection 4.5 to address implementation concerns. 3. changes in the MIB (mainly based on Juergen's comments) 1) expand lockUserName length to 255. 2) change lockStartTime/lockEndTime from TimeTicks to TimeStamp 3) make lockIndex to be the index of all tables. washam --Boundary_(ID_pH0UM7VAPx6txI+x29PU5w) Content-type: message/rfc822 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KS200IWH47M2U00@hstga01-in.huaweisymantec.com> for Washam.Fan@huaweisymantec.com; Sun, 25 Oct 2009 14:18:58 +0800 (CST) Received: from hstrg02-in.huaweisymantec.com ([172.26.3.38]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KS200E6J47MXW10@hstml01-in.huaweisymantec.com> for Washam.Fan@huaweisymantec.com (ORCPT Washam.Fan@huaweisymantec.com); Sun, 25 Oct 2009 14:18:58 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by hstrg02-in.huaweisymantec.com (MOS 3.10.6-GA) id AID41909; Sun, 25 Oct 2009 14:19:01 +0800 (CST) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by hstrg02-in.huaweisymantec.com (MOS 3.10.6-GA) with ESMTP id AID41907; Sun, 25 Oct 2009 14:18:59 +0800 (CST) Received: by core3.amsl.com (Postfix, from userid 30) id 663723A67EA; Sat, 24 Oct 2009 23:18:41 -0700 (PDT) Date: Sat, 24 Oct 2009 23:18:42 -0700 (PDT) From: IETF I-D Submission Tool Subject: New Version Notification for draft-meng-fan-lock-mib-02 To: Washam.Fan@huaweisymantec.com Cc: mengjian@huaweisymantec.com Message-id: <20091025061842.663723A67EA@core3.amsl.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Junkmail-Status: score=10/55, host=hstrg02-in.huaweisymantec.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A150203.4AE3EDD2.0046:SCFSTAT3674418,ss=1,fgs=0, ip=64.170.98.32, so=2009-06-02 17:34:35, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false X-Mirapoint-Loop-Id: c9169f4018214b5547d8cf1c64b7947a A new version of I-D, draft-meng-fan-lock-mib-02.txt has been successfuly submitted by Washam Fan and posted to the IETF repository. Filename: draft-meng-fan-lock-mib Revision: 02 Title: Definitions of Managed Objects for lock via network management protocols Creation_date: 2009-10-23 WG ID: Independent Submission Number_of_pages: 20 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. It describes managed objects used for monitoring locks on a device, The IETF Secretariat. --Boundary_(ID_pH0UM7VAPx6txI+x29PU5w)-- From Minoru.Teraoka@jp.yokogawa.com Sun Oct 25 22:12:19 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C6C3A6405 for ; Sun, 25 Oct 2009 22:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iq2+OGbvTU6L for ; Sun, 25 Oct 2009 22:12:16 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by core3.amsl.com (Postfix) with ESMTP id 92C0F3A67A5 for ; Sun, 25 Oct 2009 22:12:16 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9Q5CSDF000875 for ; Mon, 26 Oct 2009 14:12:28 +0900 (JST) Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.p.ykgw.net [10.0.11.15] (may be forged)) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9Q5BcK1000013 for ; Mon, 26 Oct 2009 14:12:16 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.15]) with mapi; Mon, 26 Oct 2009 14:12:14 +0900 From: To: Date: Mon, 26 Oct 2009 14:12:14 +0900 Thread-Topic: powerconsumption mib Thread-Index: AcpV+uElS3pkZY65QMi7g/u7jgy1sg== Message-ID: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 05:12:19 -0000 Hi all, I have submitted an I-D as follows. http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt The goal of this MIB is the realization of effective reducing power consumption for the router. Currently, the router is able to manage dynamic performance. This MIB is used to monitor the router traffic and power consumption to optimize performance. A new version of I-D,=20 draft-teraoka-powerconsumption-mib-00.txt has been=20 successfuly submitted by Minoru Teraoka and posted to the=20 IETF repository. Filename: draft-teraoka-powerconsumption-mib Revision: 00 Title: Power Consumption MIB for IP forwarding devices Creation_date: 2009-10-18 WG ID: Independent Submission Number_of_pages: 19 Abstract: This memo defines a portion of the Management Information=20 Base (MIB) for use with network management protocols. In=20 particular it defines objects for monitoring power=20 consumption with IP network element that has a function of=20 dynamic performance control. Best regards, Minoru Teraoka From j.schoenwaelder@jacobs-university.de Mon Oct 26 00:24:06 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CABB3A69E1 for ; Mon, 26 Oct 2009 00:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-D92mw9xUlA for ; Mon, 26 Oct 2009 00:24:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1AE3B3A67EA for ; Mon, 26 Oct 2009 00:24:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5D66C001A; Mon, 26 Oct 2009 08:24:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Xhv1AbIdOEty; Mon, 26 Oct 2009 08:24:15 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65478C0014; Mon, 26 Oct 2009 08:24:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 46534D58783; Mon, 26 Oct 2009 08:24:14 +0100 (CET) Date: Mon, 26 Oct 2009 08:24:14 +0100 From: Juergen Schoenwaelder To: "Minoru.Teraoka@jp.yokogawa.com" Message-ID: <20091026072414.GB16670@elstar.local> Mail-Followup-To: "Minoru.Teraoka@jp.yokogawa.com" , "opsawg@ietf.org" References: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "opsawg@ietf.org" Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 07:24:06 -0000 On Mon, Oct 26, 2009 at 06:12:14AM +0100, Minoru.Teraoka@jp.yokogawa.com wrote: > I have submitted an I-D as follows. > > http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt > > The goal of this MIB is the realization of effective reducing power > consumption for the router. Currently, the router is able to manage > dynamic performance. This MIB is used to monitor the router traffic > and power consumption to optimize performance. >From a quick look, it seems the MIB module duplicates parts of the IF-MIB, the ENTITY-MIB and the ENTITY-SENSOR-MIB. I do not see why it is needed; and if there is something not covered by existing MIB modules, it should be built on top of the exiting MIB infrastructure. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From Minoru.Teraoka@jp.yokogawa.com Mon Oct 26 01:40:52 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE443A6906 for ; Mon, 26 Oct 2009 01:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19vwG9QsxU9S for ; Mon, 26 Oct 2009 01:40:49 -0700 (PDT) Received: from zns001-0m9003.yokogawa.co.jp (zns001-0m9003.yokogawa.co.jp [203.174.79.161]) by core3.amsl.com (Postfix) with ESMTP id 70BA53A6774 for ; Mon, 26 Oct 2009 01:40:49 -0700 (PDT) Received: from zns001-0m9003.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9Q8f1aB010223; Mon, 26 Oct 2009 17:41:01 +0900 (JST) Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.p.ykgw.net [10.0.11.15] (may be forged)) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9Q8enSd009895; Mon, 26 Oct 2009 17:41:01 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.15]) with mapi; Mon, 26 Oct 2009 17:40:53 +0900 From: To: Date: Mon, 26 Oct 2009 17:40:46 +0900 Thread-Topic: [OPSAWG] powerconsumption mib Thread-Index: AcpWDV7zKy4r5GX0S8Kr5Wi9mY102gACnacQ Message-ID: <92A5C8A0221B31479EB7913C528ACC5901707C058EE6@EXMAIL01.jp.ykgw.net> References: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net> <20091026072414.GB16670@elstar.local> In-Reply-To: <20091026072414.GB16670@elstar.local> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 08:40:52 -0000 Hi, Thank you for your reply. To each functions of the router, there is a demand to obtain power consumption information. I had wanted to achieve simple MIB intended for the router, it became this composition. The point of this MIB is an information gathering for a plain unit of the router. To prevent a traffic increase, I wanted to avoid the information gathering in each detailed entity.=20 Minoru Teraoka=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Monday, October 26, 2009 4:24 PM > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com) > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] powerconsumption mib >=20 > On Mon, Oct 26, 2009 at 06:12:14AM +0100,=20 > Minoru.Teraoka@jp.yokogawa.com wrote: >=20 > > I have submitted an I-D as follows. > >=20 > > http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt > >=20 > > The goal of this MIB is the realization of effective reducing power=20 > > consumption for the router. Currently, the router is able=20 > to manage=20 > > dynamic performance. This MIB is used to monitor the=20 > router traffic=20 > > and power consumption to optimize performance. >=20 > From a quick look, it seems the MIB module duplicates parts=20 > of the IF-MIB, the ENTITY-MIB and the ENTITY-SENSOR-MIB. I do=20 > not see why it is needed; and if there is something not=20 > covered by existing MIB modules, it should be built on top of=20 > the exiting MIB infrastructure. >=20 > /js >=20 > --=20 > 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 Mon Oct 26 01:48:56 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A723A69D2 for ; Mon, 26 Oct 2009 01:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBwTsWuOl8J4 for ; Mon, 26 Oct 2009 01:48:55 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id BBFD73A6956 for ; Mon, 26 Oct 2009 01:48:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,625,1249272000"; d="scan'208";a="161331810" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Oct 2009 04:49:05 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Oct 2009 04:49:04 -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: Mon, 26 Oct 2009 09:48:41 +0100 Message-ID: In-Reply-To: <92A5C8A0221B31479EB7913C528ACC5901707C058EE6@EXMAIL01.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] powerconsumption mib Thread-Index: AcpWDV7zKy4r5GX0S8Kr5Wi9mY102gACnacQAAApZ+A= References: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net><20091026072414.GB16670@elstar.local> <92A5C8A0221B31479EB7913C528ACC5901707C058EE6@EXMAIL01.jp.ykgw.net> From: "Romascanu, Dan (Dan)" To: , Cc: opsawg@ietf.org Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 08:48:56 -0000 Hi, Inventing new objects and creating a new MIB module for information that is already described another standard MIB modules does not simplify in any way the implementation in the router, and does not reduce the traffic - on the contrary. It is quite reasonable to assume that routers already implement basic ifTable objects for traffic counters. The Entity MIB and Entity Sensor MIB allow for power consumption to be read from a device with a small number of objects.=20 Regards, Dan (speaking as a contributor) > -----Original Message----- > From: opsawg-bounces@ietf.org=20 > [mailto:opsawg-bounces@ietf.org] On Behalf Of=20 > Minoru.Teraoka@jp.yokogawa.com > Sent: Monday, October 26, 2009 10:41 AM > To: j.schoenwaelder@jacobs-university.de > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] powerconsumption mib >=20 > Hi, > Thank you for your reply. >=20 > To each functions of the router, there is a demand to obtain=20 > power consumption information. I had wanted to achieve=20 > simple MIB intended for the router, it became this=20 > composition. The point of this MIB is an information=20 > gathering for a plain unit of the router. > To prevent a traffic increase, I wanted to avoid the=20 > information gathering in each detailed entity.=20 >=20 > Minoru Teraoka=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Monday, October 26, 2009 4:24 PM > > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com) > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] powerconsumption mib > >=20 > > On Mon, Oct 26, 2009 at 06:12:14AM +0100,=20 > > Minoru.Teraoka@jp.yokogawa.com wrote: > >=20 > > > I have submitted an I-D as follows. > > >=20 > > > http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt > > >=20 > > > The goal of this MIB is the realization of effective=20 > reducing power=20 > > > consumption for the router. Currently, the router is able > > to manage > > > dynamic performance. This MIB is used to monitor the > > router traffic > > > and power consumption to optimize performance. > >=20 > > From a quick look, it seems the MIB module duplicates parts of the=20 > > IF-MIB, the ENTITY-MIB and the ENTITY-SENSOR-MIB. I do not=20 > see why it=20 > > is needed; and if there is something not covered by existing MIB=20 > > modules, it should be built on top of the exiting MIB=20 > infrastructure. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From Minoru.Teraoka@jp.yokogawa.com Mon Oct 26 04:20:57 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012A83A67A1 for ; Mon, 26 Oct 2009 04:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFa9ADcDObER for ; Mon, 26 Oct 2009 04:20:55 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by core3.amsl.com (Postfix) with ESMTP id A65E73A6966 for ; Mon, 26 Oct 2009 04:20:55 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9QBL4W5027754; Mon, 26 Oct 2009 20:21:04 +0900 (JST) Received: from zex001-0m9025.jp.ykgw.net (zex001-0m9025.jp.ykgw.net [10.0.11.44]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9QBL2eB027750; Mon, 26 Oct 2009 20:21:03 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9025.jp.ykgw.net ([10.0.11.44]) with mapi; Mon, 26 Oct 2009 20:21:02 +0900 From: To: , Date: Mon, 26 Oct 2009 20:21:01 +0900 Thread-Topic: [OPSAWG] powerconsumption mib Thread-Index: AcpWDV7zKy4r5GX0S8Kr5Wi9mY102gACnacQAAApZ+AABWUdMA== Message-ID: <92A5C8A0221B31479EB7913C528ACC5901707CEBC90B@EXMAIL01.jp.ykgw.net> References: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net><20091026072414.GB16670@elstar.local> <92A5C8A0221B31479EB7913C528ACC5901707C058EE6@EXMAIL01.jp.ykgw.net> In-Reply-To: Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:20:57 -0000 Hi, Thanks for your comment. I am reading the I-D 'draft-quittek-power-monitoring-requirements-00.txt' now. If this scheme can acquire the power consumption and traffic of each module= , it might meet my requirement. Does this contain the item that becomes the change factor of the amount of power consumption? The engine performance is decided by quantity of traffic after all. Regards, Minoru Teraoka=20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Monday, October 26, 2009 5:49 PM > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com);=20 > j.schoenwaelder@jacobs-university.de > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] powerconsumption mib >=20 > Hi, >=20 > Inventing new objects and creating a new MIB module for=20 > information that is already described another standard MIB=20 > modules does not simplify in any way the implementation in=20 > the router, and does not reduce the traffic - on the=20 > contrary. It is quite reasonable to assume that routers=20 > already implement basic ifTable objects for traffic counters.=20 > The Entity MIB and Entity Sensor MIB allow for power=20 > consumption to be read from a device with a small number of objects.=20 >=20 > Regards, >=20 > Dan > (speaking as a contributor) >=20 > > -----Original Message----- > > From: opsawg-bounces@ietf.org > > [mailto:opsawg-bounces@ietf.org] On Behalf Of=20 > > Minoru.Teraoka@jp.yokogawa.com > > Sent: Monday, October 26, 2009 10:41 AM > > To: j.schoenwaelder@jacobs-university.de > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] powerconsumption mib > >=20 > > Hi, > > Thank you for your reply. > >=20 > > To each functions of the router, there is a demand to obtain power=20 > > consumption information. I had wanted to achieve simple=20 > MIB intended=20 > > for the router, it became this composition. The point of=20 > this MIB is=20 > > an information gathering for a plain unit of the router. > > To prevent a traffic increase, I wanted to avoid the information=20 > > gathering in each detailed entity. > >=20 > > Minoru Teraoka > >=20 > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > [mailto:j.schoenwaelder@jacobs-university.de] > > > Sent: Monday, October 26, 2009 4:24 PM > > > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com) > > > Cc: opsawg@ietf.org > > > Subject: Re: [OPSAWG] powerconsumption mib > > >=20 > > > On Mon, Oct 26, 2009 at 06:12:14AM +0100,=20 > > > Minoru.Teraoka@jp.yokogawa.com wrote: > > >=20 > > > > I have submitted an I-D as follows. > > > >=20 > > > > http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt > > > >=20 > > > > The goal of this MIB is the realization of effective > > reducing power > > > > consumption for the router. Currently, the router is able > > > to manage > > > > dynamic performance. This MIB is used to monitor the > > > router traffic > > > > and power consumption to optimize performance. > > >=20 > > > From a quick look, it seems the MIB module duplicates=20 > parts of the=20 > > > IF-MIB, the ENTITY-MIB and the ENTITY-SENSOR-MIB. I do not > > see why it > > > is needed; and if there is something not covered by existing MIB=20 > > > modules, it should be built on top of the exiting MIB > > infrastructure. > > >=20 > > > /js > > >=20 > > > --=20 > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1, 28759=20 > Bremen, Germany > > > Fax: +49 421 200 3103 > > >=20 > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > >=20 > = From hideki.okita.pf@hitachi.com Mon Oct 26 04:32:55 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FFC28C22D for ; Mon, 26 Oct 2009 04:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oofsLcN6gnq9 for ; Mon, 26 Oct 2009 04:32:53 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by core3.amsl.com (Postfix) with ESMTP id 5507628C213 for ; Mon, 26 Oct 2009 04:32:53 -0700 (PDT) Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id CDF6B33CC2; Mon, 26 Oct 2009 20:33:05 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id n9QBX5Z6027295; Mon, 26 Oct 2009 20:33:05 +0900 Received: from hitachi.com (mfbcchk2.hitachi.co.jp [10.201.6.151]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id n9QBS5Po008531; Mon, 26 Oct 2009 20:33:05 +0900 Received: from vshuts3.hitachi.co.jp ([vshuts3.hitachi.co.jp [10.201.6.72]]) by mfbcchk2.hitachi.co.jp with RELAY id n9QBX4R0010496 ; Mon, 26 Oct 2009 20:33:05 +0900 X-AuditID: b753bd60-ab473ba000004725-c2-4ae588f08740 Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 804B8774266; Mon, 26 Oct 2009 20:33:04 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id n9QBX4J25071776; Mon, 26 Oct 2009 20:33:04 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: From: Date: Mon, 26 Oct 2009 20:32:56 +0900 References: <20091021115831.4E2041B524A@newdev.eecs.harvard.edu> Priority: normal Importance: normal X400-Content-Identifier: X4AE588DA00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml28091026203242YEH] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-FMFTCR: RANGEC Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:32:55 -0000 Scott, I'd like to have a slot at the opsawg session in Hiroshima to take a presentation about the update of our network virtulization model. "Virtual Network Management Information Model" http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt Regards, Hideki Okita >please send requests for agenda time slots for the opsawq session in Hiroshima >to the opsawg list asap > >Scott From dromasca@avaya.com Mon Oct 26 04:35:14 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C8928C1CD for ; Mon, 26 Oct 2009 04:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ycmwj5auvrdq for ; Mon, 26 Oct 2009 04:35:13 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 3EF3A28C213 for ; Mon, 26 Oct 2009 04:35:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,625,1249272000"; d="scan'208";a="178156706" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 26 Oct 2009 07:35:25 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Oct 2009 07:35:25 -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: Mon, 26 Oct 2009 12:35:03 +0100 Message-ID: In-Reply-To: <92A5C8A0221B31479EB7913C528ACC5901707CEBC90B@EXMAIL01.jp.ykgw.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] powerconsumption mib Thread-Index: AcpWDV7zKy4r5GX0S8Kr5Wi9mY102gACnacQAAApZ+AABWUdMAAAXUnw References: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net><20091026072414.GB16670@elstar.local> <92A5C8A0221B31479EB7913C528ACC5901707C058EE6@EXMAIL01.jp.ykgw.net> <92A5C8A0221B31479EB7913C528ACC5901707CEBC90B@EXMAIL01.jp.ykgw.net> From: "Romascanu, Dan (Dan)" To: , Cc: opsawg@ietf.org Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 11:35:14 -0000 Hi, See in-line.=20 Regards, Dan (speaking as a contributor)=20 > -----Original Message----- > From: Minoru.Teraoka@jp.yokogawa.com=20 > [mailto:Minoru.Teraoka@jp.yokogawa.com]=20 > Sent: Monday, October 26, 2009 1:21 PM > To: Romascanu, Dan (Dan); j.schoenwaelder@jacobs-university.de > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] powerconsumption mib >=20 > Hi, >=20 > Thanks for your comment. > I am reading the I-D > 'draft-quittek-power-monitoring-requirements-00.txt' now. This is a good start for requirements and description of already existing standards.=20 > If this scheme can acquire the power consumption and traffic=20 > of each module, it might meet my requirement. Does this=20 > contain the item that becomes the change factor of the amount=20 > of power consumption? I am not sure what is the 'this' that you are referring to, and what is exactly the 'change factor of the amount of power consumption'. That you refer to. If there are objects that are not defined in the existing standards MIB modules they could certainly be considered, but I did not see such an object in http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt - maybe I missed it.=20 > The engine performance is decided by quantity of traffic after all. >=20 > Regards, > Minoru Teraoka=20 >=20 From ietfdbh@comcast.net Mon Oct 26 05:51:41 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B233A67DD for ; Mon, 26 Oct 2009 05:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KThHtDhovQWw for ; Mon, 26 Oct 2009 05:51:40 -0700 (PDT) Received: from QMTA13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by core3.amsl.com (Postfix) with ESMTP id 687623A6768 for ; Mon, 26 Oct 2009 05:51:40 -0700 (PDT) Received: from OMTA22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA13.westchester.pa.mail.comcast.net with comcast id xQdp1c0041ap0As5DQru4J; Mon, 26 Oct 2009 12:51:54 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA22.westchester.pa.mail.comcast.net with comcast id xQx41c009284sdk3iQx4d5; Mon, 26 Oct 2009 12:57:04 +0000 From: "David Harrington" To: , References: <20091021115831.4E2041B524A@newdev.eecs.harvard.edu> Date: Mon, 26 Oct 2009 08:51:53 -0400 Message-ID: <063401ca563b$18168a30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcpWMBmEABuhFj1UTdes7fa9rMlzswABd7RA Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:51:41 -0000 Hi, I did a quick read of this document. I have a concern. The IETF decided years ago that a MIB module was the preferred mechanism for explicitly documenting an IETF standards-track data model and (implicitly) the IETF standards-track information model. Once the IETF began to accept that having only one data modeling language (the SMI) might not be adequate, the IETF struggled with the question of "how do we deal with multiple modeling languages?", and we started to pay attention to the distinction between data model and information model. RFC3444 was published as output of the NMRG to help clarify the distinction. The informational model in http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt is similar to the information model that is implicit in the ENTITY-MIB data model design. I would not like to see anybody make the mistake of thinking that this Informational document represents IETF consensus on an information model for managing virtual networks. This document needs to be very clear that the IETF already has consensus on an (implicit) information model for managing physical entities, logicial entities, and the mappings between them. I think defining an information model for the management of virtual networks is very important work, and I think this document really misses an opportunity to help **standardize** how virtual network management systems present information to NMS clients. This document would be terrific if it extracted and documented the information model implicit in the existing IETF standard ENTITY-MIB, and went on to discuss whether the existing information model does or does not meet the needs of real-world implementations/deployments. If the existing implicit information model does meet real-world needs, then I think such a document might become a BCP or an Informational guideline for managing virtual networks. If the existing implicit information does not meet real-world needs, then the document could be a justification for an IETF standards track information model that meets needs better than the current implicit information model. Unfortunately, the current document does not even mention that there is an information model implicit in the ENTITY-MIB standard, which makes me question whether this document should be published as an RFC without a clear statement that it ignores, and may be in conflict with, existing IETF standards. dbh > -----Original Message----- > From: opsawg-bounces@ietf.org > [mailto:opsawg-bounces@ietf.org] On Behalf Of > hideki.okita.pf@hitachi.com > Sent: Monday, October 26, 2009 7:33 AM > To: sob@harvard.edu > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] call for opsawg agenda time requests > > Scott, > > > I'd like to have a slot at the opsawg session in Hiroshima > to take a presentation about the update of our network > virtulization model. > > "Virtual Network Management Information Model" > http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt > > Regards, > > Hideki Okita > > > >please send requests for agenda time slots for the opsawq > session in Hiroshima > >to the opsawg list asap > > > >Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > From dromasca@avaya.com Mon Oct 26 05:59:49 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACFA73A6860 for ; Mon, 26 Oct 2009 05:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbLIgXz6DK2y for ; Mon, 26 Oct 2009 05:59:48 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 764663A67DD for ; Mon, 26 Oct 2009 05:59:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,625,1249272000"; d="scan'208";a="188131336" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Oct 2009 09:00:01 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 26 Oct 2009 09:00:00 -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: Mon, 26 Oct 2009 13:59:51 +0100 Message-ID: In-Reply-To: <063401ca563b$18168a30$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] call for opsawg agenda time requests Thread-Index: AcpWMBmEABuhFj1UTdes7fa9rMlzswABd7RAAAFddxA= References: <20091021115831.4E2041B524A@newdev.eecs.harvard.edu> <063401ca563b$18168a30$0600a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , , Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 12:59:49 -0000 See in-line.=20 Regards, Dan =20 > -----Original Message----- > From: opsawg-bounces@ietf.org=20 > [mailto:opsawg-bounces@ietf.org] On Behalf Of David Harrington > Sent: Monday, October 26, 2009 2:52 PM > To: hideki.okita.pf@hitachi.com; sob@harvard.edu > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] call for opsawg agenda time requests >=20 > Hi, >=20 > I did a quick read of this document. I have a concern. >=20 > The IETF decided years ago that a MIB module was the=20 > preferred mechanism for explicitly documenting an IETF=20 > standards-track data model and (implicitly) the IETF=20 > standards-track information model. >=20 > Once the IETF began to accept that having only one data=20 > modeling language (the SMI) might not be adequate, the IETF=20 > struggled with the question of "how do we deal with multiple=20 > modeling languages?", and we started to pay attention to the=20 > distinction between data model and information model. RFC3444=20 > was published as output of the NMRG to help clarify the distinction. >=20 > The informational model in > http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt is=20 > similar to the information model that is implicit in the=20 > ENTITY-MIB data model design.=20 >=20 > I would not like to see anybody make the mistake of thinking=20 > that this Informational document represents IETF consensus on=20 > an information model for managing virtual networks. This=20 > document needs to be very clear that the IETF already has=20 > consensus on an (implicit) information model for managing=20 > physical entities, logicial entities, and the mappings between them.=20 I share your concerns, but this document is right now no more than an individual submission I-D. Bringing it to the attention of the community is fine, OPSAWG may be the right forum. Only further discussions can enlighten whether it will be submitted as WG item, or other form of document requesting IETF consensus.=20 >=20 > I think defining an information model for the management of=20 > virtual networks is very important work, and I think this=20 > document really misses an opportunity to help **standardize**=20 > how virtual network management systems present information to=20 > NMS clients. This document would be terrific if it extracted=20 > and documented the information model implicit in the existing=20 > IETF standard ENTITY-MIB, and went on to discuss whether the=20 > existing information model does or does not meet the needs of=20 > real-world implementations/deployments.=20 >=20 > If the existing implicit information model does meet=20 > real-world needs, then I think such a document might become a=20 > BCP or an Informational guideline for managing virtual=20 > networks. If the existing implicit information does not meet=20 > real-world needs, then the document could be a justification=20 > for an IETF standards track information model that meets=20 > needs better than the current implicit information model. >=20 > Unfortunately, the current document does not even mention=20 > that there is an information model implicit in the ENTITY-MIB=20 > standard, which makes me question whether this document=20 > should be published as an RFC without a clear statement that=20 > it ignores, and may be in conflict with, existing IETF standards. If this document went through the IETF stream it would be the IETF consensus process that would point to such a problem. If it went through the independent RFC Editor stream the IESG would be the one pointing to such conflicts with an appropriate note.=20 >=20 > dbh >=20 >=20 > > -----Original Message----- > > From: opsawg-bounces@ietf.org > > [mailto:opsawg-bounces@ietf.org] On Behalf Of=20 > > hideki.okita.pf@hitachi.com > > Sent: Monday, October 26, 2009 7:33 AM > > To: sob@harvard.edu > > Cc: opsawg@ietf.org > > Subject: Re: [OPSAWG] call for opsawg agenda time requests > >=20 > > Scott, > >=20 > >=20 > > I'd like to have a slot at the opsawg session in Hiroshima=20 > to take a=20 > > presentation about the update of our network virtulization model. > >=20 > > "Virtual Network Management Information Model" > > http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt > >=20 > > Regards, > >=20 > > Hideki Okita > >=20 > >=20 > > >please send requests for agenda time slots for the opsawq > > session in Hiroshima > > >to the opsawg list asap > > > > > >Scott > > _______________________________________________ > > OPSAWG mailing list > > OPSAWG@ietf.org > > https://www.ietf.org/mailman/listinfo/opsawg > >=20 >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 From ietfdbh@comcast.net Mon Oct 26 06:56:06 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DD333A6A6D for ; Mon, 26 Oct 2009 06:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxsdjNFWKKkZ for ; Mon, 26 Oct 2009 06:56:05 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id C8D513A698A for ; Mon, 26 Oct 2009 06:56:04 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA10.westchester.pa.mail.comcast.net with comcast id xPAo1c00A0ldTLk5ARwKiR; Mon, 26 Oct 2009 13:56:19 +0000 Received: from Harrington73653 ([24.147.240.98]) by OMTA04.westchester.pa.mail.comcast.net with comcast id xRwJ1c00l284sdk3QRwJ7X; Mon, 26 Oct 2009 13:56:19 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , , References: <20091021115831.4E2041B524A@newdev.eecs.harvard.edu> <063401ca563b$18168a30$0600a8c0@china.huawei.com> Date: Mon, 26 Oct 2009 09:56:09 -0400 Message-ID: <069501ca5644$125f49c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcpWMBmEABuhFj1UTdes7fa9rMlzswABd7RAAAFddxAAAL9MgA== Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 13:56:06 -0000 Hi, > I share your concerns, but this document is right now no more than an > individual submission I-D. Bringing it to the attention of > the community > is fine, OPSAWG may be the right forum. Only further discussions can > enlighten whether it will be submitted as WG item, or other form of > document requesting IETF consensus. Which raises another concern. When I saw the email from Hideki, I thought to myself "what, yet another presentation on this work?" Hopefully, the presentation will answer these questions: is this document going to be proposed as an OPSAWG wg item? How is this work relevant to the IETF standards-development function? If it is NOT going to be proposed as a WG item, why is the presentation relevant to this WG? If it is NOT going to be proposed as an IETF document, why is the presentation relevant to the IETF? Maybe this presentation should be targeted at the NMRG. Maybe this presentation should be targeted at a research conference rather than the IETF Standards Development Organization. I normally would not consider such a presentation to be a concern. It is useful to understand other people's thinking on what needs to be operated and managed, especially if it concerns what existing standards are not addressing adequately. For example, Juergen S did a presentation on emerging requirements for low-power applications, and Juergen Q did a presentation on power management. I found them useful presentations that were definitely relevant to (potential) IETF work. But I think this is about six IETFs in a row where we have been treated to presentations from Hideki about his project. I want to understand Hideki's intentions relative to the IETF and OPSAWG. Is the presentation (and paper) actually relevant to work being done in the IETF? Is he proposing that this work be IETF work? The paper's lack of discussion of relevant IETF work (e.g., the ENTITY-MIB) makes me question why the IETF should be repeatedly scheduling Hideki's presentations. The IETF mailing list is deep in discussions about whether we really must have Friday sessions, and whether we are effectively using the time in the sessions that are scheduled. What exactly does this presentation/paper have to do with the WG? What exactly does this presentation/paper have to do with the IETF? What exactly does this presentation/paper have to do with standardizing Internet technologies? dbh From Minoru.Teraoka@jp.yokogawa.com Mon Oct 26 07:39:46 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B60E23A6835 for ; Mon, 26 Oct 2009 07:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLsaU5QrEMbp for ; Mon, 26 Oct 2009 07:39:45 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (zns001-0m9002.yokogawa.co.jp [203.174.79.139]) by core3.amsl.com (Postfix) with ESMTP id AE1643A67F1 for ; Mon, 26 Oct 2009 07:39:45 -0700 (PDT) Received: from zns001-0m9002.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9QEdsDF020917; Mon, 26 Oct 2009 23:39:54 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9002.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9QEdqJo020887; Mon, 26 Oct 2009 23:39:53 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Mon, 26 Oct 2009 23:39:52 +0900 From: To: , Date: Mon, 26 Oct 2009 23:39:51 +0900 Thread-Topic: [OPSAWG] powerconsumption mib Thread-Index: AcpWDV7zKy4r5GX0S8Kr5Wi9mY102gACnacQAAApZ+AABWUdMAAAXUnwAAZYXUU= Message-ID: <92A5C8A0221B31479EB7913C528ACC5901707BDF1CB4@EXMAIL01.jp.ykgw.net> References: <92A5C8A0221B31479EB7913C528ACC5901707CD3B3BA@EXMAIL01.jp.ykgw.net><20091026072414.GB16670@elstar.local> <92A5C8A0221B31479EB7913C528ACC5901707C058EE6@EXMAIL01.jp.ykgw.net> <92A5C8A0221B31479EB7913C528ACC5901707CEBC90B@EXMAIL01.jp.ykgw.net>, In-Reply-To: Accept-Language: en-US, ja-JP Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 14:39:46 -0000 Hi, Sorry for confusion occurred by my remark.=20 Please see in-line. > ________________________________________ > From: Romascanu, Dan (Dan) [dromasca@avaya.com] > Sent: Monday, October 26, 2009 20:35 > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com); j.schoenwaelder@jac= obs-university.de > Cc: opsawg@ietf.org > Subject: RE: [OPSAWG] powerconsumption mib >=20 > Hi, >=20 > See in-line. >=20 > Regards, >=20 > Dan > (speaking as a contributor) >=20 > > -----Original Message----- > > From: Minoru.Teraoka@jp.yokogawa.com > > [mailto:Minoru.Teraoka@jp.yokogawa.com] > > Sent: Monday, October 26, 2009 1:21 PM > > To: Romascanu, Dan (Dan); j.schoenwaelder@jacobs-university.de > > Cc: opsawg@ietf.org > > Subject: RE: [OPSAWG] powerconsumption mib > > > > Hi, > > > > Thanks for your comment. > > I am reading the I-D > > 'draft-quittek-power-monitoring-requirements-00.txt' now. >=20 > This is a good start for requirements and description of already > existing standards. >=20 > > If this scheme can acquire the power consumption and traffic > > of each module, it might meet my requirement. Does this > > contain the item that becomes the change factor of the amount > > of power consumption? >=20 > I am not sure what is the 'this' that you are referring to, and what is > exactly the 'change factor of the amount of power consumption'. That you > refer to. If there are objects that are not defined in the existing > standards MIB modules they could certainly be considered, but I did not > see such an object in > http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt - maybe > I missed it. The 'this' in my comment aimed at 'draft-quittek-power-monitoring-requirements-00.txt', not at my I-D and I wanted to say that there was a cause-and-effect relationship between power consumption and traffic. I thought that I had to know a surplus ability of the entity about the effect of the power saving for the evaluation.=20 Therefore, in my I-D http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt , I defined the following contents. * PconMaxTransferCapacity is a meaning of the maximum transfer performance of the entity.=20 * PconTotalTransferCapacity is a meaning of the transfer performance in a current state.=20 >=20 > > The engine performance is decided by quantity of traffic after all. > > Regards, Minoru Teraoka From Quittek@nw.neclab.eu Mon Oct 26 14:28:24 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC5428C16A for ; Mon, 26 Oct 2009 14:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9ybj5xBhJ52 for ; Mon, 26 Oct 2009 14:28:23 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0BC4D28C181 for ; Mon, 26 Oct 2009 14:28:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 259EA2C0004D6; Mon, 26 Oct 2009 22:28:36 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpJORFrip1uV; Mon, 26 Oct 2009 22:28:35 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id D935A2C0002FE; Mon, 26 Oct 2009 22:28:15 +0100 (CET) Received: from VENUS.office ([192.168.24.102]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 22:28:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Oct 2009 21:28:12 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3339437298_14206195" Date: Mon, 26 Oct 2009 22:28:12 +0100 Message-ID: In-Reply-To: <92A5C8A0221B31479EB7913C528ACC5901707BDF1CB4@EXMAIL01.jp.ykgw.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] powerconsumption mib thread-index: AcpWDV7zKy4r5GX0S8Kr5Wi9mY102gACnacQAAApZ+AABWUdMAAAXUnwAAZYXUUADHzXsA== From: "Juergen Quittek" To: , "Dan Romascanu" , "Juergen Schoenwaelder" X-OriginalArrivalTime: 26 Oct 2009 21:28:12.0783 (UTC) FILETIME=[38D777F0:01CA5683] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 21:28:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339437298_14206195 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Minoru, Thank you for contributing to the effort of developing power monitoring standards. There are already several existing MIB modules. Besides the one you describe in your draft there is a prototype implementation (http://www.csee.usf.edu/~christen/energy/lcn08_2_proceedings.pdf) and least two proprietary industrial MIB modules. Instead of contributing all of them as individual Internet drafts and then trying to merge them, we started collecting requirements from all existing approaches first and collected them in draft-quittek-power-monitoring-requirements. I would appreciate to receive your comments, suggestions and contributions. After agreeing on a set of requirements, we can jointly look at what is already available, such as the entity MIB module, and what would still be needed to meet the requirements. Best regards, Juergen On 26.10.09 15:39 "Minoru.Teraoka@jp.yokogawa.com" wrote: > Hi, > > Sorry for confusion occurred by my remark. > Please see in-line. > > >> ________________________________________ >> From: Romascanu, Dan (Dan) [dromasca@avaya.com] >> Sent: Monday, October 26, 2009 20:35 >> To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com); >> j.schoenwaelder@jacobs-university.de >> Cc: opsawg@ietf.org >> Subject: RE: [OPSAWG] powerconsumption mib >> >> Hi, >> >> See in-line. >> >> Regards, >> >> Dan >> (speaking as a contributor) >> >>> -----Original Message----- >>> From: Minoru.Teraoka@jp.yokogawa.com >>> [mailto:Minoru.Teraoka@jp.yokogawa.com] >>> Sent: Monday, October 26, 2009 1:21 PM >>> To: Romascanu, Dan (Dan); j.schoenwaelder@jacobs-university.de >>> Cc: opsawg@ietf.org >>> Subject: RE: [OPSAWG] powerconsumption mib >>> >>> Hi, >>> >>> Thanks for your comment. >>> I am reading the I-D >>> 'draft-quittek-power-monitoring-requirements-00.txt' now. >> >> This is a good start for requirements and description of already >> existing standards. >> >>> If this scheme can acquire the power consumption and traffic >>> of each module, it might meet my requirement. Does this >>> contain the item that becomes the change factor of the amount >>> of power consumption? >> >> I am not sure what is the 'this' that you are referring to, and what is >> exactly the 'change factor of the amount of power consumption'. That you >> refer to. If there are objects that are not defined in the existing >> standards MIB modules they could certainly be considered, but I did not >> see such an object in >> http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt - maybe >> I missed it. > > > The 'this' in my comment aimed at > 'draft-quittek-power-monitoring-requirements-00.txt', > not at my I-D and I wanted to say that there was a cause-and-effect > relationship between power consumption and traffic. > > I thought that I had to know a surplus ability of the entity about the > effect of the power saving for the evaluation. > Therefore, in my I-D > http://www.ietf.org/id/draft-teraoka-powerconsumption-mib-00.txt , > I defined the following contents. > * PconMaxTransferCapacity is a meaning of the maximum transfer > performance of the entity. > * PconTotalTransferCapacity is a meaning of the transfer performance > in a current state. > > >> >>> The engine performance is decided by quantity of traffic after all. >>> > > > > Regards, > Minoru Teraoka > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --B_3339437298_14206195 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBSeFLHmO3rk5lO812mr /jmpZMhKHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjYyMDI4MTdaMA0GCSqGSIb3DQEBAQUABIIBALI0DidDHv88ks0n95vo/h9r6+e8zAmsMUmX zACMidabH35Gc8v85YqbHbZ1yZx6qB5dIaf0uUCKQ4Az+wiLqYeKSR8RnI41YT1OWN32VZs5 Va92q7qIqdXpBi3aOLgGrDW0JSD5RWxfqIkxnKr747EL1yspAkkypLwcPAEq8jxmz51Q2PC5 WGv7wSGSjo+LsYt82bKnYyLal4H83kULI/X5e4ieNjfBawPgi8JUouQSPBZbXGoBUP3kuQvg QYr4tibBoYlwrCBQkqd4q0aHDgZGpq5X6HYpfM6Qz1UqYA1MR8GLHD3E5jkTB36/IILZcXxc ckaRVX5Hf9TstiiIHWg= --B_3339437298_14206195-- From sob@harvard.edu Mon Oct 26 17:31:04 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70D8F3A6861 for ; Mon, 26 Oct 2009 17:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.242 X-Spam-Level: X-Spam-Status: No, score=-1.242 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyndsKp+nPr8 for ; Mon, 26 Oct 2009 17:31:03 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 733433A6963 for ; Mon, 26 Oct 2009 17:31:03 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id E2D3D1C8116; Mon, 26 Oct 2009 20:31:16 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20091027003116.E2D3D1C8116@newdev.eecs.harvard.edu> Date: Mon, 26 Oct 2009 20:31:16 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [OPSAWG] draft agenda for opsawg X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 00:31:04 -0000 I posted a draft agenda for the opsawg session in Japan comments/suggestions to the list asap Scott From Minoru.Teraoka@jp.yokogawa.com Mon Oct 26 19:16:14 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B203A6890 for ; Mon, 26 Oct 2009 19:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.904 X-Spam-Level: X-Spam-Status: No, score=0.904 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G0VUl4JlfcD for ; Mon, 26 Oct 2009 19:16:13 -0700 (PDT) Received: from zns001-0m9003.yokogawa.co.jp (zns001-0m9003.yokogawa.co.jp [203.174.79.161]) by core3.amsl.com (Postfix) with ESMTP id A65843A6824 for ; Mon, 26 Oct 2009 19:16:13 -0700 (PDT) Received: from zns001-0m9003.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9R2GPaB013664; Tue, 27 Oct 2009 11:16:25 +0900 (JST) Received: from zex001-0m9026.jp.ykgw.net (zex001-0m9026.p.ykgw.net [10.0.11.15] (may be forged)) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id n9R2GOSB013648; Tue, 27 Oct 2009 11:16:25 +0900 (JST) Received: from EXMAIL01.jp.ykgw.net ([10.0.11.27]) by zex001-0m9026.jp.ykgw.net ([10.0.11.15]) with mapi; Tue, 27 Oct 2009 11:16:25 +0900 From: To: Date: Tue, 27 Oct 2009 11:16:23 +0900 Thread-Topic: [OPSAWG] powerconsumption mib Thread-Index: AcpWDV7zKy4r5GX0S8Kr5Wi9mY102gACnacQAAApZ+AABWUdMAAAXUnwAAZYXUUADHzXsAAMCEJg Message-ID: <92A5C8A0221B31479EB7913C528ACC5901707CEBC97E@EXMAIL01.jp.ykgw.net> References: <92A5C8A0221B31479EB7913C528ACC5901707BDF1CB4@EXMAIL01.jp.ykgw.net> In-Reply-To: Accept-Language: en-US, ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, ja-JP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] powerconsumption mib X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 02:16:14 -0000 Dear Juergen, Thank you for your reply. I thought that your approach about the power monitoring is appropriate. http://www.ietf.org/id/draft-quittek-power-monitoring-requirements-00.txt I also have some requirements such as related to the traffic for power monitoring. If possible, I would like to cooperate with you. Best regards, Minoru > -----Original Message----- > From: Juergen Quittek [mailto:Quittek@nw.neclab.eu]=20 > Sent: Tuesday, October 27, 2009 6:28 AM > To: Teraoka, Minoru (Minoru.Teraoka@jp.yokogawa.com); Dan=20 > Romascanu; Juergen Schoenwaelder > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] powerconsumption mib >=20 > Dear Minoru, >=20 > Thank you for contributing to the effort of developing power=20 > monitoring standards. There are already several existing MIB=20 > modules. Besides the one you describe in your draft there is=20 > a prototype implementation > (http://www.csee.usf.edu/~christen/energy/lcn08_2_proceedings.pdf) > and least two proprietary industrial MIB modules. >=20 > Instead of contributing all of them as individual Internet=20 > drafts and then trying to merge them, we started collecting=20 > requirements from all existing approaches first and collected=20 > them in draft-quittek-power-monitoring-requirements. I would=20 > appreciate to receive your comments, suggestions and contributions. >=20 > After agreeing on a set of requirements, we can jointly look=20 > at what is already available, such as the entity MIB module,=20 > and what would still be needed to meet the requirements. >=20 > Best regards, >=20 > Juergen =20 >=20 From talmi@marvell.com Tue Oct 27 04:33:49 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735443A684E for ; Tue, 27 Oct 2009 04:33:49 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vudZ9Nh9jUPU for ; Tue, 27 Oct 2009 04:33:43 -0700 (PDT) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by core3.amsl.com (Postfix) with ESMTP id CB2ED3A681D for ; Tue, 27 Oct 2009 04:33:42 -0700 (PDT) From: Tal Mizrahi To: "opsawg@ietf.org" Date: Tue, 27 Oct 2009 13:34:00 +0200 Thread-Topic: Re: [OPSAWG] draft-mizrahi-opsawg-oam-overview-00 Thread-Index: AcpW+WDWqOwz7YTKRMOaFS6nLGOVaA== Message-ID: <74470498B659FA4687F0B0018C19A89CAA88AD9DD1@IL-MB01.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_74470498B659FA4687F0B0018C19A89CAA88AD9DD1ILMB01marvell_" MIME-Version: 1.0 Subject: Re: [OPSAWG] draft-mizrahi-opsawg-oam-overview-00 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 11:33:49 -0000 --_000_74470498B659FA4687F0B0018C19A89CAA88AD9DD1ILMB01marvell_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, Since OAM was developed in many parallel paths, some of the mechanisms and = terminology, as you say, were inherited from SONET or ATM, while others wer= e developed for IP / Ethernet networks. I believe, indeed that the IETF sho= uld adopt a consistent OAM architecture for various transport types, but th= e current document does not intend to do this. Indeed, the intent of this document is to provide a brief summary and a com= parison of existing OAM mechanisms, emphasizing the differences in terminol= ogy and in functionality. With all the OAM chaos that we are up against the= se days, it feels like such a document is necessary. Regards, Tal. Tal, What is the intent of this document? If it is merely to exchange information between SDO's, that's fine. However, I think that you could take this document a step further. You could use this document to frame a conversation about which OAM capabilities the IETF should develop and which they should avoid. For example, in Section 3.2.4, you distinguish between a failure, a fault and a defect. In a connection oriented-environment, like SONET, where bandwidth is reserved even when it is not being used, it makes sense to manage all three. It also makes sense for the OAM mechanism to be built into the protocol, as they are in SONET. However, it is possible that neither assumption is true for statistically multiplexed, connectionless environments like IP or Ethernet. If you want to broaden the scope of your document, you might want to explore these issues. Ron /speaking as individual contributor > > Title : An Overview of Operations, > Administration, and Maintenance (OAM) Mechanisms > Author(s) : T. Mizrahi > Filename : draft-mizrahi-opsawg-oam-overview-00.txt > Pages : 22 > Date : 2009-10-07 > > Operations, Administration, and Maintenance (OAM) is a general term > that refers to detecting and reporting link failures. OAM mechanisms > have been defined for various layers in the protocol stack, and are > used with a variety of protocols. > > This document presents an overview of the OAM mechanisms that have > been defined and are currently being defined by the IETF, as well as > a comparison to other OAM mechanisms that have been defined by the > IEEE and ITU-T. ________________________________ Tal Mizrahi, Marvell, Switching - Product Definition Architect Email: talmi@marvell.com Office: +972.4.9091539 This message may contain confidential, proprietary or legally privileged in= formation. The information is intended only for the use of the individual o= r entity named above. If the reader of this message is not the intended rec= ipient, you are hereby notified that any dissemination, distribution or cop= ying of this communication is strictly prohibited. If you have received thi= s communication in error, please notify us immediately by telephone or by e= -mail and delete the message from your computer. ________________________________ --_000_74470498B659FA4687F0B0018C19A89CAA88AD9DD1ILMB01marvell_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,

 

Since OAM was developed in many parallel paths, some of = the mechanisms and terminology, as you say, were inherited from SONET or ATM, w= hile others were developed for IP / Ethernet networks. I believe, indeed that th= e IETF should adopt a consistent OAM architecture for various transport types= , but the current document does not intend to do this.

Indeed, the intent of this document is to provide a brie= f summary and a comparison of existing OAM mechanisms, emphasizing the differences in terminology and in functionality. With all the OAM chaos tha= t we are up against these days, it feels like such a document is necessary.=

 

Regards,

Tal.

 

 

 

 

 

 

 

 

 

 

 

 

T=
al,
 <=
/o:p>
What is the =
intent of this document? If it is merely to exchange
information =
between SDO's, that's fine. However, I think that you could
take this do=
cument a step further. You could use this document to frame
a conversati=
on about which OAM capabilities the IETF should develop and
which they s=
hould avoid.
 <=
/o:p>
For example,=
 in Section 3.2.4, you distinguish between a failure, a
fault and a =
defect. In a connection oriented-environment, like SONET,=

where bandwi=
dth is reserved even when it is not being used, it makes<=
/font>
sense to man=
age all three. It also makes sense for the OAM mechanism to
be built int=
o the protocol, as they are in SONET.
 <=
/o:p>
However, it =
is possible that neither assumption is true for
statisticall=
y multiplexed, connectionless environments like IP or
Ethernet. If=
 you want to broaden the scope of your document, you might
want to expl=
ore these issues.
 <=
/o:p>
  =
            &nb=
sp;            =
       Ron
  =
            &nb=
sp;            =
      /speaking as individual contributor
 <=
/o:p>
 <=
/o:p>
 <=
/o:p>
 <=
/o:p>
>&nb=
sp;
>  &=
nbsp;    Title       &nbs=
p;   : An Overview of Operations,
<= pre>> Adminis= tration, and Maintenance (OAM) Mechanisms>  &= nbsp;    Author(s)       : T. = Mizrahi
>  &=
nbsp;    Filename        =
: draft-mizrahi-opsawg-oam-overview-00.txt
>  &= nbsp;    Pages       &nbs= p;   : 22
>  &=
nbsp;    Date        =
;    : 2009-10-07
>&nb=
sp;
> Operati=
ons, Administration, and Maintenance (OAM) is a general term
> that re=
fers to detecting and reporting link failures. OAM mechanisms
> have be=
en defined for various layers in the protocol stack, and are
> used wi=
th a variety of protocols.
>&nb=
sp;
> This do=
cument presents an overview of the OAM mechanisms that have
> been de=
fined and are currently being defined by the IETF, as well as
> a compa=
rison to other OAM mechanisms that have been defined by the
> IEEE an=
d ITU-T.
 <=
/o:p>

 

Tal Mizrahi, Marvell, Switching – Product Definition Architect
Email: talmi@marvell.com
Office: +972.4.9091539

This message may contain confidential, proprietary or legally privileged information. The informatio= n is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notifi= ed that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, plea= se notify us immediately by telephone or by e-mail and delete the message from your computer.<= span style=3D'font-size:10.0pt;font-family:Arial'>

 

--_000_74470498B659FA4687F0B0018C19A89CAA88AD9DD1ILMB01marvell_-- From Quittek@nw.neclab.eu Tue Oct 27 08:36:36 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6753A6858 for ; Tue, 27 Oct 2009 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuV7DZ77sW3I for ; Tue, 27 Oct 2009 08:36:35 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 5B0A23A6359 for ; Tue, 27 Oct 2009 08:36:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id A90AE2C019172; Tue, 27 Oct 2009 16:36:47 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AA-5oiLISabZ; Tue, 27 Oct 2009 16:36:47 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id 6F0EF2C0002FC; Tue, 27 Oct 2009 16:36:27 +0100 (CET) Received: from VENUS.office ([192.168.24.102]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 16:36:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Tue, 27 Oct 2009 15:36:27 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3339502360_15460830" Date: Tue, 27 Oct 2009 16:36:27 +0100 Message-ID: In-Reply-To: <063401ca563b$18168a30$0600a8c0@china.huawei.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] call for opsawg agenda time requests thread-index: AcpWMBmEABuhFj1UTdes7fa9rMlzswABd7RAADcXdUw= From: "Juergen Quittek" To: "David Harrington" , , "Scott O. Bradner" X-OriginalArrivalTime: 27 Oct 2009 15:36:27.0444 (UTC) FILETIME=[3F7E0F40:01CA571B] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 15:36:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339502360_15460830 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I also had a look at the draft and I think that the basic idea of mapping virtual to real resources is very good. Can't we easily align the draft with the ENTITY MIB data model? I could imagine a MIB module based on the ENTITY MIB that realizes the information model for virtual entities in SMI. Juergen On 26.10.09 13:51 "David Harrington" wrote: > Hi, > > I did a quick read of this document. I have a concern. > > The IETF decided years ago that a MIB module was the preferred > mechanism for explicitly documenting an IETF standards-track data > model and (implicitly) the IETF standards-track information model. > > Once the IETF began to accept that having only one data modeling > language (the SMI) might not be adequate, the IETF struggled with the > question of "how do we deal with multiple modeling languages?", and we > started to pay attention to the distinction between data model and > information model. RFC3444 was published as output of the NMRG to help > clarify the distinction. > > The informational model in > http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt is similar to > the information model that is implicit in the ENTITY-MIB data model > design. > > I would not like to see anybody make the mistake of thinking that this > Informational document represents IETF consensus on an information > model for managing virtual networks. This document needs to be very > clear that the IETF already has consensus on an (implicit) information > model for managing physical entities, logicial entities, and the > mappings between them. > > I think defining an information model for the management of virtual > networks is very important work, and I think this document really > misses an opportunity to help **standardize** how virtual network > management systems present information to NMS clients. This document > would be terrific if it extracted and documented the information model > implicit in the existing IETF standard ENTITY-MIB, and went on to > discuss whether the existing information model does or does not meet > the needs of real-world implementations/deployments. > > If the existing implicit information model does meet real-world needs, > then I think such a document might become a BCP or an Informational > guideline for managing virtual networks. If the existing implicit > information does not meet real-world needs, then the document could be > a justification for an IETF standards track information model that > meets needs better than the current implicit information model. > > Unfortunately, the current document does not even mention that there > is an information model implicit in the ENTITY-MIB standard, which > makes me question whether this document should be published as an RFC > without a clear statement that it ignores, and may be in conflict > with, existing IETF standards. > > dbh > > >> -----Original Message----- >> From: opsawg-bounces@ietf.org >> [mailto:opsawg-bounces@ietf.org] On Behalf Of >> hideki.okita.pf@hitachi.com >> Sent: Monday, October 26, 2009 7:33 AM >> To: sob@harvard.edu >> Cc: opsawg@ietf.org >> Subject: Re: [OPSAWG] call for opsawg agenda time requests >> >> Scott, >> >> >> I'd like to have a slot at the opsawg session in Hiroshima >> to take a presentation about the update of our network >> virtulization model. >> >> "Virtual Network Management Information Model" >> http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt >> >> Regards, >> >> Hideki Okita >> >> >>> please send requests for agenda time slots for the opsawq >> session in Hiroshima >>> to the opsawg list asap >>> >>> Scott >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --B_3339502360_15460830 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBTvNRniqL4vN+gOO1eB CFZB2uXezjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjcxNDMyNDBaMA0GCSqGSIb3DQEBAQUABIIBAGzii4fEZY2xNssxT2LOF3XvnZSAOYs3cOqC OXXzB3EH0U2q47HPX3vp9CpVr8co3XZ9YcD7oZ2P+v/7zwVdNhOPT4TEZCMtruCkY0IrwLMd QWhZI2ZQyHvUXNrXk1Mt2r4SzFne+acfAxMpsUz3OVvnI490ofdzFQaiOIgnlp/PaVX7duPM /ypXpoUpgWnOGk3Pj6r+sIsEysZa9iEt9if0XIZ/+4Jso0FS1xkefwLnEKaiQKFsomvnyJJd yGEil9BApqaGbh8vgCvBJWfxKQeldZLgD1xVOa0xbWEwM5beme6/qDMvK2VQwPuTwoPZINHh AGINhZmFOGQaG2og00E= --B_3339502360_15460830-- From rbonica@juniper.net Tue Oct 27 12:40:05 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA0828C112 for ; Tue, 27 Oct 2009 12:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQzVXmX33+xA for ; Tue, 27 Oct 2009 12:40:04 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id 669813A68A6 for ; Tue, 27 Oct 2009 12:39:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKSudMm+uB97+D1t1r3MIKwgGRR5MncZJG@postini.com; Tue, 27 Oct 2009 12:40:19 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 27 Oct 2009 12:35:25 -0700 Received: from [172.28.134.74] (172.28.134.74) by p-emfe02-wf.jnpr.net (172.28.145.22) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 27 Oct 2009 15:35:24 -0400 Message-ID: <4AE74B7B.4030305@juniper.net> Date: Tue, 27 Oct 2009 15:35:23 -0400 From: Ron Bonica User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "opsawg@ietf.org" , "Romascanu, Dan (Dan)" , Scott O Bradner , Chris Liljenstolpe X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: [OPSAWG] Organizational Announcement X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 19:40:05 -0000 Folks, After three years of service, Ted Seely will be stepping down as co-chairman of the OPSAREA WG. I would like to thank Ted for his service and say that we all look forward to working with him on other IETF endeavors. Chris Liljenstolpe will be replace Ted, sharing responsibility for the group with Scott Bradner. Please join me in welcoming Chris. Ron and Dan From hideki.okita.pf@hitachi.com Tue Oct 27 19:41:28 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6493A683B for ; Tue, 27 Oct 2009 19:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTELcxHIEh-t for ; Tue, 27 Oct 2009 19:41:27 -0700 (PDT) Received: from mail9.hitachi.co.jp (mail9.hitachi.co.jp [133.145.228.44]) by core3.amsl.com (Postfix) with ESMTP id E9EB63A6903 for ; Tue, 27 Oct 2009 19:41:25 -0700 (PDT) Received: from mlsv7.hitachi.co.jp (unknown [133.144.234.166]) by mail9.hitachi.co.jp (Postfix) with ESMTP id 3279037C8B; Wed, 28 Oct 2009 11:41:40 +0900 (JST) Received: from mfilter2.hitachi.co.jp by mlsv7.hitachi.co.jp (8.13.1/8.13.1) id n9S2feNr020393; Wed, 28 Oct 2009 11:41:40 +0900 Received: from hitachi.com (mfbcchk3.hitachi.co.jp [10.201.6.152]) by mfilter2.hitachi.co.jp (Switch-3.3.2/Switch-3.3.2) with ESMTP id n9RNR55N016062; Wed, 28 Oct 2009 11:41:39 +0900 Received: from vshuts3.hitachi.co.jp ([vshuts3.hitachi.co.jp [10.201.6.72]]) by mfbcchk3.hitachi.co.jp with RELAY id n9S2fcAL018751 ; Wed, 28 Oct 2009 11:41:39 +0900 X-AuditID: b753bd60-a9670ba000004725-d1-4ae7af62fa7b Received: from gmml25.itg.hitachi.co.jp (unknown [158.213.165.145]) by vshuts3.hitachi.co.jp (Symantec Mail Security) with ESMTP id 96E87774264; Wed, 28 Oct 2009 11:41:38 +0900 (JST) Received: from [127.0.0.1] by gmml25.itg.hitachi.co.jp (AIX5.2/8.11.6p2/8.11.0) id n9S2fcd7733346; Wed, 28 Oct 2009 11:41:38 +0900 Message-Type: Multiple Part MIME-Version: 1.0 Message-ID: Content-Type: text/plain; charset=us-ascii To: , , From: Date: Wed, 28 Oct 2009 11:41:17 +0900 References: <063401ca563b$18168a30$0600a8c0@china.huawei.com> Priority: normal Importance: normal X400-Content-Identifier: X4AE7AF2B00000M X400-MTS-Identifier: [/C=JP/ADMD=HITNET/PRMD=HITACHI/;gmml280910281140432ZF] Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== X-FMFTCR: RANGEC Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 02:41:28 -0000 David, Dan, Juergen, Thank you so much for your reviews and comments. First, please let me summarize David's concerns. Please tell me if I have any misunderstanding. 1. The proposed model seems similar to the information model implicitly defined in the existing ENTITY-MIB. 2. The draft does not mention the relationship between the proposed model and the ENTITY-MIB. 3. The draft lacks the concrete definition how the NMS presents the virtual network information to NMS clients. For the first concern, I examined the ENTITY-MIB since I have not considered it. I checked RFC 4133 and implementation by a router. Then, I found that our model have a similarity with the ENTITY-MIB. Both of following objects describe the structure of a physical entity. - entPhysicalTable and entPhysicalContainsTable in the ENTITY-MIB - PhysicalNode, PhysicalNodeGroup, and PhysicalInterface in our model. However, IMO, the model of the ENTITY-MIB is insufficient to manage virtual networks in data centers from following reasons. a. ENTITY-MIB does not have connection objects for describing the connections between physical nodes. b. ENTITY-MIB does not have connection objects for describing the connections between virtual nodes, for example, the connection between a virtual switch and virtual machines on a physical server. c. ENTITY-MIB does not have virtual-virtual relationship objects for describing the structure of a virtual entity. Therefore, I'd like to propose our model as an solution and opsawg's new work. For the second concern, I'd like to add a "relationship to the ENTITY-MIB" section that describes above distinction to our draft. For the third concern, I can add a section about a MIB module or an XML schema to our draft to describe the concrete datamodel. Best regards, Hideki Okita >I also had a look at the draft and I think that the basic idea >of mapping virtual to real resources is very good. > >Can't we easily align the draft with the ENTITY MIB data model? > >I could imagine a MIB module based on the ENTITY MIB that realizes >the information model for virtual entities in SMI. > > Juergen > > >On 26.10.09 13:51 "David Harrington" wrote: > >> Hi, >> >> I did a quick read of this document. I have a concern. >> >> The IETF decided years ago that a MIB module was the preferred >> mechanism for explicitly documenting an IETF standards-track data >> model and (implicitly) the IETF standards-track information model. >> >> Once the IETF began to accept that having only one data modeling >> language (the SMI) might not be adequate, the IETF struggled with the >> question of "how do we deal with multiple modeling languages?", and we >> started to pay attention to the distinction between data model and >> information model. RFC3444 was published as output of the NMRG to help >> clarify the distinction. >> >> The informational model in >> http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt is similar to >> the information model that is implicit in the ENTITY-MIB data model >> design. >> >> I would not like to see anybody make the mistake of thinking that this >> Informational document represents IETF consensus on an information >> model for managing virtual networks. This document needs to be very >> clear that the IETF already has consensus on an (implicit) information >> model for managing physical entities, logicial entities, and the >> mappings between them. >> >> I think defining an information model for the management of virtual >> networks is very important work, and I think this document really >> misses an opportunity to help **standardize** how virtual network >> management systems present information to NMS clients. This document >> would be terrific if it extracted and documented the information model >> implicit in the existing IETF standard ENTITY-MIB, and went on to >> discuss whether the existing information model does or does not meet >> the needs of real-world implementations/deployments. >> >> If the existing implicit information model does meet real-world needs, >> then I think such a document might become a BCP or an Informational >> guideline for managing virtual networks. If the existing implicit >> information does not meet real-world needs, then the document could be >> a justification for an IETF standards track information model that >> meets needs better than the current implicit information model. >> >> Unfortunately, the current document does not even mention that there >> is an information model implicit in the ENTITY-MIB standard, which >> makes me question whether this document should be published as an RFC >> without a clear statement that it ignores, and may be in conflict >> with, existing IETF standards. >> >> dbh >> >> >>> -----Original Message----- >>> From: opsawg-bounces@ietf.org >>> [mailto:opsawg-bounces@ietf.org] On Behalf Of >>> hideki.okita.pf@hitachi.com >>> Sent: Monday, October 26, 2009 7:33 AM >>> To: sob@harvard.edu >>> Cc: opsawg@ietf.org >>> Subject: Re: [OPSAWG] call for opsawg agenda time requests >>> >>> Scott, >>> >>> >>> I'd like to have a slot at the opsawg session in Hiroshima >>> to take a presentation about the update of our network >>> virtulization model. >>> >>> "Virtual Network Management Information Model" >>> http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt >>> >>> Regards, >>> >>> Hideki Okita >>> >>> >>>> please send requests for agenda time slots for the opsawq >>> session in Hiroshima >>>> to the opsawg list asap >>>> >>>> Scott From j.schoenwaelder@jacobs-university.de Wed Oct 28 04:00:35 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141553A6909 for ; Wed, 28 Oct 2009 04:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.497, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCshvL3pjML7 for ; Wed, 28 Oct 2009 04:00:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 52B063A6908 for ; Wed, 28 Oct 2009 04:00:33 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BD77C002B; Wed, 28 Oct 2009 12:00:48 +0100 (CET) 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 6amkBKecCX4J; Wed, 28 Oct 2009 12:00:46 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DA04C0029; Wed, 28 Oct 2009 12:00:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1D77BD5C6A7; Wed, 28 Oct 2009 12:00:44 +0100 (CET) Date: Wed, 28 Oct 2009 12:00:44 +0100 From: Juergen Schoenwaelder To: RFC Errata System Message-ID: <20091028110044.GA19229@elstar.local> Mail-Followup-To: RFC Errata System , "alex@cisco.com" , "akarmaka@cisco.com" , "dromasca@avaya.com" , "rbonica@juniper.net" , "sob@harvard.edu" , "ted.a.seely@sprint.com" , "ah@TR-Sys.de" , "opsawg@ietf.org" References: <200910231939.n9NJdmMr006579@boreas.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910231939.n9NJdmMr006579@boreas.isi.edu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "ah@TR-Sys.de" , "akarmaka@cisco.com" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 11:00:35 -0000 On Fri, Oct 23, 2009 at 09:39:48PM +0200, RFC Errata System wrote: > The following errata report has been submitted for RFC5676, > "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1928 > > -------------------------------------- > Type: Technical > Reported by: Alfred Hoenes I am trying to understand the errata and so I might stupid questions. Since you report two independent defects, it might have been useful to have two errata posted. I have no clue whether the errata tracker allows to make such changes now. > Section: 7, pg. 7 > > Original Text > ------------- > SyslogTimeStamp ::= TEXTUAL-CONVENTION > ! DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d" What does the '!' mark imply here? > STATUS current > DESCRIPTION > "A date-time specification. This type is similar to the > DateAndTime type defined in the SNMPv2-TC, except the > subsecond granulation is microseconds instead of > deciseconds and a zero-length string can be used > to indicate a missing value. > > field octets contents range > ----- ------ -------- ----- > | 1 1-2 year* 0..65536 > 2 3 month 1..12 > 3 4 day 1..31 > 4 5 hour 0..23 > 5 6 minutes 0..59 > 6 7 seconds 0..60 > (use 60 for leap-second) > ! 7 8-10 microseconds* 0..999999 Again, it is not clear to me what this ! mark tries to convey. > 8 11 direction from UTC '+' / '-' > 9 12 hours from UTC* 0..13 > 10 13 minutes from UTC 0..59 > > * Notes: > - the value of year is in network-byte order > | - the value of microseconds is in network-byte order > - daylight saving time in New Zealand is +13 > > For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be > displayed as: > > 1992-5-26,13:30:15.0,-4:0 > > Note that if only local time is known, then timezone > information (fields 11-13) is not present." > SYNTAX OCTET STRING (SIZE (0 | 10 | 13)) > > > Corrected Text > -------------- > (a) upper part of the table: > > field octets contents range > ----- ------ -------- ----- > | 1 1-2 year* 0..32767 > ... > > (b) "*Notes:" part: > > << see Notes below -- one possibility to address the issue is > amending the text as follows; verifiers might do better >> > > * Notes: > - the value of year is in network-byte order > | - the value of microseconds is in network-byte order; > | users of network management applications following > | the DISPLAY-HINT specified above should be aware of > | the unusual appearance of the apparent 'fractional part' > | displayed: RFC 2579 requires the leading zeros to be > | omitted; thus a time component diaplayed as '13:30:15.50' > | does not indicate 50 centiseconds, but 50 microseconds > | past the full second! > - daylight saving time in New Zealand is +13 > > > Notes > ----- > (a) > > Section 3.1 of RFC 2579 (on page 21) states, regarding numerical > conversion descriptor components in DISPLAY-HINTS: > > [...] For all types, when rendering a value, leading > zeros are omitted, and for negative values, a minus sign is rendered > immediately before the digits. [...] > > Arguably, this means that substrings of OCTET STRING type are > interpreted as *signed* values (in network byte order). > Therefore, the range restriction for the 'year' part specified > informally in the DESCRIPTION clause does not make proper sense; > an upper bound of 65536 is nonsensical anyway since a 2-octet > substring cannot assme 65537 different values; to avoid issues > with different interpretation of RFC 2579, the 'safe' range > 0..32767 is recommended -- this should not be a serious restriction > in practice. Hm. The text you quote is the definition of 'd' for INTEGER typed DISPLAY-HINTs. Given the absence of a definition of 'd' for OCTET STRING types DISPLAY-HINTs, it is not really clear what RFC 2579 intended. If your interpretation is right that numbers are signed, then we have similar problems in other documents, e.g. RFC 2579's definition of DateAndTime. > (b) > > WARNING: > > According to Section 3.1 of RFC 2579, the components of the > DISPLAY-HINTS string describe the *independent* formatting of > substrings of the OCTET STRING (in this case). > Thus, the display instructions for the conceptional 'seconds' > part of the OCTET STRING, "1d.3d", actually describes the > independent formatting of a 1-octet and a 3-octet substring > (in network byte order) as decimal integers without leading > zeros, separated by a literal period ('.') -- a "display > separator character" in RFC 2579 terms --, and not the > human-friendly formatting of a single fixed-point fractional > number; there is no concept of a decimal fraction representation > in this notation. > So the presentation format will be very different from common > practice for human beings. See the example below. > The "fixed-point with decimal sign" representation from > RFC 2579 is only available for INTEGER values, for cases with > scaled values, where the conceptual integer and fractional part > are stored as a single integer in units of the specified > fractional part; it is not applicable to display formats for > OCTET STRING objects. > > Elaborating on a slight variant of the example from the RFC, ... > Tuesday May 26, 1992 at 1:30:15.008 PM EDT > (8 milliseconds past the full 15 seconds), the 'seconds' part > would be represented as 15 seconds 8000 microseconds in four > octets containing 0x0F, 0x00, 0x1F, 0x40, which, together with > the other components, would be rendered as: > 1992-5-26,13:30:15.8000,-4:0 This is a very good catch - too bad nobody did find this before the RFC was posted. Your clarification surely makes sense, but the resulting format is really irritating. I do not know at the moment how to deal with this. The two options we have: a) Keep the published DISPLAY-HINT and document that the rendered value is really misleading humans (and we usually render for humans - so this is really bad) b) Declare the DISPLAY-HINT as a failure and remove it by hardwiring into the DESCRIPTION clause a conversation that uses leading zeros. I think more discussion is needed. /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 Oct 28 04:37:22 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DEA128C0E4 for ; Wed, 28 Oct 2009 04:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAWWsiNKRbdr for ; Wed, 28 Oct 2009 04:37:21 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 6B0B43A6954 for ; Wed, 28 Oct 2009 04:37:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,639,1249272000"; d="scan'208";a="178422639" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 28 Oct 2009 07:37:35 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 28 Oct 2009 07:37:34 -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, 28 Oct 2009 12:37:20 +0100 Message-ID: In-Reply-To: <20091028110044.GA19229@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Technical Errata Reported] RFC5676 (1928) Thread-Index: AcpXveqNjNA1gM2nQCewtI0l21w55gAAY6ZQ References: <200910231939.n9NJdmMr006579@boreas.isi.edu> <20091028110044.GA19229@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "RFC Errata System" Cc: ah@TR-Sys.de, akarmaka@cisco.com, opsawg@ietf.org Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:37:22 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 >=20 > I am trying to understand the errata and so I might stupid=20 > questions. Since you report two independent defects, it might=20 > have been useful to have two errata posted. I have no clue=20 > whether the errata tracker allows to make such changes now. > =20 It's always better to enter errata at a granularity where a single resolution makes sense. I think that the submitter can edit to reduce the text to one item, and then submit a second item. Or alternatively I can reject the current erratum (#1928) and Alfred can submit two (or more) errata instead.=20 Dan From A.Hoenes@TR-Sys.de Wed Oct 28 04:50:15 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD6328C0DE for ; Wed, 28 Oct 2009 04:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.9 X-Spam-Level: * X-Spam-Status: No, score=1.9 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LdwK6+iLnqU for ; Wed, 28 Oct 2009 04:50:13 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 5AD673A6784 for ; Wed, 28 Oct 2009 04:50:11 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA023710485; Wed, 28 Oct 2009 12:48:05 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA03161; Wed, 28 Oct 2009 12:48:02 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910281148.MAA03161@TR-Sys.de> To: j.schoenwaelder@jacobs-university.de Date: Wed, 28 Oct 2009 12:48:02 +0100 (MEZ) In-Reply-To: <20091028110044.GA19229@elstar.local> from Juergen Schoenwaelder at Oct "28, " 2009 "12:00:44" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 28 Oct 2009 04:51:02 -0700 Cc: akarmaka@cisco.com, opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 11:50:15 -0000 > On Fri, Oct 23, 2009 at 09:39:48PM +0200, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5676, >> "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1928 >> >> -------------------------------------- >> Type: Technical >> Reported by: Alfred Hoenes > > I am trying to understand the errata and so I might stupid > questions. Since you report two independent defects, it might have > been useful to have two errata posted. I have no clue whether the > errata tracker allows to make such changes now. a) Asking early is much better than carrying out endless discussions based on ambiguous grounds! So there are no 'stupid' questions! b) AFIACT, the responsible AD can do almost anything he likes ... >> Section: 7, pg. 7 >> >> Original Text >> ------------- >> SyslogTimeStamp ::= TEXTUAL-CONVENTION >> ! DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d" > > What does the '!' mark imply here? I always use change bars ("|") in the leftmost column to mark lines to be changed (OLD) or changed (NEW); this style now recurs so frequently in RFC Errata as well that I do not want to explain it again and again. However, in *this* case, where I had to present a rather long quotation to give the necessary context for the rationale, I wanted to draw the attention to other lines that the suggestions in the Errata Note do _not_ attempt to change, and thus the exclamation mark ("!") seemed to be an intuitive tag for lines containing important related details an to which I wanted to refer specifically in the Errata's 'Notes'. >> STATUS current >> DESCRIPTION >> "A date-time specification. This type is similar to the >> DateAndTime type defined in the SNMPv2-TC, except the >> subsecond granulation is microseconds instead of >> deciseconds and a zero-length string can be used >> to indicate a missing value. >> >> field octets contents range >> ----- ------ -------- ----- >> | 1 1-2 year* 0..65536 >> 2 3 month 1..12 >> 3 4 day 1..31 >> 4 5 hour 0..23 >> 5 6 minutes 0..59 >> 6 7 seconds 0..60 >> (use 60 for leap-second) >> ! 7 8-10 microseconds* 0..999999 > > Again, it is not clear to me what this ! mark tries to convey. "Pay attention to this line. It strongly matters for this Errata Note!" >> 8 11 direction from UTC '+' / '-' >> 9 12 hours from UTC* 0..13 >> 10 13 minutes from UTC 0..59 >> >> * Notes: >> - the value of year is in network-byte order >> | - the value of microseconds is in network-byte order >> - daylight saving time in New Zealand is +13 >> >> For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be >> displayed as: >> >> 1992-5-26,13:30:15.0,-4:0 >> >> Note that if only local time is known, then timezone >> information (fields 11-13) is not present." >> SYNTAX OCTET STRING (SIZE (0 | 10 | 13)) >> >> >> Corrected Text >> -------------- >> (a) upper part of the table: >> >> field octets contents range >> ----- ------ -------- ----- >> | 1 1-2 year* 0..32767 >> ... >> >> (b) "*Notes:" part: >> >> << see Notes below -- one possibility to address the issue is >> amending the text as follows; verifiers might do better >> >> >> * Notes: >> - the value of year is in network-byte order >> | - the value of microseconds is in network-byte order; >> | users of network management applications following >> | the DISPLAY-HINT specified above should be aware of >> | the unusual appearance of the apparent 'fractional part' >> | displayed: RFC 2579 requires the leading zeros to be >> | omitted; thus a time component diaplayed as '13:30:15.50' >> | does not indicate 50 centiseconds, but 50 microseconds >> | past the full second! >> - daylight saving time in New Zealand is +13 >> >> >> Notes >> ----- >> (a) >> >> Section 3.1 of RFC 2579 (on page 21) states, regarding numerical >> conversion descriptor components in DISPLAY-HINTS: >> >> [...] For all types, when rendering a value, leading >> zeros are omitted, and for negative values, a minus sign is rendered >> immediately before the digits. [...] >> >> Arguably, this means that substrings of OCTET STRING type are >> interpreted as *signed* values (in network byte order). >> Therefore, the range restriction for the 'year' part specified >> informally in the DESCRIPTION clause does not make proper sense; >> an upper bound of 65536 is nonsensical anyway since a 2-octet >> substring cannot assme 65537 different values; to avoid issues >> with different interpretation of RFC 2579, the 'safe' range >> 0..32767 is recommended -- this should not be a serious restriction >> in practice. > > Hm. The text you quote is the definition of 'd' for INTEGER typed > DISPLAY-HINTs. Given the absence of a definition of 'd' for OCTET > STRING types DISPLAY-HINTs, it is not really clear what RFC 2579 > intended. ... The text in RFC 2579 for numerical translations is convoluted indeed, but I believe it is unambiguous. It starts out with "For INTEGER types ..." and continues with: "For all types, ..." as quoted above. > ... If your interpretation is right that numbers are signed, > then we have similar problems in other documents, e.g. RFC 2579's > definition of DateAndTime. You may be right; I'll take a closer look at that; maybe more Errata? >> (b) >> >> WARNING: >> >> According to Section 3.1 of RFC 2579, the components of the >> DISPLAY-HINTS string describe the *independent* formatting of >> substrings of the OCTET STRING (in this case). >> Thus, the display instructions for the conceptional 'seconds' >> part of the OCTET STRING, "1d.3d", actually describes the >> independent formatting of a 1-octet and a 3-octet substring >> (in network byte order) as decimal integers without leading >> zeros, separated by a literal period ('.') -- a "display >> separator character" in RFC 2579 terms --, and not the >> human-friendly formatting of a single fixed-point fractional >> number; there is no concept of a decimal fraction representation >> in this notation. >> So the presentation format will be very different from common >> practice for human beings. See the example below. >> The "fixed-point with decimal sign" representation from >> RFC 2579 is only available for INTEGER values, for cases with >> scaled values, where the conceptual integer and fractional part >> are stored as a single integer in units of the specified >> fractional part; it is not applicable to display formats for >> OCTET STRING objects. >> >> Elaborating on a slight variant of the example from the RFC, ... >> Tuesday May 26, 1992 at 1:30:15.008 PM EDT >> (8 milliseconds past the full 15 seconds), the 'seconds' part >> would be represented as 15 seconds 8000 microseconds in four >> octets containing 0x0F, 0x00, 0x1F, 0x40, which, together with >> the other components, would be rendered as: >> 1992-5-26,13:30:15.8000,-4:0 > > This is a very good catch - too bad nobody did find this before the > RFC was posted. Your clarification surely makes sense, but the > resulting format is really irritating. ... Two observations here (let's stay on the learning curve!): - It's always tempting to (only) give 'simple' examples. This might be taken as evidence that reviewers perhaps should challenge authors to provide less simple examples as well. - Playing with an early prototype implementation might have revealed the issue. Now that we have a PS, playing with upcoming implementations will give us a chance to improve the PS in a future update at Draft Standard level. That's what the Standards Track envisions anyway, isn't it? > ... I do not know at the moment how > to deal with this. The two options we have: > > a) Keep the published DISPLAY-HINT and document that the rendered > value is really misleading humans (and we usually render for humans > - so this is really bad) > > b) Declare the DISPLAY-HINT as a failure and remove it by hardwiring > into the DESCRIPTION clause a conversation that uses leading zeros. > > I think more discussion is needed. +1 Since I did not have the cycles available to step in earlier in syslog, I wanted to start this discussion in a manner that becomes visible to prospective readers of the RFC, hence the Errata path taken. This emerging thread should be the right place for the discussion, and the conclusions drawn eventually should be used to update the Errata note in the most useful manner. > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From j.schoenwaelder@jacobs-university.de Wed Oct 28 08:54:12 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2A7E3A67A3 for ; Wed, 28 Oct 2009 08:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1kUzwygX15J for ; Wed, 28 Oct 2009 08:54:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6B1E528C1E2 for ; Wed, 28 Oct 2009 08:54:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 672A1C000D; Wed, 28 Oct 2009 16:54:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29xhapGSt8dS; Wed, 28 Oct 2009 16:54:25 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D516C0030; Wed, 28 Oct 2009 16:54:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 864FAD5CAA7; Wed, 28 Oct 2009 16:54:23 +0100 (CET) Date: Wed, 28 Oct 2009 16:54:23 +0100 From: Juergen Schoenwaelder To: "ah@TR-Sys.de" Message-ID: <20091028155423.GA19329@elstar.local> Mail-Followup-To: "ah@TR-Sys.de" , "alex@cisco.com" , "akarmaka@cisco.com" , "dromasca@avaya.com" , "rbonica@juniper.net" , "sob@harvard.edu" , "ted.a.seely@sprint.com" , "opsawg@ietf.org" References: <20091028110044.GA19229@elstar.local> <200910281148.MAA03161@TR-Sys.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200910281148.MAA03161@TR-Sys.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "akarmaka@cisco.com" , "opsawg@ietf.org" Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 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, 28 Oct 2009 15:54:12 -0000 On Wed, Oct 28, 2009 at 12:48:02PM +0100, ah@TR-Sys.de wrote: > > Hm. The text you quote is the definition of 'd' for INTEGER typed > > DISPLAY-HINTs. Given the absence of a definition of 'd' for OCTET > > STRING types DISPLAY-HINTs, it is not really clear what RFC 2579 > > intended. ... > > The text in RFC 2579 for numerical translations is convoluted indeed, > but I believe it is unambiguous. > It starts out with "For INTEGER types ..." and continues with: > "For all types, ..." as quoted above. See, it depends how you parse the text. One can read it as the initial "for INTEGER types" phrase qualifies the whole paragraph for INTEGER types. I have to look at code I wrote many years ago to see what my implementation does. Knowing what implementations do would certainly help. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From A.Hoenes@TR-Sys.de Wed Oct 28 09:28:06 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB8628C23C for ; Wed, 28 Oct 2009 09:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.928 X-Spam-Level: * X-Spam-Status: No, score=1.928 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTgxn12I23eG for ; Wed, 28 Oct 2009 09:28:05 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D39C028C20C for ; Wed, 28 Oct 2009 09:28:02 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA025047248; Wed, 28 Oct 2009 17:27:28 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id RAA03630; Wed, 28 Oct 2009 17:27:23 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200910281627.RAA03630@TR-Sys.de> To: j.schoenwaelder@jacobs-university.de, opsawg@ietf.org Date: Wed, 28 Oct 2009 17:27:22 +0100 (MEZ) In-Reply-To: <20091028110044.GA19229@elstar.local> from Juergen Schoenwaelder at Oct "28, " 2009 "12:00:44" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Cc: ah@WOTAN.TR-Sys.de Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:28:06 -0000 In the message archived at http://www.IETF.ORG/mail-archive/web/opsawg/current/msg00848.html, Juergen Schoenwaelder wrote: > On Fri, Oct 23, 2009 at 09:39:48PM +0200, RFC Errata System wrote: > >> The following errata report has been submitted for RFC5676, >> "Definitions of Managed Objects for Mapping SYSLOG Messages to >> Simple Network Management Protocol (SNMP) Notifications". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1928 >> >> -------------------------------------- >> Type: Technical >> Reported by: Alfred Hoenes > > ... [snip] > >> Section: 7, pg. 7 >> >> Original Text >> ------------- >> SyslogTimeStamp ::= TEXTUAL-CONVENTION >> ! DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d" > > ... [snip] ... > >> Notes >> ----- >> (a) >> >> Section 3.1 of RFC 2579 (on page 21) states, regarding numerical >> conversion descriptor components in DISPLAY-HINTS: >> >> [...] For all types, when rendering a value, leading >> zeros are omitted, and for negative values, a minus sign is rendered >> immediately before the digits. [...] >> >> Arguably, this means that substrings of OCTET STRING type are >> interpreted as *signed* values (in network byte order). >> Therefore, the range restriction for the 'year' part specified >> informally in the DESCRIPTION clause does not make proper sense; >> an upper bound of 65536 is nonsensical anyway since a 2-octet >> substring cannot assme 65537 different values; to avoid issues >> with different interpretation of RFC 2579, the 'safe' range >> 0..32767 is recommended -- this should not be a serious restriction >> in practice. > > Hm. The text you quote is the definition of 'd' for INTEGER typed > DISPLAY-HINTs. Given the absence of a definition of 'd' for OCTET > STRING types DISPLAY-HINTs, it is not really clear what RFC 2579 > intended. If your interpretation is right that numbers are signed, > then we have similar problems in other documents, e.g. RFC 2579's > definition of DateAndTime. Returning to RFC 2579 and reconsidering the context, a few observations should be made before progressing: Unlike purists argue for RADIUS and DHCP, the SMI has peacefully lived with the concept of structured data carried in OCTET STRING objects, whithout seeing a need to formally define a new SMI data type for each such, say, 'application layer data type'. (Intrinsically that already has been inherited from X.208 / X.680.) Therefore, it might be wise to precisely distinguish SMI layer aspects from 'application layer' aspects considered out of scope for the SMI, but keeping in mind that the latter preferably should make use of general, standard SMI mechanisms as far as possible. The data structures and types superimposed on OCTET STRINGs via TEXTUAL-CONVENTIONs and defined otherwise in MIB module specifications are essentially at the application layer, not a matter of interest at the SMI layer. Therefore, I see no conceptual problem of specifying signed or unsigned integer values conceptually mapped into OCTET STRINGs (or BCD data, 5-bit Baudot codes, or 7-bit SMS characters, packed into OCTET STRINGs, or integer parts of seconds and fractional parts of seconds mapped separately, whatever you need, btw!). All that needs to be done at MIB module specification time is providing unambiguous coding rules for interoperability (e.g., "3-octet unsigned integer in network byte order"). So far, I believe, we do not have any problem now. The second topic scratched at in the Errata Note deals with the application of the SMI (RFC 2579) DISPLAY-HINT mechanism to such 'application level' data types. The precise specification of that generic mechanism is in the domain of the SMI, as is the interpretation of the standard. However, the DISPLAY-HINT mechanism needs to make some assumptions on the binary patterns that shall be presented to humans; this is easy for the 'fully specified' SMI data types, but it is much less straightforward for structured data superimposed on OCTET STRINGs, and arguably RFC 2579 has underspecified this aspect -- otherwise it would not be possible to give rise to different interpretations, as it turns out now. The other question indeed is the applicability of the mechanism to a specific application, the restrictions to be adhered to in order to make proper use of the mechanism for an 'application data type', e.g. how to design such data types in a 'DISPLAY-HINT friendly' manner. Since this subject cannot be dealt with properly without a solid foundation, we should first tackle the perceived ambiguity in RFC 2579 before discussing the SMI user (application) layer details. Therefore, I suggest to defer the discussion of the latter. Thus, let's focus on Section 3.1 of RFC 2579 (p.21/22). The first part of that section -- almost all on p.21 -- mainly deals with the 'fully specified' SMI data types, where syntax and sematics are so narrow the DISPLAY-HINT is not needed and hence not permitted, and the presentation of those subcases of the INTEGER data type that do not have narrow semantics specified in the SMI. The second part of the section extends from the bottom of p.21 to the end of the section and deals with OCTET STRING conversions. Bullet (3) on p.22 discusses the display format characters in the DISPLAY-HINT string for OCTET-STRING objects, and refers to numeric format conversions; the only detailed rule given is: If the octet length part is greater than one, and the display format part refers to a numeric format, then network-byte ordering (big-endian encoding) is used interpreting the octets in the value. That's why I always had concluded that the description of numeric conversions on page 21 was included here by reference, for all other relevant (yet herein unspecified) details, in particular the phrase quoted above, starting with "For all types, ...". This contains the assumption that the n-octet integer values to be converted were signed integers. As it has turned out, this interpretation is not shared universally, with the alternate assumption being that these n-octet integers must always be regarded as unsigned. Most instances I recall ever having seen are uncritical because the valid range for the integer values is restricted by application semantics to the extent that the MSB is always 0, thus admitting both interpretations without any impact on their use. (Ironically, related trouble has recurred in other places in the IETF, where specifications had not been explicit enough to state precisely whether particular protocol fields carry signed or unsigned integer values, and later protocol additions had to work around deployed implementations assuming either.) Apparently, the best solution would be to file a clarification for Section 3.1 of RFC 2579, as an Errata note, as well, in order to disambiguate the interpretation. When this is done, collateral issues can be identified and resolved. Before performing any action, it would perhaps be useful to harvest existing IETF and Vendor MIB modules for instances of data structures superimposed on OCTET strings and observe the kind of integer values (signed/unsigned) in these structures: a) in general (irrelevant for the issue at hand, hence for information only); and (significant for the issue): b) when the DISPLAY-HINT mechanism is also used for the respective objects. I have neither enough spare time nor the (non-IETF) example material at hand to perform this harvesting and therefore would like to solicit input from vendors. > ... [snip] ... > > I think more discussion is needed. > > /js Yes, I tried to start it hereby. :-) > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From randy_presuhn@mindspring.com Wed Oct 28 09:36:34 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23D53A6A0D for ; Wed, 28 Oct 2009 09:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gtqf+wbY3n0n for ; Wed, 28 Oct 2009 09:36:33 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 7217E3A6833 for ; Wed, 28 Oct 2009 09:36:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=IpsJYVe6Tt3cr9S6x1hlLP2+EeEJ4Eerm4YtqRU0AdvE8nOCPmzKt87s1CcSKPgR; h=Received:Message-ID:From:To:Cc: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.23.160.219] (helo=oemcomputer) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N3BVw-0000aX-8M; Wed, 28 Oct 2009 12:36:48 -0400 Message-ID: <003901ca57ed$1eee9ba0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "RFC Errata System" References: <200910231939.n9NJdmMr006579@boreas.isi.edu> <20091028110044.GA19229@elstar.local> Date: Wed, 28 Oct 2009 09:38:45 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f96361993c3baca3ce0b1b9f46fbc31430350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.219 Cc: opsawg@ietf.org Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:36:35 -0000 Hi - I don't see how RFC 2579 supports the reading that bytes of an octet string should be interpreted as negative numbers. It certainly was never the intent, and none of the definitions in RFC 2579 would support that reading. If anything is to be changed here, it is the text in RFC 2579 clause 3.1 (3). The simple clarification is that these octets are unsigned. I'm not aware of any TCs for which this would do the wrong thing, but we should review what's out there. The tougher problem is what to do about the leading zeroes - DISPLAY-HINT is clearly broken there with respect to the needs of a human- friendly DateAndTime. Perhaps the good news is that since DISPLAY-HINTS really have no normative force, implementations can just ignore them and do the Right Thing. :-) * 0.5 Randy ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "RFC Errata System" > Cc: ; ; > Sent: Wednesday, October 28, 2009 4:00 AM > Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) > > On Fri, Oct 23, 2009 at 09:39:48PM +0200, RFC Errata System wrote: > > > The following errata report has been submitted for RFC5676, > > "Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5676&eid=1928 > > > > -------------------------------------- > > Type: Technical > > Reported by: Alfred Hoenes > > I am trying to understand the errata and so I might stupid > questions. Since you report two independent defects, it might have > been useful to have two errata posted. I have no clue whether the > errata tracker allows to make such changes now. > > > Section: 7, pg. 7 > > > > Original Text > > ------------- > > SyslogTimeStamp ::= TEXTUAL-CONVENTION > > ! DISPLAY-HINT "2d-1d-1d,1d:1d:1d.3d,1a1d:1d" > > What does the '!' mark imply here? > > > STATUS current > > DESCRIPTION > > "A date-time specification. This type is similar to the > > DateAndTime type defined in the SNMPv2-TC, except the > > subsecond granulation is microseconds instead of > > deciseconds and a zero-length string can be used > > to indicate a missing value. > > > > field octets contents range > > ----- ------ -------- ----- > > | 1 1-2 year* 0..65536 > > 2 3 month 1..12 > > 3 4 day 1..31 > > 4 5 hour 0..23 > > 5 6 minutes 0..59 > > 6 7 seconds 0..60 > > (use 60 for leap-second) > > ! 7 8-10 microseconds* 0..999999 > > Again, it is not clear to me what this ! mark tries to convey. > > > 8 11 direction from UTC '+' / '-' > > 9 12 hours from UTC* 0..13 > > 10 13 minutes from UTC 0..59 > > > > * Notes: > > - the value of year is in network-byte order > > | - the value of microseconds is in network-byte order > > - daylight saving time in New Zealand is +13 > > > > For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be > > displayed as: > > > > 1992-5-26,13:30:15.0,-4:0 > > > > Note that if only local time is known, then timezone > > information (fields 11-13) is not present." > > SYNTAX OCTET STRING (SIZE (0 | 10 | 13)) > > > > > > Corrected Text > > -------------- > > (a) upper part of the table: > > > > field octets contents range > > ----- ------ -------- ----- > > | 1 1-2 year* 0..32767 > > ... > > > > (b) "*Notes:" part: > > > > << see Notes below -- one possibility to address the issue is > > amending the text as follows; verifiers might do better >> > > > > * Notes: > > - the value of year is in network-byte order > > | - the value of microseconds is in network-byte order; > > | users of network management applications following > > | the DISPLAY-HINT specified above should be aware of > > | the unusual appearance of the apparent 'fractional part' > > | displayed: RFC 2579 requires the leading zeros to be > > | omitted; thus a time component diaplayed as '13:30:15.50' > > | does not indicate 50 centiseconds, but 50 microseconds > > | past the full second! > > - daylight saving time in New Zealand is +13 > > > > > > Notes > > ----- > > (a) > > > > Section 3.1 of RFC 2579 (on page 21) states, regarding numerical > > conversion descriptor components in DISPLAY-HINTS: > > > > [...] For all types, when rendering a value, leading > > zeros are omitted, and for negative values, a minus sign is rendered > > immediately before the digits. [...] > > > > Arguably, this means that substrings of OCTET STRING type are > > interpreted as *signed* values (in network byte order). > > Therefore, the range restriction for the 'year' part specified > > informally in the DESCRIPTION clause does not make proper sense; > > an upper bound of 65536 is nonsensical anyway since a 2-octet > > substring cannot assme 65537 different values; to avoid issues > > with different interpretation of RFC 2579, the 'safe' range > > 0..32767 is recommended -- this should not be a serious restriction > > in practice. > > Hm. The text you quote is the definition of 'd' for INTEGER typed > DISPLAY-HINTs. Given the absence of a definition of 'd' for OCTET > STRING types DISPLAY-HINTs, it is not really clear what RFC 2579 > intended. If your interpretation is right that numbers are signed, > then we have similar problems in other documents, e.g. RFC 2579's > definition of DateAndTime. > > > (b) > > > > WARNING: > > > > According to Section 3.1 of RFC 2579, the components of the > > DISPLAY-HINTS string describe the *independent* formatting of > > substrings of the OCTET STRING (in this case). > > Thus, the display instructions for the conceptional 'seconds' > > part of the OCTET STRING, "1d.3d", actually describes the > > independent formatting of a 1-octet and a 3-octet substring > > (in network byte order) as decimal integers without leading > > zeros, separated by a literal period ('.') -- a "display > > separator character" in RFC 2579 terms --, and not the > > human-friendly formatting of a single fixed-point fractional > > number; there is no concept of a decimal fraction representation > > in this notation. > > So the presentation format will be very different from common > > practice for human beings. See the example below. > > The "fixed-point with decimal sign" representation from > > RFC 2579 is only available for INTEGER values, for cases with > > scaled values, where the conceptual integer and fractional part > > are stored as a single integer in units of the specified > > fractional part; it is not applicable to display formats for > > OCTET STRING objects. > > > > Elaborating on a slight variant of the example from the RFC, ... > > Tuesday May 26, 1992 at 1:30:15.008 PM EDT > > (8 milliseconds past the full 15 seconds), the 'seconds' part > > would be represented as 15 seconds 8000 microseconds in four > > octets containing 0x0F, 0x00, 0x1F, 0x40, which, together with > > the other components, would be rendered as: > > 1992-5-26,13:30:15.8000,-4:0 > > This is a very good catch - too bad nobody did find this before the > RFC was posted. Your clarification surely makes sense, but the > resulting format is really irritating. I do not know at the moment how > to deal with this. The two options we have: > > a) Keep the published DISPLAY-HINT and document that the rendered > value is really misleading humans (and we usually render for humans > - so this is really bad) > > b) Declare the DISPLAY-HINT as a failure and remove it by hardwiring > into the DESCRIPTION clause a conversation that uses leading zeros. > > I think more discussion is needed. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg From randy_presuhn@mindspring.com Wed Oct 28 09:48:18 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0235B28C24D for ; Wed, 28 Oct 2009 09:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1EQuT6uP4SF for ; Wed, 28 Oct 2009 09:48:17 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id EB34028C206 for ; Wed, 28 Oct 2009 09:48:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=kawwipSl3TkLrPxOZ48PQLLJRZUm8+zH0XhHI3KOQ4TAGWWyBiejIjcKhBstkkzQ; 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.23.160.219] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N3BhI-0004XU-2Y for opsawg@ietf.org; Wed, 28 Oct 2009 12:48:32 -0400 Message-ID: <005a01ca57ee$c3421000$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <200910281627.RAA03630@TR-Sys.de> Date: Wed, 28 Oct 2009 09:50:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f9477ff0cb5037f862ba3cc02c0abff692350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.219 Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 16:48:18 -0000 Hi - > From: "Alfred Hnes" > To: ; > Cc: > Sent: Wednesday, October 28, 2009 9:27 AM > Subject: Re: [OPSAWG] [Technical Errata Reported] RFC5676 (1928) ... > The first part of that section -- almost all on p.21 -- mainly > deals with the 'fully specified' SMI data types, where syntax and > sematics are so narrow the DISPLAY-HINT is not needed and hence > not permitted, and the presentation of those subcases of the > INTEGER data type that do not have narrow semantics specified > in the SMI. > > The second part of the section extends from the bottom of p.21 > to the end of the section and deals with OCTET STRING conversions. > Bullet (3) on p.22 discusses the display format characters in the > DISPLAY-HINT string for OCTET-STRING objects, and refers to > numeric format conversions; the only detailed rule given is: > > If the octet > length part is greater than one, and the display format part refers > to a numeric format, then network-byte ordering (big-endian > encoding) is used interpreting the octets in the value. > > That's why I always had concluded that the description of numeric > conversions on page 21 was included here by reference, for all other > relevant (yet herein unspecified) details, in particular the phrase > quoted above, starting with "For all types, ...". > This contains the assumption that the n-octet integer values to be > converted were signed integers. That was not the intent when the text was developed. It is also worth keeping in mind that since its inception DISPLAY-HINT has been recognized as being a very limited facility. That's one of the reasons why it is so totally optional. > As it has turned out, this interpretation is not shared universally, > with the alternate assumption being that these n-octet integers > must always be regarded as unsigned. This is my recollection of the intent when the text was written. > Most instances I recall ever having seen are uncritical because the > valid range for the integer values is restricted by application > semantics to the extent that the MSB is always 0, thus admitting > both interpretations without any impact on their use. > > (Ironically, related trouble has recurred in other places in the > IETF, where specifications had not been explicit enough to state > precisely whether particular protocol fields carry signed or > unsigned integer values, and later protocol additions had to work > around deployed implementations assuming either.) In general, it's safest to assume that bit fields are unsigned unless explicitly stated otherwise, the behaviour of some C compilers notwithstanding. > Apparently, the best solution would be to file a clarification > for Section 3.1 of RFC 2579, as an Errata note, as well, in order > to disambiguate the interpretation. When this is done, collateral > issues can be identified and resolved. Agreed. Randy From Quittek@nw.neclab.eu Wed Oct 28 10:15:55 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0846028C182 for ; Wed, 28 Oct 2009 10:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dKjZglfTWiP for ; Wed, 28 Oct 2009 10:15:51 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 0CB693A6925 for ; Wed, 28 Oct 2009 10:15:51 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 0E77F2C017B2F; Wed, 28 Oct 2009 18:16:06 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAn4ZrPE0hDV; Wed, 28 Oct 2009 18:16:05 +0100 (CET) Received: from VENUS.office (mx1.office [192.168.24.3]) by smtp0.neclab.eu (Postfix) with ESMTP id C5C802C0002FE; Wed, 28 Oct 2009 18:15:45 +0100 (CET) Received: from VENUS.office ([192.168.24.102]) by VENUS.office with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Oct 2009 18:15:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.7.0.54 ([10.7.0.54]) by VENUS.office ([192.168.24.102]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Oct 2009 17:15:46 +0000 MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3339597704_17342512" Date: Wed, 28 Oct 2009 18:15:46 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] call for opsawg agenda time requests thread-index: AcpX8FOcDEyAcE+0y0+zwu3no4ijCA== From: "Juergen Quittek" To: , "David Harrington" , "Dan Romascanu" X-OriginalArrivalTime: 28 Oct 2009 17:15:46.0284 (UTC) FILETIME=[49A6A2C0:01CA57F2] Cc: opsawg@ietf.org Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:15:55 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3339597704_17342512 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear Hideki, Please see comments inline. On 28.10.09 03:41 "hideki.okita.pf@hitachi.com" wrote: > David, Dan, Juergen, > > > Thank you so much for your reviews and comments. > > First, please let me summarize David's concerns. > Please tell me if I have any misunderstanding. > > 1. The proposed model seems similar to the information model > implicitly defined in the existing ENTITY-MIB. > 2. The draft does not mention the relationship between the proposed > model and the ENTITY-MIB. > 3. The draft lacks the concrete definition how the NMS presents > the virtual network information to NMS clients. > > For the first concern, I examined the ENTITY-MIB since I have not > considered it. I checked RFC 4133 and implementation by a router. > > Then, I found that our model have a similarity with the ENTITY-MIB. > Both of following objects describe the structure of a physical entity. > - entPhysicalTable and entPhysicalContainsTable in the ENTITY-MIB > - PhysicalNode, PhysicalNodeGroup, and PhysicalInterface in our model. > > However, IMO, the model of the ENTITY-MIB is insufficient to > manage virtual networks in data centers from following reasons. > a. ENTITY-MIB does not have connection objects for describing the > connections between physical nodes. Yes, that is not the purpose of the ENTITY MIB. However, topology detection of an IP network is a very common task of network management systems and well supported by other MIB modules. I don't think we need new managed objects for this purpose. > b. ENTITY-MIB does not have connection objects for describing the > connections between virtual nodes, for example, the connection > between a virtual switch and virtual machines on a physical server. This may not be necessary, depending on how you build your information model. What I think is really missing is a mapping of virtual entities to physical entities. The virtual entities need relations to their virtual interfaces and virtual interfaces need to be mapped to real interfaces. > c. ENTITY-MIB does not have virtual-virtual relationship objects for > describing the structure of a virtual entity. Yes, but again, there may be sufficient other means than the ENTITY MIB to provide this information. > Therefore, I'd like to propose our model as an solution and opsawg's > new work. > > For the second concern, I'd like to add a "relationship to the > ENTITY-MIB" section that describes above distinction to our draft. This is probably the best way to achieve your objectives. As said before, I would consider the most important step to find a good way of mapping virtual entities to real entities. Best regards, Juergen > For the third concern, I can add a section about a MIB module or > an XML schema to our draft to describe the concrete datamodel. > > > Best regards, > > Hideki Okita > > >> I also had a look at the draft and I think that the basic idea >> of mapping virtual to real resources is very good. >> >> Can't we easily align the draft with the ENTITY MIB data model? >> >> I could imagine a MIB module based on the ENTITY MIB that realizes >> the information model for virtual entities in SMI. >> >> Juergen >> >> >> On 26.10.09 13:51 "David Harrington" wrote: >> >>> Hi, >>> >>> I did a quick read of this document. I have a concern. >>> >>> The IETF decided years ago that a MIB module was the preferred >>> mechanism for explicitly documenting an IETF standards-track data >>> model and (implicitly) the IETF standards-track information model. >>> >>> Once the IETF began to accept that having only one data modeling >>> language (the SMI) might not be adequate, the IETF struggled with the >>> question of "how do we deal with multiple modeling languages?", and we >>> started to pay attention to the distinction between data model and >>> information model. RFC3444 was published as output of the NMRG to help >>> clarify the distinction. >>> >>> The informational model in >>> http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt is similar to >>> the information model that is implicit in the ENTITY-MIB data model >>> design. >>> >>> I would not like to see anybody make the mistake of thinking that this >>> Informational document represents IETF consensus on an information >>> model for managing virtual networks. This document needs to be very >>> clear that the IETF already has consensus on an (implicit) information >>> model for managing physical entities, logicial entities, and the >>> mappings between them. >>> >>> I think defining an information model for the management of virtual >>> networks is very important work, and I think this document really >>> misses an opportunity to help **standardize** how virtual network >>> management systems present information to NMS clients. This document >>> would be terrific if it extracted and documented the information model >>> implicit in the existing IETF standard ENTITY-MIB, and went on to >>> discuss whether the existing information model does or does not meet >>> the needs of real-world implementations/deployments. >>> >>> If the existing implicit information model does meet real-world needs, >>> then I think such a document might become a BCP or an Informational >>> guideline for managing virtual networks. If the existing implicit >>> information does not meet real-world needs, then the document could be >>> a justification for an IETF standards track information model that >>> meets needs better than the current implicit information model. >>> >>> Unfortunately, the current document does not even mention that there >>> is an information model implicit in the ENTITY-MIB standard, which >>> makes me question whether this document should be published as an RFC >>> without a clear statement that it ignores, and may be in conflict >>> with, existing IETF standards. >>> >>> dbh >>> >>> >>>> -----Original Message----- >>>> From: opsawg-bounces@ietf.org >>>> [mailto:opsawg-bounces@ietf.org] On Behalf Of >>>> hideki.okita.pf@hitachi.com >>>> Sent: Monday, October 26, 2009 7:33 AM >>>> To: sob@harvard.edu >>>> Cc: opsawg@ietf.org >>>> Subject: Re: [OPSAWG] call for opsawg agenda time requests >>>> >>>> Scott, >>>> >>>> >>>> I'd like to have a slot at the opsawg session in Hiroshima >>>> to take a presentation about the update of our network >>>> virtulization model. >>>> >>>> "Virtual Network Management Information Model" >>>> http://www.ietf.org/id/draft-okita-ops-vnetmodel-01.txt >>>> >>>> Regards, >>>> >>>> Hideki Okita >>>> >>>> >>>>> please send requests for agenda time slots for the opsawq >>>> session in Hiroshima >>>>> to the opsawg list asap >>>>> >>>>> Scott > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --B_3339597704_17342512 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIQ6gYJKoZIhvcNAQcCoIIQ2zCCENcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DpIwggU2MIIEHqADAgECAgQNLisHMA0GCSqGSIb3DQEBBQUAMIGQMQswCQYDVQQGEwJERTEY MBYGA1UEChMPTkVDIEV1cm9wZSBMdGQuMSAwHgYDVQQLExdORUMgTGFib3JhdG9yaWVzIEV1 cm9wZTESMBAGA1UEAxMJTkVDTEFCLUNBMTEwLwYJKoZIhvcNAQkBFiJ6ZXJ0aWZpemllcnVu Z3NzdGVsbGVAbncubmVjbGFiLmV1MB4XDTA4MTEwMzA3NTEyMFoXDTExMTEwMzA3NTEyMFow YzELMAkGA1UEBhMCREUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVD IExhYm9yYXRvcmllcyBFdXJvcGUxGDAWBgNVBAMTD0p1ZXJnZW4gUXVpdHRlazCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALYRfFB9x4h1YO6Mva6A5GCwKjwpgvzjiayFSmdD HwV8u5gHp3sHIhyVtxgMSifEp9AV+ChxWHS3KQwuQ3XhDAP/xDN6QSk4Bmqa6rCZuTJygxYh K39rNKd47ZfpuRC7j/Mbzwe9DTsbbBtpBgl5UKFc9c+zMbPlSwwlVbshWaUEoM6HoVFaDJdh tJBIpsblz1oQVKXDjxjGkUNh9Ds3m7BGXkr5yaGsEuEa0J/QAFdO+auvBJlAzIM0UwBAmlcT UHanS6Sdw5MkeutQqnmsUBtoenydq2Tmd9hfSfuTfiFuLmsvL3udH/jDAgQZ+PH6Mprqpyd3 wSycF/xZF5zz8X0CAwEAAaOCAcIwggG+MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXgMCkGA1Ud JQQiMCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAjAdBgNVHQ4EFgQUWQo3BPrO OLA4qljzDL1H8/6hIWEwHwYDVR0jBBgwFoAUTxyHeh3gL5n2vhWq0TWdDkrmujYwHwYDVR0R BBgwFoEUUXVpdHRla0Budy5uZWNsYWIuZXUwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2Nk cDEucGNhLmRmbi5kZS9uZWNsYWItY2EvcHViL2NybC9jYWNybC5jcmwwOKA2oDSGMmh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvbmVjbGFiLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGYBggrBgEF BQcBAQSBizCBiDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDEucGNhLmRmbi5kZS9uZWNsYWIt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEIGCCsGAQUFBzAChjZodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL25lY2xhYi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQAD ggEBAB37+54yupDBTDpEMuyf+ouCRrOE3fPAD2SEGBXCpKTYteFkFSWvHlgN8ecRSma0Dz/5 QShzacGMeJ8o+XzVXHe2gtZbjzSVvJn+/nAKtKgDCzw0ltt3xkdMMv2ax6IKGR7BcccsXx7B R2PMaxdmHfCJseXiMzZO9QlWN2NZq2SSo3eGX/YDhHCWXDsoSu+uaKU/aRL2uZa92ptak2MA uKI5tylKLFZ3FHf08F8J+5tTaMGem6DfaMZR/9GZ8aRFJrdA7tzUAGKpl+CzRxsJVHbAAU5L hm5oTt6XYbh2G/cgdpeucsHJWBz9NQJrSrfWZYSwrv6AekMcvMi9X/CVZxEwggUvMIIEF6AD AgECAgQNIQpHMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4t VmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9i YWwgLSBHMDEwHhcNMDgxMDI0MDg1MjA4WhcNMTkwNjMwMDAwMDAwWjCBkDELMAkGA1UEBhMC REUxGDAWBgNVBAoTD05FQyBFdXJvcGUgTHRkLjEgMB4GA1UECxMXTkVDIExhYm9yYXRvcmll cyBFdXJvcGUxEjAQBgNVBAMTCU5FQ0xBQi1DQTExMC8GCSqGSIb3DQEJARYiemVydGlmaXpp ZXJ1bmdzc3RlbGxlQG53Lm5lY2xhYi5ldTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJ7yFbG1EaoyDnG5367mJEXHljmacrzNnm52KW3dXD/s3Vpuskex0jvaaTntWWRSGrAK 6kKXnTxBb3J3EhveBUbltzQ+K0XKtPJm6VE5qVpl33WJSaUHs27Dhwlke+DV6BBGyukz2SDB aSa+nc0AwMZ0XO1DoDuiUNVeNmd/QT4SGzyFs+uLfLL2n8WzkZsbpSZ+xecwyw3EdQBBsp/i /W+uOQBsGqaCjYe3EkBU6nW+pBsj0Iy1n7b9PXb5gQynrK3Mi2V7g1idSzHos0o1BMoHUrMz Vw94Hj4CWlWmQ0t6Pdt1uYAMjwk0saQBY/Fyfv+wKeYycGIYyYCfJIRUeyUCAwEAAaOCAcQw ggHAMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBRPHId6HeAv mfa+FarRNZ0OSua6NjAfBgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAtBgNVHREE JjAkgSJ6ZXJ0aWZpemllcnVuZ3NzdGVsbGVAbncubmVjbGFiLmV1MIGIBgNVHR8EgYAwfjA9 oDugOYY3aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY3JsL2Nh Y3JsLmNybDA9oDugOYY3aHR0cDovL2NkcDIucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9w dWIvY3JsL2NhY3JsLmNybDCBogYIKwYBBQUHAQEEgZUwgZIwRwYIKwYBBQUHMAKGO2h0dHA6 Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0 MEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1 Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAbDEPnQ9JpouPHYA1OEek P3l3GNM0HBzadVbtbN5MDtFmoVgdLYqlQaHb30wFhuOMbsNCOzV0k8EOvBVOT9BiEJ70RWcl SZQ460jZS2MY6n5oG/ilZuu6N/N3GSLg2pBBNH9vZFCyBJ9n4Px7A4gQF07G+CNfV2jdE1yy PjzIVPhg6bBgia8nXroBFe6oteavMspo0gLGIJ63NsCbl6ckPa96grT+mnnQD0h6jk/IGtXS 09mEWRbN7zZu0x0q+SScpljG36Q+jnG0U5zQI0jAx8CcYEQQH5QOlsw1Zu35OI4lsi7ycFkz JNfbfEC4ihuw9J2L43BFGMojkhPkhVExHTCCBCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEB BQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYD VQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYT AkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtE Rk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgj hIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa 7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZD z+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkw gdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2Vy dmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9S T09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHD eRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEC MA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn 8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y 4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GG hfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJhp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3 VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5J Y6gA9/IcMYICIDCCAhwCAQEwgZkwgZAxCzAJBgNVBAYTAkRFMRgwFgYDVQQKEw9ORUMgRXVy b3BlIEx0ZC4xIDAeBgNVBAsTF05FQyBMYWJvcmF0b3JpZXMgRXVyb3BlMRIwEAYDVQQDEwlO RUNMQUItQ0ExMTAvBgkqhkiG9w0BCQEWInplcnRpZml6aWVydW5nc3N0ZWxsZUBudy5uZWNs YWIuZXUCBA0uKwcwCQYFKw4DAhoFAKBdMCMGCSqGSIb3DQEJBDEWBBT/HVS6JbEM0ul+WX8k JtYuy+u0NjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEw MjgxNzAxNDRaMA0GCSqGSIb3DQEBAQUABIIBAA8HAdlBk6JOHVrSCjjpKCVrnDBBREZkkFLs ZJ7KCMng0xL3ba2pkQc3jwxYSbYtCJgeYN4uCOTVqD3vJ06HpjPftyHwgGpm7ALQxxcCkABN CcfZu8R6qa+DZ6331KVZmFCfIcAG1hPj7sMY3F7ROvT/LNC8eWkET2hNyvAuaS7ObLXdB7Pe 6C/7/W6vxaXqwon2ZugTTa+V7jmadZduosxbzPxMQVWNlSX37ic5iDEJyfa62fdvWQgfw9jJ 5GFIhrAsKKc04ddP4oweTCYL07B4eFGnNdGg0MNbxcI816DoJCtv5Mej84g7Ii2gz+O224zf lcnQRoT1Vnh3I9S66O8= --B_3339597704_17342512-- From randy_presuhn@mindspring.com Wed Oct 28 10:31:47 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221DC3A6925 for ; Wed, 28 Oct 2009 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z9s67myJhL3 for ; Wed, 28 Oct 2009 10:31:46 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 4644A3A6847 for ; Wed, 28 Oct 2009 10:31:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=KPksRffmy84cMne75ElJMH403CRv/c2hA4d+nWzGZAw43SEeQuSYj56JkCwnUnoK; 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.23.160.219] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1N3CNL-0001Qc-AJ for opsawg@ietf.org; Wed, 28 Oct 2009 13:31:59 -0400 Message-ID: <002c01ca57f4$d566c7c0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Wed, 28 Oct 2009 10:33:58 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8881afdcb5313ff34f966e41cae84dc47cf29a2df3ca2ef7ecc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.23.160.219 Subject: Re: [OPSAWG] call for opsawg agenda time requests X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 17:31:47 -0000 Hi - > From: "Juergen Quittek" > To: ; "David Harrington" ; "Dan Romascanu" > Cc: > Sent: Wednesday, October 28, 2009 10:15 AM > Subject: Re: [OPSAWG] call for opsawg agenda time requests ... The entity MIB does a good job at representing containment / component-of relationships. Representing "virtual" thingies is a reasonable "extension" (if it even requires an extension). But where this proposal leads is to a complementary capability for representing connectivity relationships existing between those entities. Randy From rfc-editor@rfc-editor.org Wed Oct 28 12:22:12 2009 Return-Path: X-Original-To: opsawg@core3.amsl.com Delivered-To: opsawg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AB9728C215; Wed, 28 Oct 2009 12:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.931 X-Spam-Level: X-Spam-Status: No, score=-16.931 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q62F0b8qqyIe; Wed, 28 Oct 2009 12:22:11 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 48EC828C213; Wed, 28 Oct 2009 12:22:11 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 32C67356BC3; Wed, 28 Oct 2009 12:19:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091028191921.32C67356BC3@bosco.isi.edu> Date: Wed, 28 Oct 2009 12:19:21 -0700 (PDT) X-Mailman-Approved-At: Thu, 29 Oct 2009 06:39:22 -0700 Cc: opsawg@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSAWG] RFC 5674 on Alarms in Syslog X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:22:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5674 Title: Alarms in Syslog Author: S. Chisholm, R. Gerhards Status: Standards Track Date: October 2009 Mailbox: schishol@nortel.com, rgerhards@adiscon.com Pages: 7 Characters: 13837 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-opsawg-syslog-alarm-02.txt URL: http://www.rfc-editor.org/rfc/rfc5674.txt This document describes how to send alarm information in syslog. It includes the mapping of ITU perceived severities onto syslog message fields. It also includes a number of alarm-specific SD-PARAM definitions from X.733 and the IETF Alarm MIB. [STANDARDS TRACK] This document is a product of the Operations and Management Area Working Group Working Group of the IETF. This is now a Proposed 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 USC/Information Sciences Institute