From opsawg-bounces@ietf.org Thu Jul 05 16:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6XYm-0005P5-U7; Thu, 05 Jul 2007 16:04:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6XYm-0005Oq-7r for opsawg@ietf.org; Thu, 05 Jul 2007 16:04:16 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6XYl-0002mT-VN for opsawg@ietf.org; Thu, 05 Jul 2007 16:04:16 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B1AD86524 for ; Thu, 5 Jul 2007 22:03:51 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07985-07; Thu, 5 Jul 2007 22:03:47 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9313E9AE; Thu, 5 Jul 2007 22:03:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F168B2BDAD1; Thu, 5 Jul 2007 22:03:46 +0200 (CEST) Date: Thu, 5 Jul 2007 22:03:46 +0200 From: Juergen Schoenwaelder To: opsawg@ietf.org Message-ID: <20070705200346.GA4586@elstar.local> Mail-Followup-To: opsawg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [OPSAWG] status SNMP context engineid discovery draft X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, I have posted the context engineID discovery draft as draft-ietf-opsawg-snmp-engineid-discovery-00.txt (last version was draft-schoenw-snmp-discover-02.txt). I believe the document is fairly complete - this version incorporates mostly editorial and formatting changes. It would be nice to have people read and review this document. If you take away all the boilerplate and references, then there are about 5 pages left to be read. If you read the document and you feel it is ready for WG last call, let the chairs know about it. /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://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Jul 12 08:08:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xSs-0005c4-8k; Thu, 12 Jul 2007 08:08:10 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1I8xSr-0005bJ-7V for opsawg-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 08:08:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8xSq-0005Zv-T1 for opsawg@ietf.org; Thu, 12 Jul 2007 08:08:08 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8xSq-0007g8-Lb for opsawg@ietf.org; Thu, 12 Jul 2007 08:08:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 12 Jul 2007 08:07:35 -0400 X-IronPort-AV: i="4.16,532,1175486400"; d="scan'208"; a="41517298:sNHT7106988" 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, 12 Jul 2007 14:06:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments and questions on http://www.ietf.org/internet-drafts/draft-ietf-opsawg-snmp-engineid-discovery-00.txt Thread-Index: AcfEfSYeLiQd4junR5CTZclTE8RhsA== From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: opsawg@ietf.org Subject: [OPSAWG] Comments and questions on http://www.ietf.org/internet-drafts/draft-ietf-opsawg-snmp-engineid-discovery-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org 1. This standard seems to update RFC 3411. I suggest this to be mentioned in the document header and in the Abstract 2. Section 3.2: The SnmpEngineID textual convention defines that an snmpEngineID value MUST be between 5 and 12 octets long. =20 Is not this between 5 and 32? According to the TC definition only in length format 2) the size is 12, but we are using variable length format 3) lor the localEngineID.=20 3. In the IANA considerations - should the proposed new registry apply only for enterprise ID zero?=20 Thanks and Regards, Dan (speaking as contributor) =20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Jul 12 16:22:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95BX-0008Nd-80; Thu, 12 Jul 2007 16:22:47 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1I95BW-0008N6-Fl for opsawg-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 16:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I95BW-0008Mn-4g for opsawg@ietf.org; Thu, 12 Jul 2007 16:22:46 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I95BH-0004bd-8X for opsawg@ietf.org; Thu, 12 Jul 2007 16:22:46 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 875C686498; Thu, 12 Jul 2007 22:22:30 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06399-06; Thu, 12 Jul 2007 22:22:26 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 761F4995; Thu, 12 Jul 2007 22:22:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1BFF22C8003; Thu, 12 Jul 2007 22:22:25 +0200 (CEST) Date: Thu, 12 Jul 2007 22:22:24 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20070712202224.GB8737@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , opsawg@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: opsawg@ietf.org Subject: [OPSAWG] Re: Comments and questions on http://www.ietf.org/internet-drafts/draft-ietf-opsawg-snmp-engineid- discovery-00.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org On Thu, Jul 12, 2007 at 02:06:59PM +0200, Romascanu, Dan (Dan) wrote: > 1. This standard seems to update RFC 3411. I suggest this to be > mentioned in the document header and in the Abstract Added in my xml sources. > 2. Section 3.2: > > The SnmpEngineID textual convention defines that an snmpEngineID > value MUST be between 5 and 12 octets long. > > Is not this between 5 and 32? According to the TC definition only in > length format 2) the size is 12, but we are using variable length format > 3) lor the localEngineID. Good catch. I have fixed this in my xml sources. > 3. In the IANA considerations - should the proposed new registry apply > only for enterprise ID zero? I am surprised by the question since the registry is for format values in general. The specific allocation 6 happens to use the enterprise ID zero but that surely should not be imposed on other future formats. Why did the text lead you to believe that this is only for allocations that use enterprise ID zero? The text in the IANA considerations section just talks about an enterprise number followed by a format value. /js PS: Thanks for taking the time to review the document. -- 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://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Jul 19 13:52:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaB1-0001gE-FG; Thu, 19 Jul 2007 13:52:35 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IBaB0-0001g9-SB for opsawg-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 13:52:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaAx-0001fz-E0 for opsawg@ietf.org; Thu, 19 Jul 2007 13:52:31 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaAx-000818-3A for opsawg@ietf.org; Thu, 19 Jul 2007 13:52:31 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6JHqSF02730 for ; Thu, 19 Jul 2007 17:52:28 GMT 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, 19 Jul 2007 13:52:07 -0400 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B410059D0E@zcarhxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Alarms in SYSLOG Thread-Index: AcfKLYXmm1RtFqKARAGKthpmo+vARQ== From: "Sharon Chisholm" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [OPSAWG] Alarms in SYSLOG X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi It has been suggested that this might be a good home for this draft http://www.ietf.org/internet-drafts/draft-gerhards-chisholm-syslog-alarm -00.txt Note that I have already received the feedback that we likely don't want alarmedResource(syslog) to be tied to alarmActiveResourceId(SNMP). A separate field should be introduce to provide this link. Please let me know if you have any comments or suggestions. Thanks, Sharon Chisholm Nortel=20 Ottawa, Ontario Canada _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jul 22 14:43:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICgPE-0006pe-Bg; Sun, 22 Jul 2007 14:43:48 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1ICgPD-0006p6-8h for opsawg-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 14:43:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICgPB-0006oV-WB; Sun, 22 Jul 2007 14:43:46 -0400 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICgPB-0007v5-Ky; Sun, 22 Jul 2007 14:43:45 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Jul 2007 14:43:44 -0400 X-IronPort-AV: i="4.16,569,1175486400"; d="scan'208"; a="40828495:sNHT8503092" 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: Sun, 22 Jul 2007 20:43:03 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Office Hours Thread-Index: AcfMkCKQ0tfyT6lXQmasVB8laEJ8Wg== From: "Romascanu, Dan (Dan)" To: , , "Netconf (E-mail)" , , "Aaa-Doctors (E-mail)" , "Ops-Nm" , "capwap" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [OPSAWG] OPS Area Office Hours X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org I apologize for the cross-posting, which is definitely intentional in this case.=20 We remind everybody that the OPS Area Directors will be waiting for you to come at the office hours to discuss current and future work in the area and any other IETF related business.=20 The office hours will happen in the IESG meeting room PDR-4 (standing for Private Dining Room I guess) at the 3rd floor in the Palmer House and the schedule is as follows: Monday 9:00AM to 11:30AM Wednesday 4:10PM to 5:00PM Thursday 4:10PM to 5:00PM See you there.=20 Ron and Dan =20 _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Jul 23 12:14:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0Xx-0003Ip-2T; Mon, 23 Jul 2007 12:14:09 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1ICy6f-0001yZ-P0 for opsawg-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 09:37:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICy6c-0001rU-6f for opsawg@ietf.org; Mon, 23 Jul 2007 09:37:46 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICy6b-0005Jc-JJ for opsawg@ietf.org; Mon, 23 Jul 2007 09:37:46 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLM0035TWHBH4@usaga01-in.huawei.com> for opsawg@ietf.org; Mon, 23 Jul 2007 06:36:47 -0700 (PDT) Received: from huawei.com ([172.18.9.13]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLM00M6HWHBL6@usaga01-in.huawei.com> for opsawg@ietf.org; Mon, 23 Jul 2007 06:36:47 -0700 (PDT) Received: from [172.18.4.6] (Forwarded-For: [67.97.210.2]) by usams02-in.huawei.com (mshttpd); Mon, 23 Jul 2007 09:35:06 -0400 Date: Mon, 23 Jul 2007 09:35:06 -0400 From: HarringtonDavid 73653 To: opsawg@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_8uuet1HL84UxsaioDOdDzQ)" Content-language: en X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 X-Mailman-Approved-At: Mon, 23 Jul 2007 12:14:07 -0400 Subject: [OPSAWG] Fwd: Re: I-D ACTION:draft-harrington-operations-and-management-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_8uuet1HL84UxsaioDOdDzQ) Content-type: message/rfc822 Content-disposition: inline Return-path: Return-path: Received: from huawei.com ([172.24.2.3]) by usams02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLL00I4JMS2J4@usams02-in.huawei.com> for dharrington@huawei.com; Sun, 22 Jul 2007 16:09:39 -0500 (CDT) Received: from szxga01-in (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 <0JLL005A9MUU7L@szxga01-in.huawei.com> for dharrington@huawei.com; Mon, 23 Jul 2007 05:11:18 +0800 (CST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLL00C2WMUR61@szxga01-in.huawei.com> for dharrington@huawei.com (ORCPT dharrington@huawei.com); Mon, 23 Jul 2007 05:11:18 +0800 (CST) Received: by ug-out-1314.google.com with SMTP id q2so953998uge for ; Sun, 22 Jul 2007 14:11:15 -0700 (PDT) Received: by 10.67.93.7 with SMTP id v7mr3694391ugl.1185138674958; Sun, 22 Jul 2007 14:11:14 -0700 (PDT) Received: from ?172.28.171.186? ( [67.97.210.2]) by mx.google.com with ESMTPS id f4sm20480345nfh.2007.07.22.14.11.11 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Jul 2007 14:11:12 -0700 (PDT) Date: Sun, 22 Jul 2007 23:11:10 +0200 From: Brian E Carpenter Subject: Re: I-D ACTION:draft-harrington-operations-and-management-01.txt In-reply-to: To: dharrington@huawei.com Cc: Dan Romascanu , Ron Bonica Message-id: <46A3C7EE.5040204@gmail.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 7BIT DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AxwejGleAzuzb5T3Akkq6N4Xm/+ggSGPrbj5DsB91SJt/pgWSQkSovl5i7A1c8OMthmcM523AHhDnk7zaxY75VJA+EEtZ/ld7R8RNSn/WhoAZGmPbvKTBu8GK1/jFR5CKoAAySHqTJh4tKSXk4pGnLBXXf+T/gAfUbwzDr9nMZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=klhxzaBR8SD72NqfXpxzn9Sn27fWTQgaVSt39i8+KYp+PCztX+uDDpxvnVNR7SdWI2ziA+EHjkoWykV+EdrwMPpyHmIX4JOGq/k0dp7VUFLzqNC84NQhBqwSjQY3m9iOvmI55AWBosoQROhTuXuj/3kX3kBpqPhfsvGAo+2fecY= User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) References: Original-recipient: rfc822;@usams02-in.huawei.com:dharrington@huawei.com Dave, I'm not sure where this is being discussed, so feel free to forward these comments, or not, as you feel useful. One general point I thought was missing was some discussion of which protocols need O&M considerations more than others. (For example, I can imagine being much more concerned to instrument the server end of a client/server protocol.) > 3. Operational Considerations ... > Operations and manageability considerations should focus on on-the- > wire interoperability, and not constrain implementation decisions. I don't understand this, and the more often I read it the less I understand it. The first half (on-the-wire interop) really doesn't mean anything specific to me for O&M, and the second half seems directly in conflict with other guidelines such as defining default values for config parameters. If it means "focus on externally observable behaviors" that would be fine, but then say so ;-) > 4. Management Considerations ... > Getting everybody to agree on a certain syntax and the protocol > associated with that has proven to be difficult. So management > systems tend to speak whatever the boxes support, whether the IETF > likes this or not. The IETF is moving from support for a single > management data modeling language and a single management protocol > towards support for multiple management protocols and multiple data > models suited to different purposes. This seems to be the place to mention that other SDOs (e.g. DMTF, TMF) also define management mechanisms and that these mechanisms may be more suitable than IETF mechanisms in some cases. > 4.2.1. Liveness Detection and Monitoring > > Liveness detection and monitoring applies both to the control plane > and the data plane. 'control plane' and 'data plane' are such slippery terms that I think they need to be defined. > 4.3. Configuration Management > ... > It is highly desirable that text processing tools such as diff, and > version management tools such as RCS or CVS or SVN, can be used to > process configurations. This approach simplifies comparing the > current operational state to the initial configuration. If we are including XML config in the scope, simple text diffs are basically useless and more sophisticated tools are needed to make any useful comparison of versions. > 5. Existing Protocols ... > We want to avoid seeming to impose a solution by putting in place > a strict terminology - for example implying that a formal data model, > or even using a management protocol is mandatory. If a WG considers > that its technology can be managed solely by using proprietary CLIs, > and no structured or standardzied data model needs to be in place, > this should be fine, but this is a requirement that needs to be > explicit in their manageability section, Consistency issue: later you say that there is no required section. > 6.4. Performance Management You could mention the IPPM and BMWG work. > 7. Documentation Guidelines ... > Making a Management Considerations section a mandatory publication > requirement is the responsibility of the IESG, or specific area > directors, or working groups, and this document avoids recommending > any mandatory publication requirements. Good. You might also comment that for a complex protocol, a completely separate draft on O&M might be appropriate. Or even a completely separate WG. Hope this helps. Brian --Boundary_(ID_8uuet1HL84UxsaioDOdDzQ) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg --Boundary_(ID_8uuet1HL84UxsaioDOdDzQ)-- From opsawg-bounces@ietf.org Mon Jul 23 12:14:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0Xx-0003J1-6G; Mon, 23 Jul 2007 12:14:09 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1ID0WG-0002m7-61 for opsawg-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 12:12:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0WF-0002lz-RO for opsawg@ietf.org; Mon, 23 Jul 2007 12:12:23 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0WF-000166-8L for opsawg@ietf.org; Mon, 23 Jul 2007 12:12:23 -0400 Received: from harrington73653 (dhcp-108c.ietf69.org[130.129.16.140]) by comcast.net (rwcrmhc12) with SMTP id <20070723161222m1200f3j6de>; Mon, 23 Jul 2007 16:12:22 +0000 From: "David Harrington" To: Date: Mon, 23 Jul 2007 11:12:24 -0500 Message-ID: <007001c7cd44$460bd800$79aa1cac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfMpJ1aW+QG4yRNQdyJIjsyh7QuZAAl79zA X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 X-Mailman-Approved-At: Mon, 23 Jul 2007 12:14:07 -0400 Subject: [OPSAWG] FW: I-D ACTION:draft-harrington-operations-and-management-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org I'm not sure my earlier forward of Brian's comments will be readable, so I am resending. David Harrington dbharrington@comcast.net ietfdbh@comcast.net -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] Sent: Sunday, July 22, 2007 4:11 PM To: dharrington@huawei.com Cc: Dan Romascanu; Ron Bonica Subject: Re: I-D ACTION:draft-harrington-operations-and-management-01.txt Dave, I'm not sure where this is being discussed, so feel free to forward these comments, or not, as you feel useful. One general point I thought was missing was some discussion of which protocols need O&M considerations more than others. (For example, I can imagine being much more concerned to instrument the server end of a client/server protocol.) > 3. Operational Considerations ... > Operations and manageability considerations should focus on on-the- > wire interoperability, and not constrain implementation decisions. I don't understand this, and the more often I read it the less I understand it. The first half (on-the-wire interop) really doesn't mean anything specific to me for O&M, and the second half seems directly in conflict with other guidelines such as defining default values for config parameters. If it means "focus on externally observable behaviors" that would be fine, but then say so ;-) > 4. Management Considerations ... > Getting everybody to agree on a certain syntax and the protocol > associated with that has proven to be difficult. So management > systems tend to speak whatever the boxes support, whether the IETF > likes this or not. The IETF is moving from support for a single > management data modeling language and a single management protocol > towards support for multiple management protocols and multiple data > models suited to different purposes. This seems to be the place to mention that other SDOs (e.g. DMTF, TMF) also define management mechanisms and that these mechanisms may be more suitable than IETF mechanisms in some cases. > 4.2.1. Liveness Detection and Monitoring > > Liveness detection and monitoring applies both to the control plane > and the data plane. 'control plane' and 'data plane' are such slippery terms that I think they need to be defined. > 4.3. Configuration Management > ... > It is highly desirable that text processing tools such as diff, and > version management tools such as RCS or CVS or SVN, can be used to > process configurations. This approach simplifies comparing the > current operational state to the initial configuration. If we are including XML config in the scope, simple text diffs are basically useless and more sophisticated tools are needed to make any useful comparison of versions. > 5. Existing Protocols ... > We want to avoid seeming to impose a solution by putting in place > a strict terminology - for example implying that a formal data model, > or even using a management protocol is mandatory. If a WG considers > that its technology can be managed solely by using proprietary CLIs, > and no structured or standardzied data model needs to be in place, > this should be fine, but this is a requirement that needs to be > explicit in their manageability section, Consistency issue: later you say that there is no required section. > 6.4. Performance Management You could mention the IPPM and BMWG work. > 7. Documentation Guidelines ... > Making a Management Considerations section a mandatory publication > requirement is the responsibility of the IESG, or specific area > directors, or working groups, and this document avoids recommending > any mandatory publication requirements. Good. You might also comment that for a complex protocol, a completely separate draft on O&M might be appropriate. Or even a completely separate WG. Hope this helps. Brian _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jul 24 17:07:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRb7-0008TS-Su; Tue, 24 Jul 2007 17:07:13 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IDRb6-0008Sh-VN for opsawg-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:07:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRb2-0008SR-K2 for opsawg@ietf.org; Tue, 24 Jul 2007 17:07:08 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDRb2-0006qd-BK for opsawg@ietf.org; Tue, 24 Jul 2007 17:07:08 -0400 Received: by newdev.harvard.edu (Postfix, from userid 501) id 06A94448314; Tue, 24 Jul 2007 17:07:37 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20070724210737.06A94448314@newdev.harvard.edu> Date: Tue, 24 Jul 2007 17:07:37 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [OPSAWG] use of RFC 2119 terms in non-standards documents X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org I mentioned during the session todya that there is some pushback on the use of RFC 2119 terms on non standards documents see draft-harrington-operations-and-management-01.txt section 1.1 for a discussion on this point Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jul 24 17:38:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS5Z-0001Is-Ld; Tue, 24 Jul 2007 17:38:41 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IDS5Y-0001Gf-56 for opsawg-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:38:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS5X-0001GV-Py for opsawg@ietf.org; Tue, 24 Jul 2007 17:38:39 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDS5X-0003gb-HT for opsawg@ietf.org; Tue, 24 Jul 2007 17:38:39 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 24 Jul 2007 14:38:40 -0700 X-IronPort-AV: i="4.16,575,1175497200"; d="scan'208"; a="42992127:sNHT29963696" Received: from [172.23.1.113] ([172.23.1.113] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 17:38:38 -0400 Message-ID: <46A6715B.5050501@juniper.net> Date: Tue, 24 Jul 2007 17:38:35 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: opsawg@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 21:38:38.0225 (UTC) FILETIME=[FED69810:01C7CE3A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [OPSAWG] draft-kikuchi-tunnel-measure-req-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Folks, How will the mechanism described in draft-kikuchi-tunnel-measure-req-01 be deployed? Will it be deployed only occasionally, on a single tunnel, as part of a debugging exercise? Or will it be deployed all the time, on all tunnels, in a production network. If the later, how is the mechanism secured? If a malicious third party injects a packet with a random sequence number into a stream, would the mechanism behave badly? Ron _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jul 24 17:41:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS8g-0002Td-TY; Tue, 24 Jul 2007 17:41:54 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IDS8g-0002T2-9d for opsawg-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:41:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS8f-0002St-W8 for opsawg@ietf.org; Tue, 24 Jul 2007 17:41:53 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDS8f-0003kP-KS for opsawg@ietf.org; Tue, 24 Jul 2007 17:41:53 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED15C259738; Tue, 24 Jul 2007 23:41:52 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05064-10; Tue, 24 Jul 2007 23:41:48 +0200 (CEST) Received: from htat43p-no.corp.google.com (dhcp-12ed.ietf69.org [130.129.18.237]) by eikenes.alvestrand.no (Postfix) with ESMTP id A9D72259737; Tue, 24 Jul 2007 23:41:47 +0200 (CEST) Date: Tue, 24 Jul 2007 16:40:29 -0500 From: Harald Tveit Alvestrand To: ietfdbh@comcast.net, opsawg@ietf.org Message-ID: X-Mailer: Mulberry/4.0.7 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Subject: [OPSAWG] Comments on draft-harrington-operations-and-management-01 X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Repeating what I said in the room: This is an useful document, with lots of good advice. But its scope is sharply limited, and not in ways that everyone will expect given the title of "management". 1) The document, for better or worse, talks about management of a protocol endpoint on a single device. Despite its title, it doesn't talk about managing the *protocol* (it manages one end at a time), and doesn't even come near managing the *service* (which includes a lot of stuff that's very far away from the box). (retreat on that: there are some elements, like "consider whether you need billing data", that touch on larger scopes. I believe it is wise to retreat from those forays into unknown territory, and rather talk about "producing data that is useful for a billing service"). 2) The document needs to clearly point out that one needs to identify the *entities* to be managed - what the participants in the protocol are, and how they are tied to manageable entities. This has been an enormous source of confusion in security ("WHO is being authorized by this certificate?"), and will be no less of a source of confusion in management if the protocol designers don't get it right. With those two things made clear, I think this has the potential of being an extremely useful document. Harald _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jul 24 17:46:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSCl-0006t3-Dl; Tue, 24 Jul 2007 17:46:07 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IDSCj-0006qR-Nv for opsawg-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:46:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSCj-0006q0-AX for opsawg@ietf.org; Tue, 24 Jul 2007 17:46:05 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDSCj-0007ex-1J for opsawg@ietf.org; Tue, 24 Jul 2007 17:46:05 -0400 Received: by newdev.harvard.edu (Postfix, from userid 501) id E4F4E448592; Tue, 24 Jul 2007 17:46:33 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20070724214633.E4F4E448592@newdev.harvard.edu> Date: Tue, 24 Jul 2007 17:46:33 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [OPSAWG] draft-kikuchi-tunnel-measure-req-01: "passive" X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org it seems to me that calling this technology "passive" when it can modify packets on the fly is not accurate - I'm not sure what better to say - maybe just do not try to characterize it as active or passive Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jul 24 18:01:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSRs-0002Nk-Ao; Tue, 24 Jul 2007 18:01:44 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IDSRq-0002Nd-J3 for opsawg-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 18:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSRp-0002NV-Vx for opsawg@ietf.org; Tue, 24 Jul 2007 18:01:42 -0400 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDSRp-00044x-PY for opsawg@ietf.org; Tue, 24 Jul 2007 18:01:41 -0400 Received: by newdev.harvard.edu (Postfix, from userid 501) id C1108448643; Tue, 24 Jul 2007 18:02:10 -0400 (EDT) To: opsawg@ietf.org Message-Id: <20070724220210.C1108448643@newdev.harvard.edu> Date: Tue, 24 Jul 2007 18:02:10 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [OPSAWG] draft-kikuchi-tunnel-measure-req-01: metrics X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org In general, IETF working groups are encouraged to reuse existing IETF technology when they can rather than invent new technologies to do basically the same thing. Since the IPPM working group has defined a number of methodologies for the types of metrics measurement proposed in this ID the authors should use those methodologies if possible or discuss the reasons that it is not appropriate Scott _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Thu Jul 26 20:33:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEDm7-000448-Sk; Thu, 26 Jul 2007 20:33:47 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IEDm6-000443-JB for opsawg-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 20:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEDm2-00043s-ES for opsawg@ietf.org; Thu, 26 Jul 2007 20:33:42 -0400 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEDm2-0004cC-5i for opsawg@ietf.org; Thu, 26 Jul 2007 20:33:42 -0400 Received: from 12.140.64.135.in-addr.arpa (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-outbound.avaya.com with ESMTP; 26 Jul 2007 20:33:41 -0400 X-IronPort-AV: i="4.16,585,1175486400"; d="scan'208"; a="43226979:sNHT8626140" 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 Subject: RE: [OPSAWG] Comments on draft-harrington-operations-and-management-01 Date: Fri, 27 Jul 2007 02:33:19 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] Comments on draft-harrington-operations-and-management-01 Thread-Index: AcfOO3hizxGXVGsWRCC8u2QKoXc23wBqcrNg References: From: "Romascanu, Dan (Dan)" To: "Harald Tveit Alvestrand" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org =20 =20 > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@alvestrand.no]=20 > 2) The document needs to clearly point out that one needs to=20 > identify the > *entities* to be managed - what the participants in the=20 > protocol are, and how they are tied to manageable entities.=20 > This has been an enormous source of confusion in security=20 > ("WHO is being authorized by this certificate?"), and will be=20 > no less of a source of confusion in management if the=20 > protocol designers don't get it right. >=20 > With those two things made clear, I think this has the=20 > potential of being an extremely useful document. >=20 > Harald >=20 I would like to support this point of Harald. In my opinion the manageability considerations should start from describing the operational model, which includes identifying the entities to be managed, how the respective protocol is supposed to be installed, configured and monitored, who are the managers and what type of management interfaces and protocols they would use.=20 Dan _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jul 29 04:08:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF3p1-0007fy-1F; Sun, 29 Jul 2007 04:08:15 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IF3oz-0007eL-1N for opsawg-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 04:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF3ov-0007bZ-Go for opsawg@ietf.org; Sun, 29 Jul 2007 04:08:09 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IF3ou-00054O-KR for opsawg@ietf.org; Sun, 29 Jul 2007 04:08:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-outbound.avaya.com with ESMTP; 29 Jul 2007 04:08:07 -0400 X-IronPort-AV: i="4.19,195,1183348800"; d="scan'208"; a="47842308:sNHT13523418" 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: Sun, 29 Jul 2007 10:07:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-harrington-operations-and-management-01.txt Thread-Index: AcfOOkkMQJVbLxU+THWhlFSgfjgChgCn/JcQ From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [OPSAWG] FW: I-D ACTION:draft-harrington-operations-and-management-01.txt X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org =20 Comments from Brian Carpenter.=20 Regards, Dan =20 -----Original Message----- From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]=20 Sent: Wednesday, July 25, 2007 12:33 AM To: ietfdbh@comcast.net Cc: Romascanu, Dan (Dan); Ron Bonica Subject: Re: I-D ACTION:draft-harrington-operations-and-management-01.txt Dave, It's very likely you didn't see this before, due to a bad address. Feel free to forward if desired. One general point I thought was missing was some discussion of which protocols need O&M considerations more than others. (For example, I can imagine being much more concerned to instrument the server end of a client/server protocol.) > 3. Operational Considerations ... > Operations and manageability considerations should focus on on-the-=20 > wire interoperability, and not constrain implementation decisions. I don't understand this, and the more often I read it the less I understand it. The first half (on-the-wire interop) really doesn't mean anything specific to me for O&M, and the second half seems directly in conflict with other guidelines such as defining default values for config parameters. If it means "focus on externally observable behaviors" that would be fine, but then say so ;-) > 4. Management Considerations ... > Getting everybody to agree on a certain syntax and the protocol=20 > associated with that has proven to be difficult. So management=20 > systems tend to speak whatever the boxes support, whether the IETF=20 > likes this or not. The IETF is moving from support for a single=20 > management data modeling language and a single management protocol=20 > towards support for multiple management protocols and multiple data=20 > models suited to different purposes. This seems to be the place to mention that other SDOs (e.g. DMTF, TMF) also define management mechanisms and that these mechanisms may be more suitable than IETF mechanisms in some cases. > 4.2.1. Liveness Detection and Monitoring > > Liveness detection and monitoring applies both to the control plane=20 > and the data plane. 'control plane' and 'data plane' are such slippery terms that I think they need to be defined. > 4.3. Configuration Management > ... > It is highly desirable that text processing tools such as diff, and=20 > version management tools such as RCS or CVS or SVN, can be used to=20 > process configurations. This approach simplifies comparing the=20 > current operational state to the initial configuration. If we are including XML config in the scope, simple text diffs are basically useless and more sophisticated tools are needed to make any useful comparison of versions. > 5. Existing Protocols ... > We want to avoid seeming to impose a solution by putting in place a=20 > strict terminology - for example implying that a formal data model, or > even using a management protocol is mandatory. If a WG considers that > its technology can be managed solely by using proprietary CLIs, and no > structured or standardzied data model needs to be in place, this=20 > should be fine, but this is a requirement that needs to be explicit in > their manageability section, Consistency issue: later you say that there is no required section. > 6.4. Performance Management You could mention the IPPM and BMWG work. > 7. Documentation Guidelines ... > Making a Management Considerations section a mandatory publication=20 > requirement is the responsibility of the IESG, or specific area=20 > directors, or working groups, and this document avoids recommending=20 > any mandatory publication requirements. Good. You might also comment that for a complex protocol, a completely separate draft on O&M might be appropriate. Or even a completely separate WG. Hope this helps. Brian _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jul 29 04:23:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF445-00061E-Jq; Sun, 29 Jul 2007 04:23:49 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IESWp-0003Xn-Nf for opsawg-confirm+ok@megatron.ietf.org; Fri, 27 Jul 2007 12:18:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IESWl-0003W9-SJ for opsawg@ietf.org; Fri, 27 Jul 2007 12:18:55 -0400 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IESWl-0008RI-Gs for opsawg@ietf.org; Fri, 27 Jul 2007 12:18:55 -0400 Received: (qmail 14025 invoked by uid 0); 27 Jul 2007 16:11:14 -0000 Received: by simscan 1.2.0 ppid: 14013, pid: 14017, t: 0.7623s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: **** X-Spam-Status: No, score=4.2 required=6.2 tests=ALL_TRUSTED,BAYES_99 autolearn=disabled version=3.2.1 Received: from unknown (HELO Harrington73653) (ietfdbh@67.97.210.2) by hiltonsmtp.worldspice.net with ESMTPA; 27 Jul 2007 16:11:14 -0000 From: "David Harrington" To: Date: Fri, 27 Jul 2007 11:18:44 -0500 Message-ID: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfQac2Ojb81cPnxSjOcaS901pQt3w== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Sun, 29 Jul 2007 04:23:48 -0400 Subject: [OPSAWG] SMI-to-XSD mapping work X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, The XSDMI BOF proposed the creation of a WG to develop 1) the XSD equivalents of datatypes and textual conventions from SMIv2, 2) algorithms to translate MIB module specifications into XSD equivalents, 3) Netconf operations to access MIB data, and 4) a draft documenting security requirements for protocols accessing the MIB. The BOF demonstrated community support for the first two objectives. The third objective should be moved to a Netconf-specific WG. There was a lack of support for the fourth objective. People in the BOF volunteered to commit to being editors (3) and reviewers (14) for the first two objectives. Starting documents and implementations already exist. The work is expected to take less than 12 months. Rather than starting a new WG for achieving the first two objectives, I would like to propose this protocol-independent work be done in the OPSAWG. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jul 29 04:37:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF4HS-0006LP-Ge; Sun, 29 Jul 2007 04:37:38 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IF4HR-0006K0-T0 for opsawg-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 04:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF4HR-0006Hp-IG for opsawg@ietf.org; Sun, 29 Jul 2007 04:37:37 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IF4HQ-0002bj-3L for opsawg@ietf.org; Sun, 29 Jul 2007 04:37:37 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F79F99F; Sun, 29 Jul 2007 10:37:35 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 09737-09; Sun, 29 Jul 2007 10:37:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7132C988; Sun, 29 Jul 2007 10:37:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0705B2F25B8; Sun, 29 Jul 2007 10:37:30 +0200 (CEST) Date: Sun, 29 Jul 2007 10:37:30 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [OPSAWG] SMI-to-XSD mapping work Message-ID: <20070729083730.GA6607@elstar.local> Mail-Followup-To: David Harrington , opsawg@ietf.org References: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org On Fri, Jul 27, 2007 at 11:18:44AM -0500, David Harrington wrote: > The XSDMI BOF proposed the creation of a WG to develop 1) the XSD > equivalents of datatypes and textual conventions from SMIv2, 2) > algorithms to translate MIB module specifications into XSD > equivalents, 3) Netconf operations to access MIB data, and 4) a > draft documenting security requirements for protocols accessing the > MIB. The BOF demonstrated community support for the first two > objectives. The third objective should be moved to a > Netconf-specific WG. There was a lack of support for the fourth > objective. As long as NETCONF data modeling is completely undefined, developing XSDs for data types and SMIv2 MIB module translations for use with NETCONF will constrain any future NETCONF standards-track data modeling work. I don't want to discourage people from doing work on accessing SNMP instrumentation via NETCONF; but I have a serious concern if the goal is to produce standards-track specifications for 1) and 2) for the reason mentioned above. /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://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Sun Jul 29 05:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF4ni-0000TU-F3; Sun, 29 Jul 2007 05:10:58 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IF4nh-0000TO-1d for opsawg-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 05:10:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IF4ng-0000TE-ND for opsawg@ietf.org; Sun, 29 Jul 2007 05:10:56 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IF4ng-0004r2-8x for opsawg@ietf.org; Sun, 29 Jul 2007 05:10:56 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-outbound.avaya.com with ESMTP; 29 Jul 2007 05:10:55 -0400 X-IronPort-AV: i="4.19,195,1183348800"; d="scan'208"; a="47850339:sNHT9116388" 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 Subject: RE: [OPSAWG] SMI-to-XSD mapping work Date: Sun, 29 Jul 2007 11:10:14 +0200 Message-ID: In-Reply-To: <20070729083730.GA6607@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSAWG] SMI-to-XSD mapping work Thread-Index: AcfRu7yaP6pmdeYtTWiOpodcGrZGtQAA5aCg References: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> <20070729083730.GA6607@elstar.local> From: "Romascanu, Dan (Dan)" To: , "David Harrington" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Sunday, July 29, 2007 11:38 AM > To: David Harrington > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] SMI-to-XSD mapping work >=20 > On Fri, Jul 27, 2007 at 11:18:44AM -0500, David Harrington wrote: >=20 > > The XSDMI BOF proposed the creation of a WG to develop 1) the XSD=20 > > equivalents of datatypes and textual conventions from SMIv2, 2)=20 > > algorithms to translate MIB module specifications into XSD=20 > > equivalents, 3) Netconf operations to access MIB data, and=20 > 4) a draft=20 > > documenting security requirements for protocols accessing=20 > the MIB. The=20 > > BOF demonstrated community support for the first two=20 > objectives. The=20 > > third objective should be moved to a Netconf-specific WG.=20 > There was a=20 > > lack of support for the fourth objective. >=20 > As long as NETCONF data modeling is completely undefined,=20 > developing XSDs for data types and SMIv2 MIB module=20 > translations for use with NETCONF will constrain any future=20 > NETCONF standards-track data modeling work. >=20 > I don't want to discourage people from doing work on=20 > accessing SNMP instrumentation via NETCONF; but I have a=20 > serious concern if the goal is to produce standards-track=20 > specifications for 1) and 2) for the reason mentioned above. >=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 >=20 Hi Juergen, I am not sure that I follow. Why would be somebody constrained to develop data models for NETCONF?=20 As I understand David's proposal, he is not targeting NETCONF only. Although NETCONF can be one possible protocol using the outputs of 1) and 2) other protocols that need XSD-expressed data could benefit. On the other hand there are clear limitations for NETCONF using only the output of such work, so that development of other data models should be pursued.=20 If the target proposed status would be experimental rather than standard-track would this ease your concerns?=20 Dan _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Jul 30 01:38:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFNxp-0000tB-H7; Mon, 30 Jul 2007 01:38:41 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IFNxo-0000t6-IT for opsawg-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 01:38:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFNxm-0000sq-TY for opsawg@ietf.org; Mon, 30 Jul 2007 01:38:38 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFNxl-0007bI-F6 for opsawg@ietf.org; Mon, 30 Jul 2007 01:38:38 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 74EDF86566; Mon, 30 Jul 2007 07:38:36 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07865-10; Mon, 30 Jul 2007 07:38:31 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8285886570; Mon, 30 Jul 2007 07:38:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 373B52F28D1; Mon, 30 Jul 2007 07:38:31 +0200 (CEST) Date: Mon, 30 Jul 2007 07:38:31 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [OPSAWG] SMI-to-XSD mapping work Message-ID: <20070730053831.GA6941@elstar.local> Mail-Followup-To: David Harrington , opsawg@ietf.org References: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> <20070729083730.GA6607@elstar.local> <000401c7d1f0$ef700280$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000401c7d1f0$ef700280$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org On Sun, Jul 29, 2007 at 10:58:29AM -0400, David Harrington wrote: > This proposed work is explicitly NOT particular to NETCONF. I have > worked hard to ensure this is NOT a NETCONF-specific work item. This > is a work item for the whole IETF, led by the OPS area. This makes my concern even stronger. [Comments continue at the end.] > The proposed SMI-to-XSD translation is targeted at providing a > protocol-independent XSD rendering of SMIv2 datatypes so any XML-based > protocol, IETF-standard or otherwise, can transport existing > management objects in XML and be able to use XSD to validate the data. > > Most MIB data is focused on monitoring information, such as statistics > and state. The MIB (with SNMP) has not been widely used for > configuration, and many MIB modules do not contain objects for > configuration or other protocol-specific specialized functionality. > Any protocol that wants to look at statistics or state for > technologies where a MIB module has already been developed for that > purpose could benefit from utilizing the same managed objects as are > used in the MIB module. NM protocols that have a different focus of > applicability, such as NETCONF, will almost certainly require a > different modeling language than SMI to entirely model their > functionality, but might still benefit from reusing existing MIB > objects for monitoring the configured technology or checking the state > following configuration. They should not be required to use SNMP to > carry the data in ASN.1 format, and an SMIv2 MIB module parser to > validate the existing data if their protocol can already carry XML, > and their application already supports XSD validation. We should > provide a standard translation to make using the MIB's managed objects > with XML/XSD easier. > > If the developers of a protocol decide that there are insufficient > benefits from reusing existing MIB data, they are not forced to do so. > > Two goals of this work are instrumentation reuse and semantics reuse. > The IETF has spent twenty years developing standard managed objects, > and vendors have supplemented that with proprietary managed objects, > all written using a standard language for expressing the syntax and > semantics. We want to preserve that work and make it available for > XML-based messaging. > > Vendors have spent a great deal of money adding "hooks" into their > instrumentation to support existing managed objects, such as counters. > Operators have spent a great deal of time learning those managed > objects, including which things a counter does and does not count. > > It would be a bad thing if NM data model designers designed new > objects that differ slightly from existing standard managed objects, > for no good reason,, thus requiring vendors to reimplement to support > the slight differences, and operators to learn the new semantics if > this is really unnecessary. If a new object would better serve the > purpose, there is nothing that constrains designers from developing a > new counter. > > If an existing managed object would work for multiple protocols, it > would be a good thing if the XSD format used to represent the existing > managed object is consistent across protocols, and properly represents > the original design of the managed object. WG review can help to > ensure that the translations are done properly. I do not question any of the motivation. My concern, however, remains that the existence of the translated XSD output will cause future data modeling languages to be "consistent" with the XSD output coming out of the translation. For me, a NETCONF data modeling language and SMIv2 translations should go hand in hand and not be separate efforts. /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://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Jul 30 06:38:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSdn-0007o3-0A; Mon, 30 Jul 2007 06:38:19 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IFADh-0000U9-9a for opsawg-confirm+ok@megatron.ietf.org; Sun, 29 Jul 2007 10:58:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFADg-0000T2-Ig for opsawg@ietf.org; Sun, 29 Jul 2007 10:58:08 -0400 Received: from alnrmhc16.comcast.net ([204.127.225.96]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFADf-00041O-V3 for opsawg@ietf.org; Sun, 29 Jul 2007 10:58:08 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc16) with SMTP id <20070729145807b1600phtvue>; Sun, 29 Jul 2007 14:58:07 +0000 From: "David Harrington" To: References: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> <20070729083730.GA6607@elstar.local> Subject: RE: [OPSAWG] SMI-to-XSD mapping work Date: Sun, 29 Jul 2007 10:58:29 -0400 Message-ID: <000401c7d1f0$ef700280$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: <20070729083730.GA6607@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfRu7bX/hMJkIZyT5OvXXlpNQ+7ugAJy/BQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-Mailman-Approved-At: Mon, 30 Jul 2007 06:38:18 -0400 Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi, This proposed work is explicitly NOT particular to NETCONF. I have worked hard to ensure this is NOT a NETCONF-specific work item. This is a work item for the whole IETF, led by the OPS area. The proposed SMI-to-XSD translation is targeted at providing a protocol-independent XSD rendering of SMIv2 datatypes so any XML-based protocol, IETF-standard or otherwise, can transport existing management objects in XML and be able to use XSD to validate the data. Most MIB data is focused on monitoring information, such as statistics and state. The MIB (with SNMP) has not been widely used for configuration, and many MIB modules do not contain objects for configuration or other protocol-specific specialized functionality. Any protocol that wants to look at statistics or state for technologies where a MIB module has already been developed for that purpose could benefit from utilizing the same managed objects as are used in the MIB module. NM protocols that have a different focus of applicability, such as NETCONF, will almost certainly require a different modeling language than SMI to entirely model their functionality, but might still benefit from reusing existing MIB objects for monitoring the configured technology or checking the state following configuration. They should not be required to use SNMP to carry the data in ASN.1 format, and an SMIv2 MIB module parser to validate the existing data if their protocol can already carry XML, and their application already supports XSD validation. We should provide a standard translation to make using the MIB's managed objects with XML/XSD easier. If the developers of a protocol decide that there are insufficient benefits from reusing existing MIB data, they are not forced to do so. Two goals of this work are instrumentation reuse and semantics reuse. The IETF has spent twenty years developing standard managed objects, and vendors have supplemented that with proprietary managed objects, all written using a standard language for expressing the syntax and semantics. We want to preserve that work and make it available for XML-based messaging. Vendors have spent a great deal of money adding "hooks" into their instrumentation to support existing managed objects, such as counters. Operators have spent a great deal of time learning those managed objects, including which things a counter does and does not count. It would be a bad thing if NM data model designers designed new objects that differ slightly from existing standard managed objects, for no good reason,, thus requiring vendors to reimplement to support the slight differences, and operators to learn the new semantics if this is really unnecessary. If a new object would better serve the purpose, there is nothing that constrains designers from developing a new counter. If an existing managed object would work for multiple protocols, it would be a good thing if the XSD format used to represent the existing managed object is consistent across protocols, and properly represents the original design of the managed object. WG review can help to ensure that the translations are done properly. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Sunday, July 29, 2007 4:38 AM > To: David Harrington > Cc: opsawg@ietf.org > Subject: Re: [OPSAWG] SMI-to-XSD mapping work > > On Fri, Jul 27, 2007 at 11:18:44AM -0500, David Harrington wrote: > > > The XSDMI BOF proposed the creation of a WG to develop 1) the XSD > > equivalents of datatypes and textual conventions from SMIv2, 2) > > algorithms to translate MIB module specifications into XSD > > equivalents, 3) Netconf operations to access MIB data, and 4) a > > draft documenting security requirements for protocols accessing the > > MIB. The BOF demonstrated community support for the first two > > objectives. The third objective should be moved to a > > Netconf-specific WG. There was a lack of support for the fourth > > objective. > > As long as NETCONF data modeling is completely undefined, developing > XSDs for data types and SMIv2 MIB module translations for use with > NETCONF will constrain any future NETCONF standards-track data > modeling work. > > I don't want to discourage people from doing work on accessing SNMP > instrumentation via NETCONF; but I have a serious concern if the goal > is to produce standards-track specifications for 1) and 2) for the > reason mentioned above. > > /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://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Jul 30 13:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ02-0000oj-LF; Mon, 30 Jul 2007 13:25:42 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IFZ01-0000oW-I7 for opsawg-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:25:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ01-0000oN-8X for opsawg@ietf.org; Mon, 30 Jul 2007 13:25:41 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23] helo=hermes.jacobs-university.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYzz-0003o6-M1 for opsawg@ietf.org; Mon, 30 Jul 2007 13:25:41 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D4049B4; Mon, 30 Jul 2007 19:25:39 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10318-09; Mon, 30 Jul 2007 19:25:34 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40C359AB; Mon, 30 Jul 2007 19:25:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 411E92F3D58; Mon, 30 Jul 2007 19:25:34 +0200 (CEST) Date: Mon, 30 Jul 2007 19:25:34 +0200 From: Juergen Schoenwaelder To: David Harrington Subject: Re: [OPSAWG] SMI-to-XSD mapping work Message-ID: <20070730172534.GB9244@elstar.local> Mail-Followup-To: David Harrington , opsawg@ietf.org References: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> <20070729083730.GA6607@elstar.local> <000401c7d1f0$ef700280$0600a8c0@china.huawei.com> <20070730053831.GA6941@elstar.local> <002101c7d2cd$0cd4cdb0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101c7d2cd$0cd4cdb0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org On Mon, Jul 30, 2007 at 01:14:11PM -0400, David Harrington wrote: > To my knowledge there are three "teams" working on NETCONF data > modeling - pure-XSD, and two unpublished specs (NCX and Yang). I have > discussed the SMI-to-XSD work with leaders of each of these teams, and > all agree that a common XSD for MIB access makes sense. I do not think > they feel constrained by such an effort. > > You didn't attend the XSDMI BOF. The XSDMI BOF was filled primarily > with people who are active in NETCONF, including the leaders of the > three teams, and the consensus was 13 for doing this work, and zero > against. OK. Then count me as the one against. > One reason I view the separation of this work to be acceptable is that > the SMI-to-XSD effort is fairly simple translation work from one > modeling langauge to another; it can be done by engineers with a > reasonable amount of skill in SMI and XSD - a junior programmer could > do most of the work in this effort, with technical reviews done by > more experienced SMI and XSD engineers. We have three editors willing > to document the translations, and thirteen willing reviewers, > including the leaders of the three NETCONF teams. > > The work being done in the NCX and Yang efforts is to develop a > completely new modeling language; this (and the work with pure-XSD) > requires the expertise of people with years of experience with SMI and > XML, a profound understanding of the limitations of the SMI and the > limitations of XML/XSD, and years of experience developing language > tools. This requires senior programmer/architect skills. I don't care which skills are required for which document. I am concerned that we see a situation where we have both (a) SMIv2 -> XSD (b) SMIv2 -> "NETCONF DML" -> XSD and thus there may be some notable confusion if the result is not the same or we have in fact established a constraint on the "NETCONF DML" and associated translations. > I will point out that many of the current NETCONF leaders could not > reach consensus on a new data modeling langauge in the failed SMING > WG. I do not believe that all IETF protocols should be denied > XML-based access to MIB data just because the NETCONF community cannot > achieve consensus on a new data modeling language. Which protocols other than NETCONF do you have in mind? > There is work that can be done now to allow access to MIB data by > XML-based protocols, that will not constrain the "star" developers in > their efforts, and will allow the whole IETF to better utilize the > standard MIB objects have developed over the past twenty years. Again, what is this "whole IETF" thing you are talking about other than NETCONF? /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://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Mon Jul 30 13:32:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ6Z-0006PI-RU; Mon, 30 Jul 2007 13:32:27 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IFYp2-0003rz-Sr for opsawg-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 13:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYoz-0003rk-Cm for opsawg@ietf.org; Mon, 30 Jul 2007 13:14:17 -0400 Received: from alnrmhc12.comcast.net ([206.18.177.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYoy-0002pK-5t for opsawg@ietf.org; Mon, 30 Jul 2007 13:14:17 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070730171415b1200de6qve>; Mon, 30 Jul 2007 17:14:15 +0000 From: "David Harrington" To: References: <01fc01c7d069$d0f2b920$79aa1cac@china.huawei.com> <20070729083730.GA6607@elstar.local> <000401c7d1f0$ef700280$0600a8c0@china.huawei.com> <20070730053831.GA6941@elstar.local> Subject: RE: [OPSAWG] SMI-to-XSD mapping work Date: Mon, 30 Jul 2007 13:14:11 -0400 Message-ID: <002101c7d2cd$0cd4cdb0$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: <20070730053831.GA6941@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfSa+BP1e0nn+TSTmO7K7Zi6fM1KwAWpoow X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-Mailman-Approved-At: Mon, 30 Jul 2007 13:32:26 -0400 Cc: opsawg@ietf.org X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: opsawg-bounces@ietf.org Hi Juergen, > -----Original Message----- > From: Juergen Schoenwaelder > I do not question any of the motivation. My concern, however, remains > that the existence of the translated XSD output will cause future data > modeling languages to be "consistent" with the XSD output coming out > of the translation. For me, a NETCONF data modeling language and SMIv2 > translations should go hand in hand and not be separate efforts. > I think the efforts should be coordinated, but can be different. To my knowledge there are three "teams" working on NETCONF data modeling - pure-XSD, and two unpublished specs (NCX and Yang). I have discussed the SMI-to-XSD work with leaders of each of these teams, and all agree that a common XSD for MIB access makes sense. I do not think they feel constrained by such an effort. You didn't attend the XSDMI BOF. The XSDMI BOF was filled primarily with people who are active in NETCONF, including the leaders of the three teams, and the consensus was 13 for doing this work, and zero against. One reason I view the separation of this work to be acceptable is that the SMI-to-XSD effort is fairly simple translation work from one modeling langauge to another; it can be done by engineers with a reasonable amount of skill in SMI and XSD - a junior programmer could do most of the work in this effort, with technical reviews done by more experienced SMI and XSD engineers. We have three editors willing to document the translations, and thirteen willing reviewers, including the leaders of the three NETCONF teams. The work being done in the NCX and Yang efforts is to develop a completely new modeling language; this (and the work with pure-XSD) requires the expertise of people with years of experience with SMI and XML, a profound understanding of the limitations of the SMI and the limitations of XML/XSD, and years of experience developing language tools. This requires senior programmer/architect skills. I will point out that many of the current NETCONF leaders could not reach consensus on a new data modeling langauge in the failed SMING WG. I do not believe that all IETF protocols should be denied XML-based access to MIB data just because the NETCONF community cannot achieve consensus on a new data modeling language. There is work that can be done now to allow access to MIB data by XML-based protocols, that will not constrain the "star" developers in their efforts, and will allow the whole IETF to better utilize the standard MIB objects have developed over the past twenty years. This work should NOT be gated on NETCONF data modeling consensus. David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg From opsawg-bounces@ietf.org Tue Jul 31 10:16:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFsWD-0001bc-IV; Tue, 31 Jul 2007 10:16:13 -0400 Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IFsWC-0001bW-Vv for opsawg-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 10:16:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFsW9-0001ao-0T for opsawg@ietf.org; Tue, 31 Jul 2007 10:16:09 -0400 Received: from legolas.restena.lu ([158.64.1.34] helo=smtp.restena.lu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFsW8-0003Ic-FM for opsawg@ietf.org; Tue, 31 Jul 2007 10:16:08 -0400 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id B45B73027253 for ; Tue, 31 Jul 2007 16:16:07 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [158.64.1.155]) by smtp.restena.lu (Postfix) with ESMTP id A4F2A3027248 for ; Tue, 31 Jul 2007 16:16:07 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: opsawg@ietf.org Date: Tue, 31 Jul 2007 16:16:37 +0200 User-Agent: KMail/1.9.7 X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [OPSAWG] Report on RadSec X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2056700982==" Errors-To: opsawg-bounces@ietf.org --===============2056700982== Content-Type: multipart/signed; boundary="nextPart1472246.tTdIEZLJ3r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1472246.tTdIEZLJ3r Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello all, as promised in the opsawg session at IETF69, here's a short report on what= =20 happened in the radiusext wg session: I held a very similar presentation at radiusext, and it stirred up an=20 interesting (and polarised) discussion. It turned out that radsec could solve also one of the wgs chartered problem= s:=20 crypto-agility. In a hand-count, the supporters of the in-charter=20 crypto-agility solution ("keywrap" version -14) vs. RadSec was roughly 50-5= 0. It also turned out that a re-charter of radiusext would be necessary to=20 include the radsec work, some had strong feelings against that re-charterin= g,=20 others supported it. Another important point raised was that possibly RadSec is challenged by th= e=20 very same patents from Nokia that Diameter is. A follow-up patent research= =20 will be done. I will keep further reports and discussions on the radiusext mailing list,= =20 since it seems to be the place where people are most interested in the topi= c.=20 Those of you interested in the topic, please join radiusext@ops.ietf.org. Greetings, Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart1472246.tTdIEZLJ3r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGr0RJ+jm90f8eFWYRAkSnAJ9D2ivUXEnciHr6A9INJE+iS3AIPwCfXxSM EJTUr+ZYQ2PVROb/Pm2iq+Y= =ZQml -----END PGP SIGNATURE----- --nextPart1472246.tTdIEZLJ3r-- --===============2056700982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg --===============2056700982==--