From ops-area-bounces@ietf.org Tue Apr 03 11:49:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlFb-0005QV-K0; Tue, 03 Apr 2007 11:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYlFa-0005QA-Ey; Tue, 03 Apr 2007 11:48:50 -0400 Received: from smtp-mclean.mitre.org ([192.80.55.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYlFW-0007B6-I3; Tue, 03 Apr 2007 11:48:50 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l33FmeYI008795; Tue, 3 Apr 2007 11:48:40 -0400 Received: from smtp-mclean.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-mclean.mitre.org (Postfix) with ESMTP id B479F1BDA7; Tue, 3 Apr 2007 11:48:39 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-mclean.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l33FmaJx008667; Tue, 3 Apr 2007 11:48:39 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:48:33 -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: Tue, 3 Apr 2007 11:48:31 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01BA8D88@IMCSRV2.MITRE.ORG> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB2RMDL discussion list available Thread-Index: AcdwcCfEZyJt5bMOTaeTKpD3N4xYIQFlU3kA References: From: "Natale, Bob" To: X-OriginalArrivalTime: 03 Apr 2007 15:48:33.0029 (UTC) FILETIME=[88800B50:01C77607] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ops-nm@ietf.org, nmrg@ibr.cs.tu-bs.de, IETF MIBs Subject: [OPS-AREA] MIB2RMDL discussion list available X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi, For those who were not at the OpsArea meetings in Prague (or have forgotten :), we held a mini-BOF on the topic of standardizing a methodology to convert SNMP MIBs to SOA/WS resource model artifacts (tagged as "MIB to Resource Model Description Language" (MIB2RMDL), using "Language" very loosely in this context). =20 The material presented in Prague is available at http://www3.ietf.org/proceedings/07mar/slides/opsarea-7.ppt. It's relatively short (13 slides or so) and employs the "repetition is the key to learning" approach (familiar to all of us from Jeff Case's many helpful tutorials on SNMP in past years). =20 =20 The O&M Area decided to proceed with further investigation of the MIB2RMDL idea, with the first step being to establish an e-mail list for discussion of the proposal. If you would like to participate or even just monitor the discussion, you can subscribe at https://www1.ietf.org/mailman/listinfo/mib2rdml. My hope is that the discussion will lead to sufficient definition and further acceptance of the MIB2RMDL proposal so that we can charter a formal Working Group at IETF-69 in Chicago this July.=20 I will produce and post an updated (-01) I-D in the next week or so, incorporating input/feedback from the Prague meeting and anything else that might develop on this list in the meantime. (Co-authors welcomed.) =20 Cheers, BobN _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Apr 11 03:07:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWum-0001H2-SX; Wed, 11 Apr 2007 03:06:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbWul-0001Gx-Kv for ops-area@ietf.org; Wed, 11 Apr 2007 03:06:47 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbWui-0007hj-Tq for ops-area@ietf.org; Wed, 11 Apr 2007 03:06:47 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 16BC06DB4A; Wed, 11 Apr 2007 09:06:38 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 22505-04; Wed, 11 Apr 2007 09:06:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8F8176DADB; Wed, 11 Apr 2007 09:05:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 31DB7213966; Wed, 11 Apr 2007 09:05:15 +0200 (CEST) Date: Wed, 11 Apr 2007 09:05:15 +0200 From: Juergen Schoenwaelder To: dharrington@huawei.com Message-ID: <20070411070515.GA5696@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: ops-area@ietf.org Subject: [OPS-AREA] comments on draft-harrington-operations-and-management-00.txt X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org David, here are comments about draft-harrington-operations-and-management-00.txt which I wanted to pass on to you in Prague (but since I failed to do so, I wrote them down and so more people can see them easily). a) I did not understand the next to last paragraph in section 2 above 2.1: Considering the operational and manageability aspects related to a new protocol provides guidance to the editor of a document specifying management functionality, weighs the management options, and allows the editor to start actually editing earlier than if they need to research requirements before writing a management specification. This sounds like somehow things get faster, but I am not sure why. b) p6: s/contrain/constrain/ (BTW, there is a spell checking service on the IETF's tool page.) c) p11: s/shoul/should d) p12: I would mention SVN in addition to RCS and CVS (which are both being gradually replaced by SVN it seems) e) p12/13: [...] It is desirable to extract, document, and standardize the common parts of these network wide configuration database schemas. A working group should consider how to standardize the common parts of configuring the new protocol, while recognizing the vendors will likely have proprietary aspects of their configurations. I do not think this belongs here. Yes, standards or even just guidelines for building network wide configuration databases would really help to advance the state of art but I believe this constitutes a problem the IETF can't really handle. The only way to tackle this problem is actually to fund open source initiatives in this space. (ISPs who have such systems have no interest to share them, those who don't have them typically do not have the resources to build them.) f) p13: Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems. It is important to minimize the impact caused by configuration changes. This has been said in section 3.5 already. g) p13: I am not sure section 4.3.1 belongs into the section on configuration. Section 4.3.2 seems to be repetition and again I am not sure it belongs into 4.3. h) p14: Consider the expected behaviors when counters reach their maximum value - should they be reset to zero, or should they latch at the maximum value? From an SNMP perspective this is rather confusing; I would prefer to avoid the phrase "reset to zero" and instead use "roll-over" and I doubt counters that latch are a good thing. Consider whether counters should be persistent across reboots of the device, or restarts of the management system. It might be important to explain what counter discontinuities are, that is which events can cause counter delta computations to become irrelevant. i) p15: s/application swill/ applications will/ j) p15: remove duplicate paragraph For performance monitoring, it is important to report counters and not gauges as it is important to report the time spent in a state rather than the actual state. In other words, objects that report snapshots are of less value for performance monitoring. k) p15: I suggest to add text to section 4.6 that people should think about how ACLs are maintained and updated. l) p16: s/deployment/deployment. m) p18: A key aspect of NETCONF is that it allows the functionality of the management protocol to closely mirror the native functionality of the device. I believe this is confusing. The truth is that NETCONF aims at closely mirroring the native CLI of the device. n) p18: I like to see strong warnings attached to COPS-PR, like that it did not side wide support/deployment and that its binary BER encoding of management data puts it close to SNMP in terms of the efforts it takes to script a simple solution in whatever automation language an operator prefers. o) p19: I suggest to explain more about the differences between RADIUS and DIAMETER and how to make a choice between them. How is actually using DIAMETER?? (I do not care about other bodies refering to it; I mean deployed systems.) p) p19: I think it is essential to get EPP included in the list of management protocols and also perhaps XCAP. q) p19: I am not sure structuring section 6 along FCAPS is a good idea. I am also not sure that IETF status of a specification is a useful selection criteria. r) p20: Protocol designers should always build in basic testing features (e.g. ICMP echo, UDP/TCP echo service, NULL RPC calls) that can be used to test for liveness, with an option to enable and disable them. While I agree with the statement, I doubt it belongs into section 6. s) p20: A command line interface (CLI) might be used to provide initial configuration of the target functionality. Command line interfaces are usually proprietary, but working groups could suggest specific commands and command parameters that would be useful in configuring the new protocol, so implementers could have similarities in their proprietary CLI implementations. This has been said already in section 5.8 and I do not think this belongs into section 6.2. t) p21: s/PIBs During/PIBs. During/ u) p21: s/capabilities New/capabilities. New/ v) p21: I am not sure the following sections talk about configuration (but then I already suggested to not structure this section along FCAPS): RFC 3418 [RFC3418], part of STD 62 SNMPv3, contains objects in the system group that are often polled to determine if a device is still operating, and sysUpTime can be used to detect if a system has rebooted and caused potential discontinuity in other counters. Other objects in the system MIB are useful for identifying the type of device, the location of the device, the person responsible for the device, etc. Draft Standard RFC2863 [RFC2863], the Interfaces MIB is used for managing Network Interfaces. This includes the 'interfaces' group of MIB-II and discusses the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork-layer. Proposed Standard RFC4133 [RFC4133] the Entity MIB is used for managing multiple logical and physical entities managed by a single SNMP agent. w) p21: is the following really relevant? are there any implementations and deployments? Proposed Standard RFC4011 [RFC4011] defines objects that enable policy-based monitoring and management of SNMP infrastructures, a scripting language, and a script execution environment. x) p22: RFC3159 discusses the Proposed Standard Structure of Policy Provisioning Information (SPPI), an extension to the SMI standard for purposes of policy-based provisioning, for use with the COPS-PR protocol defined in RFC3084. Informational RFC3317 defines a DiffServ QoS PIB, and Informational RFC3571 defines policy classes for monitoring and reporting policy usage feedback, as well as policy classes for controlling reporting intervals, suspension, resumption and solicitation. At the time of this writing, there are no standards-track PIBs During the IAB Workshop on Network Management, the workshop had rough consensus from the protocol developers that the IETF should not spend resources on SPPI PIB definitions, and the operators had rough consensus that they do not care about SPPI PIBs. Why is this text here and not in the COPS-PR description? y) After reading section 6, I asked myself whether it is possible to mention somehow that different "technologies" in the various layers tend to prefer different management interfaces. Layer two stuff seems to like SNMP much more than higher layers in the stack. It might be useful to explain integration with CLIs; there are boxes that layer CLI and Web interfaces over a common SNMP interface, there are boxes that layer CLI and Web interfaces over a common NETCONF interface, there are boxes where management interfaces are pretty much separate, which is known to be problematic. Sure, we get to discuss implementation choices but at the end, this is actually important to understand when making design decisions. I also found the end of section 6 a rather unstructured collection of things and it remains unclear what to learn from this. z) Just to complete the alphabet. ;-) -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Apr 12 07:49: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 1HbxnY-0006lH-V0; Thu, 12 Apr 2007 07:49:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbxnX-0006kx-BF; Thu, 12 Apr 2007 07:49:07 -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 1HbxnW-0005lc-EK; Thu, 12 Apr 2007 07:49:07 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 12 Apr 2007 07:49:04 -0400 X-IronPort-AV: i="4.14,400,1170651600"; d="scan'208"; a="2716171:sNHT10351074" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Mar 2007 14:20:54 +0200 MIME-Version: 1.0 Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l2TCKrQ3029018 for ; Thu, 29 Mar 2007 08:20:53 -0400 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Received: from lists.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by co300216-co-ierwest.avaya.com with ESMTP; 29 Mar 2007 08:23:58 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWtcQ-0000At-2E; Thu, 29 Mar 2007 08:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWtcO-00009p-HE; Thu, 29 Mar 2007 08:20:40 -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 1HWtcM-0000zj-Op; Thu, 29 Mar 2007 08:20:40 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 29 Mar 2007 08:23:42 -0400 Received: from 300216erh2.post.avaya.com ([198.152.7.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 27 Mar 2007 15:03:25 +0200 Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by 300216erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l2RD2hjf000420 for ; Tue, 27 Mar 2007 07:03:23 -0600 Received: from megatron.ietf.org ([156.154.16.145]) by de307622-de-ieremea.avaya.com with ESMTP; 27 Mar 2007 09:03:22 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBKP-0002cd-5Q; Tue, 27 Mar 2007 09:03:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWBKN-0002bm-7r; Tue, 27 Mar 2007 09:03:07 -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 1HWBKK-0000I7-Jc; Tue, 27 Mar 2007 09:03:07 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 27 Mar 2007 09:05:31 -0400 content-class: urn:content-classes:message Date: Thu, 12 Apr 2007 14:48:23 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes of the OPS Area open meetings in Prague - FINAL VERSION? Thread-Index: AcdwcCfEZyJt5bMOTaeTKpD3N4xYIQ== From: "Romascanu, Dan \(Dan\)" To: , , , "IETF MIBs" , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: Subject: [OPS-AREA] Minutes of the OPS Area open meetings in Prague - FINAL VERSION? X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Unless I missed some mails during my vacation, I did not record any = further feedback to this version.=20 Going once ... Going twice ... (but not later than this weekend, please) Dan -------------------------------------------------------------------------= ------ Meeting 1 - Monday March 19, 2007 15:20 to 17:20=20 1. Meeting Administrivia 2. Introduction of new Area Director - Ron Bonica=20 Dan - thanking David Kessens for his years of service as Area Director 3. Mini-BOF A: - Manageability and Operational Guidelines - David = Harrington=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-1.ppt Discussions about the structure of the document - should the protocol = evaluation be part of the document?=20 4. Mini-BOF B: COPS push mode policy configuration - Tom Taylor and Tina = Tsou =20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-3.ppt Sharon Chisholm: why COPS? because COPS is (apparently) going away=20 Unidentified : working at the ITU-T, still some interest=20 Kevin Johnson: in the draft, not quite clear if a new message was used. Tom: draft proposes a new message but could also use a flag, which is = the less violent solution. Discussion of the collision of handles Dbh: there are two questions to answer. question 1: is COPS going away? Worth it? Little update in the industry. = Should this be part of the manageability work (his mini-BOF)? Should we = move COPS to experimental or not recommended? question 2: technical = decision whether change is the right one? Scott Bradner: Answer Dave's first question. some enthusiasm for COPS at = the beginning, then faded away. Interest in ITU. The ITU-T is using a = few protocols including DIAMETER and COPS from the IETF that require = some extensions. If another non-IETF group wants to use COPS, why stand = in their way? Dave: "I can agree with that; somebody once said that the IETF doesn't = produce standards, but technologies; other organizations produce = standards" Dan (to Tom): what is your preferred solution?=20 Tom: A standard document with the COPS update . ITU and IETF would = progress this in parallel (approve in ITU-T as an annex), and then have = IETF (tweak and) approve it, and then update ITU-T to reference the RFC. Scott: This parallel approach has been problematic in the past. It = should either be done in ITU or in IETF, but not both. Tina: I think this can be done Dan: another approach is that the ITU-T can publish an Informational = document. I do not want to take a position at this point. ITU should = also consider what happens Dave Partain: I think there will be little energy to do this in the = IETF, so it should be done in ITU. Bert: I do not know if COPS-PR is being used or not; I know I do not = want to spend time working on COPS-PR. Is anybody interested in working = on it (including review any work done by ITU?) Tom: Does anybody work for an organization that uses COPS-PR?=20 One person raised their hands (Tina Tsou from Huawei) Tom: Is there any interest in working on COPS-PR extensions?=20 Dan: these questions should be asked on the OPS lists and ITU lists. Should it be standards track? - the authors would like it so.=20 Action item - Tom to address the ops-area list with query to determine = status of implementation and deployment of COPS and COPS-PR and level of = interest in participating in such a work 5. Mini-BOF C: Best Current Practices in Operations and Management - = David Harrington =20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-2.ppt Proposal to create operation capabilities working group, modeled on the = experience of opsec WG Would bring in operators experience Framework document and operational guidelines as principal output Is opsec a success story?=20 Straw poll indicates interest - continue discussion after the next item 6. Improved Efficiency of the OPS Area - proposal for the formation of a = OPS Area WG - ADs=20 David and Dan - create structure for OPS area, similar to the one = existing in TSV and Routing Should it be merged with OPS and management capabilities WG as suggested = by David H.?=20 TSV chair - success in Transport due to multiple small items, no = dominant item Straw poll indicates interest - nobody believes it's a bad idea, = continue discussions in net meeting 7. Open Microphone=20 Meeting 2 - Wednesday March 21, 2007 - 13:00 to 16:10=20 1. Meeting Administrivia ADs (total: 5 min)=20 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - = Michael Alexander=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-4.ppt Scott Bradner - very complex, IETF not good history in this type of = thing Pekka - benefit would go to NMS vendors? response - benefit to equipment vendors to get devices into NMSs Pekka - simpler version may be helpful, clean terminology would be = helpful potential but current scope too big, maybe more fit to the IRTF Margret Wassermann - interesting, but what gets standardized? response - focus on meta models only xx - sim (info model) underway for 4 years - achieved meta view, now = time to distribute to groups to use response - this proposal is much simpler than sim Chair: suggest create list & discuss issues raised in meeting, only one = opposed 3. MIB-Doctor-sponsored MIB-document-writing template: David Harrington=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-8.ppt No discussions 4. Mini-BOF E: MIB module editing in XML : Emile Stephan =20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-5.ppt Sharon - do you actually have tools to translate XML to MIBs? response - I'm proposing to edit the MIB in XML and use XSL = transformation. Sharon - do you do SMI verification? Emile: Shows that the tool captures mistakes. Bill Fenner - wrong way to model MIB in XML - better to have element = that is syntax or XML schema for writing a MIB response - I'm using XML in a very loose way, but this is better than = nothing. Please make better proposal. Juergen - The opening argument in the beginning you wanted to move to = data model. The main issue is not syntactic problem to get there. response - I asked for a BOF in order to discuss and have proposals of = how to move forward chair - does not feel that it's a standards problem at this time but = maybe should be discussed with tools people 5. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-6.ppt - proposed goal for NGO Sharon - why select VLANs? response - well used technology in enterprise space chair - MIB modules are used for VLAN config in enterprises - good to = see comparison between SNMP & netconf=20 chair - In Chicago we will have one or two BOFs for data modeling. This = contribution belongs to this space. Encourage to continue the work, = update the I-D and bring proposals to the NGO work. 6. Mini-BOF G: OWL techniques for MIB to XML documents and schema = translation - Bob Natale=20 http://www3.ietf.org/proceedings/07mar/slides/opsarea-7.ppt Andy Bierman - there are issues beyond mere translations - suggests that = experts in a protocol would need to be involved in determining if = conversion can even be done Scott Bradner - how fill in holes (beyond what MIB covers) bob - would need to have collaborative process for each MIB =09 chair - good to invite WS-CIM folk to join discussion Sharon xx - may be mismatch between MIBs and service-orientated = interface - also may be too high a data bandwidth generated for SOA/WS = management stations Bob - yes an issue Sharon - how much interest in WS community Bob - much need among user & developer communities=20 Dan Romascanu (from floor) - not sure that this fits the base role of = the IETF - make net work better Bob - this will help the operators run the network better Eugene - spent years in WS area - high level seems to be good - but WS = seems to rely on different fundamental information needs than what is in = MIBs - also some groups in this area do not like each other (OAIS & = DMTF for example). The other is political. Are the two standard bodies = can really work together in the long term? xx - good idea & he is optimistic that this would be useful - but there = are valid concerns about level of impact on the other communities chair - open list for discussion, consensus in the room 7. Late Submission - requirements to tunneling protocols OAM - KIKUCHI = Yutaka=20 Pekka - why is this tunnel specific? Only reordering is response - Our main objective is to measure tunnel quality. Chair - Maybe the next version of the draft you may need to better = clarify what is tunnel quality, to emphasis the difference between = interface and tunnel interface Scott Bradner - if you prepend seq # you change packet size you may have = to fragment Response - I used GRE sequence number (32 bits). Good, if you prepend = sequence number you may get into segmentation situation. chair -We'll continue to discuss this on the list, gauge interest and = answer the questions. I forwarded this to IPPM and benchmarking WG. Tries to sense the interest in the room: 4-5 hands. Is this not = relevant? None 8. Open microphone =20 Margaret: The topics today were interesting. But interesting is not good = enough. We have really bad history of trying to standardize management = approaches that were not really needed by service providers. We much = work only on what users really need. Dan: We split the OPS session to two days. Today's is more the 'new' issues. We need more feedback from operators. Work in the past lead to = NETCONF etc. Dave K.: We haven't allowed BOFs for the last few IETF being strict to = ensure that ideas that are not really required will not go forward. However we felt that we may miss some good ideas from going forward. Bob: To answer Margaret. I wanted to stress in my presentation that = there are operators and users that need the data models. What do you = want that shows this need. Margaret: I want them to be here and participate. If we don' t have = multiple sources of input. David Partain: I'd like to address Margaret point. There has been a lot = of discussions on data modeling. This is a real problem, since everyone = wants to use NETCOM but there is not any data models. Our users want = NETCONF. I think this is fair to characterizing it as real need. Margeret: Are you the customer of the data model David: Me and my customer. Ron B.: Maybe we should go to the operators and ask what are the most = critical problems and start from that, i.e. solve this first. When he = was a operator he would not have seen the issue as a lack of a data = model - rather why does pager go off - should keep doing this kind of = thing but should try to get closer to user=E2=80=99s actual perceived = needs Andy: I don't believe it is possible to have a protocol independent data = model. We don't have the expertise in web verbs etc. You should do the = work. I agree with Scott that we don't have a way to fill in the holes. Dave H: Addressing Margaret point. I'm going to have a workgroup meeting = to understand their needs. Are there any operators in the rooms? ~ 5 = hands. on Monday he proposed an ops nm WG to get operators involved - = looking for volunteers to help ops area better understand operator = needs, also - operations & managements guidelines doc - also ooking for = volunteers for that Bob: We might have minimum basic requirements for conversion of MIBs. = But most MIBs should be map-able. Dave K.: Is the experiment with the mini-BOF useful? Around 30 hands Who thinks this is not useful? None Dan: Regarding Dave H suggestion for two working groups, I suggest that = we unite it into one working group. Dave H: I think these are two different problems and should be done by = two different contributor groups. Protocol designers and Operators. Dan: I agree, but work generates feedback and input generates work. My = concern that split of resources and that there will not be enough = interest if we split it to two. Dave K: From the operator part we don't want to be too lonely=85 The = important thing is to have a good charter for the working group. Ron B: New WG chair. Applause to Dave K. I work for Juniper. I was an = operator in the VBNS network. Looking forward to work with you all. _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Apr 12 08:01: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 1Hbxzb-0005qk-KI; Thu, 12 Apr 2007 08:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbxza-0005qQ-Te; Thu, 12 Apr 2007 08:01:34 -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 1HbxzZ-0002e8-N0; Thu, 12 Apr 2007 08:01:34 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 12 Apr 2007 07:59:32 -0400 X-IronPort-AV: i="4.14,400,1170651600"; d="scan'208"; a="2705580:sNHT26971566" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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 Apr 2007 14:59:32 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Operations and Management Area Open Hour Calls Thread-Index: Acd8+gfH6aOrb3XeSmirednYz/Np7Q== From: "Romascanu, Dan \(Dan\)" To: , , , , , , "IETF MIBs" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [OPS-AREA] Operations and Management Area Open Hour Calls X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Ron Bonica and Dan Romascanu are holding Open Hours to discuss issues related to the IETF Operations and Management Area on the first and third Tuesday of each month at noon-1PM PT / 3-4PM ET / 9-10PM CET.=20 All WG chairs, document editors, contributors, participants and in general all interested to talk with us about the area and IETF business are invited to ask for a meeting slot using the space below, and/or to write us directly at rbonica@juniper.net or dromasca@avaya.com. An e-mail will be sent in response to acknowledge the time slot and provide a telephone bridge number to be used in the call.=20 The next OPS area open slots are:=20 * Tue 4/17 PT CET 12-12:30pm 9-9:30pm =20 12:30-1pm 9:30-10pm =20 Ron and Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 04:40: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 1HcHK1-0007L7-P0; Fri, 13 Apr 2007 04:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcHJz-0007Kt-MP; Fri, 13 Apr 2007 04:39:55 -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 1HcHJy-0000fT-GZ; Fri, 13 Apr 2007 04:39:55 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 13 Apr 2007 04:39:53 -0400 X-IronPort-AV: i="4.14,406,1170651600"; d="scan'208"; a="3114271:sNHT7244820" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Apr 2007 11:39:17 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Mailing Lists in the OPS area Thread-Index: Acd9pzhQm687EVF1RV2xvp6F3c5w/Q== From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: mib2rdml@ietf.org, nmrg@ibr.cs.tu-bs.de, meta-model@ietf.org Subject: [OPS-AREA] New Mailing Lists in the OPS area X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Following the OPS area meetings and mini-BOF sessions in Prague we have created two new mail lists:=20 meta-model@ietf.org - this list will focus on discussions about the need and requirements for a meta data model in the network management space and what the IETF should do on this respect mib2rdml@ietf.org - the list will discuss the need and requirements of converting MIB modules into resource models for the SOA/Web Services Management environment and work that should be done in the IETF in this field The two lists will create a framework for discussions and contributions for the respective subjects and will allow the operations and management community to debate the level of interest and what should be done respectively in the two fields. If you are interested please subscribe and participate.=20 Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 07:35:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcK4G-0006Yy-F5; Fri, 13 Apr 2007 07:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcK4E-0006Yp-Tq for ops-area@ietf.org; Fri, 13 Apr 2007 07:35:50 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcK4D-0007RU-Ja for ops-area@ietf.org; Fri, 13 Apr 2007 07:35:50 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id AEC1F6DA29; Fri, 13 Apr 2007 13:35:48 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06091-09; Fri, 13 Apr 2007 13:35:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0B43158962; Fri, 13 Apr 2007 13:35:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 66374218C1D; Fri, 13 Apr 2007 13:35:42 +0200 (CEST) Date: Fri, 13 Apr 2007 13:35:42 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area Message-ID: <20070413113542.GA26504@elstar.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Fri, Apr 13, 2007 at 11:39:17AM +0300, Romascanu, Dan (Dan) wrote: > Following the OPS area meetings and mini-BOF sessions in Prague we have > created two new mail lists: > > meta-model@ietf.org - this list will focus on discussions about the need > and requirements for a meta data model in the network management space > and what the IETF should do on this respect > > mib2rdml@ietf.org - the list will discuss the need and requirements of > converting MIB modules into resource models for the SOA/Web Services > Management environment and work that should be done in the IETF in this > field > > The two lists will create a framework for discussions and contributions > for the respective subjects and will allow the operations and management > community to debate the level of interest and what should be done > respectively in the two fields. If you are interested please subscribe > and participate. I would prefer if mailing lists are created once there is actually enough traffic to warrant a new mailing list. I believe we already have too many "ops" mailing lists and I like to ask the ADs to consider actually merging lists instead of creating more. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 12:08: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 1HcOKD-0000Aa-Ir; Fri, 13 Apr 2007 12:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOKB-00009Z-LK; Fri, 13 Apr 2007 12:08:35 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcOKA-0000gW-AW; Fri, 13 Apr 2007 12:08:35 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc14) with SMTP id <20070413160832m1400ina4ge>; Fri, 13 Apr 2007 16:08:33 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area Date: Fri, 13 Apr 2007 12:08:13 -0400 Message-ID: <0e4d01c77de5$f198bc50$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 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Acd9pzhQm687EVF1RV2xvp6F3c5w/QAPi1cw X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mib2rdml@ietf.org, nmrg@ibr.cs.tu-bs.de, meta-model@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org What does meta-modeling cover? dbh > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Friday, April 13, 2007 4:39 AM > To: ops-area@ietf.org > Cc: mib2rdml@ietf.org; nmrg@ibr.cs.tu-bs.de; meta-model@ietf.org > Subject: [OPS-AREA] New Mailing Lists in the OPS area > > Following the OPS area meetings and mini-BOF sessions in > Prague we have > created two new mail lists: > > meta-model@ietf.org - this list will focus on discussions > about the need > and requirements for a meta data model in the network management space > and what the IETF should do on this respect > > mib2rdml@ietf.org - the list will discuss the need and requirements of > converting MIB modules into resource models for the SOA/Web Services > Management environment and work that should be done in the > IETF in this > field > > The two lists will create a framework for discussions and > contributions > for the respective subjects and will allow the operations and > management > community to debate the level of interest and what should be done > respectively in the two fields. If you are interested please subscribe > and participate. > > Dan > > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 12:39:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOnf-0004Ze-H0; Fri, 13 Apr 2007 12:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcOna-0004ZA-Pb; Fri, 13 Apr 2007 12:38:58 -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 1HcOnZ-0006ge-H8; Fri, 13 Apr 2007 12:38:58 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 13 Apr 2007 12:38:56 -0400 X-IronPort-AV: i="4.14,408,1170651600"; d="scan'208"; a="3291489:sNHT7557786" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area Date: Fri, 13 Apr 2007 19:38:20 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] New Mailing Lists in the OPS area Thread-Index: Acd9pzhQm687EVF1RV2xvp6F3c5w/QAPi1cwAAEdHiA= References: <0e4d01c77de5$f198bc50$0600a8c0@china.huawei.com> From: "Romascanu, Dan \(Dan\)" To: "David Harrington" , X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: mib2rdml@ietf.org, nmrg@ibr.cs.tu-bs.de, meta-model@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org This is the follow-up to one of the mini-BOFs in Prague http://www3.ietf.org/proceedings/07mar/slides/opsarea-4/sld1.htm.=20 Dan =20 =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, April 13, 2007 7:08 PM > To: Romascanu, Dan (Dan); ops-area@ietf.org > Cc: mib2rdml@ietf.org; nmrg@ibr.cs.tu-bs.de; meta-model@ietf.org > Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area >=20 > What does meta-modeling cover? >=20 > dbh=20 >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Friday, April 13, 2007 4:39 AM > > To: ops-area@ietf.org > > Cc: mib2rdml@ietf.org; nmrg@ibr.cs.tu-bs.de; meta-model@ietf.org > > Subject: [OPS-AREA] New Mailing Lists in the OPS area > >=20 > > Following the OPS area meetings and mini-BOF sessions in Prague we=20 > > have created two new mail lists: > >=20 > > meta-model@ietf.org - this list will focus on discussions about the=20 > > need and requirements for a meta data model in the network=20 > management > space > > and what the IETF should do on this respect > >=20 > > mib2rdml@ietf.org - the list will discuss the need and requirements > of > > converting MIB modules into resource models for the SOA/Web=20 > Services=20 > > Management environment and work that should be done in the IETF in=20 > > this field > >=20 > > The two lists will create a framework for discussions and=20 > > contributions for the respective subjects and will allow the=20 > > operations and management community to debate the level of interest=20 > > and what should be done respectively in the two fields. If you are=20 > > interested please > subscribe > > and participate.=20 > >=20 > > Dan > >=20 > >=20 > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www1.ietf.org/mailman/listinfo/ops-area > >=20 >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 13:05: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 1HcPDC-0003Po-2D; Fri, 13 Apr 2007 13:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPDA-0003PR-7j for ops-area@ietf.org; Fri, 13 Apr 2007 13:05:24 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPD8-0004q3-To for ops-area@ietf.org; Fri, 13 Apr 2007 13:05:24 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc11) with SMTP id <20070413170521m11005k40ke>; Fri, 13 Apr 2007 17:05:22 +0000 From: "David Harrington" To: , "'Romascanu, Dan \(Dan\)'" References: <20070413113542.GA26504@elstar.local> Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area Date: Fri, 13 Apr 2007 13:05:03 -0400 Message-ID: <0e7001c77ded$e1b6e750$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 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <20070413113542.GA26504@elstar.local> Thread-Index: Acd9v+UlvvzYZ0SVTZm/BU2OUJmnhgALS7Rg X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org I agree; I find it hard to carry on similar discussions on a wide variety of mailing lists. I also would like to see the cross-posting to OPS lists reduced. It would be better to have fewer OPS mailing lists. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Friday, April 13, 2007 7:36 AM > To: Romascanu, Dan (Dan) > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area > > On Fri, Apr 13, 2007 at 11:39:17AM +0300, Romascanu, Dan (Dan) wrote: > > Following the OPS area meetings and mini-BOF sessions in > Prague we have > > created two new mail lists: > > > > meta-model@ietf.org - this list will focus on discussions > about the need > > and requirements for a meta data model in the network > management space > > and what the IETF should do on this respect > > > > mib2rdml@ietf.org - the list will discuss the need and > requirements of > > converting MIB modules into resource models for the SOA/Web Services > > Management environment and work that should be done in the > IETF in this > > field > > > > The two lists will create a framework for discussions and > contributions > > for the respective subjects and will allow the operations > and management > > community to debate the level of interest and what should be done > > respectively in the two fields. If you are interested > please subscribe > > and participate. > > I would prefer if mailing lists are created once there is actually > enough traffic to warrant a new mailing list. I believe we already > have too many "ops" mailing lists and I like to ask the ADs to > consider actually merging lists instead of creating more. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 13:16:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPNs-0002Ch-Cz; Fri, 13 Apr 2007 13:16:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPNr-0002CY-FN for ops-area@ietf.org; Fri, 13 Apr 2007 13:16:27 -0400 Received: from smtpproxy1.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPNr-00019i-2c for ops-area@ietf.org; Fri, 13 Apr 2007 13:16:27 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with SMTP id l3DHGQhS026175 for ; Fri, 13 Apr 2007 13:16:26 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 9E8F6C062 for ; Fri, 13 Apr 2007 13:16:26 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id l3DHGQhs026149; Fri, 13 Apr 2007 13:16:26 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 13:16: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 Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area Date: Fri, 13 Apr 2007 13:16:18 -0400 Message-ID: <4915F014FDD99049A9C3A8C1B832004F01C258C4@IMCSRV2.MITRE.ORG> In-Reply-To: <0e7001c77ded$e1b6e750$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] New Mailing Lists in the OPS area Thread-Index: Acd9v+UlvvzYZ0SVTZm/BU2OUJmnhgALS7RgAAB2KhA= References: <20070413113542.GA26504@elstar.local> <0e7001c77ded$e1b6e750$0600a8c0@china.huawei.com> From: "Natale, Bob" To: "David Harrington" , , "Romascanu, Dan (Dan)" X-OriginalArrivalTime: 13 Apr 2007 17:16:25.0890 (UTC) FILETIME=[77804820:01C77DEF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi, While my first reaction was to agree with Juergen and Dave on this matter, it occurs to me that for a topic that might benefit from input from experts outside the traditional OpsArea domain (e.g., MIB2RMDL) having the dedicated list makes it easier to involve them (or for them to get involved). Cheers, BobN=20 -----Original Message----- From: David Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Friday, April 13, 2007 1:05 PM To: j.schoenwaelder@iu-bremen.de; 'Romascanu, Dan (Dan)' Cc: ops-area@ietf.org Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area I agree; I find it hard to carry on similar discussions on a wide variety of mailing lists. I also would like to see the cross-posting to OPS lists reduced. It would be better to have fewer OPS mailing lists. dbh > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Friday, April 13, 2007 7:36 AM > To: Romascanu, Dan (Dan) > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area >=20 > On Fri, Apr 13, 2007 at 11:39:17AM +0300, Romascanu, Dan (Dan) wrote: > > Following the OPS area meetings and mini-BOF sessions in=20 > Prague we have > > created two new mail lists:=20 > >=20 > > meta-model@ietf.org - this list will focus on discussions=20 > about the need > > and requirements for a meta data model in the network=20 > management space > > and what the IETF should do on this respect > >=20 > > mib2rdml@ietf.org - the list will discuss the need and=20 > requirements of > > converting MIB modules into resource models for the SOA/Web Services > > Management environment and work that should be done in the=20 > IETF in this > > field > >=20 > > The two lists will create a framework for discussions and=20 > contributions > > for the respective subjects and will allow the operations=20 > and management > > community to debate the level of interest and what should be done > > respectively in the two fields. If you are interested=20 > please subscribe > > and participate.=20 >=20 > I would prefer if mailing lists are created once there is actually > enough traffic to warrant a new mailing list. I believe we already > have too many "ops" mailing lists and I like to ask the ADs to > consider actually merging lists instead of creating more. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 13:18: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 1HcPPf-0004gb-K2; Fri, 13 Apr 2007 13:18:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPPd-0004ZM-Rm for ops-area@ietf.org; Fri, 13 Apr 2007 13:18:17 -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 1HcPPd-0001uv-4v for ops-area@ietf.org; Fri, 13 Apr 2007 13:18:17 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 13 Apr 2007 13:18:16 -0400 X-IronPort-AV: i="4.14,408,1170651600"; d="scan'208"; a="3370265:sNHT8419818" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area Date: Fri, 13 Apr 2007 20:17:39 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] New Mailing Lists in the OPS area Thread-Index: Acd9v+UlvvzYZ0SVTZm/BU2OUJmnhgALS7RgAABwlMA= References: <20070413113542.GA26504@elstar.local> <0e7001c77ded$e1b6e750$0600a8c0@china.huawei.com> From: "Romascanu, Dan \(Dan\)" To: "David Harrington" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org I have to respectfully disagree with you two on this. Creating a list does not require too many resources. It is easier to measure the level of interest on a specific topics if the discussions are focused on a separate list where only who is interested in the respective topics subscribes. If there is enough interest on the topics we can continue, otherwise if the interest dies the list can be shut done. We have done this recently with the ntdp list.=20 Dan =20 =20 > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, April 13, 2007 8:05 PM > To: j.schoenwaelder@iu-bremen.de; Romascanu, Dan (Dan) > Cc: ops-area@ietf.org > Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area >=20 > I agree; I find it hard to carry on similar discussions on a=20 > wide variety of mailing lists. I also would like to see the=20 > cross-posting to OPS lists reduced. It would be better to=20 > have fewer OPS mailing lists. >=20 > dbh >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: Friday, April 13, 2007 7:36 AM > > To: Romascanu, Dan (Dan) > > Cc: ops-area@ietf.org > > Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area > >=20 > > On Fri, Apr 13, 2007 at 11:39:17AM +0300, Romascanu, Dan (Dan) > wrote: > > > Following the OPS area meetings and mini-BOF sessions in > > Prague we have > > > created two new mail lists:=20 > > >=20 > > > meta-model@ietf.org - this list will focus on discussions > > about the need > > > and requirements for a meta data model in the network > > management space > > > and what the IETF should do on this respect > > >=20 > > > mib2rdml@ietf.org - the list will discuss the need and > > requirements of > > > converting MIB modules into resource models for the SOA/Web > Services > > > Management environment and work that should be done in the > > IETF in this > > > field > > >=20 > > > The two lists will create a framework for discussions and > > contributions > > > for the respective subjects and will allow the operations > > and management > > > community to debate the level of interest and what should be done=20 > > > respectively in the two fields. If you are interested > > please subscribe > > > and participate.=20 > >=20 > > I would prefer if mailing lists are created once there is actually=20 > > enough traffic to warrant a new mailing list. I believe we already=20 > > have too many "ops" mailing lists and I like to ask the ADs to=20 > > consider actually merging lists instead of creating more. > >=20 > > /js > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen > > P.O. Box 750 561,=20 > > 28725 Bremen, Germany > >=20 > > _______________________________________________ > > OPS-AREA mailing list > > OPS-AREA@ietf.org > > https://www1.ietf.org/mailman/listinfo/ops-area > >=20 >=20 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 14:04: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 1HcQ8b-0000HD-1X; Fri, 13 Apr 2007 14:04:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcQ8Z-0000Et-6x for ops-area@ietf.org; Fri, 13 Apr 2007 14:04:43 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcQ8Y-0001rH-M3 for ops-area@ietf.org; Fri, 13 Apr 2007 14:04:43 -0400 Received: by ug-out-1314.google.com with SMTP id 72so486151ugd for ; Fri, 13 Apr 2007 11:04:42 -0700 (PDT) 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:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=MVG04+pe3Nb/cwu+0Stjoue/iSL4729jlPVSWLcomlo/1TTvdTHv5wQq4kGyVjfafx2at1N4Qz37lUGxUGF4dx8lg9RwkPM1vsst1cqQ1omxqZi86WRbkpAEQKtGj/ZU0OSk07S6XzDU4z51CX24YQ9EbSSQlIGgB0+/rjGOgPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=D/vGKLc0LLS69PRK8NihgLniAx3ELtAj1Gmya9sahZzfqos/6orM9PnNvi0wk4dGZ/YE2k6rs2/aB5myULuKI6CMJDoShnJ9HXKKOxSBhzQlJpIStmoZnA7h/nh1rOthpG/FQ0v2dZrAJ2LiXhnMIhRghZ6vbXNGnKz900pbnnI= Received: by 10.66.232.11 with SMTP id e11mr2156458ugh.1176487481877; Fri, 13 Apr 2007 11:04:41 -0700 (PDT) Received: from ?137.208.224.46? ( [137.208.224.46]) by mx.google.com with ESMTP id y37sm5490263iky.2007.04.13.11.04.37; Fri, 13 Apr 2007 11:04:40 -0700 (PDT) Message-ID: <461FC612.5080606@wu-wien.ac.at> Date: Fri, 13 Apr 2007 20:04:02 +0200 From: Michael Alexander User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ops-area@ietf.org, mib2rdml@ietf.org, nmrg@ibr.cs.tu-bs.de, meta-model@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [OPS-AREA] IETF68 Follow-Up: NE/Facilities/Lines/Protocols/Services Data Modeling X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org In follow-up to the IETF 68 Mini-BOF on NE/Facilities/Lines/Protocols/Services Data Modeling: Effort Summary: =============== Modeling network of network elements (NE), facilities, lines, protocols and services for substantially easing development and operation of element manager systems (EMS), network management systems (NMS) and operations support systems (OSS). The framework is independent of the access method used, including SNMP, CLI, Netconf, Corba, CMIP, XML-RPC, etc.) It covers configuration, alarms, current-historical performance, accounting management and security. The frameworks builds on and reuses the existing base of MIBs. Effort Sub-Projects: ==================== - Namespaces - Object Model - Base Meta Model - Alarm Template Base Meta Model - Device/Line/Service/Protocol Class Meta Model - Device/Line/Service/Protocol Type Meta Model - Device/Line/Service/Protocol Model - MIB Transformation - Model Instances three devices, one line type, one protocol and one service. Draft: http://www.ietf.org/internet-drafts/draft-alexan-datamod-00.txt ppt: http://www3.ietf.org/proceedings/07mar/slides/opsarea-4/opsarea-4.ppt Next Steps: =========== This is a complex project which needs the cooperation of multiple foci in order to produce meta models and namespaces which very substantially decrease the burden of building EMS/NMS/OSSs and model protocols, devices etc. At this stage there has been a fair amount of interest for: - creating a base meta model (language) - and to a lesser extent an object model Skill that is in definite need is for: - Device Class Specialists: (IP-Router, ATM, SONET/SDH, IP PBX etc.) - Protocol Specialists: e.g. BGP, OSPF, SIP, MPLS - Service Specialists: eg. SIP IP Voice Provided the necessary skill comes together, and a structure is built that supports the required interaction for a layered modeling effort, a full BoF towards a Data Modeling WG at either at IETF69 or 70 would be targeted. FP7 Filing: =========== There has been substantial interest from many parties in the filing of this as an EU framework project 7 (FP7) project. The targeted filing budget sum would exceed EUR 8 Million. The number of participants would be >20, and can be from all over the world (NOT only the EU). Please send me an email if you or your organization is interested in participating. Please use the list meta-model@ietf.org for discussion. Best Regards, Dr. Michael Alexander WU Wien Dept. of Information Systems malexand@wu-wien.ac.at / +43.1.31336.4467 GSM +43.699.1228.3586 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Apr 13 15:26: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 1HcRPp-0006v7-Ik; Fri, 13 Apr 2007 15:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcRPo-0006v1-50 for ops-area@ietf.org; Fri, 13 Apr 2007 15:26:36 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcRPm-0004mH-P9 for ops-area@ietf.org; Fri, 13 Apr 2007 15:26:36 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 83B7C6DD56; Fri, 13 Apr 2007 21:26:33 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 15332-04; Fri, 13 Apr 2007 21:26:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 296746DD4C; Fri, 13 Apr 2007 21:26:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6C74821980D; Fri, 13 Apr 2007 21:26:27 +0200 (CEST) Date: Fri, 13 Apr 2007 21:26:27 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area Message-ID: <20070413192627.GA27563@elstar.local> References: <20070413113542.GA26504@elstar.local> <0e7001c77ded$e1b6e750$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Fri, Apr 13, 2007 at 08:17:39PM +0300, Romascanu, Dan (Dan) wrote: > I have to respectfully disagree with you two on this. Creating a list > does not require too many resources. It is easier to measure the level > of interest on a specific topics if the discussions are focused on a > separate list where only who is interested in the respective topics > subscribes. If there is enough interest on the topics we can continue, > otherwise if the interest dies the list can be shut done. We have done > this recently with the ntdp list. I believe there is value in having diverse discussions on an ops-area list if we want to be one area. If we create a separate list for every little topic that comes up, we can give up the idea to have an ops area (or we will see excessive cross postings - and I feel we are already on a good path towards it). So yes, I respectfully disagree. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sat Apr 14 07:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcg0J-0007k9-Ot; Sat, 14 Apr 2007 07:01:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcg0H-0007jv-IA; Sat, 14 Apr 2007 07:01:13 -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 1Hcg0G-0005as-4E; Sat, 14 Apr 2007 07:01:13 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 14 Apr 2007 07:01:11 -0400 X-IronPort-AV: i="4.14,410,1170651600"; d="scan'208"; a="3555052:sNHT8998032" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Apr 2007 14:00:54 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: UPDATED Agenda and Package for April 19, 2007 Telechat Thread-Index: Acd+Dru/+5xz8MzKRO28VbP1qZRp3wAdKqfA From: "Romascanu, Dan \(Dan\)" To: , , "IETF MIBs" , , "capwap" X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: Subject: [OPS-AREA] FW: UPDATED Agenda and Package for April 19, 2007 Telechat X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Please find below the preliminary agenda of the 4/19 IESG telechat. Please have a look at the documents proposed for approval and let me know if there are any comments or concerns until 4/18 COB the latest.=20 Note that the agenda includes one MIB document proposed for standards and three CAPWAP initial submission documents that are proposed to be published as informational RFCs.=20 Thanks and Regards, Dan =20 =20 =20 2. Protocol Actions Reviews should focus on these questions: "Is this document a reasonable basis on which to build the salient part of the Internet infrastructure? If not, what changes would make it so?" 2.1 WG Submissions 2.1.1 New Item o draft-ietf-simple-presence-rules-09.txt Presence Authorization Rules (Proposed Standard) - 1 of 5=20 Token: Jon Peterson o draft-ietf-ips-isns-mib-11.txt Definitions of Managed Objects for iSNS (Internet Storage Name Service)=20 (Proposed Standard) - 2 of 5=20 Note: PROTO Shepherd: David Black (Black_David@emc.com). MIB Doctor: Bert=20 Wijnen (bwijnen@lucent.com). Initial expert review: Keith McCloghrie (kzm@cisco.com)=20 Token: Lars Eggert o draft-ietf-rmt-fec-bb-revised-06.txt Forward Error Correction (FEC) Building Block (Proposed Standard) - 3 of 5=20 Token: Magnus Westerlund o draft-ietf-16ng-ipv6-over-ipv6cs-09.txt IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16=20 Networks (Proposed Standard) - 4 of 5=20 Note: NOTE: There are some LC and IEEE-review comments pending=20 Token: Jari Arkko o draft-ietf-behave-tcp-06.txt NAT Behavioral Requirements for TCP (BCP) - 5 of 5=20 Token: Magnus Westerlund 2.1.2 Returning Item o draft-ietf-pkix-lightweight-ocsp-profile-08.txt Lightweight OCSP Profile for High Volume Environments (Proposed Standard) -=20 1 of 1=20 Token: Russ Housley 2.2 Individual Submissions 2.2.1 New Item o draft-siemborski-imap-sasl-initial-response-06.txt IMAP Extension for SASL Initial Client Response (Proposed Standard) - 1 of=20 1=20 Token: Chris Newman 2.2.2 Returning Item NONE 3. Document Actions 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.1.1 New Item o draft-ietf-16ng-ipv6-link-model-analysis-03.txt Analysis of IPv6 Link Models for 802.16 based Networks (Informational) - 1=20 of 2=20 Note: PROTO Shepherd is Soohong Daniel Park=20 <soohong.park@samsung.com>=20 Token: Jari Arkko o draft-ietf-trill-routing-reqs-02.txt TRILL Routing Requirements in Support of RBridges (Informational) - 2 of 2=20 Token: Mark Townsley 3.1.2 Returning Item o Five-document ballot: - 1 of 1 - draft-ietf-hip-base-07.txt Host Identity Protocol (Experimental)=20 - draft-ietf-hip-esp-05.txt Using ESP transport format with HIP (Experimental)=20 - draft-ietf-hip-registration-02.txt Host Identity Protocol (HIP) Registration Extension (Experimental) - draft-ietf-hip-mm-05.txt End-Host Mobility and Multihoming with the Host Identity Protocol (Experimental)=20 - draft-ietf-hip-rvs-05.txt Host Identity Protocol (HIP) Rendezvous Extension (Experimental)=20 Token: Mark Townsley 3.2 Individual Submissions Via AD Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" 3.2.1 New Item o draft-allen-sipping-poc-p-answer-state-header-05.txt The P-Answer-State Header Extension to the Session Initiation Protocol for=20 the Open Mobile Alliance Push-to-talk over Cellular (Informational) - 1 of=20 1=20 Note: SIPPING RFC 3427 Expert Reviewer is Gonzalo Camarillo; dependency of=20 OMA=20 Token: Jon Peterson 3.2.2 Returning Item NONE 3.3 Independent Submissions Via RFC Editor The IESG will use RFC 3932 responses: 1) The IESG has not found any conflict between this document and IETF work; 2) The IESG thinks that this work is related to IETF work done in WG , but this does not prevent publishing; 3) The IESG thinks that publication is harmful to work in WG and recommends not publishing at this time; 4) The IESG thinks that this document violates the IETF procedures for and should therefore not be published without IETF review and IESG approval; 5) The IESG thinks that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. =20 =20 Other matters may be recorded in comments to be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-iino-capwap-wicop-02.txt Wireless LAN Control Protocol (WiCoP) (Informational) - 1 of 2=20 Note: This document is an independent submission via the RFC Editor. In=20 conformace with RFC 3932, Section 4, the IESG requests the publication of=20 the following note: "This RFC documents the WiCoP protocol as it was when=20 submitted to the IETF as a basis for further work in the CAPWAP WG, and=20 therefore it may resemble a current IETF work in progress or a published=20 IETF work. This RFC itself is not a candidate for any level of Internet.=20 Standard. The IETF disclaims any knowledge of the fitness of this RFC for=20 any purpose, and in particular notes that it has not had complete IETF =20 review for such things as security, congestion control, or inappropriate=20 interaction with deployed protocols. The RFC Editor has chosen to publish=20 this document at its discretion."=20 Token: Dan Romascanu o draft-ohara-capwap-lwapp-04.txt Light Weight Access Point Protocol (Informational) - 2 of 2=20 Note: This document is an independent submission via the RFC Editor. In=20 conformace with RFC 3932, Section 4, the IESG requests the publication of=20 the following note: "This RFC documents the LWAPP protocol as it was when=20 submitted to the IETF as a basis for further work in the CAPWAP WG, and=20 therefore it may resemble a current IETF work in progress or a published=20 IETF work. This RFC itself is not a candidate for any level of Internet=20 Standard. The IETF disclaims any knowledge of the fitness of this RFC for=20 any purpose, and in particular notes that it has not had complete IETF =20 review for such things as security, congestion control, or inappropriate=20 interaction with deployed protocols. The RFC Editor has chosen to publish=20 this document at its discretion."=20 Token: Dan Romascanu 3.3.2 Returning Item o draft-narasimhan-ietf-slapp-01.txt SLAPP : Secure Light Access Point Protocol (Informational) - 1 of 1=20 Note: This document is an independent submission via the RFC Editor. In=20 conformace with RFC 3932, Section 4, the IESG requests the publication of=20 the following note: "This RFC documents the SLAPP protocol as it was when=20 submitted to the IETF as a basis for further work in the CAPWAP WG, and=20 therefore it may resemble a current IETF work in progress or a published=20 IETF work. This RFC itself is not a candidate for any level of Internet=20 Standard. The IETF disclaims any knowledge of the fitness of this RFC for=20 any purpose, and in particular notes that it has not had complete IETF =20 review for such things as security, congestion control, or inappropriate=20 interaction with deployed protocols. The RFC Editor has chosen to publish=20 this document at its discretion.".=20 Token: Dan Romascanu _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Apr 15 01:11: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 1Hcx0H-0006Xo-7F; Sun, 15 Apr 2007 01:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hcx0F-0006Xc-S5; Sun, 15 Apr 2007 01:10:19 -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 1Hcx0E-0007Tz-Hr; Sun, 15 Apr 2007 01:10:19 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 15 Apr 2007 01:10:17 -0400 X-IronPort-AV: i="4.14,411,1170651600"; d="txt'?scan'208"; a="3771386:sNHT9611070" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C77F1C.5B631236" Date: Sun, 15 Apr 2007 08:10:17 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: [New-work] OMA New Work - 1 New Work Item Approved] Thread-Index: Acd/GTHohag0tBXbRYS+G5lJitVfRAAAudYQ From: "Romascanu, Dan \(Dan\)" To: , "NETCONF Goes On" X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Subject: [OPS-AREA] FW: [Fwd: [New-work] OMA New Work - 1 New Work Item Approved] X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C77F1C.5B631236 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe that this may be of some interest.=20 Dan =20 -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: Sunday, April 15, 2007 7:47 AM To: IAB; Iesg (E-mail) Subject: [Fwd: [New-work] OMA New Work - 1 New Work Item Approved] FYI /Loa -------- Original Message -------- Subject: [New-work] OMA New Work - 1 New Work Item Approved Date: Thu, 12 Apr 2007 16:06:16 +0200 From: Victoria Gray To: Dear All, OMA would like to inform all the organisations subscribed to the IETF new-work list of the approval of 1 revised work item: 1 Lock and Wipe Management Object WI: http://www.openmobilealliance.org/ftp/Public_documents/TP/Permanent_docu ments/OMA-WID_0144-LAWMO-V1_0-20070410-A.zip The overall goal of the LAWMO is, to provide Management Authorities (e.g. Operators, Device Manufacturers and 3rd party service providers) an effective way to help their subscribers protect their devices and data. Based on the above, it is proposed that the work item will address the following areas: 1) Support the capability to lock terminal interface functions. In the case of lock all terminal interface functionality the terminal should only allow: incoming calls, emergency calls and data sessions. 2) Support capability to unlock the user interface on the device. 3) When the phone is in the lock state the terminal must accept remote management only from the Authorised DM Server that invoked the Lock function in the first place. No user input will be required to action these operations. 4) Support capability to wipe user data from the device. 5) Support resetting the terminal to a factory clean state. This means clearing of memory and initialisation of the file systems and databases in the terminal. 6) The LAWMO will indicate the lock, unlock or wipe operation which needs to be executed but the actual operation processing and which part of user data to be locked, unlocked or wiped is out of scope of this work item.. This work item has been allocated to the OMA DM (Device Management WG) for specification development. Best regards, Victoria Gray on behalf of OMA. Victoria Gray FORApolis / DSO Tel +33 (0)4 92 94 49 23 Fax +33 (0)4 92 38 49 23 GSM +33 (0)6 73 99 62 90 victoria.gray@forapolis.com MSN: victoria.gray@forapolis.com Yahoo!: bluevicci Skype: victoria-gray Google: vics.gray@gmail.com -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se ------_=_NextPart_001_01C77F1C.5B631236 Content-Type: text/plain; name="ATT578925.txt" Content-Transfer-Encoding: base64 Content-Description: ATT578925.txt Content-Disposition: attachment; filename="ATT578925.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldy13b3Jr IG1haWxpbmcgbGlzdA0KTmV3LXdvcmtAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldy13b3JrDQoNCg== ------_=_NextPart_001_01C77F1C.5B631236 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area ------_=_NextPart_001_01C77F1C.5B631236-- From ops-area-bounces@ietf.org Sun Apr 15 05:21:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd0v4-0004uM-1Z; Sun, 15 Apr 2007 05:21:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd0v2-0004u9-HA for ops-area@ietf.org; Sun, 15 Apr 2007 05:21:12 -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 1Hd0uz-0000Ch-7y for ops-area@ietf.org; Sun, 15 Apr 2007 05:21:12 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 15 Apr 2007 05:21:08 -0400 X-IronPort-AV: i="4.14,412,1170651600"; d="scan'208"; a="3917668:sNHT7744374" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area Date: Sun, 15 Apr 2007 12:20:27 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] New Mailing Lists in the OPS area Thread-Index: Acd+Aag2chpYtz5cREOUobzRvxOdUABO5bUA References: <20070413113542.GA26504@elstar.local> <0e7001c77ded$e1b6e750$0600a8c0@china.huawei.com> <20070413192627.GA27563@elstar.local> From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Friday, April 13, 2007 10:26 PM > To: Romascanu, Dan (Dan) > Cc: David Harrington; ops-area@ietf.org > Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area >=20 > On Fri, Apr 13, 2007 at 08:17:39PM +0300, Romascanu, Dan (Dan) wrote: >=20 > > I have to respectfully disagree with you two on this.=20 > Creating a list=20 > > does not require too many resources. It is easier to=20 > measure the level=20 > > of interest on a specific topics if the discussions are=20 > focused on a=20 > > separate list where only who is interested in the respective topics=20 > > subscribes. If there is enough interest on the topics we=20 > can continue,=20 > > otherwise if the interest dies the list can be shut done.=20 > We have done=20 > > this recently with the ntdp list. >=20 > I believe there is value in having diverse discussions on an=20 > ops-area list if we want to be one area. If we create a=20 > separate list for every little topic that comes up, we can=20 > give up the idea to have an ops area (or we will see=20 > excessive cross postings - and I feel we are already on a=20 > good path towards it). >=20 > So yes, I respectfully disagree. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 I agree that there is value in having discussions on the ops-area list when the topics are of general interest for the area. In this case however we are using the specialized lists to let people work on more detailed proposals in specific areas of interest without copying necessarily all participants in the area. This would actually result IMO in a reduction of the level of cross-posting and unwanted traffic. This method would also allow to determine more easily the level of interest on a specific topic. If and when these folks would have some results or recommendations they could bring those back to the ops-area lists.=20 Dan _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Sun Apr 15 14:16: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 1Hd9Ge-0000h8-0v; Sun, 15 Apr 2007 14:16:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd9Gc-0000h1-Ab for ops-area@ietf.org; Sun, 15 Apr 2007 14:16:02 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd9GY-00082m-Hn for ops-area@ietf.org; Sun, 15 Apr 2007 14:16:02 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 609817013D; Sun, 15 Apr 2007 20:15:57 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 30913-02; Sun, 15 Apr 2007 20:15:53 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id C576A6DE0D; Sun, 15 Apr 2007 20:15:53 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C2882226125; Sun, 15 Apr 2007 20:15:50 +0200 (CEST) Date: Sun, 15 Apr 2007 20:15:50 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area Message-ID: <20070415181550.GA19234@elstar.local> References: <20070413113542.GA26504@elstar.local> <0e7001c77ded$e1b6e750$0600a8c0@china.huawei.com> <20070413192627.GA27563@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Sun, Apr 15, 2007 at 12:20:27PM +0300, Romascanu, Dan (Dan) wrote: > I agree that there is value in having discussions on the ops-area list > when the topics are of general interest for the area. In this case > however we are using the specialized lists to let people work on more > detailed proposals in specific areas of interest without copying > necessarily all participants in the area. This would actually result IMO > in a reduction of the level of cross-posting and unwanted traffic. This > method would also allow to determine more easily the level of interest > on a specific topic. If and when these folks would have some results or > recommendations they could bring those back to the ops-area lists. Several lists related to data modeling seems odd to me and I believe this will actually lead to more cross-postings and duplicate messages. Why not move all traffic in meta-model, mib2rdml, ngo to ops-nm? This would turn 4 lists into 1 and clearly reduces the chances for cross-postings and duplicate discussions or ingorance of some other people's work. (I believe ops-nm seems to have about 3 messages per months recently, most of them cross-postings. ;-) I addition, I like to suggest a policy that all announcements will go to ops-area only; so if people want to receive general announcements interesting for the OPS area, they should ensure that they are properly subscribed to the ops-area list. /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Apr 16 04:09:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMH1-0004B6-FM; Mon, 16 Apr 2007 04:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdMGz-0004Az-Nf for ops-area@ietf.org; Mon, 16 Apr 2007 04:09:17 -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 1HdMGy-0006wJ-G4 for ops-area@ietf.org; Mon, 16 Apr 2007 04:09:17 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 16 Apr 2007 04:09:15 -0400 X-IronPort-AV: i="4.14,414,1170651600"; d="scan'208"; a="4075566:sNHT7176756" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [OPS-AREA] New Mailing Lists in the OPS area Date: Mon, 16 Apr 2007 11:09:15 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] New Mailing Lists in the OPS area Thread-Index: Acd/iiAXbiv5lwu5TnGKajDB0mYmtQAc3CJQ References: <20070413113542.GA26504@elstar.local> <0e7001c77ded$e1b6e750$0600a8c0@china.huawei.com> <20070413192627.GA27563@elstar.local> <20070415181550.GA19234@elstar.local> From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi Juergen, See in-line.=20 Dan =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Sunday, April 15, 2007 9:16 PM > To: Romascanu, Dan (Dan) > Cc: David Harrington; ops-area@ietf.org > Subject: Re: [OPS-AREA] New Mailing Lists in the OPS area >=20 > On Sun, Apr 15, 2007 at 12:20:27PM +0300, Romascanu, Dan (Dan) wrote: > Several lists related to data modeling seems odd to me and I=20 > believe this will actually lead to more cross-postings and=20 > duplicate messages. > Why not move all traffic in meta-model, mib2rdml, ngo to=20 > ops-nm? This would turn 4 lists into 1 and clearly reduces=20 > the chances for cross-postings and duplicate discussions or=20 > ingorance of some other people's work. (I believe ops-nm=20 > seems to have about 3 messages per months recently, most of=20 > them cross-postings. ;-) I propose that for the time being we stick to what was discussed in Prague. We already created the mib2rdml and meta-model lists, let us give them the opportunity to do their work and come again and make an assessment of where they are by the time of the Chicago meeting.=20 >=20 > I addition, I like to suggest a policy that all announcements=20 > will go to ops-area only; so if people want to receive=20 > general announcements interesting for the OPS area, they=20 > should ensure that they are properly subscribed to the ops-area list. I agree with you on this. Actually my preference is to limit even more the announcements to those that are relevant to the IETF work. Dan =20 >=20 > /js >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Apr 18 02:27:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3dK-0003VX-CE; Wed, 18 Apr 2007 02:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3dJ-0003VS-B6 for ops-area@ietf.org; Wed, 18 Apr 2007 02:27:13 -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 1He3dJ-0004fX-2Z for ops-area@ietf.org; Wed, 18 Apr 2007 02:27:13 -0400 Received: from unknown (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by co300216-co-outbound.avaya.com with ESMTP; 18 Apr 2007 02:27:12 -0400 X-IronPort-AV: i="4.14,421,1170651600"; d="scan'208"; a="5077329:sNHT7359528" content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2007 09:26:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area WG Charter proposal Thread-Index: AceBWpPQLeG5ZGAvQ2C098C/9NKCFQAJhHJQ From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Subject: [OPS-AREA] OPS Area WG Charter proposal X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Following the discussions in the OPS Area meetings in Prague, please find below an initial proposal for chartering a OPS Area Working Group. Please provide feedback, comments and proposals for charter items to ops-area@ietf.org.=20 Ron and Dan Operations and Management Area Working Group (opsawg) Chair(s):=20 TBD TBD Area Directors:=20 Dan Romascanu Ronald Bonica The Operations and Management Area receives occasional proposals for=20 the development and publication of RFCs dealing with operational and=20 management topics that are not in scope of an existing working group=20 or do not justify the formation of a new working group. The OPSAWG will=20 serve as the forum for developing such work items in the IETF. The OPSAWG mailing list is an open discussion forum for such work=20 items, when they arise. The working group meets if there are active proposals that require discussion. The working group=20 milestones are updated as needed to reflect the current work items and=20 their associated milestones. All new work items and rechartering=20 proposals will be brought for approval with the IESG. =20 The focus of the work will be on topics that govern the behavior or=20 WGs in the O&M area (e.g., manageability requirements) and on small, highly focused projects that don't merit a=20 WG of their own or belong to WGs that have already concluded (e.g.=20 advancement of documents on the standards track, application=20 statements, extensions of MIB modules). =20 The OPSAWG will undertake only work items that are proved to have at=20 least a reasonable level of interest from the operators and users=20 community and have a committed number of editors and reviewers. It is=20 not within the scope of the OPSAWG to pick up failed WG work or parts=20 of a WG charter items that could not come to convergence on what they=20 were chartered to do. =20 The currently active OPSAWG work items mostly fall under the following topics: =20 (A) Development of a BCP document that will provide guidelines for=20 operational and manageability requirements that need to be covered in=20 IETF documents, especially those documents that include requirements=20 and specification of new protocols or protocol extensions. =20 (B) Templates and tools for Operations and Management Area Documents =20 (C) Maintenance and extensions of documents that define MIB modules=20 which were developped in working groups that have concluded. =20 Goals and Milestones: =20 June 2007 - Initial submission for the Guidelines for Considering=20 Operations and Management of New Protocols Internet-Draft=20 December 2007 - WGLC for the Guidelines for Considering Operations and=20 Management of New Protocols Internet-Draft=20 February 2008 - Submit the Guidelines for Considering Operations and=20 Management of New Protocols Internet-Draft to the IESG for consideration as BCP _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Apr 18 02:43:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3t4-0005Ch-NP; Wed, 18 Apr 2007 02:43:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3t3-0005CX-Om for ops-area@ietf.org; Wed, 18 Apr 2007 02:43:29 -0400 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1He3t2-0000LS-EU for ops-area@ietf.org; Wed, 18 Apr 2007 02:43:29 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A91B176764; Wed, 18 Apr 2007 08:43:27 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius.iu-bremen.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28658-01; Wed, 18 Apr 2007 08:43:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.iu-bremen.de (Postfix) with ESMTP id 2E3286DCF1; Wed, 18 Apr 2007 08:43:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B4AD722A05C; Wed, 18 Apr 2007 08:43:20 +0200 (CEST) Date: Wed, 18 Apr 2007 08:43:20 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [OPS-AREA] OPS Area WG Charter proposal Message-ID: <20070418064320.GC6729@elstar.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15 (2007-04-06) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org On Wed, Apr 18, 2007 at 09:26:35AM +0300, Romascanu, Dan (Dan) wrote: > Following the discussions in the OPS Area meetings in Prague, please > find below an initial proposal for chartering a OPS Area Working Group. > Please provide feedback, comments and proposals for charter items to > ops-area@ietf.org. A quick question - do small (SNMP) protocol extensions also fall into this WG? I am talking about things like the SNMP over IEEE 802 spec we did last year to support work in the IEEE or the SNMP LocalEngineID document I am currently editing (draft-schoenw-snmp-discover-02.txt). The charter specifically talks about MIB modules. I am not specifically asking for inclusion; the individual submission approach we used for the SNMP over IEEE 802 spec was fast and pretty much painless. Perhaps I am just asking for guideance how draft-schoenw-snmp-discover-02.txt document should be handled... ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Apr 18 03:12:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4Kw-00055Y-TF; Wed, 18 Apr 2007 03:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He4Kw-00053R-8C for ops-area@ietf.org; Wed, 18 Apr 2007 03:12:18 -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 1He4Kv-000510-0x for ops-area@ietf.org; Wed, 18 Apr 2007 03:12:18 -0400 Received: from 51.105.64.135.in-addr.arpa (HELO IS0004AVEXU1.global.avaya.com) ([135.64.105.51]) by nj300815-nj-outbound.avaya.com with ESMTP; 18 Apr 2007 03:12:16 -0400 X-IronPort-AV: i="4.14,421,1170651600"; d="scan'208"; a="4883674:sNHT6768810" content-class: urn:content-classes:message Subject: RE: [OPS-AREA] OPS Area WG Charter proposal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2007 10:11:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] OPS Area WG Charter proposal Thread-Index: AceBhOLhOi+IAaKBReKl/aK36Y+apgAAzd/w References: <20070418064320.GC6729@elstar.local> From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Long-term we want to reduce the load on the ADs and ensure that such documents undergo wider community review. For these reasons I believe that such documents would fall under the scope and we should find some charter words to make this clear, e.g.: D) minor extensions to management protocols and definition of new transport mappings of management protocols For the specific case, we will not delay ongoing work, and we may still use individual submission via AD unless the OPSAWG is approved quickly.=20 Dan =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 > Sent: Wednesday, April 18, 2007 9:43 AM > To: Romascanu, Dan (Dan) > Cc: ops-area@ietf.org > Subject: Re: [OPS-AREA] OPS Area WG Charter proposal >=20 > On Wed, Apr 18, 2007 at 09:26:35AM +0300, Romascanu, Dan (Dan) wrote: >=20 > > Following the discussions in the OPS Area meetings in=20 > Prague, please=20 > > find below an initial proposal for chartering a OPS Area=20 > Working Group. > > Please provide feedback, comments and proposals for charter=20 > items to=20 > > ops-area@ietf.org. >=20 > A quick question - do small (SNMP) protocol extensions also=20 > fall into this WG? I am talking about things like the SNMP=20 > over IEEE 802 spec we did last year to support work in the=20 > IEEE or the SNMP LocalEngineID document I am currently=20 > editing (draft-schoenw-snmp-discover-02.txt). > The charter specifically talks about MIB modules. >=20 > I am not specifically asking for inclusion; the individual=20 > submission approach we used for the SNMP over IEEE 802 spec=20 > was fast and pretty much painless. Perhaps I am just asking=20 > for guideance how draft-schoenw-snmp-discover-02.txt document=20 > should be handled... ;-) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Apr 18 20:27:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeKUB-00055K-Cd; Wed, 18 Apr 2007 20:26:55 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1HeKU9-00053j-16 for ops-area-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 20:26:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeKU6-00053b-7F for ops-area@ietf.org; Wed, 18 Apr 2007 20:26:50 -0400 Received: from sccrmhc11.comcast.net ([204.127.200.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeKU4-0002Ib-TE for ops-area@ietf.org; Wed, 18 Apr 2007 20:26:50 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (sccrmhc11) with SMTP id <2007041900264801100fg745e>; Thu, 19 Apr 2007 00:26:48 +0000 From: "David Harrington" To: "'Romascanu, Dan \(Dan\)'" , References: Subject: RE: [OPS-AREA] OPS Area WG Charter proposal Date: Wed, 18 Apr 2007 20:26:27 -0400 Message-ID: <02ff01c78219$5ea9fb60$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceBWpPQLeG5ZGAvQ2C098C/9NKCFQAJhHJQACXkVlA= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ops-area-bounces@ietf.org Hi, We are moving from an SNMP-focused to a multi-protocol focused approach. The MIB module templates I have been working on will help people develop the surrounding text for MIB modules (and then they #include the actual MIB module definitions into the document). Do you think we should develop a generic template that has similar sections, to provide the surrounding descripions for things like netconf data models, syslog structured data elements, and so on? Such a document template could include sections for 1) management framework boilerplate (probably with a pointer to the guidelines for operability and manageability) 2) conventions and terminology 3) an overview of the technology being managed via the data model 4) the structure of the data model 5) how the data model relates to other data models 6) definitions 7) security considerations (with specific NM-related guidelines) 8) IANA considerations (with NM-specific considerations) 9) normal sections for acknowledgements, references, etc. If you think this would be worth doing, should it be an item in the charter of the OPSWG? David Harrington dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, April 18, 2007 2:27 AM > To: ops-area@ietf.org > Subject: [OPS-AREA] OPS Area WG Charter proposal > > Following the discussions in the OPS Area meetings in Prague, please > find below an initial proposal for chartering a OPS Area > Working Group. > Please provide feedback, comments and proposals for charter items to > ops-area@ietf.org. > > Ron and Dan > > Operations and Management Area Working Group (opsawg) > > Chair(s): > > TBD > TBD > > Area Directors: > > Dan Romascanu > Ronald Bonica > > > The Operations and Management Area receives occasional proposals for > the development and publication of RFCs dealing with operational and > management topics that are not in scope of an existing working group > or do not justify the formation of a new working group. The > OPSAWG will > serve as the forum for developing such work items in the IETF. > > The OPSAWG mailing list is an open discussion forum for such work > items, when they arise. The working group meets if there > are active proposals that require discussion. The working group > milestones are updated as needed to reflect the current work > items and > their associated milestones. All new work items and rechartering > proposals will be brought for approval with the IESG. > > The focus of the work will be on topics that govern the behavior or > WGs in the O&M area (e.g., manageability > requirements) and on small, highly focused projects that > don't merit a > WG of their own or belong to WGs that have already concluded (e.g. > advancement of documents on the standards track, application > statements, extensions of MIB modules). > > The OPSAWG will undertake only work items that are proved to have at > least a reasonable level of interest from the operators and users > community and have a committed number of editors and > reviewers. It is > not within the scope of the OPSAWG to pick up failed WG work or parts > of a WG charter items that could not come to convergence on what they > were chartered to do. > > The currently active OPSAWG work items mostly fall under the following > topics: > > (A) Development of a BCP document that will provide guidelines for > operational and manageability requirements that need to be covered in > IETF documents, especially those documents that include requirements > and specification of new protocols or protocol extensions. > > (B) Templates and tools for Operations and Management Area Documents > > (C) Maintenance and extensions of documents that define MIB modules > which were developped in working groups that have concluded. > > Goals and Milestones: > > June 2007 - Initial submission for the Guidelines for Considering > Operations and Management of New Protocols Internet-Draft > > December 2007 - WGLC for the Guidelines for Considering > Operations and > Management of New Protocols Internet-Draft > > February 2008 - Submit the Guidelines for Considering Operations and > Management of New Protocols Internet-Draft to the IESG for > consideration > as BCP > > _______________________________________________ > OPS-AREA mailing list > OPS-AREA@ietf.org > https://www1.ietf.org/mailman/listinfo/ops-area > _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Apr 18 20:32:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeKZ7-0003hp-JG; Wed, 18 Apr 2007 20:32:01 -0400 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1HeKZ7-0003hj-09 for ops-area-confirm+ok@megatron.ietf.org; Wed, 18 Apr 2007 20:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeKZ6-0003hb-Mn for ops-area@ietf.org; Wed, 18 Apr 2007 20:32:00 -0400 Received: from rs32.luxsci.com ([65.61.166.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeKZ6-0002u8-7B for ops-area@ietf.org; Wed, 18 Apr 2007 20:32:00 -0400 Received: from [192.168.20.100] (c-24-218-138-247.hsd1.ma.comcast.net [24.218.138.247]) (authenticated bits=0) by rs32.luxsci.com (8.13.1/8.13.7) with ESMTP id l3J0Vt1v020456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Apr 2007 19:31:56 -0500 Message-ID: <4626B87A.30204@jdscons.com> Date: Wed, 18 Apr 2007 20:31:54 -0400 From: Jon Saperia User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: David Harrington Subject: Re: [OPS-AREA] OPS Area WG Charter proposal References: <02ff01c78219$5ea9fb60$0600a8c0@china.huawei.com> In-Reply-To: <02ff01c78219$5ea9fb60$0600a8c0@china.huawei.com> X-Spam-Score: 1.2 (+) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0747770051==" Errors-To: ops-area-bounces@ietf.org --===============0747770051== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To the extent you do this work, the different data models should be related. That is, if you create configuration data models, then the monitoring objects in existing MIB modules, or new MIB objects should be cross referenced.

/jon

David Harrington wrote: 
Hi,

We are moving from an SNMP-focused to a multi-protocol 
focused approach.

The MIB module templates I have been working on will help 
people develop the surrounding text for MIB modules (and then 
they #include the actual MIB module definitions into the document).

Do you think we should develop a generic template that has 
similar sections, to provide the surrounding descripions for 
things like netconf data models, syslog structured data 
elements, and so on? 

Such a document template could include sections for
1) management framework boilerplate (probably with a pointer 
to the guidelines for operability and manageability)
2) conventions and terminology
3) an overview of the technology being managed via the data model
4) the structure of the data model
5) how the data model relates to other data models
6) definitions <the actual data model>
7) security considerations (with specific NM-related guidelines)
8) IANA considerations (with NM-specific considerations)
9) normal sections for acknowledgements, references, etc.
 
