From ops-area-bounces@ietf.org Mon Nov 05 02:26:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IowM9-0001xV-82; Mon, 05 Nov 2007 02:26:45 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IowM7-0001vA-Hp for ops-area-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 02:26:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IowM7-0001uq-5s for ops-area@ietf.org; Mon, 05 Nov 2007 02:26:43 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IowM6-0006BG-NY for ops-area@ietf.org; Mon, 05 Nov 2007 02:26:42 -0500 X-IronPort-AV: E=Sophos;i="4.21,370,1188792000"; d="scan'208";a="76080187" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 05 Nov 2007 02:24:44 -0500 X-IronPort-AV: E=Sophos;i="4.21,370,1188792000"; d="scan'208";a="122029074" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 05 Nov 2007 02:24:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Nov 2007 08:24:43 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The IETF t-mpls design team Thread-Index: AcgfHowelFF2XCfdS3qWibi6DJCiSQAXh/BA From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Dinesh Mohan Subject: [OPS-AREA] FW: The IETF t-mpls design team 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 FYI.=20 Dinesh Mohan will represent and coordinate the work in this design team with the OPS community.=20 Dan =20 -----Original Message----- From: Loa Andersson [mailto:loa@pi.se]=20 Sent: Sunday, November 04, 2007 10:08 PM To: Iesg (E-mail); mpls@ietf.org; pwe3; ccamp Cc: Thomas D. Nadeau; IAB; Thomas Walsh; Ross Callon; Dinesh Mohan; Loa Andersson; Matthew Bocci (IETF); Deborah Brungard; Stewart Bryant Subject: The IETF t-mpls design team The IAB has decided to appoint the following design team: - Loa Andersson - Matthew Bocci - Deborah Brungard - Stewart Bryant - Ross Callon - Dinesh Mohan - Tom Nadeau - Tom Walsh to address issues in preparation of the potential cooperation between IETF and ITU-T on protocols for t-mpls. The design team will further discuss its charter and coordinate it with IAB as necessary; a tentative design team is: o Identifying an action list for the IETF o Identifying incompatibles and inconsistencies between IETF and ITU-T documents o IETF decisions to be revisited o organization to take care of ITU-T mpls/pwe3 requirements On behalf of the IAB /Loa -- 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 This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Nov 08 04:48: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 1Iq3zV-0003xi-V8; Thu, 08 Nov 2007 04:48:01 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Iq3zU-0003xH-Np for ops-area-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:48:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3zP-0003or-Np; Thu, 08 Nov 2007 04:47:55 -0500 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 1Iq3zL-0007S0-9M; Thu, 08 Nov 2007 04:47:55 -0500 X-IronPort-AV: E=Sophos;i="4.21,388,1188792000"; d="scan'208";a="76890104" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 08 Nov 2007 04:47:51 -0500 X-IronPort-AV: E=Sophos;i="4.21,388,1188792000"; d="scan'208";a="123061300" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 08 Nov 2007 04:47:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2007 10:47:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Candidates - NETCONF WG chairs Thread-Index: Acgh7GeEK+PXzx1HSYCbZXmfNI4T5A== From: "Romascanu, Dan (Dan)" To: "Netconf WG" X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ngo@ietf.org, yang@ietf.org, ops-area@ietf.org Subject: [OPS-AREA] Call for Candidates - NETCONF WG chairs 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 A new charter for the NETCONF Working Group is right now in review. We expect it to be approved before the Vancouver meeting.=20 As you may know Andy Bierman and Simon Linen who chaired the working group from its start express the desire to step down from their positions of co-chairs by the time the Working Group engages in the new phase of NETCONF.=20 The ADs have decided to write down a brief profile for the WG chair(s) and issue an open call for candidates.=20 We would like you to consider this profile and either nominate yourself or other people that you think that would fit well in this role by sending mail to the OPS ADs. (dromasca@avaya.com and rbonica@juniper.net) We do not intend to disclose the names of the nominees in public, but we will probably solicit for feedback with various other people. If you have a problem with your name being mentioned in this context, pls let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent, so don't hesitate to nominate somebody who in your opinion would fit this role quite well but doesn't fit this profile 100%. And the intend is to select two co-chairs that can complement each other and work together. As for the profile: =20 - Good management and process skills, including but not limited to choosing and supervising editors, commitment and follow-through on the charter, active management of the working group discussions, and handling IETF process steps in prompt fashion. - Good basic knowledge of the NETCONF protocols - Understanding of the requirements/needs/applications of management protocols. - Operational background/experience is very desirable. - Enough available time. For example, preferable not more than one other working chair role in IETF. - There is no requirement that the candidate has been an IETF working group chair before, but it helps if there is some evidence that the candidate can fulfill such a role (e.g.. other management role in other places than IETF etc.) We would like to receive your comments & nominations by November 16, 2007 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your nomination mail how you or the nominated candidate fits this profile as best as possible. =20 And last but not least, we would like to thank Andy and Simon for leading and guiding the work to develop NETCONF. Their contribution was tremendous and we hope that they will continue to contribute to the NETCONF WG and other related activities in the area.=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 Nov 09 03:16:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqP27-0002al-2P; Fri, 09 Nov 2007 03:16:07 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IqP24-0002YH-VO for ops-area-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 03:16:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqP1u-0002RZ-96; Fri, 09 Nov 2007 03:15:54 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqP1t-0000o7-Fn; Fri, 09 Nov 2007 03:15:54 -0500 X-IronPort-AV: E=Sophos;i="4.21,394,1188792000"; d="scan'208";a="82069901" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 09 Nov 2007 03:15:52 -0500 X-IronPort-AV: E=Sophos;i="4.21,394,1188792000"; d="scan'208";a="129298951" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 09 Nov 2007 03:15:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Nov 2007 09:14:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for November 15, 2007 Telechat Thread-Index: AcgidQE3nBUgA58iToyGdeXNvUArqAAMp0zw From: "Romascanu, Dan (Dan)" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: Subject: [OPS-AREA] FW: PRELIMINARY Agenda and Package for November 15, 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 11/15 IESG telechat. = Please let me know if there are any concerns or questions related to the = documents that are being brought for IESG approval until 11/14 COB the = latest.=20 Dan 2.1 WG Submissions 2.1.1 New Item o draft-ietf-xcon-framework-09.txt A Framework for Centralized Conferencing (Proposed Standard) - 1 of = 6 Note: Adam Roach is proto shepherd=20 Token: Cullen Jennings o draft-ietf-simple-prescaps-ext-08.txt Session Initiation Protocol (SIP) User Agent Capability Extension to = Presence Information Data Format (PIDF) (Proposed Standard) - 2 of 6 = Token: Jon Peterson o draft-ietf-behave-nat-icmp-06.txt NAT Behavioral Requirements for ICMP protocol (BCP) - 3 of 6=20 Token: Magnus Westerlund o draft-ietf-tsvwg-ecn-mpls-02.txt Explicit Congestion Marking in MPLS (Proposed Standard) - 4 of 6=20 Note: Lars Eggert (lars.eggert@nokia.com) is document shepherd.=20 Token: Lars Eggert o draft-ietf-sigtran-rfc4233update-02.txt TEI Query Request Number Change (Proposed Standard) - 5 of 6=20 Token: Jon Peterson o draft-ietf-mipshop-handover-key-03.txt Distributing a Symmetric FMIPv6 Handover Key using SEND (Proposed Standard)=20 - 6 of 6=20 Note: Document Shepherd is Vijay Devarapalli=20 Token: Jari Arkko 2.1.2 Returning Item NONE 2.2 Individual Submissions 2.2.1 New Item o draft-garcia-simple-presence-dictionary-06.txt The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)=20 (Proposed Standard) - 1 of 1=20 Token: Jon Peterson 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-nfsv4-nfs-rdma-problem-statement-07.txt NFS RDMA Problem Statement (Informational) - 1 of 5=20 Note: Document Shepherd: Spencer Shepler (spencer.shepler@sun.com)=20 Token: Lars Eggert o draft-ietf-sipping-ipv6-torture-tests-04.txt Session Initiation Protocol (SIP) Torture Test Messages for Internet = Protocol Version 6 (IPv6) (Informational) - 2 of 5=20 Token: Jon Peterson o draft-ietf-eap-netsel-problem-08.txt Network Discovery and Selection Problem (Informational) - 3 of 5=20 Token: Mark Townsley o draft-ietf-behave-p2p-state-05.txt State of Peer-to-Peer(P2P) Communication Across Network Address=20 Translators(NATs) (Informational) - 4 of 5=20 Token: Magnus Westerlund o draft-ietf-smime-cades-06.txt CMS Advanced Electronic Signatures (CAdES) (Informational) - 5 of 5=20 Token: Tim Polk 3.1.2 Returning Item NONE 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 NONE 3.2.2 Returning Item o draft-mealling-epc-urn-02.txt A Uniform Resource Name Namespace For The EPCglobal Electronic = Product Code=20 (EPC) and Related Standards (Informational) - 1 of 2=20 Token: Lisa Dusseault o draft-lepinski-dh-groups-03.txt Additional Diffie-Hellman Groups for use with IETF Standards=20 (Informational) - 2 of 2=20 Token: Tim Polk 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. The document shepherd must propose one of these responses in the the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item NONE 3.3.2 Returning Item o draft-irtf-tmrg-metrics-11.txt Metrics for the Evaluation of Congestion Control Mechanisms (Informational)=20 - 1 of 1=20 Note: To be published according to draft-irtf-rfcs-01.txt Based on = the =20 Working Group Summary, I believe that the. second variant suggested = in =20 Appendix A of draft-irtf-rfcs-0. is appropriate for this document: "This=20 document in not an IETF Internet Standard.=A0 It represents. the=20 individual opinion(s) of one or more members of the TMRG. Research Group of=20 the Internet Research Task Force. It may be. considered for standardization=20 by the IETF or adoption as a. IRTF Research Group consensus document in the=20 future."=20 Token: Lars Eggert 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under evaluation for IETF Review NONE 4.2.2 Proposed for Approval o IP Flow Information Export (ipfix) - 1 of 2 Token: Dan Romascanu o Network Configuration (netconf) - 2 of 2 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 Mon Nov 12 11:21: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 1Irc29-0000vK-Vc; Mon, 12 Nov 2007 11:21:09 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Irc27-0000pn-Km for ops-area-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 11:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irc27-0000o6-AS for ops-area@ietf.org; Mon, 12 Nov 2007 11:21:07 -0500 Received: from qmta10.emeryville.ca.mail.comcast.net ([76.96.30.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irc22-0002Wl-Uh for ops-area@ietf.org; Mon, 12 Nov 2007 11:21:07 -0500 Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA10.emeryville.ca.mail.comcast.net with smtp id BoDo1Y00616AWCU010Ln00; Mon, 12 Nov 2007 16:21:04 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id BsLy1Y0074UVsHU0000000; Mon, 12 Nov 2007 16:21:04 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=DWlViMFdWLJ0LvPDWiUA:9 a=0IwJJdh4nvPuA2xkkw0A:7 a=IRtq0SrMNFxHNz_1oMsTPTFLOwAA:4 a=lZB815dzVvQA:10 a=uWS-M9W3EfsA:10 From: "David Harrington" To: "'Adrian Farrel'" , References: <003101c7fbd4$5df62740$0200a8c0@your029b8cecfe> Date: Mon, 12 Nov 2007 11:20:32 -0500 Message-ID: <087d01c82547$f446de50$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <003101c7fbd4$5df62740$0200a8c0@your029b8cecfe> Thread-Index: Acf71NbgSAp2rMK3RYGEGrjsrbhSMwpagGTg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: ops-area@ietf.org Subject: [OPS-AREA] draft-ietf-opsawg-operations-and-management-00.txt 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 inline. > The last sentence of the abstract is a bit convoluted. Suggest: > OLD > The purpose of this document is to provide guidance to authors of > protocol documents about aspects to consider related to the > operations and management that should be considered for > inclusion in > documents defining requirements or functionality of new > protocols or > protocol extensions. > NEW > The purpose of this document is to provide guidance to authors of > documents that define requirements or functionality of new > protocols > or that define protocol extensions. The guidance is about aspects > related to operations and management that should be considered for > inclusion. Thank you for the NEW text. I think it can be made even more concise. How about this? "The purpose of this document is to provide guidance to authors of documents defining new protocols or protocol extensions. The guidance covers aspects of operations and management that should be considered." > === > Introduction. First paragraph. > First sentence rightly refers to new protocols or protocol extensions. > Last sentence refers only to new protocols. fixed. > === > [DISCUSS - This document seems to be just as concerned with the > protocol designer's "mind-set" and the protocol development process > as it is with the protocol as a finished product. While > we all agree > that it would be a good thing to imprint operational sensitivities > into the consciousness of the protocol developer, I do not > think that > this is a practical goal. The best that we can do is to > set forth a > list of objective criteria by which a protocol designer > can evaluate > whether the protocol that he/she has developed is manageable.] > I think this point is worth crystalising in the text. But we > shoud also > give some guidance about things to include/exclude in order to achieve > the goal of being manageable. I have this listed as a DISCUSS. The WG needs to discuss this and reach consensus on what this document should focus on. Different people have different ideas of what this document is for. > === > [DISCUSS: - the document may attempt to cover too much > ground. Maybe > it will develop into a framework document, supported by > documents of > the following sort: . what makes a MIB usable? . how much protocol > state information needs to be exposed and how? . how much > performance > information needs to be exposed and how?] > Certainly too much detail will render the document unreadable > by all but > the management geeks (who we assume are already the converted in this > matter. Better to be short and pithy with pointers to more information > on specific topics in different places. > In fact, a good piece of the docment seems to be about the philosophy > underlying the giving of guidance. maybe that should be separated from > the guidance itself and the philosophy underlying the guidance. > My feeling is that, at 37 pages, it is already unlikely to be read by > many people. That may be unfortunate, but it fact. I think you have to > get your base document down to around 15 pages. Suggestions for specific text that can be eliminated are welcome. I think most of the discussion about the philosophy of giving guidance are in DISCUSS sections, where the comments I have received reflect different opinions about what this document should focus on, and I do not see a consensus on the point. The WG needs to make a decision, and then all these DISCUSSes will go away. Some of the philosophy text is here because people are concerned about having another required "considerations" section, or having more requirements that might slow the standards approval process. When this document was started, I was told by one OPS AD to make it very clear this imposed no requirements on document authors or protocol designers. The other OPS AD now seems to want this document to be more of a checklist of requirements that must be met for document approval. My personal take on this is that this document can provide guidelines, but the (ever-changing membership of the) IESG can make a decision about how the guidelines should be used over time. > === > Experiments > to require such sections have had a mixed reaction from protocol > developers. > Not for inclusion in the I-D, but have you any details of negative > reactions to such experiments? No. I believe this is cut and paste from somebody's email comments. I do not have specific details of the "experiments" done in the routing area or various WGs. My impression from presentations in Montreal is there was a mixed reaction. > === > Section 4 (maybe 4.1?) > It might be interesting to consider extensibility. For example, a MIB > module structure that is open to future protocol extensions or to > proprietary extensions provide greater manageability. I think that belongs in a "guidance for MIB designers" document, not this document. The book "SNMP MIBs" provides hundreds of pages of MIB design guidance. > === > Section 4.3.1 > [DISCUSS:: 'control plane' and 'data plane' are such slippery terms > that I think they need to be defined.] > Probably, this being mainly an IP-centric world, you could use: > - control protocol fault > - data forwarding fault following Bert's suggestion, I eliminated the DISCUSS. > === > Sections 4.6, 6.5, and 9 > I find the subtly of difference between 4.6 and 6.5 hard. Could the > sections reference each other for some clarification? section 4 is "guidelines for making a protocol manageable"; Section 4.6 is about monitoring performance. Did you mean 4.7, which is about security management? Section 6 discusses specific standard data models; Section 6.5 is about specific data models designed for monitoring security protocols. We have aproblen in the IETF. Security WGs apparently think their protocols do not need to be manageable, so we have a dearth of data models for managing security protocols. I don't see a subtly of difference between section 4 and section 6. I can see the possible confusion about the difference between 4.67 and 6.5. Text would be welcome. If you think some sentences from 6.5 belong in 4.7, or vice-vera, suggestions welcome. Concrete suggestions are more useful to me than abstract observations. > I think section 9 should at least reference 4.6 and 6.5. > But we also need to consider security vulnerabilities introduced by > management techniques. For example, if you cannot configure a > router, it > is hard to make it do bad things. For example, OAM techniques can be > used to swamp the forwarding plane achieving a DoS attack. It is true that if you cannot configure a router it is hard to make it do bad things. But it is also hard to make it do good things. What do you consider the best current practice guideline on this point? Text welcome. It is also true that if you cannot provide power to a router it is hard to make the router do bad things. Should we recommend that router vendors not include power cords or power supplies with their products? You have a good point that adding management (or any protocol) creates new opportunities for security vulnerabilities. I don't know what you want me to say. What specific text would you like to see inserted into which section to address this issue? > === > > Hope this is useful. > > Cheers, > Adrian > > > > > _______________________________________________ > 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 Mon Nov 12 11:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irc7d-0006qN-0V; Mon, 12 Nov 2007 11:26:49 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Irc7c-0006ok-6W for ops-area-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 11:26:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irc7b-0006ob-R1 for ops-area@ietf.org; Mon, 12 Nov 2007 11:26:47 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irc7b-00079d-G1 for ops-area@ietf.org; Mon, 12 Nov 2007 11:26:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,406,1188792000"; d="scan'208";a="77860274" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 12 Nov 2007 11:26:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,406,1188792000"; d="scan'208";a="124237246" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Nov 2007 11:26:46 -0500 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] draft-ietf-opsawg-operations-and-management-00.txt Date: Mon, 12 Nov 2007 17:25:55 +0100 Message-ID: In-Reply-To: <087d01c82547$f446de50$6502a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] draft-ietf-opsawg-operations-and-management-00.txt Thread-Index: Acf71NbgSAp2rMK3RYGEGrjsrbhSMwpagGTgAAJmmbA= References: <003101c7fbd4$5df62740$0200a8c0@your029b8cecfe> <087d01c82547$f446de50$6502a8c0@china.huawei.com> From: "Romascanu, Dan (Dan)" To: "David Harrington" , "Adrian Farrel" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, November 12, 2007 6:21 PM > To: 'Adrian Farrel'; dharrington@huawei.com > Cc: ops-area@ietf.org > Subject: [OPS-AREA]=20 > draft-ietf-opsawg-operations-and-management-00.txt=20 >=20 > inline.=20 >=20 > > The last sentence of the abstract is a bit convoluted. Suggest: > > OLD > > The purpose of this document is to provide guidance to authors of > > protocol documents about aspects to consider related to the > > operations and management that should be considered for=20 > inclusion=20 > > in > > documents defining requirements or functionality of new=20 > protocols=20 > > or > > protocol extensions. > > NEW > > The purpose of this document is to provide guidance to authors of > > documents that define requirements or functionality of new=20 > > protocols > > or that define protocol extensions. The guidance is about aspects > > related to operations and management that should be considered > for > > inclusion. >=20 I would add to the first phrase '... and to reviewers of such documents.' Dan =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Nov 12 11:44:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcP1-0001gk-6w; Mon, 12 Nov 2007 11:44:47 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IrcP0-0001gY-EW for ops-area-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 11:44:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcP0-0001gQ-39 for ops-area@ietf.org; Mon, 12 Nov 2007 11:44:46 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrcOz-0007nL-6R for ops-area@ietf.org; Mon, 12 Nov 2007 11:44:46 -0500 Received: from [88.96.235.142] (helo=aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IrcOx-0008C9-OF; Mon, 12 Nov 2007 16:44:43 +0000 Received: from your029b8cecfe ([81.140.15.32]) by aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 16:39:36 +0000 Message-ID: <025f01c8254b$506b18b0$0200a8c0@your029b8cecfe> From: "Adrian Farrel" To: "David Harrington" , References: <003101c7fbd4$5df62740$0200a8c0@your029b8cecfe> <087d01c82547$f446de50$6502a8c0@china.huawei.com> Date: Mon, 12 Nov 2007 16:43:57 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 12 Nov 2007 16:39:37.0133 (UTC) FILETIME=[9CF775D0:01C8254A] X-Originating-Heisenberg-IP: [88.96.235.142] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: ops-area@ietf.org Subject: [OPS-AREA] Re: draft-ietf-opsawg-operations-and-management-00.txt X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Farrel 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, >> The last sentence of the abstract is a bit convoluted. Suggest [SNIP] > > Thank you for the NEW text. > I think it can be made even more concise. How about this? > "The purpose of this document is to provide guidance to authors of > documents defining new protocols or protocol extensions. The guidance > covers aspects of operations and management that should be > considered." WFM >> [DISCUSS - This document seems to be just as concerned with the >> protocol designer's "mind-set" and the protocol development >> process as it is with the protocol as a finished product. While >> we all agree that it would be a good thing to imprint operational >> sensitivities into the consciousness of the protocol developer, I >> do not think that this is a practical goal. The best that we can >> do is to set forth a list of objective criteria by which a protocol >> designer can evaluate whether the protocol that he/she has >> developed is manageable.] >> >> I think this point is worth crystalising in the text. But we >> shoud also give some guidance about things to include/exclude >> in order to achieve the goal of being manageable. > > I have this listed as a DISCUSS. The WG needs to discuss this and > reach consensus on what this document should focus on. Different > people have different ideas of what this document is for. Agreed. That was jst me contributing to the discussion. >> [DISCUSS: - the document may attempt to cover too much >> ground. Maybe it will develop into a framework document, >> supported by documents of the following sort: >> . what makes a MIB usable? >> . how much protocol state information needs to be exposed and how? >> . how much performance information needs to be exposed and how?] >> >> Certainly too much detail will render the document unreadable >> by all but the management geeks (who we assume are already >> the converted in this matter. Better to be short and pithy with >> pointers to more information on specific topics in different places. >> In fact, a good piece of the docment seems to be about the >> philosophy underlying the giving of guidance. maybe that >> should be separated from the guidance itself and the >> philosophy underlying the guidance. >> My feeling is that, at 37 pages, it is already unlikely to be read >> by many people. That may be unfortunate, but it fact. I think >> you have to get your base document down to around 15 pages. > > Suggestions for specific text that can be eliminated are welcome. OK. I'll take a look. > I think most of the discussion about the philosophy of giving guidance > are in DISCUSS sections, where the comments I have received reflect > different opinions about what this document should focus on, and I do > not see a consensus on the point. The WG needs to make a decision, and > then all these DISCUSSes will go away. That helps. > Some of the philosophy text is here because people are concerned about > having another required "considerations" section, or having more > requirements that might slow the standards approval process. When this > document was started, I was told by one OPS AD to make it very clear > this imposed no requirements on document authors or protocol > designers. The other OPS AD now seems to want this document to be more > of a checklist of requirements that must be met for document approval. > My personal take on this is that this document can provide guidelines, > but the (ever-changing membership of the) IESG can make a decision > about how the guidelines should be used over time. Hmmm. I wonder if we can replace the "philospohy text" with just that short statement? >> Section 4 (maybe 4.1?) >> It might be interesting to consider extensibility. For example, a >> MIB module structure that is open to future protocol extensions >> or to proprietary extensions provide greater manageability. > > I think that belongs in a "guidance for MIB designers" document, not > this document. The book "SNMP MIBs" provides hundreds of pages of MIB > design guidance. Right. Perhaps I should not have given an example. What I meant was that a manageability consideration is "extensibility." The general question to be answered by I-D authors is "How open to future protocol extensions are the management techniques you are defining?" >> Sections 4.6, 6.5, and 9 >> I find the subtly of difference between 4.6 and 6.5 hard. Could the >> sections reference each other for some clarification? > > section 4 is "guidelines for making a protocol manageable"; Section > 4.6 is about monitoring performance. Did you mean 4.7, which is about > security management? Section 6 discusses specific standard data > models; Section 6.5 is about specific data models designed for > monitoring security protocols. We have aproblen in the IETF. Security > WGs apparently think their protocols do not need to be manageable, so > we have a dearth of data models for managing security protocols. > > I don't see a subtly of difference between section 4 and section 6. I > can see the possible confusion about the difference between 4.67 and > 6.5. > > Text would be welcome. If you think some sentences from 6.5 belong in > 4.7, or vice-vera, suggestions welcome. Concrete suggestions are more > useful to me than abstract observations. Understood. Now I know what the intended drift is, I'll look at the text again. >> I think section 9 should at least reference 4.6 and 6.5. >> But we also need to consider security vulnerabilities introduced by >> management techniques. For example, if you cannot configure a >> router, it is hard to make it do bad things. For example, OAM >> techniques can be used to swamp the forwarding plane achieving >> a DoS attack. > > It is true that if you cannot configure a router it is hard to make it > do bad things. But it is also hard to make it do good things. What do > you consider the best current practice guideline on this point? Text > welcome. > > It is also true that if you cannot provide power to a router it is > hard to make the router do bad things. Should we recommend that router > vendors not include power cords or power supplies with their products? > > You have a good point that adding management (or any protocol) creates > new opportunities for security vulnerabilities. I don't know what you > want me to say. What specific text would you like to see inserted into > which section to address this issue? Will try to make some concrete. A _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Mon Nov 26 08:04:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwdd3-0000kk-Ut; Mon, 26 Nov 2007 08:04:01 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Iwdd2-0000k5-UT for ops-area-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 08:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwdcw-0000jP-GG; Mon, 26 Nov 2007 08:03:54 -0500 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 1Iwdcq-0005Ct-Qr; Mon, 26 Nov 2007 08:03:54 -0500 X-IronPort-AV: E=Sophos;i="4.21,467,1188792000"; d="scan'208";a="81341171" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 26 Nov 2007 08:03:46 -0500 X-IronPort-AV: E=Sophos;i="4.21,467,1188792000"; d="scan'208";a="134045781" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Nov 2007 08:03:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2007 14:03:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for November 29, 2007 Telechat Thread-Index: AcgtiK/HlQFahEqWQmazuRv1Cy7UAgCowbWQ From: "Romascanu, Dan (Dan)" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Subject: [OPS-AREA] FW: PRELIMINARY Agenda and Package for November 29, 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 Sorry for the delay, but I was out of the network for the weekend.=20 Please find below the preliminary agenda of the 11/29 IESG telechat. = Please let me know about any issues and comments until 11/28 COB the = latest.=20 Thanks and Regards, Dan =20 =20 -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org]=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-behave-rfc3489bis-13.txt Session Traversal Utilities for (NAT) (STUN) (Proposed Standard) - 1 of 9=20 Token: Magnus Westerlund o draft-ietf-geopriv-revised-civic-lo-06.txt Revised Civic Location Format for PIDF-LO (Proposed Standard) - 2 of = 9 =20 Note: Robert is proto shepherd=20 Token: Cullen Jennings o draft-ietf-rmt-bb-fec-ldpc-07.txt Low Density Parity Check (LDPC) Staircase and Triangle Forward Error = Correction (FEC) Schemes (Proposed Standard) - 3 of 9=20 Token: Magnus Westerlund o draft-ietf-rmt-bb-fec-rs-05.txt Reed-Solomon Forward Error Correction (FEC) Schemes (Proposed Standard) - 4=20 of 9=20 Token: Magnus Westerlund o draft-ietf-smime-bfibecms-08.txt Using the Boneh-Franklin and Boneh-Boyen identity-based encryption=20 algorithms with the Cryptographic Message Syntax (CMS) (Proposed Standard)=20 - 5 of 9=20 Token: Tim Polk o draft-ietf-smime-ibearch-06.txt Identity-based Encryption Architecture (Proposed Standard) - 6 of 9=20 Token: Tim Polk o draft-ietf-avt-rfc3119bis-05.txt A More Loss-Tolerant RTP Payload Format for MP3 Audio (Proposed Standard) -=20 7 of 9=20 Note: Colin Perkins is the document shepherd.=20 Token: Cullen Jennings o draft-ietf-avt-rfc2833biscas-05.txt Definition of Events For Channel-Oriented Telephony Signalling (Proposed=20 Standard) - 8 of 9=20 Note: Proto shepherd is Roni Even=20 Token: Cullen Jennings o draft-ietf-mip4-vpn-problem-solution-03.txt Mobile IPv4 Traversal Across IPsec-based VPN Gateways (BCP) - 9 of 9 = Note: Document Shepherd is Henrik Levkowetz=20 Token: Jari Arkko 2.1.2 Returning Item o draft-ietf-mip4-mobike-connectivity-03.txt Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE (BCP) = - 1 of=20 1=20 Note: Document Shepherd is =20 Token: Jari Arkko 2.2 Individual Submissions 2.2.1 New Item o draft-klensin-unicode-escapes-07.txt ASCII Escaping of Unicode Characters (BCP) - 1 of 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-manet-jitter-03.txt Jitter considerations in Mobile Ad Hoc Networks (MANETs) (Informational) -=20 1 of 1=20 Token: Ross Callon 3.1.2 Returning Item NONE 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-korhonen-mip6-service-05.txt Service Selection for Mobile IPv6 (Informational) - 1 of 2=20 Note: No document shepherd=20 Token: Jari Arkko o draft-irtf-mobopts-l2-abstractions-04.txt Unified L2 Abstractions for L3-Driven Fast Handover (Experimental) - = 2 of 2=20 Note: This is an IRTF submission=20 Token: Jari Arkko 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. The document shepherd must propose one of these responses in the Data Tracker note and supply complete text in the IESG Note portion of the write-up. The Area Director ballot positions indicate consensus with the response proposed by the document shepherd. Other matters may be recorded in comments, and the comments will be passed on to the RFC Editor as community review of the document. 3.3.1 New Item o draft-jayasumana-reorder-density-08.txt Reorder Density and Reorder Buffer-occupancy Density - Metrics for Packet=20 Reordering Measurements (Informational) - 1 of 1=20 Note: Suggest to respond to the RFC Editor with RFC 3932, Section 3, Option=20 2: "The IESG thinks that this work is related to IETF work done in = the IPPM=20 WG, but this does not prevent publishing."=20 Token: Lars Eggert 3.3.2 Returning Item o draft-irtf-tmrg-metrics-11.txt Metrics for the Evaluation of Congestion Control Mechanisms (Informational)=20 - 1 of 1=20 Note: To be published according to draft-irtf-rfcs-01.txt Based on = the =20 Working Group Summary, I believe that the. second variant suggested = in =20 Appendix A of draft-irtf-rfcs-0. is appropriate for this document: "This=20 document in not an IETF Internet Standard.=A0 It represents. the=20 individual opinion(s) of one or more members of the TMRG. Research Group of=20 the Internet Research Task Force. It may be. considered for standardization=20 by the IETF or adoption as a. IRTF Research Group consensus document in the=20 future."=20 Token: Lars Eggert _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Tue Nov 27 13:18: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 1Ix510-0008Ow-Fh; Tue, 27 Nov 2007 13:18:34 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Ix50y-0008Mn-4m for ops-area-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 13:18:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix50x-0008MX-CO for ops-area@ietf.org; Tue, 27 Nov 2007 13:18:31 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix50x-0002zI-4a for ops-area@ietf.org; Tue, 27 Nov 2007 13:18:31 -0500 X-IronPort-AV: E=Sophos;i="4.23,220,1194238800"; d="scan'208";a="81711106" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 27 Nov 2007 13:18:28 -0500 X-IronPort-AV: E=Sophos;i="4.23,220,1194238800"; d="scan'208";a="134556922" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Nov 2007 13:18:27 -0500 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, 27 Nov 2007 19:16:59 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Open Office Hours in Vancouver Thread-Index: AcgxIbNxbLrMNx36QJe3PtCTRcLcOQ== From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [OPS-AREA] OPS Area Open Office Hours in Vancouver 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 As at each IETF meeting we shall be holding the OPS Area Open Office Hours at IETF-70 in Vancouver as follows:=20 Tuesday 12/4 between 9:00 and 11:30AM PT Thursday 12/6 Between 3:15 and 5:00AM PT The room is the breakout IESG room which is by now TBD. Announcement about what TBD means will follow.=20 All folks interested to discuss Operations and Management Area and other IETF business with the OPS ADs are invited to come and talk with us.=20 Ron and Dan =20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Nov 28 01:48:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGio-0002k3-7Y; Wed, 28 Nov 2007 01:48:34 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IxGim-0002he-Js for ops-area-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 01:48:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGil-0002hG-Py; Wed, 28 Nov 2007 01:48:31 -0500 Received: from smtp-bedford.mitre.org ([192.160.51.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxGil-0000WT-21; Wed, 28 Nov 2007 01:48:31 -0500 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 lAS6mU5e024183; Wed, 28 Nov 2007 01:48:30 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id AC115BF90; Wed, 28 Nov 2007 01:48:30 -0500 (EST) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.12.11.20060308/8.12.11) with ESMTP id lAS6mTQ2024168; Wed, 28 Nov 2007 01:48:29 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 01:48:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Nov 2007 01:48:33 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SNMP MIB to XSD mapping I-D available Thread-Index: AcgxirHW5FIU2mR9TiKWOw3/nJQ+Iw== From: "Natale, Bob" To: X-OriginalArrivalTime: 28 Nov 2007 06:48:29.0386 (UTC) FILETIME=[AF26C2A0:01C8318A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: ops-area@ietf.org Subject: [OPS-AREA] SNMP MIB to XSD mapping I-D 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: , Content-Type: multipart/mixed; boundary="===============0448208931==" Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. --===============0448208931== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8318A.AEA4FD5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8318A.AEA4FD5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 For those of you on the MIB2RMDL list who have been wondering what (if anything!) has been going on during this long period of silence on the e-mail list, and for others interested in having an IETF standard methodology for mapping SNMP MIBs to XML via XSD for generic use by XML-based management applications, I can now report some progress. =20 That progress is best represented by a new Internet Draft which is now available at http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd -00.txt, pending posting to the IETF I-D repository following the imminent Vancouver IETF meeting. =20 Dave Harrington has led this effort, starting with the XSDMI proposal at the Chicago IETF meeting. As I published on this list around that time, it makes sense for the MIB2RMDL effort to see XSDMI as the essential first half of the equation (i.e., the "MIB2->" part) of MIB2RMDL. Once the IETF publishes a standard methodology for the expression of management information described in and accessible via SNMP Management Information Bases (MIBs) as XML documents, then other groups (if desired) can undertake the second half (i.e., the "->2RMDL" part). (Note that this approach also allows for multiple resource model mappings from the standard MIB to XSD mapping.) Yan Li did much of the concrete research of multiple existing independent approaches for doing the fundamental datatypes mapping addressed in this draft. We then did a comparative analysis of those approaches, relative to the requirements stipulated in Sec. 3 of this draft, as a baseline for the specific approach this draft proposes. This draft originated from draft-romascanu-netconf-datatypes, but now bears little resemblance to that document, due to differences in scope, structure, and content. =20 Any errors or otherwise errant statements in the draft are purely my responsibility. =20 I believe that the OPS ADs plan to allocate some agenda time to discuss this work at the Vancouver IETF. I will post that scheduling info when it becomes available, and I will do a post-Vancouver recap message as soon after IETF-70 as possible. =20 In the meantime, please feel free to raise any issues or post any comments concerning the draft or the plans here and on the ops-area list (unless the ADs give other guidance about which list(s) to use). =20 Cheers, BobN ------_=_NextPart_001_01C8318A.AEA4FD5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
For=20 those of you on the MIB2RMDL list who have been wondering what (if = anything!)=20 has been going on during this long period of silence on the e-mail list, = and for=20 others interested in having an IETF standard methodology for mapping = SNMP MIBs=20 to XML via XSD for generic use by XML-based management applications, I = can now=20 report some progress.
 
That=20 progress is best represented by a new Internet Draft which is now = available=20 at http://home.comcast.net/~bobnatale/draft-li-natale-smi-dat= atypes-in-xsd-00.txt,=20 pending posting to the IETF I-D repository following the imminent = Vancouver IETF=20 meeting.
 
Dave=20 Harrington has led this effort, starting with the XSDMI proposal at the = Chicago=20 IETF meeting.  As I published on this list around that time, it = makes sense=20 for the MIB2RMDL effort to see XSDMI as the essential first half of the = equation=20 (i.e., the "MIB2->" part) of MIB2RMDL.  Once the IETF publishes = a=20 standard methodology for the expression of management information = described in=20 and accessible via SNMP Management Information Bases (MIBs) as XML = documents,=20 then other groups (if desired) can undertake the second half (i.e., the=20 "->2RMDL" part).  (Note that this approach also allows for = multiple=20 resource model mappings from the standard MIB to XSD mapping.)  Yan = Li did=20 much of the concrete research of multiple existing independent = approaches for=20 doing the fundamental datatypes mapping addressed in this = draft.  We=20 then did a comparative analysis of those approaches, relative to the=20 requirements stipulated in Sec. 3 of this draft, as a baseline for the = specific=20 approach this draft proposes.  This draft originated from=20 draft-romascanu-netconf-datatypes, but now bears little resemblance to = that=20 document, due to differences in scope, structure, and=20 content.
 
Any=20 errors or otherwise errant statements in the draft are purely my=20 responsibility.
 
I=20 believe that the OPS ADs plan to allocate some agenda time to discuss = this work=20 at the Vancouver IETF.  I will post that scheduling info when it = becomes=20 available, and I will do a post-Vancouver recap message as soon after = IETF-70 as=20 possible.
 
In=20 the meantime, please feel free to raise any issues or post any comments=20 concerning the draft or the plans here and on the ops-area list (unless = the ADs=20 give other guidance about which list(s) to use).
 
Cheers,
BobN
------_=_NextPart_001_01C8318A.AEA4FD5A-- --===============0448208931== 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 --===============0448208931==-- From ops-area-bounces@ietf.org Wed Nov 28 02:30:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxHNB-0006w8-Sc; Wed, 28 Nov 2007 02:30:17 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IxHNA-0006vk-NL for ops-area-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 02:30:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxHNA-0006vN-As; Wed, 28 Nov 2007 02:30:16 -0500 Received: from mail.unijos.edu.ng ([82.206.136.75] helo=smtp.unijos.edu.ng) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxHN7-0006mV-3F; Wed, 28 Nov 2007 02:30:14 -0500 Received: from localhost (smtp.unijos.edu.ng [127.0.0.1]) by smtp.unijos.edu.ng (Postfix) with ESMTP id AA0786813F; Wed, 28 Nov 2007 08:30:03 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng X-Spam-Score: -3.705 X-Spam-Level: X-Spam-Status: No, score=-3.705 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1.8, AWL=0.694, BAYES_00=-2.599] Received: from smtp.unijos.edu.ng ([127.0.0.1]) by localhost (smtp.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceVk4pkeN2zx; Wed, 28 Nov 2007 08:29:53 +0100 (WAT) Received: from imap.unijos.edu.ng (imap.unijos.edu.ng [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.unijos.edu.ng (Postfix) with ESMTP id 9D5A66813C; Wed, 28 Nov 2007 08:29:53 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id F347A281C9; Wed, 28 Nov 2007 08:57:11 +0100 (WAT) Received: from 192.168.192.51 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Wed, 28 Nov 2007 08:57:12 +0100 (WAT) Message-ID: <2300.192.168.192.51.1196236632.squirrel@mail.unijos.edu.ng> In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> Date: Wed, 28 Nov 2007 08:57:12 +0100 (WAT) Subject: Re: [OPS-AREA] SNMP MIB to XSD mapping I-D available From: "GOGWIM, JOEL GODWIN" To: "Natale, Bob" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mib2rdml@ietf.org, ops-area@ietf.org X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gogwim@unijos.edu.ng 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 tried getting the site given but it responded page does not exist. That is: http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd On Wed, November 28, 2007 7:48 am, Natale, Bob said: > Hi, > > For those of you on the MIB2RMDL list who have been wondering what (if > anything!) has been going on during this long period of silence on the > e-mail list, and for others interested in having an IETF standard > methodology for mapping SNMP MIBs to XML via XSD for generic use by > XML-based management applications, I can now report some progress. > > That progress is best represented by a new Internet Draft which is now > available at > http://home.comcast.net/~bobnatale/draft-li-natale-smi-datatypes-in-xsd > -00.txt, pending posting to the IETF I-D repository following the > imminent Vancouver IETF meeting. > > Dave Harrington has led this effort, starting with the XSDMI proposal > at the Chicago IETF meeting. As I published on this list around that > time, it makes sense for the MIB2RMDL effort to see XSDMI as the > essential first half of the equation (i.e., the "MIB2->" part) of > MIB2RMDL. Once the IETF publishes a standard methodology for the > expression of management information described in and accessible via > SNMP Management Information Bases (MIBs) as XML documents, then other > groups (if desired) can undertake the second half (i.e., the "->2RMDL" > part). (Note that this approach also allows for multiple resource > model mappings from the standard MIB to XSD mapping.) Yan Li did much > of the concrete research of multiple existing independent approaches > for doing the fundamental datatypes mapping addressed in this draft. > We then did a comparative analysis of those approaches, relative to the > requirements stipulated in Sec. 3 of this draft, as a baseline for the > specific approach this draft proposes. This draft originated from > draft-romascanu-netconf-datatypes, but now bears little resemblance to > that document, due to differences in scope, structure, and content. > > Any errors or otherwise errant statements in the draft are purely my > responsibility. > > I believe that the OPS ADs plan to allocate some agenda time to discuss > this work at the Vancouver IETF. I will post that scheduling info when > it becomes available, and I will do a post-Vancouver recap message as > soon after IETF-70 as possible. > > In the meantime, please feel free to raise any issues or post any > comments concerning the draft or the plans here and on the ops-area > list (unless the ADs give other guidance about which list(s) to use). > > Cheers, > BobN > _______________________________________________ > 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 Nov 28 03:27:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIGp-0000kx-Up; Wed, 28 Nov 2007 03:27:47 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IxIGo-0000gR-Lj for ops-area-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 03:27:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxIGg-0000I2-Nj; Wed, 28 Nov 2007 03:27:38 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxIGe-0006Nq-Qt; Wed, 28 Nov 2007 03:27:38 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C925784AE5; Wed, 28 Nov 2007 09:27:35 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29714-03; Wed, 28 Nov 2007 09:27:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C47408A105; Wed, 28 Nov 2007 09:27:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6DBE43F7BB9; Wed, 28 Nov 2007 09:27:30 +0100 (CET) Date: Wed, 28 Nov 2007 09:27:30 +0100 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20071128082730.GA28685@elstar.local> References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mib2rdml@ietf.org, ops-area@ietf.org Subject: [OPS-AREA] Re: [MIB2RDML] SNMP MIB to XSD mapping I-D available X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.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, Nov 28, 2007 at 01:48:33AM -0500, Natale, Bob wrote: > In the meantime, please feel free to raise any issues or post any > comments concerning the draft or the plans here and on the ops-area > list (unless the ADs give other guidance about which list(s) to use). It might be helpful to clarify what is meant with the following stated requirements: R3. The XSD datatype specified for a given SMI datatype MUST include and restrictions on values associated with the SMI datatype. R4. The XSD datatype specified for a given SMI datatype MUST be the most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements. You seem to want SMI <=> XSD equivalence (I assume this because you carry the 128 subidentifier OID restriction forward) while in other places people are fine with just SMI => XSD mapping. Note that it is a very fundamental design decision to require equivalence and will be of much more importance once you move to TCs and you look at the stuff that is more challenging. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Wed Nov 28 08:17: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 1IxMnB-0008Kf-7Q; Wed, 28 Nov 2007 08:17:29 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IxMnA-0008KR-DH for ops-area-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:17:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMn9-0008KA-Bm; Wed, 28 Nov 2007 08:17:27 -0500 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 1IxMn8-0007tG-HB; Wed, 28 Nov 2007 08:17:26 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208,217";a="81908729" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 28 Nov 2007 08:17:25 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194238800"; d="scan'208,217";a="134816825" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Nov 2007 08:17:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [OPS-AREA] SNMP MIB to XSD mapping I-D available Date: Wed, 28 Nov 2007 14:16:14 +0100 Message-ID: In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] SNMP MIB to XSD mapping I-D available Thread-Index: AcgxirHW5FIU2mR9TiKWOw3/nJQ+IwANhBwQ References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> From: "Romascanu, Dan (Dan)" To: "Natale, Bob" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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="===============1841091551==" Errors-To: ops-area-bounces@ietf.org This is a multi-part message in MIME format. --===============1841091551== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C831C0.DA86E689" This is a multi-part message in MIME format. ------_=_NextPart_001_01C831C0.DA86E689 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 ________________________________ From: Natale, Bob [mailto:RNATALE@mitre.org]=20 =09 =20 =20 I believe that the OPS ADs plan to allocate some agenda time to discuss this work at the Vancouver IETF. I will post that scheduling info when it becomes available, and I will do a post-Vancouver recap message as soon after IETF-70 as possible. =20 =09 [DR] It's on the agenda of the OPS Area Open Meeting available at http://www3.ietf.org/proceedings/07dec/agenda/opsarea.txt.=20 =20 Dan =20 ------_=_NextPart_001_01C831C0.DA86E689 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 

From: Natale, Bob = [mailto:RNATALE@mitre.org]=20
 
 
I=20 believe that the OPS ADs plan to allocate some agenda time to discuss = this=20 work at the Vancouver IETF.  I will post that scheduling info = when it=20 becomes available, and I will do a post-Vancouver recap message as = soon after=20 IETF-70 as possible.
 

[DR] It's on the agenda of the OPS Area = Open Meeting=20 available at http:/= /www3.ietf.org/proceedings/07dec/agenda/opsarea.txt. 
 
Dan
 
= ------_=_NextPart_001_01C831C0.DA86E689-- --===============1841091551== 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 --===============1841091551==-- From ops-area-bounces@ietf.org Thu Nov 29 01:25:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxcqK-0006xt-3L; Thu, 29 Nov 2007 01:25:48 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IxcqH-0006ml-V3 for ops-area-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 01:25:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxcqH-0006lC-3V; Thu, 29 Nov 2007 01:25:45 -0500 Received: from smtpproxy1.mitre.org ([192.160.51.76] helo=smtp-bedford.mitre.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxcqG-0004Bm-Hn; Thu, 29 Nov 2007 01:25:44 -0500 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 lAT6PimJ000593; Thu, 29 Nov 2007 01:25:44 -0500 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id D575EBF8F; Thu, 29 Nov 2007 01:25:43 -0500 (EST) 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 lAT6PhsQ000582; Thu, 29 Nov 2007 01:25:43 -0500 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 01:25:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Nov 2007 01:25:43 -0500 Message-ID: <4915F014FDD99049A9C3A8C1B832004F02520673@IMCSRV2.MITRE.ORG> In-Reply-To: <20071128082730.GA28685@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB2RDML] SNMP MIB to XSD mapping I-D available Thread-Index: AcgxmIjASuDDdv6OTE6BeTxUYFIAeAAtdySg References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> <20071128082730.GA28685@elstar.local> From: "Natale, Bob" To: X-OriginalArrivalTime: 29 Nov 2007 06:25:43.0264 (UTC) FILETIME=[AB4AD600:01C83250] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mib2rdml@ietf.org, ops-area@ietf.org Subject: [OPS-AREA] RE: [MIB2RDML] SNMP MIB to XSD mapping I-D 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 Juergen, Thanks for the feedback. Concerning the clarifications you requested:=20 "R3. The XSD datatype specified for a given SMI datatype MUST include and restrictions on values associated with the SMI datatype." ^^^ Stupid typo on my part...should be: "...MUST include any restrictions on=20 values associated with the SMI datatype." ^^^ This simply means that any restrictions on a datatype specified in the SMI (such as the maximum length of 65535 octets for an OCTET STRING) must be reflected in the XSD datatype definition. "R4. The XSD datatype specified for a given SMI datatype MUST be the most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements." This is just the corollary of R3: The XSD datatype definition must not add any unnecessary "decoration" relative to the SMI datatype definition. You are correct in noting that this specification aims for "fidelity" of the XSD to the SMI for the core datatypes defined in RFC 2578 (and RFC 1155) -- or, put another way, "equivalence where possible; variance only where necessary". I do understand the implications and appreciate your cautions about impact on TC mappings -- there the guidance might become, "equivalence where possible; variance where helpful". The goal of "fidelity" is important in this effort because it targets *reuse* by generic XML-based management applications of existing (including future) MIBs both as precise data models and as instrumentation artifacts via gateways to SNMP agents. Cheers, BobN -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Wednesday, November 28, 2007 3:28 AM To: Natale, Bob Cc: mib2rdml@ietf.org; ops-area@ietf.org Subject: Re: [MIB2RDML] SNMP MIB to XSD mapping I-D available On Wed, Nov 28, 2007 at 01:48:33AM -0500, Natale, Bob wrote: =20 > In the meantime, please feel free to raise any issues or post any > comments concerning the draft or the plans here and on the ops-area > list (unless the ADs give other guidance about which list(s) to use). It might be helpful to clarify what is meant with the following stated requirements: R3. The XSD datatype specified for a given SMI datatype MUST include and restrictions on values associated with the SMI datatype. R4. The XSD datatype specified for a given SMI datatype MUST be the most direct XSD datatype, with the most parsimonious restrictions, which matches the foregoing requirements. You seem to want SMI <=3D> XSD equivalence (I assume this because you carry the 128 subidentifier OID restriction forward) while in other places people are fine with just SMI =3D> XSD mapping. Note that it is a very fundamental design decision to require equivalence and will be of much more importance once you move to TCs and you look at the stuff that is more challenging. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Thu Nov 29 05:11: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 1IxgMS-00069c-Ms; Thu, 29 Nov 2007 05:11:12 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IxgMR-00069N-Bb for ops-area-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 05:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgMQ-00069B-Uj for ops-area@ietf.org; Thu, 29 Nov 2007 05:11:10 -0500 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 1IxgMQ-0008Qp-Js for ops-area@ietf.org; Thu, 29 Nov 2007 05:11:10 -0500 X-IronPort-AV: E=Sophos;i="4.23,228,1194238800"; d="scan'208";a="82143862" Received: from 5.7.8.135.in-addr.arpa (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 29 Nov 2007 05:11:08 -0500 X-IronPort-AV: E=Sophos;i="4.23,228,1194238800"; d="scan'208";a="135169326" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Nov 2007 05:11:07 -0500 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] OPS Area Open Office Hours in Vancouver Date: Thu, 29 Nov 2007 11:11:06 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPS-AREA] OPS Area Open Office Hours in Vancouver Thread-Index: AcgxIbNxbLrMNx36QJe3PtCTRcLcOQBTi+MA References: From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 The Thursday time slot is 3:15 to 5PM (15:15 to 17:00). Thanks, Simon for being awake :-) Dan =20 =20 > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 > Sent: Tuesday, November 27, 2007 8:17 PM > To: ops-area@ietf.org > Subject: [OPS-AREA] OPS Area Open Office Hours in Vancouver >=20 > As at each IETF meeting we shall be holding the OPS Area Open=20 > Office Hours at IETF-70 in Vancouver as follows:=20 >=20 > Tuesday 12/4 between 9:00 and 11:30AM PT Thursday 12/6=20 > Between 3:15 and 5:00AM PT >=20 > The room is the breakout IESG room which is by now TBD.=20 > Announcement about what TBD means will follow.=20 >=20 > All folks interested to discuss Operations and Management=20 > Area and other IETF business with the OPS ADs are invited to=20 > come and talk with us.=20 >=20 > Ron and Dan > =20 >=20 >=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 From ops-area-bounces@ietf.org Thu Nov 29 05:45: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 1IxgtR-00052W-0u; Thu, 29 Nov 2007 05:45:17 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1IxgtQ-00052L-8T for ops-area-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 05:45:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxgtP-00052A-O0; Thu, 29 Nov 2007 05:45:15 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxgtO-0004ye-0b; Thu, 29 Nov 2007 05:45:15 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB4D88A22A; Thu, 29 Nov 2007 11:45:08 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03064-01; Thu, 29 Nov 2007 11:45:03 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D89148A1EC; Thu, 29 Nov 2007 11:44:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 710AD40219A; Thu, 29 Nov 2007 11:44:57 +0100 (CET) Date: Thu, 29 Nov 2007 11:44:57 +0100 From: Juergen Schoenwaelder To: "Natale, Bob" Message-ID: <20071129104457.GA10751@elstar.local> References: <4915F014FDD99049A9C3A8C1B832004F0252047B@IMCSRV2.MITRE.ORG> <20071128082730.GA28685@elstar.local> <4915F014FDD99049A9C3A8C1B832004F02520673@IMCSRV2.MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4915F014FDD99049A9C3A8C1B832004F02520673@IMCSRV2.MITRE.ORG> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: mib2rdml@ietf.org, ops-area@ietf.org Subject: [OPS-AREA] Re: [MIB2RDML] SNMP MIB to XSD mapping I-D available X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.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 Thu, Nov 29, 2007 at 01:25:43AM -0500, Natale, Bob wrote: > Concerning the clarifications you requested: > > "R3. The XSD datatype specified for a given SMI datatype MUST include > and restrictions on values associated with the SMI datatype." > ^^^ > > Stupid typo on my part...should be: "...MUST include any restrictions > on > values associated with the SMI datatype." ^^^ > > This simply means that any restrictions on a datatype specified in > the SMI (such as the maximum length of 65535 octets for an OCTET > STRING) must be reflected in the XSD datatype definition. OK > "R4. The XSD datatype specified for a given SMI datatype MUST be the > most direct XSD datatype, with the most parsimonious > restrictions, which matches the foregoing requirements." > > This is just the corollary of R3: The XSD datatype definition must not > add any unnecessary "decoration" relative to the SMI datatype > definition. This sounds fuzzy to me; people likely have totally different understandings of 'unnecessary "decoration"'. > You are correct in noting that this specification aims for "fidelity" > of the XSD to the SMI for the core datatypes defined in RFC 2578 (and > RFC 1155) -- or, put another way, "equivalence where possible; variance > only where necessary". Let me ask why you actually have Counter and Couter32 (and similarly Gauge and Gauge32). Since SMI versions prior to SMIv2 [RFC2578] can be translated to SMIv2 (STD58 since 1999), why does this document care about SMIv1 and things such as RFC 1155 at all? Note that libsmi does not distinguish between Counter and Couter32 or Gauge and Gauge32 and this has never been a problem as far as I can tell. > I do understand the implications and appreciate your cautions about > impact on TC mappings -- there the guidance might become, "equivalence > where possible; variance where helpful". So you are saying lossless SMI => XSD translation is required while lossless XSD => SMI translation is nice to have but not required. > The goal of "fidelity" is important in this effort because it > targets *reuse* by generic XML-based management applications of > existing (including future) MIBs both as precise data models and as > instrumentation artifacts via gateways to SNMP agents. You either require strict XSD => SMI or not. Gateways or translations that work sometimes or only for some subsets are IMHO not a solution. I just want to understand whether you guys envision to live with the SMIv2 limitations forever or whether you have a plan to overcome some of them and to gradually move forward. This is not clear to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Nov 30 03:09: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 1Iy0w1-0006gP-Uf; Fri, 30 Nov 2007 03:09:17 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Iy0w1-0006g9-7E for ops-area-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 03:09:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy0w0-0006fx-Ss for ops-area@ietf.org; Fri, 30 Nov 2007 03:09:16 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy0vz-0001aT-32 for ops-area@ietf.org; Fri, 30 Nov 2007 03:09:16 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C4688A261; Fri, 30 Nov 2007 09:09:14 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 21991-01-14; Fri, 30 Nov 2007 09:09:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6309B8A26F; Fri, 30 Nov 2007 09:08:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 29E484039F3; Fri, 30 Nov 2007 09:08:46 +0100 (CET) Date: Fri, 30 Nov 2007 09:08:46 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20071130080846.GA12952@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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ops-area@ietf.org Subject: [OPS-AREA] ops area mailing lists X-BeenThere: ops-area@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.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, Oct 24, 2007 at 05:50:11PM +0200, Romascanu, Dan (Dan) wrote: > 3. Open microphone > > We are looking forward for further proposals If you have spare time, you might want to discuss how we make best use of mailing lists. I personally believe we have too many of them, leading to discussions spread over several lists, which makes it actually harder to find all the bits and pieces. Examples: - Do we still need ngo since netconf got rechartered? - Do we still need mib2rdml since it is now also doing SMI to XSD conversion? (I count 3 message before the SMI builtin type to XSD ID was posted.) - What about meta-model which I think had exactly one message since its creation? - We have the yang list but then due to APP area involvement we were asked to use the APP area discuss list while some discussion remains on the ngo list... Perhaps the ADs can come up with a proposal how they like to deal with OPS mailing lists in the future and present it at the meeting (or post it to the mailing lists ;-). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area From ops-area-bounces@ietf.org Fri Nov 30 03:21: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 1Iy187-0007m5-Dh; Fri, 30 Nov 2007 03:21:47 -0500 Received: from ops-area by megatron.ietf.org with local (Exim 4.43) id 1Iy186-0007lo-Fz for ops-area-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 03:21:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy186-0007ld-6N for ops-area@ietf.org; Fri, 30 Nov 2007 03:21:46 -0500 Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy185-0003TQ-Oc for ops-area@ietf.org; Fri, 30 Nov 2007 03:21:46 -0500 X-IronPort-AV: E=Sophos;i="4.23,233,1194238800"; d="scan'208";a="76890692" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Nov 2007 03:21:44 -0500 X-IronPort-AV: E=Sophos;i="4.23,233,1194238800"; d="scan'208";a="135508188" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 30 Nov 2007 03:21:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Nov 2007 09:20:41 +0100 Message-ID: In-Reply-To: <20071130080846.GA12952@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ops area mailing lists Thread-Index: AcgzKFC0hg5gTgs+Q/a0mJ6ZQx7auQAAO1Qw References: <20071130080846.GA12952@elstar.local> From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ops-area@ietf.org Subject: [OPS-AREA] RE: ops area mailing lists 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 Good point.=20 My take - and other please send your opinions:=20 - ngo - with NETCONF rechartered we need to decide if we want to keep it for further beyond-the-charter discussions or shut it down - mib2rdml - Bob Natale will present a draft in the meeting, we should discuss there if this still fits in a separate effort - meta-language - unless something spectacular happens very soon I will propose to close it - yang - I suggest to continue with it, and see what happens in Vancouver and soon after Dan =20 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Friday, November 30, 2007 10:09 AM > To: Romascanu, Dan (Dan) > Cc: ops-area@ietf.org > Subject: ops area mailing lists >=20 > On Wed, Oct 24, 2007 at 05:50:11PM +0200, Romascanu, Dan (Dan) wrote: >=20 > > 3. Open microphone > >=20 > > We are looking forward for further proposals >=20 > If you have spare time, you might want to discuss how we make=20 > best use of mailing lists. I personally believe we have too=20 > many of them, leading to discussions spread over several=20 > lists, which makes it actually harder to find all the bits and pieces. >=20 > Examples: >=20 > - Do we still need ngo since netconf got rechartered? >=20 > - Do we still need mib2rdml since it is now also doing SMI to XSD > conversion? (I count 3 message before the SMI builtin type to XSD ID > was posted.) >=20 > - What about meta-model which I think had exactly one message since > its creation? >=20 > - We have the yang list but then due to APP area involvement we were > asked to use the APP area discuss list while some discussion remains > on the ngo list... >=20 > Perhaps the ADs can come up with a proposal how they like to=20 > deal with OPS mailing lists in the future and present it at=20 > the meeting (or post it to the mailing lists ;-). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 _______________________________________________ OPS-AREA mailing list OPS-AREA@ietf.org https://www1.ietf.org/mailman/listinfo/ops-area