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 m1TCtWmH026947 for ; Fri, 29 Feb 2008 13:55:37 +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 m1TCtPCw006774; Fri, 29 Feb 2008 13:55:25 +0100 (MET) Received: from ifidyn169.ifi.unizh.ch (ifidyn169.ifi.unizh.ch [130.60.155.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leeuwarden.cs.utwente.nl (Postfix) with ESMTP id 0EC1137C801; Fri, 29 Feb 2008 13:57:25 +0100 (CET) Message-ID: <47C800BC.7080801@utwente.nl> Date: Fri, 29 Feb 2008 13:55:24 +0100 From: Aiko Pras User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] meeting at the upcoming ietf 71 References: <20080123175957.GA13637@elstar.local> In-Reply-To: <20080123175957.GA13637@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 () 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]); Fri, 29 Feb 2008 13:55:32 +0100 (MET) X-IBRFilter-SpamReport: -1.951 () BAYES_20 Cc: Lisandro Zambenedetti Granville , Juergen Schoenwaelder , Georgios Karagiannis 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: Fri, 29 Feb 2008 12:55:45 -0000 Hi I would appreciate if you could put on the agenda for the Philadelphia IETF an item on network management research classification. This classification is under development within the Emanics NoE, and it would be great if we can have 10 minutes for a short presentation and possible feedback. Georgios will be able to give that presentation. Bye Aiko Juergen Schoenwaelder wrote: > Hi, > > I am wondering what the interest is here to schedule a meeting at the > upcoming IETF, say on Friday morning. > > A possible topics is a detailed review and discussion of the SNMP > analysis definitions document - assuming I can get Gijs who is a main > contributor to travel to Philadelphia. It would be very nice to get > technical feedback on the document (please be reminded that I posted a > poll whether this should become an NMRG work item on January 15th). > > http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-00.txt > > Another possible agenda item could be the presentation of a > classification system for research work in the network and service > management area that some people have put together by doing an > analysis of information recorded in conference paper reviewing > systems. > > There might be other issues to discuss - feel free to propose topics > that should be on a possible agenda. > > /js > Received: from jake.unipi.it (jake.unipi.it [131.114.21.22]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1SJjlT3031155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 28 Feb 2008 20:45:53 +0100 Received: from Luca-Deris-iMac.homenet.telecomitalia.it (host156-55-dynamic.9-79-r.retail.telecomitalia.it [79.9.55.156]) (authenticated bits=0) by jake.unipi.it (8.13.5/8.12.10) with ESMTP id m1SJjHGp032093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2008 20:45:22 +0100 From: Luca Deri To: Bert Wijnen - IETF In-Reply-To: Subject: Re: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps X-Priority: 3 (Normal) References: Message-Id: <6744DE01-AF9D-4456-943C-A95F11790B58@ntop.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 28 Feb 2008 20:45:12 +0100 X-Mailer: Apple Mail (2.919.2) X-Spam-Status: No, score=4.0 required=5.0 tests=FORGED_RCVD_HELO, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on jake.unipi.it X-IBRFilter-SpamReport: -1.096 () BAYES_40 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: Nmrg 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: Thu, 28 Feb 2008 19:45:54 -0000 Bert, in his email Juergen has explained why he made some design choices. I'm happy with them, hence for me the document is ready for publication. Regards Luca On Feb 27, 2008, at 6:05 PM, Bert Wijnen - IETF wrote: > Luca, > > Juergen has answered you comments as per > http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001270.html > I think the new document is ready for publication now. > > If you want to recheck, pls do so before March 13 2008. > > Bert Wijnen > Document shepherd Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1S949lm027924 for ; Thu, 28 Feb 2008 10:04:14 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C30F8A710 for ; Thu, 28 Feb 2008 10:04:09 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29257-03-44 for ; Thu, 28 Feb 2008 10:04:02 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D0038A6E5 for ; Thu, 28 Feb 2008 10:02:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5EABC4D4B37; Thu, 28 Feb 2008 10:02:53 +0100 (CET) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Thu, 28 Feb 2008 10:02:53 +0100 Resent-Message-ID: <20080228090253.GA7635@elstar.local> Resent-To: nmrg@ibr.cs.tu-bs.de Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Wed, 27 Feb 2008 22:02:57 +0100 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id 6A4233F1E7 for ; Wed, 27 Feb 2008 22:02:57 +0100 (CET) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65E8E8A2E6 for ; Wed, 27 Feb 2008 22:02:57 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10228-02 for ; Wed, 27 Feb 2008 22:02:49 +0100 (CET) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C5EF8A49D for ; Wed, 27 Feb 2008 22:02:47 +0100 (CET) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id ubd01Y0030lTkoCA80dS00; Wed, 27 Feb 2008 21:02:19 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id ul2g1Y00A4HwxpC8Q00000; Wed, 27 Feb 2008 21:02:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=9_A2ykmwZIoA:10 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=Jiz0tsSxAAAA:8 a=5jnoVbSEvchYJzOApYAA:9 a=bk6dC9RgH6b5gbj5cgUA:7 a=08g0-W1qRbbnw77wIYnpWjTHzCoA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=Z2S6vQYbBZQA:10 From: "David B Harrington" To: Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps Date: Wed, 27 Feb 2008 16:02:40 -0500 Message-ID: <0a9c01c87984$1787f850$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ach5LADclBcIpi9aQGi9xl7DynLrFQAP0bEwAAYtduA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Status: No, score=-0.147 tagged_above=-100 required=5 tests=[AWL=-1.396, BAYES_00=-2.599, DNS_FROM_RFC_POST=1.708, SARE_SUB_RAND_LETTRS4=0.799, WEIRD_QUOTING=1.341] X-Spam-Score: -0.147 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 2.001 (**) BAYES_50,WEIRD_QUOTING 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: Thu, 28 Feb 2008 09:04:20 -0000 trying again. -----Original Message----- From: David B Harrington [mailto:dbharrington@comcast.net] Sent: Wednesday, February 27, 2008 3:26 PM To: 'Bert Wijnen - IETF'; nmrg@ibr.cs.tu-bs.de Cc: 'Dan Romascanu'; j.schoenwaelder@jacobs-university.de Subject: RE: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps Hi, I have reviewed -03-. I (naturally) have a few comments. Hopefully, they are all editorial only. 1. The statement that this is the work of the NMRG is repeated unnecessarily in the abstract and introduction. It might actually be better in the acknowledgements. s/loosing/losing/ s/It should be noted that//g - it is noted, and therefore doesn't need to say it should be noted. s/In addition, //g - this is overused. s/In situation /In situations / Assuming this document is generated using xml2rfc, I recommend using the compact option to reduce the blank lines generated between sections. I notice that the XSDMI XSD for object identifier differs from your XSD: XSDMI: measure: oid.type = xsd:string { pattern = """[0-2](\.[0-9]+)+""" } Should these patterns be similar? or doesn't it matter? Or is this a difference in regexp between XSD and relaxNG? I notice the ipv4address pattern differs as well: XSDMI: measure: ipv4address.type = xsd:string { pattern = """[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*""" } is this difference significant? in the CSV format, item 13 1., the text has been changed to refer to a single object name, but then it says names are separated by commas. I found this a bit confusing. s/An IPv4 addesses is/An IPv4 address is/ "In case of an exception, the object value is an empty string." Does this mean it shows up as ,, or ,"",? In the third paragraph of security considerations, a sentence starts "When using anonymization, values should only be added when". I found this a little hard to parse; I thought you were talking about creating some new value and adding it to anonymization (which made no sense to me), when you were really talking about keeping or not keeping a value extracted from the input. I recommend "When using anonymization, values should only be kept when" or something similar. As an editor, I'm curious. For normative and informational references, you used symbolic identifiers, but changed to numeric identifiers for the URI section. Any particular reason for changing the style? Are the URIs informative or normative? Are there guidelines for listing URIs in an I-D? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Bert Wijnen - IETF > Sent: Tuesday, February 26, 2008 11:58 AM > To: nmrg@ibr.cs.tu-bs.de > Cc: Dan Romascanu; j.schoenwaelder@jacobs-university.de > Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps > > Dear NMRG participants, > > This document has been out for 2 weeks now. > I have not seen anyone speak up that the document does > not address the comments we had received. Basically I (as the > document shepherd) am now assuming that the comments have > indeed been addressed. A list of commenters (with pointers > to their actual comments) can be found here: > > http://www3.tools.ietf.org/group/irtf/trac/ticket/9 > > So you can all check if you want. > > The document does request an assignment in the IETF XML > registry (RFC3688), > and such a registration requires IETF consensus (sect 3.1 of RFC3688). > So the IESG has issued an IETF Last Call for that on feb 14 2008. That > Last Call ends on March 13, 2008. > > So we have approx 2 more weeks before the document will go onto the > IESG agenda and before any other action happens (or so I think). > If anyone still finds anything to be an issue, pls speak up > rather sooner than later, but certainly BEFORE March 13, 2008. > > Bert Wijnen > document shepherd > > > -----Oorspronkelijk bericht----- > > Van: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > > Verzonden: dinsdag 12 februari 2008 22:02 > > Aan: Dan Romascanu; Bert Wijnen > > CC: nmrg@ibr.cs.tu-bs.de > > Onderwerp: draft-irtf-nmrg-snmp-measure-03.txt - next steps > > > > > > Hi, > > > > I have posted which > incorporates > > changes to address David Harrington's last call comments and to put > > into place the correct boilerplate to allocate a proper URN for the > > XML namespace. > > > > I believe this version addresses all concerns and so I would like to > > ask Dan to start the IETF wide last call on the XML namespace URN > > allocation and Bert to pick up the document and move it > along the IRTF > > publication procedure. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > -- > !! 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 hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1S9497S027927 for ; Thu, 28 Feb 2008 10:04:14 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFEAF8A6E5 for ; Thu, 28 Feb 2008 10:04:09 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29163-05-41 for ; Thu, 28 Feb 2008 10:04:04 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E2B68A730 for ; Thu, 28 Feb 2008 10:02:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 048DB4D4B42; Thu, 28 Feb 2008 10:02:59 +0100 (CET) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Thu, 28 Feb 2008 10:02:58 +0100 Resent-Message-ID: <20080228090258.GB7635@elstar.local> Resent-To: nmrg@ibr.cs.tu-bs.de Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Thu, 28 Feb 2008 02:03:38 +0100 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id C7EBA12738 for ; Thu, 28 Feb 2008 02:03:38 +0100 (CET) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3F048A668 for ; Thu, 28 Feb 2008 02:03:38 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 28805-04; Thu, 28 Feb 2008 02:03:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1D1C8A62E; Thu, 28 Feb 2008 02:03:33 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 85A944D4619; Thu, 28 Feb 2008 02:03:32 +0100 (CET) Date: Thu, 28 Feb 2008 02:03:32 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps Message-ID: <20080228010332.GA7122@elstar.local> References: <0a9c01c87984$1787f850$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a9c01c87984$1787f850$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Status: No, score=-3.319 tagged_above=-100 required=5 tests=[ALL_TRUSTED=-1.8, AWL=-1.060, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, WEIRD_QUOTING=1.341] X-Spam-Score: -3.319 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 2.001 (**) BAYES_50,WEIRD_QUOTING 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 Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 09:04:18 -0000 On Wed, Feb 27, 2008 at 04:02:40PM -0500, David B Harrington wrote: > I have reviewed -03-. I (naturally) have a few comments. Hopefully, > they are all editorial only. > > 1. The statement that this is the work of the NMRG is repeated > unnecessarily in the abstract and introduction. It might actually be > better in the acknowledgements. There are new boilerplates for IRTF publications and I am just trying to be a brave soul. ;-) > s/loosing/losing/ > s/It should be noted that//g - it is noted, and therefore doesn't need > to say it should be noted. > s/In addition, //g - this is overused. > s/In situation /In situations / Editorial fixes - no problem. > Assuming this document is generated using xml2rfc, I recommend using > the compact option to reduce the blank lines generated between > sections. OK > I notice that the XSDMI XSD for object identifier differs from your > XSD: > XSDMI: > > > "[0-2](\.[1-3]?[0-9])(\.(0|([1-9]\d*))){0,126}"/> > > > measure: > oid.type = > xsd:string { > pattern = > """[0-2](\.[0-9]+)+""" > } > Should these patterns be similar? or doesn't it matter? > Or is this a difference in regexp between XSD and relaxNG? The XSDMI is more precise or restrictive. I am fine with adopting the XSDMI version. > I notice the ipv4address pattern differs as well: > XSDMI: > > > > "((0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)\.){3} > (0|1[0-9]{0,2}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[3-9][0-9]?)"/> > > > measure: > ipv4address.type = > xsd:string { > pattern = > """[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*""" > } > is this difference significant? Significant? I don't know. The XSDMI pattern is more precise but on the other hand it does not fit on an RFC line and hence the pattern is actually broken until someone fixes it by removing the white space. But since we have the same line length problem with the IPv6 pattern, I am fine with adopting the XSDMI version. > in the CSV format, item 13 1., the text has been changed to refer to a > single object name, but then it says names are separated by commas. I > found this a bit confusing. I suggest to remove the second sentence since it is not needed. > s/An IPv4 addesses is/An IPv4 address is/ Editorial. > "In case of an exception, the object value is an empty string." Does > this mean it shows up as ,, or ,"",? It is perhaps better to say: In case of an exception, the object value is empty. > In the third paragraph of security considerations, a sentence starts > "When using anonymization, values should only be added when". I found > this a little hard to parse; I thought you were talking about creating > some new value and adding it to anonymization (which made no sense to > me), when you were really talking about keeping or not keeping a value > extracted from the input. I recommend "When using anonymization, > values should only be kept when" or something similar. Yes, kept is better than added. > As an editor, I'm curious. For normative and informational references, > you used symbolic identifiers, but changed to numeric identifiers for > the URI section. Any particular reason for changing the style? I use whatever xml2rfc spits out. > Are the URIs informative or normative? It is relatively obvious that all listed URIs are informative. > Are there guidelines for listing URIs in an I-D? I am sure someone will write such guidelines if they have not been written yet. I hope, however, that this does not stop this document. Just in case you write in your response that the header above the URIs should be changed to "Informative URIs", let me tell you that I have no clue how to do that in xml2rfc since the header is generated automagically. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1RKaWg2016681 for ; Wed, 27 Feb 2008 21:36:38 +0100 Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 99C62399B9B; Wed, 27 Feb 2008 12:36:28 -0800 (PST) DKIM-Signature: v=0.5; a=rsa-sha1; c=relaxed; d=hardakers.net; h=received:from:to:cc:subject:organization:references:date:in-reply-to:message-id:user-agent:mime-version:content-type; q=dns/txt; s=wesmail; bh=HRBuud7B4cXYnTD7tWj7eMreV/M=; b=F1tQIEkVfgc9mFG6bbglGdiHGxPqUKEKGZmPIkx/ZGW83yPg6q1SH5IJynfjECAjtnsNRypnChBZ1tLL1qwInqKQnuqfBKIu6Ty9IpgxlA4eXPDhHpGwFXDPNAXTzIBTAjzgNDl0vl+nRV0aV+PKoWRfeubBqeTWpkT2B82FIJw= Received: by wes.hardakers.net (Postfix, from userid 274) id DE768399BDF; Wed, 27 Feb 2008 12:36:27 -0800 (PST) From: Wes Hardaker To: "Bert Wijnen - IETF" Organization: Sparta References: Date: Wed, 27 Feb 2008 12:36:26 -0800 In-Reply-To: (Bert Wijnen's message of "Wed, 27 Feb 2008 17:44:49 +0100") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) XEmacs/21.4.20 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: Nmrg Subject: [nmrg] Re: FW: nmrgdraft-irtf-nmrg-snmp-measure-03.txt - next steps 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, 27 Feb 2008 20:36:41 -0000 >>>>> "BW" == Bert Wijnen <- IETF" > writes: BW> Wes, you commented as documented here BW> http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-February/001198.html BW> I think this doc is now OK. BW> But if you want to re-check, pls do so before Matrch 13th. Thanks. I expect to have the time to do so before the 13th. -- Wes Hardaker Sparta, Inc. Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1RH57Yo021682 for ; Wed, 27 Feb 2008 18:05:12 +0100 Received: (qmail 95804 invoked from network); 27 Feb 2008 17:05:07 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Feb 2008 17:05:07 -0000 From: "Bert Wijnen - IETF" To: "David Perkins" Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps Date: Wed, 27 Feb 2008 18:05:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Thu, 28 Feb 2008 10:02:28 +0100 Cc: Nmrg 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, 27 Feb 2008 17:05:16 -0000 David, Juergen has answered to your comments in december http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001268.html and I think the new rev of the document is OK to go out as RFC. If you want to re-check, pls do so before 13 March 2008 Bert Wijnen document shepherd Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1RH58B0021686 for ; Wed, 27 Feb 2008 18:05:13 +0100 Received: (qmail 95814 invoked from network); 27 Feb 2008 17:05:07 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Feb 2008 17:05:07 -0000 From: "Bert Wijnen - IETF" To: Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps Date: Wed, 27 Feb 2008 18:05:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Thu, 28 Feb 2008 10:02:15 +0100 Cc: Nmrg 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, 27 Feb 2008 17:05:15 -0000 Luca, Juergen has answered you comments as per http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001270.html I think the new document is ready for publication now. If you want to recheck, pls do so before March 13 2008. Bert Wijnen Document shepherd Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1RH57pm021684 for ; Wed, 27 Feb 2008 18:05:13 +0100 Received: (qmail 95807 invoked from network); 27 Feb 2008 17:05:07 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Feb 2008 17:05:07 -0000 From: "Bert Wijnen - IETF" To: Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps Date: Wed, 27 Feb 2008 18:05:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Thu, 28 Feb 2008 10:02:22 +0100 Cc: Nmrg 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, 27 Feb 2008 17:05:15 -0000 Medhi, Juergen has answered your comments as per http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-December/001269.html I think the new document is ready for publication now. If you do want to recheck, pls do so before Match 13 2008 Bert Wijnen document shepherd Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1RGinos018495 for ; Wed, 27 Feb 2008 17:44:54 +0100 Received: (qmail 79713 invoked from network); 27 Feb 2008 16:44:48 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 27 Feb 2008 16:44:48 -0000 From: "Bert Wijnen - IETF" To: "Wes Hardaker" Subject: FW: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps Date: Wed, 27 Feb 2008 17:44:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Thu, 28 Feb 2008 10:02:04 +0100 Cc: Nmrg 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, 27 Feb 2008 16:44:56 -0000 Wes, you commented as documented here http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-February/001198.html I think this doc is now OK. But if you want to re-check, pls do so before Matrch 13th. Bert Wijnen document shepherd Received: from arlet.ibr.cs.tu-bs.de (arlet.ibr.cs.tu-bs.de [IPv6:2001:638:602:2200:216:cbff:fe8d:26ba]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1R8S4Kc031817; Wed, 27 Feb 2008 09:28:04 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: Bert Wijnen - IETF In-Reply-To: X-Priority: 3 (Normal) References: Message-Id: <30A84A78-9C60-4309-9FAD-215FF0FF84F8@ibr.cs.tu-bs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 27 Feb 2008 09:28:04 +0100 X-Mailer: Apple Mail (2.919.2) X-IBRFilter-SpamReport: -4.396 () ALL_TRUSTED,BAYES_40 X-Scanned-By: MIMEDefang 2.51 on IPv6:2001:638:602:2200:20d:60ff:fe9a:2b5c Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by bierator.ibr.cs.tu-bs.de id m1R8S4Kc031817 Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] Re: draft-irtf-nmrg-snmp-measure-03.txt - next steps 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, 27 Feb 2008 08:28:06 -0000 Hi Bert, Am 26.02.2008 um 18:04 schrieb Bert Wijnen - IETF: > Frank, I believe most of you rcomments have been addressed > and/or answered. As document shepherd I want to pass the > doc on to the IRSG for approval. Can you check and let is > know if you are OK with the document now, BEFORE mar 13? > > Your comemnts are/were recorded here: > http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001194.html I'm sorry that I did not response in December when Jürgen revised the document with respect to my comments. He sent me a detailed response upon my initial input. I've been completely fine with the changes and arguments against my comments. So, regarding my point of view: Move the document forward! -frank Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1QH4nBc022843 for ; Tue, 26 Feb 2008 18:04:54 +0100 Received: (qmail 69400 invoked from network); 26 Feb 2008 17:04:49 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 26 Feb 2008 17:04:49 -0000 From: "Bert Wijnen - IETF" To: "Frank Strauss" Date: Tue, 26 Feb 2008 18:04:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 1 (*) BAYES_60 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Wed, 27 Feb 2008 11:31:37 +0100 Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps 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, 26 Feb 2008 17:04:55 -0000 Frank, I believe most of you rcomments have been addressed and/or answered. As document shepherd I want to pass the doc on to the IRSG for approval. Can you check and let is know if you are OK with the document now, BEFORE mar 13? Your comemnts are/were recorded here: http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001194.html Bert Wijnen Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1QH4nXi022847 for ; Tue, 26 Feb 2008 18:04:54 +0100 Received: (qmail 69406 invoked from network); 26 Feb 2008 17:04:49 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 26 Feb 2008 17:04:49 -0000 From: "Bert Wijnen - IETF" To: Date: Tue, 26 Feb 2008 18:04:52 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20080212210213.GA16118@elstar.local> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Wed, 27 Feb 2008 11:31:45 +0100 Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps 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, 26 Feb 2008 17:04:56 -0000 Giogio, I hope the new revision of the document is OK. Your earlier comments were recorded here: http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-February/001196.html Your comments may not have been resolved exactly as you prefered, but hopefully they have been answered and addressed such that the documnt is now good enough for publication. Bert Wijnen document shepherd Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1QGwSIK021847 for ; Tue, 26 Feb 2008 17:58:33 +0100 Received: (qmail 65236 invoked from network); 26 Feb 2008 16:58:25 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 26 Feb 2008 16:58:25 -0000 From: "Bert Wijnen - IETF" To: Date: Tue, 26 Feb 2008 17:58:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20080212210213.GA16118@elstar.local> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Wed, 27 Feb 2008 11:31:54 +0100 Cc: Dan Romascanu , j.schoenwaelder@jacobs-university.de Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps 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, 26 Feb 2008 16:58:39 -0000 Dear NMRG participants, This document has been out for 2 weeks now. I have not seen anyone speak up that the document does not address the comments we had received. Basically I (as the document shepherd) am now assuming that the comments have indeed been addressed. A list of commenters (with pointers to their actual comments) can be found here: http://www3.tools.ietf.org/group/irtf/trac/ticket/9 So you can all check if you want. The document does request an assignment in the IETF XML registry (RFC3688), and such a registration requires IETF consensus (sect 3.1 of RFC3688). So the IESG has issued an IETF Last Call for that on feb 14 2008. That Last Call ends on March 13, 2008. So we have approx 2 more weeks before the document will go onto the IESG agenda and before any other action happens (or so I think). If anyone still finds anything to be an issue, pls speak up rather sooner than later, but certainly BEFORE March 13, 2008. Bert Wijnen document shepherd > -----Oorspronkelijk bericht----- > Van: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Verzonden: dinsdag 12 februari 2008 22:02 > Aan: Dan Romascanu; Bert Wijnen > CC: nmrg@ibr.cs.tu-bs.de > Onderwerp: draft-irtf-nmrg-snmp-measure-03.txt - next steps > > > Hi, > > I have posted which incorporates > changes to address David Harrington's last call comments and to put > into place the correct boilerplate to allocate a proper URN for the > XML namespace. > > I believe this version addresses all concerns and so I would like to > ask Dan to start the IETF wide last call on the XML namespace URN > allocation and Bert to pick up the document and move it along the IRTF > publication procedure. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with SMTP id m1QGwS5Y021848 for ; Tue, 26 Feb 2008 17:58:33 +0100 Received: (qmail 65247 invoked from network); 26 Feb 2008 16:58:26 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 26 Feb 2008 16:58:26 -0000 From: "Bert Wijnen - IETF" To: Date: Tue, 26 Feb 2008 17:58:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20080212210213.GA16118@elstar.local> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 X-Mailman-Approved-At: Wed, 27 Feb 2008 11:31:21 +0100 Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] RE: draft-irtf-nmrg-snmp-measure-03.txt - next steps 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, 26 Feb 2008 16:58:36 -0000 For the record, My comments (to revision 1) as stated at http://mail.ibr.cs.tu-bs.de/pipermail/nmrg/2007-January/001187.html have been adequately addressed. Thanks Bert Wijnen Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1Q7hbpr031360 for ; Tue, 26 Feb 2008 08:43:42 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A98A8A271 for ; Tue, 26 Feb 2008 08:43:37 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 11098-06; Tue, 26 Feb 2008 08:43:32 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 791AA8A2E4; Tue, 26 Feb 2008 08:43:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6805D4CFCF1; Tue, 26 Feb 2008 08:43:31 +0100 (CET) Date: Tue, 26 Feb 2008 08:43:31 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20080226074331.GA1448@elstar.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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] nmrg meeting at the ietf in philadelphia X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 07:43:46 -0000 Hi, I requested an NMRG meeting slot and we initially got scheduling conflicts with the NETCONF data modeling BOF. This scheduling conflict has now been resolved and the meeting is now scheduled for Friday morning, that is 2008-03-14 in the time 09:00-11:30. The main agenda item will be the revised version of the SNMP trace analysis definitions document: http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-01.txt Gijs will attend the meeting and go through the definitions. The idea is to get feedback where there might be problems and to decide whether there is enough interest to make this document an NMRG work item (which essentially means enough people committing to actively review the document as it moves forward and to last call). During the week, there will also be an IAB review of the NMRG, a procedure every RG goes through periodically. I plan to report about it on Friday; I am also soliciting input you might have for the meeting. If you have requests for the agenda, e.g. suggestions for new work items, please let me know as soon as possible. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1P7kXin000785 for ; Mon, 25 Feb 2008 08:46:38 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFA228A383 for ; Mon, 25 Feb 2008 08:46:32 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03021-08 for ; Mon, 25 Feb 2008 08:46:32 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 782588A56F for ; Mon, 25 Feb 2008 08:46:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E9E194CDAB0; Mon, 25 Feb 2008 08:46:30 +0100 (CET) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Mon, 25 Feb 2008 08:46:30 +0100 Resent-Message-ID: <20080225074630.GA8348@elstar.local> Resent-To: nmrg@ibr.cs.tu-bs.de Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Mon, 25 Feb 2008 08:45:57 +0100 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id A5EF9412C7 for ; Mon, 25 Feb 2008 08:45:57 +0100 (CET) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A05008A56F for ; Mon, 25 Feb 2008 08:45:57 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 03418-01-2 for ; Mon, 25 Feb 2008 08:45:51 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F0B78A271 for ; Mon, 25 Feb 2008 08:45:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2797528C4A0; Sun, 24 Feb 2008 23:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikjlz5Vnwcyx; Sun, 24 Feb 2008 23:45:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7A628C1B3; Sun, 24 Feb 2008 23:45:14 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 29D123A67F4; Sun, 24 Feb 2008 23:45:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080225074502.29D123A67F4@core3.amsl.com> Date: Sun, 24 Feb 2008 23:45:02 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Status: No, score=-0.513 tagged_above=-100 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, DNS_FROM_RFC_POST=1.708, NO_REAL_NAME=0.961] X-Spam-Score: -0.513 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.008 () BAYES_50,MIME_BOUND_NEXTPART,NO_REAL_NAME X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] I-D Action:draft-schoenw-nmrg-snmp-trace-definitions-01.txt X-BeenThere: nmrg@ibr.cs.tu-bs.de Reply-To: internet-drafts@ietf.org List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 07:46:39 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SNMP Trace Analysis Definitions Author(s) : U. Twente, et al. Filename : draft-schoenw-nmrg-snmp-trace-definitions-01.txt Pages : 27 Date : 2008-02-24 The Network Management Research Group (NMRG) started an activity to collect traces of the Simple Network Management Protocol (SNMP) from operational networks. To analyze these traces, it is necessary to split potentially large traces into more manageable pieces that make it easier to deal with large data sets and simplify the analysis of the data. This document provides some common definitions that have been found useful for implementing tools to support trace analysis. This document mainly serves as a reference for the definitions underlying these tools and it is not meant to explain all the motivation and reasoning behind the definitions. Some of this background information can be found in other research papers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-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-schoenw-nmrg-snmp-trace-definitions-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-schoenw-nmrg-snmp-trace-definitions-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-24234009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-schoenw-nmrg-snmp-trace-definitions-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-schoenw-nmrg-snmp-trace-definitions-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-24234009.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce --NextPart-- Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1EFs6E6001349 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 14 Feb 2008 16:54:16 +0100 X-IronPort-AV: E=Sophos;i="4.25,352,1199682000"; d="scan'208";a="99504519" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 14 Feb 2008 10:54:00 -0500 X-IronPort-AV: E=Sophos;i="4.25,352,1199682000"; d="scan'208";a="162531917" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Feb 2008 10:53:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Feb 2008 16:53:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-irtf-nmrg-snmp-measure (SNMP Traffic Measurements and Trace Exchange Formats) to Informational RFC Thread-Index: AchvIRTpm8lkOBhMT7m2X+kfNIL0tAAAKZWg From: "Romascanu, Dan (Dan)" 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 m1EFs6E6001349 Subject: [nmrg] FW: Last Call: draft-irtf-nmrg-snmp-measure (SNMP Traffic Measurements and Trace Exchange Formats) to 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: Thu, 14 Feb 2008 15:54:21 -0000 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Thursday, February 14, 2008 5:43 PM To: IETF-Announce Subject: Last Call: draft-irtf-nmrg-snmp-measure (SNMP Traffic Measurements and Trace Exchange Formats) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'SNMP Traffic Measurements and Trace Exchange Formats ' as an Informational RFC This document which is the work of the Network Management Reseach Group (NMRG) of the IRTF requests that IANA register a URI for the SNMP XML trace format namespace in the IETF XML registry [RFC3688]. The IESG plans to make a decision about this registration request in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-03-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= 14654&rfc_flag=0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org http://www.ietf.org/mailman/listinfo/ietf-announce Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1CLW2nO027107 for ; Tue, 12 Feb 2008 22:32:08 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC49A8AAA4; Tue, 12 Feb 2008 22:02:27 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 07401-07-4; Tue, 12 Feb 2008 22:02:23 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07D318A71C; Tue, 12 Feb 2008 22:02:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E65BA4AED2E; Tue, 12 Feb 2008 22:02:13 +0100 (CET) Date: Tue, 12 Feb 2008 22:02:13 +0100 From: Juergen Schoenwaelder To: Dan Romascanu , Bert Wijnen Message-ID: <20080212210213.GA16118@elstar.local> Mail-Followup-To: Dan Romascanu , Bert Wijnen , 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.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] draft-irtf-nmrg-snmp-measure-03.txt - next steps X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2008 21:32:33 -0000 Hi, I have posted which incorporates changes to address David Harrington's last call comments and to put into place the correct boilerplate to allocate a proper URN for the XML namespace. I believe this version addresses all concerns and so I would like to ask Dan to start the IETF wide last call on the XML namespace URN allocation and Bert to pick up the document and move it along the IRTF publication procedure. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1CKcJg9019200 for ; Tue, 12 Feb 2008 21:38:24 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 77D298A268 for ; Tue, 12 Feb 2008 21:38:19 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05853-03 for ; Tue, 12 Feb 2008 21:38:15 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 833548A4C5 for ; Tue, 12 Feb 2008 21:38:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 77E6E4AEB09; Tue, 12 Feb 2008 21:38:14 +0100 (CET) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Tue, 12 Feb 2008 21:38:14 +0100 Resent-Message-ID: <20080212203814.GA15958@elstar.local> Resent-To: nmrg@ibr.cs.tu-bs.de Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Tue, 12 Feb 2008 21:34:19 +0100 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id 561F4385E8 for ; Tue, 12 Feb 2008 21:34:19 +0100 (CET) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5048F8A268 for ; Tue, 12 Feb 2008 21:34:19 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05441-04 for ; Tue, 12 Feb 2008 21:34:14 +0100 (CET) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2CF78A70C for ; Tue, 12 Feb 2008 21:34:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208EE28CC94; Tue, 12 Feb 2008 12:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgtCFj+yxzln; Tue, 12 Feb 2008 12:30:26 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F220528C4DF; Tue, 12 Feb 2008 12:30:03 -0800 (PST) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 66C3B28C463; Tue, 12 Feb 2008 12:30:01 -0800 (PST) Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: <20080212203001.66C3B28C463@core3.amsl.com> Date: Tue, 12 Feb 2008 12:30:01 -0800 (PST) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Status: No, score=-1.229 tagged_above=-100 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, NO_REAL_NAME=0.961, SARE_SUB_RAND_LETTRS4=0.799] X-Spam-Score: -1.229 X-Spam-Level: X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.008 () BAYES_50,MIME_BOUND_NEXTPART,NO_REAL_NAME X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Subject: [nmrg] I-D Action:draft-irtf-nmrg-snmp-measure-03.txt X-BeenThere: nmrg@ibr.cs.tu-bs.de Reply-To: internet-drafts@ietf.org List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2008 20:38:36 -0000 --NextPart 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-03.txt Pages : 30 Date : 2008-02-12 The Simple Network Management Protocol (SNMP) is widely deployed to monitor, control and (sometimes also) 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. This document was produced within the IRTF's Network Management Research Group (NMRG) and represents the consensus of all of the active contributors to this group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-03.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-03.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-03.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2008-02-12121522.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-irtf-nmrg-snmp-measure-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-irtf-nmrg-snmp-measure-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-02-12121522.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org http://www.ietf.org/mailman/listinfo/i-d-announce --NextPart-- Received: from co300216-co-outbound.avaya.com ([198.152.13.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1CGlCoG022307 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Feb 2008 17:47:18 +0100 X-IronPort-AV: E=Sophos;i="4.25,341,1199682000"; d="scan'208";a="105538237" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 12 Feb 2008 11:46:59 -0500 X-IronPort-AV: E=Sophos;i="4.25,341,1199682000"; d="scan'208";a="154178851" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Feb 2008 11:46:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] RE:URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Date: Tue, 12 Feb 2008 17:46:56 +0100 Message-ID: In-Reply-To: <20080212162358.GB15232@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] RE:URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: AchtlhdWGCaoNs0OQq+hGwpKyrpzaAAALrww References: <20080212135316.GA15232@elstar.local> <20080212162358.GB15232@elstar.local> From: "Romascanu, Dan (Dan)" 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 m1CGlCoG022307 Cc: nmrg@ibr.cs.tu-bs.de, Lisa Dusseault 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, 12 Feb 2008 16:47:21 -0000 > -----Original Message----- > From: Juergen Schoenwaelder > > Since the allocation is actually IETF last called via the > IESG, one could argue that the IESG is the registration > contact. But I am happy to put there whatever allows us to > move forward. What about: > > NMRG of the IRTF > > /js > Looks fine to me. Dan Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1CGfDnP021591 for ; Tue, 12 Feb 2008 17:41:18 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 145CC8AE2F; Tue, 12 Feb 2008 17:41:13 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 13101-03-9; Tue, 12 Feb 2008 17:41:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81BC68AE4E; Tue, 12 Feb 2008 17:24:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8379A4AE3F3; Tue, 12 Feb 2008 17:23:58 +0100 (CET) Date: Tue, 12 Feb 2008 17:23:58 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [nmrg] RE: URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg- snmp-measure-02.txt Message-ID: <20080212162358.GB15232@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , nmrg@ibr.cs.tu-bs.de, Lisa Dusseault References: <20080212135316.GA15232@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de, Lisa Dusseault X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2008 16:41:34 -0000 On Tue, Feb 12, 2008 at 03:29:30PM +0100, Romascanu, Dan (Dan) wrote: > This looks fine. > > One question: > > > Registrant Contact: The IESG. > > Why would the IESG figure here as Registrant? > > RFC 3688 says: > > Registrant Contact > The individual/organization that is the registration contact for > the component being registered. Ideally, this will be the name > and pertinent physical and network contact information. In the > case of IETF developed standards, the Registrant will be the IESG. > > In this case it seems that we do not deal with the 'usual' IETF > developped standard and that the IRTF or the NMRG would be the more > appropriate organization to be mentioned. Since the allocation is actually IETF last called via the IESG, one could argue that the IESG is the registration contact. But I am happy to put there whatever allows us to move forward. What about: NMRG of the IRTF /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from nj300815-nj-outbound.avaya.com ([198.152.12.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1CEUALW030916 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Feb 2008 15:30:17 +0100 X-IronPort-AV: E=Sophos;i="4.25,340,1199682000"; d="scan'208";a="99070901" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 12 Feb 2008 09:29:58 -0500 X-IronPort-AV: E=Sophos;i="4.25,340,1199682000"; d="scan'208";a="154108858" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Feb 2008 09:29:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] RE: URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Date: Tue, 12 Feb 2008 15:29:30 +0100 Message-ID: In-Reply-To: <20080212135316.GA15232@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] RE: URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: Achtf7exN3RJqTDUQZuHx5d3rGWf8QAAIzlg References: <20080212135316.GA15232@elstar.local> From: "Romascanu, Dan (Dan)" 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 m1CEUALW030916 Cc: nmrg@ibr.cs.tu-bs.de, Lisa Dusseault 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, 12 Feb 2008 14:30:22 -0000 This looks fine. One question: > Registrant Contact: The IESG. Why would the IESG figure here as Registrant? RFC 3688 says: Registrant Contact The individual/organization that is the registration contact for the component being registered. Ideally, this will be the name and pertinent physical and network contact information. In the case of IETF developed standards, the Registrant will be the IESG. In this case it seems that we do not deal with the 'usual' IETF developped standard and that the IRTF or the NMRG would be the more appropriate organization to be mentioned. Dan > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, February 12, 2008 3:53 PM > To: Romascanu, Dan (Dan) > Cc: nmrg@ibr.cs.tu-bs.de; Lisa Dusseault > Subject: Re: [nmrg] RE: > URNallocationforhttp://www.ietf.org/internet-drafts/draft-irtf > -nmrg-snmp-measure-02.txt > > On Tue, Feb 12, 2008 at 02:36:59PM +0100, Romascanu, Dan (Dan) wrote: > > > Actually, now that I am looking, the I-D needs to be > revised in order > > to make the explicit request to IANA to allocate > > > > urn:ietf:params:xml:ns:snmp-trace-1.0 > > > > according to the procedure described in RFC 3688. If you do > it better > > to write a separate IANA considerations section to make > id-nits happy. > > Here is what is already in my sources: > > 6. IANA Considerations > > This document requests that IANA register a URI for the SNMP XML > trace format namespace in the IETF XML registry [RFC3688]. > Following > the format in RFC 3688, the following registration is requested. > > URI: Please assign the URI "urn:ietf:params:xml:ns:snmp-trace-1.0" > for use by the SNMP trace format. > > Registrant Contact: The IESG. > > XML: N/A, the requested URI is an XML namespace. > > > Also this may be the right opportunity to make the > editorial changes > > suggested by David Harrington. > > I am waiting for David's ack for the proposed edits. Once I > get it, I will post the updated ID and then things are back > in Bert's hands (as the document shepherd) and it should be > fine to last call the URN allocation. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1CE12CD027328 for ; Tue, 12 Feb 2008 15:01:07 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E5898A7CF; Tue, 12 Feb 2008 15:01:02 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 25188-03-17; Tue, 12 Feb 2008 15:00:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2E1078A7D5; Tue, 12 Feb 2008 14:53:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1B23C4AE20B; Tue, 12 Feb 2008 14:53:16 +0100 (CET) Date: Tue, 12 Feb 2008 14:53:16 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Subject: Re: [nmrg] RE: URN allocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snm p-measure-02.txt Message-ID: <20080212135316.GA15232@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , nmrg@ibr.cs.tu-bs.de, Lisa Dusseault References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: -1.951 () BAYES_20 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de, Lisa Dusseault X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2008 14:01:10 -0000 On Tue, Feb 12, 2008 at 02:36:59PM +0100, Romascanu, Dan (Dan) wrote: > Actually, now that I am looking, the I-D needs to be revised in order to > make the explicit request to IANA to allocate > > urn:ietf:params:xml:ns:snmp-trace-1.0 > > according to the procedure described in RFC 3688. If you do it better to > write a separate IANA considerations section to make id-nits happy. Here is what is already in my sources: 6. IANA Considerations This document requests that IANA register a URI for the SNMP XML trace format namespace in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested. URI: Please assign the URI "urn:ietf:params:xml:ns:snmp-trace-1.0" for use by the SNMP trace format. Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. > Also this may be the right opportunity to make the editorial changes > suggested by David Harrington. I am waiting for David's ack for the proposed edits. Once I get it, I will post the updated ID and then things are back in Bert's hands (as the document shepherd) and it should be fine to last call the URN allocation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from co300216-co-outbound.avaya.com ([198.152.13.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1CDbone023116 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 12 Feb 2008 14:37:56 +0100 X-IronPort-AV: E=Sophos;i="4.25,340,1199682000"; d="scan'208";a="105495856" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 12 Feb 2008 08:37:21 -0500 X-IronPort-AV: E=Sophos;i="4.25,340,1199682000"; d="scan'208";a="154083256" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 12 Feb 2008 08:37:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [nmrg] RE: URN allocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Date: Tue, 12 Feb 2008 14:36:59 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nmrg] RE: URN allocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: AchstHO1X8VTu4wFRPKS4KNS+QvQowABXNsQADB8YcA= References: <20080211133950.GB13424@elstar.local> From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , 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 m1CDbone023116 Cc: nmrg@ibr.cs.tu-bs.de, Lisa Dusseault 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, 12 Feb 2008 13:38:03 -0000 Juergen, Actually, now that I am looking, the I-D needs to be revised in order to make the explicit request to IANA to allocate urn:ietf:params:xml:ns:snmp-trace-1.0 according to the procedure described in RFC 3688. If you do it better to write a separate IANA considerations section to make id-nits happy. Also this may be the right opportunity to make the editorial changes suggested by David Harrington. Thanks and Regards, Dan > -----Original Message----- > From: nmrg-bounces@ibr.cs.tu-bs.de > [mailto:nmrg-bounces@ibr.cs.tu-bs.de] On Behalf Of Romascanu, > Dan (Dan) > Sent: Monday, February 11, 2008 4:26 PM > To: j.schoenwaelder@jacobs-university.de > Cc: nmrg@ibr.cs.tu-bs.de; Lisa Dusseault > Subject: [nmrg] RE: URN > allocationforhttp://www.ietf.org/internet-drafts/draft-irtf-nm > rg-snmp-measure-02.txt > > OK, I will push the right buttons in the next 24 hours or so. > > Dan > > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > > So bottom line is that I am happy with an IETF last call > for the URN > > allocation. And thanks for your help and support in this case. > > > > /js > > -- > !! 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. > > This email was protected during delivery to Avaya with TLS encryption > > Received: from de307622-de-outbound.net.avaya.com ([198.152.71.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1BEQmFH024163 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 11 Feb 2008 15:26:53 +0100 X-IronPort-AV: E=Sophos;i="4.25,333,1199682000"; d="scan'208";a="91978297" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Feb 2008 09:26:37 -0500 X-IronPort-AV: E=Sophos;i="4.25,333,1199682000"; d="scan'208";a="153583745" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 11 Feb 2008 09:26:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2008 15:26:10 +0100 Message-ID: In-Reply-To: <20080211133950.GB13424@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URN allocation forhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: AchstHO1X8VTu4wFRPKS4KNS+QvQowABXNsQ References: <20080211133950.GB13424@elstar.local> From: "Romascanu, Dan (Dan)" 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 m1BEQmFH024163 Cc: nmrg@ibr.cs.tu-bs.de, Lisa Dusseault Subject: [nmrg] RE: URN allocation forhttp://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt 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, 11 Feb 2008 14:27:00 -0000 OK, I will push the right buttons in the next 24 hours or so. Dan > -----Original Message----- > From: Juergen Schoenwaelder > So bottom line is that I am happy with an IETF last call for > the URN allocation. And thanks for your help and support in this case. > > /js Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1BDk4Ft019032 for ; Mon, 11 Feb 2008 14:46:09 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88E5C8A62A; Mon, 11 Feb 2008 14:46:04 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24603-03-4; Mon, 11 Feb 2008 14:45:59 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CB358A5A5; Mon, 11 Feb 2008 14:39:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 097BF4AC7A2; Mon, 11 Feb 2008 14:39:51 +0100 (CET) Date: Mon, 11 Feb 2008 14:39:50 +0100 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20080211133950.GB13424@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , nmrg@ibr.cs.tu-bs.de, Lisa Dusseault , Aaron Falk References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de, Lisa Dusseault Subject: [nmrg] Re: URN allocation for http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02. txt X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2008 13:46:11 -0000 On Mon, Feb 11, 2008 at 02:28:16PM +0100, Romascanu, Dan (Dan) wrote: > > Hi Juergen, > > The IESG discussed on the last telechat the issue of URN allocation in > http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt. > > > The minutes of the telechat concluded: > > > Action item: Dan Romascanu to send mail to nmrg/irtf proposing two > > options to move forward: 1. Last Call their document for the specific > > question according to the current RFC 3688 text, or 2. Defining a > > urn:irtf... space for the IRTF to manage. > > Action item: Lisa Dusseault to resolve the ambiguity in registration > > requirements in RFC 3866. > > Please let me know which of options 1 or 2 you prefer. If you chose > option 1 I will sponsor the I-D though the IESG process, and the Last > Call will make clear that the question that is asked is related to the > URN allocation and not to the whole document. If you chose option 2 the > IRTF needs to work with IANA the creation of the urn:irtf space and you > resubmit the I-D with modified IANA considerations asking for an > allocation under urn:irtf. I prefer to get the document out quickly and with the least pain. The problem is that nothing in the IETF process is predictable. Right now, I assume option 1 is the least pain but I know that I have been wrong with these sorts of predictions many times. Whether there is a need for an urn:irtf space is something the whole IRTF concerns and likely not just the NMRG. But since the ambiguity in RFC 3866 does not seem to have been resolved, I think the best for the IRTF is simply to wait. But this is something for Aaron to decide. So bottom line is that I am happy with an IETF last call for the URN allocation. And thanks for your help and support in this case. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m1BDSZ0K015825 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 11 Feb 2008 14:28:42 +0100 X-IronPort-AV: E=Sophos;i="4.25,333,1199682000"; d="scan'208";a="91966452" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Feb 2008 08:28:29 -0500 X-IronPort-AV: E=Sophos;i="4.25,333,1199682000"; d="scan'208";a="153554710" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 11 Feb 2008 08:28:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2008 14:28:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: URN allocation for http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt Thread-Index: AchssfW6N6AVwjE+TNKtUMi+BHLijA== From: "Romascanu, Dan (Dan)" 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 m1BDSZ0K015825 Cc: Lisa Dusseault Subject: [nmrg] URN allocation for http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt 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, 11 Feb 2008 13:28:47 -0000 Hi Juergen, The IESG discussed on the last telechat the issue of URN allocation in http://www.ietf.org/internet-drafts/draft-irtf-nmrg-snmp-measure-02.txt. The minutes of the telechat concluded: > Action item: Dan Romascanu to send mail to nmrg/irtf proposing two > options to move forward: 1. Last Call their document for the specific > question according to the current RFC 3688 text, or 2. Defining a > urn:irtf... space for the IRTF to manage. > Action item: Lisa Dusseault to resolve the ambiguity in registration > requirements in RFC 3866. Please let me know which of options 1 or 2 you prefer. If you chose option 1 I will sponsor the I-D though the IESG process, and the Last Call will make clear that the question that is asked is related to the URN allocation and not to the whole document. If you chose option 2 the IRTF needs to work with IANA the creation of the urn:irtf space and you resubmit the I-D with modified IANA considerations asking for an allocation under urn:irtf. Thanks and Regards, Dan Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by bierator.ibr.cs.tu-bs.de (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id m14EUxKr019105 for ; Mon, 4 Feb 2008 15:31:04 +0100 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id F02E08A2A9; Mon, 4 Feb 2008 15:30:58 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 14504-09-40; Mon, 4 Feb 2008 15:30:50 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E219A8A0EA; Mon, 4 Feb 2008 15:29:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1ABA24A1214; Mon, 4 Feb 2008 15:29:41 +0100 (CET) Date: Mon, 4 Feb 2008 15:29:41 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [nmrg] RE: NMRG Last Call: draft-irtf-nmrg-snmp-measure-02.txt Message-ID: <20080204142941.GB23548@elstar.local> Mail-Followup-To: David B Harrington , nmrg@ibr.cs.tu-bs.de References: <11f301c74f9d$215d2240$0600a8c0@china.huawei.com> <004301c85f98$ca4d9950$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301c85f98$ca4d9950$6502a8c0@china.huawei.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-IBRFilter-SpamReport: 0.001 () BAYES_50 X-Scanned-By: MIMEDefang 2.51 on 134.169.34.9 Cc: nmrg@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 14:31:06 -0000 On Fri, Jan 25, 2008 at 04:25:20PM -0500, David B Harrington wrote: > I have reviewed this document. In my opinion, this document is > well-written, and documents a useful research approach. I recommend > it be published as an RFC. > > Below are some comments that might or might not improve the > document. Many of the comments deal with application-specific > considerations that could impact analysis results, and I feel the > potential impact is not as well documented as it should be. > > s/patterns are in real world/patterns occur in real world/ fixed > s/binding interface/interface/ changed > s/can be store/can be stored/ already fixed > s/an SNMP messages/an SNMP message/ fixed > s/are able convert/are able to convert/ already fixed > s/unneeded/unnecessary/ already changed > "The CSV format only captures the most essential parts ..." > Shouldn't you provide a qualifier for "the most essential"? I would > think "the most essential" depends on what you are trying to do with > the raw data, and that for some purposes, the data not kept might > actually be the most essential. replaced "the most essential" with "selected" since this is more neutral > Storing Traffic Traces stresses keeping the original traces. While > this is certainly important from a researcher's point of view, it > also incresaes the potential for security breach that could expose > sensitive information. I think this emphasis would make it harder > for me to convince operators to run traces and make them > available. I think there is a tradeoff between researcher needs and > operators' security needs, and for an operator, security trumps > research. I think this section should be written to recognize and > contrast both points of view, and to stress that operators should > make the decision about long-term storage of their non-anonymized > traces. There is already new text in place: While this document recommends that raw traces should be kept, it must be noted that there are situations where this may not be feasible. The recommendation to keep raw traces may be ignored for example to comply with data protection laws or to protect a network operator from being forced to provide the data to other organizations. I think this addresses your concerns. > "Due to the availability" - This paragraph "rubs me the wrong way" > by suggesting that everybody use the same language. I think it would > be more effective if presented as "Tool implementers can choose any > language they want. The following tools have been used to do > analysis already, and are freely available for others to build on to > speed development time and consistency with other analysis work." > Let people decide it is in their best interest to build on the > existing framework rather than to start from scratch. But don't > suggest that everybody use the same language. But I do think it is > important to inform the reader of available tools that can be used > to build their own solution so they can try to replicate results of > others, and make repliation of their results easy for others. The language has already been softened - it now says "such as Perl". > I found section 3.1 a little difficult to read. I think it might > benefit from being made a list: > 1) protocol versions used, > 2) operations used, > 3) standardized, proprietary, or experimental data > 4) message size distributions, and > 5) periodicity. > > For the third type of basic statistics, why not use mgmt(2), > experimental(30, private(4), and snmpv2(6) rather than standardized, > proprietary, and experimental? These are well-defined and standard > subtrees for these purposes. You might actually just say "categorize > by subtree" and then give examples. Is this text better: 3.1. Basic Statistics Basic statistics cover things such as o protocol version used, o protocol operations used, o message size distribution, o error message type frequency, or o usage of authentication and encryption mechanisms. In addition, the OID names of the objects manipulated can be categorized into OID subtrees, for example to identify 'standardized', 'proprietary', and 'experimental' objects. > Differentiation at the layer you mention is useful, but within a > proprietary subtree, the tree might be broken down by product model, > and knowing which models generate which varbinds might be useful > info. > Some polling applications adapt their requests based on what is > known > to be available; once they determine that a given MIB module is not > supported on a device, then they might not poll for that subtree > (unless they detect a reboot or other event where the subtree might > become available). > > When doing any analysis based on a pcap capture in front of an > application, it should certainly be noted in the metadata which > application's traffic was being captured. This should probably be > mentioned in paragraph one of section 2.1. We already added a general warning to section 2.5. I changed it slightly and now it reads as follows: It should be noted that any results produced by analyzing a trace must be interpreted in the context of the trace. The nature of the network, the attachment point used to collect the trace, the nature of the applications generating SNMP traffic, or the events that happened while the trace was collected clearly influence the result. It is therefore important to be careful when drawing general conclusions based on a potentially (too) limited data set. > Different applications are designed to do different things. A > generic MIB browser might not be particular about what it polls; a > bridging fault detection application might poll the bridge mib and > use traps more extensively than other applications. One type of > analysis that could be done is to identify which MIB modules are > polled regularly by specific applications. > > Some applications rely on administrative configuration of polling; > for example, a popular application displays the date and time from > the device; but it asks the operator which object (and its format) > to poll to get the raw data used to generate that information. The > bias of a particular operator or a particular device vendor might be > eliminated in comparing large number of traces, but could be > misleading is small samples. > > Some applications only poll what an operator asks it to, and at the > frequency requested. This bias should be recognized. I think this is already covered by the above paragraph - not in that level of detail but I think that is also not needed. If you think more detail is needed, please suggest concrete text. > 3.2 Periodicity > > Again, the application should be taken into consideration. Spectrum, > and I expect other application suites, use a shared polling engine > to > support multiple applications, and has indicators in its local > database of the likely variability of an object, and how important > that variability is to each using application. An application can > tell > the poller "I need the absolute latest value" which causes the > database to always poll the object, or "Any value within the last 30 > minutes is fine", and the database will return a value form the > database that was recorded within the last 30 minutes, if available, > otherwise it polls to update the object, or "Any value since reboot" > which might be used for things like sysContact. > > So the periodic polling behavior is highly dependent on the > application and the polling engine it uses, and this needs to be > considered when analyzing traces. Added the following paragraph: The periodic polling behavior may dependent on the application and the polling engine it uses. For example, some management platforms allow applications to specify how long polled values may be kept in a cache before it is polled again. Such optimizations needs to be considered when analyzing traces for periodic and aperiodic traffic. > 3.3 Latency Distributions > > Some device implementations update their SNMP counters from the > underlying instrumentation following adaptive algorthms, not > necessarily periodically, and not necessarily on-demand. For > example, > if an implementation chose to update the counters from the > instrumentation only when asked, but then to update the counter for > subsequent requests only if the data in the counter is more than X > seconds old, the measured latency might vary as a result (assuming > sending the repeat value takes less time than updating from the > actual > instrumentation). The granularity of counter update may or may not > be > significant to the latency measurement. Added the following paragraph: Some SNMP implementations update their counters from the underlying instrumentation following adaptive algorthms, not necessarily periodically, and not necessarily on-demand. The granularity of internal counter updates may impact latency measurements and should be taken into account. > 3.4 Concurrency > > It might also be interesting to see how many redundant requests > coming > from different applications are processed almost simultaneously by a > device. Understanding this might prompt more usage of shared polling > engines to reduce the redundancy. Added the following paragraph: In addition, it will be interesting to analyze how many redundant requests coming from applications are processed almost simultaneously by a device. > Of course, for this you might need to perform the capture in front > of > specific devices or device groups to capture traffic from multiple > applications. Section 2.1 discusses the location of probes; it > probably should mention the impact of location on analysis affected > by manager:device relationships of 1:m, m:1, and m:m. The text already suggests to place probes close to management system(s) - so this should almost always give you *:m. And we do not require to have an inventory of management applications listed (and in fact we have seen traces where people were somewhat surprised where the SNMP traffic was originating from). Note that the general warning about the interpretation of results already mentions the influence of the attachement point. So I did not change anything. > 3.5 retrieval approaches > > This is application-specific. > > "It will be useful to know which of these approaches are used on > production networks, by which applications." > > If an operator can detect that a particular application is being > inefficient, he can ask the vendor to modify the application > retrieval > approach to improve efficiency, or he can buy more efficient > applications. I did not make any changes here as I prefer to stay away from discussing for each item what can be done with the results. > 3.6 Trap-directed polling > > Whether polling is adapted based on having received a notification > is > application-specific. > > Any analysis should take into consideration the application-specific > behavior before concluding "to what extent SNMP managers use > automated > procedures ..." > > With a large enough sample, this might become unimportant, but thus > far, it has been hard to get samples, so this type of bias should be > mentioned for small samples. I believe this is covered by the general warning about generalizations of results mentioned above. > 3.8 Obsolete objects > > By parseing sysObjectID and sysDecr and the Host Resources MIB, you > might be able to determine how old the revisions of hardware and > software of the mansged devices are. This should probably be taken > into consideration when analyzing the use of obsolete and deprecated > objects. Added the following paragraph: Depending on the data recorded in a trace, it might be possible to determine the age of devices by looking at values of objects such as sysObjectID and sysDecr [RFC3418]. The age of a device can then be taken into consideration when analyzing the use of obsolete and deprecated objects. > 3.10 Discontinuity > > "It will be interesting to study to what extent these objects are > actually used by management applications ..." isn't clear how you > would determine which continuity indicators are used by management > applications. The traces could be analyzed to correlate which > discontinuity indicators are included in requests for which counters > to infer what is used by management applications. I am not sure I understand your suggestion. We take a management application as a black box - such a block box either generates requests checking for discontinuity indicators or not. Nothing changed. > 4.1 Should the irtf establish its own namespace registry? Ongoing discussion, right now in the hands of the IESG... > 4.13 why should activation of trap conversion be the user's choice? > I can see reasons for this, but you don't mention any, and it could > be important to the analysis. Is it also important to any subsequent > user of the CSV to know whether the traps were converted or not? Filtering is a users' choice as is anonymization as is trap conversion. And some of these things can even interact. I think the recommendation is fine as is. > 5.0 (filter-in principle) is mentioned, but there is no defintion of > what this means in the document, and no reference. It should either > be removed or a citation/reference added. The filter-in principle is explained in never versions of the ID. > Good job. Thanks or the review. If you are fine with changes and I do not hear objections, I will post an updated ID. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103