If you think this would be worth doing, should it be an item 
in the charter of the OPSWG? 

David Harrington
dharrington@huawei.com 
dbharrington@comcast.net
ietfdbh@comcast.net
 

  
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
Sent: Wednesday, April 18, 2007 2:27 AM
To: ops-area@ietf.org
Subject: [OPS-AREA] OPS Area WG Charter proposal

Following the discussions in the OPS Area meetings in Prague, please
find below an initial proposal for chartering a OPS Area 
Working Group.
Please provide feedback, comments and proposals for charter items to
ops-area@ietf.org. 

Ron and Dan

Operations and Management Area Working Group (opsawg)

Chair(s): 

TBD
TBD

Area Directors: 

Dan Romascanu <dromasca@avaya.com>
Ronald Bonica <rbonica@juniper.net>


The Operations and Management Area receives occasional proposals for
    

  
the development and publication of RFCs dealing with operational and
    

  
management topics that are not in scope of an existing working group
    

  
or do not justify the formation of a new working group. The 
OPSAWG will 
serve as the forum for developing such work items in the IETF.

The OPSAWG mailing list is an open discussion forum for such work 
items, when they arise. The working group meets if there
are active proposals that require discussion. The working group 
milestones are updated as needed to reflect the current work 
items and 
their associated milestones. All new work items and rechartering 
proposals will be brought for approval with the IESG.
  
