Received: from [134.169.34.51] (arlet.ibr.cs.tu-bs.de [134.169.34.51]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0VFhB5e028325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 31 Jan 2007 16:43:11 +0100 Message-ID: <45C0B90F.1040403@ibr.cs.tu-bs.de> Date: Wed, 31 Jan 2007 16:43:11 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= Organization: IBR, TU Braunschweig User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 02 Feb 2007 10:45:43 +0100 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2007 15:43:11 -0000 Wijnen, Bert (Bert) wrote: > Juergen and NMRG members. > > Pls review and post your opinion BEFORE Feb 17th, 2007. I have read the document and came up with the following comments: - General: What about a glossary to introduce a few common terms for the entities and processing steps? I would love to see a figure that shows these entities and steps with their relationships and the levels of concrete/anonymized/meta data. This could especially help to make clear in which spheres anonymized and non-anonymized data could reside. (I still have my problems with this question.) - Section 1, 2nd paragraph It looks a bit unfair to state that the mentioned performance related publications are based on speculations about SNMP performance. I propose to rephrase the last sentence to something like: "In fact, there are many speculations how SNMP is being used in real world production networks and performance comparisons are based on limited test cases, but no systematic wide-range measurements have been performed and published so far." - Section 2.1, 1st paragraph You should probably also write a few words about the (unlikely) case of fragmented packets. - Section 2.1, concerning port monitoring In practice, such monitoring ports cannot always be configured this way. E.g., our (relatively new) Nortel switches allow a monitoring port only to monitor no more than two other ports or up to two MAC addresses on any port. I have no experience with other vendors, but I guess it is a general question of available CPU and bandwidth resources on a device's management plane. - Section 2.1, 3rd paragraph concerning h/w checksum offloading Why do you suggest to turn offloading off? In my opinion, wrong checksums in traces don't hurt. A short note, so that people don't wonder about wrong checksums should be enough. - Section 2.1, 4th paragraph concerning pcap backups/archives Hm. I don't like this paragraph. Software should be "mature enough" before you ask people to use it. At least, integrety and correctness of data at steps 4+5 should remain the responsibilty of the party who would like to collect the measurements. - Section 2.2, 1st paragraph Pcap files *are* machine readable. Porposal: "...that are human readable while remaining also machine readable for ..." - Section 2.2, 2nd paragraph s/a [OASISRNG] schema/a RELAX NG schema [OASISRNG] - Section 2.2, 4th paragraph concerning h/w checksum offloading again I suggest to make checksum error ignorance mandatory. See another comment above. Are you sure that pcap files recorded with a tool like tcpdump and with the aforementioned filter expression contain IP fragments at all? I didn't check it. - Section 2.2, last paragraph concerning XML and CSV formats So snmpdump cannot read CSV and creating CSV is one-way? Maybe, it's worth to state this explicitly. Furthermore, I would prefer to decide for one format. That would make data handling, script authoring, etc. much easier. - Section 2.3, 1st paragraph concerning Perl The Perl community names it "modules" instead of "packages", AFAIK. If you decide to change it, also grep for subsequent occurances of the word "package". - Section 2.3, 2nd paragraph concerning anonymization retaining lexi-order It would be fine to have this feature mature enough so that this is no longer work in progress when the document is ready to become an Informational RFC. Maybe it already is, since HS06 was published in April 2006? However, the goal seems to be non-trivial to me, especially when you want to be able to merge traces, right? I'm generally missing more information about anonymization. Which pieces of information can or should be anonymized? Wouldn't it be meaningful to add a flag to the schema to signal which pieces have actually been anonymized? Should a value A that has been anonymized to value B be anonymized to B again in subsequent occurances? If yes, how could this mapping be maintained for merged traces? I think there are quite some interesting questions. :-) A central question for this document is, whether these issues should be addressed here or whether they should be left to implementors or to other documents. In the latter case, it should be made clear that the schema specified in this document can be expanded somehow. - Section 2.4, 1st paragraph concerning storage of pcap and processed data Why should they be stored together? My understanding is that the person that records the trace may be interested in anonymization of the data. So pcap data MIGHT be archived by the user that applies steps 1-3 (see also above), and the XML or CSV data is stored in the repository. - Section 2.4, last paragraph concerning storage of original pcap data Due to the obvious conflict in the interests of the data supplier (anonymized data) and the repository operator (availabilty also of source data), I suggest to drop the strict need to keep the original data. - Section 3.6, 2nd paragraph s/identity/identify/ - Section 3.9 a/Assumption/Assumptions/ - Section 3.12 Please give a reference to RFC 2579. - Section 4.1, the RNG Schema I did not read the schema carefully, primarily because I'm not very familiar with Relax NG. Maybe some of the comments in Section 4.2 also apply to this schema. I tried to convert the schema to XSD using trang, but only got a trang segfault on Debian/sarge, so I'm not sure whether I did something wrong, whether there is an error in the schema, or whether just my trang is broken. Are elements by default optional? I suggest to make almost all pieces of information optional, so that data suppliers can remove those pieces of information that they have to hide for any reason. - Section 4.2, CSV value #8 (SNMP protocol operation) Maybe, it would be better to delay decoding of the SNMP operation (and probably other types of decoding) to the analysis step, so that (obscure and very unlikely) cases of non-standard operations could also be handled? If you want to have such values in a human readable form, maybe a mixture of text (if well-known an decodeable) and numeric (if unknown) values would be doable. - Section 4.2, CSV value #10 (SNMP error-status) Why do you decode protocol operations to keywords, and keep error-status as a numeric value? - Section 4.2, CSV value #13/3 (object values) Does this mean, that exception names appear twice? Wouldn't it be better to keep the third value empty in case of exceptions? - Section 5, 1st paragraph on sensitive data It is a subjective matter what pieces of information are "unneeded". I propose something like s/unneeded/unwanted/. - Section 5, 2nd paragraph s/suppress/suppress or anonymize/ ? (I did not review Sections 7+ (References and below).) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0V8lAYL012498 for ; Wed, 31 Jan 2007 09:47:16 +0100 Received: from [130.89.11.144] (ewi899.ewi.utwente.nl [130.89.11.144]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l0V8cdPx023701; Wed, 31 Jan 2007 09:38:39 +0100 (MET) Message-ID: <45C055A1.3060303@utwente.nl> Date: Wed, 31 Jan 2007 09:38:57 +0100 From: Aiko Pras User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.044 () AWL X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 31 Jan 2007 09:38:43 +0100 (MET) X-IBRFilter-SpamReport: -2.599 () BAYES_00 Cc: j.schoenwaelder@iu-bremen.de, "Wijnen, Bert \(Bert\)" X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2007 08:47:31 -0000 Wijnen, Bert (Bert) wrote: > NMRG members: > > In order to consider this as an NMRG document, it is not sufficient > to "not object". We need at least a set of NMRG members/participants > to review the document and to comment. If you are happy with the > document and support its publication as an NMRG supported > Informational RFC, then I would like to hear that, prefereably > by posting such a statement to the NMRG list. Something aka > > I have read the document, it is in good shape and I support > its publication as Informational RFC. Hi all I've read the document and I'm very happy with it. I support very much publication as Informational RFC. :-) Aiko Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0UDx8UW010466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Jan 2007 14:59:14 +0100 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0UDx2X4001761; Tue, 30 Jan 2007 07:59:02 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 07:59:02 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 14:58:59 +0100 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" Date: Tue, 30 Jan 2007 14:58:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC Thread-Index: AcdEdscSxIVBee/8SXSLY9V37ItJ6A== From: "Wijnen, Bert \(Bert\)" To: X-OriginalArrivalTime: 30 Jan 2007 13:58:59.0706 (UTC) FILETIME=[CA784DA0:01C74476] X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-IBRFilter-SpamReport: 0.001 () BAYES_50 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l0UDx8UW010466 Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] NMRG Last Call: draft-irtf-nmrg-snmp-measure-01.txt for Informational RFC X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2007 13:59:18 -0000 Juergen and NMRG members. Pls review and post your opinion BEFORE Feb 17th, 2007. Juergen wrote: > > [...] Since I am personally involved > > as the author/editor, the first thing we need is a shepherd who is > > willing to run the process, which starts with soliciting RG > reviews by > > doing a RG last call. Any volunteers? > > Our shepherd for is > Bert Wijnen and he will now take over the procedure. Thanks > to Bert for helping us with this and also many thanks to the > others who volunteered to help move this document along. > > /js I am starting my work as shepherd of this document, using the irtf-rfcs-01a draft (as Juergen had included in his posting last Friday) as the process to follow. This is based on: Juergen, According to the irtf-rfcs-01a draft, we need to make sure we have consensus that this is an RG supported document. from my quick checking of the nmrg mlist archives, it seems that you proposed to make this an NMRG document in march 2006, when you psted the abstract of your individual doument, and asked: I believe that this work is highly relevant for the NMRG and I hereby propose to turn this Internet-Draft which is still an individual submission into an NMRG sponsored Internet-Draft. Please let me know what you think about this and especially if you have concerns about doing so. For all I can tell, I am the only one who responded positive to this. I see no negative answers, but a lot of silence w.r.t. this question. So it seems you have assumed that silence means consent (and give the formulation of your question, we can indeed interpret silence as consent, or at least as no objection. NMRG members: In order to consider this as an NMRG document, it is not sufficient to "not object". We need at least a set of NMRG members/participants to review the document and to comment. If you are happy with the document and support its publication as an NMRG supported Informational RFC, then I would like to hear that, prefereably by posting such a statement to the NMRG list. Something aka I have read the document, it is in good shape and I support its publication as Informational RFC. If you have comments/sugegstions/concerns, pls let us know and post them to this NMRG mailing list. Pls send your review comments/results BEFORE 17 Feb 2007. Sooner is of course better. This allows for the authors to do a new revision (if needed) before the ID cutoff. I propose that we consider my own review comments (posted yesterday, http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001187.html) as initial RG LC comments. Bert Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0THPru4002526 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 29 Jan 2007 18:25:59 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0THPmeD029707 for ; Mon, 29 Jan 2007 12:25:51 -0500 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); Mon, 29 Jan 2007 16:07:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE5tpT011572 for ; Mon, 29 Jan 2007 09:06:09 -0500 Received: from optimus.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by nj300815-nj-outbound.avaya.com with ESMTP; 29 Jan 2007 09:07:11 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXA8-0006nV-Gn; Mon, 29 Jan 2007 09:07:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBXA6-0006mh-Rs; Mon, 29 Jan 2007 09:07:10 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBXA5-0007qw-C2; Mon, 29 Jan 2007 09:07:10 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE76eB020529; Mon, 29 Jan 2007 09:07:07 -0500 content-class: urn:content-classes:message Date: Mon, 29 Jan 2007 19:25:47 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF OPS Area Meetings and mini-BOFs: Preliminary Agenda for the Prague IETF meeting - March 2007 Thread-Index: AcdDrpqUSwS6PSnaQHKopeF9pnPMag== From: "Romascanu, Dan \(Dan\)" To: X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l0THPru4002526 Subject: [nmrg] IETF OPS Area Meetings and mini-BOFs: Preliminary Agenda for the Prague IETF meeting - March 2007 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2007 17:26:03 -0000 I believe that the following announcement may be of interest to the participants in NMRG. Note that the agenda is at this point preliminary and subject to change and that the exact day and time of the OPS Area meetings during the IETF meeting week may also change. Dan Operations and Management (OPS) Area AGENDA Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007 Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20 and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30 Chairs : David Kessens (david.kessens@nokia.com) and Dan Romascanu (dromasca@avaya.com) Jabber : ops@jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda : version 0.1 (draft) ============================================================== Meeting 1 - Monday March 19, 2007 15:20 to 17:20 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina Tsou (total: 30 min) This mini-BOF is requested to gain comments on a technical proposal to reduce the number of messages required when COPS is used to support push mode policy configuration, where each request-state corresponds to an user session. The essence of this proposal is to allow the PDP to request the opening of a new request-state in the same message that sends down policy to be stored against this request-state. At the other end of the session life cycle, allow the PDP to delete a request-state. The proposed extensions to COPS could save two to three messages per session, depending on the details that are finally agreed. I-D: to be submitted 3. Mini-BOF B: - Manageability and Operational Guidelines - David Harrington (total: 30 min) We need to develop multi-protocol manageability and operational guidelines for developers of protocols in the IETF. An internet-draft has been published that summarizes previous work on this goal as a starting point. This work would lead to either a WG, if enough people want to be involved, or a design team to get the document finished. If we can get enough feedback from operators and from protocol designers, this could lead to a BCP; with limited input it would lead to an Informational RFC instead. I-D: to be submitted 4. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington (total: 20 min) This would be an effort to get operators together in a WG to develop a set of best current practices, and a description of supporting technologies, for manageability and operations, similar to the work done in the OpSec WG. There will not be an internet-draft published prior to ietf68. A WG should be created for operators to do this work. 5. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs (total: 20 min) 6. Open Microphone - 15 min Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander (total: 40 min) Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch...Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. I-D: 3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min) Present the state of the art of editing MIB module in XML; Introduce a basic template to edit SMI items in pure XML instead of in raw text; Propose a simple XML template for SMI items; discuss the connections with XML schema and network management protocols. I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be submitted before mid February) 4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20 min) I'd like to show the data model examples we developed and was adopted in the Japanese Standard body. We developed data models of VLAN, Filter (Access Control List), and so on and those data models were adopted by Japanese standardization body called INTAP/OSMIC as standard data models. I'd like to make our data model examples be adopted as an Informational RFC. I-D: to be submitted 5. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale (total: 40 min) Specification of a standard methodology for translating SNMP MIBs into outputs more directly usable by emerging SOA/web services management tools, and specification of a standard methodology for validating those translations. Appropriate translation outputs are TBD by the WG, but can be expected to include one or more of the following: XML, RDF, WSDL, WS-Policy, WS-Event/Notification, Ontology. The translation output(s) should allow for extension of the respective managed element data model in the native SOA/web services environment. Because of the extensibility objective, reverse translation back into SNMP MIB format is a non-goal of the WG, but the possibility should be considered when weighing alternatives. I-D: to be submitted 6. Open microphone (total: 25 min) _______________________________________________ AAA-DOCTORS mailing list AAA-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/aaa-doctors Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0THCroe001214 for ; Mon, 29 Jan 2007 18:12:58 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 88147560AE for ; Mon, 29 Jan 2007 18:12:53 +0100 (CET) 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 10876-02; Mon, 29 Jan 2007 18:12:48 +0100 (CET) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id AF99355E1A; Mon, 29 Jan 2007 18:12:48 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 4AB399E9543; Mon, 29 Jan 2007 18:12:46 +0100 (CET) Date: Mon, 29 Jan 2007 18:12:45 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20070129171245.GA3090@boskop.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de References: <20070126221609.GC937@boskop.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070126221609.GC937@boskop.local> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] Re: future of the snmp measurement document - shepherding volunteer needed X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2007 17:13:09 -0000 On Fri, Jan 26, 2007 at 11:16:09PM +0100, Juergen Schoenwaelder wrote: > [...] Since I am personally involved > as the author/editor, the first thing we need is a shepherd who is > willing to run the process, which starts with soliciting RG reviews by > doing a RG last call. Any volunteers? Our shepherd for is Bert Wijnen and he will now take over the procedure. Thanks to Bert for helping us with this and also many thanks to the others who volunteered to help move this document along. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from nj300815-ier2.net.avaya.com (103.12.152.198.in-addr.arpa [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0TE7AfR011331 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 29 Jan 2007 15:07:16 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE765P000563 for ; Mon, 29 Jan 2007 09:07:07 -0500 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" Date: Mon, 29 Jan 2007 16:07:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague (corrected date) Thread-Index: AcdDrpqUSwS6PSnaQHKopeF9pnPMag== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , , "MIB Doctors \(E-mail\)" , X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l0TE7AfR011331 Subject: [nmrg] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague (corrected date) X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2007 14:07:18 -0000 Please find below the preliminary agenda of the meetings in Prague, as well as the list of mini-BOFs that David and myself have approved for Prague. We were not able to grant to everybody the time that you requested - please be prepared to adjust and manage your time accordingly. Also note that there still may be changes in the dates and time of the meting slots as result of IESG-Secretary changes. Please comment on the agenda items and mini-BOF proposals. We are looking forward to see you all in Prague. Dan Operations and Management (OPS) Area AGENDA Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007 Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20 and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30 Chairs : David Kessens (david.kessens@nokia.com) and Dan Romascanu (dromasca@avaya.com) Jabber : ops@jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda : version 0.1 (draft) ============================================================== Meeting 1 - Monday March 19, 2007 15:20 to 17:20 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina Tsou (total: 30 min) This mini-BOF is requested to gain comments on a technical proposal to reduce the number of messages required when COPS is used to support push mode policy configuration, where each request-state corresponds to an user session. The essence of this proposal is to allow the PDP to request the opening of a new request-state in the same message that sends down policy to be stored against this request-state. At the other end of the session life cycle, allow the PDP to delete a request-state. The proposed extensions to COPS could save two to three messages per session, depending on the details that are finally agreed. I-D: to be submitted 3. Mini-BOF B: - Manageability and Operational Guidelines - David Harrington (total: 30 min) We need to develop multi-protocol manageability and operational guidelines for developers of protocols in the IETF. An internet-draft has been published that summarizes previous work on this goal as a starting point. This work would lead to either a WG, if enough people want to be involved, or a design team to get the document finished. If we can get enough feedback from operators and from protocol designers, this could lead to a BCP; with limited input it would lead to an Informational RFC instead. I-D: to be submitted 4. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington (total: 20 min) This would be an effort to get operators together in a WG to develop a set of best current practices, and a description of supporting technologies, for manageability and operations, similar to the work done in the OpSec WG. There will not be an internet-draft published prior to ietf68. A WG should be created for operators to do this work. 5. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs (total: 20 min) 6. Open Microphone - 15 min Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander (total: 40 min) Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch...Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. I-D: 3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min) Present the state of the art of editing MIB module in XML; Introduce a basic template to edit SMI items in pure XML instead of in raw text; Propose a simple XML template for SMI items; discuss the connections with XML schema and network management protocols. I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be submitted before mid February) 4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20 min) I'd like to show the data model examples we developed and was adopted in the Japanese Standard body. We developed data models of VLAN, Filter (Access Control List), and so on and those data models were adopted by Japanese standardization body called INTAP/OSMIC as standard data models. I'd like to make our data model examples be adopted as an Informational RFC. I-D: to be submitted 5. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale (total: 40 min) Specification of a standard methodology for translating SNMP MIBs into outputs more directly usable by emerging SOA/web services management tools, and specification of a standard methodology for validating those translations. Appropriate translation outputs are TBD by the WG, but can be expected to include one or more of the following: XML, RDF, WSDL, WS-Policy, WS-Event/Notification, Ontology. The translation output(s) should allow for extension of the respective managed element data model in the native SOA/web services environment. Because of the extensibility objective, reverse translation back into SNMP MIB format is a non-goal of the WG, but the possibility should be considered when weighing alternatives. I-D: to be submitted 6. Open microphone (total: 25 min) Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0TE64mb011222 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Mon, 29 Jan 2007 15:06:11 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0TE610D019446 for ; Mon, 29 Jan 2007 09:06:02 -0500 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" Date: Mon, 29 Jan 2007 16:06:00 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague Thread-Index: AcdDrpqUSwS6PSnaQHKopeF9pnPMag== From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , , "MIB Doctors \(E-mail\)" , X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l0TE64mb011222 Subject: [nmrg] OPS Area Meetings and mini-BOFs: Preliminary Agenda for Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2007 14:06:14 -0000 Please find below the preliminary agenda of the meetings in Prague, as well as the list of mini-BOFs that David and myself have approved for Prague. We were not able to grant to everybody the time that you requested - please be prepared to adjust and manage your time accordingly. Also note that there still may be changes in the dates and time of the meting slots as result of IESG-Secretary changes. Please comment on the agenda items and mini-BOF proposals. We are looking forward to see you all in Prague. Dan Operations and Management (OPS) Area AGENDA Meeting : IETF68, Monday March 19, 2007 and Thursday March 22, 2007 Location: Prague, Congress II, Monday March 19, 2007 15:20 to 17:20 and Grand Ballroom Thursday March 22, 2007 9:00 to 11:30 Chairs : David Kessens (david.kessens@nokia.com) and Dan Romascanu (dromasca@avaya.com) Jabber : ops@jabber.ietf.org URL : http://www.ops.ietf.org/ Agenda : version 0.1 (draft) ============================================================== Meeting 1 - Monday March 19, 2007 15:20 to 17:20 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF A: COPS push mode policy configuration - Tom Taylor and Tina Tsou (total: 30 min) This mini-BOF is requested to gain comments on a technical proposal to reduce the number of messages required when COPS is used to support push mode policy configuration, where each request-state corresponds to an user session. The essence of this proposal is to allow the PDP to request the opening of a new request-state in the same message that sends down policy to be stored against this request-state. At the other end of the session life cycle, allow the PDP to delete a request-state. The proposed extensions to COPS could save two to three messages per session, depending on the details that are finally agreed. I-D: to be submitted 3. Mini-BOF B: - Manageability and Operational Guidelines - David Harrington (total: 30 min) We need to develop multi-protocol manageability and operational guidelines for developers of protocols in the IETF. An internet-draft has been published that summarizes previous work on this goal as a starting point. This work would lead to either a WG, if enough people want to be involved, or a design team to get the document finished. If we can get enough feedback from operators and from protocol designers, this could lead to a BCP; with limited input it would lead to an Informational RFC instead. I-D: to be submitted 4. Mini-BOF C: Best Current Practices in Operations and Management - David Harrington (total: 20 min) This would be an effort to get operators together in a WG to develop a set of best current practices, and a description of supporting technologies, for manageability and operations, similar to the work done in the OpSec WG. There will not be an internet-draft published prior to ietf68. A WG should be created for operators to do this work. 5. Improved Efficiency of the OPS Area - proposal for the formation of a OPS Area WG - ADs (total: 20 min) 6. Open Microphone - 15 min Meeting 2 - Monday March 19, 2007 - 9:00 to 11:30AM 1. Meeting Administrivia ADs (total: 5 min) - Mailing list and URL - Minutes Scribe - Jabber Scribe - Blue Sheets 2. Mini-BOF D: NE/facilities/lines/protocols/services data modeling - Michael Alexander (total: 40 min) Network Management (NM) standards have traditionally been focused on protocols, such as pertaining to configuration management and discovery. Yet, all areas of Network Management, ranging from Element Management (EM) to Network Management Systems (NMS) and Service Management Systems have in common that they critically rely on underlying data structures describing devices and services being managed. Network elements (NE) frequently spawn ten thousands of managed objects, such as for a multiservice switch...Traditionally, standardization of access-methods (protocols), discovery, etc. have received most attention, while the more heterogeneous data models and data modeling per saw comparatively less. As there are real possibilities to standardize underlying and universal commonalities in EMS/NMS/Service Management Systems on the one side and managed attributes of NEs, protocols, transmission facilities, lines and services on the other, the two distributions should be closer aligned. Despite the complexity, it is possible to identify and define frameworks and meta models of each constituent and their relation to each other, that would substantially ease the management of present and future devices, networks and services. I-D: 3. Mini-BOF E: MIB module editing in XML : Emile Stephan (total: 20 min) Present the state of the art of editing MIB module in XML; Introduce a basic template to edit SMI items in pure XML instead of in raw text; Propose a simple XML template for SMI items; discuss the connections with XML schema and network management protocols. I-D: draft-stephan-ops-xml-mib-module-template-00 (under edition to be submitted before mid February) 4. Mini-BOF F: Japanese Data Model Standards: Tomoyuki Iijima (total: 20 min) I'd like to show the data model examples we developed and was adopted in the Japanese Standard body. We developed data models of VLAN, Filter (Access Control List), and so on and those data models were adopted by Japanese standardization body called INTAP/OSMIC as standard data models. I'd like to make our data model examples be adopted as an Informational RFC. I-D: to be submitted 5. Mini-BOF G: OWL techniques for MIB to XML documents and schema translation - Bob Natale (total: 40 min) Specification of a standard methodology for translating SNMP MIBs into outputs more directly usable by emerging SOA/web services management tools, and specification of a standard methodology for validating those translations. Appropriate translation outputs are TBD by the WG, but can be expected to include one or more of the following: XML, RDF, WSDL, WS-Policy, WS-Event/Notification, Ontology. The translation output(s) should allow for extension of the respective managed element data model in the native SOA/web services environment. Because of the extensibility objective, reverse translation back into SNMP MIB format is a non-goal of the WG, but the possibility should be considered when weighing alternatives. I-D: to be submitted 6. Open microphone (total: 25 min) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0TA6Eqd018985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 29 Jan 2007 11:06:20 +0100 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l0TA61NM018074; Mon, 29 Jan 2007 04:06:13 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 04:06:10 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jan 2007 11:06:07 +0100 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" Subject: RE: [nmrg] future of the snmp measurement document - shepherdingvolunteer needed Date: Mon, 29 Jan 2007 11:04:45 +0100 Message-ID: In-Reply-To: <20070126221609.GC937@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] future of the snmp measurement document - shepherdingvolunteer needed Thread-Index: AcdBl6W4kv43pCwpR/W127XpM021swB7FLSQ References: <20070126221609.GC937@boskop.local> From: "Wijnen, Bert \(Bert\)" To: , X-OriginalArrivalTime: 29 Jan 2007 10:06:07.0963 (UTC) FILETIME=[183FC2B0:01C7438D] X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-IBRFilter-SpamReport: 0.001 () BAYES_50 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l0TA6Eqd018985 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2007 10:06:24 -0000 I reviewed the document and have the following comments, just NITS and TYPOs - abstract In order to prevent discussion/questioning about it, you might want to de-emphasize the "configuration" usage of SNMP. How about changing The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and configure network elements. Even though the wo something aka The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and (sometimes also) configure network elements. Even though the - page 6 It is recommended to capture at least a full week of data. Operators are encouraged to capture traces over even longer periods of time. Tools such as tcpslice [1] or pcapmerge [3] can be used to merge or split pcap trace files as needed. I would change "to merge or split" into "to split or merge" so that you have the same sequence as the "tcpslice pr pcapmerge". - page 6 For each captured trace, some meta data should be recorded and made available. The meta data should include information such as where the traces was collected, when it was collected, contact information, s/the traces/the trace/ ?? the size of the trace, any known special events during the data collection period and so on. It is also extremely useful to provide a unique identification. There are special online services such as DatCat [4] where meta data can be store and which provide unique identifiers. s/can be store/can be stored/ - section 4.2 The comma separated values (CSV) format has been design to capture s/has been design/has been designed/ 2. Source IP address in dotted quad notation (IPv4), for example "127.0.0.1", or compact hexadecimal notation (IPv6), for example "::1". Would it not be better to use the reserved addresses for example as per RFC3330 and RFC3849!!?? 8. SNMP protocol operation indicated by one of the keywords get- request, get-next-request, get-bulk-request, set-request, trap, trap2, inform, response, report. I onder why sme operations are represented by the full name, while other are represented by a name that is not complete. Why not use the pdu-names as per RFC3416L PDUs ::= CHOICE { get-request GetRequest-PDU, get-next-request GetNextRequest-PDU, get-bulk-request GetBulkRequest-PDU, response Response-PDU, set-request SetRequest-PDU, inform-request InformRequest-PDU, snmpV2-trap SNMPv2-Trap-PDU, report Report-PDU } So change inform to inform-request and trap2 to snmpV2-trap 13. For each varbind in the varbind list, three output elements are generated 1. Object names given as object identifiers in dotted decimal s/Object names given as object identifiers/Object name goven as object identifier/ That is make it singular instead of plural? After all you speak "for each object", and it seems to me that for one object you have only one name/oid. Same for sub-points 2 and 3. 2. Object base type name or exception names, that is one of the following: null, integer32, unsigned32, unsigned64, ipaddress, octet-string, object-identifier, no-such-object, no-such-instance, and end-of-mib-view. Is the 'unsigned64' meant to be used for Counter64? - security considerations section: Anonymization techniques can be applied to keep more information in traces which could reveal sensitive information. When using s/could reveal/could otherwise reveal/ ?? - general You use "bytes" instead of "octets". I know some IETF people prefer "octets". - references. not sure I understand why RFC3418 is normative while 2863 is informative. same for some other RFCs. But I can live with it. Bert > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Juergen > Schoenwaelder > Sent: vrijdag 26 januari 2007 23:16 > To: nmrg@ibr.cs.tu-bs.de > Subject: [nmrg] future of the snmp measurement document - > shepherdingvolunteer needed > > Hi, > > a few days ago, I visited Aiko Pras and this led (among other > things) to the updated version of . We moved the format > specifications into the body of the document and revised the > XML format to match existing implementations, to deal with > Opaque varbind values, and to have a proper namespace. We > also dropped the appendix about meta-data and instead provide > a reference to the www.datcat.org CAIDA project. Aiko and I > believe that the document is essentially done and useful > since it documents the trace exchange formats that are being > using for some time now successfully. > > So we would like to move this document forward. To do this, > it is important to know that the IRTF has raised the bar > significantly to publish RFCs. There is a working document > (currently expired) which defines a procedure which > essentially consists of the following steps: > > a) There needs to be some RG last call and the level of support and > number of reviewers should be documented. > > b) A document shepherd must be selected to run the process. This > should be a person not involved as an author or main technical > contributor. > > c) Once RG support has been established, the sponsoring RG chair > brings the document to the IRSG for publication. > > d) A (firm) eight-week IRSG review period follows after which > a poll is > taken. Reviews should be similar to that for a conference paper. > > e) Reviews should be written to be public. In particular, they should > be sent to the submitted RG mailing list. > > f) Once the IRSG supports the document, the document goes to the RFC > editor who sends it to the IESG for review. > > g) Once the IESG review is complete, the document goes into the > publication queue. > > As you can see, the process is non-trivial. Note that I do > not want to stimulate a discussion of the value of all this > here - I am just interested to move a document forward. Since > I am personally involved as the author/editor, the first > thing we need is a shepherd who is willing to run the > process, which starts with soliciting RG reviews by doing a > RG last call. Any volunteers? > > /js > > [I am attaching the latest IRTF RFC publication process draft > I have seen as some of your might be interested what the > details of this procedure are.] > > -- > Juergen Schoenwaelder {International|Jacobs} > University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0QMGGlC008447 for ; Fri, 26 Jan 2007 23:16:21 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D311A5AD55 for ; Fri, 26 Jan 2007 23:16:16 +0100 (CET) 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 20506-08; Fri, 26 Jan 2007 23:16:12 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id B3A965AD1F; Fri, 26 Jan 2007 23:16:11 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 315BD9DD745; Fri, 26 Jan 2007 23:16:09 +0100 (CET) Date: Fri, 26 Jan 2007 23:16:09 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20070126221609.GC937@boskop.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: 1 (*) BAYES_60 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] future of the snmp measurement document - shepherding volunteer needed X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 22:16:24 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, a few days ago, I visited Aiko Pras and this led (among other things) to the updated version of . We moved the format specifications into the body of the document and revised the XML format to match existing implementations, to deal with Opaque varbind values, and to have a proper namespace. We also dropped the appendix about meta-data and instead provide a reference to the www.datcat.org CAIDA project. Aiko and I believe that the document is essentially done and useful since it documents the trace exchange formats that are being using for some time now successfully. So we would like to move this document forward. To do this, it is important to know that the IRTF has raised the bar significantly to publish RFCs. There is a working document (currently expired) which defines a procedure which essentially consists of the following steps: a) There needs to be some RG last call and the level of support and number of reviewers should be documented. b) A document shepherd must be selected to run the process. This should be a person not involved as an author or main technical contributor. c) Once RG support has been established, the sponsoring RG chair brings the document to the IRSG for publication. d) A (firm) eight-week IRSG review period follows after which a poll is taken. Reviews should be similar to that for a conference paper. e) Reviews should be written to be public. In particular, they should be sent to the submitted RG mailing list. f) Once the IRSG supports the document, the document goes to the RFC editor who sends it to the IESG for review. g) Once the IESG review is complete, the document goes into the publication queue. As you can see, the process is non-trivial. Note that I do not want to stimulate a discussion of the value of all this here - I am just interested to move a document forward. Since I am personally involved as the author/editor, the first thing we need is a shepherd who is willing to run the process, which starts with soliciting RG reviews by doing a RG last call. Any volunteers? /js [I am attaching the latest IRTF RFC publication process draft I have seen as some of your might be interested what the details of this procedure are.] -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-irtf-rfcs-01a.txt" Network Working Group A. Falk Internet-Draft IRTF Chair Intended status: Informational January 10, 2007 Expires: July 14, 2007 IRTF Research Group RFCs draft-irtf-rfcs-01a.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 14, 2007. Copyright Notice Copyright (C) The Internet Society (2007). Falk Expires July 14, 2007 [Page 1] Internet-Draft IRTF RFCs January 2007 Abstract This document describes a process for research groups in the Internet Research Task Force to publish RFCs. Table of Contents 1. Changes from Last Version . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Document Shepherds . . . . . . . . . . . . . . . . . . . . . . 5 4. Document Tracker . . . . . . . . . . . . . . . . . . . . . . . 6 5. Process Description . . . . . . . . . . . . . . . . . . . . . 7 5.1. Research Group Preparation . . . . . . . . . . . . . . . . 7 5.2. IRSG Review . . . . . . . . . . . . . . . . . . . . . . . 7 5.2.1. Initial steps . . . . . . . . . . . . . . . . . . . . 8 5.2.2. Reviews . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.3. Poll . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2.4. Followup . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. IESG Review . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. RFC Editor Handling . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. Informative References . . . . . . . . . . . . . . . . . . . . 14 Appendix A. IESG Notes . . . . . . . . . . . . . . . . . . . . . 15 Appendix B. State Diagram . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 18 Falk Expires July 14, 2007 [Page 2] Internet-Draft IRTF RFCs January 2007 1. Changes from Last Version Updates from draft-irtf-rfcs-00.txt: o Moved IESG review to occur before RFC Editor submission o Expansion of shepherd duties o Added section on tracker o Text on thorough reviews o Removed a decreasingly-relevant section on A-D sponsored documents as a model for the IRTF docs o Linkage added to draft-iab-rfc-editor o Added state diagram o Reformatting Falk Expires July 14, 2007 [Page 3] Internet-Draft IRTF RFCs January 2007 2. Introduction This document specifies a review and publication process for the Internet Research Task Force (IRTF) [RFC2014]. Most documents undergoing this process will come from IRTF Research Groups and the objective is that they are published as Informational or Experimental RFCs by the RFC Editor. Currently, the IRTF Research Group drafts are treated like independent submissions by the RFC Editor. Roughly, the process consists of the following steps: o The document author submits an Internet Draft to the RFC Editor as an independent submission. o The RFC Editor performs independent submission review (ISR) for editorial acceptability and may request the authors revise the document before publishing. o The IESG performs a review (to avoid standards process end- arounds) and inserts a disclaimer (see RFC3932[RFC3932]). o Independent submissions are delayed by lower priority treatment as they move through the RFC Editor's queue. This document defines the review and publication process for an IRTF Document Stream. (Document streams are described in Section 5 of [I-D.iab-rfc-editor].) The process may be summarized as: o The Research Group reviews the document and agrees it should be published (but may not agree on the technical content). o The Internet Research Steering Group (IRSG) conducts a thorough technical and editorial review o The Internet Engineering Steering Group (IESG) reviews the document to assure there are no conflicts the standardization activities o The document is submitted to the RFC Editor for publication This draft has been updated based on about nine months of experience and processing of four documents. The IRTF plans to continue the trial of this process for several more documents and may again revise this process. Falk Expires July 14, 2007 [Page 4] Internet-Draft IRTF RFCs January 2007 3. Document Shepherds Documents should have a shepherd. This is a relatively new concept initially developed in the IETF to ensure that issues raised in the review and publication process are responded to in a timely manner. The IETF shepherding process is described in [I-D.ietf-proto-wgchair-doc-shepherding] and has been adapted to the IRTF publication process. Shepherd responsibilities are noted for each phase of the publication process in subsequent sections. Some general things to note: o Shepherds should normally be an RG chair since they know the IRSG members, are familiar with the technical content, and know the document history. However, the RG chair should not be a shepherd if they are an author of the document. o Shepherds are responsible to track and facilitate document progression through RFC publication. This includes finding IRSG reviewers, facilitating resolution of review comments, entering information into the tracker(s), keeping track of review schedules, and prodding token holders to act expeditiously. o Shepherds should summarize substantive review comments and their resolution. o Shepherds should be copied on all correspondence regarding a document. For example, if the IESG has questions during their review, the shepherd should be included in the exchange. This can be helpful should the RG take a position different than the author on suggested changes. Falk Expires July 14, 2007 [Page 5] Internet-Draft IRTF RFCs January 2007 4. Document Tracker As of this writing the IRSG is using its own public document tracker [TRAC]. This tracker is intended to collect the shepherd and reviewer identities, reviewer comments, and state transitions as the document progresses. It is the responsibility of the shepherd to maintain the tracker. It is expected that, in the future, the IRTF will use the IETF's I-D Tracker [IDTRAC] to collect and manage this information. Modifications are planned for the I-D Tracker to accommodate the IRTF publication process. When the I-D Tracker can support the process described below, the IRSG tracker will no longer be used. Information to be captured in the tracker: o URL to the draft (updated if the draft is revised) o Document shepherd o Type of RFC: Informational or Experimental o Desired IESG Note text o Reviewers (volunteers for the thorough review) o Scheduled date for IRSG poll o IRSG poll results o Pointers to RG reviews o IRSG Review text (or pointers) o IRSG review resolutions (or pointers) Falk Expires July 14, 2007 [Page 6] Internet-Draft IRTF RFCs January 2007 5. Process Description The following sections describe the steps for IRTF-track document review and publication process. There are fundamentally two steps: IRSG review and IESG review. The document shepherd is responsible for making sure reviews are responded to and documented and that the process moves along. The RFC Editor and the IAB have reviewed the procedure below and fully support it. [[anchor4: Need to confirm that all the parties -- IRSG, IAB, IESG, and RFC Editor -- still support the modifications. This text remains as a placeholder for a statement of support by the relevant bodies.]] 5.1. Research Group Preparation An RG may choose to publish RFCs as independent submissions directly to the RFC Editor or may decide to publish a document using the IRTF publication track. If the latter is chosen, the RG must review the document for editorial and technical quality. The document should contain a statement in the abstract identifying it as the product of the RG and a paragraph in the first section describing the level of support for publication (e.g., "this document represents the consensus of the FOOBAR RG", "the views in this document were considered controversial by the FOOBAR RG but the RG reached a consensus that the document should still be published") and the breadth of review for the document. For example, was this document read by all the active contributors, only three people, or folks who are not "in" the RG but are expert in the area? It should also be very clear throughout the document that it is not an IETF product and is not a standard. If an experimental protocol is described appropriate usage caveats need to be present. If the protocol has been considered in an IETF working group in the past, this should be noted in the introduction as well. The shepherd should be selected at this time as discussed in Section 3. Now the document may be submitted to the IRSG for review. 5.2. IRSG Review IRSG review includes at least two thorough technical reviews concluding with a poll of the IRSG on whether the document should be published. It is the IRSG's responsibility to ensure high technical and editorial quality. Falk Expires July 14, 2007 [Page 7] Internet-Draft IRTF RFCs January 2007 5.2.1. Initial steps The RG chair brings the document to the IRSG for publication by sending an email message to the IRSG requesting review and including a pointer to the draft. The expectation is that the RG chair has already reviewed the draft thoroughly and considers it of publishable quality editorially and technically. The RG should be copied on the mail message requesting IRSG review. The RG chair should identify the document shepherd at that time (if it isn't them). The shepherd should do several things at this time: 1. Create an entry in the tracker for the document, entering all of the items listed in Section 4 that are available and setting the document state to "IRSG Review". 2. Send an email to the IRSG mailing list with pointers to the new tracker entries (this may be automated) 3. Find two members of the IRSG to perform a thorough review of the document. (This is to ensure at least two thorough reviews are performed.) 4. Schedule the poll eight weeks later. 5.2.2. Reviews The purpose of the IRSG review is to ensure consistent editorial and technical quality for IRTF publications. Reviews should be similar to that for a conference paper. Reviews should be written to be public. Review comments should be sent to the IRSG and RG mailing lists and entered into the tracker. All IRSG review comments must be addressed. However, the RG need not accept every comment. It is the responsibility of the shepherd to understand the comments and ensure that the RG considers them including adequate dialog between the reviewer and the author and/or RG. Reviews and their resolution should be entered into the tracker by the document shepherd. 5.2.3. Poll A (firm) eight-week IRSG review period follows after which a poll is taken. Votes can be: Falk Expires July 14, 2007 [Page 8] Internet-Draft IRTF RFCs January 2007 o 'ready to publish' -- requires a thorough read and reasonably detailed review o 'not ready to publish' -- requires a thorough read, reasonably detailed review, and actionable comments. o 'no objection' -- I don't object if this document goes forward; I've read the document (perhaps quickly); I have some small comments which are not show stoppers; I don't have great expertise in the area. o 'request more time to review' -- a commitment to provide a thorough review in a specified period of time. At least two other IRSG members (besides the one sponsoring the document) need to vote 'ready to publish' for the document to move forward. Any vote of 'not ready to publish' will hold a document's progress until the comments are addressed. The IRTF chair may choose to override 'not ready to publish' holds that, in the opinion of the chair, have received an adequate response. The IRTF chair will record the poll results in the tracker. 5.2.4. Followup When an ID has been published reflecting the resolution of all comments, the RG chair or the shepherd sends an email to the IRTF Chair (cc'ing the IRSG and the RG) summarizing the IRSG review comments and their resolution and including pointers to the tracker entries, detailed reviews, and discussion. IRSG Review is concluded at this time. The tracker should be updated to reflect moving to new state, IESG Review. 5.3. IESG Review The IRTF Chair will forward the summary email to the IESG [[anchor12: sent to the secretariat?]]requesting the document be reviewed using the criteria from RFC3932. RFC3932 describes a review process to ensure non-IETF documents do not conflict with active or immanent IETF work. The request email to the IESG should identify the document authors and shepherd. The document shepherd should provide the IESG reviewer with the desired IESG note (and rationale) from the list in Appendix A. The IESG member leading the review should make it clear to the rest of the IESG that IRTF documents on the agenda are to be reviewed according to RFC 3932 procedures. At the time of this writing, a recommended procedure is to include text in the Note field of the Falk Expires July 14, 2007 [Page 9] Internet-Draft IRTF RFCs January 2007 Tracker to this effect. In the future, other methods of identifying these documents may arise, such as IRTF documents being grouped separately on the agenda or being marked as such explicitly in the tracker. [[anchor13: Mark Townsley requested this text. Seems a little too mechanical for me but it can be removed later.]] The document shepherd is responsible for collecting IESG comments and responding to questions. This may include checking the IETF I-D tracker for IESG comments and forward them to the research group. A revised draft may be required to respond to IESG comments. There are several reasons why the IESG may question or object to a document being published which are described in RFC3932 section 4. However, the decision to publish a document ultimately rests with the RFC Editor, under the direction of the IAB (as described in [I-D.iab-rfc-editor]. The shepherd now sends a request for publication including pointers to the reviews in the tracker to the IRTF Chair, cc'ing the RG and IRSG. The tracker should be updated at this time to reflect the new state, "Doc approved, awaiting submission to RFC Editor." 5.4. RFC Editor Handling The IRTF Chair will forward the request for publication email to the RFC Editor, placing the document in the RFC Editor's publication queue. The tracker should be updated to reflect the state of "RFC Editor publication queue." The document enters the RFC Editor queue at the same priority as IETF- and IAB-track (non-standards) documents. The document shepherd is responsible for ensuring that the document authors are responsive to the RFC Editor and that the RFC editing process goes smoothly. The AUTH48 review stage of RFC publication is an area where the shepherd's may be of particular assistance, ensuring a) authors respond promptly in reviewing about-to-be-published documents and b) authors don't inject changes into the document at the last minute which would not be supported by the research group. Falk Expires July 14, 2007 [Page 10] Internet-Draft IRTF RFCs January 2007 6. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Falk Expires July 14, 2007 [Page 11] Internet-Draft IRTF RFCs January 2007 7. Security Considerations There are no security considerations in this document. Falk Expires July 14, 2007 [Page 12] Internet-Draft IRTF RFCs January 2007 8. Acknowledgements Many thanks for Mark Allman, Bob Braden, Brian Carpenter, Leslie Daigle, Stephen Farrell, Tom Henderson, Rajeev Koodli, Allison Mankin, Karen Sollins, and Mark Townsley who contributed to preparation of this process. Falk Expires July 14, 2007 [Page 13] Internet-Draft IRTF RFCs January 2007 9. Informative References [I-D.iab-rfc-editor] Daigle, L., "The RFC Editor", draft-iab-rfc-editor-00 (work in progress), May 2006. [I-D.ietf-proto-wgchair-doc-shepherding] Levkowetz, H. and D. Meyer, "Protocol Pilot: Workgroup Chair Followup of AD Evaluation Comments", draft-ietf-proto-wgchair-doc-shepherding-00 (work in progress), July 2004. [IDTRAC] "IETF I-D Tracker", 2006, . [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. [TRAC] "IRTF Document Tracker", 2006, . Falk Expires July 14, 2007 [Page 14] Internet-Draft IRTF RFCs January 2007 Appendix A. IESG Notes After the review an IESG note is typically added. Rather than the disclaimers found in RFC3932, the IESG will instruct the authors to add the following disclaimer: "This RFC is a product of the Internet Research Task Force and is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment." For documents that specify a protocol or other technology and that have been considered in the IETF at one time: "This RFC is a product of the Internet Research Task Force. The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. However, this is not an IETF document is not a candidate for any level of Internet Standard. The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment." Falk Expires July 14, 2007 [Page 15] Internet-Draft IRTF RFCs January 2007 Appendix B. State Diagram The diagram below shows the states and transition events for IRTF RFC processing. +---------------+ +------------+ review cmnts +---------------+ | request to | | |-------------->| IRSG Review: | | publish from |---->|IRSG Review | | revised ID | | RG chair | | |<--------------| needed | +---------------+ +------------+ +---------------+ | |IRSG |Approval | V +--------------+ review cmnts +---------------+ | IESG |-------------->|IESG review: | | 'end-around' | |revised ID | | review |<--------------|needed | +-------+------+ +---------------+ | |shepherd sends |summary email | V +---------------+ | Doc approved, | | awaiting | | submission to | | RFC Editor | | | +---------------+ | |IRTF chair |sends msg |to RFC Ed | V +---------------+ +-----------------+ | RFC Editor | | | | publication |-------------->| RFC published | | queue | | | +---------------+ +-----------------+ Falk Expires July 14, 2007 [Page 16] Internet-Draft IRTF RFCs January 2007 Author's Address Aaron Falk USC Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina Del Rey, California 90292 USA Phone: +1-310-448-9327 Email: falk@isi.edu Falk Expires July 14, 2007 [Page 17] Internet-Draft IRTF RFCs January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Falk Expires July 14, 2007 [Page 18] --tKW2IUtsqtDRztdT-- Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0QLv4mu006516 for ; Fri, 26 Jan 2007 22:57:09 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 3E4B85AD4F for ; Fri, 26 Jan 2007 22:57:04 +0100 (CET) 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 19882-02; Fri, 26 Jan 2007 22:57:00 +0100 (CET) Received: from boskop.local (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id C1A3C5AD1F; Fri, 26 Jan 2007 22:57:00 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 378739DD64F; Fri, 26 Jan 2007 22:57:00 +0100 (CET) Date: Fri, 26 Jan 2007 22:57:00 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20070126215700.GB937@boskop.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] [Internet-Drafts@ietf.org: I-D ACTION:draft-irtf-nmrg-snmp-measure-01.txt] X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jan 2007 21:57:11 -0000 Hi, the updated version of the SNMP measurement document has been posted by the IETF secretariat (see below). I will say more about the potential future of this document in a subsequent message. /js ----- Forwarded message from Internet-Drafts@ietf.org ----- To: i-d-announce@ietf.org Cc: From: Internet-Drafts@ietf.org Date: Fri, 26 Jan 2007 15:50:02 -0500 Subject: I-D ACTION:draft-irtf-nmrg-snmp-measure-01.txt Precedence: list Reply-To: internet-drafts@ietf.org Errors-To: i-d-announce-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SNMP Traffic Measurements and Trace Exchange Formats Author(s) : J. Schoenwaelder Filename : draft-irtf-nmrg-snmp-measure-01.txt Pages : 23 Date : 2007-1-26 The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and configure network elements. Even though the SNMP technology is well documented, it remains relatively unclear how SNMP is used in practice and what typical SNMP usage patterns are. This document proposes to carry out large scale SNMP traffic measurements in order to develop a better understanding how SNMP is used in real world production networks. It describes the motivation, the measurement approach, and the tools and data formats needed to carry out such a study. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-irtf-nmrg-snmp-measure-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----- End forwarded message ----- Received: from mail13.bluewin.ch (mail13.bluewin.ch [195.186.18.62]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0P9aRjf030023 for ; Thu, 25 Jan 2007 10:36:33 +0100 Received: from [192.168.1.2] (85.3.98.250) by mail13.bluewin.ch (Bluewin 7.3.118) id 45AB75E800438ECB for nmrg@ibr.cs.tu-bs.de; Thu, 25 Jan 2007 09:36:22 +0000 Message-ID: <45B87A14.200@ieee.org> Date: Thu, 25 Jan 2007 10:36:20 +0100 From: "J.P. Martin-Flatin" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061211 SeaMonkey/1.0.7 MIME-Version: 1.0 To: IRTF Network Management Research Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] ITU-T recommendations available for free X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "J.P. Martin-Flatin" List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 09:36:36 -0000 -------- Original Message -------- Date: Thu, 18 Jan 2007 17:36:54 +0000 From: David Chadwick Organization: University of Kent Dear All ITU just announced From the beginning of 2007, ITU-T Recommendations will be available without charge for a trial period. With only a small number of exceptions all in-force Recommendations will be available in PDF form via a simple mouse click. There is a general belief that the strategic importance of making on-line access to ITU-T Recommendations free outweighs the costs (in terms of lost revenue) to ITU. This is seen as a way to increase the transparency of ITU-T work and encourage wider participation in ITU-T activities. It is also believed that this policy will help increase developing countries' awareness of pertinent issues and help to promote the participation of academia in ITU-T work. Links to all the recommendations start here http://www.itu.int/ITU-T/publications/recs.html Links to the X Recommendations start here http://www.itu.int/rec/T-REC-X/e Enjoy David -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0P7auGv014292 for ; Thu, 25 Jan 2007 08:37:01 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0A34A5AD02 for ; Thu, 25 Jan 2007 08:36:56 +0100 (CET) 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 23997-03; Thu, 25 Jan 2007 08:36:52 +0100 (CET) Received: from noname.localhost (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8C9C15AD19; Thu, 25 Jan 2007 08:36:52 +0100 (CET) Received: by noname.localhost (Postfix, from userid 501) id 172BD9DAB3E; Thu, 25 Jan 2007 08:36:52 +0100 (CET) Date: Thu, 25 Jan 2007 08:36:52 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20070125073651.GC1878@noname> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] [falk@ISI.EDU: [IRSG] call for a plenary research talk at the Prague IETF] X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 07:37:03 -0000 Hi, below about an opportunity to give a really good talk in front of a large technical audience. Like Steve Jobs... ;-) /js ----- Forwarded message from Aaron Falk ----- To: Internet Steering Group From: Aaron Falk Date: Wed, 24 Jan 2007 16:27:48 -0800 Subject: [IRSG] call for a plenary research talk at the Prague IETF Precedence: list Errors-To: irsg-bounces@mailman.isi.edu As I mentioned in my last message, we are trying something new for the IAB plenary at the Prague IETF. Rather than a long talk by an RG, we are going with a short talk about the highlights of a group and a second research talk which may or may not be related to the IRTF. So, this is a call for ideas on a research talk at the IETF. I'm attaching a message below from an IAB member outlining some of the, er, quality control requirements for such a talk. Ideally, we want an engaging speaker with interesting stuff that's relevant to the IETF. If you have suggestions (and have reason to believe they would be available to give a talk in Prague in March) please send suggestions. The IAB (with our input) will make the decision to extend the invitation. --aaron Begin forwarded message: > From: Eric Rescorla > Date: January 11, 2007 2:43:31 PM PST > To: iab@ietf.org > Subject: Criteria for plenary talks > > On yesterday's call I volunteered to write up what I thought > was a reasonable barrier for a plenary talk. My overriding > principle is that we don't *need* to have any given talk. > If people are just sitting through it wishing they were in > the bar, then we should have them in the bar. So, with that > in mind, a talk should be: > > - On a topic of general interest to a reasonably large fraction > of the IETF population. > - Deliver new information at a level they can process. E.g., > security is a topic of general interest but it doesn't make > sense to have Dan Boneh talk about Bilinear Maps. > - Be reasonably well delivered and hopefully entertaining. > > The first point we can evaluate from the talk proposal. The > second two points require us to either have a lot of trust > in the person speaking (e.g., I would let Steve Jobs speak > because I know he's entertaining...) or that we see the > slides in advance. Optimally, we'd see the slides and have > someone report that this person was a good speaker. > > Note that I'm not suggesting we hack the slides into being good. > Rather, we solicit proposals for plenary talks and if people's > slides look bad we don't let them talk (again, with the exception > of the people we really know will be good...) > > -Ekr > _______________________________________________ IRSG mailing list IRSG@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/irsg ----- End forwarded message ----- -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0O05bfJ002385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 24 Jan 2007 01:05:43 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0O05YuU006152 for ; Tue, 23 Jan 2007 19:05:35 -0500 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" Date: Wed, 24 Jan 2007 02:05:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LAST REMINDER: OPS Area mini-BOFs in Prague Thread-Index: Acc0gtyrABLFfwSZQwe7EkhqqrpLqwGUzm1Q References: <459B763C.1000600@alaxala.net> <45A445ED.9070509@hitachi.com> From: "Romascanu, Dan \(Dan\)" To: "OPS Area" , , , "MIB Doctors \(E-mail\)" , , X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l0O05bfJ002385 Subject: [nmrg] LAST REMINDER: OPS Area mini-BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2007 00:05:45 -0000 To all contributors who intend to present in Prague - If you did not do it yet, please confirm the submissions for a mini-BOF slot at the OPS Area meetings in Prague and send us the following information: . - short technical scope description (not much more than one paragraph) - goals of the proposal, where this can lead: e.g. new protocol or extension of an existing protocol, standard, BCP or Informational RFC, formation of a WG or individual submission, other - estimation of time you will need in Prague including Q&A - whether there is an Internet-Draft or you intent to submit one before the Prague IETF Please send us this information until 1/25 the latest. David and me will meet on 1/26 and will communicate the finalized agenda shortly after. Thanks and Regards, Dan Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0HEcTYj011707 for ; Wed, 17 Jan 2007 15:38:34 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 18FA057F62 for ; Wed, 17 Jan 2007 15:38:29 +0100 (CET) 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 03683-08; Wed, 17 Jan 2007 15:38:25 +0100 (CET) Received: from wavelan1.dynip.doc.ic.ac.uk (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id E4C5358B29; Wed, 17 Jan 2007 15:38:25 +0100 (CET) Received: by wavelan1.dynip.doc.ic.ac.uk (Postfix, from userid 501) id 43ED99C5121; Wed, 17 Jan 2007 15:37:23 +0100 (CET) Date: Wed, 17 Jan 2007 15:37:22 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20070117143722.GA13894@wavelan1.dynip.doc.ic.ac.uk> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de References: <20070109094224.GA4333@boskop.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070109094224.GA4333@boskop.local> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] Re: 22nd NMRG meeting in Prague in March 2007 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 14:38:36 -0000 On Tue, Jan 09, 2007 at 10:42:24AM +0100, Juergen Schoenwaelder wrote: > [...] To complement Dan's efforts, I propose to hold an NMRG meeting > on Friday March 23, either just during the afternoon or the full day. [...] I have asked for an IETF Friday meeting slot with the option to extend into the afternoon to have more time for discussion. We will have to wait what comes out of the scheduling algorithm executed by the IETF secretariat. I working on collecting contributions to the meeting in cooperation with Dan Romascanu and Dave Kessens who are organizing some IETF mini-bof session at the Prague IETF. We are open for proposals; if you have done research that you want to discuss with an IETF community, going to Prague is a perfect chance of doing this. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0HEM0nO009624 for ; Wed, 17 Jan 2007 15:22:05 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 553D657F62 for ; Wed, 17 Jan 2007 15:22:00 +0100 (CET) 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 02282-03; Wed, 17 Jan 2007 15:21:55 +0100 (CET) Received: from wavelan1.dynip.doc.ic.ac.uk (unknown [10.222.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 7439D56179; Wed, 17 Jan 2007 15:21:52 +0100 (CET) Received: by wavelan1.dynip.doc.ic.ac.uk (Postfix, from userid 501) id B9B549C5095; Wed, 17 Jan 2007 15:21:49 +0100 (CET) Date: Wed, 17 Jan 2007 15:21:49 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20070117142149.GC13400@wavelan1.dynip.doc.ic.ac.uk> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -1.951 () BAYES_20 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] snmp trace analysis status update X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2007 14:22:07 -0000 Hi, at the IETF in Montreal, I reported about the activity to collect SNMP traces and to analyze what is going on in production networks. We have done some additional work in this space and we are doing the final edits on a paper which will be presented at IM 2007. Since there are lots of SNMP experts on this list and since we still have a window to make some updates, I have put a draft copy on the web. http://www.faculty.iu-bremen.de/jschoenwae/papers/im-2007.pdf We appreciate feedback. /js PS: We are still looking for more traces. If you believe our data source is biased, please help us to unbias it. ;-) -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0G9vOX9003125 for ; Tue, 16 Jan 2007 10:57:30 +0100 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BDB8520031E5; Tue, 16 Jan 2007 10:57:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF9xuv-+A8XN; Tue, 16 Jan 2007 10:57:58 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id AB08C20001AF; Tue, 16 Jan 2007 10:57:58 +0100 (CET) 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" Subject: RE: [nmrg] 22nd NMRG meeting in Prague in March 2007 Date: Tue, 16 Jan 2007 10:57:19 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD696984020@mx1.office> In-Reply-To: <20070109094224.GA4333@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] 22nd NMRG meeting in Prague in March 2007 Thread-Index: Accz01rONBTUJCGLSFmHjvvhUSmWyAE8vh2g References: <20070109094224.GA4333@boskop.local> From: "Giorgio Nunzi" To: , X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l0G9vOX9003125 X-Mailman-Approved-At: Thu, 18 Jan 2007 08:02:42 +0100 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jan 2007 09:57:31 -0000 Hi Juergen, Here is my contribution: > a) Do you support an NMRG meeting in Prague? Yes > b) Do you plan to attend an NMRG in Prague? Yes > c) Do you have any research results you like to present during an NMRG > meeting in Prague? Not sure at the moment. We can provide more input later on. Giorgio Received: from alnrmhc12.comcast.net (alnrmhc12.comcast.net [204.127.225.92]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0FHZwwp010667 for ; Mon, 15 Jan 2007 18:36:03 +0100 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (alnrmhc12) with SMTP id <20070115173552b1200jniuee>; Mon, 15 Jan 2007 17:35:52 +0000 From: "David B Harrington" To: References: <20070109094224.GA4333@boskop.local> <45ABA3AF.70000@utwente.nl> Subject: RE: [nmrg] 22nd NMRG meeting in Prague in March 2007 Date: Mon, 15 Jan 2007 12:32:15 -0500 Message-ID: <001301c738cb$19c69630$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.2962 Thread-Index: Acc4vXller2ZQw7WRHeTLQj25JAdewADUsPw In-Reply-To: <45ABA3AF.70000@utwente.nl> X-IBRFilter-SpamReport: 1.615 (*) BAYES_50,DNS_FROM_RFC_POST X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 17:36:05 -0000 Has anything been decided about whether such a meeting will precede or follow the IETF meeting? I would like to start the lengthy corporate process to book my airline, so I need to know when the NMRG meeting will be. dbh > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Aiko Pras > Sent: Monday, January 15, 2007 10:54 AM > To: nmrg@ibr.cs.tu-bs.de > Cc: Aiko Pras > Subject: Re: [nmrg] 22nd NMRG meeting in Prague in March 2007 > > Juergen Schoenwaelder wrote: > > a) Do you support an NMRG meeting in Prague? > Yes > > > > b) Do you plan to attend an NMRG in Prague? > My plan is to attend the NMRG meeting on friday, and IETF meetings > provided they are at the end of the week (I will not be able > to attend > the entire week). > > > c) Do you have any research results you like to present > during an NMRG > > meeting in Prague? > I think some results of our SNMP trace analysis can be presented. > > Bye > > Aiko > -- > !! This message is brought to you via the `nmrg' mailing list. > !! Please do not reply to this message to unsubscribe. To > unsubscribe or adjust > !! your settings, send a mail message to > > !! or look at https://mail.ibr.cs.tu-bs.de/mailman/listinfo/nmrg. > Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l0FFsOC8030159 for ; Mon, 15 Jan 2007 16:54:29 +0100 Received: from leeuwarden.cs.utwente.nl (leeuwarden.ewi.utwente.nl [130.89.10.54]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id l0FFsBM7029546; Mon, 15 Jan 2007 16:54:11 +0100 (MET) Received: from [146.169.25.26] (wavelan1.dynip.doc.ic.ac.uk [146.169.25.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leeuwarden.cs.utwente.nl (Postfix) with ESMTP id 36D3C37C7ED; Mon, 15 Jan 2007 16:54:11 +0100 (CET) Message-ID: <45ABA3AF.70000@utwente.nl> Date: Mon, 15 Jan 2007 16:54:23 +0100 From: Aiko Pras User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] 22nd NMRG meeting in Prague in March 2007 References: <20070109094224.GA4333@boskop.local> In-Reply-To: <20070109094224.GA4333@boskop.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.003 () AWL X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 15 Jan 2007 16:54:11 +0100 (MET) X-IBRFilter-SpamReport: -2.599 () BAYES_00 Cc: Aiko Pras X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2007 15:54:39 -0000 Juergen Schoenwaelder wrote: > a) Do you support an NMRG meeting in Prague? Yes > > b) Do you plan to attend an NMRG in Prague? My plan is to attend the NMRG meeting on friday, and IETF meetings provided they are at the end of the week (I will not be able to attend the entire week). > c) Do you have any research results you like to present during an NMRG > meeting in Prague? I think some results of our SNMP trace analysis can be presented. Bye Aiko Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l09EfNRZ015951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 9 Jan 2007 15:41:29 +0100 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l09EfIWg008275; Tue, 9 Jan 2007 08:41:18 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 08:41:18 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 15:41:16 +0100 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" Subject: RE: [nmrg] 22nd NMRG meeting in Prague in March 2007 Date: Tue, 9 Jan 2007 15:37:18 +0100 Message-ID: In-Reply-To: <20070109094224.GA4333@boskop.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] 22nd NMRG meeting in Prague in March 2007 Thread-Index: Accz0xa0MEqa7uXPRNuHu8vfaXeogAAKGYHQ From: "Wijnen, Bert \(Bert\)" To: , X-OriginalArrivalTime: 09 Jan 2007 14:41:16.0182 (UTC) FILETIME=[37A71360:01C733FC] X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-IBRFilter-SpamReport: -1.951 () BAYES_20 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l09EfNRZ015951 X-Mailman-Approved-At: Tue, 09 Jan 2007 16:51:51 +0100 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 14:41:35 -0000 > a) Do you support an NMRG meeting in Prague? > yes > b) Do you plan to attend an NMRG in Prague? > not 100% sure. In principle yes... but It will be the 3rd weekend that I am not home if I cannot catch a plane on Friday eve 23rd. > c) Do you have any research results you like to present during an NMRG > meeting in Prague? > no Bert Received: from hermes.iu-bremen.de (hermes.iu-bremen.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l099gWNX018104 for ; Tue, 9 Jan 2007 10:42:37 +0100 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0589357A0A for ; Tue, 9 Jan 2007 10:42:32 +0100 (CET) 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 16403-02; Tue, 9 Jan 2007 10:42:28 +0100 (CET) Received: from boskop.local (unknown [10.222.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id CD8DE5627F; Tue, 9 Jan 2007 10:42:26 +0100 (CET) Received: by boskop.local (Postfix, from userid 501) id 0E250961AE0; Tue, 9 Jan 2007 10:42:24 +0100 (CET) Date: Tue, 9 Jan 2007 10:42:24 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20070109094224.GA4333@boskop.local> Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at iu-bremen.de X-IBRFilter-SpamReport: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] 22nd NMRG meeting in Prague in March 2007 X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2007 09:42:39 -0000 Hi, I hope you all had a good transition into 2007. As most of us are getting back into "office mode", I like to foster some discussion on the next NMRG meeting. Dan Romascanu (IETF OPS area director) is organizing two sessions during the 68. IETF meeting, which will take place in Prague March 18-23, in order to solicit ideas and proposals for work the IETF should consider in the network management space. The NMRG should of course provide input to these sessions. To complement Dan's efforts, I propose to hold an NMRG meeting on Friday March 23, either just during the afternoon or the full day. Note that the Prague meeting may be an excellent place to present research ideas that you believe should lead not just to some nice papers but impact the world. Since people start to make travel plans for Prague, I like to solicit your feedback on the following three questions: a) Do you support an NMRG meeting in Prague? b) Do you plan to attend an NMRG in Prague? c) Do you have any research results you like to present during an NMRG meeting in Prague? It would be nice to receive your feedback by the end of this week. /js -- Juergen Schoenwaelder {International|Jacobs} University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l038gk1u001338 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 3 Jan 2007 09:42:52 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l038gi3l007676 for ; Wed, 3 Jan 2007 03:42:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from 300216erh2.post.avaya.com ([198.152.7.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 19 Dec 2006 09:54:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by 300216erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ9sjjv007652 for ; Tue, 19 Dec 2006 02:54:46 -0700 Received: from nj300815-nj-iereast.avaya.com (h198-152-12-104.avaya.com [198.152.12.104]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7WCMs013530 for ; Tue, 19 Dec 2006 02:54:47 -0500 Received: from bierator.ibr.cs.tu-bs.de ([134.169.34.9]) by nj300815-nj-iereast.avaya.com with ESMTP; 19 Dec 2006 02:53:32 -0500 Received: from bierator.ibr.cs.tu-bs.de (list@localhost [127.0.0.1]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJ7s3F0016453; Tue, 19 Dec 2006 08:54:08 +0100 Received: from nj300815-ier2.net.avaya.com (nj300815-ier2.net.avaya.com [198.152.12.103]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kBJ7rsAG016433 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Tue, 19 Dec 2006 08:54:00 +0100 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBJ7rqKT024301 for ; Tue, 19 Dec 2006 02:53:53 -0500 Received: from 300815erh2.post.avaya.com ([198.152.6.49]) by IS0004AVEXU1.global.avaya.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 18 Dec 2006 21:32:37 +0200 Received: from co300216-ier2.net.avaya.com (co300216-ier2.net.avaya.com [198.152.13.103]) by 300815erh2.post.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJWa1g000326 for ; Mon, 18 Dec 2006 14:32:36 -0500 Received: from co300216-co-ierwest.avaya.com (h198-152-13-104.avaya.com [198.152.13.104]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJRLYO001667 for ; Mon, 18 Dec 2006 14:32:30 -0500 Received: from lists.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by co300216-co-ierwest.avaya.com with ESMTP; 18 Dec 2006 14:31:38 -0500 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCk-00055A-Iu; Mon, 18 Dec 2006 14:31:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOCj-00054X-Hm; Mon, 18 Dec 2006 14:31:17 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwOCh-0001Sr-2S; Mon, 18 Dec 2006 14:31:17 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBIJVBEC009649; Mon, 18 Dec 2006 14:31:14 -0500 content-class: urn:content-classes:message Date: Wed, 3 Jan 2007 10:42:43 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OPS Area BOFs in Prague Thread-Index: AcccV6ii14zulLX7R3CFlQvi3jCmlA== From: "Romascanu, Dan \(Dan\)" To: , , "MIB Doctors" , , "DNS Directorate" X-Scanner: InterScan AntiVirus for Sendmail X-IBRFilter-SpamReport: 1 (*) BAYES_60 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id l038gk1u001338 Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] OPS Area BOFs in Prague X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2007 08:42:59 -0000 Happy New Year! This is a final reminder that we shall schedule for the Prague IETF a number of BOFs or mini-BOFs in the OPS area meeting slots with the intention to bring to attention new ideas in the operations and management area and discuss which of those are worth becoming subject for future standardization, research or prototyping work. We (David and Dan) will be meeting by the end of the month to discuss the proposed BOF subjects, please send your proposals as soon as you can, but not later than January 24. Any of the lists in the area would do, but ops-area@ietf.org would probably be the best. Note that if you intent to ask for a separate and dedicated BOF session rather than for a mini-BOF in the OPS area meeting slots the deadline for submitting a BOF request is January 15. David and Dan