The focus of the work will be on topics that govern the behavior or 
WGs in the O&M area  (e.g., manageability
requirements) and on small, highly focused projects that 
don't merit a 
WG of their own or belong to WGs that have already concluded (e.g. 
advancement of documents on the standards track,  application 
statements, extensions of MIB modules).
  
The OPSAWG will undertake only work items that are proved to have at
    

  
least a reasonable level of interest from the operators and users 
community and have a committed number of editors and 
reviewers.  It is 
not within the scope of the OPSAWG to pick up failed WG work or
    
parts 
  
of a WG charter items that could not come to convergence on what
    
they 
  
were chartered to do.
  
The currently active OPSAWG work items mostly fall under the
    
following
  
topics:
  
(A) Development of a BCP document that will provide guidelines for 
operational and manageability requirements that need to be covered
    
in 
  
IETF documents, especially those documents that include requirements
    

  
and specification of new protocols or protocol extensions.
  
(B) Templates and tools for Operations and Management Area Documents
  
(C) Maintenance and extensions of documents that define MIB modules 
which were developped in working groups that have concluded.
  
Goals and Milestones:
  
June 2007 - Initial submission for the Guidelines for Considering 
Operations and Management of New Protocols Internet-Draft 

December  2007 - WGLC for the Guidelines for Considering 
Operations and 
Management of New Protocols Internet-Draft 

February 2008 - Submit the Guidelines for Considering Operations and
    

  
Management of New Protocols Internet-Draft to the IESG for 
consideration
as BCP

_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-area

    




_______________________________________________
OPS-AREA mailing list
OPS-AREA@ietf.org
https://www1.ietf.org/mailman/listinfo/ops-area

  

-- 
Jon Saperia
(cell) 617-201-2655
(Eve.) 978-461-0264
--===============0747770051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area --===============0747770051==--