From majordomo@mil.doit.wisc.edu Mon Feb 2 09:16:14 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14054 for ; Mon, 2 Feb 2004 09:16:13 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AneU2-0003Tm-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Feb 2004 07:51:26 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AneU0-0003Th-00 for ipfix@net.doit.wisc.edu; Mon, 02 Feb 2004 07:51:24 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i12Dp1L20279; Mon, 2 Feb 2004 14:51:01 +0100 (MET) Message-ID: <401E5526.5090106@fokus.fraunhofer.de> Date: Mon, 02 Feb 2004 14:48:22 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Meyer CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, I see the value of having an XML description but I agree to Juergen, Nevil and Stewart that the text should be the normative reference. I do not see the point of forcing people to use XML if they don't want to. I also do not see the point of extending the IM. Most people will anyway read only the text and comment on this. So you have to do the XML editing anyway. As for IPFIX IM extensions not even the PSAMP IM draft currently uses the XML model. Even worse the use of XML schema types like hexBinary has caused some confusion among the authors. I don't think that the use of XML in the IETF is as widely accepted as the use of MIBs. And how many IETF drafts provide normative textual descriptions vs. how many provide normative XML schemas? The W3C schema definition is not even accepted by the whole XML community. There are alternatives e.g. RELAX NG. Let's close this issue and move forward. A further point is whether IPFIX will standardize how to store the information. 1) AFAIK the idea of MIBs is to have a virtual information store. Do we need an IPFIX MIB? (PSAMP has a MIP draft already...) 2) IMO the info model draft should focus on the definition of the information model and _not_ how to encode IPFIX information in XML. Cheers, Sebastian Jeff Meyer wrote: > Juergen, > > I agree few protocols have formal model specs. SNMP, however, which > has as a key value proposition the means of extensibility chose to > define MIBs, quite formal. MIBs also suffer somewhat from difficulty in > reading along with some other issues inherited from ASN.1 which are > improved by XML. > > Since I believe one of the key aspects of IPFIX is the mechanism for > extension, I think we should learn from another IETF protocol which > seemed rather successful in addressing this requirement. > > So, I think maintaining the connection between the mechanism which is > available today in IPFIX-info to formally specify the model is > important, if there is an interest in drawing others to extend IPFIX > with information content which differs from IPFIX's initial focus. > > One approach would be to break out another document as part of IPFIX, > which would be something like "Formal IPFIX Information Modeling". But > I'm not particularly eager to create another document. > > -- Jeff > > >> From: Juergen Quittek >> To: Jeff Meyer , n.brownlee@auckland.ac.nz >> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >> vs.Appendix A >> Date: Thu, 29 Jan 2004 12:30:58 +0100 >> >> Jeff, >> >> We had this entire discussion already some time ago. >> >> For me, the main argument is that all IETF standards so far >> are human-readable. The XML document in the Appendix is hardly >> readable, while section 6 is well readable. >> >> You are requesting to move from a human-readable standard >> to a machine-readable standard. I understand that there are >> several good reasons to do so. But the change in the >> standardization approach is fundamental. >> >> This might be an issue for the ietf@ieft mailing list. >> However, so far very few protocols or models in the IETF >> have been formally defined. Looks like still the 'running >> code' approach dominates the 'well specified' approach. >> >> Regards, >> >> Juergen >> >> --On 28.01.2004 19:53 h -0800 Jeff Meyer wrote: >> >>> Nevil, >>> >>> My only contention would be that I did not do any direct data entry >>> for section 6. I.e. I wrote the XML-Schema ran it through the >>> publicly available stylesheet and free transform engine and pasted it >>> into the doc. >>> >>> Certainly it would be my hope that authors of additional >>> information models to be carried over IPFIX would follow the same >>> process, because then I can simply take their XML-Schema spec and use >>> it in a variety of tools. If I only get text, then I >>> have the tedious prospect of transcribing it. If equipment providers >>> favor a manual transcription process, it is certainly not precluded. >>> >>> My understanding was that PSAMP might be using the XML technique >>> today, I believe it was Juergen who asked about the tools and I >>> passed along the pointer. >>> >>> If it is politically simpler to call section 6 normative but >>> indicate that authors of new models SHOULD create an XML-Schema model >>> and MAY machine translate these models to create the normative text, >>> then I could live with such a compromise. >>> >>> Simply excising this information as Stewart seems to be advocating >>> seems like a step backwards and I'm at a loss to see any benefit from >>> that. >>> >>> Regards, >>> >>> Jeff Meyer >>> >>> >>>> From: Nevil Brownlee >>>> To: Jeff Meyer >>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>> vs.Appendix A >>>> Date: Thu, 29 Jan 2004 13:02:07 +1300 >>>> >>>> Stewart and Jeff: >>>> >>>> > With the use of XSL stylesheets the XML style informaiton model >>>> could >>>> be >>>> > transformed automatically into any set of text one would want, >>>> e.g. IOS >>>> > commands to enable flags, HTML tables for presentation, RFC2629 >>>> entries >>>> in >>>> > an RFC document, etc. For a discussion and example of using free XSL >>>> tools >>>> > to process this you can see >>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html. >>>> >>>> Jeff's right in saying that XML is becoming more widely used within the >>>> IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially >>>> in the Applications Area) are using it. >>>> >>>> However, RFC 2629 explicitly says it doesn't address "IETF politics" >>>> issues. My take on that is that the text in section 6 of the Info >>>> Model >>>> draft is the normative version; Appendix A gives the xml because people >>>> may find it useful, but if they use it they should check that it really >>>> does match the (normative) text version. >>>> >>>> As for IPFIX WG consensus on this, in my view the document editors >>>> are free to use whatever tools they need to produce the actual drafts. >>>> Furthermore, including the xml as an appendix allows other people to >>>> use the xml for other purposes, which (I guess) is why the editors >>>> appended it to the draft. >>>> >>>> Does that make the situation clearer? >>>> >>>> ----------------------------------------------------------------------- >>>> Nevil Brownlee Director, Technology Development >>>> Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland >>>> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand >>>> >>>> >>>> ------------------------------------------------- >>>> This mail sent through University of Auckland >>>> http://www.auckland.ac.nz/ >>>> >>>> -- >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>> message >>>> body >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>> "unsubscribe ipfix" in message body >>>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> _________________________________________________________________ >>> Learn how to choose, serve, and enjoy wine at Wine @ MSN. >>> http://wine.msn.com/ >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> >> >> > > _________________________________________________________________ > There are now three new levels of MSN Hotmail Extra Storage! Learn > more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 2 10:21:28 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18329 for ; Mon, 2 Feb 2004 10:21:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Anfh8-0006Rx-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Feb 2004 09:09:02 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Anfh7-0006Rm-00 for ipfix@net.doit.wisc.edu; Mon, 02 Feb 2004 09:09:01 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i12F8uL01603; Mon, 2 Feb 2004 16:08:56 +0100 (MET) Message-ID: <401E6769.8040402@fokus.fraunhofer.de> Date: Mon, 02 Feb 2004 16:06:17 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations References: <2147483647.1075471150@[10.1.1.171]> <2147483647.1075483972@[10.1.1.171]> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id i12F8uL01603 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Hi Juergen, good work! Some comments: - Do we really need the semantics attribute? Often the semantics are alre= ady included in the description or even in the field name. I'd prefer to h= ave that in the description. - No signed types yet (do we need them?) - Do we need both enumeratedRange and Range? I'd prefer to have only one = element and let this be an enumeration or range. According to the current defi= nition you can specify both which might not be a good idea. - Allow multiple reference elements instead of comma separation in the va= lue? - Make some attributes of field elements instead to make the first line s= horter and more readable. I'd suggest to have only name and *Type as attribut= es. Cheers, Sebastian Juergen Quittek wrote: > Jeff and all, >=20 > Here is an alternative suggestion for the XML representation of the > info model that I developed together with Thomas, one of the editors of > the PSAMP info model. This XML representation of the info model uses > an XML document (ipfix.xml) instead of an XML schema for specifying > the IPFIX information elements (or fields as the IPFIX protocol documen= t > calls them). It just shows the first 11 elements defined in the current= =20 > draft, > but this is enough to show how this XML format looks like. >=20 > File ipfix.xml can be used for automatically generating Section 6 of > the INFO model document as well as the XML schema used for the previous > version. The difference is that it uses abstract data types (as a data > model should) instead of concrete ones. >=20 > In addition, file ipfix.xsd contains an XML schema, that can be used > for validating the ipfix.xml file. It defines the properties of fields/ > information elements that are used in ipfix.xml and it also includes > a definition of the abstract data types used in ipfix.xml. >=20 > A nice consequence is that now not just Section 6 (field definitions) > but also Section 3 (Properties of an IPFIX Flow Attribute) and Section = 4 > (Type Space) can be generated out of XML input. >=20 > While section 6 is generated from ipfix.xml, Sections 3 and 4 are > generated from ipfix.xsd. >=20 > Also the XML schema, we used for the previous versions of the INFO mode= l > can be generated out of the info model given in ipfix.xml. You just ha= ve > to define a mapping of the used abstract data types to concrete ones, > such as the IPDR definitions of IPv4 and IPv6 addresses. >=20 > Conclusion: > - This version is a pure data model using abstract data types and witho= ut > any data encodings. > - It does not have dependencies on external data type definitions by IP= DR. > - We do not loose anything, because the XML schema, we used so far > (including XML data types) can be generated automatically. >=20 > Cheers, >=20 > Juergen >=20 > --On 30.01.2004 13:59 Uhr +0100 Juergen Quittek wrote: >=20 >> Jeff, >> >> --On 29.01.2004 10:20 Uhr -0800 Jeff Meyer wrote: >> >>> Juergen, >>> >>> XML-Schema can be thought of as a pure Informaiton Model. >> >> >> Of course we can say: >> "Here is a combined info and data model, please ignore the data=20 >> model part, >> because this standard is just about the info model." >> >> But this appears to be - at least - curious. >> >>> XML-Schema and XML also define productions which can be used to creat= e >>> instance documents which are a data model and encoded in ASCII. >> >> >> This is what people call a data model. >> >>> IPDR takes full advantage of this by providing both >>> ASCII and Binary encodings from the same information model. >>> I.e. XML-Schema CAN be used AS IS as a pure information model. >> >> >> Yes and we can have exactly the same with what I suggested. >> The current version of the IPFIX INFO model does not contain >> a binary encoding, but it does contain an ASCII encoding. >> >>> Think of ASN.1 which has a Syntax and various encoding rules such >>> as BER, DER and others (even an XER). At some point you need to >>> formally define something, but that DOES NOT mean that the ASN.1 >>> syntax is just a BINARY encoding model nor is it just >>> one encoding model. Hence it IS separate from encoding. >>> >>> I view XML-Schema as the ASN.1 of the 21st century, only with a >>> much richer set of off the shelf and often free tools and other >>> interoperable components. >> >> >> I am sure you do not claim to inherit all properties of ASN.1 ;-) >> >>> Renaming things which are well defined (e.g. int) to duplicate >>> names (e.g. ipfix-int) is just a lot of unnecessary rework. >>> The temptation to simply redefine things is often large for >>> engineers. However in the long run reusing existing work >>> increases the likelihood that people will converge on certain >>> key patterns. >> >> >> It is not just renaming. It is replacing the concrete XML data type >> with an abstract one that can be mapped to XML as well as to many othe= r >> domains. And if you look at other INFO models, for example defined >> in CIM by the DMTF, always abstract data types are used in info models. >> Concrete ones are just used in data models. >> >> But even if you just consider it as renaming, it solves some problems. >> [And having worked as software engineer, I know that renaming (e.g. = by >> endless sets of #DEFINEs in C and C++ is not really unusual.] >> The problems we can solve are >> >> 1. We can replace 'hexBinary' by 'octetArray' or something else. >> Why should a binary data type use 'hex' in its name, if not ONLY >> with respect to its ASCII data encoding? And the encoding that=20 >> really >> is of importance for IPFIX standardization is the binary encoding >> by the protocol. >> >> 2. We do not have to refer to an IPDR document as a normative=20 >> reference. >> This has three implications: >> >> First, I do not know if this is (so far) possible at all for IETF >> standard track documents. >> >> Second, I am not sure if the IPDR definition of IPv4 addresses=20 >> and IPv6 >> addresses is what the IETF would like to use. It does not make=20 >> sense >> to import IPv4 address XML encoding from the IPDR definitions in = one >> IETF standard and to use another source in another IETF standard. >> >> Third, if we use our own ABSTRACT data types, users can more easi= ly >> choose other XML encodings than the one promoted by IPDR. >> [Nothing against IPDR. I like it very much and my company is a=20 >> member] >> Management systems and database builders/integrators may/will=20 >> already >> have their own (XML) data types for flow recording. If we use an >> abstract data type we do not explicitly request them to use the >> IPDR definitions. >> >> >> Juergen >> >>> -- Jeff >>> >>> >>>> From: Juergen Quittek >>>> To: Jeff Meyer , ipfix@net.doit.wisc.edu >>>> Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need= =20 >>>> IANA >>>> considerations >>>> Date: Thu, 29 Jan 2004 13:31:19 +0100 >>>> >>>> Jeff, >>>> >>>> I suggest to follow a completely different way of solving this >>>> problems such that everybody get what is needed. >>>> >>>> I see the cause in our dispute that the Appendix of the INFO model >>>> document is NOT just an information model, but a data model. >>>> >>>> As you argued well some time ago, it is a bad idea specifying >>>> binary encodings in the info model document, because this would >>>> already be a data model, which may vary among different protocols >>>> that potentially use the IPFIX INFO model. >>>> >>>> So, it is completely correct, that the binary encoding has become >>>> a part of the IPFIX PROTOCOL document. But still the IPFIX INFO >>>> model document contains a data model: the XML ASCII encoding for >>>> each information element. This is a data model. IMHO this is wrong! >>>> >>>> We should follow a clean approach by just specifying an >>>> information model. This would solve several of the open issues >>>> we are discussing, including the name space problem (iprd:), >>>> because we get completely independent of these data encoding issues >>>> and still can support IPDR data types in XML-based applications. >>>> >>>> Here is my suggestion: >>>> >>>> Currently, the Appendix is an XML schema defining which fixes ASCII >>>> encodings for each information element. I suggest to replace this >>>> XML schema by an XML document. The document would consist of a set >>>> of XML element, each of them specifying a single information element= s >>>> with a set of attributes and/or contained XML elements exactly >>>> covering all properties of information elements as defined in=20 >>>> section 3. >>>> (We can use a small, simple XML schema for checking consistency of t= his >>>> XML document.) >>>> >>>> Information elements defined this way would not have a standard XML, >>>> IPDR, or other data type (data model should be separated from info=20 >>>> model), >>>> but would be defined just by English text, for example >>>> ipfix-int: integer value in the range of -2147483648 to 2147483647 >>>> ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h >>>> ipfix-ipv4address: integral representation of a 32 bit IPv4 address >>>> ... >>>> We would create our own IPFIX type space for the information element= s. >>>> >>>> Based on this pure information model, we can use XSLT (as we do it n= ow) >>>> to generate all the text in Section 6 describing the information=20 >>>> elements. >>>> >>>> Now, if you want to realize an XML-based application, you can take t= he >>>> new XML document and use XSLT for automatic generation of a schema,=20 >>>> such >>>> as the one we have in the Appendix of the current version of the=20 >>>> INFO model >>>> document. You see, you still have all the advantages of the machine= - >>>> readability and all opportunities to generate IPFIX XML parsers >>>> automatically. >>>> But with the suggested change you would also have a clean=20 >>>> information model >>>> in the IPFIX INFO document avoiding all discussions on whether or=20 >>>> not to >>>> use the IPDR data types. >>>> >>>> I am currently working together with Thomas, editor of the PSAMP INF= O >>>> model, to implement the idea sketched above. We will send an example= to >>>> this list in a few days. >>>> >>>> Regards, >>>> >>>> Juergen >>>> >>>> >>>> --On 27.01.2004 23:55 h -0800 Jeff Meyer wrote: >>>> >>>>> The current info-model-02 specification contains references to XML=20 >>>>> type >>>>> names and semantics borrowed directly from the XML-Schema=20 >>>>> specification as >>>>> well as extensions. >>>>> >>>>> Currently these extensions borrow from existing work of IPDR as=20 >>>>> well as >>>>> newly identified types currently specific to IPFIX. >>>>> >>>>> There are a few ways to address this. >>>>> >>>>> The following e-mail thread discusses the options and opinion of th= is >>>>> editor as well as opinions from Andrew Norton who is involved in=20 >>>>> IETF's >>>>> and IANA's work in utilizing XML in RFC's. >>>>> >>>>> >>>>> Jeff, >>>>> >>>>> It would seem that this is all a matter of "taste" as any of these=20 >>>>> options >>>>> technically work. Personally I would go with option 3; though it=20 >>>>> requires >>>>> more coordination between organizations, to an outsider it would=20 >>>>> seem more >>>>> cohesive. >>>>> >>>>> There is a practical difference between option 1 and option 3 in=20 >>>>> terms of >>>>> setting the standard. With option 3, if IPDR upgrades their=20 >>>>> standard, the >>>>> IPFIX group needs to do nothing to incorporate the changes. =20 >>>>> However, with >>>>> option 1, IPFIX will have to >>>>> standardize a new schema and issue new RFC's. >>>>> >>>>> -andy >>>>> >>>>> Jeff Meyer wrote: >>>>> Hi Andy, >>>>> >>>>> I wanted to get your opinion on extending the XML-Schema type=20 >>>>> system for >>>>> some specific information modeling requirements encountered by the=20 >>>>> IPFIX >>>>> working group. >>>>> >>>>> IPFIX currently reuses about 15 types from XML-Schema directly,=20 >>>>> however >>>>> there are several types which are worthwile to distinguish from an=20 >>>>> IPFIX >>>>> persepective which are not defined by XML-Schema. >>>>> >>>>> These include types to identify timestamps of specific resolution=20 >>>>> (e.g. >>>>> mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and=20 >>>>> one for >>>>> UUIDs. >>>>> >>>>> Today most of these extension types are defined in the public NDM-U= =20 >>>>> 3.1.1 >>>>> specification from the industry consortium called IPDR.org. There=20 >>>>> are a >>>>> couple which are not are related to the high resolution timestamps=20 >>>>> (uSec >>>>> and nSec). >>>>> >>>>> The NDM-U 3.1.1 specificaiton is avaiable at >>>>> http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically sect= ion >>>>> A.4.4. >>>>> >>>>> The IPFIX-Info reference is available at: >>>>> >>>>> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info= -02.html#anchor4=20 >>>>> >>>>> >>>>> >>>>> This is a link to the specific secion in the HTML format of the=20 >>>>> info model >>>>> based on RFC2629. >>>>> >>>>> >>>>> The quesion at hand is whether to follow one of the following 3=20 >>>>> options: >>>>> >>>>> 1. have a single XML-Schema which defines the extension types=20 >>>>> relevant >>>>> to IPFIX and contained in the IPFIX namespace >>>>> 2. reference the existing types targeted by IPDR and add only=20 >>>>> the new >>>>> types specific to the IPFIX Schema >>>>> 3. petition IPDR to define the remaining two IPFIX types for >>>>> timestamps in their upcoming 3.5 specification (likely timeframe=20 >>>>> Feb. or >>>>> March) >>>>> >>>>> I get the impression from IPFIX discussions that referencing IPDR i= s >>>>> something that some vocal participants find objectionable, i.e.=20 >>>>> they would >>>>> prefer to see option 1. >>>>> >>>>> My personal preference would be to go with option 3 or 2. I=20 >>>>> believe 3 is >>>>> doable and would reduce the number of places where people have to=20 >>>>> look for >>>>> things. Option 1 I see as creating some confusion in the space, bu= t >>>>> ultimately addressable through XSL >>>>> or other mapping functions, if that's what it takes to get consensu= s. >>>>> >>>>> >>>>> Any guidance on your part would be appreciated. >>>>> >>>>> Regards, >>>>> >>>>> Jeff Meyer >>>>> >>>>> _________________________________________________________________ >>>>> Get a FREE online virus check for your PC here, from McAfee. >>>>> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963 >>>>> >>>>> >>>>> --=20 >>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in=20 >>>>> message >>>>> body >>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>> "unsubscribe ipfix" in message body >>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>>> >>>> >>>> >>>> >>> >>> _________________________________________________________________ >>> Find high-speed =91net deals ? comparison-shop your local providers=20 >>> here. https://broadband.msn.com >>> >> >> >> >> >> >> --=20 >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in=20 >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >=20 >=20 >=20 >=20 --=20 Sebastian Zander E-mail: zander@fokus.fraunhofer.= de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/seba= stian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 2 13:06:30 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26773 for ; Mon, 2 Feb 2004 13:06:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AniFY-000425-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Feb 2004 11:52:44 -0600 Received: from bay3-f5.bay3.hotmail.com ([65.54.169.5] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AniFW-00041z-00 for ipfix@net.doit.wisc.edu; Mon, 02 Feb 2004 11:52:43 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 2 Feb 2004 09:52:42 -0800 Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP; Mon, 02 Feb 2004 17:52:41 GMT X-Originating-IP: [67.169.184.134] X-Originating-Email: [inetpix@msn.com] X-Sender: inetpix@msn.com From: "Jeff Meyer" To: zander@fokus.fraunhofer.de Cc: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A Date: Mon, 02 Feb 2004 09:52:41 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Feb 2004 17:52:42.0053 (UTC) FILETIME=[5AEFE750:01C3E9B5] Precedence: bulk Sender: majordomo listserver Sebastian, Comments inline... -- Jeff >From: Sebastian Zander >To: Jeff Meyer >CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, >ipfix@net.doit.wisc.edu >Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >vs.Appendix A >Date: Mon, 02 Feb 2004 14:48:22 +0100 > >Jeff, > >I see the value of having an XML description Good. >but I agree to Juergen, Nevil >and Stewart that the text should be the normative reference. I do not see >the point of forcing people to use XML if they don't want to. Do you mean "use" or "read" XML? Assuming that you have a working XSL implementation the two forms are equivalent. >I also do not >see the point of extending the IM. Huh? Take a look at the requirements document, section 6.2: The data model MUST be extensible for future attributes to be added. Even if a set of attributes is fixed in the flow record, the data model MUST provide a way of extending the record by configuration or for certain implementations. The term "data model" is misused here, but obviously from the context the intent is that extending the IM is a MUST. PSAMP is a case in point. >Most people will anyway read only the >text and comment on this. So you have to do the XML editing anyway. So you're saying one should write in XML? (I agree, but it seems inconsistent with your previous statements?) >As for >IPFIX IM extensions not even the PSAMP IM draft currently uses the XML >model. Read the thread more carefully. They did use XML, they just didn't publish it, not very helpful. As it stands I would need to cut and paste each subsection for each attribute of their work to operate with a system that is capable of directly a single XML document. >Even worse the use of XML schema types like hexBinary has caused some >confusion >among the authors. "hexBinary" is a poorly chosen name. If we embarked on reinventing things every time we disliked the names, then maybe we could solve the technology slump! Jobs for everyone! > >I don't think that the use of XML in the IETF is as widely accepted as the >use of MIBs. And how many IETF drafts provide normative textual >descriptions >vs. how many provide normative XML schemas? This seems to be simply an argument that change is bad. That if things were one way before, embarking on something which might improve upon them should be viewed with great skepticism. Obviously as new work there are a lot more MIBs which have had > 10 years to be built up vs. something which is proposed for IPFIX. >The W3C schema definition is not >even accepted by the whole XML community. There are alternatives e.g. RELAX >NG. XML-Schema is the W3C specification. Plain and simple. Ultimately the utility is agreeing on one piece of work, which W3C did. > >Let's close this issue and move forward. If both the XML and human readable forms are in the document, and assuming the process of converting from XML->human readable is automated using free and open tools, then I guess it really doesn't matter which one calls normative. So, assuming we publish both, calling the text based normative to benefit readers unfamiliar with XML is an acceptable compromise. If only human readable is contained in the document, as in the current PSAMP document, then I still have an issue. You've taken away the more useful artifact of the two artifacts, the XML document which can be transformed into whatever you want it to be. > >A further point is whether IPFIX will standardize how to store the >information. >1) AFAIK the idea of MIBs is to have a virtual information store. Do we >need an > IPFIX MIB? (PSAMP has a MIP draft already...) >2) IMO the info model draft should focus on the definition of the >information > model and _not_ how to encode IPFIX information in XML. The info model simply points out how because it is abstract and separate from encoding and transport, it may be applied to other activities dealing with IPFIX information. Because MIBs typically deal with virtual stores of instantenous (vs. historical) information, they aren't very useful in the IPFIX context where enormous volumes of individual records are streaming off the device. Yes, RMON is an example of a MIB which invented a complex indexing scheme to store historical information, while clever, I think it also illustrates some of the limitations/irritations of working with MIBs in this context. A file format, or DB on the other hand is a handy way to capture these. Being able to "get this for free" seems like goodness to me. > >Cheers, > >Sebastian > >Jeff Meyer wrote: >>Juergen, >> >> I agree few protocols have formal model specs. SNMP, however, which has >>as a key value proposition the means of extensibility chose to define >>MIBs, quite formal. MIBs also suffer somewhat from difficulty in reading >>along with some other issues inherited from ASN.1 which are improved by >>XML. >> >> Since I believe one of the key aspects of IPFIX is the mechanism for >>extension, I think we should learn from another IETF protocol which seemed >>rather successful in addressing this requirement. >> >> So, I think maintaining the connection between the mechanism which is >>available today in IPFIX-info to formally specify the model is important, >>if there is an interest in drawing others to extend IPFIX with information >>content which differs from IPFIX's initial focus. >> >> One approach would be to break out another document as part of IPFIX, >>which would be something like "Formal IPFIX Information Modeling". But >>I'm not particularly eager to create another document. >> >>-- Jeff >> >> >>>From: Juergen Quittek >>>To: Jeff Meyer , n.brownlee@auckland.ac.nz >>>CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>vs.Appendix A >>>Date: Thu, 29 Jan 2004 12:30:58 +0100 >>> >>>Jeff, >>> >>>We had this entire discussion already some time ago. >>> >>>For me, the main argument is that all IETF standards so far >>>are human-readable. The XML document in the Appendix is hardly >>>readable, while section 6 is well readable. >>> >>>You are requesting to move from a human-readable standard >>>to a machine-readable standard. I understand that there are >>>several good reasons to do so. But the change in the >>>standardization approach is fundamental. >>> >>>This might be an issue for the ietf@ieft mailing list. >>>However, so far very few protocols or models in the IETF >>>have been formally defined. Looks like still the 'running >>>code' approach dominates the 'well specified' approach. >>> >>>Regards, >>> >>> Juergen >>> >>>--On 28.01.2004 19:53 h -0800 Jeff Meyer wrote: >>> >>>>Nevil, >>>> >>>> My only contention would be that I did not do any direct data entry >>>>for section 6. I.e. I wrote the XML-Schema ran it through the publicly >>>>available stylesheet and free transform engine and pasted it into the >>>>doc. >>>> >>>> Certainly it would be my hope that authors of additional information >>>>models to be carried over IPFIX would follow the same process, because >>>>then I can simply take their XML-Schema spec and use it in a variety of >>>>tools. If I only get text, then I >>>>have the tedious prospect of transcribing it. If equipment providers >>>>favor a manual transcription process, it is certainly not precluded. >>>> >>>> My understanding was that PSAMP might be using the XML technique >>>>today, I believe it was Juergen who asked about the tools and I passed >>>>along the pointer. >>>> >>>> If it is politically simpler to call section 6 normative but indicate >>>>that authors of new models SHOULD create an XML-Schema model and MAY >>>>machine translate these models to create the normative text, then I >>>>could live with such a compromise. >>>> >>>> Simply excising this information as Stewart seems to be advocating >>>>seems like a step backwards and I'm at a loss to see any benefit from >>>>that. >>>> >>>>Regards, >>>> >>>> Jeff Meyer >>>> >>>> >>>>>From: Nevil Brownlee >>>>>To: Jeff Meyer >>>>>CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>vs.Appendix A >>>>>Date: Thu, 29 Jan 2004 13:02:07 +1300 >>>>> >>>>>Stewart and Jeff: >>>>> >>>>> > With the use of XSL stylesheets the XML style informaiton model >>>>>could >>>>>be >>>>> > transformed automatically into any set of text one would want, e.g. >>>>>IOS >>>>> > commands to enable flags, HTML tables for presentation, RFC2629 >>>>>entries >>>>>in >>>>> > an RFC document, etc. For a discussion and example of using free >>>>>XSL >>>>>tools >>>>> > to process this you can see >>>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html. >>>>> >>>>>Jeff's right in saying that XML is becoming more widely used within the >>>>>IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially >>>>>in the Applications Area) are using it. >>>>> >>>>>However, RFC 2629 explicitly says it doesn't address "IETF politics" >>>>>issues. My take on that is that the text in section 6 of the Info >>>>>Model >>>>>draft is the normative version; Appendix A gives the xml because people >>>>>may find it useful, but if they use it they should check that it really >>>>>does match the (normative) text version. >>>>> >>>>>As for IPFIX WG consensus on this, in my view the document editors >>>>>are free to use whatever tools they need to produce the actual drafts. >>>>>Furthermore, including the xml as an appendix allows other people to >>>>>use the xml for other purposes, which (I guess) is why the editors >>>>>appended it to the draft. >>>>> >>>>>Does that make the situation clearer? >>>>> >>>>>----------------------------------------------------------------------- >>>>> Nevil Brownlee Director, Technology Development >>>>> Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland >>>>> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand >>>>> >>>>> >>>>>------------------------------------------------- >>>>>This mail sent through University of Auckland >>>>>http://www.auckland.ac.nz/ >>>>> >>>>>-- >>>>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>message >>>>>body >>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>"unsubscribe ipfix" in message body >>>>>Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>>> >>>>_________________________________________________________________ >>>>Learn how to choose, serve, and enjoy wine at Wine @ MSN. >>>>http://wine.msn.com/ >>>> >>>> >>>>-- >>>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >>>>body >>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>"unsubscribe ipfix" in message body >>>>Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> >>> >>> >> >>_________________________________________________________________ >>There are now three new levels of MSN Hotmail Extra Storage! Learn more. >>http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 >> >> >>-- >>Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >>body >>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>"unsubscribe ipfix" in message body >>Archive http://ipfix.doit.wisc.edu/archive/ >> > > >-- >Sebastian Zander E-mail: zander@fokus.fraunhofer.de >Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >D-10589 Berlin, Germany >www.fokus.fraunhofer.de/usr/sebastian.zander > > > > _________________________________________________________________ Let the new MSN Premium Internet Software make the most of your high-speed experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 2 13:37:56 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29674 for ; Mon, 2 Feb 2004 13:37:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Anik5-0005Fe-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Feb 2004 12:24:17 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Anik4-0005FY-00 for ipfix@net.doit.wisc.edu; Mon, 02 Feb 2004 12:24:16 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i12IOEN8059745 for ; Mon, 2 Feb 2004 19:24:14 +0100 (CET) Received: from ccrle.nec.de (molina.office [10.1.1.126]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A15E754BAC for ; Mon, 2 Feb 2004 19:24:13 +0100 (CET) Message-ID: <401E95CC.6030208@ccrle.nec.de> Date: Mon, 02 Feb 2004 19:24:12 +0100 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'ipfix@net.doit.wisc.edu'" Subject: [ipfix] proposal for protocol sec. 9.3.1 (meter statistics) Content-Type: multipart/mixed; boundary="------------040903000403040401060300" X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------040903000403040401060300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I reviwed section 9.3.1 of the IPFIX protocol draft, and here's my proposal about how to better define the "meter statistic" information that can be useful from a collector perspective. I defined only information that IMHO a meter/exporter can keep up to date without complex scannings of its internal data structure. Maurizio --------------040903000403040401060300 Content-Type: text/plain; name="out.txt" Content-Disposition: inline; filename="out.txt" Content-Transfer-Encoding: 7bit 9.3.1 The Metering Process Statistics Option Template The Metering Process Statistics Option Template specifies information about losses in the metering/exporting process and other information useful for the collector to understand whether pathological situations (e.g. discarding of a lot of flow records) are happening. The information can be divided in 4 categories: General, Dropped Packets, Dropped Flows, Active flows. 1) General Info ipfixOption The value MUST be METER_STATS observationDomain Scope ID time; When this record was generated 2) Dropped Packets Info about dropped packets and bytes at the meter that could not be attributed to flows (*) or could not be recorded for the flows they had been attributed to(**). FU stands for Flow Un-attributed droppedFUPacketCount Packets dropped by Metering Process at the specified scope ID droppedFUByteCount Bytes dropped by Metering Process at the specified scope ID timeFirstFUDropped Time of the first packet dropped at the Specified scope ID timeLastFUDropped Time of the last packet dropped at the Specified scope ID With the above information, a collector can reconstruct the dynamic of the macro-flow of all FU discarded packets (*) this doesn't account for packets that have been discarded before the metering process, e.g. because of RED, for sampling or for explicit firewalling rules (**) discarding of packets after flow classification can e.g. happen if room for a new flow record is not available 3) Dropped Flows Info on dropped flows at the meter/flow recording/exporter and on packets and byte therein contained. FA stands for Flow Attributed droppedFlows(*) flows dropped due to resource starvation at the specified scope ID droppedFAPacketCount(**)Packets in the dropped flows droppedFAByteCount(**) Bytes in the dropped flows timeFirstFADropped Time of the first packet within the dropped flows timeLastFADropped Time of the last packet within the dropped flows With the above information, a collector can reconstruct the dynamic of the macro-flow of all FA discarded packets, and have an indication of the average packet and byte size of these flows. (*) flows only account to the above only if when they were discarded their packet count was different since their last exporting (**) only packets and bytes having arrived since last flow exporting account for this counter 4) Active flows Info on flows currently receiving traffic activeFlows Number of flows whose packet counter changed since their last exporting at the specified scope ID packetCountInActFlows packets arrived to active flows since their last exporting time byteCountInActFlows bytes arrived to active flows since their last exporting time With the above information, a collector can know how many flows are receiving traffic and how many packets and bytes arrived since the last exporting. By comparing these counters with the number of received flow records and bytes and packets in them, a collector can estimate the exporter latency and understand if there are pathological situations at the exporter (e.g. flow records never exported). A Metering Process Statistics Option template MUST contain ipfixOption, scopeID, time and droppedFlows. It SHOULD contain droppedFAPacketCount droppedFAByteCount droppedFUPacketCount droppedFUByteCount. It MAY contain the other information listed above. --------------040903000403040401060300-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 2 16:23:01 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12614 for ; Mon, 2 Feb 2004 16:23:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AnlKU-0003Y6-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Feb 2004 15:10:02 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AnlKT-0003Xo-00 for ipfix@net.doit.wisc.edu; Mon, 02 Feb 2004 15:10:01 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i12L9xN8069175 for ; Mon, 2 Feb 2004 22:09:59 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i12L9wBb069173 for ; Mon, 2 Feb 2004 22:09:58 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i12L9vN8069172; Mon, 02 Feb 2004 22:09:58 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id E689E100A04; Mon, 2 Feb 2004 22:09:52 +0100 (CET) Date: Mon, 02 Feb 2004 22:10:04 +0100 From: Juergen Quittek To: Sebastian Zander Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations Message-ID: <2147483647.1075759804@[10.1.1.26]> In-Reply-To: <401E6769.8040402@fokus.fraunhofer.de> References: <2147483647.1075471150@[10.1.1.171]> <2147483647.1075483972@[10.1.1.171]> <401E6769.8040402@fokus.fraunhofer.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Sebastian, --On 02.02.2004 16:06 Uhr +0100 Sebastian Zander wrote: > Hi Juergen, > > good work! Some comments: Thanks. > - Do we really need the semantics attribute? Often the semantics are already > included in the description or even in the field name. I'd prefer to have that in > the description. I copied them from draft -02. I am not really a fan of the semantics attribute, but I did not find time to look for a good alternative. There is some benefit in having them formally specified, but maybe just an explanation in the description is fine. However, SMI distinguishes counters from gauges and plain integers. I suggest to make this separate INFO model issue. > - No signed types yet (do we need them?) Maybe another issue. It tried to find an example that requires negative integers, but I could not find any. Can soemone else? > - Do we need both enumeratedRange and Range? I'd prefer to have only one element > and let this be an enumeration or range. According to the current definition you > can specify both which might not be a good idea. Well, an enumerated range may assigns semantics to each individual numbers, while a plain range just defines maximum and minimum value. Again it would be good to discuss this using an example. > - Allow multiple reference elements instead of comma separation in the value? I'm in favor of plain text in a single reference element. You can list as many references as you like. > - Make some attributes of field elements instead to make the first line shorter > and more readable. I'd suggest to have only name and *Type as attributes. It makes the first line shorter, but the number of lines larger. Thanks, Juergen > Cheers, > > Sebastian > > Juergen Quittek wrote: >> Jeff and all, >> >> Here is an alternative suggestion for the XML representation of the >> info model that I developed together with Thomas, one of the editors of >> the PSAMP info model. This XML representation of the info model uses >> an XML document (ipfix.xml) instead of an XML schema for specifying >> the IPFIX information elements (or fields as the IPFIX protocol document >> calls them). It just shows the first 11 elements defined in the current >> draft, >> but this is enough to show how this XML format looks like. >> >> File ipfix.xml can be used for automatically generating Section 6 of >> the INFO model document as well as the XML schema used for the previous >> version. The difference is that it uses abstract data types (as a data >> model should) instead of concrete ones. >> >> In addition, file ipfix.xsd contains an XML schema, that can be used >> for validating the ipfix.xml file. It defines the properties of fields/ >> information elements that are used in ipfix.xml and it also includes >> a definition of the abstract data types used in ipfix.xml. >> >> A nice consequence is that now not just Section 6 (field definitions) >> but also Section 3 (Properties of an IPFIX Flow Attribute) and Section 4 >> (Type Space) can be generated out of XML input. >> >> While section 6 is generated from ipfix.xml, Sections 3 and 4 are >> generated from ipfix.xsd. >> >> Also the XML schema, we used for the previous versions of the INFO model >> can be generated out of the info model given in ipfix.xml. You just have >> to define a mapping of the used abstract data types to concrete ones, >> such as the IPDR definitions of IPv4 and IPv6 addresses. >> >> Conclusion: >> - This version is a pure data model using abstract data types and without >> any data encodings. >> - It does not have dependencies on external data type definitions by IPDR. >> - We do not loose anything, because the XML schema, we used so far >> (including XML data types) can be generated automatically. >> >> Cheers, >> >> Juergen >> >> --On 30.01.2004 13:59 Uhr +0100 Juergen Quittek wrote: >> >>> Jeff, >>> >>> --On 29.01.2004 10:20 Uhr -0800 Jeff Meyer wrote: >>> >>>> Juergen, >>>> >>>> XML-Schema can be thought of as a pure Informaiton Model. >>> >>> >>> Of course we can say: >>> "Here is a combined info and data model, please ignore the data >>> model part, >>> because this standard is just about the info model." >>> >>> But this appears to be - at least - curious. >>> >>>> XML-Schema and XML also define productions which can be used to create >>>> instance documents which are a data model and encoded in ASCII. >>> >>> >>> This is what people call a data model. >>> >>>> IPDR takes full advantage of this by providing both >>>> ASCII and Binary encodings from the same information model. >>>> I.e. XML-Schema CAN be used AS IS as a pure information model. >>> >>> >>> Yes and we can have exactly the same with what I suggested. >>> The current version of the IPFIX INFO model does not contain >>> a binary encoding, but it does contain an ASCII encoding. >>> >>>> Think of ASN.1 which has a Syntax and various encoding rules such >>>> as BER, DER and others (even an XER). At some point you need to >>>> formally define something, but that DOES NOT mean that the ASN.1 >>>> syntax is just a BINARY encoding model nor is it just >>>> one encoding model. Hence it IS separate from encoding. >>>> >>>> I view XML-Schema as the ASN.1 of the 21st century, only with a >>>> much richer set of off the shelf and often free tools and other >>>> interoperable components. >>> >>> >>> I am sure you do not claim to inherit all properties of ASN.1 ;-) >>> >>>> Renaming things which are well defined (e.g. int) to duplicate >>>> names (e.g. ipfix-int) is just a lot of unnecessary rework. >>>> The temptation to simply redefine things is often large for >>>> engineers. However in the long run reusing existing work >>>> increases the likelihood that people will converge on certain >>>> key patterns. >>> >>> >>> It is not just renaming. It is replacing the concrete XML data type >>> with an abstract one that can be mapped to XML as well as to many other >>> domains. And if you look at other INFO models, for example defined >>> in CIM by the DMTF, always abstract data types are used in info models. >>> Concrete ones are just used in data models. >>> >>> But even if you just consider it as renaming, it solves some problems. >>> [And having worked as software engineer, I know that renaming (e.g. by >>> endless sets of #DEFINEs in C and C++ is not really unusual.] >>> The problems we can solve are >>> >>> 1. We can replace 'hexBinary' by 'octetArray' or something else. >>> Why should a binary data type use 'hex' in its name, if not ONLY >>> with respect to its ASCII data encoding? And the encoding that >>> really >>> is of importance for IPFIX standardization is the binary encoding >>> by the protocol. >>> >>> 2. We do not have to refer to an IPDR document as a normative >>> reference. >>> This has three implications: >>> >>> First, I do not know if this is (so far) possible at all for IETF >>> standard track documents. >>> >>> Second, I am not sure if the IPDR definition of IPv4 addresses >>> and IPv6 >>> addresses is what the IETF would like to use. It does not make >>> sense >>> to import IPv4 address XML encoding from the IPDR definitions in one >>> IETF standard and to use another source in another IETF standard. >>> >>> Third, if we use our own ABSTRACT data types, users can more easily >>> choose other XML encodings than the one promoted by IPDR. >>> [Nothing against IPDR. I like it very much and my company is a >>> member] >>> Management systems and database builders/integrators may/will >>> already >>> have their own (XML) data types for flow recording. If we use an >>> abstract data type we do not explicitly request them to use the >>> IPDR definitions. >>> >>> >>> Juergen >>> >>>> -- Jeff >>>> >>>> >>>>> From: Juergen Quittek >>>>> To: Jeff Meyer , ipfix@net.doit.wisc.edu >>>>> Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need >>>>> IANA >>>>> considerations >>>>> Date: Thu, 29 Jan 2004 13:31:19 +0100 >>>>> >>>>> Jeff, >>>>> >>>>> I suggest to follow a completely different way of solving this >>>>> problems such that everybody get what is needed. >>>>> >>>>> I see the cause in our dispute that the Appendix of the INFO model >>>>> document is NOT just an information model, but a data model. >>>>> >>>>> As you argued well some time ago, it is a bad idea specifying >>>>> binary encodings in the info model document, because this would >>>>> already be a data model, which may vary among different protocols >>>>> that potentially use the IPFIX INFO model. >>>>> >>>>> So, it is completely correct, that the binary encoding has become >>>>> a part of the IPFIX PROTOCOL document. But still the IPFIX INFO >>>>> model document contains a data model: the XML ASCII encoding for >>>>> each information element. This is a data model. IMHO this is wrong! >>>>> >>>>> We should follow a clean approach by just specifying an >>>>> information model. This would solve several of the open issues >>>>> we are discussing, including the name space problem (iprd:), >>>>> because we get completely independent of these data encoding issues >>>>> and still can support IPDR data types in XML-based applications. >>>>> >>>>> Here is my suggestion: >>>>> >>>>> Currently, the Appendix is an XML schema defining which fixes ASCII >>>>> encodings for each information element. I suggest to replace this >>>>> XML schema by an XML document. The document would consist of a set >>>>> of XML element, each of them specifying a single information elements >>>>> with a set of attributes and/or contained XML elements exactly >>>>> covering all properties of information elements as defined in >>>>> section 3. >>>>> (We can use a small, simple XML schema for checking consistency of this >>>>> XML document.) >>>>> >>>>> Information elements defined this way would not have a standard XML, >>>>> IPDR, or other data type (data model should be separated from info >>>>> model), >>>>> but would be defined just by English text, for example >>>>> ipfix-int: integer value in the range of -2147483648 to 2147483647 >>>>> ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h >>>>> ipfix-ipv4address: integral representation of a 32 bit IPv4 address >>>>> ... >>>>> We would create our own IPFIX type space for the information elements. >>>>> >>>>> Based on this pure information model, we can use XSLT (as we do it now) >>>>> to generate all the text in Section 6 describing the information >>>>> elements. >>>>> >>>>> Now, if you want to realize an XML-based application, you can take the >>>>> new XML document and use XSLT for automatic generation of a schema, >>>>> such >>>>> as the one we have in the Appendix of the current version of the >>>>> INFO model >>>>> document. You see, you still have all the advantages of the machine- >>>>> readability and all opportunities to generate IPFIX XML parsers >>>>> automatically. >>>>> But with the suggested change you would also have a clean >>>>> information model >>>>> in the IPFIX INFO document avoiding all discussions on whether or >>>>> not to >>>>> use the IPDR data types. >>>>> >>>>> I am currently working together with Thomas, editor of the PSAMP INFO >>>>> model, to implement the idea sketched above. We will send an example to >>>>> this list in a few days. >>>>> >>>>> Regards, >>>>> >>>>> Juergen >>>>> >>>>> >>>>> --On 27.01.2004 23:55 h -0800 Jeff Meyer wrote: >>>>> >>>>>> The current info-model-02 specification contains references to XML >>>>>> type >>>>>> names and semantics borrowed directly from the XML-Schema >>>>>> specification as >>>>>> well as extensions. >>>>>> >>>>>> Currently these extensions borrow from existing work of IPDR as >>>>>> well as >>>>>> newly identified types currently specific to IPFIX. >>>>>> >>>>>> There are a few ways to address this. >>>>>> >>>>>> The following e-mail thread discusses the options and opinion of this >>>>>> editor as well as opinions from Andrew Norton who is involved in >>>>>> IETF's >>>>>> and IANA's work in utilizing XML in RFC's. >>>>>> >>>>>> >>>>>> Jeff, >>>>>> >>>>>> It would seem that this is all a matter of "taste" as any of these >>>>>> options >>>>>> technically work. Personally I would go with option 3; though it >>>>>> requires >>>>>> more coordination between organizations, to an outsider it would >>>>>> seem more >>>>>> cohesive. >>>>>> >>>>>> There is a practical difference between option 1 and option 3 in >>>>>> terms of >>>>>> setting the standard. With option 3, if IPDR upgrades their >>>>>> standard, the >>>>>> IPFIX group needs to do nothing to incorporate the changes. >>>>>> However, with >>>>>> option 1, IPFIX will have to >>>>>> standardize a new schema and issue new RFC's. >>>>>> >>>>>> -andy >>>>>> >>>>>> Jeff Meyer wrote: >>>>>> Hi Andy, >>>>>> >>>>>> I wanted to get your opinion on extending the XML-Schema type >>>>>> system for >>>>>> some specific information modeling requirements encountered by the >>>>>> IPFIX >>>>>> working group. >>>>>> >>>>>> IPFIX currently reuses about 15 types from XML-Schema directly, >>>>>> however >>>>>> there are several types which are worthwile to distinguish from an >>>>>> IPFIX >>>>>> persepective which are not defined by XML-Schema. >>>>>> >>>>>> These include types to identify timestamps of specific resolution >>>>>> (e.g. >>>>>> mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and >>>>>> one for >>>>>> UUIDs. >>>>>> >>>>>> Today most of these extension types are defined in the public NDM-U >>>>>> 3.1.1 >>>>>> specification from the industry consortium called IPDR.org. There >>>>>> are a >>>>>> couple which are not are related to the high resolution timestamps >>>>>> (uSec >>>>>> and nSec). >>>>>> >>>>>> The NDM-U 3.1.1 specificaiton is avaiable at >>>>>> http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically section >>>>>> A.4.4. >>>>>> >>>>>> The IPFIX-Info reference is available at: >>>>>> >>>>>> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-info-02.html#anchor4 >>>>>> >>>>>> >>>>>> >>>>>> This is a link to the specific secion in the HTML format of the >>>>>> info model >>>>>> based on RFC2629. >>>>>> >>>>>> >>>>>> The quesion at hand is whether to follow one of the following 3 >>>>>> options: >>>>>> >>>>>> 1. have a single XML-Schema which defines the extension types >>>>>> relevant >>>>>> to IPFIX and contained in the IPFIX namespace >>>>>> 2. reference the existing types targeted by IPDR and add only >>>>>> the new >>>>>> types specific to the IPFIX Schema >>>>>> 3. petition IPDR to define the remaining two IPFIX types for >>>>>> timestamps in their upcoming 3.5 specification (likely timeframe >>>>>> Feb. or >>>>>> March) >>>>>> >>>>>> I get the impression from IPFIX discussions that referencing IPDR is >>>>>> something that some vocal participants find objectionable, i.e. >>>>>> they would >>>>>> prefer to see option 1. >>>>>> >>>>>> My personal preference would be to go with option 3 or 2. I >>>>>> believe 3 is >>>>>> doable and would reduce the number of places where people have to >>>>>> look for >>>>>> things. Option 1 I see as creating some confusion in the space, but >>>>>> ultimately addressable through XSL >>>>>> or other mapping functions, if that's what it takes to get consensus. >>>>>> >>>>>> >>>>>> Any guidance on your part would be appreciated. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Jeff Meyer >>>>>> >>>>>> _________________________________________________________________ >>>>>> Get a FREE online virus check for your PC here, from McAfee. >>>>>> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963 >>>>>> >>>>>> >>>>>> -- >>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>> message >>>>>> body >>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>> "unsubscribe ipfix" in message body >>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _________________________________________________________________ >>>> Find high-speed =91net deals ? comparison-shop your local providers >>>> here. https://broadband.msn.com >>>> >>> >>> >>> >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> >> > > > -- > Sebastian Zander E-mail: zander@fokus.fraunhofer.de > Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 2 16:50:47 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15481 for ; Mon, 2 Feb 2004 16:50:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AnlqZ-0004fw-00 for ipfix-list@mil.doit.wisc.edu; Mon, 02 Feb 2004 15:43:11 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AnlqY-0004fq-00 for ipfix@net.doit.wisc.edu; Mon, 02 Feb 2004 15:43:10 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i12Lh6NC070474 for ; Mon, 2 Feb 2004 22:43:08 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i12Lh4qF070472 for ; Mon, 2 Feb 2004 22:43:04 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i12Lh3N8070469; Mon, 02 Feb 2004 22:43:04 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C3005100DED; Mon, 2 Feb 2004 22:42:59 +0100 (CET) Date: Mon, 02 Feb 2004 22:43:15 +0100 From: Juergen Quittek To: stbryant@cisco.com, bwijnen@lucent.com, allison mankin , ipfix@net.doit.wisc.edu Subject: [ipfix] Re: IPFIX requirements - security Message-ID: <2147483647.1075761794@[10.1.1.26]> In-Reply-To: <4017A0A6.2020907@cisco.com> References: <2147483647.1075253117@[10.1.1.26]> <4017A0A6.2020907@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Stewart, We changed the requirement for confidentiality from SHOULD to MUST in October. It was based on a comment from Allison: "Requirements on the ipfix implementation - the document is long and I wonder if the working group really meant the protocol's confidentiality and anonymization features to be so optional - SHOULD confidentiality, MAY anonymization. Just for implementation." So far there was an agreement on this change on the mailing list as well as at the last IPFIX session, where this particular issue was presented. This does not mean, that we may not discuss the issue anymore, but so far, we had an agreement. I see the higher implementation effort, but I also see that most new devices today implement IPsec anyway. So, I would be fine with both ways. Are there people on the mailing list who either agree or disagree? Please speak up. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de --On 28.01.2004 11:44 Uhr +0000 Stewart Bryant wrote: > I believe that the security requirements (below) which were > enhanced by the IESG are an unreasonable burden on many > implementations. > > The new requirements lack a measure of appropriateness which > needs to be incorporated in the definition. > > For example there is no point in providing greater > confidentiality in the IPFIX protocol than exists at the > observation point itself. > > There is no point in providing a level of integrity or > authenticity that exceeds the requirements of the collecting > application. > > Setting the baseline for operation over the public Internet > leads to the inevitable conclusion that IPFIX MUST be run > over IPsec, but that is absurd in situations where the > network design precludes the possibility of data leakage > (for example where the IPFIX traffic is carried over a > private management network). > > The net result of setting the bar at this level will be > either late and unnecessarily costly deployment of IPFIX, > or (more likely) the widespread deployment of non-compliant > IPFIX, thereby bringing the RFC into disrepute. > > Section 6.3.3 should therefore be reworded to something > of the following form: > > IPFIX data transferred from an exporting process to a > collecting process MUST NOT degrade the confidentiality of > the packet flows at the observation point. > > The method of transferring IPFIX data from the exporting > process to the collecting process MUST provide the level > of data integrity required by the collecting application. > > The authenticity of IPFIX data transferred from an exporting > process to a collecting process MUST be sufficient to meet > the application needs at the collector. > > - Stewart > > > Original text for reference: > > ==================== > > 6.3.3. Security > > Confidentiality of IPFIX data transferred from an exporting process > to a collecting process MUST be ensured. > > Integrity of IPFIX data transferred from an exporting process to a > collecting process MUST be ensured. > > Authenticity of IPFIX data transferred from an exporting process to a > collecting process MUST be ensured. > > ===================== > > 10. Security Considerations > > An IPFIX protocol must be capable of transporting data over the > public Internet. Therefore it cannot be excluded that an attacker > captures or modifies packets or inserts additional packets. > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 05:02:19 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00270 for ; Tue, 3 Feb 2004 05:02:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Anx0A-00067R-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 03:37:50 -0600 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Anx09-00067H-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 03:37:49 -0600 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2004 10:38:27 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i139bNL1026251; Tue, 3 Feb 2004 10:37:23 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp313.cisco.com [10.61.65.57]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA15771; Tue, 3 Feb 2004 09:37:43 GMT Message-ID: <401F6BE5.80801@cisco.com> Date: Tue, 03 Feb 2004 09:37:41 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Meyer CC: zander@fokus.fraunhofer.de, quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit >> but I agree to Juergen, Nevil >> and Stewart that the text should be the normative reference. I do not see >> the point of forcing people to use XML if they don't want to. > > > Do you mean "use" or "read" XML? Assuming that you have a working XSL > implementation the two forms are equivalent. > > But the point is that we should not require engineers to have a running XSL implementation just to check a normative statement. The IETF tradition, which has served us well over the years, is that we just need an ascii text viewer to read an IETF specification. >> I also do not >> see the point of extending the IM. Here I disagree, the IM must be extensible. > > > "hexBinary" is a poorly chosen name. If we embarked on reinventing > things every time we disliked the names, then maybe we could solve the > technology slump! Jobs for everyone! "4.7 hexBinary The type "hexBinary" represents a finite length string of octets." I am sure that if you asked most IETF members what a hexBinary was, they would say that it was the representation of a set of bits (a binary number) in hexadecimal notation. If it is anything other than that I think we need to find a better name. - Stewart -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 05:03:17 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00318 for ; Tue, 3 Feb 2004 05:03:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Anx2J-0006V8-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 03:40:03 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Anx2H-0006Uc-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 03:40:02 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i139dhL01126; Tue, 3 Feb 2004 10:39:43 +0100 (MET) Message-ID: <401F6BBF.7030907@fokus.fraunhofer.de> Date: Tue, 03 Feb 2004 10:37:03 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Meyer CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff Meyer wrote: > Sebastian, > > Comments inline... > > -- Jeff > > >> From: Sebastian Zander >> To: Jeff Meyer >> CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, >> stbryant@cisco.com, ipfix@net.doit.wisc.edu >> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >> vs.Appendix A >> Date: Mon, 02 Feb 2004 14:48:22 +0100 >> >> Jeff, >> >> I see the value of having an XML description > > > Good. > >> but I agree to Juergen, Nevil >> and Stewart that the text should be the normative reference. I do not see >> the point of forcing people to use XML if they don't want to. > > > Do you mean "use" or "read" XML? Assuming that you have a working XSL > implementation the two forms are equivalent. I would assume that most people who are not going to use XML won't read it. Why should they if the text contains the same information more readable? > >> I also do not >> see the point of extending the IM. > > > Huh? Take a look at the requirements document, section 6.2: > > The data model MUST be extensible for future attributes to be added. > Even if a set of attributes is fixed in the flow record, the data > model MUST provide a way of extending the record by configuration or > for certain implementations. > > The term "data model" is misused here, but obviously from the context > the intent is that extending the IM is a MUST. PSAMP is a case in point. When the text version is normative the IM is still extensible. > >> Most people will anyway read only the >> text and comment on this. So you have to do the XML editing anyway. > > > So you're saying one should write in XML? (I agree, but it seems > inconsistent with your previous statements?) Sure >> As for >> IPFIX IM extensions not even the PSAMP IM draft currently uses the XML >> model. > > > Read the thread more carefully. They did use XML, they just didn't > publish it, not very helpful. As it stands I would need to cut and > paste each subsection for each attribute of their work to operate with a > system that is capable of directly a single XML document. The result of using XML and not providing it is for the reader essentially the same as not using XML ;-) >> Even worse the use of XML schema types like hexBinary has caused some >> confusion >> among the authors. > > > "hexBinary" is a poorly chosen name. If we embarked on reinventing > things every time we disliked the names, then maybe we could solve the > technology slump! Jobs for everyone! The fact is that the type specifies how to encode binary field in XML which is not the job of the information model and which is the reason why Juergen and I propose to use a XML document instead of a schema. >> >> I don't think that the use of XML in the IETF is as widely accepted as >> the >> use of MIBs. And how many IETF drafts provide normative textual >> descriptions >> vs. how many provide normative XML schemas? > > > This seems to be simply an argument that change is bad. That if things > were one way before, embarking on something which might improve upon > them should be viewed with great skepticism. You miss the point. I'm not against change but I'm not convinced by your arguments. > Obviously as new work there are a lot more MIBs which have had > 10 > years to be built up vs. something which is proposed for IPFIX. > >> The W3C schema definition is not >> even accepted by the whole XML community. There are alternatives e.g. >> RELAX NG. > > > XML-Schema is the W3C specification. Plain and simple. Ultimately the > utility is agreeing on one piece of work, which W3C did. > >> >> Let's close this issue and move forward. > > > If both the XML and human readable forms are in the document, and > assuming the process of converting from XML->human readable is automated > using free and open tools, then I guess it really doesn't matter which > one calls normative. > > So, assuming we publish both, calling the text based normative to > benefit readers unfamiliar with XML is an acceptable compromise. Great! > If only human readable is contained in the document, as in the current > PSAMP document, then I still have an issue. You've taken away the more > useful artifact of the two artifacts, the XML document which can be > transformed into whatever you want it to be. Can we mandate that extensions provide XML? I have the feeling that this won't get consensus. Solution could be to recommend it. At least you can always produce the XML from the text. Assuming that authors use a consistent format this can be done automatically. I don't think that PSAMP is a big problem because it seems well aligned with IPFIX but in the future other extensions may be created from people not involved in the initial IPFIX or PSAMP work. > >> >> A further point is whether IPFIX will standardize how to store the >> information. >> 1) AFAIK the idea of MIBs is to have a virtual information store. Do >> we need an >> IPFIX MIB? (PSAMP has a MIP draft already...) >> 2) IMO the info model draft should focus on the definition of the >> information >> model and _not_ how to encode IPFIX information in XML. > > > The info model simply points out how because it is abstract and separate > from encoding and transport, it may be applied to other activities > dealing with IPFIX information. > > Because MIBs typically deal with virtual stores of instantenous (vs. > historical) information, they aren't very useful in the IPFIX context > where enormous volumes of individual records are streaming off the > device. Yes, RMON is an example of a MIB which invented a complex > indexing scheme to store historical information, while clever, I think > it also illustrates some of the limitations/irritations of working with > MIBs in this context. > > A file format, or DB on the other hand is a handy way to capture these. > Being able to "get this for free" seems like goodness to me. It appears to me that a MIB for the configuration of IPFIX devices could be a good idea. For IPFIX data I'm not sure either. RTFM is another example which has defined a MIB for flow data... Cheers, Sebastian >> >> Cheers, >> >> Sebastian >> >> Jeff Meyer wrote: >> >>> Juergen, >>> >>> I agree few protocols have formal model specs. SNMP, however, which >>> has as a key value proposition the means of extensibility chose to >>> define MIBs, quite formal. MIBs also suffer somewhat from difficulty >>> in reading along with some other issues inherited from ASN.1 which >>> are improved by XML. >>> >>> Since I believe one of the key aspects of IPFIX is the mechanism for >>> extension, I think we should learn from another IETF protocol which >>> seemed rather successful in addressing this requirement. >>> >>> So, I think maintaining the connection between the mechanism which >>> is available today in IPFIX-info to formally specify the model is >>> important, if there is an interest in drawing others to extend IPFIX >>> with information content which differs from IPFIX's initial focus. >>> >>> One approach would be to break out another document as part of >>> IPFIX, which would be something like "Formal IPFIX Information >>> Modeling". But I'm not particularly eager to create another document. >>> >>> -- Jeff >>> >>> >>>> From: Juergen Quittek >>>> To: Jeff Meyer , n.brownlee@auckland.ac.nz >>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>> vs.Appendix A >>>> Date: Thu, 29 Jan 2004 12:30:58 +0100 >>>> >>>> Jeff, >>>> >>>> We had this entire discussion already some time ago. >>>> >>>> For me, the main argument is that all IETF standards so far >>>> are human-readable. The XML document in the Appendix is hardly >>>> readable, while section 6 is well readable. >>>> >>>> You are requesting to move from a human-readable standard >>>> to a machine-readable standard. I understand that there are >>>> several good reasons to do so. But the change in the >>>> standardization approach is fundamental. >>>> >>>> This might be an issue for the ietf@ieft mailing list. >>>> However, so far very few protocols or models in the IETF >>>> have been formally defined. Looks like still the 'running >>>> code' approach dominates the 'well specified' approach. >>>> >>>> Regards, >>>> >>>> Juergen >>>> >>>> --On 28.01.2004 19:53 h -0800 Jeff Meyer wrote: >>>> >>>>> Nevil, >>>>> >>>>> My only contention would be that I did not do any direct data >>>>> entry for section 6. I.e. I wrote the XML-Schema ran it through >>>>> the publicly available stylesheet and free transform engine and >>>>> pasted it into the doc. >>>>> >>>>> Certainly it would be my hope that authors of additional >>>>> information models to be carried over IPFIX would follow the same >>>>> process, because then I can simply take their XML-Schema spec and >>>>> use it in a variety of tools. If I only get text, then I >>>>> have the tedious prospect of transcribing it. If equipment >>>>> providers favor a manual transcription process, it is certainly not >>>>> precluded. >>>>> >>>>> My understanding was that PSAMP might be using the XML technique >>>>> today, I believe it was Juergen who asked about the tools and I >>>>> passed along the pointer. >>>>> >>>>> If it is politically simpler to call section 6 normative but >>>>> indicate that authors of new models SHOULD create an XML-Schema >>>>> model and MAY machine translate these models to create the >>>>> normative text, then I could live with such a compromise. >>>>> >>>>> Simply excising this information as Stewart seems to be >>>>> advocating seems like a step backwards and I'm at a loss to see any >>>>> benefit from that. >>>>> >>>>> Regards, >>>>> >>>>> Jeff Meyer >>>>> >>>>> >>>>>> From: Nevil Brownlee >>>>>> To: Jeff Meyer >>>>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>> vs.Appendix A >>>>>> Date: Thu, 29 Jan 2004 13:02:07 +1300 >>>>>> >>>>>> Stewart and Jeff: >>>>>> >>>>>> > With the use of XSL stylesheets the XML style informaiton >>>>>> model could >>>>>> be >>>>>> > transformed automatically into any set of text one would want, >>>>>> e.g. IOS >>>>>> > commands to enable flags, HTML tables for presentation, RFC2629 >>>>>> entries >>>>>> in >>>>>> > an RFC document, etc. For a discussion and example of using >>>>>> free XSL >>>>>> tools >>>>>> > to process this you can see >>>>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html. >>>>>> >>>>>> Jeff's right in saying that XML is becoming more widely used >>>>>> within the >>>>>> IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially >>>>>> in the Applications Area) are using it. >>>>>> >>>>>> However, RFC 2629 explicitly says it doesn't address "IETF politics" >>>>>> issues. My take on that is that the text in section 6 of the Info >>>>>> Model >>>>>> draft is the normative version; Appendix A gives the xml because >>>>>> people >>>>>> may find it useful, but if they use it they should check that it >>>>>> really >>>>>> does match the (normative) text version. >>>>>> >>>>>> As for IPFIX WG consensus on this, in my view the document editors >>>>>> are free to use whatever tools they need to produce the actual >>>>>> drafts. >>>>>> Furthermore, including the xml as an appendix allows other people to >>>>>> use the xml for other purposes, which (I guess) is why the editors >>>>>> appended it to the draft. >>>>>> >>>>>> Does that make the situation clearer? >>>>>> >>>>>> ----------------------------------------------------------------------- >>>>>> >>>>>> Nevil Brownlee Director, Technology Development >>>>>> Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland >>>>>> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand >>>>>> >>>>>> >>>>>> ------------------------------------------------- >>>>>> This mail sent through University of Auckland >>>>>> http://www.auckland.ac.nz/ >>>>>> >>>>>> -- >>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>> message >>>>>> body >>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>> "unsubscribe ipfix" in message body >>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>>> >>>>> >>>>> _________________________________________________________________ >>>>> Learn how to choose, serve, and enjoy wine at Wine @ MSN. >>>>> http://wine.msn.com/ >>>>> >>>>> >>>>> -- >>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>> message body >>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>> "unsubscribe ipfix" in message body >>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> _________________________________________________________________ >>> There are now three new levels of MSN Hotmail Extra Storage! Learn >>> more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >> >> >> -- >> Sebastian Zander E-mail: >> zander@fokus.fraunhofer.de >> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >> D-10589 Berlin, Germany >> www.fokus.fraunhofer.de/usr/sebastian.zander >> >> >> >> > > _________________________________________________________________ > Let the new MSN Premium Internet Software make the most of your > high-speed experience. > http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 05:52:56 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02240 for ; Tue, 3 Feb 2004 05:52:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AnxeO-0000QC-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 04:19:24 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AnxeM-0000Q7-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 04:19:23 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i13AJIL06582; Tue, 3 Feb 2004 11:19:18 +0100 (MET) Message-ID: <401F7506.9040504@fokus.fraunhofer.de> Date: Tue, 03 Feb 2004 11:16:38 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may need IANA considerations References: <2147483647.1075471150@[10.1.1.171]> <2147483647.1075483972@[10.1.1.171]> <401E6769.8040402@fokus.fraunhofer.de> <2147483647.1075759804@[10.1.1.26]> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.fraunhofer.de id i13AJIL06582 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: quoted-printable Juergen Quittek wrote: > Sebastian, >=20 > --On 02.02.2004 16:06 Uhr +0100 Sebastian Zander wrote: >=20 >> Hi Juergen, >> >> good work! Some comments: >=20 >=20 > Thanks. >=20 >> - Do we really need the semantics attribute? Often the semantics are=20 >> already >> included in the description or even in the field name. I'd prefer=20 >> to have that in >> the description. >=20 >=20 > I copied them from draft -02. I am not really a fan of the semantics=20 > attribute, > but I did not find time to look for a good alternative. There is some=20 > benefit in > having them formally specified, but maybe just an explanation in the=20 > description > is fine. However, SMI distinguishes counters from gauges and plain=20 > integers. > I suggest to make this separate INFO model issue. Ok. Another issue: Current bitset not only has a different semantics but also needs a different presentation. Furthermore an octetArray might be used as bitset too. >> - No signed types yet (do we need them?) >=20 >=20 > Maybe another issue. It tried to find an example that requires negativ= e=20 > integers, > but I could not find any. Can soemone else? The delta time encoding (as currently defined in the protocol draft) need= s a signed type. >> - Do we need both enumeratedRange and Range? I'd prefer to have only=20 >> one element >> and let this be an enumeration or range. According to the current=20 >> definition you >> can specify both which might not be a good idea. >=20 >=20 > Well, an enumerated range may assigns semantics to each individual numb= ers, > while a plain range just defines maximum and minimum value. Again it=20 > would be > good to discuss this using an example. I think my comment wasn't too clear. Can we do this: 1: semantic1, 2: semantic2 1..50 From the value is pretty clear what is an enumeration and what a range. = Do we really need two tags? Actually enumeratedRange is not really used right now. It is used for e.g. samplingMethod _but_ in the Description! >=20 >> - Allow multiple reference elements instead of comma separation in the= =20 >> value? >=20 >=20 > I'm in favor of plain text in a single reference element. > You can list as many references as you like. >=20 >> - Make some attributes of field elements instead to make the first=20 >> line shorter >> and more readable. I'd suggest to have only name and *Type as=20 >> attributes. >=20 >=20 > It makes the first line shorter, but the number of lines larger. Exactly. IMO the first line should contain only the essential data allowi= ng the reader to skip the rest of the field definition. So e.g. I don't think that sementics is so important to must appear in the first line. Another proposal: It would be good to have a list (maybe two lists) generated from the XML document which contain only field ids and field na= mes and is sorted by 1) field id ( 2) name) for convenience of the reader and possible input for IANA. Cheers, Sebastian > Thanks, >=20 > Juergen >=20 >> Cheers, >> >> Sebastian >> >> Juergen Quittek wrote: >> >>> Jeff and all, >>> >>> Here is an alternative suggestion for the XML representation of the >>> info model that I developed together with Thomas, one of the editors = of >>> the PSAMP info model. This XML representation of the info model uses >>> an XML document (ipfix.xml) instead of an XML schema for specifying >>> the IPFIX information elements (or fields as the IPFIX protocol docum= ent >>> calls them). It just shows the first 11 elements defined in the curre= nt >>> draft, >>> but this is enough to show how this XML format looks like. >>> >>> File ipfix.xml can be used for automatically generating Section 6 of >>> the INFO model document as well as the XML schema used for the previo= us >>> version. The difference is that it uses abstract data types (as a da= ta >>> model should) instead of concrete ones. >>> >>> In addition, file ipfix.xsd contains an XML schema, that can be used >>> for validating the ipfix.xml file. It defines the properties of field= s/ >>> information elements that are used in ipfix.xml and it also includes >>> a definition of the abstract data types used in ipfix.xml. >>> >>> A nice consequence is that now not just Section 6 (field definitions) >>> but also Section 3 (Properties of an IPFIX Flow Attribute) and Sectio= n 4 >>> (Type Space) can be generated out of XML input. >>> >>> While section 6 is generated from ipfix.xml, Sections 3 and 4 are >>> generated from ipfix.xsd. >>> >>> Also the XML schema, we used for the previous versions of the INFO mo= del >>> can be generated out of the info model given in ipfix.xml. You just=20 >>> have >>> to define a mapping of the used abstract data types to concrete ones, >>> such as the IPDR definitions of IPv4 and IPv6 addresses. >>> >>> Conclusion: >>> - This version is a pure data model using abstract data types and=20 >>> without >>> any data encodings. >>> - It does not have dependencies on external data type definitions by=20 >>> IPDR. >>> - We do not loose anything, because the XML schema, we used so far >>> (including XML data types) can be generated automatically. >>> >>> Cheers, >>> >>> Juergen >>> >>> --On 30.01.2004 13:59 Uhr +0100 Juergen Quittek wrote: >>> >>>> Jeff, >>>> >>>> --On 29.01.2004 10:20 Uhr -0800 Jeff Meyer wrote: >>>> >>>>> Juergen, >>>>> >>>>> XML-Schema can be thought of as a pure Informaiton Model. >>>> >>>> >>>> >>>> Of course we can say: >>>> "Here is a combined info and data model, please ignore the data >>>> model part, >>>> because this standard is just about the info model." >>>> >>>> But this appears to be - at least - curious. >>>> >>>>> XML-Schema and XML also define productions which can be used to cre= ate >>>>> instance documents which are a data model and encoded in ASCII. >>>> >>>> >>>> >>>> This is what people call a data model. >>>> >>>>> IPDR takes full advantage of this by providing both >>>>> ASCII and Binary encodings from the same information model. >>>>> I.e. XML-Schema CAN be used AS IS as a pure information model. >>>> >>>> >>>> >>>> Yes and we can have exactly the same with what I suggested. >>>> The current version of the IPFIX INFO model does not contain >>>> a binary encoding, but it does contain an ASCII encoding. >>>> >>>>> Think of ASN.1 which has a Syntax and various encoding rules such >>>>> as BER, DER and others (even an XER). At some point you need to >>>>> formally define something, but that DOES NOT mean that the ASN.1 >>>>> syntax is just a BINARY encoding model nor is it just >>>>> one encoding model. Hence it IS separate from encoding. >>>>> >>>>> I view XML-Schema as the ASN.1 of the 21st century, only with a >>>>> much richer set of off the shelf and often free tools and other >>>>> interoperable components. >>>> >>>> >>>> >>>> I am sure you do not claim to inherit all properties of ASN.1 ;-) >>>> >>>>> Renaming things which are well defined (e.g. int) to duplicate >>>>> names (e.g. ipfix-int) is just a lot of unnecessary rework. >>>>> The temptation to simply redefine things is often large for >>>>> engineers. However in the long run reusing existing work >>>>> increases the likelihood that people will converge on certain >>>>> key patterns. >>>> >>>> >>>> >>>> It is not just renaming. It is replacing the concrete XML data type >>>> with an abstract one that can be mapped to XML as well as to many ot= her >>>> domains. And if you look at other INFO models, for example defined >>>> in CIM by the DMTF, always abstract data types are used in info mode= ls. >>>> Concrete ones are just used in data models. >>>> >>>> But even if you just consider it as renaming, it solves some problem= s. >>>> [And having worked as software engineer, I know that renaming=20 >>>> (e.g. by >>>> endless sets of #DEFINEs in C and C++ is not really unusual.] >>>> The problems we can solve are >>>> >>>> 1. We can replace 'hexBinary' by 'octetArray' or something else. >>>> Why should a binary data type use 'hex' in its name, if not ONL= Y >>>> with respect to its ASCII data encoding? And the encoding that >>>> really >>>> is of importance for IPFIX standardization is the binary encodi= ng >>>> by the protocol. >>>> >>>> 2. We do not have to refer to an IPDR document as a normative >>>> reference. >>>> This has three implications: >>>> >>>> First, I do not know if this is (so far) possible at all for IE= TF >>>> standard track documents. >>>> >>>> Second, I am not sure if the IPDR definition of IPv4 addresses >>>> and IPv6 >>>> addresses is what the IETF would like to use. It does not make >>>> sense >>>> to import IPv4 address XML encoding from the IPDR definitions=20 >>>> in one >>>> IETF standard and to use another source in another IETF standar= d. >>>> >>>> Third, if we use our own ABSTRACT data types, users can more=20 >>>> easily >>>> choose other XML encodings than the one promoted by IPDR. >>>> [Nothing against IPDR. I like it very much and my company is a >>>> member] >>>> Management systems and database builders/integrators may/will >>>> already >>>> have their own (XML) data types for flow recording. If we use a= n >>>> abstract data type we do not explicitly request them to use the >>>> IPDR definitions. >>>> >>>> >>>> Juergen >>>> >>>>> -- Jeff >>>>> >>>>> >>>>>> From: Juergen Quittek >>>>>> To: Jeff Meyer , ipfix@net.doit.wisc.edu >>>>>> Subject: Re: [ipfix] [issue] INFO-29 Namespace definitions may ne= ed >>>>>> IANA >>>>>> considerations >>>>>> Date: Thu, 29 Jan 2004 13:31:19 +0100 >>>>>> >>>>>> Jeff, >>>>>> >>>>>> I suggest to follow a completely different way of solving this >>>>>> problems such that everybody get what is needed. >>>>>> >>>>>> I see the cause in our dispute that the Appendix of the INFO model >>>>>> document is NOT just an information model, but a data model. >>>>>> >>>>>> As you argued well some time ago, it is a bad idea specifying >>>>>> binary encodings in the info model document, because this would >>>>>> already be a data model, which may vary among different protocols >>>>>> that potentially use the IPFIX INFO model. >>>>>> >>>>>> So, it is completely correct, that the binary encoding has become >>>>>> a part of the IPFIX PROTOCOL document. But still the IPFIX INFO >>>>>> model document contains a data model: the XML ASCII encoding for >>>>>> each information element. This is a data model. IMHO this is wrong= ! >>>>>> >>>>>> We should follow a clean approach by just specifying an >>>>>> information model. This would solve several of the open issues >>>>>> we are discussing, including the name space problem (iprd:), >>>>>> because we get completely independent of these data encoding issue= s >>>>>> and still can support IPDR data types in XML-based applications. >>>>>> >>>>>> Here is my suggestion: >>>>>> >>>>>> Currently, the Appendix is an XML schema defining which fixes ASCI= I >>>>>> encodings for each information element. I suggest to replace this >>>>>> XML schema by an XML document. The document would consist of a se= t >>>>>> of XML element, each of them specifying a single information eleme= nts >>>>>> with a set of attributes and/or contained XML elements exactly >>>>>> covering all properties of information elements as defined in >>>>>> section 3. >>>>>> (We can use a small, simple XML schema for checking consistency of= =20 >>>>>> this >>>>>> XML document.) >>>>>> >>>>>> Information elements defined this way would not have a standard XM= L, >>>>>> IPDR, or other data type (data model should be separated from info >>>>>> model), >>>>>> but would be defined just by English text, for example >>>>>> ipfix-int: integer value in the range of -2147483648 to 214748364= 7 >>>>>> ipfix-dateTime: number of seconds since Jan 1st, 1970, 00:00 h >>>>>> ipfix-ipv4address: integral representation of a 32 bit IPv4 addre= ss >>>>>> ... >>>>>> We would create our own IPFIX type space for the information=20 >>>>>> elements. >>>>>> >>>>>> Based on this pure information model, we can use XSLT (as we do it= =20 >>>>>> now) >>>>>> to generate all the text in Section 6 describing the information >>>>>> elements. >>>>>> >>>>>> Now, if you want to realize an XML-based application, you can take= =20 >>>>>> the >>>>>> new XML document and use XSLT for automatic generation of a schema= , >>>>>> such >>>>>> as the one we have in the Appendix of the current version of the >>>>>> INFO model >>>>>> document. You see, you still have all the advantages of the machi= ne- >>>>>> readability and all opportunities to generate IPFIX XML parsers >>>>>> automatically. >>>>>> But with the suggested change you would also have a clean >>>>>> information model >>>>>> in the IPFIX INFO document avoiding all discussions on whether or >>>>>> not to >>>>>> use the IPDR data types. >>>>>> >>>>>> I am currently working together with Thomas, editor of the PSAMP I= NFO >>>>>> model, to implement the idea sketched above. We will send an=20 >>>>>> example to >>>>>> this list in a few days. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Juergen >>>>>> >>>>>> >>>>>> --On 27.01.2004 23:55 h -0800 Jeff Meyer wrote: >>>>>> >>>>>>> The current info-model-02 specification contains references to XM= L >>>>>>> type >>>>>>> names and semantics borrowed directly from the XML-Schema >>>>>>> specification as >>>>>>> well as extensions. >>>>>>> >>>>>>> Currently these extensions borrow from existing work of IPDR as >>>>>>> well as >>>>>>> newly identified types currently specific to IPFIX. >>>>>>> >>>>>>> There are a few ways to address this. >>>>>>> >>>>>>> The following e-mail thread discusses the options and opinion of=20 >>>>>>> this >>>>>>> editor as well as opinions from Andrew Norton who is involved in >>>>>>> IETF's >>>>>>> and IANA's work in utilizing XML in RFC's. >>>>>>> >>>>>>> >>>>>>> Jeff, >>>>>>> >>>>>>> It would seem that this is all a matter of "taste" as any of thes= e >>>>>>> options >>>>>>> technically work. Personally I would go with option 3; though it >>>>>>> requires >>>>>>> more coordination between organizations, to an outsider it would >>>>>>> seem more >>>>>>> cohesive. >>>>>>> >>>>>>> There is a practical difference between option 1 and option 3 in >>>>>>> terms of >>>>>>> setting the standard. With option 3, if IPDR upgrades their >>>>>>> standard, the >>>>>>> IPFIX group needs to do nothing to incorporate the changes. >>>>>>> However, with >>>>>>> option 1, IPFIX will have to >>>>>>> standardize a new schema and issue new RFC's. >>>>>>> >>>>>>> -andy >>>>>>> >>>>>>> Jeff Meyer wrote: >>>>>>> Hi Andy, >>>>>>> >>>>>>> I wanted to get your opinion on extending the XML-Schema type >>>>>>> system for >>>>>>> some specific information modeling requirements encountered by th= e >>>>>>> IPFIX >>>>>>> working group. >>>>>>> >>>>>>> IPFIX currently reuses about 15 types from XML-Schema directly, >>>>>>> however >>>>>>> there are several types which are worthwile to distinguish from a= n >>>>>>> IPFIX >>>>>>> persepective which are not defined by XML-Schema. >>>>>>> >>>>>>> These include types to identify timestamps of specific resolution >>>>>>> (e.g. >>>>>>> mSec, uSec, nSec), addressing types (IPv4 and IPv6 addresses) and >>>>>>> one for >>>>>>> UUIDs. >>>>>>> >>>>>>> Today most of these extension types are defined in the public NDM= -U >>>>>>> 3.1.1 >>>>>>> specification from the industry consortium called IPDR.org. Ther= e >>>>>>> are a >>>>>>> couple which are not are related to the high resolution timestamp= s >>>>>>> (uSec >>>>>>> and nSec). >>>>>>> >>>>>>> The NDM-U 3.1.1 specificaiton is avaiable at >>>>>>> http://www.ipdr.org/documents/NDM-U_3.1.1.pdf and specifically=20 >>>>>>> section >>>>>>> A.4.4. >>>>>>> >>>>>>> The IPFIX-Info reference is available at: >>>>>>> >>>>>>> http://www.ipdr.org/documents/ipfix/infomodel/draft-ietf-ipfix-in= fo-02.html#anchor4=20 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is a link to the specific secion in the HTML format of the >>>>>>> info model >>>>>>> based on RFC2629. >>>>>>> >>>>>>> >>>>>>> The quesion at hand is whether to follow one of the following 3 >>>>>>> options: >>>>>>> >>>>>>> 1. have a single XML-Schema which defines the extension types >>>>>>> relevant >>>>>>> to IPFIX and contained in the IPFIX namespace >>>>>>> 2. reference the existing types targeted by IPDR and add only >>>>>>> the new >>>>>>> types specific to the IPFIX Schema >>>>>>> 3. petition IPDR to define the remaining two IPFIX types for >>>>>>> timestamps in their upcoming 3.5 specification (likely timeframe >>>>>>> Feb. or >>>>>>> March) >>>>>>> >>>>>>> I get the impression from IPFIX discussions that referencing IPDR= is >>>>>>> something that some vocal participants find objectionable, i.e. >>>>>>> they would >>>>>>> prefer to see option 1. >>>>>>> >>>>>>> My personal preference would be to go with option 3 or 2. I >>>>>>> believe 3 is >>>>>>> doable and would reduce the number of places where people have to >>>>>>> look for >>>>>>> things. Option 1 I see as creating some confusion in the space, = but >>>>>>> ultimately addressable through XSL >>>>>>> or other mapping functions, if that's what it takes to get=20 >>>>>>> consensus. >>>>>>> >>>>>>> >>>>>>> Any guidance on your part would be appreciated. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Jeff Meyer >>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> Get a FREE online virus check for your PC here, from McAfee. >>>>>>> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963 >>>>>>> >>>>>>> >>>>>>> --=20 >>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>> message >>>>>>> body >>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>> "unsubscribe ipfix" in message body >>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _________________________________________________________________ >>>>> Find high-speed =91net deals ? comparison-shop your local providers >>>>> here. https://broadband.msn.com >>>>> >>>> >>>> >>>> >>>> >>>> >>>> --=20 >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>> message body >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>> "unsubscribe ipfix" in message body >>>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >>> >>> >>> >>> >> >> >> --=20 >> Sebastian Zander E-mail:=20 >> zander@fokus.fraunhofer.de >> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >> D-10589 Berlin, Germany =20 >> www.fokus.fraunhofer.de/usr/sebastian.zander >> >> >> >> >=20 >=20 >=20 >=20 --=20 Sebastian Zander E-mail: zander@fokus.fraunhofer.= de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/seba= stian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 05:58:55 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02346 for ; Tue, 3 Feb 2004 05:58:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Anxxg-0001A0-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 04:39:20 -0600 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Anxxf-00019v-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 04:39:19 -0600 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 03 Feb 2004 11:39:57 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i13AcsL1016183; Tue, 3 Feb 2004 11:38:54 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp313.cisco.com [10.61.65.57]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA17872; Tue, 3 Feb 2004 10:39:15 GMT Message-ID: <401F7A4E.30906@cisco.com> Date: Tue, 03 Feb 2004 10:39:10 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: bwijnen@lucent.com, allison mankin , ipfix@net.doit.wisc.edu Subject: [ipfix] Re: IPFIX requirements - security References: <2147483647.1075253117@[10.1.1.26]> <4017A0A6.2020907@cisco.com> <2147483647.1075761794@[10.1.1.26]> In-Reply-To: <2147483647.1075761794@[10.1.1.26]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Stewart, > > We changed the requirement for confidentiality from SHOULD to MUST in > October. > It was based on a comment from Allison: > > "Requirements on the ipfix implementation - the document is long and > I wonder if the working group really meant the protocol's > confidentiality > and anonymization features to be so optional - SHOULD confidentiality, > MAY anonymization. Just for implementation." > > So far there was an agreement on this change on the mailing list as well as > at the last IPFIX session, where this particular issue was presented. > This does not mean, that we may not discuss the issue anymore, but so far, > we had an agreement. > > I see the higher implementation effort, but I also see that most new > devices > today implement IPsec anyway. So, I would be fine with both ways. > On the other hand we also talk about the performance issues of IPFIX, and IPsec will mean either a lot of CPU cycles or hardware support. Also to be of use in a reasonable timeframe, IPFIX has to work on existing platforms. Now I do not have any problem with requiring the system to provide confidentially etc, it's just that the way that the requirement is written, the protocol MUST support it, which constrains the implementation choices. - Stewart > Are there people on the mailing list who either agree or disagree? > Please speak up. > > Thanks, > > Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 06:14:18 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03126 for ; Tue, 3 Feb 2004 06:14:18 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AnyOK-0002lP-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 05:06:52 -0600 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AnyOJ-0002lH-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 05:06:51 -0600 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 03 Feb 2004 03:06:53 -0800 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i13B6l50024327; Tue, 3 Feb 2004 03:06:47 -0800 (PST) Received: from cisco.com (ams-clip-vpn-dhcp313.cisco.com [10.61.65.57]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA18875; Tue, 3 Feb 2004 11:06:44 GMT Message-ID: <401F80C2.10607@cisco.com> Date: Tue, 03 Feb 2004 11:06:42 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX status, propose not meeting at 59th IETF (Seoul) References: <20040108161700.A13837@doit.wisc.edu> <2147483647.1075293702@[10.1.1.171]> In-Reply-To: <2147483647.1075293702@[10.1.1.171]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I agree with Juergen that we have a lot of work still to do. Please would the chairs indicate whether they indend to schedule a meeting or not. If the issue is that the chairs are unable to travel to Korea, I am sure that a suitable deputy could be appointed for the meeting itself. - Stewart Juergen Quittek wrote: > Dave, > > The mailing list is very active and there are still many open issues. > > I doubt that we will solve all of them within a month, although > the issues are not fundamental (except the decision on the IPFIX > default transport protocol which IMHO has not yet been made in a > clearly visible way). > > So, I guess we would have a lot of discussion points in Seoul, > particularly concerning IPFIX transport (how to handle reconnection > after temporary disconnection, error recovery if sequence counters > fail, protection against DoS acctacks, ... , and the TCP section > in the protocol draft is still empty and needs to be written and > discussed). > > So, my guess is that there is indeed a need for an IPFIX session > at Seoul. > > Thanks, > > Juergen > > > --On 08.01.2004 16:17 Uhr -0600 Dave Plonka wrote: > >> IPFIXers, >> >> Please review the status update (thanks to Nevil) below and >> this proposal from Nevil and I: >> >> At this stage there don't appear to be any 'show-stopper' issues, which >> raises the question, "Do we need to hold an IPFIX meeting in Seoul?" >> >> Your WG co-chairs feel that what's needed is concentrated work to >> finish the four IPFIX drafts so that the protocol can be implemented >> from the definition. It would be great to get the drafts to WG last >> call by late February and finished by the end of March. >> >> How do WG members feel about this proposal? >> >> If we were to meet in Seoul, what are the main issues we'd need to >> discuss? It would be quite a challenge for either of us to attend in >> Seoul, so any such issues would have to be compelling. >> >> Cheers, >> Dave & Nevil >> >> -- >> >> IPFIX WG: Status as of 9 Jan 04 >> ------------------------------- >> >> 1. WG Drafts being considered by IESG >> >> - Requirements Draft, version 13 >> - Evaluation draft: >> Simon is revising following comments from Bert (Ops AD) >> >> 2. Milestones >> >> Have been reivsed as discussed at Minneapolis meeting. Looking >> at them on the IPFIX charter page, I see that I've left out the >> PROTOCOL draft - that goes along with the ARCHITECTURE, >> INFO_MODEL and APPLICABILITY drafts. >> >> Those four drafts have a milestone date saying they'll be >> submitted to IESG by May 04. Note that we set that date assuming >> that they'd all be in their final stages by the next meeting >> (Seoul, 29 Feb - 5 Mar 04). Since other WGs (e.g. PSAMP) are >> waiting for them, we would be good to get them done before that! >> >> 3. Current drafts >> >> These are the four referred to in capitals above. There's been >> quite a lot of mailing-list discussion of various issues relating >> to PROTOCOL and INFO_MODEL in the last month or so, which is >> great. Also, that discussion has been fairly well-structured, >> i.e. we've managed to keep the issues separate by using their >> issue number in the subject lines. >> >> -- >> plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF >> Madison, WI >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 10:10:19 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12116 for ; Tue, 3 Feb 2004 10:10:19 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ao1uU-0002xS-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 08:52:18 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ao1uT-0002xM-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 08:52:17 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i13EqDNA030218 for ; Tue, 3 Feb 2004 15:52:14 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i13EqDej030216 for ; Tue, 3 Feb 2004 15:52:13 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i13EqBN8030211; Tue, 03 Feb 2004 15:52:13 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id CF3DCFFEB3; Tue, 3 Feb 2004 15:52:09 +0100 (CET) Date: Tue, 03 Feb 2004 15:52:29 +0100 From: Juergen Quittek To: stbryant@cisco.com Cc: bwijnen@lucent.com, allison mankin , ipfix@net.doit.wisc.edu Subject: [ipfix] Re: IPFIX requirements - security Message-ID: <2147483647.1075823549@[10.1.1.171]> In-Reply-To: <401F7A4E.30906@cisco.com> References: <2147483647.1075253117@[10.1.1.26]> <4017A0A6.2020907@cisco.com> <2147483647.1075761794@[10.1.1.26]> <401F7A4E.30906@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, What shall we do with Stewart's issue? The requirements draft is under IESG review. Shall we call it back from there? Juergen --On 03.02.2004 10:39 Uhr +0000 Stewart Bryant wrote: > > > Juergen Quittek wrote: > >> Stewart, >> >> We changed the requirement for confidentiality from SHOULD to MUST in >> October. >> It was based on a comment from Allison: >> >> "Requirements on the ipfix implementation - the document is long and >> I wonder if the working group really meant the protocol's >> confidentiality >> and anonymization features to be so optional - SHOULD confidentiality, >> MAY anonymization. Just for implementation." >> >> So far there was an agreement on this change on the mailing list as well as >> at the last IPFIX session, where this particular issue was presented. >> This does not mean, that we may not discuss the issue anymore, but so far, >> we had an agreement. >> >> I see the higher implementation effort, but I also see that most new >> devices >> today implement IPsec anyway. So, I would be fine with both ways. >> > > On the other hand we also talk about the performance issues of IPFIX, > and IPsec will mean either a lot of CPU cycles or hardware support. > Also to be of use in a reasonable timeframe, IPFIX has to work on > existing platforms. > > Now I do not have any problem with requiring the system to provide > confidentially etc, it's just that the way that the requirement > is written, the protocol MUST support it, which constrains the > implementation choices. > > - Stewart > >> Are there people on the mailing list who either agree or disagree? >> Please speak up. >> >> Thanks, >> >> Juergen > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 10:15:49 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12912 for ; Tue, 3 Feb 2004 10:15:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ao29e-0003WD-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 09:07:58 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ao29d-0003Vw-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 09:07:57 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i13F7i917996; Tue, 3 Feb 2004 16:07:44 +0100 (MET) Message-ID: <401FB8A0.8000907@fokus.fraunhofer.de> Date: Tue, 03 Feb 2004 16:05:04 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stbryant@cisco.com CC: Juergen Quittek , plonka@doit.wisc.edu, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX status, propose not meeting at 59th IETF (Seoul) References: <20040108161700.A13837@doit.wisc.edu> <2147483647.1075293702@[10.1.1.171]> <401F80C2.10607@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit I also second Juergen proposal for a meeting. There are many open issues which need to be discussed and solved. Cheers, Sebastian Stewart Bryant wrote: > I agree with Juergen that we have a lot of work still to do. > > Please would the chairs indicate whether they indend to schedule > a meeting or not. If the issue is that the chairs are unable to > travel to Korea, I am sure that a suitable deputy could be > appointed for the meeting itself. > > - Stewart > > > Juergen Quittek wrote: > >> Dave, >> >> The mailing list is very active and there are still many open issues. >> >> I doubt that we will solve all of them within a month, although >> the issues are not fundamental (except the decision on the IPFIX >> default transport protocol which IMHO has not yet been made in a >> clearly visible way). >> >> So, I guess we would have a lot of discussion points in Seoul, >> particularly concerning IPFIX transport (how to handle reconnection >> after temporary disconnection, error recovery if sequence counters >> fail, protection against DoS acctacks, ... , and the TCP section >> in the protocol draft is still empty and needs to be written and >> discussed). >> >> So, my guess is that there is indeed a need for an IPFIX session >> at Seoul. >> >> Thanks, >> >> Juergen >> >> >> --On 08.01.2004 16:17 Uhr -0600 Dave Plonka wrote: >> >>> IPFIXers, >>> >>> Please review the status update (thanks to Nevil) below and >>> this proposal from Nevil and I: >>> >>> At this stage there don't appear to be any 'show-stopper' issues, which >>> raises the question, "Do we need to hold an IPFIX meeting in Seoul?" >>> >>> Your WG co-chairs feel that what's needed is concentrated work to >>> finish the four IPFIX drafts so that the protocol can be implemented >>> from the definition. It would be great to get the drafts to WG last >>> call by late February and finished by the end of March. >>> >>> How do WG members feel about this proposal? >>> >>> If we were to meet in Seoul, what are the main issues we'd need to >>> discuss? It would be quite a challenge for either of us to attend in >>> Seoul, so any such issues would have to be compelling. >>> >>> Cheers, >>> Dave & Nevil >>> >>> -- >>> >>> IPFIX WG: Status as of 9 Jan 04 >>> ------------------------------- >>> >>> 1. WG Drafts being considered by IESG >>> >>> - Requirements Draft, version 13 >>> - Evaluation draft: >>> Simon is revising following comments from Bert (Ops AD) >>> >>> 2. Milestones >>> >>> Have been reivsed as discussed at Minneapolis meeting. Looking >>> at them on the IPFIX charter page, I see that I've left out the >>> PROTOCOL draft - that goes along with the ARCHITECTURE, >>> INFO_MODEL and APPLICABILITY drafts. >>> >>> Those four drafts have a milestone date saying they'll be >>> submitted to IESG by May 04. Note that we set that date assuming >>> that they'd all be in their final stages by the next meeting >>> (Seoul, 29 Feb - 5 Mar 04). Since other WGs (e.g. PSAMP) are >>> waiting for them, we would be good to get them done before that! >>> >>> 3. Current drafts >>> >>> These are the four referred to in capitals above. There's been >>> quite a lot of mailing-list discussion of various issues relating >>> to PROTOCOL and INFO_MODEL in the last month or so, which is >>> great. Also, that discussion has been fairly well-structured, >>> i.e. we've managed to keep the issues separate by using their >>> issue number in the subject lines. >>> >>> -- >>> plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF >>> Madison, WI >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>> message body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >> >> >> >> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 10:24:05 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13657 for ; Tue, 3 Feb 2004 10:24:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ao25o-0003SY-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 09:04:00 -0600 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ao25n-0003ST-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 09:03:59 -0600 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i13F3hl11207 for ; Tue, 3 Feb 2004 09:03:45 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 16:03:37 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4EB@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Juergen Quittek'" , stbryant@cisco.com Cc: "Wijnen, Bert (Bert)" , allison mankin , "David Kessens (E-mail)" , ipfix@net.doit.wisc.edu Subject: [ipfix] RE: IPFIX requirements - security Date: Tue, 3 Feb 2004 16:03:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Precedence: bulk Sender: majordomo listserver You can call it back, but I doubt you can get away with what Stewart wants. Thanks, Bert > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: dinsdag 3 februari 2004 15:52 > To: stbryant@cisco.com > Cc: bwijnen@lucent.com; allison mankin; ipfix@net.doit.wisc.edu > Subject: Re: IPFIX requirements - security > > > Dear all, > > What shall we do with Stewart's issue? > > The requirements draft is under IESG review. > Shall we call it back from there? > > Juergen > > > --On 03.02.2004 10:39 Uhr +0000 Stewart Bryant wrote: > > > > > > > Juergen Quittek wrote: > > > >> Stewart, > >> > >> We changed the requirement for confidentiality from SHOULD > to MUST in > >> October. > >> It was based on a comment from Allison: > >> > >> "Requirements on the ipfix implementation - the document > is long and > >> I wonder if the working group really meant the protocol's > >> confidentiality > >> and anonymization features to be so optional - SHOULD > confidentiality, > >> MAY anonymization. Just for implementation." > >> > >> So far there was an agreement on this change on the > mailing list as well as > >> at the last IPFIX session, where this particular issue was > presented. > >> This does not mean, that we may not discuss the issue > anymore, but so far, > >> we had an agreement. > >> > >> I see the higher implementation effort, but I also see > that most new > >> devices > >> today implement IPsec anyway. So, I would be fine with both ways. > >> > > > > On the other hand we also talk about the performance issues > of IPFIX, > > and IPsec will mean either a lot of CPU cycles or hardware support. > > Also to be of use in a reasonable timeframe, IPFIX has to work on > > existing platforms. > > > > Now I do not have any problem with requiring the system to provide > > confidentially etc, it's just that the way that the requirement > > is written, the protocol MUST support it, which constrains the > > implementation choices. > > > > - Stewart > > > >> Are there people on the mailing list who either agree or disagree? > >> Please speak up. > >> > >> Thanks, > >> > >> Juergen > > > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 12:32:54 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20232 for ; Tue, 3 Feb 2004 12:32:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ao4Fs-0000rP-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 11:22:32 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ao4Fr-0000rK-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 11:22:31 -0600 Date: Tue, 3 Feb 2004 11:22:31 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX meeting at 59th IETF (Seoul) Message-ID: <20040203112231.A28839@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <20040108161700.A13837@doit.wisc.edu> <2147483647.1075293702@[10.1.1.171]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <2147483647.1075293702@[10.1.1.171]>; from quittek@ccrle.nec.de on Wed, Jan 28, 2004 at 12:41:42PM +0100 X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-W-SUBRNG4, subscript 4 range error, PC=00000000, PS=0000058A X-Shakespearean-Insult: Thou reeky dizzy-eyed coxcomb Precedence: bulk Sender: majordomo listserver IPFIXers, After the recent follow-ups expressing interest in meeting in Seoul, and our talking with the ADs, we have decided to request a meeting time for IPFIX at the 59th IETF in Seoul. The chairs suggest that this meeting focus on preparing and discussing a list of editorial issues with IPFIX documents, as deemed necessary by the draft editors present. Unfortunately, Nevil and I will not be attending the upcoming meeting due to other commitments. However, Juergen Quittek (the PSAMP cochair, and an IPFIX document editor) has offered to preside over the meeting, so we'll ask him to serve as chair for this one meeting. Thanks, Juergen! I apologize for this late turn of events if it has made it hard for anyone's travel plans. However, note that the narrowed focus of this upcoming meeting should mean that we can all participate effectively even if we can't attend. Had an IPFIX meeting not been scheduled (as proposed earlier), the attending editors would have taken the opportunity in Seoul to meet anyway, so a real meeting will allow others to participate in that as well. Dave & Nevil -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 3 22:28:32 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19804 for ; Tue, 3 Feb 2004 22:28:31 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AoDMc-0006TV-00 for ipfix-list@mil.doit.wisc.edu; Tue, 03 Feb 2004 21:06:06 -0600 Received: from bay3-f30.bay3.hotmail.com ([65.54.169.30] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AoDMb-0006TP-00 for ipfix@net.doit.wisc.edu; Tue, 03 Feb 2004 21:06:05 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 3 Feb 2004 19:06:04 -0800 Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP; Wed, 04 Feb 2004 03:06:04 GMT X-Originating-IP: [216.113.168.128] X-Originating-Email: [inetpix@msn.com] X-Sender: inetpix@msn.com From: "Jeff Meyer" To: zander@fokus.fraunhofer.de Cc: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A Date: Tue, 03 Feb 2004 19:06:04 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Feb 2004 03:06:04.0801 (UTC) FILETIME=[D3BAEF10:01C3EACB] Precedence: bulk Sender: majordomo listserver Sebastian, So it sounds like consensus is that the information model will call section 6 the normative description of the information carried by IPFIX. The rationale being that interested parties will find it easier to review in this format and that any use of XML is optional in the IPFIX context. Appendix A (XML format) will remain, possibly being rolled to the XML format used by PSAMP, (waiting for those XSL stylesheets;-) The document will recommend that authors of IM extensions SHOULD use the XML format for authoring and utilize tools (pointers included in non normative reference section) to generate the normative "human readable" text and SHOULD include an XML based IM if one is produced. -- Jeff >From: Sebastian Zander >To: Jeff Meyer >CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, >ipfix@net.doit.wisc.edu >Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >vs.Appendix A >Date: Tue, 03 Feb 2004 10:37:03 +0100 > >Jeff Meyer wrote: >>Sebastian, >> >> Comments inline... >> >>-- Jeff >> >> >>>From: Sebastian Zander >>>To: Jeff Meyer >>>CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, >>> ipfix@net.doit.wisc.edu >>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>vs.Appendix A >>>Date: Mon, 02 Feb 2004 14:48:22 +0100 >>> >>>Jeff, >>> >>>I see the value of having an XML description >> >> >>Good. >> >>>but I agree to Juergen, Nevil >>>and Stewart that the text should be the normative reference. I do not see >>>the point of forcing people to use XML if they don't want to. >> >> >>Do you mean "use" or "read" XML? Assuming that you have a working XSL >>implementation the two forms are equivalent. > >I would assume that most people who are not going to use XML won't read it. >Why should they if the text contains the same information more readable? > >> >>>I also do not >>>see the point of extending the IM. >> >> >>Huh? Take a look at the requirements document, section 6.2: >> >> The data model MUST be extensible for future attributes to be added. >> Even if a set of attributes is fixed in the flow record, the data >> model MUST provide a way of extending the record by configuration or >> for certain implementations. >> >>The term "data model" is misused here, but obviously from the context the >>intent is that extending the IM is a MUST. PSAMP is a case in point. > >When the text version is normative the IM is still extensible. > >> >>>Most people will anyway read only the >>>text and comment on this. So you have to do the XML editing anyway. >> >> >>So you're saying one should write in XML? (I agree, but it seems >>inconsistent with your previous statements?) > >Sure > >>>As for >>>IPFIX IM extensions not even the PSAMP IM draft currently uses the XML >>>model. >> >> >>Read the thread more carefully. They did use XML, they just didn't >>publish it, not very helpful. As it stands I would need to cut and paste >>each subsection for each attribute of their work to operate with a system >>that is capable of directly a single XML document. > >The result of using XML and not providing it is for the reader >essentially the same as not using XML ;-) > >>>Even worse the use of XML schema types like hexBinary has caused some >>>confusion >>>among the authors. >> >> >>"hexBinary" is a poorly chosen name. If we embarked on reinventing things >>every time we disliked the names, then maybe we could solve the technology >>slump! Jobs for everyone! > >The fact is that the type specifies how to encode binary field in XML which >is not the job of the information model and which is the reason why Juergen >and I propose to use a XML document instead of a schema. > >>> >>>I don't think that the use of XML in the IETF is as widely accepted as >>>the >>>use of MIBs. And how many IETF drafts provide normative textual >>>descriptions >>>vs. how many provide normative XML schemas? >> >> >>This seems to be simply an argument that change is bad. That if things >>were one way before, embarking on something which might improve upon them >>should be viewed with great skepticism. > >You miss the point. I'm not against change but I'm not convinced by your >arguments. > >>Obviously as new work there are a lot more MIBs which have had > 10 years >>to be built up vs. something which is proposed for IPFIX. >> >>>The W3C schema definition is not >>>even accepted by the whole XML community. There are alternatives e.g. >>>RELAX NG. >> >> >>XML-Schema is the W3C specification. Plain and simple. Ultimately the >>utility is agreeing on one piece of work, which W3C did. >> >>> >>>Let's close this issue and move forward. >> >> >>If both the XML and human readable forms are in the document, and assuming >>the process of converting from XML->human readable is automated using free >>and open tools, then I guess it really doesn't matter which one calls >>normative. >> >>So, assuming we publish both, calling the text based normative to benefit >>readers unfamiliar with XML is an acceptable compromise. > >Great! > >>If only human readable is contained in the document, as in the current >>PSAMP document, then I still have an issue. You've taken away the more >>useful artifact of the two artifacts, the XML document which can be >>transformed into whatever you want it to be. > >Can we mandate that extensions provide XML? I have the feeling that this >won't get consensus. Solution could be to recommend it. > >At least you can always produce the XML from the text. Assuming that >authors >use a consistent format this can be done automatically. > >I don't think that PSAMP is a big problem because it seems well aligned >with >IPFIX but in the future other extensions may be created from people not >involved in the initial IPFIX or PSAMP work. > >> >>> >>>A further point is whether IPFIX will standardize how to store the >>>information. >>>1) AFAIK the idea of MIBs is to have a virtual information store. Do we >>>need an >>> IPFIX MIB? (PSAMP has a MIP draft already...) >>>2) IMO the info model draft should focus on the definition of the >>>information >>> model and _not_ how to encode IPFIX information in XML. >> >> >>The info model simply points out how because it is abstract and separate >>from encoding and transport, it may be applied to other activities dealing >>with IPFIX information. >> >>Because MIBs typically deal with virtual stores of instantenous (vs. >>historical) information, they aren't very useful in the IPFIX context >>where enormous volumes of individual records are streaming off the device. >> Yes, RMON is an example of a MIB which invented a complex indexing >>scheme to store historical information, while clever, I think it also >>illustrates some of the limitations/irritations of working with MIBs in >>this context. >> >>A file format, or DB on the other hand is a handy way to capture these. >>Being able to "get this for free" seems like goodness to me. > >It appears to me that a MIB for the configuration of IPFIX devices could be >a good idea. > >For IPFIX data I'm not sure either. RTFM is another example which has >defined >a MIB for flow data... > >Cheers, > >Sebastian > >>> >>>Cheers, >>> >>>Sebastian >>> >>>Jeff Meyer wrote: >>> >>>>Juergen, >>>> >>>> I agree few protocols have formal model specs. SNMP, however, which >>>>has as a key value proposition the means of extensibility chose to >>>>define MIBs, quite formal. MIBs also suffer somewhat from difficulty in >>>>reading along with some other issues inherited from ASN.1 which are >>>>improved by XML. >>>> >>>> Since I believe one of the key aspects of IPFIX is the mechanism for >>>>extension, I think we should learn from another IETF protocol which >>>>seemed rather successful in addressing this requirement. >>>> >>>> So, I think maintaining the connection between the mechanism which is >>>>available today in IPFIX-info to formally specify the model is >>>>important, if there is an interest in drawing others to extend IPFIX >>>>with information content which differs from IPFIX's initial focus. >>>> >>>> One approach would be to break out another document as part of IPFIX, >>>>which would be something like "Formal IPFIX Information Modeling". But >>>>I'm not particularly eager to create another document. >>>> >>>>-- Jeff >>>> >>>> >>>>>From: Juergen Quittek >>>>>To: Jeff Meyer , n.brownlee@auckland.ac.nz >>>>>CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>vs.Appendix A >>>>>Date: Thu, 29 Jan 2004 12:30:58 +0100 >>>>> >>>>>Jeff, >>>>> >>>>>We had this entire discussion already some time ago. >>>>> >>>>>For me, the main argument is that all IETF standards so far >>>>>are human-readable. The XML document in the Appendix is hardly >>>>>readable, while section 6 is well readable. >>>>> >>>>>You are requesting to move from a human-readable standard >>>>>to a machine-readable standard. I understand that there are >>>>>several good reasons to do so. But the change in the >>>>>standardization approach is fundamental. >>>>> >>>>>This might be an issue for the ietf@ieft mailing list. >>>>>However, so far very few protocols or models in the IETF >>>>>have been formally defined. Looks like still the 'running >>>>>code' approach dominates the 'well specified' approach. >>>>> >>>>>Regards, >>>>> >>>>> Juergen >>>>> >>>>>--On 28.01.2004 19:53 h -0800 Jeff Meyer wrote: >>>>> >>>>>>Nevil, >>>>>> >>>>>> My only contention would be that I did not do any direct data entry >>>>>>for section 6. I.e. I wrote the XML-Schema ran it through the >>>>>>publicly available stylesheet and free transform engine and pasted it >>>>>>into the doc. >>>>>> >>>>>> Certainly it would be my hope that authors of additional >>>>>>information models to be carried over IPFIX would follow the same >>>>>>process, because then I can simply take their XML-Schema spec and use >>>>>>it in a variety of tools. If I only get text, then I >>>>>>have the tedious prospect of transcribing it. If equipment providers >>>>>>favor a manual transcription process, it is certainly not precluded. >>>>>> >>>>>> My understanding was that PSAMP might be using the XML technique >>>>>>today, I believe it was Juergen who asked about the tools and I passed >>>>>>along the pointer. >>>>>> >>>>>> If it is politically simpler to call section 6 normative but >>>>>>indicate that authors of new models SHOULD create an XML-Schema model >>>>>>and MAY machine translate these models to create the normative text, >>>>>>then I could live with such a compromise. >>>>>> >>>>>> Simply excising this information as Stewart seems to be advocating >>>>>>seems like a step backwards and I'm at a loss to see any benefit from >>>>>>that. >>>>>> >>>>>>Regards, >>>>>> >>>>>> Jeff Meyer >>>>>> >>>>>> >>>>>>>From: Nevil Brownlee >>>>>>>To: Jeff Meyer >>>>>>>CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>>>Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>>>vs.Appendix A >>>>>>>Date: Thu, 29 Jan 2004 13:02:07 +1300 >>>>>>> >>>>>>>Stewart and Jeff: >>>>>>> >>>>>>> > With the use of XSL stylesheets the XML style informaiton model >>>>>>>could >>>>>>>be >>>>>>> > transformed automatically into any set of text one would want, >>>>>>>e.g. IOS >>>>>>> > commands to enable flags, HTML tables for presentation, RFC2629 >>>>>>>entries >>>>>>>in >>>>>>> > an RFC document, etc. For a discussion and example of using free >>>>>>>XSL >>>>>>>tools >>>>>>> > to process this you can see >>>>>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html. >>>>>>> >>>>>>>Jeff's right in saying that XML is becoming more widely used within >>>>>>>the >>>>>>>IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially >>>>>>>in the Applications Area) are using it. >>>>>>> >>>>>>>However, RFC 2629 explicitly says it doesn't address "IETF politics" >>>>>>>issues. My take on that is that the text in section 6 of the Info >>>>>>>Model >>>>>>>draft is the normative version; Appendix A gives the xml because >>>>>>>people >>>>>>>may find it useful, but if they use it they should check that it >>>>>>>really >>>>>>>does match the (normative) text version. >>>>>>> >>>>>>>As for IPFIX WG consensus on this, in my view the document editors >>>>>>>are free to use whatever tools they need to produce the actual >>>>>>>drafts. >>>>>>>Furthermore, including the xml as an appendix allows other people to >>>>>>>use the xml for other purposes, which (I guess) is why the editors >>>>>>>appended it to the draft. >>>>>>> >>>>>>>Does that make the situation clearer? >>>>>>> >>>>>>>----------------------------------------------------------------------- >>>>>>> >>>>>>> Nevil Brownlee Director, Technology Development >>>>>>> Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland >>>>>>> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand >>>>>>> >>>>>>> >>>>>>>------------------------------------------------- >>>>>>>This mail sent through University of Auckland >>>>>>>http://www.auckland.ac.nz/ >>>>>>> >>>>>>>-- >>>>>>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>>message >>>>>>>body >>>>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>>"unsubscribe ipfix" in message body >>>>>>>Archive http://ipfix.doit.wisc.edu/archive/ >>>>>> >>>>>> >>>>>> >>>>>>_________________________________________________________________ >>>>>>Learn how to choose, serve, and enjoy wine at Wine @ MSN. >>>>>>http://wine.msn.com/ >>>>>> >>>>>> >>>>>>-- >>>>>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>message body >>>>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>"unsubscribe ipfix" in message body >>>>>>Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>>_________________________________________________________________ >>>>There are now three new levels of MSN Hotmail Extra Storage! Learn >>>>more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 >>>> >>>> >>>>-- >>>>Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >>>>body >>>>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>"unsubscribe ipfix" in message body >>>>Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>> >>> >>>-- >>>Sebastian Zander E-mail: >>>zander@fokus.fraunhofer.de >>>Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >>>Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >>>D-10589 Berlin, Germany >>>www.fokus.fraunhofer.de/usr/sebastian.zander >>> >>> >>> >>> >> >>_________________________________________________________________ >>Let the new MSN Premium Internet Software make the most of your high-speed >>experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 >> >> >>-- >>Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >>body >>Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>"unsubscribe ipfix" in message body >>Archive http://ipfix.doit.wisc.edu/archive/ >> > > >-- >Sebastian Zander E-mail: zander@fokus.fraunhofer.de >Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >D-10589 Berlin, Germany >www.fokus.fraunhofer.de/usr/sebastian.zander > > > > _________________________________________________________________ High-speed users—be more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 4 03:50:30 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26319 for ; Wed, 4 Feb 2004 03:50:30 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AoIXZ-0002XJ-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 Feb 2004 02:37:45 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AoIXY-0002XE-00 for ipfix@net.doit.wisc.edu; Wed, 04 Feb 2004 02:37:44 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i148bcNC065581 for ; Wed, 4 Feb 2004 09:37:42 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i148bX9E065575 for ; Wed, 4 Feb 2004 09:37:33 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i148bVN8065572; Wed, 04 Feb 2004 09:37:33 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 44A304DCCE; Wed, 4 Feb 2004 09:37:29 +0100 (CET) Date: Wed, 04 Feb 2004 09:37:48 +0100 From: Juergen Quittek To: Jeff Meyer , zander@fokus.fraunhofer.de Cc: n.brownlee@auckland.ac.nz, stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A Message-ID: <2147483647.1075887468@[10.1.1.171]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, --On 03.02.2004 19:06 Uhr -0800 Jeff Meyer wrote: > Sebastian, > > So it sounds like consensus is that the information model will call > section 6 the normative description of the information carried by IPFIX. > The rationale being that interested parties will find it easier to > review in this format and that any use of XML is optional in the > IPFIX context. > > Appendix A (XML format) will remain, possibly being rolled to the XML > format used by PSAMP, (waiting for those XSL stylesheets;-) > > The document will recommend that authors of IM extensions SHOULD use > the XML format for authoring and utilize tools (pointers included in > non normative reference section) to generate the normative "human readable" > text and SHOULD include an XML based IM if one is produced. This sounds very good to me. I suggest adding another recommendation for implementers to use the Appendix for generating code for IPFIX protocol implementations. In another step we could add an appendix to the protocol document containing an XSL style sheet generating a C header out of the IM. This XSL style sheet would implement the binary encoding rules stated in plain text in the protocol document. Thanks, Juergen > -- Jeff > >> From: Sebastian Zander >> To: Jeff Meyer >> CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, >> ipfix@net.doit.wisc.edu >> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >> vs.Appendix A >> Date: Tue, 03 Feb 2004 10:37:03 +0100 >> >> Jeff Meyer wrote: >>> Sebastian, >>> >>> Comments inline... >>> >>> -- Jeff >>> >>> >>>> From: Sebastian Zander >>>> To: Jeff Meyer >>>> CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, >>>> ipfix@net.doit.wisc.edu >>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>> vs.Appendix A >>>> Date: Mon, 02 Feb 2004 14:48:22 +0100 >>>> >>>> Jeff, >>>> >>>> I see the value of having an XML description >>> >>> >>> Good. >>> >>>> but I agree to Juergen, Nevil >>>> and Stewart that the text should be the normative reference. I do not see >>>> the point of forcing people to use XML if they don't want to. >>> >>> >>> Do you mean "use" or "read" XML? Assuming that you have a working XSL >>> implementation the two forms are equivalent. >> >> I would assume that most people who are not going to use XML won't read it. >> Why should they if the text contains the same information more readable? >> >>> >>>> I also do not >>>> see the point of extending the IM. >>> >>> >>> Huh? Take a look at the requirements document, section 6.2: >>> >>> The data model MUST be extensible for future attributes to be added. >>> Even if a set of attributes is fixed in the flow record, the data >>> model MUST provide a way of extending the record by configuration or >>> for certain implementations. >>> >>> The term "data model" is misused here, but obviously from the context the >>> intent is that extending the IM is a MUST. PSAMP is a case in point. >> >> When the text version is normative the IM is still extensible. >> >>> >>>> Most people will anyway read only the >>>> text and comment on this. So you have to do the XML editing anyway. >>> >>> >>> So you're saying one should write in XML? (I agree, but it seems >>> inconsistent with your previous statements?) >> >> Sure >> >>>> As for >>>> IPFIX IM extensions not even the PSAMP IM draft currently uses the XML >>>> model. >>> >>> >>> Read the thread more carefully. They did use XML, they just didn't >>> publish it, not very helpful. As it stands I would need to cut and paste >>> each subsection for each attribute of their work to operate with a system >>> that is capable of directly a single XML document. >> >> The result of using XML and not providing it is for the reader >> essentially the same as not using XML ;-) >> >>>> Even worse the use of XML schema types like hexBinary has caused some >>>> confusion >>>> among the authors. >>> >>> >>> "hexBinary" is a poorly chosen name. If we embarked on reinventing things >>> every time we disliked the names, then maybe we could solve the technology >>> slump! Jobs for everyone! >> >> The fact is that the type specifies how to encode binary field in XML which >> is not the job of the information model and which is the reason why Juergen >> and I propose to use a XML document instead of a schema. >> >>>> >>>> I don't think that the use of XML in the IETF is as widely accepted as >>>> the >>>> use of MIBs. And how many IETF drafts provide normative textual >>>> descriptions >>>> vs. how many provide normative XML schemas? >>> >>> >>> This seems to be simply an argument that change is bad. That if things >>> were one way before, embarking on something which might improve upon them >>> should be viewed with great skepticism. >> >> You miss the point. I'm not against change but I'm not convinced by your >> arguments. >> >>> Obviously as new work there are a lot more MIBs which have had > 10 years >>> to be built up vs. something which is proposed for IPFIX. >>> >>>> The W3C schema definition is not >>>> even accepted by the whole XML community. There are alternatives e.g. >>>> RELAX NG. >>> >>> >>> XML-Schema is the W3C specification. Plain and simple. Ultimately the >>> utility is agreeing on one piece of work, which W3C did. >>> >>>> >>>> Let's close this issue and move forward. >>> >>> >>> If both the XML and human readable forms are in the document, and assuming >>> the process of converting from XML->human readable is automated using free >>> and open tools, then I guess it really doesn't matter which one calls >>> normative. >>> >>> So, assuming we publish both, calling the text based normative to benefit >>> readers unfamiliar with XML is an acceptable compromise. >> >> Great! >> >>> If only human readable is contained in the document, as in the current >>> PSAMP document, then I still have an issue. You've taken away the more >>> useful artifact of the two artifacts, the XML document which can be >>> transformed into whatever you want it to be. >> >> Can we mandate that extensions provide XML? I have the feeling that this >> won't get consensus. Solution could be to recommend it. >> >> At least you can always produce the XML from the text. Assuming that >> authors >> use a consistent format this can be done automatically. >> >> I don't think that PSAMP is a big problem because it seems well aligned >> with >> IPFIX but in the future other extensions may be created from people not >> involved in the initial IPFIX or PSAMP work. >> >>> >>>> >>>> A further point is whether IPFIX will standardize how to store the >>>> information. >>>> 1) AFAIK the idea of MIBs is to have a virtual information store. Do we >>>> need an >>>> IPFIX MIB? (PSAMP has a MIP draft already...) >>>> 2) IMO the info model draft should focus on the definition of the >>>> information >>>> model and _not_ how to encode IPFIX information in XML. >>> >>> >>> The info model simply points out how because it is abstract and separate >>> from encoding and transport, it may be applied to other activities dealing >>> with IPFIX information. >>> >>> Because MIBs typically deal with virtual stores of instantenous (vs. >>> historical) information, they aren't very useful in the IPFIX context >>> where enormous volumes of individual records are streaming off the device. >>> Yes, RMON is an example of a MIB which invented a complex indexing >>> scheme to store historical information, while clever, I think it also >>> illustrates some of the limitations/irritations of working with MIBs in >>> this context. >>> >>> A file format, or DB on the other hand is a handy way to capture these. >>> Being able to "get this for free" seems like goodness to me. >> >> It appears to me that a MIB for the configuration of IPFIX devices could be >> a good idea. >> >> For IPFIX data I'm not sure either. RTFM is another example which has >> defined >> a MIB for flow data... >> >> Cheers, >> >> Sebastian >> >>>> >>>> Cheers, >>>> >>>> Sebastian >>>> >>>> Jeff Meyer wrote: >>>> >>>>> Juergen, >>>>> >>>>> I agree few protocols have formal model specs. SNMP, however, which >>>>> has as a key value proposition the means of extensibility chose to >>>>> define MIBs, quite formal. MIBs also suffer somewhat from difficulty in >>>>> reading along with some other issues inherited from ASN.1 which are >>>>> improved by XML. >>>>> >>>>> Since I believe one of the key aspects of IPFIX is the mechanism for >>>>> extension, I think we should learn from another IETF protocol which >>>>> seemed rather successful in addressing this requirement. >>>>> >>>>> So, I think maintaining the connection between the mechanism which is >>>>> available today in IPFIX-info to formally specify the model is >>>>> important, if there is an interest in drawing others to extend IPFIX >>>>> with information content which differs from IPFIX's initial focus. >>>>> >>>>> One approach would be to break out another document as part of IPFIX, >>>>> which would be something like "Formal IPFIX Information Modeling". But >>>>> I'm not particularly eager to create another document. >>>>> >>>>> -- Jeff >>>>> >>>>> >>>>>> From: Juergen Quittek >>>>>> To: Jeff Meyer , n.brownlee@auckland.ac.nz >>>>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>> vs.Appendix A >>>>>> Date: Thu, 29 Jan 2004 12:30:58 +0100 >>>>>> >>>>>> Jeff, >>>>>> >>>>>> We had this entire discussion already some time ago. >>>>>> >>>>>> For me, the main argument is that all IETF standards so far >>>>>> are human-readable. The XML document in the Appendix is hardly >>>>>> readable, while section 6 is well readable. >>>>>> >>>>>> You are requesting to move from a human-readable standard >>>>>> to a machine-readable standard. I understand that there are >>>>>> several good reasons to do so. But the change in the >>>>>> standardization approach is fundamental. >>>>>> >>>>>> This might be an issue for the ietf@ieft mailing list. >>>>>> However, so far very few protocols or models in the IETF >>>>>> have been formally defined. Looks like still the 'running >>>>>> code' approach dominates the 'well specified' approach. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Juergen >>>>>> >>>>>> --On 28.01.2004 19:53 h -0800 Jeff Meyer wrote: >>>>>> >>>>>>> Nevil, >>>>>>> >>>>>>> My only contention would be that I did not do any direct data entry >>>>>>> for section 6. I.e. I wrote the XML-Schema ran it through the >>>>>>> publicly available stylesheet and free transform engine and pasted it >>>>>>> into the doc. >>>>>>> >>>>>>> Certainly it would be my hope that authors of additional >>>>>>> information models to be carried over IPFIX would follow the same >>>>>>> process, because then I can simply take their XML-Schema spec and use >>>>>>> it in a variety of tools. If I only get text, then I >>>>>>> have the tedious prospect of transcribing it. If equipment providers >>>>>>> favor a manual transcription process, it is certainly not precluded. >>>>>>> >>>>>>> My understanding was that PSAMP might be using the XML technique >>>>>>> today, I believe it was Juergen who asked about the tools and I passed >>>>>>> along the pointer. >>>>>>> >>>>>>> If it is politically simpler to call section 6 normative but >>>>>>> indicate that authors of new models SHOULD create an XML-Schema model >>>>>>> and MAY machine translate these models to create the normative text, >>>>>>> then I could live with such a compromise. >>>>>>> >>>>>>> Simply excising this information as Stewart seems to be advocating >>>>>>> seems like a step backwards and I'm at a loss to see any benefit from >>>>>>> that. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Jeff Meyer >>>>>>> >>>>>>> >>>>>>>> From: Nevil Brownlee >>>>>>>> To: Jeff Meyer >>>>>>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>>>> vs.Appendix A >>>>>>>> Date: Thu, 29 Jan 2004 13:02:07 +1300 >>>>>>>> >>>>>>>> Stewart and Jeff: >>>>>>>> >>>>>>>> > With the use of XSL stylesheets the XML style informaiton model >>>>>>>> could >>>>>>>> be >>>>>>>> > transformed automatically into any set of text one would want, >>>>>>>> e.g. IOS >>>>>>>> > commands to enable flags, HTML tables for presentation, RFC2629 >>>>>>>> entries >>>>>>>> in >>>>>>>> > an RFC document, etc. For a discussion and example of using free >>>>>>>> XSL >>>>>>>> tools >>>>>>>> > to process this you can see >>>>>>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html. >>>>>>>> >>>>>>>> Jeff's right in saying that XML is becoming more widely used within >>>>>>>> the >>>>>>>> IETF, as evidenced by RFC 2629 and the fact that more WGs (espcially >>>>>>>> in the Applications Area) are using it. >>>>>>>> >>>>>>>> However, RFC 2629 explicitly says it doesn't address "IETF politics" >>>>>>>> issues. My take on that is that the text in section 6 of the Info >>>>>>>> Model >>>>>>>> draft is the normative version; Appendix A gives the xml because >>>>>>>> people >>>>>>>> may find it useful, but if they use it they should check that it >>>>>>>> really >>>>>>>> does match the (normative) text version. >>>>>>>> >>>>>>>> As for IPFIX WG consensus on this, in my view the document editors >>>>>>>> are free to use whatever tools they need to produce the actual >>>>>>>> drafts. >>>>>>>> Furthermore, including the xml as an appendix allows other people to >>>>>>>> use the xml for other purposes, which (I guess) is why the editors >>>>>>>> appended it to the draft. >>>>>>>> >>>>>>>> Does that make the situation clearer? >>>>>>>> >>>>>>>> ----------------------------------------------------------------------- >>>>>>>> >>>>>>>> Nevil Brownlee Director, Technology Development >>>>>>>> Phone: +64 9 373 7599 x88941 ITSS, The University of Auckland >>>>>>>> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------- >>>>>>>> This mail sent through University of Auckland >>>>>>>> http://www.auckland.ac.nz/ >>>>>>>> >>>>>>>> -- >>>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>>> message >>>>>>>> body >>>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>>> "unsubscribe ipfix" in message body >>>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> Learn how to choose, serve, and enjoy wine at Wine @ MSN. >>>>>>> http://wine.msn.com/ >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>> message body >>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>> "unsubscribe ipfix" in message body >>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _________________________________________________________________ >>>>> There are now three new levels of MSN Hotmail Extra Storage! Learn >>>>> more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 >>>>> >>>>> >>>>> -- >>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >>>>> body >>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>> "unsubscribe ipfix" in message body >>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>> >>>> >>>> -- >>>> Sebastian Zander E-mail: >>>> zander@fokus.fraunhofer.de >>>> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >>>> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >>>> D-10589 Berlin, Germany >>>> www.fokus.fraunhofer.de/usr/sebastian.zander >>>> >>>> >>>> >>>> >>> >>> _________________________________________________________________ >>> Let the new MSN Premium Internet Software make the most of your high-speed >>> experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 >>> >>> >>> -- >>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >>> body >>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>> "unsubscribe ipfix" in message body >>> Archive http://ipfix.doit.wisc.edu/archive/ >>> >> >> >> -- >> Sebastian Zander E-mail: zander@fokus.fraunhofer.de >> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >> D-10589 Berlin, Germany >> www.fokus.fraunhofer.de/usr/sebastian.zander >> >> >> >> > > _________________________________________________________________ > High-speed users?be more efficient online with the new MSN Premium Internet Software. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 4 04:43:55 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27925 for ; Wed, 4 Feb 2004 04:43:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AoJSA-00054k-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 Feb 2004 03:36:14 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AoJS8-00054f-00 for ipfix@net.doit.wisc.edu; Wed, 04 Feb 2004 03:36:12 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i149Zt916024; Wed, 4 Feb 2004 10:35:55 +0100 (MET) Message-ID: <4020BC5A.6030105@fokus.fraunhofer.de> Date: Wed, 04 Feb 2004 10:33:14 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Jeff Meyer , n.brownlee@auckland.ac.nz, stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A References: <2147483647.1075887468@[10.1.1.171]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Quittek wrote: > Jeff, > > --On 03.02.2004 19:06 Uhr -0800 Jeff Meyer wrote: > >> Sebastian, >> >> So it sounds like consensus is that the information model will call >> section 6 the normative description of the information carried by IPFIX. >> The rationale being that interested parties will find it easier to >> review in this format and that any use of XML is optional in the >> IPFIX context. >> >> Appendix A (XML format) will remain, possibly being rolled to the XML >> format used by PSAMP, (waiting for those XSL stylesheets;-) >> >> The document will recommend that authors of IM extensions SHOULD use >> the XML format for authoring and utilize tools (pointers included in >> non normative reference section) to generate the normative "human >> readable" >> text and SHOULD include an XML based IM if one is produced. > > > This sounds very good to me. I suggest adding another recommendation for > implementers to use the Appendix for generating code for IPFIX protocol > implementations. In another step we could add an appendix to the protocol > document containing an XSL style sheet generating a C header out of the IM. > This XSL style sheet would implement the binary encoding rules stated in > plain text in the protocol document. Sounds good! I'm not sure if the XSL belongs into the protocol draft. To be consistent the other XSL would then go in the info draft? To make the drafts shorter they could be made available separately and just referenced. Sebastian > Thanks, > > Juergen > >> -- Jeff >> >>> From: Sebastian Zander >>> To: Jeff Meyer >>> CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, >>> ipfix@net.doit.wisc.edu >>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>> vs.Appendix A >>> Date: Tue, 03 Feb 2004 10:37:03 +0100 >>> >>> Jeff Meyer wrote: >>> >>>> Sebastian, >>>> >>>> Comments inline... >>>> >>>> -- Jeff >>>> >>>> >>>>> From: Sebastian Zander >>>>> To: Jeff Meyer >>>>> CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, >>>>> stbryant@cisco.com, >>>>> ipfix@net.doit.wisc.edu >>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>> vs.Appendix A >>>>> Date: Mon, 02 Feb 2004 14:48:22 +0100 >>>>> >>>>> Jeff, >>>>> >>>>> I see the value of having an XML description >>>> >>>> >>>> >>>> Good. >>>> >>>>> but I agree to Juergen, Nevil >>>>> and Stewart that the text should be the normative reference. I do >>>>> not see >>>>> the point of forcing people to use XML if they don't want to. >>>> >>>> >>>> >>>> Do you mean "use" or "read" XML? Assuming that you have a working XSL >>>> implementation the two forms are equivalent. >>> >>> >>> I would assume that most people who are not going to use XML won't >>> read it. >>> Why should they if the text contains the same information more readable? >>> >>>> >>>>> I also do not >>>>> see the point of extending the IM. >>>> >>>> >>>> >>>> Huh? Take a look at the requirements document, section 6.2: >>>> >>>> The data model MUST be extensible for future attributes to be added. >>>> Even if a set of attributes is fixed in the flow record, the data >>>> model MUST provide a way of extending the record by configuration or >>>> for certain implementations. >>>> >>>> The term "data model" is misused here, but obviously from the >>>> context the >>>> intent is that extending the IM is a MUST. PSAMP is a case in point. >>> >>> >>> When the text version is normative the IM is still extensible. >>> >>>> >>>>> Most people will anyway read only the >>>>> text and comment on this. So you have to do the XML editing anyway. >>>> >>>> >>>> >>>> So you're saying one should write in XML? (I agree, but it seems >>>> inconsistent with your previous statements?) >>> >>> >>> Sure >>> >>>>> As for >>>>> IPFIX IM extensions not even the PSAMP IM draft currently uses the XML >>>>> model. >>>> >>>> >>>> >>>> Read the thread more carefully. They did use XML, they just didn't >>>> publish it, not very helpful. As it stands I would need to cut and >>>> paste >>>> each subsection for each attribute of their work to operate with a >>>> system >>>> that is capable of directly a single XML document. >>> >>> >>> The result of using XML and not providing it is for the reader >>> essentially the same as not using XML ;-) >>> >>>>> Even worse the use of XML schema types like hexBinary has caused some >>>>> confusion >>>>> among the authors. >>>> >>>> >>>> >>>> "hexBinary" is a poorly chosen name. If we embarked on reinventing >>>> things >>>> every time we disliked the names, then maybe we could solve the >>>> technology >>>> slump! Jobs for everyone! >>> >>> >>> The fact is that the type specifies how to encode binary field in XML >>> which >>> is not the job of the information model and which is the reason why >>> Juergen >>> and I propose to use a XML document instead of a schema. >>> >>>>> >>>>> I don't think that the use of XML in the IETF is as widely accepted as >>>>> the >>>>> use of MIBs. And how many IETF drafts provide normative textual >>>>> descriptions >>>>> vs. how many provide normative XML schemas? >>>> >>>> >>>> >>>> This seems to be simply an argument that change is bad. That if things >>>> were one way before, embarking on something which might improve upon >>>> them >>>> should be viewed with great skepticism. >>> >>> >>> You miss the point. I'm not against change but I'm not convinced by your >>> arguments. >>> >>>> Obviously as new work there are a lot more MIBs which have had > 10 >>>> years >>>> to be built up vs. something which is proposed for IPFIX. >>>> >>>>> The W3C schema definition is not >>>>> even accepted by the whole XML community. There are alternatives e.g. >>>>> RELAX NG. >>>> >>>> >>>> >>>> XML-Schema is the W3C specification. Plain and simple. Ultimately the >>>> utility is agreeing on one piece of work, which W3C did. >>>> >>>>> >>>>> Let's close this issue and move forward. >>>> >>>> >>>> >>>> If both the XML and human readable forms are in the document, and >>>> assuming >>>> the process of converting from XML->human readable is automated >>>> using free >>>> and open tools, then I guess it really doesn't matter which one calls >>>> normative. >>>> >>>> So, assuming we publish both, calling the text based normative to >>>> benefit >>>> readers unfamiliar with XML is an acceptable compromise. >>> >>> >>> Great! >>> >>>> If only human readable is contained in the document, as in the current >>>> PSAMP document, then I still have an issue. You've taken away the more >>>> useful artifact of the two artifacts, the XML document which can be >>>> transformed into whatever you want it to be. >>> >>> >>> Can we mandate that extensions provide XML? I have the feeling that this >>> won't get consensus. Solution could be to recommend it. >>> >>> At least you can always produce the XML from the text. Assuming that >>> authors >>> use a consistent format this can be done automatically. >>> >>> I don't think that PSAMP is a big problem because it seems well aligned >>> with >>> IPFIX but in the future other extensions may be created from people not >>> involved in the initial IPFIX or PSAMP work. >>> >>>> >>>>> >>>>> A further point is whether IPFIX will standardize how to store the >>>>> information. >>>>> 1) AFAIK the idea of MIBs is to have a virtual information store. >>>>> Do we >>>>> need an >>>>> IPFIX MIB? (PSAMP has a MIP draft already...) >>>>> 2) IMO the info model draft should focus on the definition of the >>>>> information >>>>> model and _not_ how to encode IPFIX information in XML. >>>> >>>> >>>> >>>> The info model simply points out how because it is abstract and >>>> separate >>>> from encoding and transport, it may be applied to other activities >>>> dealing >>>> with IPFIX information. >>>> >>>> Because MIBs typically deal with virtual stores of instantenous (vs. >>>> historical) information, they aren't very useful in the IPFIX context >>>> where enormous volumes of individual records are streaming off the >>>> device. >>>> Yes, RMON is an example of a MIB which invented a complex indexing >>>> scheme to store historical information, while clever, I think it also >>>> illustrates some of the limitations/irritations of working with MIBs in >>>> this context. >>>> >>>> A file format, or DB on the other hand is a handy way to capture these. >>>> Being able to "get this for free" seems like goodness to me. >>> >>> >>> It appears to me that a MIB for the configuration of IPFIX devices >>> could be >>> a good idea. >>> >>> For IPFIX data I'm not sure either. RTFM is another example which has >>> defined >>> a MIB for flow data... >>> >>> Cheers, >>> >>> Sebastian >>> >>>>> >>>>> Cheers, >>>>> >>>>> Sebastian >>>>> >>>>> Jeff Meyer wrote: >>>>> >>>>>> Juergen, >>>>>> >>>>>> I agree few protocols have formal model specs. SNMP, however, which >>>>>> has as a key value proposition the means of extensibility chose to >>>>>> define MIBs, quite formal. MIBs also suffer somewhat from >>>>>> difficulty in >>>>>> reading along with some other issues inherited from ASN.1 which are >>>>>> improved by XML. >>>>>> >>>>>> Since I believe one of the key aspects of IPFIX is the mechanism for >>>>>> extension, I think we should learn from another IETF protocol which >>>>>> seemed rather successful in addressing this requirement. >>>>>> >>>>>> So, I think maintaining the connection between the mechanism >>>>>> which is >>>>>> available today in IPFIX-info to formally specify the model is >>>>>> important, if there is an interest in drawing others to extend IPFIX >>>>>> with information content which differs from IPFIX's initial focus. >>>>>> >>>>>> One approach would be to break out another document as part of >>>>>> IPFIX, >>>>>> which would be something like "Formal IPFIX Information >>>>>> Modeling". But >>>>>> I'm not particularly eager to create another document. >>>>>> >>>>>> -- Jeff >>>>>> >>>>>> >>>>>>> From: Juergen Quittek >>>>>>> To: Jeff Meyer , n.brownlee@auckland.ac.nz >>>>>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>>> vs.Appendix A >>>>>>> Date: Thu, 29 Jan 2004 12:30:58 +0100 >>>>>>> >>>>>>> Jeff, >>>>>>> >>>>>>> We had this entire discussion already some time ago. >>>>>>> >>>>>>> For me, the main argument is that all IETF standards so far >>>>>>> are human-readable. The XML document in the Appendix is hardly >>>>>>> readable, while section 6 is well readable. >>>>>>> >>>>>>> You are requesting to move from a human-readable standard >>>>>>> to a machine-readable standard. I understand that there are >>>>>>> several good reasons to do so. But the change in the >>>>>>> standardization approach is fundamental. >>>>>>> >>>>>>> This might be an issue for the ietf@ieft mailing list. >>>>>>> However, so far very few protocols or models in the IETF >>>>>>> have been formally defined. Looks like still the 'running >>>>>>> code' approach dominates the 'well specified' approach. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Juergen >>>>>>> >>>>>>> --On 28.01.2004 19:53 h -0800 Jeff Meyer wrote: >>>>>>> >>>>>>>> Nevil, >>>>>>>> >>>>>>>> My only contention would be that I did not do any direct data >>>>>>>> entry >>>>>>>> for section 6. I.e. I wrote the XML-Schema ran it through the >>>>>>>> publicly available stylesheet and free transform engine and >>>>>>>> pasted it >>>>>>>> into the doc. >>>>>>>> >>>>>>>> Certainly it would be my hope that authors of additional >>>>>>>> information models to be carried over IPFIX would follow the same >>>>>>>> process, because then I can simply take their XML-Schema spec >>>>>>>> and use >>>>>>>> it in a variety of tools. If I only get text, then I >>>>>>>> have the tedious prospect of transcribing it. If equipment >>>>>>>> providers >>>>>>>> favor a manual transcription process, it is certainly not >>>>>>>> precluded. >>>>>>>> >>>>>>>> My understanding was that PSAMP might be using the XML technique >>>>>>>> today, I believe it was Juergen who asked about the tools and I >>>>>>>> passed >>>>>>>> along the pointer. >>>>>>>> >>>>>>>> If it is politically simpler to call section 6 normative but >>>>>>>> indicate that authors of new models SHOULD create an XML-Schema >>>>>>>> model >>>>>>>> and MAY machine translate these models to create the normative >>>>>>>> text, >>>>>>>> then I could live with such a compromise. >>>>>>>> >>>>>>>> Simply excising this information as Stewart seems to be >>>>>>>> advocating >>>>>>>> seems like a step backwards and I'm at a loss to see any benefit >>>>>>>> from >>>>>>>> that. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Jeff Meyer >>>>>>>> >>>>>>>> >>>>>>>>> From: Nevil Brownlee >>>>>>>>> To: Jeff Meyer >>>>>>>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>>>>> vs.Appendix A >>>>>>>>> Date: Thu, 29 Jan 2004 13:02:07 +1300 >>>>>>>>> >>>>>>>>> Stewart and Jeff: >>>>>>>>> >>>>>>>>> > With the use of XSL stylesheets the XML style informaiton >>>>>>>>> model >>>>>>>>> could >>>>>>>>> be >>>>>>>>> > transformed automatically into any set of text one would want, >>>>>>>>> e.g. IOS >>>>>>>>> > commands to enable flags, HTML tables for presentation, RFC2629 >>>>>>>>> entries >>>>>>>>> in >>>>>>>>> > an RFC document, etc. For a discussion and example of using >>>>>>>>> free >>>>>>>>> XSL >>>>>>>>> tools >>>>>>>>> > to process this you can see >>>>>>>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html. >>>>>>>>> >>>>>>>>> Jeff's right in saying that XML is becoming more widely used >>>>>>>>> within >>>>>>>>> the >>>>>>>>> IETF, as evidenced by RFC 2629 and the fact that more WGs >>>>>>>>> (espcially >>>>>>>>> in the Applications Area) are using it. >>>>>>>>> >>>>>>>>> However, RFC 2629 explicitly says it doesn't address "IETF >>>>>>>>> politics" >>>>>>>>> issues. My take on that is that the text in section 6 of the Info >>>>>>>>> Model >>>>>>>>> draft is the normative version; Appendix A gives the xml because >>>>>>>>> people >>>>>>>>> may find it useful, but if they use it they should check that it >>>>>>>>> really >>>>>>>>> does match the (normative) text version. >>>>>>>>> >>>>>>>>> As for IPFIX WG consensus on this, in my view the document editors >>>>>>>>> are free to use whatever tools they need to produce the actual >>>>>>>>> drafts. >>>>>>>>> Furthermore, including the xml as an appendix allows other >>>>>>>>> people to >>>>>>>>> use the xml for other purposes, which (I guess) is why the editors >>>>>>>>> appended it to the draft. >>>>>>>>> >>>>>>>>> Does that make the situation clearer? >>>>>>>>> >>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> >>>>>>>>> Nevil Brownlee Director, Technology >>>>>>>>> Development >>>>>>>>> Phone: +64 9 373 7599 x88941 ITSS, The University of >>>>>>>>> Auckland >>>>>>>>> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New >>>>>>>>> Zealand >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------- >>>>>>>>> This mail sent through University of Auckland >>>>>>>>> http://www.auckland.ac.nz/ >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>>>> message >>>>>>>>> body >>>>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>>>> "unsubscribe ipfix" in message body >>>>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _________________________________________________________________ >>>>>>>> Learn how to choose, serve, and enjoy wine at Wine @ MSN. >>>>>>>> http://wine.msn.com/ >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>>> message body >>>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>>> "unsubscribe ipfix" in message body >>>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _________________________________________________________________ >>>>>> There are now three new levels of MSN Hotmail Extra Storage! Learn >>>>>> more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 >>>>>> >>>>>> >>>>>> -- >>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>> message >>>>>> body >>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>> "unsubscribe ipfix" in message body >>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sebastian Zander E-mail: >>>>> zander@fokus.fraunhofer.de >>>>> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >>>>> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >>>>> D-10589 Berlin, Germany >>>>> www.fokus.fraunhofer.de/usr/sebastian.zander >>>>> >>>>> >>>>> >>>>> >>>> >>>> _________________________________________________________________ >>>> Let the new MSN Premium Internet Software make the most of your >>>> high-speed >>>> experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 >>>> >>>> >>>> -- >>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>> message >>>> body >>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>> "unsubscribe ipfix" in message body >>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>> >>> >>> >>> -- >>> Sebastian Zander E-mail: >>> zander@fokus.fraunhofer.de >>> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >>> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >>> D-10589 Berlin, Germany >>> www.fokus.fraunhofer.de/usr/sebastian.zander >>> >>> >>> >>> >> >> _________________________________________________________________ >> High-speed users?be more efficient online with the new MSN Premium >> Internet Software. >> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 >> > > > > -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 4 09:48:55 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07783 for ; Wed, 4 Feb 2004 09:48:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AoNwR-00012i-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 Feb 2004 08:23:47 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AoNwQ-00012c-00 for ipfix@net.doit.wisc.edu; Wed, 04 Feb 2004 08:23:46 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i14ENdNC099977 for ; Wed, 4 Feb 2004 15:23:43 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i14ELYZP099796 for ; Wed, 4 Feb 2004 15:21:34 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i14ELWN8099789; Wed, 04 Feb 2004 15:21:34 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 226DBF2419; Wed, 4 Feb 2004 15:21:30 +0100 (CET) Date: Wed, 04 Feb 2004 15:21:50 +0100 From: Juergen Quittek To: Sebastian Zander Cc: Jeff Meyer , n.brownlee@auckland.ac.nz, stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 vs.Appendix A Message-ID: <2147483647.1075908110@[10.1.1.171]> In-Reply-To: <4020BC5A.6030105@fokus.fraunhofer.de> References: <2147483647.1075887468@[10.1.1.171]> <4020BC5A.6030105@fokus.fraunhofer.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Sebastian, --On 04.02.2004 10:33 Uhr +0100 Sebastian Zander wrote: > Juergen Quittek wrote: >> Jeff, >> >> --On 03.02.2004 19:06 Uhr -0800 Jeff Meyer wrote: >> >>> Sebastian, >>> >>> So it sounds like consensus is that the information model will call >>> section 6 the normative description of the information carried by IPFIX. >>> The rationale being that interested parties will find it easier to >>> review in this format and that any use of XML is optional in the >>> IPFIX context. >>> >>> Appendix A (XML format) will remain, possibly being rolled to the XML >>> format used by PSAMP, (waiting for those XSL stylesheets;-) >>> >>> The document will recommend that authors of IM extensions SHOULD use >>> the XML format for authoring and utilize tools (pointers included in >>> non normative reference section) to generate the normative "human >>> readable" >>> text and SHOULD include an XML based IM if one is produced. > > >> >> This sounds very good to me. I suggest adding another recommendation for >> implementers to use the Appendix for generating code for IPFIX protocol >> implementations. In another step we could add an appendix to the protocol >> document containing an XSL style sheet generating a C header out of the IM. >> This XSL style sheet would implement the binary encoding rules stated in >> plain text in the protocol document. > > Sounds good! I'm not sure if the XSL belongs into the protocol draft. I think it does. It describe the data model of the IPFIX protocol specification. This is part of the protocol draft not of the information model. > To be consistent the other XSL would then go in the info draft? > To make the drafts shorter they could be made available separately > and just referenced. Yes, we have to discuss this. The problem is realizing what you call "made available separately". Has someone read already BCP 81, RFC 3688 on The IETF XML Registry? This RFC was published just a few days ago. Maybe we find a good answer in there ... Juergen > Sebastian > >> Thanks, >> >> Juergen >> >>> -- Jeff >>> >>>> From: Sebastian Zander >>>> To: Jeff Meyer >>>> CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, stbryant@cisco.com, >>>> ipfix@net.doit.wisc.edu >>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>> vs.Appendix A >>>> Date: Tue, 03 Feb 2004 10:37:03 +0100 >>>> >>>> Jeff Meyer wrote: >>>> >>>>> Sebastian, >>>>> >>>>> Comments inline... >>>>> >>>>> -- Jeff >>>>> >>>>> >>>>>> From: Sebastian Zander >>>>>> To: Jeff Meyer >>>>>> CC: quittek@ccrle.nec.de, n.brownlee@auckland.ac.nz, >>>>>> stbryant@cisco.com, >>>>>> ipfix@net.doit.wisc.edu >>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>> vs.Appendix A >>>>>> Date: Mon, 02 Feb 2004 14:48:22 +0100 >>>>>> >>>>>> Jeff, >>>>>> >>>>>> I see the value of having an XML description >>>>> >>>>> >>>>> >>>>> Good. >>>>> >>>>>> but I agree to Juergen, Nevil >>>>>> and Stewart that the text should be the normative reference. I do >>>>>> not see >>>>>> the point of forcing people to use XML if they don't want to. >>>>> >>>>> >>>>> >>>>> Do you mean "use" or "read" XML? Assuming that you have a working XSL >>>>> implementation the two forms are equivalent. >>>> >>>> >>>> I would assume that most people who are not going to use XML won't >>>> read it. >>>> Why should they if the text contains the same information more readable? >>>> >>>>> >>>>>> I also do not >>>>>> see the point of extending the IM. >>>>> >>>>> >>>>> >>>>> Huh? Take a look at the requirements document, section 6.2: >>>>> >>>>> The data model MUST be extensible for future attributes to be added. >>>>> Even if a set of attributes is fixed in the flow record, the data >>>>> model MUST provide a way of extending the record by configuration or >>>>> for certain implementations. >>>>> >>>>> The term "data model" is misused here, but obviously from the >>>>> context the >>>>> intent is that extending the IM is a MUST. PSAMP is a case in point. >>>> >>>> >>>> When the text version is normative the IM is still extensible. >>>> >>>>> >>>>>> Most people will anyway read only the >>>>>> text and comment on this. So you have to do the XML editing anyway. >>>>> >>>>> >>>>> >>>>> So you're saying one should write in XML? (I agree, but it seems >>>>> inconsistent with your previous statements?) >>>> >>>> >>>> Sure >>>> >>>>>> As for >>>>>> IPFIX IM extensions not even the PSAMP IM draft currently uses the XML >>>>>> model. >>>>> >>>>> >>>>> >>>>> Read the thread more carefully. They did use XML, they just didn't >>>>> publish it, not very helpful. As it stands I would need to cut and >>>>> paste >>>>> each subsection for each attribute of their work to operate with a >>>>> system >>>>> that is capable of directly a single XML document. >>>> >>>> >>>> The result of using XML and not providing it is for the reader >>>> essentially the same as not using XML ;-) >>>> >>>>>> Even worse the use of XML schema types like hexBinary has caused some >>>>>> confusion >>>>>> among the authors. >>>>> >>>>> >>>>> >>>>> "hexBinary" is a poorly chosen name. If we embarked on reinventing >>>>> things >>>>> every time we disliked the names, then maybe we could solve the >>>>> technology >>>>> slump! Jobs for everyone! >>>> >>>> >>>> The fact is that the type specifies how to encode binary field in XML >>>> which >>>> is not the job of the information model and which is the reason why >>>> Juergen >>>> and I propose to use a XML document instead of a schema. >>>> >>>>>> >>>>>> I don't think that the use of XML in the IETF is as widely accepted as >>>>>> the >>>>>> use of MIBs. And how many IETF drafts provide normative textual >>>>>> descriptions >>>>>> vs. how many provide normative XML schemas? >>>>> >>>>> >>>>> >>>>> This seems to be simply an argument that change is bad. That if things >>>>> were one way before, embarking on something which might improve upon >>>>> them >>>>> should be viewed with great skepticism. >>>> >>>> >>>> You miss the point. I'm not against change but I'm not convinced by your >>>> arguments. >>>> >>>>> Obviously as new work there are a lot more MIBs which have had > 10 >>>>> years >>>>> to be built up vs. something which is proposed for IPFIX. >>>>> >>>>>> The W3C schema definition is not >>>>>> even accepted by the whole XML community. There are alternatives e.g. >>>>>> RELAX NG. >>>>> >>>>> >>>>> >>>>> XML-Schema is the W3C specification. Plain and simple. Ultimately the >>>>> utility is agreeing on one piece of work, which W3C did. >>>>> >>>>>> >>>>>> Let's close this issue and move forward. >>>>> >>>>> >>>>> >>>>> If both the XML and human readable forms are in the document, and >>>>> assuming >>>>> the process of converting from XML->human readable is automated >>>>> using free >>>>> and open tools, then I guess it really doesn't matter which one calls >>>>> normative. >>>>> >>>>> So, assuming we publish both, calling the text based normative to >>>>> benefit >>>>> readers unfamiliar with XML is an acceptable compromise. >>>> >>>> >>>> Great! >>>> >>>>> If only human readable is contained in the document, as in the current >>>>> PSAMP document, then I still have an issue. You've taken away the more >>>>> useful artifact of the two artifacts, the XML document which can be >>>>> transformed into whatever you want it to be. >>>> >>>> >>>> Can we mandate that extensions provide XML? I have the feeling that this >>>> won't get consensus. Solution could be to recommend it. >>>> >>>> At least you can always produce the XML from the text. Assuming that >>>> authors >>>> use a consistent format this can be done automatically. >>>> >>>> I don't think that PSAMP is a big problem because it seems well aligned >>>> with >>>> IPFIX but in the future other extensions may be created from people not >>>> involved in the initial IPFIX or PSAMP work. >>>> >>>>> >>>>>> >>>>>> A further point is whether IPFIX will standardize how to store the >>>>>> information. >>>>>> 1) AFAIK the idea of MIBs is to have a virtual information store. >>>>>> Do we >>>>>> need an >>>>>> IPFIX MIB? (PSAMP has a MIP draft already...) >>>>>> 2) IMO the info model draft should focus on the definition of the >>>>>> information >>>>>> model and _not_ how to encode IPFIX information in XML. >>>>> >>>>> >>>>> >>>>> The info model simply points out how because it is abstract and >>>>> separate >>>>> from encoding and transport, it may be applied to other activities >>>>> dealing >>>>> with IPFIX information. >>>>> >>>>> Because MIBs typically deal with virtual stores of instantenous (vs. >>>>> historical) information, they aren't very useful in the IPFIX context >>>>> where enormous volumes of individual records are streaming off the >>>>> device. >>>>> Yes, RMON is an example of a MIB which invented a complex indexing >>>>> scheme to store historical information, while clever, I think it also >>>>> illustrates some of the limitations/irritations of working with MIBs in >>>>> this context. >>>>> >>>>> A file format, or DB on the other hand is a handy way to capture these. >>>>> Being able to "get this for free" seems like goodness to me. >>>> >>>> >>>> It appears to me that a MIB for the configuration of IPFIX devices >>>> could be >>>> a good idea. >>>> >>>> For IPFIX data I'm not sure either. RTFM is another example which has >>>> defined >>>> a MIB for flow data... >>>> >>>> Cheers, >>>> >>>> Sebastian >>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Sebastian >>>>>> >>>>>> Jeff Meyer wrote: >>>>>> >>>>>>> Juergen, >>>>>>> >>>>>>> I agree few protocols have formal model specs. SNMP, however, which >>>>>>> has as a key value proposition the means of extensibility chose to >>>>>>> define MIBs, quite formal. MIBs also suffer somewhat from >>>>>>> difficulty in >>>>>>> reading along with some other issues inherited from ASN.1 which are >>>>>>> improved by XML. >>>>>>> >>>>>>> Since I believe one of the key aspects of IPFIX is the mechanism for >>>>>>> extension, I think we should learn from another IETF protocol which >>>>>>> seemed rather successful in addressing this requirement. >>>>>>> >>>>>>> So, I think maintaining the connection between the mechanism >>>>>>> which is >>>>>>> available today in IPFIX-info to formally specify the model is >>>>>>> important, if there is an interest in drawing others to extend IPFIX >>>>>>> with information content which differs from IPFIX's initial focus. >>>>>>> >>>>>>> One approach would be to break out another document as part of >>>>>>> IPFIX, >>>>>>> which would be something like "Formal IPFIX Information >>>>>>> Modeling". But >>>>>>> I'm not particularly eager to create another document. >>>>>>> >>>>>>> -- Jeff >>>>>>> >>>>>>> >>>>>>>> From: Juergen Quittek >>>>>>>> To: Jeff Meyer , n.brownlee@auckland.ac.nz >>>>>>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>>>> vs.Appendix A >>>>>>>> Date: Thu, 29 Jan 2004 12:30:58 +0100 >>>>>>>> >>>>>>>> Jeff, >>>>>>>> >>>>>>>> We had this entire discussion already some time ago. >>>>>>>> >>>>>>>> For me, the main argument is that all IETF standards so far >>>>>>>> are human-readable. The XML document in the Appendix is hardly >>>>>>>> readable, while section 6 is well readable. >>>>>>>> >>>>>>>> You are requesting to move from a human-readable standard >>>>>>>> to a machine-readable standard. I understand that there are >>>>>>>> several good reasons to do so. But the change in the >>>>>>>> standardization approach is fundamental. >>>>>>>> >>>>>>>> This might be an issue for the ietf@ieft mailing list. >>>>>>>> However, so far very few protocols or models in the IETF >>>>>>>> have been formally defined. Looks like still the 'running >>>>>>>> code' approach dominates the 'well specified' approach. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Juergen >>>>>>>> >>>>>>>> --On 28.01.2004 19:53 h -0800 Jeff Meyer wrote: >>>>>>>> >>>>>>>>> Nevil, >>>>>>>>> >>>>>>>>> My only contention would be that I did not do any direct data >>>>>>>>> entry >>>>>>>>> for section 6. I.e. I wrote the XML-Schema ran it through the >>>>>>>>> publicly available stylesheet and free transform engine and >>>>>>>>> pasted it >>>>>>>>> into the doc. >>>>>>>>> >>>>>>>>> Certainly it would be my hope that authors of additional >>>>>>>>> information models to be carried over IPFIX would follow the same >>>>>>>>> process, because then I can simply take their XML-Schema spec >>>>>>>>> and use >>>>>>>>> it in a variety of tools. If I only get text, then I >>>>>>>>> have the tedious prospect of transcribing it. If equipment >>>>>>>>> providers >>>>>>>>> favor a manual transcription process, it is certainly not >>>>>>>>> precluded. >>>>>>>>> >>>>>>>>> My understanding was that PSAMP might be using the XML technique >>>>>>>>> today, I believe it was Juergen who asked about the tools and I >>>>>>>>> passed >>>>>>>>> along the pointer. >>>>>>>>> >>>>>>>>> If it is politically simpler to call section 6 normative but >>>>>>>>> indicate that authors of new models SHOULD create an XML-Schema >>>>>>>>> model >>>>>>>>> and MAY machine translate these models to create the normative >>>>>>>>> text, >>>>>>>>> then I could live with such a compromise. >>>>>>>>> >>>>>>>>> Simply excising this information as Stewart seems to be >>>>>>>>> advocating >>>>>>>>> seems like a step backwards and I'm at a loss to see any benefit >>>>>>>>> from >>>>>>>>> that. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Jeff Meyer >>>>>>>>> >>>>>>>>> >>>>>>>>>> From: Nevil Brownlee >>>>>>>>>> To: Jeff Meyer >>>>>>>>>> CC: stbryant@cisco.com, ipfix@net.doit.wisc.edu >>>>>>>>>> Subject: Re: [ipfix] [issue] INFO-30 Normative status of section 6 >>>>>>>>>> vs.Appendix A >>>>>>>>>> Date: Thu, 29 Jan 2004 13:02:07 +1300 >>>>>>>>>> >>>>>>>>>> Stewart and Jeff: >>>>>>>>>> >>>>>>>>>> > With the use of XSL stylesheets the XML style informaiton >>>>>>>>>> model >>>>>>>>>> could >>>>>>>>>> be >>>>>>>>>> > transformed automatically into any set of text one would want, >>>>>>>>>> e.g. IOS >>>>>>>>>> > commands to enable flags, HTML tables for presentation, RFC2629 >>>>>>>>>> entries >>>>>>>>>> in >>>>>>>>>> > an RFC document, etc. For a discussion and example of using >>>>>>>>>> free >>>>>>>>>> XSL >>>>>>>>>> tools >>>>>>>>>> > to process this you can see >>>>>>>>>> > http://www.ipdr.org/documents/ipfix/infomodel/README.html. >>>>>>>>>> >>>>>>>>>> Jeff's right in saying that XML is becoming more widely used >>>>>>>>>> within >>>>>>>>>> the >>>>>>>>>> IETF, as evidenced by RFC 2629 and the fact that more WGs >>>>>>>>>> (espcially >>>>>>>>>> in the Applications Area) are using it. >>>>>>>>>> >>>>>>>>>> However, RFC 2629 explicitly says it doesn't address "IETF >>>>>>>>>> politics" >>>>>>>>>> issues. My take on that is that the text in section 6 of the Info >>>>>>>>>> Model >>>>>>>>>> draft is the normative version; Appendix A gives the xml because >>>>>>>>>> people >>>>>>>>>> may find it useful, but if they use it they should check that it >>>>>>>>>> really >>>>>>>>>> does match the (normative) text version. >>>>>>>>>> >>>>>>>>>> As for IPFIX WG consensus on this, in my view the document editors >>>>>>>>>> are free to use whatever tools they need to produce the actual >>>>>>>>>> drafts. >>>>>>>>>> Furthermore, including the xml as an appendix allows other >>>>>>>>>> people to >>>>>>>>>> use the xml for other purposes, which (I guess) is why the editors >>>>>>>>>> appended it to the draft. >>>>>>>>>> >>>>>>>>>> Does that make the situation clearer? >>>>>>>>>> >>>>>>>>>> ----------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Nevil Brownlee Director, Technology >>>>>>>>>> Development >>>>>>>>>> Phone: +64 9 373 7599 x88941 ITSS, The University of >>>>>>>>>> Auckland >>>>>>>>>> FAX: +64 9 373 7021 Private Bag 92019, Auckland, New >>>>>>>>>> Zealand >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ------------------------------------------------- >>>>>>>>>> This mail sent through University of Auckland >>>>>>>>>> http://www.auckland.ac.nz/ >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>>>>> message >>>>>>>>>> body >>>>>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>>>>> "unsubscribe ipfix" in message body >>>>>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _________________________________________________________________ >>>>>>>>> Learn how to choose, serve, and enjoy wine at Wine @ MSN. >>>>>>>>> http://wine.msn.com/ >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>>>> message body >>>>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>>>> "unsubscribe ipfix" in message body >>>>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _________________________________________________________________ >>>>>>> There are now three new levels of MSN Hotmail Extra Storage! Learn >>>>>>> more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>>>> message >>>>>>> body >>>>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>>>> "unsubscribe ipfix" in message body >>>>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sebastian Zander E-mail: >>>>>> zander@fokus.fraunhofer.de >>>>>> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >>>>>> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >>>>>> D-10589 Berlin, Germany >>>>>> www.fokus.fraunhofer.de/usr/sebastian.zander >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _________________________________________________________________ >>>>> Let the new MSN Premium Internet Software make the most of your >>>>> high-speed >>>>> experience. http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 >>>>> >>>>> >>>>> -- >>>>> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >>>>> message >>>>> body >>>>> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >>>>> "unsubscribe ipfix" in message body >>>>> Archive http://ipfix.doit.wisc.edu/archive/ >>>>> >>>> >>>> >>>> -- >>>> Sebastian Zander E-mail: >>>> zander@fokus.fraunhofer.de >>>> Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 >>>> Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 >>>> D-10589 Berlin, Germany >>>> www.fokus.fraunhofer.de/usr/sebastian.zander >>>> >>>> >>>> >>>> >>> >>> _________________________________________________________________ >>> High-speed users?be more efficient online with the new MSN Premium >>> Internet Software. >>> http://join.msn.com/?pgmarket=en-us&page=byoa/prem&ST=1 >>> >> >> >> >> > > > -- > Sebastian Zander E-mail: zander@fokus.fraunhofer.de > Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 > Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 > D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 4 22:53:27 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17044 for ; Wed, 4 Feb 2004 22:53:27 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AoaFi-0006Ac-00 for ipfix-list@mil.doit.wisc.edu; Wed, 04 Feb 2004 21:32:30 -0600 Received: from [210.74.189.148] (helo=mail.iei-china.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AoaFh-0006AU-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 04 Feb 2004 21:32:29 -0600 Received: from mail.iei-china.com (bjmail [10.4.0.5]) by mail.iei-china.com (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HSL00L3LDN0O7@mail.iei-china.com> for ipfix-protocol@net.doit.wisc.edu; Thu, 05 Feb 2004 11:28:12 +0800 (CST) Date: Thu, 05 Feb 2004 11:28:12 +0800 (CST) From: =?gb2312?B?t+vOxLfl?= Subject: [ipfix-protocol] about a clerical error To: ipfix-protocol@net.doit.wisc.edu Message-id: <2438883.1075951692635.JavaMail.root@mail.iei-china.com> MIME-version: 1.0 X-Mailer: Global Messaging Service 4.5 Content-type: multipart/mixed; boundary="Boundary_(ID_vhxven7TiHQuFapl2XF1uw)" X-Template: normal Precedence: bulk Sender: majordomo listserver --Boundary_(ID_vhxven7TiHQuFapl2XF1uw) Content-type: text/plain; charset=GBK Content-Transfer-Encoding: 7BIT in [draft-ietf-ipfix-protocol-02.txt] , page 26, 9.1.1 section, the follow sect: Option 1 Field Type A numeric value that represents the type of field that would appear in the Options Template Record. Refer to [IPFIX- INFO]. thereinto, "Options Template Record" should be modified to "Options Data Record". I'm a freshman in network accounting field. best regards. yours wenfeng. --Boundary_(ID_vhxven7TiHQuFapl2XF1uw)-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 5 07:42:47 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13608 for ; Thu, 5 Feb 2004 07:42:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AoiOq-0003tl-00 for ipfix-list@mil.doit.wisc.edu; Thu, 05 Feb 2004 06:14:28 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AoiOp-0003tg-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 05 Feb 2004 06:14:27 -0600 Received: from cisco.com (ams-clip-vpn-dhcp229.cisco.com [10.61.64.229]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i15CE9703793; Thu, 5 Feb 2004 13:14:18 +0100 (CET) Message-ID: <40223390.3070103@cisco.com> Date: Thu, 05 Feb 2004 13:14:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?x-gbk?Q?=B7=EB=CE=C4=B7=E5?= CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] about a clerical error References: <2438883.1075951692635.JavaMail.root@mail.iei-china.com> In-Reply-To: <2438883.1075951692635.JavaMail.root@mail.iei-china.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Wenfeng, Corrected. Thanks for reviewing the draft. Regards, Benoit. >in [draft-ietf-ipfix-protocol-02.txt] , page 26, 9.1.1 section, > >the follow sect: > > Option 1 Field Type > A numeric value that represents the type of field that would > appear in the Options Template Record. Refer to [IPFIX- > INFO]. > >thereinto, "Options Template Record" should be modified to "Options Data Record". > > >I'm a freshman in network accounting field. > >best regards. >yours wenfeng. > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 5 23:33:23 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28272 for ; Thu, 5 Feb 2004 23:33:22 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AoxLc-0001Bd-00 for ipfix-list@mil.doit.wisc.edu; Thu, 05 Feb 2004 22:12:08 -0600 Received: from [210.74.189.148] (helo=mail.iei-china.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AoxLa-0001BY-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 05 Feb 2004 22:12:07 -0600 Received: from mail.iei-china.com (bjmail [10.4.0.5]) by mail.iei-china.com (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0HSN0084YA4UL5@mail.iei-china.com> for ipfix-protocol@net.doit.wisc.edu; Fri, 06 Feb 2004 12:07:42 +0800 (CST) Date: Fri, 06 Feb 2004 12:07:42 +0800 (CST) From: =?gb2312?B?t+vOxLfl?= Subject: [ipfix-protocol] about section 17:Examples To: ipfix-protocol@net.doit.wisc.edu Message-id: <4963507.1076040462597.JavaMail.root@mail.iei-china.com> MIME-version: 1.0 X-Mailer: Global Messaging Service 4.5 Content-type: multipart/mixed; boundary="Boundary_(ID_9sKH2YM8yuH8iZEIc5lcyg)" X-Priority: 3 X-Template: normal Precedence: bulk Sender: majordomo listserver --Boundary_(ID_9sKH2YM8yuH8iZEIc5lcyg) Content-type: text/plain; charset=GBK Content-Transfer-Encoding: 7BIT In draft-ietf-ipfix-protocol-02.txt,Section 17,Page 42. The example seems to be a NETFLOW9 example,rather than a IPFIX example. First,the message header's Version Number Field should to be 0x000a instead of 0x0009; Second, in the message header there should be a SysUpTime Field besides the Unix Secs Field; and in Section 17.5 Data FlowSet with Options Data Records Example,there may be some error: According to IPFIX Protocol Specification the Length Field should be 20 rather than 14. Best Regards yours wenfeng --Boundary_(ID_9sKH2YM8yuH8iZEIc5lcyg)-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Feb 6 11:05:14 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02467 for ; Fri, 6 Feb 2004 11:05:14 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ap85t-0005N2-00 for ipfix-list@mil.doit.wisc.edu; Fri, 06 Feb 2004 09:40:37 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ap85s-0005Mx-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 06 Feb 2004 09:40:36 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-202.cisco.com [144.254.7.202]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i16FeM726457; Fri, 6 Feb 2004 16:40:31 +0100 (CET) Message-ID: <4023B565.3010409@cisco.com> Date: Fri, 06 Feb 2004 16:40:21 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?x-gbk?Q?=B7=EB=CE=C4=B7=E5?= CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] about section 17:Examples References: <4963507.1076040462597.JavaMail.root@mail.iei-china.com> In-Reply-To: <4963507.1076040462597.JavaMail.root@mail.iei-china.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Wenfeng, >In draft-ietf-ipfix-protocol-02.txt,Section 17,Page 42. > >The example seems to be a NETFLOW9 example,rather than a IPFIX example. >First,the message header's Version Number Field should to be 0x000a instead of 0x0009; > Corrected. >Second, in the message header there should be a SysUpTime Field besides the Unix Secs Field; > This one has been reported already. Actually the example is right! http://ipfix.doit.wisc.edu/archive/2362.html >and in Section 17.5 Data FlowSet with Options Data Records Example,there may be some error: According to IPFIX Protocol Specification the Length Field should be 20 rather than 14. > Corrected. Thanks. > >Best Regards >yours wenfeng > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From gi.vito@tin.it Sun Feb 8 13:38:07 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27897 for ; Sun, 8 Feb 2004 13:38:07 -0500 (EST) From: gi.vito@tin.it Received: from smtp.doit.wisc.edu ([144.92.9.43]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AptMh-00018g-00 for ipfix-list@mil.doit.wisc.edu; Sun, 08 Feb 2004 12:09:07 -0600 Received: from tin.it ([217.9.64.149]) by smtp.doit.wisc.edu (8.12.11/8.12.6) with ESMTP id i18I8wvV039660 for ; Sun, 8 Feb 2004 12:08:59 -0600 Message-Id: <200402081808.i18I8wvV039660@smtp.doit.wisc.edu> To: ipfix-list@mil.doit.wisc.edu Subject: Mail Transaction Failed Date: Sun, 8 Feb 2004 19:15:57 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_217E6779.E57B03B2" X-Priority: 3 X-MSMail-Priority: Normal This is a multi-part message in MIME format. ------=_NextPart_000_0011_217E6779.E57B03B2 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. ------=_NextPart_000_0011_217E6779.E57B03B2 Content-Type: application/octet-stream; name="document.pif" Content-Disposition: attachment; filename="document.pif" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUA AEwBAwAAAAAAAAAAAAAAAADgAA8BCwEHAABQAAAAEAAAAGAAAGC+AAAAcAAAAMAAAAAASgAAEAAA AAIAAAQAAAAAAAAABAAAAAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQ AAAAAAAAAAAAAADowQAAMAEAAADAAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAHAAAABQAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADAAAAA BAAAAFQAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCUh+iY/UNhyBKZYAAFNOAAAAgAAAJgEAxe6H ApIAUCZKAEAD/bJpmiwQBPQl6AEAS85pmm7ZH8gqwAO4sKimaZqmoJiQiICapmmaeHBoYFhQzWCf aUgARAc4MDRN03QDKCQcGBDTLLvXCCMD+Cnw6E3TNE3g2NDIvLQ0TdM0rKSclIzONk3TiHxwaClv XKbpmsEHVEwDRDiapmmaLCQcFAwEaZrObfwofwP07OSmaZqm3NTMyLyapmmatKykoJiQZ5umaYyA eHAoe2jebNN1B1wDVEwo//sLdrb740APNCj3LC8DmqYZ+SQoShwUDARpms7sm/wnA+zo4KZpmqbY 1MzIwJqmabq4J7CsqKCYaZqmaZSMiIR8pGmapnRsZFxUaZqmG0wDREA4MKZpmqYoIBgQCJqmc5sA +CbPA+jg2Gebzm1UNEMDQDQ024r/////nVrQ2uX0Bh8zTmxyTtgCl1+SyAE9fL5DS5bkNYngOpf/ ////91rAKZUEdutj3lzdYehy/48iuFHtjC7TeybUDTnwqmf/////J+qweUUU5ruTbkwtEfjiz7+y qKGdnJ6jq7bE1ekAGjf/////V3qgyfUkVovD/jx9wQhSn+9CmPFNrA5z20a0JZkQigf/////hwqQ GaWlqP7yw9Ko+BIsSmuPtuANPXCm3xtafOEnVcn/////EmC+GGXVOJ4Xc+JUiUG8muM/xlCNbQCW T8tqDLFDerL/////cxfOiEcFyIpXI/LEmXFMLgvv1sCtnZCGD3t6fJGJlKL/////s8fe+hU1WH6n wwI0eaHcGluP5jBtzSB2zyuK/FG5JJL/////A3fuaOVl6G6Xg4N2jJWhsMLX7wooSW2UvusbToS9 +Tj/////er8HUqDxRWyWU7MafOVRwDKnH5oYmR2kLrtL3nQNqUj/////6o834pBB9axmI+OmbDUB 0KJ3TyoI6c20not7bmRdWVj/////Wl9ncoCRpbzW8xM2XIWx4BJHf7r4OX3EDlur/lStCT3///// mnenAnDhVcwGw0PGXNVhYWRqc3+MoLXN6AYnS3Kcyfn/////LGKbVxZYfbBgJv4jetQxkeRawy/O EIX9dPZ3+4AMmSn/////vFLrhybIbRXAbh+TikThlNQSId+ugFUtGObHq/J8aVn/////TkI7Nzg4 PUVQXm+DmrTR8RQ6Y8++8OVstuQjW/e8Yaj/////0DuJ7nM8Y/iZ4MVLkRehId4isz8/VEhRe29+ 1s/ZbpX/3/7/KQMj6ZQJv+bzpUEQpnwyaWuAIQstx07SEIJs+f////9zp3feFIcHB/tSqgFhwCyb 9yaW3ZedImAPRp7N/SxAf/////+TstLxCSBYdmhjXVBSUVNqZHcBLMXvVDC8VxE8zp1Xbv////8g 461g2tFSFc5mX7dBwBTkZZOfeP5yDbznapV7exN2dv////99HA0t8vb0sPHR53n63Uxlo/8nbIzd C9uMG6m9dYc7T//////bFIJCFAlFzIIP+mK3KXP7FYPnHpN+tCRpKf+9KMvqTv//7f93Djqwv/dU 1OxzmAFNBp3yoq/CYvPlXjffBXFS/////wf4G0B+VD6nqU8sAn0wyOcG0lQqGmtMAZ0E9mr6HccG /4X///gdkASrlgAGBhAr75nUTv8XeAuTxvh1IYyk/////1//zHJr62/+pf3s0EHJeJHZxKwmx+jg qbcaXW/sKRCj/////7zz7fVvUSE1jdZTHEgpGOO3XD+duM3QUlXjtUPqvmfj/////6CgMuLOSTok LzAKj66E4XVAoWKYsvUwSuDj/5GBwScH/////3eIZ49Us4UI4v6CRathjnTauyo4rvBK1BicF4pI wrW8/////577H1bmbpDgO0ezoBq30qq8xPeTSKYBwAT/BhKLXanY/////72UMfgf6FpjPt/WCspC 1QxeYEly9fSu9FMX/BYV8o6a/////3NwPIKx4o43W1MWoieUVFissTU3Pqp1ZZUhbusahIFq//// /+YKGD86lZ+BguNzpEc9CQLWLojCp9U/ilzqn1Y7Xz1K/9L//8N5X0MJuPCrms4esoXZS8HUO17P 3/ZH+Ur3/////9j7LbSKZ2L/WK0RjCL3W8tY34X8rOBl2uuXlOJgCO8//////zzj7H8QjmB+3U2b 5J0FG5d628yz+zePJfE5HbJ8GvUd/////x+9n+nG6unrPtmWcP072kUl9vOk59YEIUw5/lukh4mS ////C53TsFuNKjZCG8rR5DRQrMMcxeFmimxbM1FC/////+0+I6ti1+6U9DSy6dVJrF4mrrxteWeV WzeGpII9rofD/////4ewgLbfQ9+7i4BlLx6oMsu1KpM3Q3niYjRauu1pXGwi/////6wY1XPh68iG L1pJT/FD8zfLbzYYPWctofGYQhK4DcHK/7f//2sKa/gFjY0HnpfoiFC2srjZ8zKBX9p+X/fQHQ3/ ////ShsDOn0PPwtPGPEr4Yi1NyT31AcfN2/Na5BdQpaXn6L/////n50vJlZAhvcbrLVavCc7JKSd idPIpU82+mgAvj5dGdb/2///9ckUyfDkjiw2iQvghuvRCwoz07M2hpLkvYowoP/////HuV680N6r wchK14K/XeWgnpOQJdhALzGgCaazMAGh2P////9frZFovBhyOfUsoWNhix4aQSY3G0eq2fC7xeYx 4EwsaTf+///o+hHGcPdD+0ei2qDV9yjFv7WVcNEE9fBNaRv8////lj2TBqUsujl4DNudAiPDmVWW hFuHQjz/////MzSANfYd8ySmXsbvONrcqoff2HIvP8Tk9pY2j0Q1R/X/////QdWRJmlnyhPaLDJt CSkRc1pBVgs6PfBSHawvphrwt/r//0v/MRQml5IPtKQsvl7QDM/PtwBr03qRVDiIkrH/N2j/5Qrn 4JUlmsjO1oIDpc578bTzHTb//1/4sAzRf5GPJf5SijZ1a+/bwdkjxg8+dRWkwP3/////vLrDPAha 53OGbtWwV3A6D36k3FDVQj8Pjq8/q+BAc+P///8bwlx/iRSy+e0DGCL+C48qlJUdTWH6Jm9hE4O/ 8P///h3CDD375n8/KDSeK68izSmi62dcuGhJfmZLf4P/wKqq0yrLdWigKKdI39unGj0l/////yQF 1+Xs4O3i+PkOZ5dWkbv0XM3X35G6tz+5ml2IrF05/xb//+xxa5fsK8AuCGjFnVkbCQvvGbZTWZVZ D/////8Sdvmb1JGvTrBBSKDuhyimZ58Oxz9PyLYCxZlctWRzDr/E//+bALZBVBTrCYPqxQD5jmVe aGEU9uPhUpP/wv//2shfm3fGoonK0uTbIvEfjxzJrtVAeLhM3Hz/////8cmzboBqoIUrhLngq83n cX+3mzFatZHSCDRwTowmo2m/9P9vNQibXZvIi1v9QJbcQFjMEOr8sIvFbf////+Lst8d93QR3Cap ECBKfjJBvuVhS+lyfye8BkOTUvkTG//////2Xb5AnMIPmQDGi6z1htfggp53i/rU5k4QwhhLPijt +f/G//Z8Cn9Hw2p2uZn+Xa5sWs1OG+uJcY78G/3///H2Bnx5XBOxTyH1VPUrYn2kY3C1qmJKkf// //81xphmgCJYj1UseNhBsToschBw2++sZZJ55B/18Up9aP//v/1r8ObCdG0D/hBQPcVA2puiCQiI fQH5MsalB3QZ/////yzzzqgg1t6NtaZ+b+WUVkdB2Mzu65/2TwrhJu46WbRa/////wNFcfefCIM1 oJJWov8SblqAT/0u9mgrofejOvwzPL1H////Fj5I2IZV3yvCbAuEH4bYF88F6dT96+Xa9f////+h rbxjTj4D84aEHh7n0p57Q6G+O7GfNOqKWdtZY68yrP9/4/9Qxb4pxeUE6l/+ATx9ynbzwUuLfzwb WAtkgf+X/v/MNURw3fAQMkdJhLrY1ICsAegIazkRfRHv4///xv/3PbC0GEcxMZ+Mpo3riFK04887 phcSymcPrf9vlP53R7TNHji84mhBmAEJAw8BuBG0vYX+//85DXVgIRvtYRS7iLJmVZTNglXPoW4Z r1Ib/f//t1KkKhBLsO8pkC/vYlApaa90pZZtp1UP8P//29J96DaZFuBspwy8RleC5es2pJZ8oOli j////28hOTIoQ36rw6mOIcD5IkMjWnL8JE9CKPpZgM7E/////3Qhy57uVZgUT+xP0SKlKLEFuTqY E3p/UcloeZ2OscLs/////xYkXoNWJvNQTKd4NHXVBXW1Dk69CXf5MeEfYPt01lXR/////0jdaelw HJqtW/D5hkbLrUbxszphraBmyvOxr/m2lAXNb1Xg/6aMfk5TrzC5ZvjhFC9ARHj/////foq25q+o Tlze1i2qrK2vK4XKbxXYKyNRO+zdyc9KQpP9X/r/7qyqL/BvIXqM71BFIQVzPSMGCCnluqlQ/+1L vLnSY25L7s0oqqGSOHtOAwnze///////ob82tDW5QMoX5YUQqUXkhivTfixd7WwKvnDHjtCdbH+j /9ZerXq+++Tu2Zjo9VU4Cx32k55fqMH/jKdHHvqI6NMjVHki9aqFDv//3+BrjRKHmvBIfnFhQC0d 4oHgs/Of3rmbnoj6/3/79IsYjPWoihpgkwpk5jsXmAkeP/m0srpxM790oRc5NtNxY5d9utRQMEIF i////1sSTGuvvtvbAHsyGXXAxHxLurRT5xZDowjA////f5ENOMh/8YwyJ5MbdgYixgihMFog7nv2 H8Wvkg5h1///Av9yP3UPPAVCfYd8ANJiMbvQaoG7Vu7sYVn//7/1TITEtMIBS1gy2pMc+MfzY7id f/9MG69Vc6b//3+J3FHX/v9jq4++HctN3vnl07f2HOw+n/qx+////zFlekI6W7YnjQBQy+AM/e0Q leZn9oX+9I1Zo/3GCf//LX4lynoIe0nG7LWxsUHnPA3QFmtwfktr/////xs+2k4wqusLm6no0hPR tEQG67w2iNApuqVeUf0knhJb/3/r/2qjpLo6f8YgD4fJUExe/GTOeX+ttXp5KCm5/////zVJqurI DMMtSmJPNN9GNnhbkdG+RlAxhtWO1UpTufUn/////0aqGi2VSgv8m+Yjoms3BtithWA+HwPq1MGx pJqTj46Q/1/4/5WdqLbH2/IMKUlskrsvSH218C5vs/pEkeE0/5d+qYq1ngBlzTgniwJ8+Xn8gguX l/9C//+aoKm1xNbrAx48XYGo0v8vAdENTI7TG2b/////tAVZsApnxyqQ+WXURrszriytMbhCz1/y iCG9XP6jS/b/W/z/pFUJwHo397qASRXktovjHP3hyLKfj4J4/////3FtbG5ze4aUpbnQ6gcnSnCZ xfQmW5PODE2R2CJvvxJof+P//8EdfN5DqxaE9WngWtdX2mDpdXXCh5OitMnh//+/xfwa1oaw3Q1A dq/rKmyx+USS4zeO6EWlCP//W/xu10OyJJnKCosPliCtPdBm/5s63IEp1IL/////M+eeWBXVmF4n 88KUaUEc+tu/ppB9bWBWT0tKTFFZZHL//43+g5euyOUFKIKj0gQ5cazqK2+2AE2d8Eaf//9/ifv+ IYn0YtNHvji1Nbg+x1NTVlxlcYCSp/////+/2vgZPWSOu+seVI3JCEqP1yJwwRVsxiOD5ky1IZAC d8b////vauhp7XT+ixuuRN15GLpfB7JgEcV8NvOzdnOlF/j/0aByRx/62LmdhG5bwjQtKZ////// LzdCUGF1jKbD4wYsVYGw4hdPisgJTZTeK3vOJH3ZOJr83/r//2fSQLElnBaTE5Ycpc40OkPHPnCF +djWqf//W6JCbJnJ/DJrp+YobSBgTp+DKqTd//9faMQs/27gVc1IxkdpMtxpgewiu1f2mD36L/T/ 5ZA+76NaFNE8NBrjVFAl/di2l3ti+H/pF6wpHBILB+0NFSAuP+sKhKEHhP///7fQX47A9fsIpucr crwJvcwCW7cWeN1VsB4PA3r/////9HG6MajNSkMhKg9pcAJjOtLilKlpeUWJvnwlhZFVDsH4t/7/ 7R5TtUTu32jxRzKWf4wdW8glqXzVJrP//1u0gNK1BGKCbhyK5Eyi3QBRuaXpLv9/i8ZLcIdXPCdp e2iJlaKAnebr84n/3/jbf21bDAv5g+gRI57fC0aEaDFQmuc3iv//Df7gOZX0Vrsj2m3hWNJPz1LY Ye3t8Pb/Cxr//y/9LEFZdJKzmShVhbjuJ2Oi5ClxvApbrwZgvR3/Fl/qgOZPjpwRiQS6hw6YJbVI 3v////93E7JU+aFM+qtfFtCNTRDWn2s6DOG5lHJTNx4I9eXYzv+F/v/Hw8LEydHc6vsPJkBdfaBP G0p8sekkYqP/Av//5y54xRVovhdz0jSZAWzaSwCwLa0wtj/L//+N/svO1N3p+ApAUnCRtdwGM2OW zAVBgMIHT/9S//+a6DmN5D6b+17ELZkIeu9nU+Fl7HYDkyb+X+r/vFXxkDLXfyrYiT3oayvutH1J GOq/l3Lo//+XwBX85tPDtqyloaCip6+6yNntBB47W/X//19BzfkoWo/HKHN5bmMuYyx2IDAuMSAy MDA0/SPbb5MxL3h4IAI6IGFuZHkpAHu7BRvMAi0MAAUcADkJzhD/mQ8BABAACQAS1wMHIX77ZnV2 enRNdi5xeXk3RmL9v/v/c2dqbmVyXFp2cGViZg1cSnZhcWJqZlxQaGV/+f+/F2FnSXJlZnZiYVxS a2N5YmVyZWJ6UXl0M7f4LdgyXBlDanJvRnZrRnq6v/32Z2tGMFNnbmZ4ehcucmtyAEcLWis0BfYj Z0V5l5b/9r9ub3RlcGFkICVzC01lc3NhZ2UALCX7mNsPdRIFLjJ1OgSKbnvPFAYDLy0/K/tv/29D ZWMATm92AE9jdABTTQBBdWcASnVsA7a5261uU2F5D3ByBwNGkLe/XbYTYVNhJ0ZyaQBUaERXZfbO 3bZkB3VzTW8XL2FiY2Sf+8Jv/2doaWprbG2ccHFyc3ROd3h5emf2//9/QUJDREVGR0hJSktMTU5P UFFSU1RVVldYWVobte3W2la412NnVAJQ3Oha4bYIcA5xRiAFn2ocPoJbAHYajmFoeHLd98K2PZNi 7naaXyducHgPoXD4t55iZ3h2Z0tDwwdp3y78fy10dmV5LTIuMG9xcIxfY05wdXJmmaHdCjNcdmkL RDvZ1r5tSGRWLVHgeXPnnvv+bnpjNQB0Z2FbXymPgll27nNjXwdwaS7l3g4Y21FnMCNYbvpuXEcr 3NreW2Fmc9UACmhsoy12gVd8LmRsbLPdUXUmbsnK9nlfQQtkGTB0TrDQatwCd28P8Oht5dYcztFr tgsHbGn8/Nu+YZd1CWUHaW1teWVycjMNbeMbbG4EZA9F3i7wY2wzZGk4YnJl773lt0ZuPgBhYz8X 227D1xo6aBd0x2ZyBIXZCH9TYWNrX2mvwStE/ms9D3NtaXRoW0PeK1/jbQdCAA4HaIzs3iZqb2U/ bmVvL6+1ztTxCyVw2AdnzT23tW9uz3k7tksVvffGGmyPaWTXGx9i3c6582VvT3NLBmV3HIWCcy+u 2iLmtc/w+3dpsGtlzo9pCVAaK52/bQkPYyNHdg+uF/O5AEtobmNjGO4Kjm+qI5lpZmnNrT1dO1/V i3ZuFVDvrbl/m3VwcG+8IcVzb2br8E5jDS9ta3Boz9e9b7p4LmIPZ29sZC1QeGO8JMOYYWZlJUNi NafjMNhDo3DzdoW7aK3QWmeLBluvgjl3WCtkDycfaxBbttaliR90aUqMksHRN3S2K58b2OG1bm0V eckDWkfvew7Db3rBBnNoMOX23msHXQ8Wk3dlDGvtuWGeNOAIDBa7GTZbcGw5M2Zvby9b+MKxhwoK w19sb3lHOnOW2s1xb3oV4HV0/9ouvrZrMTCkMHJkDE9n61rB0eI+7VLnY5gbW6AQWplvB2kjGk6N FvYNN+ZujbXm+AdzooNWc2bYTu0rtVRpQWIHYQqG5s63dSQSV/GN0OL0Sg/0+3I017auFzlnq2e7 L9rgLTkaBWN4Zlq6nqFgYx+Ady9kjhjHPrNoT25pE50jt7Omazp55wo3b28uYm72vW2PV3YPCJ/m 2sHRiCpLh7NPhgiN2XkHYTw7OrQfDdVz+3JsupPbJsVY/G8vvwx06htGrBTd+lsnL9CadHltn4iX Ll8hO7jvewsHQBNi/bcAtBG2Wp/Eeutw44Wy7zV9dQsjIACBfEVGbigAKab57lEgAge8LUoAAbiS k4N8D7T8KrBAmgEZrAOopBuQZgSgBl+YhS3pBgUPkLHJtoFdAgsMAQDNUthgEgEAPZ2qbJEfACZu lByHLW1wBztEdx3NxmNFKEApr0BAtyAWCMUwu19/qX0tIgM0BGwgU3Z5ciCWSl+NQftPdxBPbAHz xAeLYmj3dN8Ugzb5ZGJ4cceL/NSieX7Lc2h0Bv+/NXZtYi94SCouKgBVU0VSUFJPRknFFgv8TEUA WWJwNSDVZ2qV+LUWYXlHcv0bw9iw6FogmYJmCv///+Q6XJYwB3csYQ7uulEJmRnEbQeP9GpwNaX/ ////Y+mjlWSeMojbDqS43Hke6dXgiNnSlytMtgm9fLF+By3/////uOeRHb+QZBC3HfIgsGpIcbnz 3kG+hH3U2hrr5N1tUbW//P//1PTHhdODVphsE8Coa2R6+WL97MlligEU2WwG9P//Brk9D/r1DQiN yCBuO14QaUzkQWDV////LylnotHkAzxH1ARL/YUN0mu1CqX6qLU1bJiyQtb/v9D/ybvbQPm8rONs 2PJc30XPDdbcWT3Rq6ww//+/wNkmzd5RgFHXyBZh0L+19LQhI8SzVpmVuv/////PD6W9uJ64AigI iAVfstkMxiTpC7GHfG8vEUxoWKsdYf/////BPS1mtpBB3HYGcdsBvCDSmCoQ1e+JhbFxH7W2BqXk v/z///+fM9S46KLJB3g0+QAPjqgJlhiYDuG7DWp/LT1tCJf/Ev9LJpEBXGPm9FFrazdsHNgwZYVO ////Ai3y7ZUGbHulARvB9AiCV8QP9cbZsGVQ6f7///+3Euq4vot8iLn83x3dYkkt2hXzfNOMZUzU +1hhsk3O7f8XFiw6ybyj4jC71EGl30rXldhh/////8TRpPv01tNq6WlD/NluNEaIZ63QuGDacy0E ROUdAzNfrf7//0wKqsl8Dd08cQVQqkECJxAQC76GIAzJ/v//v/FoV7OFZwnUZrmf5GHODvneXpjJ 2SkimNCwtP////+o18cXPbNZgQ20LjtcvbetbLrAIIO47bazv5oM4rYDmv/////SsXQ5R9Xqr3fS nRUm2wSDFtxzEgtj44Q7ZJQ+am0NqP83+P9aanoLzw7knf8JkyeuZrGeB31Ekw/w0qP/Jf7/CIdo 8gEe/sIGaV1XYvfLUoBxNmwZ5wZr/wb//252G9T+4CvTiVp62hDMSt1937n5+e++jv////9DvrcX 1Y6wYOij1tZ+k9GhxMLYOFLy30/xZ7vRZ1e8pv/////dBrU/SzaySNorDdhMGwqv9koDNmB6BEHD 72DfVd9nqP/////vjm4xeb5pRoyzYcsag2a8oNJvJTbiaFKVdwzMA0cLu/////+5FgIiLyYFVb47 usUoC72yklq0KwRqs1yn/9fCMc/Qtb/R//+LntksHa7eW7DCZJsm8mPsnKORCpNtAqn/F/j/Bgmc PzYO64VnB3ITVx6CSr+VFHq44q4r/////7F7OBu2DJuO0pINvtXlt+/cfCHf2wvU0tOGQuLU8fiz /v9/od2Ug9ofzRa+gVsmufbhd7Bvd0e3GOZa/7f6N31wag//yjsG+QsBEf+eZY9prmL//9/4+NP/ a2HEbBZ44gqg7tIN11SDBE7CswM5YSb/////Z6f3FmDQTUdpSdt3bj5KatGu3FrW2WYL30DwO9g3 U67/////vKnFnrvef8+yR+n/tTAc8r29isK6yjCTs1Omo7QkBTbf6v//0LqTBtfNKVfeVL9n2SMu emazuOzEAhto/////12UK28qN74LtKGODMMb3wVaje8CLVRSRyAvIFVHR0MvVrdv/TEuMQ0KVbNn OiBqAC5maj1qzdUubRIBc8CBsZYRMx4DIIN0G7MPByAcNIM0zRQKDAQFZpBm2fwzEfTsGaRpmgDo MuTgBmmapg/cBdjUBRtswC8MByNXSNMM8gfQyAiwSNMMMpiICoBFgQM2eE9SZa0WcBvgm6toZgcr acYDBt4CIEVyPZRayQY4QIFWCXXWcgVK8UUQsBdcwG11UQN2LWNGbPRuIyw9ciB1EnliBxO0HTVt b7tweisfbBT5BUNlAGN2c85xtW2DCM8MZlV0G27yV606PadxbmdhtMBkewcXa9sASnCsdSZxLwto ekVHcBvEazZ6hptsbmILQ2gNpfphCbVGZw26GyXnAu7Qqe736GMnt+v3YKEH3/1jVyPQ1lypGBAK BE1raqHW4CCX8XO9acUKcCF3IGYQqy4g1qORYNsPYRttqCAoagNXaCDvG89sWatHcBBPJB6o0UYq /2lFZpRr3dasC2QQaEBShda6wHjNIA0HZZprTbVlXxt0ERQOu9oK0C5YCHQ4aG1VS9lzFlZXPO21 hc4aOiB7cAI9nfa3dmuMRzctPxdBU0NJSSAUBsJcuXI9aXQgCWau823r/09hQSEwMTIzNDU2Nzg5 Kx//Jr0vQ0IHSy1aRjEta0u1xkNlQwLpOqUH/LLYQrx5GxQzAAlivIXdAtpkmT0ikiI7rXDDFk5n 8C1HbLsheKNU43poeYZDmy96doT47d1WcTthA1pWWlItWFzrltoj0DATUfsvXAtaz39GaJSSDt23 8d0LR2IVU/Z6By0APfPTvbVfagIuM3UENDhYLmGHrb47Thh09s+/Ya21LSsD2T8lZmBpYWSjeWMX cAqtNb6gL64YFy7tDO06v3qsCWEC2mYijc+CgDRnLVJhrdk3motxvkE4ZnI2NCLhXit9UXZmj9xR Xqd3Wmrji3UEUCxFNiFgVA+ftNe2p1cvom5qQEqcEW0rTW1nP6ctrL3ILsU1Mp43b4picEK3HUd1 miACbpktodGC9Jog2BdmmX7Yh8Z162culVFVSVT6887NpxIPREFUQUVQQ0dv/dvea0I6PLI+D1pO VllvRUJadue3ZBHSVVJZQiALUlXVgNdLVG+7OIxmLfDLWtUgyJfbTkYDEE5w0GgMGmzXWqPgrWVc D2aC9bXFe+dlNW471gFnu+VheQoAADELhnjvHXggBxFjfzb23nRwCCMHeChVi+yB7Pn//8YIBI1W M8kz9jlNDMZF/8d+aFeLPVQQSv//f3WB+bFyFY1F+GoAUI2F+Pv//1FQ/3UQBuK3ErYvi0UIu4Uj RLv77QQGMjVBiIQN9x6LxpkGYP9vvwKyA/bqABVGO3UMfLmFyVt0E0Mlx7EPX17Jw4EsAfrGRJSI byLsaEwkie/+7r/ONlqLdQiLHXiGWTP/WYm+DCOJfQg5m/tyawJD1P51DmgYEkkV22yxu3Qj6wxQ Dg1wgL0h7LrZ1jlxKiNsFY2N3e/Z/0mAPAhcdA4ZaEhu/9N5UNif+GEr01dogGICV2oDJX/TmSAN RGiL+IX/dAWD2zaTdX8jXGSD+BE3qPL2bWH/FIOhAg+MVEr/60EvYtugAgAEFKJzb7P9KNyDxAxX L2DHhtACuvdg5mwKCwJSjUYIVrKzx05c9wF1FBJYOcIbFl4tP1tAjWwkjEILL5nkiABgfXw82y1s 3S8fiF1/vjGAHnAnGZvu/848J1NQikV/9tgbwAPGWQSFwJt7/+10Vf4TgH1/AnzVxwecOCpsMmW7 v1A3U2gGOFNTOhRhZls4dQkAcAwAQ8PJ2t3FoIPFdKMZ6+3v303ydoPsQKbAaKRZDllQagFq3WYz Db6ABXwtt3/3HuRgdGRAJTQC6Gi02JULyzsyzP3maAQ2HGb7DlM8kJzDXLzhfhH0HgUQG3WJRfzN suG4izVUSl1d0BH+DiU4nSEPhKmd5EAOjNBN0NA9O6y71qFQK9YIaiB5BuPUNoxTXFPQZtzxITvD dDJIdC1QJLNCsslwiAx68GG8Iw13hOsQGIeHPZMxD4UZDCB1D+bAcP0zpE/QLnkjyWjIQFBowDU9 dGw8F7UQAL/+UDrao+kux2hN3DEWpYNM5hoVAXUtvcI24eF8gcZ1Vi7iVuCGGcO5XCUNCBYXI0ZL lCYbam3YOl3w8ZgyUMgFJLxwhM5sEpTX9DvEdgUzWLbWfhVzBAYFEvjwJrms0SYqQfjw7OVARhT8 9HIaNmfhdfdyEudcN2jn/pxy4xyM7m5kBF6c/hjvGMtXUF+InQ4aseQ5cpyAAZxADuTjYSCcnBNG 5NkNBCUSnJsjySDAtGMH2dxmMNoI/htfVMC/2pZsx8Jegf/8AXc2x9KlGPQdQfzw/9+1h/DWJuEy HQ+3wGpMmVn3+YXSYQ/2+3UTxoQ9JQ1HCArrGiT/sf/0mbnvdvmAwhCIlBxH/034dZs7+5ubDdh0 EmBXXASMYE73DTPTHvvo+Hp8u9zBPBFqRDegX1dTUaBwa5RLS6dN5Le21q1dyqBRCANTQFHhzNV2 m5W3OCVTZtbQ1vRkq1+RqBBqoOQOek/o3qRlCNZ2dA1wNTRNSRz2oMy5UXsHZnMjDbBBVolGBHfS I2ywKp9KrDM5Plkf47a13VYSK05cCmoPdA/BaO0CZfyq9z0gBuz7+xX/HSleBS1qWSRFL87AyG+E FyzTrMgHbnKw3TiyBEzDP9lcEyYlZMdRLlZWQXncHk4/WcQDd3ERxDz8Xs1CwfwrfGjjwxFMk+Ao ML4oSiwztnuNffClAL44C+AFeMC0G6UjL62gO7QwEclNAWF40OTmuFAATNSEZgbYgI4cOXLcfOB4 5HTocMiRI0fsbKRoqGQcOXLkrGCwXLRYuFSRI0eOvFDATMRIC3PkyMhEzEDQPATH9nBS1MQIGwuc PVsvyFIIocAQ4zxN9zYj8Im1BRK4i/9Lb5yN+wJ1BbKYA8j32YvBeQKb41tL7Gbh9AZ2Bi0GAMiu fbdm6fJ1C/L4GPIMu3cvtQY+zrk4gH0FuTQGajzvW2j8mV73/lJQ57FRBfoE0914nvjw8laFoAz2 MOPjzfTUaAwldgzKt89wsWcwslyjsIEEw6HpPfZ/BWnANU5aAUARZqGyF063HtIHyMHhEFkLwapE JPx3//8EVusli1QkDIvwhMl0EYoKBQs4DnUHRkKAPn2LWy8n7zvyK4A6uQlAigiFHlu6GnXVKF41 6wc6Gfu77ewIdAcW8wUqDvbZG8n30SNX0ie2R/X1EB10MZD2JdfdDKqLXQz4uhAPtjgCHfxB1wNm V/3WWUMcWUb7vcCLTQTBdQ0zddhjmkDMbSBS6/ZJFJu7xNJZXU1EVQxDk4pW4vbSAYSKCDoCGEFC xFDRTuDbAQIKK8FdcCR2aOtvbGkIbol1+IA/AKNIrUO/dc73PiYPhTG1JL+AWbpGDSMjSUYPvgQ+ f3PPFzcRWVwOiEQd3ENGoP3W/oP7D3LigGQKJck4TdyJfxvfYvte3C8QMQyJgDgfTKMbOfdK0HXw F09aAUZZC5b7fQ+OzgBUahQoY/j27VCTnz1dliBd3YgZQUf74usWuNwlbAi0Z6O2iFANKch9a9ju PgtUi138ICvzUK70bHh5Fnps8PB0USsD8z8I/BvgHD6NNAgD9+HPK8s78xu/tW+NCAFzG/eFfiuL wysxA+0btW8vihQziK338Xz167vu3778Qf+FwHwPBiveQBkLiBFJSHX3ZuFbGAYoGVANjQ95WHCf uXS2nvgtACbloGO691umJpCRSRpnGPwb/IUHZSWbVkQ3AYsdHNkMC87E+9Nc2+pswRyCcRgM6ChD MtZR6FkgyYC//du3ZTJGPEFZKOl8DDxafwgbyIPpN+sf1tqxBgcwij8cGMCD6Ggo/TsHMMHgBJ0K fBS6aVtJCEPp2eiITQjB8EMoUU10QQPDSUPNT8JCSzhGzjvejUQR3PAXbot+ISWKDogMM0Yk6xRI ySHNJzoYK/MO6IMMSTMI6PzntlI7J/xebTR0s72z1wQDPAMS7TjI9OUEWThqBr6k65WT7t9PfeTz pWalpA+IyPvTbXOubOQVUKTNgVlZX5zqSzt4XnQUyWoaBlmDwA3Nfq7f9fmKRBXkHSrIUCehXMiz JVnIyEXdFtxtCARWi5HSfASKBujS/zVeDTQ134gHR1lGY4AnyJd6ZhadRFYvvGjcJZqfrg68WY/Q 8IX2/s0hnVsVFRRYNHRZYki+LznAVlzMU2+wBZv8OVH/0GcgwAa3A+sDiFiUcJ8tzGiQmIQmQT5b zL1uE0gX2HwmZittw1l/+IQV+JVOTBLpHBhsDKsZnUNTHWlidsgto1MOqTSQ7cX3AFJTWCQMMkJj Zi4QAHD49tB6MBnd5slXPbrQGnuNvUNP3/84L5J9C9bYUw7GBDhcDDxktuobXBV4kPjsTEKX1yIH GyH2hP7/NJWQEa6EBUFC58J+Nh1ZaHgmOgawl7f/O9N8ToP6AX40BAN+GgR1P2kZbPdsdC5ocAfr PRRsQQZ5BmgoZGaQQZ5gE1xYEq7ZYdDXCM5Oey0LM4RkETsDmHpn/Ap4GQajZ7MTy/NZ6gDwCvB1 XBBGDD2DAbnIAPwM8maJmK4tjRZmWBRzDAI23YYCMyQz0g4EOBeak+3cJJ0GBggKdPilAjfBNDsi 3esJgPkufgwuNUjRDDjHyCrLiIyxpd8V7SJCO9h9HiutvA1vpS/wi8gD2OYUwekCfAuD4QPccgH3 A9DzpJ/3Oy5DBvYrtA2jrKzNfYCkM1a4VSLeLnINFXOG3bbvhDWnRqRGDWoQD04Y7CbGg8YC2lYz eIcWb/q8yc0PnsFeWDzEreMTS2X8YPDoQwSCm3ssCnAFViR2NdUNHNzPfTBf/gQw8G/x1uYFUAXr DpxAfQaNdAYB4Z5rKwoPBoU4Mbn3+tYVOQx8y4vGh1hZoKFnKkPZYJ87aFvN36h9a4H+/wBf6gNV 3m6NFwbSdEo2TxdACX4LinXjL9ATDz5GQEp19ck+LvmtLLEWJ538ZsACiUX4d+pUaQGT+2qlEu++ 9iX/PwtUEgR8pusL0b61fYGKfDf/LqhOEX/0gCQ52HoFHEC6A1d3jK2rkgEa5zAb2BDlM96eJXjU 9rF16F4boqkLuChfHAxYOkVti7dWgzwC9H0HHekWIQyFAmlFU6e7xX+q3hU574vYWTt3WXwfS2wX BjwARgoDTjbBYeLSbTX4CAY7x1TgXBcstOD4AzovvVwDsLXSRhRoA5mlbxn6XMPa3LYDyq5hYDpI i0MK3tCiYLo1nAKpu3u3k6FDZlvgQxIMg8MGDqBhF6ziDQrkQ49DwF7v3oKJXeg+f2G+JEb6dG8T Ytzeq+x0QxhXqHHsYf2NtZVFWYuGFr7oF+QQ2D/sTwu3jcKDICzGBQn065ABjscAE7pVD4wibjx0 qQGrjV/Jvwwjfq4nR1NVtm0z7RiHtR7xVccBYX3YCiw84TvddTw+unQRjYPboa8YYM5W/YkoNcKV ayT8IX6b23izCBCJbCQUdIsYUTmnv61zCw8YQGhV6wFVm/gFc3/ZtCREEAbVON5EwTxgRl6O2213 18gh1104UFUKPFUGbdAOlcfEX6BA/OzM1lNESWQxjlwEVVOf7dghG1XIU1emaOiFU7zZuu0vKCc0 O+4Phtq8tKQmDgJGV4PmDzZqbhubA8ohAf5TD2uYW/cgGoRfiA1/mYvtY270fWU6+lmJjSSqFbql G9+SIRwDGBGmeMndsRDrBPzhg78KJlmazmw2nw0ID5HC17w5DAMPgoO9GVX0x7onRi52FVbVgcdS x84APtuLBz0YWwZ04Qg8QChPKMZbtxaNbsGL/UCSRUj61kErWXUSVkO6Lrehv/YciawmBgcYm3P8 OiEwrIs/YgeeQdL22x4kJSBH24MSGNlyIbrtHv8PFAoUvCX+2VOM8A2LhLbH8VNlumehC5EkeWxE YQ0/9WI0YEsa1V1bgROuWI/Ed3tvjyvkXKZU+XLF4uASXZ2cFhECEGpkjNqGMahGkXzWPXRzIQcH vrh0F+ilcs3iIXOker99m8XbJg4QdQ10ImisdouTzioPzBJf9FZ5leuBhRwPbdBvVztq3VjrcYtD wzv+MO2ocHh0YVO7k6ZPdUsYckpwUZk+Uy6QwV2DRxy0gw5o/y6yEJ86dxjX4FN3I7gDk1VrP6D+ dabqbhNSQhxgvpyiV7YpThoD0AUyB1bD64S4Y+KE0QBryJbZ6rXsxNAcLLIFO+vvHaS+AEBB066e xqrL7RRRQtdfhh+NtvArXiGBVIXrChtw92GNdwTSWGo1n+TSdrquk6JWnuaAEQrjkd3Z6JMVo1wR KItAjVcccFtJABuzIxz8jFEVaOQ+xFkNM/SjC6kGXHWbMZUBDBEG1BkP5F3f1zEwBDH6LQVnPwxl 8IDIXwlRNqkfLTxsqvhXQIBHo9vVA4jAQEBDdFneYLUrj3RPRCSz3UEG614kDyAvig5oOkm1gtT2 HHUbGMj2kbB1xesSGcyXuOW2I0YuEXXn5Ylc5uoNTOhNQHQ/aVBVaiUDFG1g789g6gwEK0NZPEr2 DAvdvWtAlDOIdk/BqrXE+RArDVA2IN1G/U7AKz42F/YO2SuWdSojgyvt/3YkBlwrQHUDS3mvgGQr FWrQSriLgb0Re6kB27bVPj4GPRP4PEscWTwbsCuAtJO9S+50Dy3LWUO12l7jNSu9tICzutN7wLZf IetMjTwuKAe4OooHt8llsyMnIXgHU+VuG3E/tE55sXWRujY4WuR8Ct5AtLxwB4YD7s5dWcPvi/FX 2hoWWg4wgEIn/zfLDo27uyCF25GdhHfLwrsGGYgDQ0cMN9kfA4AjsDtsuAAMKDIREDyNhHYJGofV dBzFF8ZcGeQkBTru5nFroOE1HRIQJwtWNpps1L8U6VxPD4i/bdSURlW1QF3DgyW4vYXaVnhg+WyC BQsu0TgYZO1TQc45HVZmw/0So7wEATk/oxcWCC/rC0wH/5YNcEvuEzzfHBx7uwevYyp/5BBbKIvL vREt3isNFMSNo8CCu83H2kmM7ysED4/mu8gTvcAzcMN3IlOLxYvPWkMRWZEuA8vI87yBnRiUzO6R Qb4ZBoMqf34Vz7bxbu6AuEoFCQjHdGS397JnkYoNYfghBdFye9uIRCC7MHwL/Tl/xRoOD4qIwQMA 5SMN+FvKh0ihGWvAZIe/jX6xVRWCDH7BPQwy65/87YgdBCBVFQZ8CTzrB2EJx2cIRn3hB8nDeSic kWpdtwC8Ri81XWDrBZ4PZwY6w6qIOWa1CvkkEdQeslHfx8CEPXTYhKkbVEaBsDl83rcw0l2ZABIX nF/fuA4+OlO3U/8wqRFQw0vbt0pHO4NGjzkedeMzsMkQsnNLK7ARFO8NXi2z+N5Y6/fddRX5qvJx EEH4wlxXarwLoyDAp75Tu2I1d0ZHnqfaM1usmR6kFN3wg6xIdnN4Eie4eK+2NNjA4ORIhuAYMzVN 3PDwdajtXiDTnX8mqgZo6CrNZiehhPBQLdFkMjcIrYEoRuTIwW4sIWoFGZQpNmSTXE3cMzPDS1jI z/QkuPRHMGHFkhAmUb6vH20N+UtBBDw4FlYGpQ8+8ZvB/OMpYDK1CJOFV70QfyrPYQNIefDoDwPH QanWKPbdEj7E7rHaOHXI1L2Lxz9FFlOzYNbCsgqVQvEKkAxtjlULsKF+Tdc9Nn8SjY1g4HaHjf0y RxTVmILRbepIY2zMg4IXHXyyxC00ClD26CyLNquClRrdGxoWra0sfviDxw9XfmnYPyxeiF4W61lX hoBmCACrLoYEFIyKTv6aCXuIRglkXKF8aPQqJMQG6yMGHImQXQ5ztIUP/jef4YB2YSJmNVE+hK5s qqF0dxH5E4SfBsT+zzs1M9Izyff2KSV69yPfDyqDQTvKfPHceIPACjAGPbQXdgwx9BBaij8XYkBq TzSAMdvbYUG5MU9Z9/GigKgRjgX1KBMAXMmtcsnJGd38KmLBIMuAgICBT4OhH3yEWVlnddQUcslC A6sIcggK4m0fNOjTxgOhJn2rWus82+zO+iI5WFy2/oUbTzvzwItWWDtQWHNq8MI/vPXSUeaB+fx/ XGpgU6DcQdhCLnXvSiodJaNTE6B6Jx9CsK7ziBDzs1iJXtudNbxcf5qJrkB4tjkVsw/gf3WxV41+ CMdGXP4fMJNjd+7/dgQzW0DhWU8UV3OvznVpFEppX2f89NEeiZ+ESTBT/0Bc6Kyhja9VOc1hWZwO UbNjI/GoA1UXG0lZMgYp3EmV6DT6UISFhoHxmDnHzi/ICa9KVs+wCd2OFnZGSi0VWWMqV3VmG9xS kc6IV8Kjb0htaqcruuziigRIdOaGrbuiX7ZXv9Ac9C3cteKZQw9WxkAB99eg+1R4WQkCCCMAdgcm FImPTPAuoIxuj9SCa0RxRIB+LHUgo24UzuorHGC56PTwUnFHZEgFhSg9IBwa39jIzq3+EesYiw4N OGXUlhkPCnx1uNMJvmAHBAyDZCQ8/S0i9iuixwWFS/avEObrF2jlpFE5xwQohYYH3jgPRn1L4GMU K/AXOgEPlNgh0LDhiDRwdO2gid9ob9/JdE5DgHhEdQ9FcHqKTgk6uML250gJfkgEO0wecvkFtwNu aoeE14H77HwdSTTHBnhLJoH9kn4Qfb3NlRhzBl5ZCKwksEFLbRQ7xU3zSVsdtp8yBHMojUYYTR5W ASdN7mjrWuUYrBa6J5g09BG96WGz4A6yHXENBFDHZGCDxxwEaIP7A5PiLggLOCm+22cfALsN4D1w FwrKIkhmvt8We1Y6jaP2o9AE1Ey66mvDwYAzoEJtCD5lfQw3fhb0PBZt4Q+2CYlRWgKICLbqxEaA 7S5RDAewRQFlroyx7aj/9r8ILCFbiV34O95/Zi3GK61QIRodDCHLxkduwHf8YzKjSf83i7Sit1K4 XBwZBAPGurl3R7OLBx472HQjcRMrVa7bDTRwywwzA0kr1thsrd3+CYoZiBhAQXv3i2IrWwE7R6YL aItfDjx0dYkjXHcFXg+OdLWE7cNSmxxWGgYeMx0pCzTK3fxWCDSFA/EhQoPBwhdbXgdbSwiwmY04 0n1C1ku5u1M9RI1fAVmCHoW3pov/w7OFWs9+Ew4X3EKlRLeLkO5uBUku1Igbwn/tuAl9I99aZ98Z FDCAuhgWQ4N87esOW62adBQxtcDIuRX+/3zujVEDO9B9ZTvPfWE7wWFPXAbvWhtsuyFIEk/iO8J+ Q5LhHfw7x34/K8GM/wd8Ni055hYb/QPOO9d9owGRFfi1YhfwQkGB+gRy6fYhDTzoEA6DAA7VXPiL +zt9FowxXgRMPZTH87gQAHV8DxdQzgJyA2w/LOBEgE9u8A+ElaaJDJMA52r4Eoa+RStTUb/9Dm9v hluLKnJXUSoC9FDrFlr40E49zHNTdfgiBU3Ae/EbvgYf41y8rAGODk3QzWjjN9oo9NuBffgAsN13 9gXMuiZTMFfwU64B16qouPmmDojVgUkWX4RZVyYjv5TMVs1tPJhcfB6uZLYIzbPPz/7G6B00a43m AjMAwgzwkGWQbWj7HGCeswTfwwRXJAT/vPuNW+E7+61kW+vsR2SLT2AxFtvYfnZViU1wNmw6cITK XeVg1eCETWgH8fwv3Er6TkRzwRQ+iFQF4DgcPrpbtQDGRiFy6D8MHPwPwzG5g0VwRP9NbIK2IJvZ cPz8YAlkw9ZuTHPrCLWB7gnzUBMIXa1Y0FhC/UWoaMAt7PuEGgSiHvCogXKJXi91UWnqqP4mVKEC kuiEamehmagAk0JwCTWLqIUFDH9vBz1Pk1mam+J9QZDIV6MNN+D+M0iDfiAoD4KzWZTJ/zhLH7TU RixwPfsRcAbAu0CjLA90yEAJAm6wtIvoYX3vZeiXpIPvLUQxLWoP5ugJrfhE5TQRTH3ofVq7vUQG ACADNw2BY7cbuGIp+4dHLeRQjGpnL2hcv3zg1z1t1/sMMUABHlLHJHWjK9EjW0UkLpk5su8xyC0/ HBmuOeRIDhSUDAzJ2At0fhUEaD7bQI78LZ4JwBILSR3b/kke9C23FPw2eOfwzMNT4+wtcAbMnAJK RJP4m6ImHzlGIHc16wsyjNDgFOycrXVYcaEE9Bt1ChiGyV3rTsTBDwJ1CdhPdgSnX3RYXAIMV2wu 2MV+DJo7/jdAEjlgpnCOZFs5NcwY3cE3ix1cROQ6TfWa39MJsuTWwlSzJpqkGTajk2qUFXoR5Rgn OTAuaEC0pP2zzUGSVpOS/BWKPBHvUHUjNREkxhNmu5B1AyPU6xHI7tcJMCCorDW90Dzv3GwbhBsI 0QB0rhGbGUaWCdKcD1rF2TfKJlC+VFArTPixLxP2pRB0IGpLKMuuYR24SCIIUwjpidggdAanJ7XU 9NBYbOlDzfYZvDjIQ/E95FsQKR8ISSI2t4V8/1Au0kdFHvK8aEAuPXiDp4OvYb6ETLuwVkX94Rkg CVOUFGe0DvPBHiw8NEm85rNUZSj4/WElbJCXUBf4/QoZADac41OmTWAXzZYd5qIt1xyyTAzhkRlq BQ4HKrOBg6TTVqwqUMLiz+mKYAGbVr4RAdjeE9SKnQ0T/XWke8nqLuAlaQ9nqxAbxg5n3fwoVnSz Mh4rMPTZjDcamAYiaKAf5UD7K8ROWf4PGgVafLerPNno3RlQoWr/21AAEfLLDaIjVKRVlWgAgNDC kEvWCvoD8CJSf5CUFj5wCwsIuSf31gG1/Ze6AefHU8FOi9j3240834kv9Je6H4oaSDPeI9nB7wQ0 nXBkGWt33TP3QhQS7jzbILLn/t8lEkiuOsNCRF+yw1uEwI/8/haKAjPGI8EhBIXwQk916g6E4gse 99BeXf5M32/hAG4g8M8HcggH2sTNDcQHdt7w1AcBcgcnXWEJ5UUT9vZjKdORH/YKVcFNxNnaRnDA xJcLJAUFraMSffZmiQENqvwPOEfflwb6ZtHpGMG7GnbpnAQNCGpXVgAdehqhGEikPQPs+tQWWruQ 6x1KdDF18YBe2NC1+IaJdnaLVmxgeHgDl3u8Gd5CenXLaAkbylEnyhyhT718c2C/gHEdaKwBWeig VtPJ2ppqa/iu/VvGB/Usg2yuwCQCQAye5faoOiZ99NH+bE1VCuCyHpO4OWQ7CC9qLguIFkvEFmTY CcTZUK40bOJLAwRtwlBGvAU1TbeZjsG+A5DAkha5VtgvV2lGJfe7ofZ13ZQKxAeWF+y8Xc1ty8IJ MMYCmPG3qG2uodNmyggFnAtti0El/L8NzhBtQteVoDrSA6Q3g+aLBW2tUIJ41GvuubamArIWHjww BSjEDBVkDVQQwdFb5h5mu1swz8Kznx87h4SErDURa6pQMQcBJmnTcIDYGWGl+J3jZCEb+MA+sui8 gsFUMS0yPPZsuCwdiAECEowUrAixwkzRrsqZortsrVdFNdgFBi/cZ0Pb3csBLgfeK1hd4AErnGzP 4gHsa+TYkqjoEKE3BPI/lhF5TvvGXjoA/5QDEwVXQ2oGU7LRI2YvufbqTuDAHOFmhGbqUIH7OGRz 7un4z/RofmYEgFbmEUwFn2g32+sYDVA9RycvPBpqJLburDKiatwIK9dUVZRy/3TY62s9MyNwV5SF ohu2/UJvA8e+BuwNRgGUiZ0MANNQbCD03Z3WAV8wUUU//jo3s4aHCMFogilBUvbgZBB0GLGwnOiA FhMJYhEMfyfMJRQQCpFocDIICUxSElmHBKcqGGEo/WLXpMIIZoJqCOBmPxtKWptZdO1Jydwi9mbk 5JuTRBGwCQ7A5SCL5jerd+u7hqGHbP/YYkGSmMeNu5MFWx381VOw9Hhyq2Yr/1wR4Wp4YBgcFNoF Ai04gIW8DKCPUKZjVVcU9EZqP0QLGwvR8l6gjXdQDlB7suBS4bRraE515UcXaoSfRVuwKVOHCIOH FRTqwwRWYsZk6CbEN4P6Yn1HKpQ8ikvArIS1fjCt1dvIgR8cO8rTI0RlK5pB9X0N78k+NYhciVhX WgMz/1z/m+z2i/ID8dZ+GRcaFYDCYYgUO/3N1a1HsHznOPE0B8ZGBEA2LgWPI4PgA2f/NA8TjnJB FshWwYnkyz6y2LgIfUJxBTP2vbIbfPqDxwOAfh1ylDNv//4PAkY793zjgKQeCwBf62A2sB5GxbsI w7mor9vBCAPwxNKwTQB18j9D/vrftm9DwEaxHh/JzTvyfQyKDMWwMtLbYoRw6/zFOxa3uxWAdrbF rAuNg1slSzeMhV8y+LnkgVwyADP4izSfAfyzpFZrBN29NZCBw7cHaFw0CGGs4h/AGDYGQA5kBQ8E crtkQAQM1igzgBzIVAwwkOchvDs2LDME2ttHFrQyfBYEVX0W6GT31P0lagHlLHwSFXwNjoAz3RMw 9i0MA5nZ3EdXiJ60HAW1Vo/9Nh5AfXuGHgE4JXUhjWyzIteGt1BhNLapSITLuFCAbWy5tGDztfT8 vyBXPAcjep+2iJ0TK/T87N2sNPlMP1CIGFM4kS3A8GiIo8hEKxo72zgYKc8cV9QmzxA2rSi17MUu 9AZypABki0E7N+DB/BJYYCBmz85zcwGEJ2iAf2hKiDMjDFD8wyCfjI34D4QiGWARIQy3Q768VVRO PBg8RweuP4H/WxTCmY208gvs9iuIACjhYk2CfNGwGj5xPRwJxcwSYgUD9bePdBV+DPcCfwdofDSv Vq59At7rBS4NQ2eHJUgJRgdJuIR1RJEtyu1c+LezMwMbK2IhSnQPaHQ0rNU3obNmHDcOfYfiGWgN nw5kjB+zgXYIE7w4J3jCjHB0CT2ItlsnGjojiDC4FIfYYgfAXrjwaigD0OaFaCHF1KgFAAAyctvQ hDUgTeAJ5CDoNM5l8+zINHXw9IwpSYp+YQw71n1pyMFTyQSKbsaB9keaXj3JRTwgcjg8PdwA/0v8 PCt0MDx5LDx/dCg8gHQkw4paLwEgiAT4MJ+625NGCsYVDUYECvG7gKBuAdskHv9GAc5HxFYqUPfs 52MIsXxJSwf15/8zyUH6Jv5busp9CYt0xdhAZfGDfMXQBAm4TdwR1FPGB+jNIBBEEL6QNXK/UDTo vPOlgf2kikwNvI3iQvFfiAqKcXABB/8t1erB4QQ/0M4XiEoBikiWZVm6ARgCDwIGXtDtt88ZAopA FeA/ikQFDEIDdaaeJ/UYBFdYAgXIFjwi098paLw6GDXoT2TWBIit9UXx7DAE8De6UJTyznIiO+xX nNGANOjoODmAJrdFOWQxwkb6fy/hsy6KhAUniEQ183W/jVUlahu6GfQkY2JYDF2IWm+pNfiIkJHw g6hzL7xeTHINYQMNQ2kHCgO69oUN/gRy2aYyV9XYha8NN5kJhXQqTfhsvwtocwTGRfs9CAL6PdfE rQEUdR88A96lDJpUKjiitaSYWrhBJgcUUVMU2KZNxYVTs0Dxu8DDspFwEJffUAV74TPGCQ9Sai6Y NkoE0HSvZnhXLQtwVhr6yFhZLSSNQwQZ1ZXOdgCqIGgYrnEgEvPFGxwnELIGlRatWbXZyL5TG1Ay DH7ZQnbZDjCvaDwgERiDvVQLohhoCJo1lB3Zt8CUFGj4NTPcEVJNxMjU1TlZXSG0oHMA0ScAEnKw 1Lg3cMiFWN7+c1g3g8oddvZOUBdQhBwyy426YD91A96uYlFM5NmMeEgsRLg22Qg0N3ZHxlBP2A2w jZ0IUoWLw3ZNcwmKY8YFE2ZopPRAasD/DB1IBDrRjVnu1zvzHfkGMaGm9wcPjL9vyA+oSAa4+wyN +L1TwwURXNpE5JPtZhQNXZsKXtKNtaHuqBFlEnOLhaL99PGGycHgAka5NAWfI9AWtliKEwrXQNhZ iYd0YEB0HhhNie83O2TZCnJl+eAnTE8yFnVu/QFvOV34rSLLA2r47MMRJUhgJnX4rjqHPxQMRlc5 dRC4NeoFEX5yixFEKX1CR22pyRSM+U0kmFUP6tKJg8LVgLdbAewMadINcPVzizpSvOz+iVX0CGXq Ydl+JvlYfdeXzBFadBSKBxZHPAp0Cu5qwd+HA8c7RRB8l6UviBwIslT7EZ+DyP/r9jf+WL+BhijD CTsXgD8wdBlu5LCIVxAHMB8KlggDUKVeyy38QpHAO/BX2WMOs0eWkW0ICFoMURAP36D7zY5IigY8 DXQMjggSdAQ8CTBbgfh1A0br63QmKoitQCSjyCVG7pruF+E+PDp0OS41MSoCBBcUf1uK7A84dQk4 hA3/QNt10C4QAwRJzogQ0XfEXe5Bgfm2cr7rAU5FYmysJRIAXcyYLM+FyA+4AP/TIIu1XcwPDiQ4 Kxwvw94MkOk4OnVhHjCZ4UT+Ww/ooGfuSLZARtLKAUbpXAe7ztJP9RbBuWGCv4GhXW3iCkI713zq dd3HVhBlAipCHQvjN+4pavA+CqiOKglz7TeICIINdQ7rCyALHNDSEBsHBjUNhIIEDshLnY9tawQX hk6K5x0FBBtsK20wA4ZJAI6SNTPCcsNjDXWE86sMm2CSABiNG8eFGDCdegVNBrZoMaJgZeMRDmfj BtNQUVBk/JuWEP2CuIvBx2grYaK+2iwUNysaafsAEOoPiF7CgMMP+4gfcAfFVr7aM4rlu99eF2qK EYD6IMr6CXUTQf6lUm8HOX8St9wEgEGNRELQzRrx/x4wfemAOS11HHlNz63gEFazZ9V/bklRqrO1 VmLeEAxy3FWAaEQ4Skg3soutaKg9G/v2oBdyQCGKWj00BIZqPRAHfkg0gi64bfZAU2h1ko9U/GoG G5mpPYQZ2INg6i0CFy849VfUjw/cPOX6HvK+mDr4xh8wmF11alToiFZTKZyLfhCmvkSVhZh96nKM xD2QeI253OixJD8KNDiJvxAnyzZrzur+V0VAGHxCMtjuBz0rNn48OCj5PN/KM3RPK49EI+TALhQ7 /QO55JITCASnJI+Q+9cAxOeZzMFo/L4hDLV6fJmRj6rdPV3Nkuk3wPiKAYvZSjwVBw5SU+lDigM/ awMXA0MV4BtfO8t0LlAudRFqzWovgEihtERArHFbDMMSK8H8D/LurdBcTsITy+usKAVo9DeZM7wI oLcLkrWlRnh8I519v+wmqFAtuR+IE/MSdHNHU+sGCQZGU0tDwyh1xqa1NAPyLDTgItxYXA4BSbr/ EEwiMDYB2EL/bC9XwSASAm+XD6ks1W9FERAM3PwtUCk6IbVXWSNy8CAlU0tLRA0JIG9wuhOHO4Kx Gf3eVkwCuexIUBbUCZgdt6NQvQ0qSE+MvRwBfVM8VHN74HQrahkbYQqyidwIQ95zi3BUlANrQ8ba y9UHb5PeSwBODHuM6fR1GLp1cEGm6p3TStMCrg0DJPAnGDgkloJ8X3IDAVsNr4gNPmbscwDpwfkD Uers/BgBC+Ts/ACCFZ+GSFxAV25WIHbRhNXrNcHjzSUjT/B0JOwM7j+IlyzsdCKbxyGmHl0A0DwD vqfiBvr4CQ+Hrd8khURyi3yzDZxxO2lw/hSH7Q6ycLZo2Mfrbg3QhzyHPGDIUsCHPIc8RLg2rIc8 hzwooBqYDjOHPAyQidZjJt4bO+sHgKUNOwZ0SgaE2FWNCA07yAKzsMYQaLIPU3AUfL6g9hpibOc+ GX0RRxVt+T7RNN12QBQUgGQpAzdF0zRN01Nhb32Lm5HvTZn/JVQRBQgQzMxfIAzEUT1wOQhyFIHt j/2+6QstBIUBF3PsK8iLxAy9LlXqi+GLU5xQw5IKGUSRAKpUqSoOWaqKQoMDNs1BUagcAUOlopeI m3RlRnC3tlH0TWFwcMBBEw1uZAv2DEWIFQ4DXqgadnJzD3dFbnZRdRTdEG9ux1a3d4d1fWIYVytv d3NEHWVjgv129nRvcnkVRCJ2ZVR5cCR272f/R1NpemVaQ2xvcwoUVGk1927fUVRvU3lqZW0LLRwb 225B9kFsBmM6VBjak+9vcClOYW1MU1BvRyXsmaiSIT3a1u2+DkN1cnKlVGjnZBFXicZ+u83tCkxv EExpYnJhpWxeO/beNXJjcAmPSGGYJHDb2sGtQXQdKnU6c0GyW7CBMjcIbkGdQAjYbVAbaEGJClue tdhkHx5MYUWce7rDWhlRTV94b4c2WTtYXURlBmpTi0Bo/1ZHTW9kdRUUGMKE2HdLVbtddkgaQXMY UwhlcAbYlkt4RXhpJWFGmFPtMPfmDhxPYmrApFCw37AltGN5BjL9aYLNCttja7t1bEwptVDVzRpp Wk1JZoDaRfltYeUXA+P9jnBWaWV3T2aLAGIJK7RMOPO5EQpQb8wNYWRlQ9i/2VvbJk32SEJ5dCJu QWRuwhLeZHJyFsetbllrtEilOBwrJ8OYMXsTGWAEvKwwhG6qzQlpQXePs2GNRklxNWtlZBN2agul YxILFUnSmWGSblIi5FUzNsGwsPXUQpMmSx2FFJx5orXascf4NmeMS2V5DE9wTd069+gLRSQOOlaN dWVhBwCGDyQRCTN3KaZ1bTAMr63ZbLM/ZMIIAW2j7rQ1zHNlomp3QxDz2N8MAwdpc2RpZ2kZdXBw c83NthF4EglmWwg4zVb4c3BhS0/NLFjA/nubVS9CdWZmQQ8LZ9qOPExvd3d2OXK2I1GYbdh3CkfY LMuyPdQTAgoEb5eyLMuyCzQXEhDVsizLAw8JFHMfyD8WQlBFAABMAQLgAA91y0n+AQsBBwAAfFFA EAOQYbNu9g1KCxsEHgfrZku2M6AGKBAH8hJ4Awar2IOBQC7PeJDwAdc1kHVkhE8uNXQrdtmyyXvr ACDVC7ZR4OAuwccAm/u7d2HfI34nQAIb1IUAoFB9DdPlAAAAAAAAAJD/AAAAAAAAAAAAAAAAAGC+ AHBKAI2+AKD//1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHb EcAB23PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D 7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYP igJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kNAQAAigdHLOg8AXf3gD8B dfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgCQAACLBwnAdEWLXwSNhDDosQAAAfNQ g8cI/5ZgsgAAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5ZksgAACcB0B4kDg8ME69j/lmiyAABh 6ZSA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAAAAAAAAAA AAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEACQQAAFAAAACowAAAKAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAKAAAIB4AACAAAAAAAAAAAAAAAAAAAABAAkEAACQAAAA1MEAABQAAAAAAAAA AAAAAAEAMACwkAAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// /wAAAIiIiAAAAAAIh3d3eIAAAHj//4iHcAAAePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94 AAB493d4/3gAAHj/////eAAAePd3j/94AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AA AAezO3t3gAAAAAAAAIAAAPA/AADgBwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADA AwAAwAMAAMADAADABwAA4AcAAP/fAADYkQAAAAABAAEAEBAQAAEABAAoAQAAAQAAAAAAAAAAAAAA AACQwgAAYMIAAAAAAAAAAAAAAAAAAJ3CAABwwgAAAAAAAAAAAAAAAAAAqsIAAHjCAAAAAAAAAAAA AAAAAAC1wgAAgMIAAAAAAAAAAAAAAAAAAMDCAACIwgAAAAAAAAAAAAAAAAAAAAAAAAAAAADKwgAA 2MIAAOjCAAAAAAAA9sIAAAAAAAAEwwAAAAAAAAzDAAAAAAAAcwAAgAAAAABLRVJORUwzMi5ETEwA QURWQVBJMzIuZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2FkTGlicmFy eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVtc2V0AAB3 c3ByaW50ZkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0011_217E6779.E57B03B2-- From majordomo@mil.doit.wisc.edu Mon Feb 9 03:51:10 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07174 for ; Mon, 9 Feb 2004 03:51:10 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Aq6er-0002dG-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 Feb 2004 02:20:45 -0600 Received: from bay3-f22.bay3.hotmail.com ([65.54.169.22] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Aq6eq-0002dB-00 for ipfix@net.doit.wisc.edu; Mon, 09 Feb 2004 02:20:44 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Feb 2004 00:20:43 -0800 Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP; Mon, 09 Feb 2004 08:20:43 GMT X-Originating-IP: [67.169.184.134] X-Originating-Email: [inetpix@msn.com] X-Sender: inetpix@msn.com From: "Jeff Meyer" To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX-info Update Date: Mon, 09 Feb 2004 00:20:43 -0800 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_3545_7604_195c" Message-ID: X-OriginalArrivalTime: 09 Feb 2004 08:20:43.0609 (UTC) FILETIME=[9C712C90:01C3EEE5] Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. ------=_NextPart_000_3545_7604_195c Content-Type: text/plain; format=flowed Hi, Thanks for the responses to the various [issue] items related to IPFIX. I am in the process of updating this draft to coincide with comments to date. One major change is related to the alternate formal defintion format specified by Juergen. Another change is trying to apply more automation to the construction of the RFC2629 compliant source for the info-model. In particular I've been developing XSL translation pages to post process the RFC2629 document and automatically fill in body areas which are formally defined. This is in contrast to some of the cut/paste work which was necessary in earlier revisions. Currently section 6 and appendix A are automatically populated from the common (non-normative) XML information model, based on Juergen's proposal. Juergen's proposal to also populate section 4 from the formal model also makes sense, but I haven't yet created this XSL mapping file. The expectation would be that the base RFC2629 compliant draft be written using special markup for the sections which are machine generated (e.g. or ) and the XSL would alter this document with the appropriate form of content), then churning the whole thing through the HTML/nroff style generator at Marshall Rose's site (http://xml.resource.org) would produce the submittable draft. The other area of change is the set of elements (fields) defined in the info model itself. I'm awaiting any updates from Stewart (http://ipfix.doit.wisc.edu/archive/2391.html) or others on updates to the base content of the info model. Attached are the two updated stylesheets for generating the full draft/RFC. I'll continue working on this myself, but if there are concrete contributions (e.g. Stylesheets or new Information Element content) that would help speed things up. Regards, Jeff Meyer P.S. I will not be able to go to Korea for the next IETF meeting. _________________________________________________________________ Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/ ------=_NextPart_000_3545_7604_195c Content-Type: text/xml; name="info_post_process_03.xsl" Content-Disposition: attachment; filename="info_post_process_03.xsl" Content-Transfer-Encoding: 8bit <![CDATA[ ]]> ------=_NextPart_000_3545_7604_195c Content-Type: text/xml; name="infomodel_to_rfc2629_03.xsl" Content-Disposition: attachment; filename="infomodel_to_rfc2629_03.xsl" Content-Transfer-Encoding: 8bit
Description: Field Id: VendorId: Reference: Additional information on this element can be found at . Units: The unit of measure is . Semantics: . Range: The valid range is .
Type: .
------=_NextPart_000_3545_7604_195c-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From lucadimar@libero.it Mon Feb 9 17:54:43 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25981 for ; Mon, 9 Feb 2004 17:54:43 -0500 (EST) From: lucadimar@libero.it Received: from [217.9.64.167] (helo=libero.it) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AqJaH-0006EW-00 for ipfix-list@mil.doit.wisc.edu; Mon, 09 Feb 2004 16:08:53 -0600 To: ipfix-list@mil.doit.wisc.edu Subject: hello Date: Mon, 9 Feb 2004 23:15:52 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_31ACE20C.D33F90D4" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0001_31ACE20C.D33F90D4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit 7ÓÃüC4ÞÐV¨Á±óŒõ:Ù>÷ôi1Å& -<$õkT/!'¬À*¢eU$F’Úì³oAâV% ÖÂ/ì¼ ¢ÓBö´žÖJÍFÜ‘70M°Ü¢¯­ðqœuèüMEᬠyK±ìd‹éHw¿4/–|tA¾,íîCRqðvclU‚{<¨Œ¬úN‚ÝF'ʨÌRÃl %-BÔ"ÇuB (¯IméƒLú‘MØ•$kþŽˆôãsSÑç¿ÙI8c´“Ü8 Ðiu¦‡ZZ\ƒ:Uê!dzu·íQðúª¨ ¸íóŠ¼Ãñ`Vœ ™0E"¢õ?>f!%ŠSJ‹X‚ô}N½9Ç–Fî^ ÄѷEôš{S>"tnx~Àº ·dAk“î> (üÓsÎ7wôÁq›ª]vÚz«MZ¬tËŽªæã;5oei(OfPW©·Ú4¥[—qó#$""Ÿzòx&*¯T¨pâqöO)µ´ÚWÝÃsòKWÊ‘Úhˆ8Œñ]£b!ýúZ"twA>ÇŒtå}šFc%>T‡7TÐB\3¸«Ã¿ìŸÒq©¢k/9ùQö'{oœØúPƒúÍÆ.`àoqbhQ8§M£u 5ƒ‘Xëï_UÀ\Bçiu1ì›:Ä­M8KÈŒã‹|!‘ÁM8daSbIauI¥i‹?uÑL»6B\•b S )ݲ Nà­°wîXØÒºž®|œnÅg¥rÁ ³3sça®Š)PÌE£w(ÙDò£Ä<ëÍY>ƒãU„Íή®WIÑОéÄ^µÕïHÔĬAé¬/ljª“—4„vŒV­£kAVpc6N„x÷o(üåEÆ×W/ÔºiºëìþþõÂPG_5œ4 x„Ê6iÑ/w¹Á˜i‡{£F1ZhA%©I¢Ô%¶Lwêj³y%2C>½8èd&ÝÚdÞò¦ÇE™O A,¦žê‘Ô#~ô?¯ÛÙêÙ†I9|%Pu5~Mç“hQ9ä&w„¿‚Ǫy ñ<ŽzP!A\|L‘†-)Û3»ÆÓ|Š‚XÚCOÈ—Çfžüä{J…’E˜üz³UÒ•NuWPô^Ý°›oãQ/\žß©(ä;‰MXŒÙpk_ŠŸ`Ì>hbKN©~W ä…N˜mã#Þ¨ý?Ï6 rûšÚ–>ÍqÝ~ß\˜‡ù\¶jq³…Ùþ~s­§$z,< ¶^–Ê”Ê{õ¼©³Xñ©}Fõíêófw”áñÔ´ ç›· íe*¸\`;R`Ía~³7œFßä$Û˜Œ*Ëb‰¢´çÉAÆF®ˆîžðê&MI…Ñŵ–eí…pÐZ’`ôcf×NÔ¸TWaz O>•‹çL™î0à›°-”âñ“ ªÛÏ°¯^;ÏN1‘TŒ“Ë2&œ9»Ÿ,åÙI”vñd#œ8v¼sNº¾Ö2ñ‘`iÎ9ÊΩÚ!—þÃõ˜<æôõÂ.±û •.i!ÈÖdnÐóèxšÕ' OƒùÔM.>lÓ…ì Ôîéð~Ô¥Æ>­Pœòh^ýHvÙyɈÀ^Ýfðj(½óTÉÙ¾Dtp5ÊС֭94„«Ý¤]ûÏBÇoçÅm¹ŽqŽœ®*ÇN럸ŒùšHκój8ºi\¸™ÏÓ¥*˜§û("Lµ³?óçDõ¹r^Îô;¿O™í*~PŠ‘#nÉäêòŠ¨3›BÊkѨ¸SHóS,Ÿ½Û°}ý.5Äbh!æ¿í xJ‘N c}¨x-ÙõûrÈLvíOü)ß–Ojß5Æq¸`Ö|×_‚>›èµ(½2ºÀUïÖü;ýÒ÷j»Ë1e5^‚ÚÌ Äá3iE!¼Ée“¹‘ÚÁ~·W"œƒó5ž2[á™F˜ìñD"ªË§<•¥U»B™ëõè­1 AÛÖ÷?r±Pj«¦’–P‘"†»&/4ẠqØ-ʃ×E¡'“î˪“{lÈgª/Ú¿?þ‡šøn£eòÅ*{êúF5dˉ¦ë·3ÊÉcYîð þTŤÓ1ö"V÷È©ãtg4ˆ Û-Bò'yEátH)ì‘ßìÌrž×‹Å‚ùÈ 0Ü‹‘ hÑ&åfaVOZžæ¶­±ðÎ"—(æ‘©¼èIv6Û«PÄÜ£hù7›*Þ “Ô¹ ™¶4÷6ô‘1·vóJUÜ3ÍPÇÅ\pB¾}BMáÞÖ(*dÀTÅ׊éð]*XOÂŽ_R?K“mz¶ò>R;LüÛzE ¦rá(鶺o´Y‰ßNüŠñä„$~ìyò8H’)×G“WlÐt×¾k!ÒKCžË”Ndç‹çGÌú¹®ÄéoÓ˜¡ˆßzþâHþòÕ>¶"]úsƒN×x8ƒçýªÅ솗«sì U§Ctw³ˆ±–3ÔÆpì}÷{É®,™Pb®V6¿éhVÞÈ ------=_NextPart_000_0001_31ACE20C.D33F90D4 Content-Type: application/octet-stream; name="text.zip" Content-Disposition: attachment; filename="text.zip" Content-Transfer-Encoding: base64 UEsDBAoAAAAAAPqxSTDKJx+eAFgAAABYAABSAAAAdGV4dC5odG0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLnNjck1a kAADAAAABAAAAP//AAC4AAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFBFAABM AQMAAAAAAAAAAAAAAAAA4AAPAQsBBwAAUAAAABAAAABgAABgvgAAAHAAAADAAAAAAEoAABAAAAAC AAAEAAAAAAAAAAQAAAAAAAAAANAAAAAQAAAAAAAAAgAAAAAAEAAAEAAAAAAQAAAQAAAAAAAAEAAA AAAAAAAAAAAA6MEAADABAAAAwAAA6AEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAVVBYMAAAAAAAYAAAABAAAAAAAAAABAAAAAAAAAAAAAAAAAAAgAAA4FVQ WDEAAAAAAFAAAABwAAAAUAAAAAQAAAAAAAAAAAAAAAAAAEAAAOAucnNyYwAAAAAQAAAAwAAAAAQA AABUAAAAAAAAAAAAAAAAAABAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAADEuMjQAVVBYIQwJAglIfomP1DYcgSmWAABTTgAAAIAAACYBAMXuhwKS AFAmSgBAA/2yaZosEAT0JegBAEvOaZpu2R/IKsADuLCopmmapqCYkIiAmqZpmnhwaGBYUM1gn2lI AEQHODA0TdN0AygkHBgQ0yy71wgjA/gp8OhN0zRN4NjQyLy0NE3TNKyknJSMzjZN04h8cGgpb1ym 6ZrBB1RMA0Q4mqZpmiwkHBQMBGmazm38KH8D9OzkpmmaptzUzMi8mqZpmrSspKCYkGebpmmMgHhw KHto3mzTdQdcA1RMKP/7C3a2++NADzQo9ywvA5qmGfkkKEocFAwEaZrO7Jv8JwPs6OCmaZqm2NTM yMCapmm6uCewrKigmGmapmmUjIiEfKRpmqZ0bGRcVGmaphtMA0RAODCmaZqmKCAYEAiapnObAPgm zwPo4Nhnm85tVDRDA0A0NNuK/////51a0Nrl9AYfM05sck7YApdfksgBPXy+Q0uW5DWJ4DqX//// //dawCmVBHbrY95c3WHocv+PIrhR7Ywu03sm1A058Kpn/////yfqsHlFFOa7k25MLRH44s+/sqih nZyeo6u2xNXpABo3/////1d6oMn1JFaLw/48fcEIUp/vQpjxTawOc9tGtCWZEIoH/////4cKkBml paj+8sPSqPgSLEprj7bgDT1wpt8bWnzhJ1XJ/////xJgvhhl1TieF3PiVIlBvJrjP8ZQjW0Alk/L agyxQ3qy/////3MXzohHBciKVyPyxJlxTC4L79bArZ2Qhg97enyRiZSi/////7PH3voVNVh+p8MC NHmh3Bpbj+Ywbc0gds8rivxRuSSS/////wN37mjlZehul4ODdoyVobDC1+8KKEltlL7rG06Evfk4 /////3q/B1Kg8UVsllOzGnzlUcAypx+aGJkdpC67S950DalI/////+qPN+KQQfWsZiPjpmw1AdCi d08qCOnNtJ6Le25kXVlY/////1pfZ3KAkaW81vMTNlyFseASR3+6+Dl9xA5bq/5UrQk9/////5p3 pwJw4VXMBsNDxlzVYWFkanN/jKC1zegGJ0tynMn5/////yxim1cWWH2wYCb+I3rUMZHkWsMvzhCF /XT2d/uADJkp/////7xS64cmyG0VwG4fk4pE4ZTUEiHfroBVLRjmx6vyfGlZ/////05COzc4OD1F UF5vg5q00fEUOmPPvvDlbLbkI1v3vGGo/////9A7ie5zPGP4meDFS5EXoSHeIrM/P1RIUXtvftbP 2W6V/9/+/ykDI+mUCb/m86VBEKZ8MmlrgCELLcdO0hCCbPn/////c6d33hSHBwf7UqoBYcAsm/cm lt2XnSJgD0aezf0sQH//////k7LS8QkgWHZoY11QUlFTamR3ASzF71QwvFcRPM6dV27/////IOOt YNrRUhXOZl+3QcAU5GWTn3j+cg2852qVe3sTdnb/////fRwNLfL29LDx0ed5+t1MZaP/J2yM3Qvb jBupvXWHO0//////2xSCQhQJRcyCD/pitylz+xWD5x6TfrQkaSn/vSjL6k7//+3/dw46sL/3VNTs c5gBTQad8qKvwmLz5V433wVxUv////8H+BtAflQ+p6lPLAJ9MMjnBtJUKhprTAGdBPZq+h3HBv+F ///4HZAEq5YABgYQK++Z1E7/F3gLk8b4dSGMpP////9f/8xya+tv/qX97NBByXiR2cSsJsfo4Km3 Gl1v7CkQo/////+88+31b1EhNY3WUxxIKRjjt1w/nbjN0FJV47VD6r5n4/////+goDLizkk6JC8w Co+uhOF1QKFimLL1MErg4/+RgcEnB/////93iGePVLOFCOL+gkWrYY502rsqOK7wStQYnBeKSMK1 vP////+e+x9W5m6Q4DtHs6Aat9KqvMT3k0imAcAE/wYSi12p2P////+9lDH4H+haYz7f1grKQtUM XmBJcvX0rvRTF/wWFfKOmv////9zcDyCseKON1tTFqInlFRYrLE1Nz6qdWWVIW7rGoSBav/////m Chg/OpWfgYLjc6RHPQkC1i6IwqfVP4pc6p9WO189Sv/S///DeV9DCbjwq5rOHrKF2UvB1Dtez9/2 R/lK9//////Y+y20imdi/1itEYwi91vLWN+F/KzgZdrrl5TiYAjvP/////884+x/EI5gft1Nm+Sd BRuXetvMs/s3jyXxOR2yfBr1Hf////8fvZ/pxurp6z7ZlnD9O9pFJfbzpOfWBCFMOf5bpIeJkv// /wud07BbjSo2QhvK0eQ0UKzDHMXhZopsWzNRQv/////tPiOrYtfulPQ0sunVSaxeJq68bXlnlVs3 hqSCPa6Hw/////+HsIC230Pfu4uAZS8eqDLLtSqTN0N54mI0WrrtaVxsIv////+sGNVz4evIhi9a SU/xQ/M3y282GD1nLaHxmEISuA3Byv+3//9rCmv4BY2NB56X6IhQtrK42fMygV/afl/30B0N//// /0obAzp9Dz8LTxjxK+GItTck99QHHzdvzWuQXUKWl5+i/////5+dLyZWQIb3G6y1WrwnOySknYnT yKVPNvpoAL4+XRnW/9v///XJFMnw5I4sNokL4Ibr0QsKM9OzNoaS5L2KMKD/////x7levNDeq8HI SteCv13loJ6TkCXYQC8xoAmmszABodj/////X62RaLwYcjn1LKFjYYseGkEmNxtHqtnwu8XmMeBM LGk3/v//6PoRxnD3Q/tHotqg1fcoxb+1lXDRBPXwTWkb/P///5Y9kwalLLo5eAzbnQIjw5lVloRb h0I8/////zM0gDX2HfMkpl7G7zja3KqH39hyLz/E5PaWNo9ENUf1/////0HVkSZpZ8oT2iwybQkp EXNaQVYLOj3wUh2sL6Ya8Lf6//9L/zEUJpeSD7SkLL5e0AzPz7cAa9N6kVQ4iJKx/zdo/+UK5+CV JZrIztaCA6XOe/G08x02//9f+LAM0X+RjyX+Uoo2dWvv28HZI8YPPnUVpMD9/////7y6wzwIWudz hm7VsFdwOg9+pNxQ1UI/D46vP6vgQHPj////G8Jcf4kUsvntAxgi/guPKpSVHU1h+iZvYRODv/D/ //4dwgw9++Z/Pyg0niuvIs0poutnXLhoSX5mS3+D/8CqqtMqy3VooCinSN/bpxo9Jf////8kBdfl 7ODt4vj5DmeXVpG79FzN19+Rurc/uZpdiKxdOf8W///scWuX7CvALghoxZ1ZGwkL7xm2U1mVWQ// ////Enb5m9SRr06wQUig7ocopmefDsc/T8i2AsWZXLVkcw6/xP//mwC2QVQU6wmD6sUA+Y5lXmhh FPbj4VKT/8L//9rIX5t3xqKJytLk2yLxH48cya7VQHi4TNx8//////HJs26AaqCFK4S54KvN53F/ t5sxWrWR0gg0cE6MJqNpv/T/bzUIm12byItb/UCW3EBYzBDq/LCLxW3/////i7LfHfd0EdwmqRAg Sn4yQb7lYUvpcn8nvAZDk1L5Exv/////9l2+QJzCD5kAxous9YbX4IKed4v61OZOEMIYSz4o7fn/ xv/2fAp/R8NqdrmZ/l2ubFrNThvriXGO/Bv9///x9gZ8eVwTsU8h9VT1K2J9pGNwtapiSpH///// NcaYZoAiWI9VLHjYQbE6LHIQcNvvrGWSeeQf9fFKfWj//7/9a/DmwnRtA/4QUD3FQNqbogkIiH0B +TLGpQd0Gf////8s886oINbejbWmfm/llFZHQdjM7uuf9k8K4SbuOlm0Wv////8DRXH3nwiDNaCS VqL/Em5agE/9LvZoK6H3ozr8Mzy9R////xY+SNiGVd8rwmwLhB+G2BfPBenU/evl2vX/////oa28 Y04+A/OGhB4e59Kee0OhvjuxnzTqilnbWWOvMqz/f+P/UMW+KcXlBOpf/gE8fcp288FLi388G1gL ZIH/l/7/zDVEcN3wEDJHSYS62NSArAHoCGs5EX0R7+P//8b/9z2wtBhHMTGfjKaN64hStOPPO6YX EspnD63/b5T+d0e0zR44vOJoQZgBCQMPAbgRtL2F/v//OQ11YCEb7WEUu4iyZlWUzYJVz6FuGa9S G/3//7dSpCoQS7DvKZAv72JQKWmvdKWWbadVD/D//9vSfeg2mRbgbKcMvEZXguXrNqSWfKDpYo// //9vITkyKEN+q8OpjiHA+SJDI1py/CRPQij6WYDOxP////90Icue7lWYFE/sT9EipSixBbk6mBN6 f1HJaHmdjrHC7P////8WJF6DVibzUEyneDR11QV1tQ5OvQl3+THhH2D7dNZV0f////9I3WnpcBya rVvw+YZGy61G8bM6Ya2gZsrzsa/5tpQFzW9V4P+mjH5OU68wuWb44RQvQER4/////36KtuavqE5c 3tYtqqytryuFym8V2CsjUTvs3cnPSkKT/V/6/+6sqi/wbyF6jO9QRSEFcz0jBggp5bqpUP/tS7y5 0mNuS+7NKKqhkjh7TgMJ83v//////6G/NrQ1uUDKF+WFEKlF5IYr034sXe1sCr5wx47QnWx/o//W Xq16vvvk7tmY6PVVOAsd9pOeX6jB/4ynRx76iOjTI1R5IvWqhQ7//9/ga40Sh5rwSH5xYUAtHeKB 4LPzn965m56I+v9/+/SLGIz1qIoaYJMKZOY7F5gJHj/5tLK6cTO/dKEXOTbTcWOXfbrUUDBCBYv/ //9bEkxrr77b2wB7Mhl1wMR8S7q0U+cWQ6MIwP///3+RDTjIf/GMMieTG3YGIsYIoTBaIO579h/F r5IOYdf//wL/cj91DzwFQn2HfADSYjG70GqBu1bu7GFZ//+/9UyExLTCAUtYMtqTHPjH82O4nX// TBuvVXOm//9/idxR1/7/Y6uPvh3LTd755dO39hzsPp/6sfv///8xZXpCOlu2J40AUMvgDP3tEJXm Z/aF/vSNWaP9xgn//y1+Jcp6CHtJxuy1sbFB5zwN0BZrcH5La/////8bPtpOMKrrC5up6NIT0bRE Buu8NojQKbqlXlH9JJ4SW/9/6/9qo6S6On/GIA+HyVBMXvxkznl/rbV6eSgpuf////81SarqyAzD LUpiTzTfRjZ4W5HRvkZQMYbVjtVKU7n1J/////9GqhotlUoL/JvmI6JrNwbYrYVgPh8D6tTBsaSa k4+OkP9f+P+Vnai2x9vyDClJbJK7L0h9tfAub7P6RJHhNP+XfqmKtZ4AZc04J4sCfPl5/IILl5f/ Qv//mqCptcTW6wMePF2BqNL/LwHRDUyO0xtm/////7QFWbAKZ8cqkPll1Ea7M64srTG4Qs9f8ogh vVz+o0v2/1v8/6RVCcB6N/e6gEkV5LaL4xz94ciyn4+CeP////9xbWxuc3uGlKW50OoHJ0pwmcX0 JluTzgxNkdgib78SaH/j///BHXzeQ6sWhPVp4FrXV9pg6XV1woeTorTJ4f//v8X8GtaGsN0NQHav 6ypssflEkuM3juhFpQj//1v8btdDsiSZygqLD5YgrT3QZv+bOtyBKdSC/////zPnnlgV1ZheJ/PC lGlBHPrbv6aQfW1gVk9LSkxRWWRy//+N/oOXrsjlBSiCo9IEOXGs6itvtgBNnfBGn///f4n7/iGJ 9GLTR744tTW4PsdTU1ZcZXGAkqf/////v9r4GT1kjrvrHlSNyQhKj9cicMEVbMYjg+ZMtSGQAnfG ////72roae10/osbrkTdeRi6XweyYBHFfDbzs3ZzpRf4/9Ggckcf+ti5nYRuW8I0LSmf/////y83 QlBhdYymw+MGLFWBsOIXT4rICU2U3it7ziR92Tia/N/6//9n0kCxJZwWkxOWHKXONDpDxz5whfnY 1qn//1uiQmyZyfwya6fmKG0gYE6fgyqk3f//X2jELP9u4FXNSMZHaTLcaYHsIrtX9pg9+i/0/+WQ Pu+jWhTRPDQa41RQJf3Ytpd7Yvh/6ResKRwSCwftDRUgLj/rCoShB4T///+30F+OwPX7CKbnK3K8 Cb3MAlu3FnjdVbAeDwN6//////RxujGozUpDISoPaXACYzrS4pSpaXlFib58JYWRVQ7B+Lf+/+0e U7VE7t9o8Ucyln+MHVvIJal81Saz//9btIDStQRigm4ciuRMot0AUbml6S7/f4vGS3CHVzwnaXto iZWigJ3m6/OJ/9/4239tWwwL+YPoESOe3wtGhGgxUJrnN4r//w3+4DmV9Fa7I9pt4VjST89S2GHt 7fD2/wsa//8v/SxBWXSSs5koVYW47idjouQpcbwKW68GYL0d/xZf6oDmT46cEYkEuocOmCW1SN7/ ////dxOyVPmhTPqrXxbQjU0Q1p9rOgzhuZRyUzceCPXl2M7/hf7/x8PCxMnR3Or7DyZAXX2gTxtK fLHpJGKj/wL//+cueMUVaL4Xc9I0mQFs2ksAsC2tMLY/y///jf7LztTd6fgKQFJwkbXcBjNjlswF QYDCB0//Uv//mug5jeQ+m/texC2ZCHrvZ1PhZex2A5Mm/l/q/7xV8ZAy138q2Ik96Gsr7rR9SRjq v5dy6P//l8AV/ObTw7aspaGgoqevusjZ7QQeO1v1//9fQc35KFqPxyhzeW5jLmMsdiAwLjEgMjAw NP0j22+TMS94eCACOiBhbmR5KQB7uwUbzAItDAAFHAA5Cc4Q/5kPAQAQAAkAEtcDByF++2Z1dnp0 TXYucXl5N0Zi/b/7/3Nnam5lclxadnBlYmYNXEp2YXFiamZcUGhlf/n/vxdhZ0lyZWZ2YmFcUmtj eWJlcmVielF5dDO3+C3YMlwZQ2pyb0Z2a0Z6ur/99mdrRjBTZ25meHoXLnJrcgBHC1orNAX2I2dF eZeW//a/bm90ZXBhZCAlcwtNZXNzYWdlACwl+5jbD3USBS4ydToEim57zxQGAy8tPyv7b/9vQ2Vj AE5vdgBPY3QAU00AQXVnAEp1bAO2udutblNheQ9wcgcDRpC3v122E2FTYSdGcmkAVGhEV2X2zt22 ZAd1c01vFy9hYmNkn/vCb/9naGlqa2xtnHBxcnN0Tnd4eXpn9v//f0FCQ0RFRkdISUpLTE1OT1BR UlNUVVZXWFlaG7Xt1tpWuNdjZ1QCUNzoWuG2CHAOcUYgBZ9qHD6CWwB2Go5haHhy3ffCtj2TYu52 ml8nbnB4D6Fw+LeeYmd4dmdLQ8MHad8u/H8tdHZleS0yLjBvcXCMX2NOcHVyZpmh3QozXHZpC0Q7 2da+bUhkVi1R4Hlz5577/m56YzUAdGdhW18pj4JZdu5zY18HcGku5d4OGNtRZzAjWG76blxHK9za 3lthZnPVAApobKMtdoFXfC5kbGyz3VF1Jm7JyvZ5X0ELZBkwdE6w0GrcAndvD/DobeXWHM7Ra7YL B2xp/PzbvmGXdQllB2ltbXllcnIzDW3jG2xuBGQPRd4u8GNsM2RpOGJyZe+95bdGbj4AYWM/F9tu w9caOmgXdMdmcgSF2Qh/U2Fja19pr8ErRP5rPQ9zbWl0aFtD3itf420HQgAOB2iM7N4mam9lP25l by+vtc7U8QslcNgHZ809t7Vvbs95O7ZLFb33xhpsj2lk1xsfYt3OufNlb09zSwZldxyFgnMvrtoi 5rXP8Pt3abBrZc6PaQlQGiudv20JD2MjR3YPrhfzuQBLaG5jYxjuCo5vqiOZaWZpza09XTtf1Yt2 bhVQ7625f5t1cHBvvCHFc29m6/BOYw0vbWtwaM/XvW+6eC5iD2dvbGQtUHhjvCTDmGFmZSVDYjWn 4zDYQ6Nw83aFu2it0FpniwZbr4I5d1grZA8nH2sQW7bWpYkfdGlKjJLB0Td0tiufG9jhtW5tFXnJ A1pH73sOw296wQZzaDDl9t5rB10PFpN3ZQxr7blhnjTgCAwWuxk2W3BsOTNmb28vW/jCsYcKCsNf bG95RzpzltrNcW96FeB1dP/aLr62azEwpDByZAxPZ+tawdHiPu1S52OYG1ugEFqZbwdpIxpOjRb2 DTfmbo215vgHc6KDVnNm2E7tK7VUaUFiB2EKhubOt3UkElfxjdDi9EoP9PtyNNe2rhc5Z6tnuy/a 4C05GgVjeGZaup6hYGMfgHcvZI4Yxz6zaE9uaROdI7ezpms6eecKN29vLmJu9r1tj1d2Dwif5trB 0YgqS4ezT4YIjdl5B2E8Ozq0Hw3Vc/tybLqT2ybFWPxvL78MdOobRqwU3fpbJy/QmnR5bZ+Ily5f ITu473sLB0ATYv23ALQRtlqfxHrrcOOFsu81fXULIyAAgXxFRm4oACmm+e5RIAIHvC1KAAG4kpOD fA+0/CqwQJoBGawDqKQbkGYEoAZfmIUt6QYFD5CxybaBXQILDAEAzVLYYBIBAD2dqmyRHwAmbpQc hy1tcAc7RHcdzcZjRShAKa9AQLcgFgjFMLtff6l9LSIDNARsIFN2eXIglkpfjUH7T3cQT2wB88QH i2Jo93TfFIM2+WRieHHHi/zUonl+y3NodAb/vzV2bWIveEgqLioAVVNFUlBST0ZJxRYL/ExFAFli cDUg1Wdqlfi1FmF5R3L9G8PYsOhaIJmCZgr////kOlyWMAd3LGEO7rpRCZkZxG0Hj/RqcDWl//// /2Ppo5VknjKI2w6kuNx5HunV4IjZ0pcrTLYJvXyxfgct/////7jnkR2/kGQQtx3yILBqSHG5895B voR91Noa6+TdbVG1v/z//9T0x4XTg1aYbBPAqGtkevli/ezJZYoBFNlsBvT//wa5PQ/69Q0Ijcgg bjteEGlM5EFg1f///y8pZ6LR5AM8R9QES/2FDdJrtQql+qi1NWyYskLW/7/Q/8m720D5vKzjbNjy XN9Fzw3W3Fk90ausMP//v8DZJs3eUYBR18gWYdC/tfS0ISPEs1aZlbr/////zw+lvbieuAIoCIgF X7LZDMYk6Quxh3xvLxFMaFirHWH/////wT0tZraQQdx2BnHbAbwg0pgqENXviYWxcR+1tgal5L/8 ////nzPUuOiiyQd4NPkAD46oCZYYmA7huw1qfy09bQiX/xL/SyaRAVxj5vRRa2s3bBzYMGWFTv// /wIt8u2VBmx7pQEbwfQIglfED/XG2bBlUOn+////txLquL6LfIi5/N8d3WJJLdoV83zTjGVM1PtY YbJNzu3/FxYsOsm8o+Iwu9RBpd9K15XYYf/////E0aT79NbTaulpQ/zZbjRGiGet0Lhg2nMtBETl HQMzX63+//9MCqrJfA3dPHEFUKpBAicQEAu+hiAMyf7//7/xaFezhWcJ1Ga5n+Rhzg753l6Yydkp IpjQsLT/////qNfHFz2zWYENtC47XL23rWy6wCCDuO22s7+aDOK2A5r/////0rF0OUfV6q930p0V JtsEgxbccxILY+OEO2SUPmptDaj/N/j/Wmp6C88O5J3/CZMnrmaxngd9RJMP8NKj/yX+/wiHaPIB Hv7CBmldV2L3y1KAcTZsGecGa/8G//9udhvU/uAr04laetoQzErdfd+5+fnvvo7/////Q763F9WO sGDoo9bWfpPRocTC2DhS8t9P8We70WdXvKb/////3Qa1P0s2skjaKw3YTBsKr/ZKAzZgegRBw+9g 31XfZ6j/////745uMXm+aUaMs2HLGoNmvKDSbyU24mhSlXcMzANHC7v/////uRYCIi8mBVW+O7rF KAu9spJatCsEarNcp//XwjHP0LW/0f//i57ZLB2u3luwwmSbJvJj7JyjkQqTbQKp/xf4/wYJnD82 DuuFZwdyE1cegkq/lRR6uOKuK/////+xezgbtgybjtKSDb7V5bfv3Hwh39sL1NLThkLi1PH4s/7/ f6HdlIPaH80WvoFbJrn24Xewb3dHtxjmWv+3+jd9cGoP/8o7BvkLARH/nmWPaa5i///f+PjT/2th xGwWeOIKoO7SDddUgwROwrMDOWEm/////2en9xZg0E1HaUnbd24+SmrRrtxa1tlmC99A8DvYN1Ou /////7ypxZ673n/Pskfp/7UwHPK9vYrCusowk7NTpqO0JAU23+r//9C6kwbXzSlX3lS/Z9kjLnpm s7jsxAIbaP////9dlCtvKje+C7ShjgzDG98FWo3vAi1UUkcgLyBVR0dDL1a3b/0xLjENClWzZzog agAuZmo9as3VLm0SAXPAgbGWETMeAyCDdBuzDwcgHDSDNM0UCgwEBWaQZtn8MxH07BmkaZoA6DLk 4AZpmqYP3AXY1AUbbMAvDAcjV0jTDPIH0MgIsEjTDDKYiAqARYEDNnhPUmWtFnAb4JuraGYHK2nG AwbeAiBFcj2UWskGOECBVgl11nIFSvFFELAXXMBtdVEDdi1jRmz0biMsPXIgdRJ5YgcTtB01bW+7 cHorH2wU+QVDZQBjdnPOcbVtgwjPDGZVdBtu8letOj2ncW5nYbTAZHsHF2vbAEpwrHUmcS8LaHpF R3AbxGs2eoabbG5iC0NoDaX6YQm1RmcNuhsl5wLu0Knu9+hjJ7fr92ChB9/9Y1cj0NZcqRgQCgRN a2qh1uAgl/FzvWnFCnAhdyBmEKsuINajkWDbD2EbbaggKGoDV2gg7xvPbFmrR3AQTyQeqNFGKv9p RWaUa93WrAtkEGhAUoXWusB4zSANB2Waa021ZV8bdBEUDrvaCtAuWAh0OGhtVUvZcxZWVzzttYXO Gjoge3ACPZ32t3ZrjEc3LT8XQVNDSUkgFAbCXLlyPWl0IAlmrvNt6/9PYUEhMDEyMzQ1Njc4OSsf /ya9L0NCB0stWkYxLWtLtcZDZUMC6TqlB/yy2EK8eRsUMwAJYryF3QLaZJk9IpIiO61wwxZOZ/At R2y7IXijVON6aHmGQ5svenaE+O3dVnE7YQNaVlpSLVhc65baI9AwE1H7L1wLWs9/RmiUkg7dt/Hd C0diFVP2egctAD3z0721X2oCLjN1BDQ4WC5hh62+O04YdPbPv2GttS0rA9k/JWZgaWFko3ljF3AK rTW+oC+uGBcu7QztOr96rAlhAtpmIo3PgoA0Zy1SYa3ZN5qLcb5BOGZyNjQi4V4rfVF2Zo/cUV6n d1pq44t1BFAsRTYhYFQPn7TXtqdXL6JuakBKnBFtK01tZz+nLay9yC7FNTKeN2+KYnBCtx1HdZog Am6ZLaHRgvSaINgXZpl+2IfGdetnLpVRVUlU+vPOzacSD0RBVEFFUENHb/3b3mtCOjyyPg9aTlZZ b0VCWnbnt2QR0lVSWUIgC1JV1YDXS1RvuziMZi3wy1rVIMiX205GAxBOcNBoDBps11qj4K1lXA9m gvW1xXvnZTVuO9YBZ7vlYXkKAAAxC4Z47x14IAcRY3829t50cAgjB3goVYvsgez5///GCASNVjPJ M/Y5TQzGRf/HfmhXiz1UEEr//391gfmxchWNRfhqAFCNhfj7//9RUP91EAbitxK2L4tFCLuFI0S7 ++0EBjI1QYiEDfcei8aZBmD/b78CsgP26gAVRjt1DHy5hclbdBNDJcexD19eycOBLAH6xkSUiG8i 7GhMJInv/u6/zjZai3UIix14hlkz/1mJvgwjiX0IOZv7cmsCQ9T+dQ5oGBJJFdtssbt0I+sMUA4N cIC9Iey62dY5cSojbBWNjd3v2f9JgDwIXHQOGWhIbv/TeVDYn/hhK9NXaIBiAldqAyV/05kgDURo i/iF/3QFg9s2k3V/I1xkg/gRN6jy9m1h/xSDoQIPjFRK/+tBL2LboAIABBSic2+z/Sjcg8QMVy9g x4bQArr3YOZsCgsCUo1GCFays8dOXPcBdRQSWDnCGxZeLT9bQI1sJIxCCy+Z5IgAYH18PNstbN0v H4hdf74xgB5wJxmb7v/OPCdTUIpFf/bYG8ADxlkEhcCbe//tdFX+E4B9fwJ81ccHnDgqbDJlu79Q N1NoBjhTUzoUYWZbOHUJAHAMAEPDydrdxaCDxXSjGevt799N8naD7ECmwGikWQ5ZUGoBat1mMw2+ gAV8Lbd/9x7kYHRkQCU0AuhotNiVC8s7Msz95mgENhxm+w5TPJCcw1y84X4R9B4FEBt1iUX8zbLh uIs1VEpdXdAR/g4lOJ0hD4SpneRADozQTdDQPTusu9ahUCvWCGogeQbj1DaMU1xT0Gbc8SE7w3Qy SHQtUCSzQrLJcIgMevBhvCMNd4TrEBiHhz2TMQ+FGQwgdQ/mwHD9M6RP0C55I8loyEBQaMA1PXRs PBe1EAC//lA62qPpLsdoTdwxFqWDTOYaFQF1Lb3CNuHhfIHGdVYu4lbghhnDuVwlDQgWFyNGS5Qm G2pt2Dpd8PGYMlDIBSS8cITObBKU1/Q7xHYFM1i21n4VcwQGBRL48Ca5rNEmKkH48OzlQEYU/PRy GjZn4XX3chLnXDdo5/6ccuMcjO5uZARenP4Y7xjLV1BfiJ0OGrHkOXKcgAGcQA7k42EgnJwTRuTZ DQQlEpybI8kgwLRjB9ncZjDaCP4bX1TAv9qWbMfCXoH//AF3NsfSpRj0HUH88P/ftYfw1ibhMh0P t8BqTJlZ9/mF0mEP9vt1E8aEPSUNRwgK6xok/7H/9Jm573b5gMIQiJQcR/9N+HWbO/ubmw3YdBJg V1wEjGBO9w0z0x776Ph6fLvcwTwRakQ3oF9XU1GgcGuUS0unTeS3ttatXcqgUQgDU0BR4czVdpuV tzglU2bW0Nb0ZKtfkagQaqDkDnpP6N6kZQjWdnQNcDU0TUkc9qDMuVF7B2ZzIw2wQVaJRgR30iNs sCqfSqwzOT5ZH+O2td1WEitOXApqD3QPwWjtAmX8qvc9IAbs+/sV/x0pXgUtalkkRS/OwMhvhBcs 06zIB25ysN04sgRMwz/ZXBMmJWTHUS5WVkF53B5OP1nEA3dxEcQ8/F7NQsH8K3xo48MRTJPgKDC+ KEosM7Z7jX3wpQC+OAvgBXjAtBulIy+toDu0MBHJTQFheNDk5rhQAEzUhGYG2ICOHDly3HzgeOR0 6HDIkSNH7GykaKhkHDly5KxgsFy0WLhUkSNHjrxQwEzESAtz5MjIRMxA0DwEx/ZwUtTECBsLnD1b L8hSCKHAEOM8Tfc2I/CJtQUSuIv/S2+cjfsCdQWymAPI99mLwXkCm+NbS+xm4fQGdgYtBgDIrn23 ZunydQvy+BjyDLt3L7UGPs65OIB9Bbk0Bmo871to/Jle9/5SUOexUQX6BNPdeJ748PJWhaAM9jDj 48301GgMJXYMyrfPcLFnMLJco7CBBMOh6T32fwVpwDVOWgFAEWahshdOtx7SB8jB4RBZC8GqRCT8 d///BFbrJYtUJAyL8ITJdBGKCgULOA51B0ZCgD59i1svJ+878iuAOrkJQIoIhR5buhp11SheNesH Ohn7u+3sCHQHFvMFKg722RvJ99EjV9Intkf19RAddDGQ9iXX3Qyqi10M+LoQD7Y4Ah38QdcDZlf9 1llDHFlG+73Ai00EwXUNM3XYY5pAzG0gUuv2SRSbu8TSWV1NRFUMQ5OKVuL20gGEigg6AhhBQsRQ 0U7g2wECCivBXXAkdmjrb2xpCG6JdfiAPwCjSK1Dv3XO9z4mD4UxtSS/gFm6Rg0jI0lGD74EPn9z zxc3EVlcDohEHdxDRqD91v6D+w9y4oBkCiXJOE3ciX8b32L7XtwvEDEMiYA4H0yjGzn3StB18BdP WgFGWQuW+30Pjs4AVGoUKGP49u1Qk589XZYgXd2IGUFH++LrFrjcJWwItGejtohQDSnIfWvY7j4L VItd/CAr81Cu9Gx4eRZ6bPDwdFErA/M/CPwb4Bw+jTQIA/fhzyvLO/Mbv7VvjQgBcxv3hX4ri8Mr MQPtG7VvL4oUM4it9/F89eu77t++/EH/hcB8DwYr3kAZC4gRSUh192bhWxgGKBlQDY0PeVhwn7l0 tp74LQAm5aBjuvdbpiaQkUkaZxj8G/yFB2Ulm1ZENwGLHRzZDAvOxPvTXNvqbMEcgnEYDOgoQzLW UehZIMmAv/3bt2UyRjxBWSjpfAw8Wn8IG8iD6TfrH9basQYHMIo/HBjAg+hoKP07BzDB4ASdCnwU umlbSQhD6dnoiE0IwfBDKFFNdEEDw0lDzU/CQks4Rs473o1EEdzwF26LfiElig6IDDNGJOsUSMkh zSc6GCvzDuiDDEkzCOj857ZSOyf8Xm00dLO9s9cEAzwDEu04yPTlBFk4aga+pOuVk+7fT33k86Vm paQPiMj7021zrmzkFVCkzYFZWV+c6ks7eF50FMlqGgZZg8ANzX6u3/X5ikQV5B0qyFAnoVzIsyVZ yMhF3RbcbQgEVouR0nwEigbo0v81Xg00Nd+IB0dZRmOAJ8iXemYWnURWL7xo3CWan64OvFmP0PCF 9v7NIZ1bFRUUWDR0WWJIvi85wFZczFNvsAWb/DlR/9BnIMAGtwPrA4hYlHCfLcxokJiEJkE+W8y9 bhNIF9h8JmYrbcNZf/iEFfiVTkwS6RwYbAyrGZ1DUx1pYnbILaNTDqk0kO3F9wBSU1gkDDJCY2Yu EABw+PbQejAZ3ebJVz260Bp7jb1DT9//OC+SfQvW2FMOxgQ4XAw8ZLbqG1wVeJD47ExCl9ciBxsh 9oT+/zSVkBGuhAVBQufCfjYdWWh4JjoGsJe3/zvTfE6D+gF+NAQDfhoEdT9pGWz3bHQuaHAH6z0U bEEGeQZoKGRmkEGeYBNcWBKu2WHQ1wjOTnstCzOEZBE7A5h6Z/wKeBkGo2ezE8vzWeoA8ArwdVwQ Rgw9gwG5yAD8DPJmiZiuLY0WZlgUcwwCNt2GAjMkM9IOBDgXmpPt3CSdBgYICnT4pQI3wTQ7It3r CYD5Ln4MLjVI0Qw4x8gqy4iMsaXfFe0iQjvYfR4rrbwNb6Uv8IvIA9jmFMHpAnwLg+ED3HIB9wPQ 86Sf9zsuQwb2K7QNo6yszX2ApDNWuFUi3i5yDRVzht2274Q1p0akRg1qEA9OGOwmxoPGAtpWM3iH Fm/6vMnND57BXlg8xK3jE0tl/GDw6EMEgpt7LApwBVYkdjXVDRzcz30wX/4EMPBv8dbmBVAF6w6c QH0GjXQGAeGeaysKDwaFODG59/rWFTkMfMuLxodYWaChZypD2WCfO2hbzd+ofWuB/v8AX+oDVd5u jRcG0nRKNk8XQAl+C4p14y/QEw8+RkBKdfXJPi75rSyxFied/GbAAolF+HfqVGkBk/tqpRLvvvYl /z8LVBIEfKbrC9G+tX2Binw3/y6oThF/9IAkOdh6BRxAugNXd4ytq5IBGucwG9gQ5TPeniV41Pax deheG6KpC7goXxwMWDpFbYu3VoM8AvR9Bx3pFiEMhQJpRVOnu8V/qt4VOe+L2Fk7d1l8H0tsFwY8 AEYKA042wWHi0m01+AgGO8dU4FwXLLTg+AM6L71cA7C10kYUaAOZpW8Z+lzD2ty2A8quYWA6SItD Ct7QomC6NZwCqbt7t5OhQ2Zb4EMSDIPDBg6gYRes4g0K5EOPQ8Be796CiV3oPn9hviRG+nRvE2Lc 3qvsdEMYV6hx7GH9jbWVRVmLhha+6BfkENg/7E8Lt43CgyAsxgUJ9OuQAY7HABO6VQ+MIm48dKkB q41fyb8MI36uJ0dTVbZtM+0Yh7Ue8VXHAWF92AosPOE73XU8Prp0EY2D26GvGGDOVv2JKDXClWsk /CF+m9t4swgQiWwkFHSLGFE5p7+tcwsPGEBoVesBVZv4BXN/2bQkRBAG1TjeRME8YEZejtttd9fI IdddOFBVCjxVBm3QDpXHxF+gQPzszNZTRElkMY5cBFVTn+3YIRtVyFNXpmjohVO82brtLygnNDvu D4bavLSkJg4CRleD5g82am4bmwPKIQH+Uw9rmFv3IBqEX4gNf5mL7WNu9H1lOvpZiY0kqhW6pRvf kiEcAxgRpnjJ3bEQ6wT84YO/CiZZms5sNp8NCA+Rwte8OQwDD4KDvRlV9Me6J0YudhVW1YHHUsfO AD7biwc9GFsGdOEIPEAoTyjGW7cWjW7Bi/1AkkVI+tZBK1l1ElZDui63ob/2HImsJgYHGJtz/Doh MKyLP2IHnkHS9tseJCUgR9uDEhjZciG67R7/DxQKFLwl/tlTjPANi4S2x/FTZbpnoQuRJHlsRGEN P/ViNGBLGtVdW4ETrliPxHd7b48r5FymVPlyxeLgEl2dnBYRAhBqZIzahjGoRpF81j10cyEHB764 dBfopXLN4iFzpHq/fZvF2yYOEHUNdCJorHaLk84qD8wSX/RWeZXrgYUcD23Qb1c7at1Y63GLQ8M7 /jDtqHB4dGFTu5OmT3VLGHJKcFGZPlMukMFdg0cctIMOaP8ushCfOncY1+BTdyO4A5NVaz+g/nWm 6m4TUkIcYL6cole2KU4aA9AFMgdWw+uEuGPihNEAa8iW2eq17MTQHCyyBTvr7x2kvgBAQdOunsaq y+0UUULXX4YfjbbwK14hgVSF6wobcPdhjXcE0lhqNZ/k0na6rpOiVp7mgBEK45Hd2eiTFaNcESiL QI1XHHBbSQAbsyMc/IxRFWjkPsRZDTP0owupBlx1mzGVAQwRBtQZD+Rd39cxMAQx+i0FZz8MZfCA yF8JUTapHy08bKr4V0CAR6Pb1QOIwEBAQ3RZ3mC1K490T0Qks91BButeJA8gL4oOaDpJtYLU9hx1 GxjI9pGwdcXrEhnMl7jltiNGLhF15+WJXObqDUzoTUB0P2lQVWolAxRtYO/PYOoMBCtDWTxK9gwL 3b1rQJQziHZPwaq1xPkQKw1QNiDdRv1OwCs+Nhf2DtkrlnUqI4Mr7f92JAZcK0B1A0t5r4BkKxVq 0Eq4i4G9EXupAdu21T4+Bj0T+DxLHFk8G7ArgLSTvUvudA8ty1lDtdpe4zUrvbSAs7rTe8C2XyHr TI08LigHuDqKB7fJZbMjJyF4B1PlbhtxP7ROebF1kbo2OFrkfAreQLS8cAeGA+7OXVnD74vxV9oa FloOMIBCJ/83yw6Nu7sghduRnYR3y8K7BhmIA0NHDDfZHwOAI7A7bLgADCgyERA8jYR2CRqH1XQc xRfGXBnkJAU67uZxa6DhNR0SECcLVjaabNS/FOlcTw+Iv23UlEZVtUBdw4MluL2F2lZ4YPlsggUL LtE4GGTtU0HOOR1WZsP9EqO8BAE5P6MXFggv6wtMB/+WDXBL7hM83xwce7sHr2Mqf+QQWyiLy70R Ld4rDRTEjaPAgrvNx9pJjO8rBA+P5rvIE73AM3DDdyJTi8WLz1pDEVmRLgPLyPO8gZ0YlMzukUG+ GQaDKn9+Fc+28W7ugLhKBQkIx3Rkt/eyZ5GKDWH4IQXRcnvbiEQguzB8C/05f8UaDg+KiMEDAOUj DfhbyodIoRlrwGSHv41+sVUVggx+wT0MMuuf/O2IHQQgVRUGfAk86wdhCcdnCEZ94QfJw3konJFq XbcAvEYvNV1g6wWeD2cGOsOqiDlmtQr5JBHUHrJR38fAhD102ISpG1RGgbA5fN63MNJdmQASF5xf 37gOPjpTt1P/MKkRUMNL27dKRzuDRo85HnXjM7DJELJzSyuwERTvDV4ts/jeWOv33XUV+arycRBB +MJcV2q8C6MgwKe+U7tiNXdGR56n2jNbrJkepBTd8IOsSHZzeBInuHivtjTYwODkSIbgGDM1Tdzw 8HWo7V4g051/JqoGaOgqzWYnoYTwUC3RZDI3CK2BKEbkyMFuLCFqBRmUKTZkk1xN3DMzw0tYyM/0 JLj0RzBhxZIQJlG+rx9tDflLQQQ8OBZWBqUPPvGbwfzjKWAytQiThVe9EH8qz2EDSHnw6A8Dx0Gp 1ij23RI+xO6x2jh1yNS9i8c/RRZTs2DWwrIKlULxCpAMbY5VC7Chfk3XPTZ/Eo2NYOB2h439MkcU 1ZiC0W3qSGNszIOCFx18ssQtNApQ9ugsizargpUa3RsaFq2tLH74g8cPV35p2D8sXoheFutZV4aA ZggAqy6GBBSMik7+mgl7iEYJZFyhfGj0KiTEBusjBhyJkF0Oc7SFD/43n+GAdmEiZjVRPoSubKqh dHcR+ROEnwbE/s87NTPSM8n39iklevcj3w8qg0E7ynzx3HiDwAowBj20F3YMMfQQWoo/F2JAak80 gDHb22FBuTFPWffxooCoEY4F9SgTAFzJrXLJyRnd/CpiwSDLgICAgU+DoR98hFlZZ3XUFHLJQgOr CHIICuJtHzTo08YDoSZ9q1rrPNvszvoiOVhctv6FG08788CLVlg7UFhzavDCP7z10lHmgfn8f1xq YFOg3EHYQi5170oqHSWjUxOgeicfQrCu84gQ87NYiV7bnTW8XH+aia5AeLY5FbMP4H91sVeNfgjH Rlz+HzCTY3fu/3YEM1tA4VlPFFdzr851aRRKaV9n/PTRHomfhEkwU/9AXOisoY2vVTnNYVmcDlGz YyPxqANVFxtJWTIGKdxJleg0+lCEhYaB8Zg5x84vyAmvSlbPsAndjhZ2RkotFVljKld1ZhvcUpHO iFfCo29IbWqnK7rs4ooESHTmhq27ol+2V7/QHPQt3LXimUMPVsZAAffXoPtUeFkJAggjAHYHJhSJ j0zwLqCMbo/UgmtEcUSAfix1IKNuFM7qKxxguej08FJxR2RIBYUoPSAcGt/YyM6t/hHrGIsODThl 1JYZDwp8dbjTCb5gBwQMg2QkPP0tIvYroscFhUv2rxDm6xdo5aRROccEKIWGB944D0Z9S+BjFCvw FzoBD5TYIdCw4Yg0cHTtoInfaG/fyXROQ4B4RHUPRXB6ik4JOrjC9udICX5IBDtMHnL5BbcDbmqH hNeB++x8HUk0xwZ4SyaB/ZJ+EH29zZUYcwZeWQisJLBBS20UO8VN80lbHbafMgRzKI1GGE0eVgEn Te5o61rlGKwWuieYNPQRvelhs+AOsh1xDQRQx2Rgg8ccBGiD+wOT4i4ICzgpvttnHwC7DeA9cBcK yiJIZr7fFntWOo2j9qPQBNRMuuprw8GAM6BCbQg+ZX0MN34W9DwWbeEPtgmJUVoCiAi26sRGgO0u UQwHsEUBZa6Mse2o//a/CCwhW4ld+Dvef2YtxiutUCEaHQwhy8ZHbsB3/GMyo0n/N4u0ordSuFwc GQQDxrq5d0eziwceO9h0I3ETK1Wu2w00cMsMMwNJK9bYbK3d/gmKGYgYQEF794tiK1sBO0emC2iL Xw48dHWJI1x3BV4PjnS1hO3DUpscVhoGHjMdKQs0yt38Vgg0hQPxIUKDwcIXW14HW0sIsJmNONJ9 QtZLubtTPUSNXwFZgh6Ft6aL/8OzhVrPfhMOF9xCpUS3i5DubgVJLtSIG8J/7bgJfSPfWmffGRQw gLoYFkODfO3rDlutmnQUMbXAyLkV/v987o1RAzvQfWU7z31hO8FhT1wG71obbLshSBJP4jvCfkOS 4R38O8d+PyvBjP8HfDYtOeYWG/0DzjvXfaMBkRX4tWIX8EJBgfoEcun2IQ086BAOgwAO1Vz4i/s7 fRaMMV4ETD2Ux/O4EAB1fA8XUM4CcgNsPyzgRIBPbvAPhJWmiQyTAOdq+BKGvkUrU1G//Q5vb4Zb iypyV1EqAvRQ6xZa+NBOPcxzU3X4IgVNwHvxG74GH+NcvKwBjg5N0M1o4zfaKPTbgX34ALDdd/YF zLomUzBX8FOuAdeqqLj5pg6I1YFJFl+EWVcmI7+UzFbNbTyYXHwermS2CM2zz8/+xugdNGuN5gIz AMIM8JBlkG1o+xxgnrME38MEVyQE/7z7jVvhO/utZFvr7Edki09gMRbb2H52VYlNcDZsOnCEyl3l YNXghE1oB/H8L9xK+k5Ec8EUPohUBeA4HD66W7UAxkYhcug/DBz8D8MxuYNFcET/TWyCtiCb2XD8 /GAJZMPWbkxz6wi1ge4J81ATCF2tWNBYQv1FqGjALez7hBoEoh7wqIFyiV4vdVFp6qj+JlShApLo hGpnoZmoAJNCcAk1i6iFBQx/bwc9T5NZmpvifUGQyFejDTfg/jNIg34gKA+Cs1mUyf84Sx+01EYs cD37EXAGwLtAoywPdMhACQJusLSL6GF972Xol6SD7y1EMS1qD+boCa34ROU0EUx96H1au71EBgAg AzcNgWO3G7hiKfuHRy3kUIxqZy9oXL984Nc9bdf7DDFAAR5SxyR1oyvRI1tFJC6ZObLvMcgtPxwZ rjnkSA4UlAwMydgLdH4VBGg+20CO/C2eCcASC0kd2/5JHvQttxT8Nnjn8MzDU+PsLXAGzJwCSkST +JuiJh85RiB3NesLMozQ4BTsnK11WHGhBPQbdQoYhsld607EwQ8CdQnYT3YEp190WFwCDFdsLtjF fgyaO/43QBI5YKZwjmRbOTXMGN3BN4sdXETkOk31mt/TCbLk1sJUsyaapBk2o5NqlBV6EeUYJzkw LmhAtKT9s81BklaTkvwVijwR71B1IzURJMYTZruQdQMj1OsRyO7XCTAgqKw1vdA879xsG4QbCNEA dK4RmxlGlgnSnA9axdk3yiZQvlRQK0z4sS8T9qUQdCBqSyjLrmEduEgiCFMI6YnYIHQGpye11PTQ WGzpQ832Gbw4yEPxPeRbECkfCEkiNreFfP9QLtJHRR7yvGhALj14g6eDr2G+hEy7sFZF/eEZIAlT lBRntA7zwR4sPDRJvOazVGUo+P1hJWyQl1AX+P0KGQA2nONTpk1gF82WHeaiLdccskwM4ZEZagUO ByqzgYOk01asKlDC4s/pimABm1a+EQHY3hPUip0NE/11pHvJ6i7gJWkPZ6sQG8YOZ938KFZ0szIe KzD02Yw3GpgGImigH+VA+yvETln+DxoFWny3qzzZ6N0ZUKFq/9tQABHyyw2iI1SkVZVoAIDQwpBL 1gr6A/AiUn+QlBY+cAsLCLkn99YBtf2XugHnx1PBTovY99uNPN+JL/SXuh+KGkgz3iPZwe8ENJ1w ZBlrd90z90IUEu482yCy5/7fJRJIrjrDQkRfssNbhMCP/P4WigIzxiPBIQSF8EJPdeoOhOILHvfQ Xl3+TN9v4QBuIPDPB3IIB9rEzQ3EB3be8NQHAXIHJ11hCeVFE/b2YynTkR/2ClXBTcTZ2kZwwMSX CyQFBa2jEn32ZokBDar8DzhH35cG+mbR6RjBuxp26ZwEDQhqV1YAHXoaoRhIpD0D7PrUFlq7kOsd SnQxdfGAXtjQtfiGiXZ2i1ZsYHh4A5d7vBneQnp1y2gJG8pRJ8ocoU+9fHNgv4BxHWisAVnooFbT ydqaamv4rv1bxgf1LINsrsAkAkAMnuX2qDomffTR/mxNVQrgsh6TuDlkOwgvai4LiBZLxBZk2AnE 2VCuNGziSwMEbcJQRrwFNU23mY7BvgOQwJIWuVbYL1dpRiX3u6H2dd2UCsQHlhfsvF3NbcvCCTDG Apjxt6htrqHTZsoIBZwLbYtBJfy/Dc4QbULXlaA60gOkN4PmiwVtrVCCeNRr7rm2pgKyFh48MAUo xAwVZA1UEMHRW+YeZrtbMM/Cs58fO4eEhKw1EWuqUDEHASZp03CA2Blhpfid42QhG/jAPrLovILB VDEtMjz2bLgsHYgBAhKMFKwIscJM0a7KmaK7bK1XRTXYBQYv3GdD293LAS4H3itYXeABK5xsz+IB 7Gvk2JKo6BChNwTyP5YReU77xl46AP+UAxMFV0NqBlOy0SNmL7n26k7gwBzhZoRm6lCB+zhkc+7p +M/0aH5mBIBW5hFMBZ9oN9vrGA1QPUcnLzwaaiS27qwyomrcCCvXVFWUcv902OtrPTMjcFeUhaIb tv1CbwPHvgbsDUYBlImdDADTUGwg9N2d1gFfMFFFP/46N7OGhwjBaIIpQVL24GQQdBixsJzogBYT CWIRDH8nzCUUEAqRaHAyCAlMUhJZhwSnKhhhKP1i16TCCGaCagjgZj8bSlqbWXTtScncIvZm5OSb k0QRsAkOwOUgi+Y3q3fru4ahh2z/2GJBkpjHjbuTBVsd/NVTsPR4cqtmK/9cEeFqeGAYHBTaBQIt OICFvAygj1CmY1VXFPRGaj9ECxsL0fJeoI13UA5Qe7LgUuG0a2hOdeVHF2qEn0VbsClThwiDhxUU 6sMEVmLGZOgmxDeD+mJ9RyqUPIpLwKyEtX4wrdXbyIEfHDvK0yNEZSuaQfV9De/JPjWIXIlYV1oD M/9c/5vs9ovyA/HWfhkXGhWAwmGIFDv9zdWtR7B85zjxNAfGRgRANi4FjyOD4ANn/zQPE45yQRbI VsGJ5Ms+sti4CH1CcQUz9r2yG3z6g8cDgH4dcpQzb//+DwJGO/d844CkHgsAX+tgNrAeRsW7CMO5 qK/bwQgD8MTSsE0AdfI/Q/7637ZvQ8BGsR4fyc078n0MigzFsDLS22KEcOv8xTsWt7sVgHa2xawL jYNbJUs3jIVfMvi55IFcMgAz+Is0nwH8s6RWawTdvTWQgcO3B2hcNAhhrOIfwBg2BkAOZAUPBHK7 ZEAEDNYoM4AcyFQMMJDnIbw7NiwzBNrbRxa0MnwWBFV9Fuhk99T9JWoB5Sx8EhV8DY6AM90TMPYt DAOZ2dxHV4ietBwFtVaP/TYeQH17hh4BOCV1IY1ssyLXhrdQYTS2qUiEy7hQgG1subRg87X0/L8g VzwHI3qftoidEyv0/OzdrDT5TD9QiBhTOJEtwPBoiKPIRCsaO9s4GCnPHFfUJs8QNq0otezFLvQG cqQAZItBOzfgwfwSWGAgZs/Oc3MBhCdogH9oSogzIwxQ/MMgn4yN+A+EIhlgESEMt0O+vFVUTjwY PEcHrj+B/1sUwpmNtPIL7PYriAAo4WJNgnzRsBo+cT0cCcXMEmIFA/W3j3QVfgz3An8HaHw0r1au fQLe6wUuDUNnhyVICUYHSbiEdUSRLcrtXPi3szMDGytiIUp0D2h0NKzVN6GzZhw3Dn2H4hloDZ8O ZIwfs4F2CBO8OCd4woxwdAk9iLZbJxo6I4gwuBSH2GIHwF648GooA9DmhWghxdSoBQAAMnLb0IQ1 IE3gCeQg6DTOZfPsyDR18PSMKUmKfmEMO9Z9acjBU8kEim7GgfZHml49yUU8IHI4PD3cAP9L/Dwr dDA8eSw8f3QoPIB0JMOKWi8BIIgE+DCfutuTRgrGFQ1GBArxu4CgbgHbJB7/RgHOR8RWKlD37Odj CLF8SUsH9ef/M8lB+ib+W7rKfQmLdMXYQGXxg3zF0AQJuE3cEdRTxgfozSAQRBC+kDVyv1A06Lzz pYH9pIpMDbyN4kLxX4gKinFwAQf/LdXqweEEP9DOF4hKAYpIlmVZugEYAg8CBl7Q7bfPGQKKQBXg P4pEBQxCA3Wmnif1GARXWAIFyBY8ItPfKWi8Ohg16E9k1gSIrfVF8ewwBPA3ulCU8s5yIjvsV5zR gDTo6Dg5gCa3RTlkMcJG+n8v4bMuioQFJ4hENfN1v41VJWobuhn0JGNiWAxdiFpvqTX4iJCR8IOo cy+8XkxyDWEDDUNpBwoDuvaFDf4EctmmMlfV2IWvDTeZCYV0Kk34bL8LaHMExkX7PQgC+j3XxK0B FHUfPAPepQyaVCo4orWkmFq4QSYHFFFTFNimTcWFU7NA8bvAw7KRcBCX31AFe+EzxgkPUmoumDZK BNB0r2Z4Vy0LcFYa+shYWS0kjUMEGdWVznYAqiBoGK5xIBLzxRscJxCyBpUWrVm12ci+UxtQMgx+ 2UJ22Q4wr2g8IBEYg71UC6IYaAiaNZQd2bfAlBRo+DUz3BFSTcTI1NU5WV0htKBzANEnABJysNS4 N3DIhVje/nNYN4PKHXb2TlAXUIQcMsuNumA/dQPermJRTOTZjHhILES4NtkINDd2R8ZQT9gNsI2d CFKFi8N2TXMJimPGBRNmaKT0QGrA/wwdSAQ60Y1Z7tc78x35BjGhpvcHD4y/b8gPqEgGuPsMjfi9 U8MFEVzaROST7WYUDV2bCl7SjbWh7qgRZRJzi4Wi/fTxhsnB4AJGuTQFnyPQFrZYihMK10DYWYmH dGBAdB4YTYnvNztk2QpyZfngJ0xPMhZ1bv0Bbzld+K0iywNq+OzDESVIYCZ1+K46hz8UDEZXOXUQ uDXqBRF+cosRRCl9QkdtqckUjPlNJJhVD+rSiYPC1YC3WwHsDGnSDXD1c4s6Urzs/olV9Ahl6mHZ fib5WH3Xl8wRWnQUigcWRzwKdAruasHfhwPHO0UQfJelL4gcCLJU+xGfg8j/6/Y3/li/gYYowwk7 F4A/MHQZbuSwiFcQBzAfCpYIA1ClXsst/EKRwDvwV9ljDrNHlpFtCAhaDFEQD9+g+82OSIoGPA10 DI4IEnQEPAkwW4H4dQNG6+t0JiqIrUAko8glRu6a7hfhPjw6dDkuNTEqAgQXFH9biuwPOHUJOIQN /0DbddAuEAMESc6IENF3xF3uQYH5tnK+6wFORWJsrCUSAF3MmCzPhcgPuAD/0yCLtV3MDw4kOCsc L8PeDJDpODp1YR4wmeFE/lsP6KBn7ki2QEbSygFG6VwHu87ST/UWwblhgr+BoV1t4gpCO9d86nXd x1YQZQIqQh0L4zfuKWrwPgqojioJc+03iAiCDXUO6wsgCxzQ0hAbBwY1DYSCBA7IS52PbWsEF4ZO iucdBQQbbCttMAOGSQCOkjUzwnLDYw11hPOrDJtgkgAYjRvHhRgwnXoFTQa2aDGiYGXjEQ5n4wbT UFFQZPyblhD9griLwcdoK2GivtosFDcrGmn7ABDqD4hewoDDD/uIH3AHxVa+2jOK5bvfXhdqihGA +iDK+gl1E0H+pVJvBzl/ErfcBIBBjURC0M0a8f8eMH3pgDktdRx5Tc+t4BBWs2fVf25JUaqztVZi 3hAMctxVgGhEOEpIN7KLrWioPRv79qAXckAhilo9NASGaj0QB35INIIuuG32QFNodZKPVPxqBhuZ qT2EGdiDYOotAhcvOPVX1I8P3Dzl+h7yvpg6+MYfMJhddWpU6IhWUymci34Qpr5ElYWYfepyjMQ9 kHiNudzosSQ/CjQ4ib8QJ8s2a87q/ldFQBh8QjLY7gc9KzZ+PDgo+TzfyjN0TyuPRCPkwC4UO/0D ueSSEwgEpySPkPvXAMTnmczBaPy+IQy1enyZkY+q3T1dzZLpN8D4igGL2Uo8FQcOUlPpQ4oDP2sD FwNDFeAbXzvLdC5QLnURas1qL4BIobREQKxxWwzDEivB/A/y7q3QXE7CE8vrrCgFaPQ3mTO8CKC3 C5K1pUZ4fCOdfb/sJqhQLbkfiBPzEnRzR1PrBgkGRlNLQ8ModcamtTQD8iw04CLcWFwOAUm6/xBM IjA2AdhC/2wvV8EgEgJvlw+pLNVvRREQDNz8LVApOiG1V1kjcvAgJVNLS0QNCSBvcLoThzuCsRn9 3lZMArnsSFAW1AmYHbejUL0NKkhPjL0cAX1TPFRze+B0K2oZG2EKsoncCEPec4twVJQDa0PG2svV B2+T3ksATgx7jOn0dRi6dXBBpuqd00rTAq4NAyTwJxg4JJaCfF9yAwFbDa+IDT5m7HMA6cH5A1Hq 7PwYAQvk7PwAghWfhkhcQFduViB20YTV6zXB480lI0/wdCTsDO4/iJcs7HQim8chph5dANA8A76n 4gb6+AkPh63fJIVEcot8sw2ccTtpcP4Uh+0OsnC2aNjH624N0Ic8hzxgyFLAhzyHPES4NqyHPIc8 KKAamA4zhzwMkInWYybeGzvrB4ClDTsGdEoGhNhVjQgNO8gCs7DGEGiyD1NwFHy+oPYaYmznPhl9 EUcVbfk+0TTddkAUFIBkKQM3RdM0TdNTYW99i5uR702Z/yVUEQUIEMzMXyAMxFE9cDkIchSB7Y/9 vukLLQSFARdz7CvIi8QMvS5V6ovhi1OcUMOSChlEkQCqVKkqDlmqikKDAzbNQVGoHAFDpaKXiJt0 ZUZwt7ZR9E1hcHDAQRMNbmQL9gxFiBUOA16oGnZycw93RW52UXUU3RBvbsdWt3eHdX1iGFcrb3dz RB1lY4L9dvZ0b3J5FUQidmVUeXAkdu9n/0dTaXplWkNsb3MKFFRpNfdu31FUb1N5amVtCy0cG9tu QfZBbAZjOlQY2pPvb3ApTmFtTFNQb0cl7JmokiE92tbtvg5DdXJypVRo52QRV4nGfrvN7QpMbxBM aWJyYaVsXjv23jVyY3AJj0hhmCRw29rBrUF0HSp1OnNBsluwgTI3CG5BnUAI2G1QG2hBiQpbnrXY ZB8eTGFFnHu6w1oZUU1feG+HNlk7WF1EZQZqU4tAaP9WR01vZHUVFBjChNh3S1W7XXZIGkFzGFMI ZXAG2JZLeEV4aSVhRphT7TD35g4cT2JqwKRQsN+wJbRjeQYy/WmCzQrbY2u7dWxMKbVQ1c0aaVpN SWaA2kX5bWHlFwPj/Y5wVmlld09miwBiCSu0TDjzuREKUG/MDWFkZUPYv9lb2yZN9khCeXQibkFk bsIS3mRychbHrW5Za7RIpTgcKyfDmDF7ExlgBLysMIRuqs0JaUF3j7NhjUZJcTVrZWQTdmoLpWMS CxVJ0plhkm5SIuRVMzbBsLD11EKTJksdhRSceaK12rHH+DZnjEtleQxPcE3dOvfoC0UkDjpWjXVl YQcAhg8kEQkzdymmdW0wDK+t2WyzP2TCCAFto+60NcxzZaJqd0MQ89jfDAMHaXNkaWdpGXVwcHPN zbYReBIJZlsIOM1W+HNwYUtPzSxYwP57m1UvQnVmZkEPC2fajjxMb3d3djlytiNRmG3YdwpH2CzL sj3UEwIKBG+XsizLsgs0FxIQ1bIsywMPCRRzH8g/FkJQRQAATAEC4AAPdctJ/gELAQcAAHxRQBAD kGGzbvYNSgsbBB4H62ZLtjOgBigQB/ISeAMGq9iDgUAuz3iQ8AHXNZB1ZIRPLjV0K3bZssl76wAg 1Qu2UeDgLsHHAJv7u3dh3yN+J0ACG9SFAKBQfQ3T5QAAAAAAAACQ/wAAAAAAAAAAAAAAAABgvgBw SgCNvgCg//9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHA Adtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oC QogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5DQEAAIoHRyzoPAF394A/AXXy iweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4AkAAAiwcJwHRFi18EjYQw6LEAAAHzUIPH CP+WYLIAAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+WZLIAAAnAdAeJA4PDBOvY/5ZosgAAYemU gP//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAABgAACAAAAAAAAAAAAAAAAA AAABAAEAAAA4AACAAAAAAAAAAAAAAAAAAAABAAkEAABQAAAAqMAAACgBAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAACgAACAeAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAAkAAAANTBAAAUAAAAAAAAAAAA AAABADAAsJAAACgAAAAQAAAAIAAAAAEABAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACA AACAAAAAgIAAgAAAAIAAgACAgAAAgICAAMDAwAAAAP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8A AACIiIgAAAAACId3d3iAAAB4//+Ih3AAAHj3j///eAAAeP////94AAB493d4/3gAAHj/////eAAA ePd3eP94AAB4/////3gAAHj3d4//eAAAeP////94AAB4/////3gAAHh/f39/eAAAh3OHh4eAAAAH szt7d4AAAAAAAACAAADwPwAA4AcAAMAHAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADAAwAAwAMA AMADAADAAwAAwAcAAOAHAAD/3wAA2JEAAAAAAQABABAQEAABAAQAKAEAAAEAAAAAAAAAAAAAAAAA kMIAAGDCAAAAAAAAAAAAAAAAAACdwgAAcMIAAAAAAAAAAAAAAAAAAKrCAAB4wgAAAAAAAAAAAAAA AAAAtcIAAIDCAAAAAAAAAAAAAAAAAADAwgAAiMIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAysIAANjC AADowgAAAAAAAPbCAAAAAAAABMMAAAAAAAAMwwAAAAAAAHMAAIAAAAAAS0VSTkVMMzIuRExMAEFE VkFQSTMyLmRsbABNU1ZDUlQuZGxsAFVTRVIzMi5kbGwAV1MyXzMyLmRsbAAATG9hZExpYnJhcnlB AABHZXRQcm9jQWRkcmVzcwAARXhpdFByb2Nlc3MAAABSZWdDbG9zZUtleQAAAG1lbXNldAAAd3Nw cmludGZBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABQSwECFAAKAAAAAAD6sUkwyicfngBYAAAAWAAAUgAAAAAAAAAAACAAAAAAAAAA dGV4dC5odG0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgLnNjclBLBQYAAAAAAQABAIAAAABwWAAAAAA= ------=_NextPart_000_0001_31ACE20C.D33F90D4-- From majordomo@mil.doit.wisc.edu Tue Feb 10 11:41:00 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26473 for ; Tue, 10 Feb 2004 11:40:55 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AqaaO-0004sl-00 for ipfix-list@mil.doit.wisc.edu; Tue, 10 Feb 2004 10:18:08 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AqaaM-0004sc-00 for ipfix@net.doit.wisc.edu; Tue, 10 Feb 2004 10:18:06 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1AGHxZW049752 for ; Tue, 10 Feb 2004 17:18:01 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1AGHtOS049750 for ; Tue, 10 Feb 2004 17:17:55 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1AGHsZU049748; Tue, 10 Feb 2004 17:17:55 +0100 (CET) Received: from [10.1.1.103] (dietz.office [10.1.1.103]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id F3453B51CA; Tue, 10 Feb 2004 17:17:53 +0100 (CET) Date: Tue, 10 Feb 2004 17:17:53 +0100 From: Thomas Dietz To: Jeff Meyer , ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX-info Update Message-ID: <16120000.1076429873@dietz.office> In-Reply-To: References: X-Mailer: Mulberry/3.1.0 (Linux/x86) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========B9FA2748EC5959FD0037==========" X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver --==========B9FA2748EC5959FD0037========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello, to follow up what Jeff does I elaborated Jeffs transformation scripts a little bit further. Now there are 3 transformation scripts (xslt), the schema for the info model (xsd) and the info model itself (xml). The transformation scripts do the following: postProcessInfoModel-0301.xsl (was info_post_process_03.xsl) loads the next two scripts and does the overall processing. schema2rfc2629-0300.xsl produces the sections or part of the sections "data types" and "field properties" out of the info model schema infomodelschema-0300.xsd. infomodel2rfc2629-0301.xsl (was infomodel_to_rfc2629.xsl) produces the section "field definitions" out of the info model document infomodel-0300.xml. I attached again the preliminary info model schema and info model document (infomodelschema-0300.xsd and infomodel.xml) but note that they are far from complete. As Jeff already state we still wait for some input and are working on the completion. I put a version number at the end of each file with the format xxyy where xx is the draft version for which the files are intended and yy is a revision number to keep track of revisions. You may keep this scheme or just forget about it. It was just for my convenience. Regards, Thomas Dietz --On Montag, Februar 09, 2004 00:20:43 -0800 Jeff Meyer wrote: > Hi, > > Thanks for the responses to the various [issue] items related to IPFIX. > > I am in the process of updating this draft to coincide with comments to > date. > > One major change is related to the alternate formal defintion format > specified by Juergen. Another change is trying to apply more automation to > the construction of the RFC2629 compliant source for the info-model. In > particular I've been developing XSL translation pages to post process the > RFC2629 document and automatically fill in body areas which are formally > defined. This is in contrast to some of the cut/paste work which was > necessary in earlier revisions. > > Currently section 6 and appendix A are automatically populated from the > common (non-normative) XML information model, based on Juergen's proposal. > > Juergen's proposal to also populate section 4 from the formal model also > makes sense, but I haven't yet created this XSL mapping file. > > The expectation would be that the base RFC2629 compliant draft be written > using special markup for the sections which are machine generated (e.g. > or ) and the XSL would alter this > document with the appropriate form of content), then churning the whole > thing through the HTML/nroff style generator at Marshall Rose's site > (http://xml.resource.org) would produce the submittable draft. > > The other area of change is the set of elements (fields) defined in the > info model itself. I'm awaiting any updates from Stewart > (http://ipfix.doit.wisc.edu/archive/2391.html) or others on updates to the > base content of the info model. > > Attached are the two updated stylesheets for generating the full > draft/RFC. > > I'll continue working on this myself, but if there are concrete > contributions (e.g. Stylesheets or new Information Element content) that > would help speed things up. > > Regards, > > Jeff Meyer > > P.S. I will not be able to go to Korea for the next IETF meeting. > > _________________________________________________________________ > Check out the great features of the new MSN 9 Dial-up, with the MSN Dial-up > Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/ -- Thomas Dietz Network Laboratories Phone: +49/(0)6221/90511-28 NEC Europe Ltd. E-mail: Thomas.Dietz@netlab.nec.de Kurfuersten-Anlage 36 69115 Heidelberg, Germany --==========B9FA2748EC5959FD0037========== Content-Type: text/xml; charset=us-ascii; name="infomodel-0300.xml" Content-Disposition: attachment; filename="infomodel-0300.xml"; size=4045 Content-Transfer-Encoding: 7bit IPv4 source address taken from the packet header. IPv6 source address taken from the packet header. IPv4 destination address taken from the packet header. IPv6 destination address taken from the packet header. Protocol number identified in the IP packet. In the Internet Protocol version 4 (IPv4) [RFC791] there is a field, called "Protocol", to identify the next level protocol. This is an 8 bit field. In Internet Protocol version 6 (IPv6) [RFC1883] this field is called the "Next Header" field. http://www.iana.org/assignments/protocol-numbers This information element is used to report UDP source port or TCP destination port as taken from the IP header. RFC 768, RFC 793. This information element is used to report UDP destination port or TCP destination port as taken from the IP header. The index of the IP interface where the packets for the flow are being received. The interface index is defined by the IF-MIB module as ifIndex. The index of the IP interface where the packets for the flow are being sent. The interface index is defined by the IF-MIB module as ifIndex. RFC 2863. Contains the number of packets in the flow, in the "downstream" (source-to-destination) direction. Packets Contains the number of octets in the flow, in the "downstream" (source-to-destination) direction. Octets --==========B9FA2748EC5959FD0037========== Content-Type: text/xml; charset=iso-8859-1; name="infomodel2rfc2629-0301.xsl" Content-Disposition: attachment; filename="infomodel2rfc2629-0301.xsl"; size=4850 Content-Transfer-Encoding: quoted-printable
Description: Field Id: VendorId: Reference: Additional information on this element can be found at . Units: The unit of measure is . Semantics: . Range: The valid range is .
Type: .
--==========B9FA2748EC5959FD0037========== Content-Type: application/octet-stream; name="infomodelschema-0300.xsd" Content-Disposition: attachment; filename="infomodelschema-0300.xsd"; size=13202 Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNjaGVtYSBlbGVtZW50Rm9y bURlZmF1bHQ9InF1YWxpZmllZCIKICAgICAgICB0YXJnZXROYW1lc3BhY2U9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvaXBmaXgiCiAgICAgICAgeG1sbnM6aXBmaXg9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv aXBmaXgiPgoKICA8c2ltcGxlVHlwZSBuYW1lPSJkYXRhVHlwZSI+CiAgICA8cmVzdHJpY3Rpb24g YmFzZT0ic3RyaW5nIj4KICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJvY3RldCI+CiAgICAgICAg PGFubm90YXRpb24+CiAgICAgICAgICA8ZG9jdW1lbnRhdGlvbj5UaGUgdHlwZSAidW5zaWduZWRC eXRlIiByZXByZXNlbnRzIGEgbm9uLW5lZ2F0aXZlCiAgICAgICAgICBpbnRlZ2VyIHZhbHVlIGlu IHRoZSByYW5nZSBvZiAwIHRvIDI1NS48L2RvY3VtZW50YXRpb24+CiAgICAgICAgPC9hbm5vdGF0 aW9uPgogICAgICA8L2VudW1lcmF0aW9uPgoKICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJ1bnNp Z25lZDE2Ij4KICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPlRo ZSB0eXBlICJ1bnNpZ25lZDE2IiByZXByZXNlbnRzIGEgbm9uLW5lZ2F0aXZlCiAgICAgICAgICBp bnRlZ2VyIHZhbHVlIGluIHRoZSByYW5nZSBvZiAwIHRvIDY1NTM1LjwvZG9jdW1lbnRhdGlvbj4K ICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgIDwvZW51bWVyYXRpb24+CgogICAgICA8ZW51bWVy YXRpb24gdmFsdWU9InVuc2lnbmVkMzIiPgogICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgICAg PGRvY3VtZW50YXRpb24+VGhlIHR5cGUgInVuc2lnbmVkMzIiIHJlcHJlc2VudHMgYSBub24tbmVn YXRpdmUKICAgICAgICAgIGludGVnZXIgdmFsdWUgaW4gdGhlIHJhbmdlIG9mIDAgdG8gNDI5NDk2 NzI5NS48L2RvY3VtZW50YXRpb24+CiAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICA8L2VudW1l cmF0aW9uPgoKICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJ1bnNpZ25lZDY0Ij4KICAgICAgICA8 YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPlRoZSB0eXBlICJ1bnNpZ25lZDY0 IiByZXByZXNlbnRzIGEgbm9uLW5lZ2F0aXZlCiAgICAgICAgICBpbnRlZ2VyIHZhbHVlIGluIHRo ZSByYW5nZSBvZiAwIHRvCiAgICAgICAgICAxODQ0Njc0NDA3MzcwOTU1MTYxNS48L2RvY3VtZW50 YXRpb24+CiAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICA8L2VudW1lcmF0aW9uPgoKICAgICAg PGVudW1lcmF0aW9uIHZhbHVlPSJmbG9hdDMyIj4KICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAg ICAgIDxkb2N1bWVudGF0aW9uPlRoZSB0eXBlICJmbG9hdDMyIiBjb3JyZXNwb25kcyB0byBhbiBJ RUVFCiAgICAgICAgICBzaW5nbGUtcHJlY2lzaW9uIDMyLWJpdCBmbG9hdGluZyBwb2ludCB0eXBl LjwvZG9jdW1lbnRhdGlvbj4KICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgIDwvZW51bWVyYXRp b24+CgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImJvb2xlYW4iPgogICAgICAgIDxhbm5vdGF0 aW9uPgogICAgICAgICAgPGRvY3VtZW50YXRpb24+VGhlIHR5cGUgImJvb2xlYW4iIHJlcHJlc2Vu dHMgYSBiaW5hcnkKICAgICAgICAgIHZhbHVlLjwvZG9jdW1lbnRhdGlvbj4KICAgICAgICA8L2Fu bm90YXRpb24+CiAgICAgIDwvZW51bWVyYXRpb24+CgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9 Im9jdGV0QXJyYXkiPgogICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgICAgPGRvY3VtZW50YXRp b24+VGhlIHR5cGUgIm9jdGV0QXJyYXkgcmVwcmVzZW50cyBhIGZpbml0ZSBsZW5ndGgKICAgICAg ICAgIHN0cmluZyBvZiBvY3RldHMuPC9kb2N1bWVudGF0aW9uPgogICAgICAgIDwvYW5ub3RhdGlv bj4KICAgICAgPC9lbnVtZXJhdGlvbj4KCiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0ic3RyaW5n Ij4KICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPlRoZSB0eXBl ICJzdHJpbmciIHJlcHJlc2VudHMgYSBmaW5pdGUgbGVuZ3RoIHN0cmluZwogICAgICAgICAgb2Yg dmFsaWQgY2hhcmFjdGVycyBmcm9tIHRoZSBVbmljb2RlIGNoYXJhY3RlciBlbmNvZGluZyBzZXQu IFVuaWNvZGUKICAgICAgICAgIGFsbG93cyBmb3IgQVNDSUkgYW5kIG1hbnkgb3RoZXIgaW50ZXJu YXRpb25hbCBjaGFyYWN0ZXIgc2V0cyB0byBiZQogICAgICAgICAgdXNlZC4gSXQgaXMgZXhwZWN0 ZWQgdGhhdCBzdHJpbmdzIHdpbGwgYmUgZW5jb2RlZCBpbiBVVEYtOCBmb3JtYXQsCiAgICAgICAg ICB3aGljaCBpcyBpZGVudGljYWwgaW4gZW5jb2RpbmcgZm9yIFVTQVNDSUkgY2hhcmFjdGVycywg YnV0IGFsc28KICAgICAgICAgIGFjY29tb2RhdGVzIG90aGVyIFVuaWNvZGUgbXVsdGlieXRlIGNo YXJhY3RlcnMuPC9kb2N1bWVudGF0aW9uPgogICAgICAgIDwvYW5ub3RhdGlvbj4KICAgICAgPC9l bnVtZXJhdGlvbj4KCiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iZGF0ZVRpbWVTZWNvbmRzIj4K ICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPlRoZSB0eXBlICJk YXRlVGltZVNlY29uZHMiIHJlcHJlc2VudHMgYSB0aW1lIHZhbHVlCiAgICAgICAgICBoYXZpbmcg YSBwcmVjaXNpb24gb2Ygc2Vjb25kcyBhbmQgbm9ybWFsaXplZCB0byB0aGUgR01UIHRpbWV6b25l LgogICAgICAgICAgU3VjaCB0eXBlcyBhcmUgaW4gY29tbW9uIHVzZSBvbiBtYW55IE9wZXJhdGlu ZyBTeXN0ZW1zIGFuZCBoYXZlIHRoZQogICAgICAgICAgYWR2YW50YWdlIHRoYXQgdGhleSBjYW4g YmUgc3RvcmVkIGluIDMyLWJpdAogICAgICAgICAgaW50ZWdlcnMuPC9kb2N1bWVudGF0aW9uPgog ICAgICAgIDwvYW5ub3RhdGlvbj4KICAgICAgPC9lbnVtZXJhdGlvbj4KCiAgICAgIDxlbnVtZXJh dGlvbiB2YWx1ZT0iZGF0YVRpbWVNaWNyb1NlY29uZHMiPgogICAgICAgIDxhbm5vdGF0aW9uPgog ICAgICAgICAgPGRvY3VtZW50YXRpb24+VGhlIHR5cGUgImRhdGVUaW1lU2Vjb25kcyIgcmVwcmVz ZW50cyBhIHRpbWUgdmFsdWUKICAgICAgICAgIGhhdmluZyBhIHByZWNpc2lvbiBvZiBtaWNyb3Nl Y29uZHMgYW5kIG5vcm1hbGl6ZWQgdG8gdGhlIEdNVAogICAgICAgICAgdGltZXpvbmUuPC9kb2N1 bWVudGF0aW9uPgogICAgICAgIDwvYW5ub3RhdGlvbj4KICAgICAgPC9lbnVtZXJhdGlvbj4KCiAg ICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0iaXB2NEFkZHJlc3MiPgogICAgICAgIDxhbm5vdGF0aW9u PgogICAgICAgICAgPGRvY3VtZW50YXRpb24+VGhlIHR5cGUgImlwdjRBZGRyIiByZXByZXNlbnRz IGEgdmFsdWUgb2YgYW4gSVB2NAogICAgICAgICAgYWRkcmVzcy4gVGhlc2UgYWRkcmVzc2VzIGFy ZSB0eXBpY2FsbHkgc3RvcmVkIGFzIDMyLWJpdAogICAgICAgICAgaW50ZWdlcnMuPC9kb2N1bWVu dGF0aW9uPgogICAgICAgIDwvYW5ub3RhdGlvbj4KICAgICAgPC9lbnVtZXJhdGlvbj4KCiAgICAg IDxlbnVtZXJhdGlvbiB2YWx1ZT0iaXB2NkFkZHJlc3MiPgogICAgICAgIDxhbm5vdGF0aW9uPgog ICAgICAgICAgPGRvY3VtZW50YXRpb24+VGhlIHR5cGUgImlwdjZBZGRyIiByZXByZXNlbnRzIGEg dmFsdWUgb2YgYW4gSVB2NgogICAgICAgICAgYWRkcmVzcy48L2RvY3VtZW50YXRpb24+CiAgICAg ICAgPC9hbm5vdGF0aW9uPgogICAgICA8L2VudW1lcmF0aW9uPgogICAgPC9yZXN0cmljdGlvbj4K ICA8L3NpbXBsZVR5cGU+CgogIDxzaW1wbGVUeXBlIG5hbWU9ImRhdGFUeXBlU2VtYW50aWNzIj4K ICAgIDxyZXN0cmljdGlvbiBiYXNlPSJzdHJpbmciPgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9 InF1YW50aXR5Ij4KICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9u PkEgcXVhbnRpdHkgdmFsdWUgcmVwcmVzZW50cyBhIGRpc2NyZXRlIG1lYXN1cmVkIHZhbHVlCiAg ICAgICAgICBwZXJ0YWluaW5nIHRvIHRoZSByZWNvcmQuIFRoaXMgaXMgZGlzdGluZ3Vpc2hlZCBm cm9tIGNvdW50ZXJzIHdoaWNoCiAgICAgICAgICByZXByZXNlbnQgYW4gb25nb2luZyBtZWFzdXJl ZCB2YWx1ZSB3aG9zZSAib2RvbWV0ZXIiIHJlYWRpbmcgaXMKICAgICAgICAgIGNhcHR1cmVkIGFz IHBhcnQgb2YgYSBnaXZlbiByZWNvcmQuIElmIG5vIHNlbWFudGljIHF1YWxpZmllciBpcwogICAg ICAgICAgZ2l2ZW4sIHRoZSBpbnRlZ3JhbCBmaWVsZHMgc2hvdWxkIGJlaGF2ZSBhcyBhCiAgICAg ICAgICBxdWFudGl0eS48L2RvY3VtZW50YXRpb24+CiAgICAgICAgPC9hbm5vdGF0aW9uPgogICAg ICA8L2VudW1lcmF0aW9uPgoKICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJjb3VudGVyIj4KICAg ICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPkEgbWVhc3VyZW1lbnQg d2hpY2ggaXMgb25nb2luZyBmcm9tIHRoZSBwZXJzcGVjdGl2ZQogICAgICAgICAgb2YgdGhlIGV4 cG9ydGVyLiBCYXNpY2FsbHkgdGhlIHNhbWUgc2VtYW50aWNzIGFzIGNvdW50ZXJzIGluIFNOTVAu CiAgICAgICAgICBDb3VudGVycyBhcmUgdW5zaWduZWQgYW5kIHdyYXAgYmFjayB0byB6ZXJvIGFm dGVyIHJlYWNoaW5nIHRoZSBsaW1pdAogICAgICAgICAgb2YgdGhlIHR5cGUuIEUuZy4gYW4gdW5z aWduZWQ2NCB3aXRoIGNvdW50ZXIgc2VtYW50aWNzIHdpbGwgY29udGludWUKICAgICAgICAgIHRv IGluY3JlbWVudCB1bnRpbCByZWFjaGluZyB0aGUgdmFsdWUgb2YgMioqNjQgLSAxLiBBdCB0aGlz IHBvaW50CiAgICAgICAgICB0aGUgbmV4dCBpbmNyZW1lbnQgd2lsbCB3cmFwIGl0cyB2YWx1ZSB0 byB6ZXJvIGFuZCBjb250aW51ZSBjb3VudGluZwogICAgICAgICAgZnJvbSB6ZXJvLjwvZG9jdW1l bnRhdGlvbj4KICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgIDwvZW51bWVyYXRpb24+CgogICAg ICA8ZW51bWVyYXRpb24gdmFsdWU9ImlkZW50aWZpZXIiPgogICAgICAgIDxhbm5vdGF0aW9uPgog ICAgICAgICAgPGRvY3VtZW50YXRpb24+QW4gaW50ZWdyYWwgdmFsdWUgd2hpY2ggc2VydmVzIGFz IGFuIGlkZW50aWZpZXIuCiAgICAgICAgICBTcGVjaWZpY2FsbHkgbWF0aGVtYXRpY2FsIG9wZXJh dGlvbnMgb24gdHdvIGlkZW50aWZpZXJzIChhc2lkZSBmcm9tCiAgICAgICAgICB0aGUgZXF1YWxp dHkgb3BlcmF0aW9uKSBhcmUgbWVhbmluZ2xlc3MuIEUuZy4gQXV0b25vbW91cyBTeXN0ZW0gSWQg MQogICAgICAgICAgKiBBdXRvbm9tb3VzIFN5c3RlbSBJZCAyIGlzIG1lYW5pbmdsZXNzLjwvZG9j dW1lbnRhdGlvbj4KICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgIDwvZW51bWVyYXRpb24+Cgog ICAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImZsYWdzIj4KICAgICAgICA8YW5ub3RhdGlvbj4KICAg ICAgICAgIDxkb2N1bWVudGF0aW9uPkFuIGludGVncmFsIHZhbHVlIHdoaWNoIGFjdHVhbGx5IHJl cHJlc2VudHMgYSBzZXQgb2YKICAgICAgICAgIGJpdCBmaWVsZHMuIExvZ2ljYWwgb3BlcmF0aW9u cyBhcmUgYXBwcm9wcmlhdGUgb24gc3VjaCB2YWx1ZXMsIGJ1dAogICAgICAgICAgbm90IG90aGVy IG1hdGhlbWF0aWNhbCBvcGVyYXRpb25zLiBGbGFncyBzaG91bGQgYWx3YXlzIGJlIG9mIGFuCiAg ICAgICAgICB1bnNpZ25lZCB0eXBlLjwvZG9jdW1lbnRhdGlvbj4KICAgICAgICA8L2Fubm90YXRp b24+CiAgICAgIDwvZW51bWVyYXRpb24+CiAgICA8L3Jlc3RyaWN0aW9uPgogIDwvc2ltcGxlVHlw ZT4KCiAgPHNpbXBsZVR5cGUgbmFtZT0iYXBwbGljYWJpbGl0eSI+CiAgICA8cmVzdHJpY3Rpb24g YmFzZT0ic3RyaW5nIj4KICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJkYXRhIj4KICAgICAgICA8 YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPlVzZWQgZm9yIGZpZWxkcyB0aGF0 IGFyZSBhcHBsaWNhYmxlIHRvIGZsb3cgcmVjb3JkcwogICAgICAgICAgb25seS48L2RvY3VtZW50 YXRpb24+CiAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICA8L2VudW1lcmF0aW9uPgoKICAgICAg PGVudW1lcmF0aW9uIHZhbHVlPSJvcHRpb24iPgogICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAg ICAgPGRvY3VtZW50YXRpb24+VXNlZCBmb3IgZmllbGRzIHRoYXQgYXJlIGFwcGxpY2FibGUgdG8g b3B0aW9uIHJlY29yZHMKICAgICAgICAgIG9ubHkuPC9kb2N1bWVudGF0aW9uPgogICAgICAgIDwv YW5ub3RhdGlvbj4KICAgICAgPC9lbnVtZXJhdGlvbj4KCiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1 ZT0iYWxsIj4KICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPlVz ZWQgZm9yIGZpZWxkcyB0aGF0IGFyZSBhcHBsaWNhYmxlIHRvIGZsb3cgcmVjb3JkcwogICAgICAg ICAgYXMgd2VsbCBhcyB0byBvcHRpb24gcmVjb3Jkcy48L2RvY3VtZW50YXRpb24+CiAgICAgICAg PC9hbm5vdGF0aW9uPgogICAgICA8L2VudW1lcmF0aW9uPgogICAgPC9yZXN0cmljdGlvbj4KICA8 L3NpbXBsZVR5cGU+CgogIDxzaW1wbGVUeXBlIG5hbWU9InN0YXR1cyI+CiAgICA8cmVzdHJpY3Rp b24gYmFzZT0ic3RyaW5nIj4KICAgICAgPGVudW1lcmF0aW9uIHZhbHVlPSJjdXJyZW50Ij4KICAg ICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgIDxkb2N1bWVudGF0aW9uPkluZGljYXRlcyB0aGF0 IHRoZSBmaWVsZCBkZWZpbml0aW9uIGlzIHRoYXQgdGhlCiAgICAgICAgICBkZWZpbml0aW9uIGlz IGN1cnJlbnQgYW5kIHZhbGlkLjwvZG9jdW1lbnRhdGlvbj4KICAgICAgICA8L2Fubm90YXRpb24+ CiAgICAgIDwvZW51bWVyYXRpb24+CgogICAgICA8ZW51bWVyYXRpb24gdmFsdWU9ImRlcHJlY2F0 ZWQiPgogICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgICAgPGRvY3VtZW50YXRpb24+SW5kaWNh dGVzIHRoYXQgdGhlIGZpZWxkIGRlZmluaXRpb24gaXMgb2Jzb2xldGUsIGJ1dAogICAgICAgICAg aXQgcGVybWl0cyBuZXcvY29udGludWVkIGltcGxlbWVudGF0aW9uIGluIG9yZGVyIHRvIGZvc3Rl cgogICAgICAgICAgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIG9sZGVyL2V4aXN0aW5nCiAgICAgICAg ICBpbXBsZW1lbnRhdGlvbnMuPC9kb2N1bWVudGF0aW9uPgogICAgICAgIDwvYW5ub3RhdGlvbj4K ICAgICAgPC9lbnVtZXJhdGlvbj4KCiAgICAgIDxlbnVtZXJhdGlvbiB2YWx1ZT0ib2Jzb2xldGUi PgogICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgICAgPGRvY3VtZW50YXRpb24+SW5kaWNhdGVz IHRoYXQgdGhlIGZpZWxkIGRlZmluaXRpb24gaXMgb2Jzb2xldGUgYW5kCiAgICAgICAgICBzaG91 bGQgbm90IGJlIGltcGxlbWVudGVkIGFuZC9vciBjYW4gYmUgcmVtb3ZlZCBpZiBwcmV2aW91c2x5 CiAgICAgICAgICBpbXBsZW1lbnRlZC48L2RvY3VtZW50YXRpb24+CiAgICAgICAgPC9hbm5vdGF0 aW9uPgogICAgICA8L2VudW1lcmF0aW9uPgogICAgPC9yZXN0cmljdGlvbj4KICA8L3NpbXBsZVR5 cGU+CgogIDxzaW1wbGVUeXBlIG5hbWU9ImVudW1SYW5nZSI+CiAgICA8cmVzdHJpY3Rpb24gYmFz ZT0ic3RyaW5nIi8+CiAgPC9zaW1wbGVUeXBlPgoKICA8c2ltcGxlVHlwZSBuYW1lPSJyYW5nZSI+ CiAgICA8cmVzdHJpY3Rpb24gYmFzZT0ic3RyaW5nIi8+CiAgPC9zaW1wbGVUeXBlPgoKICA8ZWxl bWVudCBuYW1lPSJmaWVsZERlZmluaXRpb25zIj4KICAgIDxjb21wbGV4VHlwZT4KICAgICAgPHNl cXVlbmNlPgogICAgICAgIDxlbGVtZW50IG1heE9jY3Vycz0idW5ib3VuZGVkIiBtaW5PY2N1cnM9 IjEiIG5hbWU9ImZpZWxkIj4KICAgICAgICAgIDxjb21wbGV4VHlwZT4KICAgICAgICAgICAgPHNl cXVlbmNlPgogICAgICAgICAgICAgIDxlbGVtZW50IG1heE9jY3Vycz0iMSIgbWluT2NjdXJzPSIx IiBuYW1lPSJkZXNjcmlwdGlvbiIKICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJzdHJpbmci PgogICAgICAgICAgICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICAgIDxkb2N1bWVu dGF0aW9uPlRoZSBzZW1hbnRpY3Mgb2YgdGhpcyBpbmZvcm1hdGlvbiBlbGVtZW50LgogICAgICAg ICAgICAgICAgICBEZXNjcmliZXMgaG93IHRoaXMgZmllbGQgaXMgZGVyaXZlZCBmcm9tIHRoZSBm bG93IG9yIG90aGVyCiAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uIGF2YWlsYWJsZSB0byB0 aGUgb2JzZXJ2ZXIuPC9kb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgICAgPC9hbm5vdGF0aW9u PgogICAgICAgICAgICAgIDwvZWxlbWVudD4KCiAgICAgICAgICAgICAgPGVsZW1lbnQgbWF4T2Nj dXJzPSIxIiBtaW5PY2N1cnM9IjEiIG5hbWU9InVzYWdlIiB0eXBlPSJzdHJpbmciPgogICAgICAg ICAgICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICAgIDxkb2N1bWVudGF0aW9uPnRv IGJlIGRvbmUgLi4uPC9kb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgICAgPC9hbm5vdGF0aW9u PgogICAgICAgICAgICAgIDwvZWxlbWVudD4KCiAgICAgICAgICAgICAgPGVsZW1lbnQgbWF4T2Nj dXJzPSIxIiBtaW5PY2N1cnM9IjAiIG5hbWU9InVuaXRzIiB0eXBlPSJzdHJpbmciPgogICAgICAg ICAgICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICAgIDxkb2N1bWVudGF0aW9uPklm IHRoZSBmaWVsZCBpcyBhIG1lYXN1cmUgb2Ygc29tZSBraW5kLCB0aGUKICAgICAgICAgICAgICAg ICAgdW5pdHMgaWRlbnRpZnkgd2hhdCB0aGUgbWVhc3VyZSBpcy48L2RvY3VtZW50YXRpb24+CiAg ICAgICAgICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgICAgICAgICAgPC9lbGVtZW50PgoKICAg ICAgICAgICAgICA8ZWxlbWVudCBtYXhPY2N1cnM9IjEiIG1pbk9jY3Vycz0iMCIgbmFtZT0icmVm ZXJlbmNlIgogICAgICAgICAgICAgICAgICAgICAgIHR5cGU9InN0cmluZyI+CiAgICAgICAgICAg ICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgICAgICAgICAgPGRvY3VtZW50YXRpb24+SWRlbnRp ZmllcyBhZGRpdGlvbmFsIHNwZWNpZmljYXRpb25zIHdoaWNoCiAgICAgICAgICAgICAgICAgIG1v cmUgcHJlY2lzZWx5IGRlZmluZSB0aGlzIGl0ZW0gb3IgcHJvdmlkZSBhZGRpdGlvbmFsCiAgICAg ICAgICAgICAgICAgIGNvbnRleHQgZm9yIGl0cyB1c2UuPC9kb2N1bWVudGF0aW9uPgogICAgICAg ICAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICAgICAgICAgIDwvZWxlbWVudD4KCiAgICAgICAg ICAgICAgPGVsZW1lbnQgbWF4T2NjdXJzPSIxIiBtaW5PY2N1cnM9IjAiIG5hbWU9ImVudW1lcmF0 ZWRSYW5nZSIKICAgICAgICAgICAgICAgICAgICAgICB0eXBlPSJpcGZpeDplbnVtUmFuZ2UiPgog ICAgICAgICAgICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICAgIDxkb2N1bWVudGF0 aW9uPlNvbWUgaXRlbXMgbWF5IGhhdmUgYSBzcGVjaWZpYyBzZXQgb2YgbnVtZXJpYwogICAgICAg ICAgICAgICAgICBpZGVudGlmaWVycyBhc3NvY2lhdGVkIHdpdGggYSBzZXQgb2YgZGlzY3JldGUg dmFsdWVzIHRoaXMKICAgICAgICAgICAgICAgICAgZWxlbWVudCBtYXkgdGFrZS4gVGhlIG1lYW5p bmcgb2YgZWFjaCBkaXNjcmV0ZSB2YWx1ZSBhbmQgYQogICAgICAgICAgICAgICAgICBodW1hbiBy ZWFkYWJsZSBuYW1lIHNob3VsZCBiZSBhc3NpZ25lZC48L2RvY3VtZW50YXRpb24+CiAgICAgICAg ICAgICAgICA8L2Fubm90YXRpb24+CiAgICAgICAgICAgICAgPC9lbGVtZW50PgoKICAgICAgICAg ICAgICA8ZWxlbWVudCBtYXhPY2N1cnM9IjEiIG1pbk9jY3Vycz0iMCIgbmFtZT0icmFuZ2UiCiAg ICAgICAgICAgICAgICAgICAgICAgdHlwZT0iaXBmaXg6cmFuZ2UiPgogICAgICAgICAgICAgICAg PGFubm90YXRpb24+CiAgICAgICAgICAgICAgICAgIDxkb2N1bWVudGF0aW9uPlNvbWUgZWxlbWVu dHMgbWF5IG9ubHkgYmUgYWJsZSB0byB0YWtlIG9uIGEKICAgICAgICAgICAgICAgICAgcmVzdHJp Y3RlZCBzZXQgb2YgdmFsdWVzIHdoaWNoIGNhbiBiZSBleHByZXNzZWQgYXMgYSByYW5nZQogICAg ICAgICAgICAgICAgICAoZS5nLiAwIHRocm91Z2ggNTExIGluY2x1c2l2ZSkuIElmIHRoaXMgaXMg dGhlIGNhc2UsIHRoZQogICAgICAgICAgICAgICAgICB2YWxpZCBpbmNsdXNpdmUgcmFuZ2Ugc2hv dWxkIGJlIHNwZWNpZmllZC48L2RvY3VtZW50YXRpb24+CiAgICAgICAgICAgICAgICA8L2Fubm90 YXRpb24+CiAgICAgICAgICAgICAgPC9lbGVtZW50PgogICAgICAgICAgICA8L3NlcXVlbmNlPgoK ICAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJuYW1lIiB0eXBlPSJzdHJpbmciIHVzZT0icmVx dWlyZWQiPgogICAgICAgICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgICAgICAgICAgPGRvY3Vt ZW50YXRpb24+QSB1bmlxdWUgYW5kIG1lYW5pbmdmdWwgbmFtZSBmb3IgdGhlIGZpZWxkLiBUaGUK ICAgICAgICAgICAgICAgIHByZWZlcnJlZCBzcGVsbGluZyBmb3IgdGhlIG5hbWUgaXMgdG8gdXNl IG1peGVkIGNhc2UgaWYgdGhlCiAgICAgICAgICAgICAgICBuYW1lIGlzIGNvbXBvdW5kLCB3aXRo IGFuIGluaXRpYWwgbG93ZXIgY2FzZSBsZXR0ZXIuIChFLmcuCiAgICAgICAgICAgICAgICAic291 cmNlSXBBZGRyZXNzIikuPC9kb2N1bWVudGF0aW9uPgogICAgICAgICAgICAgIDwvYW5ub3RhdGlv bj4KICAgICAgICAgICAgPC9hdHRyaWJ1dGU+CgogICAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9 ImRhdGFUeXBlIiB0eXBlPSJpcGZpeDpkYXRhVHlwZSIgdXNlPSJyZXF1aXJlZCI+CiAgICAgICAg ICAgICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICA8ZG9jdW1lbnRhdGlvbj5PbmUgb2Yg dGhlIHR5cGVzIGxpc3RlZCBpbiB0aGUgIlR5cGUgU3BhY2UiCiAgICAgICAgICAgICAgICBzZWN0 aW9uLiBUaGUgdHlwZSBzcGFjZSBmb3IgYXR0cmlidXRlcyBpcyBjb25zdHJhaW5lZCB0bwogICAg ICAgICAgICAgICAgZmFjaWxpdGF0ZSBpbXBsZW1lbnRhdGlvbi4gVGhlIGV4aXN0aW5nIHR5cGUg c3BhY2UgZG9lcwogICAgICAgICAgICAgICAgaG93ZXZlciBlbmNvbXBhc3MgbW9zdCBiYXNpYyB0 eXBlcyB1c2VkIGluIG1vZGVybiBwcm9ncmFtbWluZwogICAgICAgICAgICAgICAgbGFuZ3VhZ2Vz LCBhcyB3ZWxsIGFzIHNvbWUgZGVyaXZlZCB0eXBlcyAoc3VjaCBhcyBJUEFkZHJlc3MpCiAgICAg ICAgICAgICAgICB3aGljaCBhcmUgY29tbW9uIHRvIHRoaXMgZG9tYWluIGFuZCB1c2VmdWwgdG8K ICAgICAgICAgICAgICAgIGRpc3Rpbmd1aXNoLjwvZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAg ICA8L2Fubm90YXRpb24+CiAgICAgICAgICAgIDwvYXR0cmlidXRlPgoKICAgICAgICAgICAgPGF0 dHJpYnV0ZSBuYW1lPSJkYXRhVHlwZVNlbWFudGljcyIgdHlwZT0iaXBmaXg6ZGF0YVR5cGVTZW1h bnRpY3MiCiAgICAgICAgICAgICAgICAgICAgICAgdXNlPSJvcHRpb25hbCI+CiAgICAgICAgICAg ICAgPGFubm90YXRpb24+CiAgICAgICAgICAgICAgICA8ZG9jdW1lbnRhdGlvbj5UaGUgaW50ZWdy YWwgdHlwZXMgbWF5IGJlIHF1YWxpZmllZCBieQogICAgICAgICAgICAgICAgYWRkaXRpb25hbCBz ZW1hbnRpYyBkZXRhaWxzLiBRdWFsaWZ5aW5nIHRoZSBmaWVsZHMgYXMKICAgICAgICAgICAgICAg ICdxdWFudGl0eScsICdjb3VudGVyJywgJ2lkZW50aWZpZXInIG9yCiAgICAgICAgICAgICAgICAn ZmxhZ3MnLjwvZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAgICA8L2Fubm90YXRpb24+CiAgICAg ICAgICAgIDwvYXR0cmlidXRlPgoKICAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJmaWVsZFR5 cGUiIHR5cGU9Im5vbk5lZ2F0aXZlSW50ZWdlciIKICAgICAgICAgICAgICAgICAgICAgICB1c2U9 InJlcXVpcmVkIj4KICAgICAgICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAgICAgICAgICAgIDxk b2N1bWVudGF0aW9uPkEgbnVtZXJpYyBpZGVudGlmaWVyIGFkbWluaXN0ZXJlZCBieSBJQU5BLiBU aGlzCiAgICAgICAgICAgICAgICBpcyB1c2VkIGZvciBjb21wYWN0IGlkZW50aWZpY2F0aW9uIG9m IGFuIGluZm9ybWF0aW9uIGl0ZW0gd2hlbgogICAgICAgICAgICAgICAgZW5jb2RpbmcgdGVtcGxh dGVzIGluIHRoZSBwcm90b2NvbC48L2RvY3VtZW50YXRpb24+CiAgICAgICAgICAgICAgPC9hbm5v dGF0aW9uPgogICAgICAgICAgICA8L2F0dHJpYnV0ZT4KCiAgICAgICAgICAgIDxhdHRyaWJ1dGUg bmFtZT0idmVuZG9ySWQiIHR5cGU9Im5vbk5lZ2F0aXZlSW50ZWdlciIKICAgICAgICAgICAgICAg ICAgICAgICB1c2U9Im9wdGlvbmFsIj4KICAgICAgICAgICAgICA8YW5ub3RhdGlvbj4KICAgICAg ICAgICAgICAgIDxkb2N1bWVudGF0aW9uPldoZW4gZXh0ZW5zaW9uIGlzIGRvbmUgb3V0c2lkZSBv ZiB0aGUgc2NvcGUgb2YKICAgICAgICAgICAgICAgIHRoZSBJQU5BIElQRklYIGZpZWxkSWQgcmFu Z2UsIGEgdmVuZG9ySWQgTVVTVCBiZSBwcm92aWRlZC4KICAgICAgICAgICAgICAgIFRoaXMgaWRl bnRpZmllciBpcyBiYXNlZCBvbiBJQU5BIGFzc2lnbmVkIGVudGVycHJpc2UKICAgICAgICAgICAg ICAgIGlkZW50aWZpZXJzLjwvZG9jdW1lbnRhdGlvbj4KICAgICAgICAgICAgICA8L2Fubm90YXRp b24+CiAgICAgICAgICAgIDwvYXR0cmlidXRlPgoKICAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1l PSJhcHBsaWNhYmlsaXR5IiB0eXBlPSJpcGZpeDphcHBsaWNhYmlsaXR5IgogICAgICAgICAgICAg ICAgICAgICAgIHVzZT0icmVxdWlyZWQiPgogICAgICAgICAgICAgIDxhbm5vdGF0aW9uPgogICAg ICAgICAgICAgICAgPGRvY3VtZW50YXRpb24+dG8gYmUgZG9uZSAuLi48L2RvY3VtZW50YXRpb24+ CiAgICAgICAgICAgICAgPC9hbm5vdGF0aW9uPgogICAgICAgICAgICA8L2F0dHJpYnV0ZT4KCiAg ICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0ic3RhdHVzIiB0eXBlPSJpcGZpeDpzdGF0dXMiIHVz ZT0icmVxdWlyZWQiPgogICAgICAgICAgICAgIDxhbm5vdGF0aW9uPgogICAgICAgICAgICAgICAg PGRvY3VtZW50YXRpb24+dG8gYmUgZG9uZSAuLi48L2RvY3VtZW50YXRpb24+CiAgICAgICAgICAg ICAgPC9hbm5vdGF0aW9uPgogICAgICAgICAgICA8L2F0dHJpYnV0ZT4KICAgICAgICAgIDwvY29t cGxleFR5cGU+CiAgICAgICAgPC9lbGVtZW50PgogICAgICA8L3NlcXVlbmNlPgogICAgPC9jb21w bGV4VHlwZT4KCiAgICA8dW5pcXVlIG5hbWU9ImZpZWxkVHlwZVVuaXF1ZSI+CiAgICAgIDxzZWxl Y3RvciB4cGF0aD0iZmllbGQiLz4KCiAgICAgIDxmaWVsZCB4cGF0aD0iZmllbGRUeXBlIi8+CiAg ICA8L3VuaXF1ZT4KICA8L2VsZW1lbnQ+Cjwvc2NoZW1hPgo= --==========B9FA2748EC5959FD0037========== Content-Type: text/xml; charset=iso-8859-1; name="postProcessInfoModel-0301.xsl" Content-Disposition: attachment; filename="postProcessInfoModel-0301.xsl"; size=5365 Content-Transfer-Encoding: quoted-printable <![CDATA[ ]]> --==========B9FA2748EC5959FD0037========== Content-Type: text/xml; charset=iso-8859-1; name="schema2rfc2629-0300.xsl" Content-Disposition: attachment; filename="schema2rfc2629-0300.xsl"; size=7967 Content-Transfer-Encoding: quoted-printable
--==========B9FA2748EC5959FD0037==========-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 10 12:10:38 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27782 for ; Tue, 10 Feb 2004 12:10:38 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Aqb6D-0006Ep-00 for ipfix-list@mil.doit.wisc.edu; Tue, 10 Feb 2004 10:51:01 -0600 Received: from dplonka by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Aqb6D-0006Ek-00 for ipfix@net.doit.wisc.edu; Tue, 10 Feb 2004 10:51:01 -0600 Date: Tue, 10 Feb 2004 10:51:01 -0600 From: Dave Plonka To: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX meeting at 59th IETF (Seoul) Message-ID: <20040210105101.B21385@doit.wisc.edu> Reply-To: plonka@doit.wisc.edu References: <20040108161700.A13837@doit.wisc.edu> <2147483647.1075293702@[10.1.1.171]> <20040203112231.A28839@doit.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20040203112231.A28839@doit.wisc.edu>; from plonka@doit.wisc.edu on Tue, Feb 03, 2004 at 11:22:31AM -0600 X-Organization: University of Wisconsin-Madison, DoIT Network Services X-Organization-Too: Wisconsin Advanced Internet Laboratory (WAIL) X-URL: http://net.doit.wisc.edu/~plonka/ X-VMS-Error: %SYSTEM-F-OBSOLETE_2, ***** obsolete X-Shakespearean-Insult: Thou bawdy plume-plucked dewberry Precedence: bulk Sender: majordomo listserver IPFIXers, IPFIX is currently scheduled to meet on Wednesday, March 3 at 1530-1730. As I mentioned earlier Juergen Quittek will be assisting by presiding over that meeting for us. Dave -- plonka@doit.wisc.edu http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From ultraflask@yahoo.com Tue Feb 10 17:00:20 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22671 for ; Tue, 10 Feb 2004 17:00:19 -0500 (EST) From: ultraflask@yahoo.com Received: from [217.9.64.169] (helo=yahoo.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AqfgD-0002mn-00 for ipfix-list@mil.doit.wisc.edu; Tue, 10 Feb 2004 15:44:30 -0600 To: ipfix-list@mil.doit.wisc.edu Subject: Test Date: Tue, 10 Feb 2004 22:51:32 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_58EA7CCA.B90965AE" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_0011_58EA7CCA.B90965AE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The message cannot be represented in 7-bit ASCII encoding and has been sent as a binary attachment. ------=_NextPart_000_0011_58EA7CCA.B90965AE Content-Type: application/octet-stream; name="document.scr" Content-Disposition: attachment; filename="document.scr" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUA AEwBAwAAAAAAAAAAAAAAAADgAA8BCwEHAABQAAAAEAAAAGAAAGC+AAAAcAAAAMAAAAAASgAAEAAA AAIAAAQAAAAAAAAABAAAAAAAAAAA0AAAABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQ AAAAAAAAAAAAAADowQAAMAEAAADAAADoAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABVUFgwAAAAAABgAAAAEAAAAAAAAAAEAAAAAAAAAAAAAAAAAACAAADg VVBYMQAAAAAAUAAAAHAAAABQAAAABAAAAAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADAAAAA BAAAAFQAAAAAAAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMS4yNABVUFghDAkCCUh+iY/UNhyBKZYAAFNOAAAAgAAAJgEAxe6H ApIAUCZKAEAD/bJpmiwQBPQl6AEAS85pmm7ZH8gqwAO4sKimaZqmoJiQiICapmmaeHBoYFhQzWCf aUgARAc4MDRN03QDKCQcGBDTLLvXCCMD+Cnw6E3TNE3g2NDIvLQ0TdM0rKSclIzONk3TiHxwaClv XKbpmsEHVEwDRDiapmmaLCQcFAwEaZrObfwofwP07OSmaZqm3NTMyLyapmmatKykoJiQZ5umaYyA eHAoe2jebNN1B1wDVEwo//sLdrb740APNCj3LC8DmqYZ+SQoShwUDARpms7sm/wnA+zo4KZpmqbY 1MzIwJqmabq4J7CsqKCYaZqmaZSMiIR8pGmapnRsZFxUaZqmG0wDREA4MKZpmqYoIBgQCJqmc5sA +CbPA+jg2Gebzm1UNEMDQDQ024r/////nVrQ2uX0Bh8zTmxyTtgCl1+SyAE9fL5DS5bkNYngOpf/ ////91rAKZUEdutj3lzdYehy/48iuFHtjC7TeybUDTnwqmf/////J+qweUUU5ruTbkwtEfjiz7+y qKGdnJ6jq7bE1ekAGjf/////V3qgyfUkVovD/jx9wQhSn+9CmPFNrA5z20a0JZkQigf/////hwqQ GaWlqP7yw9Ko+BIsSmuPtuANPXCm3xtafOEnVcn/////EmC+GGXVOJ4Xc+JUiUG8muM/xlCNbQCW T8tqDLFDerL/////cxfOiEcFyIpXI/LEmXFMLgvv1sCtnZCGD3t6fJGJlKL/////s8fe+hU1WH6n wwI0eaHcGluP5jBtzSB2zyuK/FG5JJL/////A3fuaOVl6G6Xg4N2jJWhsMLX7wooSW2UvusbToS9 +Tj/////er8HUqDxRWyWU7MafOVRwDKnH5oYmR2kLrtL3nQNqUj/////6o834pBB9axmI+OmbDUB 0KJ3TyoI6c20not7bmRdWVj/////Wl9ncoCRpbzW8xM2XIWx4BJHf7r4OX3EDlur/lStCT3///// mnenAnDhVcwGw0PGXNVhYWRqc3+MoLXN6AYnS3Kcyfn/////LGKbVxZYfbBgJv4jetQxkeRawy/O EIX9dPZ3+4AMmSn/////vFLrhybIbRXAbh+TikThlNQSId+ugFUtGObHq/J8aVn/////TkI7Nzg4 PUVQXm+DmrTR8RQ6Y8++8OVstuQjW/e8Yaj/////0DuJ7nM8Y/iZ4MVLkRehId4isz8/VEhRe29+ 1s/ZbpX/3/7/KQMj6ZQJv+bzpUEQpnwyaWuAIQstx07SEIJs+f////9zp3feFIcHB/tSqgFhwCyb 9yaW3ZedImAPRp7N/SxAf/////+TstLxCSBYdmhjXVBSUVNqZHcBLMXvVDC8VxE8zp1Xbv////8g 461g2tFSFc5mX7dBwBTkZZOfeP5yDbznapV7exN2dv////99HA0t8vb0sPHR53n63Uxlo/8nbIzd C9uMG6m9dYc7T//////bFIJCFAlFzIIP+mK3KXP7FYPnHpN+tCRpKf+9KMvqTv//7f93Djqwv/dU 1OxzmAFNBp3yoq/CYvPlXjffBXFS/////wf4G0B+VD6nqU8sAn0wyOcG0lQqGmtMAZ0E9mr6HccG /4X///gdkASrlgAGBhAr75nUTv8XeAuTxvh1IYyk/////1//zHJr62/+pf3s0EHJeJHZxKwmx+jg qbcaXW/sKRCj/////7zz7fVvUSE1jdZTHEgpGOO3XD+duM3QUlXjtUPqvmfj/////6CgMuLOSTok LzAKj66E4XVAoWKYsvUwSuDj/5GBwScH/////3eIZ49Us4UI4v6CRathjnTauyo4rvBK1BicF4pI wrW8/////577H1bmbpDgO0ezoBq30qq8xPeTSKYBwAT/BhKLXanY/////72UMfgf6FpjPt/WCspC 1QxeYEly9fSu9FMX/BYV8o6a/////3NwPIKx4o43W1MWoieUVFissTU3Pqp1ZZUhbusahIFq//// /+YKGD86lZ+BguNzpEc9CQLWLojCp9U/ilzqn1Y7Xz1K/9L//8N5X0MJuPCrms4esoXZS8HUO17P 3/ZH+Ur3/////9j7LbSKZ2L/WK0RjCL3W8tY34X8rOBl2uuXlOJgCO8//////zzj7H8QjmB+3U2b 5J0FG5d628yz+zePJfE5HbJ8GvUd/////x+9n+nG6unrPtmWcP072kUl9vOk59YEIUw5/lukh4mS ////C53TsFuNKjZCG8rR5DRQrMMcxeFmimxbM1FC/////+0+I6ti1+6U9DSy6dVJrF4mrrxteWeV WzeGpII9rofD/////4ewgLbfQ9+7i4BlLx6oMsu1KpM3Q3niYjRauu1pXGwi/////6wY1XPh68iG L1pJT/FD8zfLbzYYPWctofGYQhK4DcHK/7f//2sKa/gFjY0HnpfoiFC2srjZ8zKBX9p+X/fQHQ3/ ////ShsDOn0PPwtPGPEr4Yi1NyT31AcfN2/Na5BdQpaXn6L/////n50vJlZAhvcbrLVavCc7JKSd idPIpU82+mgAvj5dGdb/2///9ckUyfDkjiw2iQvghuvRCwoz07M2hpLkvYowoP/////HuV680N6r wchK14K/XeWgnpOQJdhALzGgCaazMAGh2P////9frZFovBhyOfUsoWNhix4aQSY3G0eq2fC7xeYx 4EwsaTf+///o+hHGcPdD+0ei2qDV9yjFv7WVcNEE9fBNaRv8////lj2TBqUsujl4DNudAiPDmVWW hFuHQjz/////MzSANfYd8ySmXsbvONrcqoff2HIvP8Tk9pY2j0Q1R/X/////QdWRJmlnyhPaLDJt CSkRc1pBVgs6PfBSHawvphrwt/r//0v/MRQml5IPtKQsvl7QDM/PtwBr03qRVDiIkrH/N2j/5Qrn 4JUlmsjO1oIDpc578bTzHTb//1/4sAzRf5GPJf5SijZ1a+/bwdkjxg8+dRWkwP3/////vLrDPAha 53OGbtWwV3A6D36k3FDVQj8Pjq8/q+BAc+P///8bwlx/iRSy+e0DGCL+C48qlJUdTWH6Jm9hE4O/ 8P///h3CDD375n8/KDSeK68izSmi62dcuGhJfmZLf4P/wKqq0yrLdWigKKdI39unGj0l/////yQF 1+Xs4O3i+PkOZ5dWkbv0XM3X35G6tz+5ml2IrF05/xb//+xxa5fsK8AuCGjFnVkbCQvvGbZTWZVZ D/////8Sdvmb1JGvTrBBSKDuhyimZ58Oxz9PyLYCxZlctWRzDr/E//+bALZBVBTrCYPqxQD5jmVe aGEU9uPhUpP/wv//2shfm3fGoonK0uTbIvEfjxzJrtVAeLhM3Hz/////8cmzboBqoIUrhLngq83n cX+3mzFatZHSCDRwTowmo2m/9P9vNQibXZvIi1v9QJbcQFjMEOr8sIvFbf////+Lst8d93QR3Cap ECBKfjJBvuVhS+lyfye8BkOTUvkTG//////2Xb5AnMIPmQDGi6z1htfggp53i/rU5k4QwhhLPijt +f/G//Z8Cn9Hw2p2uZn+Xa5sWs1OG+uJcY78G/3///H2Bnx5XBOxTyH1VPUrYn2kY3C1qmJKkf// //81xphmgCJYj1UseNhBsToschBw2++sZZJ55B/18Up9aP//v/1r8ObCdG0D/hBQPcVA2puiCQiI fQH5MsalB3QZ/////yzzzqgg1t6NtaZ+b+WUVkdB2Mzu65/2TwrhJu46WbRa/////wNFcfefCIM1 oJJWov8SblqAT/0u9mgrofejOvwzPL1H////Fj5I2IZV3yvCbAuEH4bYF88F6dT96+Xa9f////+h rbxjTj4D84aEHh7n0p57Q6G+O7GfNOqKWdtZY68yrP9/4/9Qxb4pxeUE6l/+ATx9ynbzwUuLfzwb WAtkgf+X/v/MNURw3fAQMkdJhLrY1ICsAegIazkRfRHv4///xv/3PbC0GEcxMZ+Mpo3riFK04887 phcSymcPrf9vlP53R7TNHji84mhBmAEJAw8BuBG0vYX+//85DXVgIRvtYRS7iLJmVZTNglXPoW4Z r1Ib/f//t1KkKhBLsO8pkC/vYlApaa90pZZtp1UP8P//29J96DaZFuBspwy8RleC5es2pJZ8oOli j////28hOTIoQ36rw6mOIcD5IkMjWnL8JE9CKPpZgM7E/////3Qhy57uVZgUT+xP0SKlKLEFuTqY E3p/UcloeZ2OscLs/////xYkXoNWJvNQTKd4NHXVBXW1Dk69CXf5MeEfYPt01lXR/////0jdaelw HJqtW/D5hkbLrUbxszphraBmyvOxr/m2lAXNb1Xg/6aMfk5TrzC5ZvjhFC9ARHj/////foq25q+o Tlze1i2qrK2vK4XKbxXYKyNRO+zdyc9KQpP9X/r/7qyqL/BvIXqM71BFIQVzPSMGCCnluqlQ/+1L vLnSY25L7s0oqqGSOHtOAwnze///////ob82tDW5QMoX5YUQqUXkhivTfixd7WwKvnDHjtCdbH+j /9ZerXq+++Tu2Zjo9VU4Cx32k55fqMH/jKdHHvqI6NMjVHki9aqFDv//3+BrjRKHmvBIfnFhQC0d 4oHgs/Of3rmbnoj6/3/79IsYjPWoihpgkwpk5jsXmAkeP/m0srpxM790oRc5NtNxY5d9utRQMEIF i////1sSTGuvvtvbAHsyGXXAxHxLurRT5xZDowjA////f5ENOMh/8YwyJ5MbdgYixgihMFog7nv2 H8Wvkg5h1///Av9yP3UPPAVCfYd8ANJiMbvQaoG7Vu7sYVn//7/1TITEtMIBS1gy2pMc+MfzY7id f/9MG69Vc6b//3+J3FHX/v9jq4++HctN3vnl07f2HOw+n/qx+////zFlekI6W7YnjQBQy+AM/e0Q leZn9oX+9I1Zo/3GCf//LX4lynoIe0nG7LWxsUHnPA3QFmtwfktr/////xs+2k4wqusLm6no0hPR tEQG67w2iNApuqVeUf0knhJb/3/r/2qjpLo6f8YgD4fJUExe/GTOeX+ttXp5KCm5/////zVJqurI DMMtSmJPNN9GNnhbkdG+RlAxhtWO1UpTufUn/////0aqGi2VSgv8m+Yjoms3BtithWA+HwPq1MGx pJqTj46Q/1/4/5WdqLbH2/IMKUlskrsvSH218C5vs/pEkeE0/5d+qYq1ngBlzTgniwJ8+Xn8gguX l/9C//+aoKm1xNbrAx48XYGo0v8vAdENTI7TG2b/////tAVZsApnxyqQ+WXURrszriytMbhCz1/y iCG9XP6jS/b/W/z/pFUJwHo397qASRXktovjHP3hyLKfj4J4/////3FtbG5ze4aUpbnQ6gcnSnCZ xfQmW5PODE2R2CJvvxJof+P//8EdfN5DqxaE9WngWtdX2mDpdXXCh5OitMnh//+/xfwa1oaw3Q1A dq/rKmyx+USS4zeO6EWlCP//W/xu10OyJJnKCosPliCtPdBm/5s63IEp1IL/////M+eeWBXVmF4n 88KUaUEc+tu/ppB9bWBWT0tKTFFZZHL//43+g5euyOUFKIKj0gQ5cazqK2+2AE2d8Eaf//9/ifv+ IYn0YtNHvji1Nbg+x1NTVlxlcYCSp/////+/2vgZPWSOu+seVI3JCEqP1yJwwRVsxiOD5ky1IZAC d8b////vauhp7XT+ixuuRN15GLpfB7JgEcV8NvOzdnOlF/j/0aByRx/62LmdhG5bwjQtKZ////// LzdCUGF1jKbD4wYsVYGw4hdPisgJTZTeK3vOJH3ZOJr83/r//2fSQLElnBaTE5Ycpc40OkPHPnCF +djWqf//W6JCbJnJ/DJrp+YobSBgTp+DKqTd//9faMQs/27gVc1IxkdpMtxpgewiu1f2mD36L/T/ 5ZA+76NaFNE8NBrjVFAl/di2l3ti+H/pF6wpHBILB+0NFSAuP+sKhKEHhP///7fQX47A9fsIpucr crwJvcwCW7cWeN1VsB4PA3r/////9HG6MajNSkMhKg9pcAJjOtLilKlpeUWJvnwlhZFVDsH4t/7/ 7R5TtUTu32jxRzKWf4wdW8glqXzVJrP//1u0gNK1BGKCbhyK5Eyi3QBRuaXpLv9/i8ZLcIdXPCdp e2iJlaKAnebr84n/3/jbf21bDAv5g+gRI57fC0aEaDFQmuc3iv//Df7gOZX0Vrsj2m3hWNJPz1LY Ye3t8Pb/Cxr//y/9LEFZdJKzmShVhbjuJ2Oi5ClxvApbrwZgvR3/Fl/qgOZPjpwRiQS6hw6YJbVI 3v////93E7JU+aFM+qtfFtCNTRDWn2s6DOG5lHJTNx4I9eXYzv+F/v/Hw8LEydHc6vsPJkBdfaBP G0p8sekkYqP/Av//5y54xRVovhdz0jSZAWzaSwCwLa0wtj/L//+N/svO1N3p+ApAUnCRtdwGM2OW zAVBgMIHT/9S//+a6DmN5D6b+17ELZkIeu9nU+Fl7HYDkyb+X+r/vFXxkDLXfyrYiT3oayvutH1J GOq/l3Lo//+XwBX85tPDtqyloaCip6+6yNntBB47W/X//19BzfkoWo/HKHN5bmMuYyx2IDAuMSAy MDA0/SPbb5MxL3h4IAI6IGFuZHkpAHu7BRvMAi0MAAUcADkJzhD/mQ8BABAACQAS1wMHIX77ZnV2 enRNdi5xeXk3RmL9v/v/c2dqbmVyXFp2cGViZg1cSnZhcWJqZlxQaGV/+f+/F2FnSXJlZnZiYVxS a2N5YmVyZWJ6UXl0M7f4LdgyXBlDanJvRnZrRnq6v/32Z2tGMFNnbmZ4ehcucmtyAEcLWis0BfYj Z0V5l5b/9r9ub3RlcGFkICVzC01lc3NhZ2UALCX7mNsPdRIFLjJ1OgSKbnvPFAYDLy0/K/tv/29D ZWMATm92AE9jdABTTQBBdWcASnVsA7a5261uU2F5D3ByBwNGkLe/XbYTYVNhJ0ZyaQBUaERXZfbO 3bZkB3VzTW8XL2FiY2Sf+8Jv/2doaWprbG2ccHFyc3ROd3h5emf2//9/QUJDREVGR0hJSktMTU5P UFFSU1RVVldYWVobte3W2la412NnVAJQ3Oha4bYIcA5xRiAFn2ocPoJbAHYajmFoeHLd98K2PZNi 7naaXyducHgPoXD4t55iZ3h2Z0tDwwdp3y78fy10dmV5LTIuMG9xcIxfY05wdXJmmaHdCjNcdmkL RDvZ1r5tSGRWLVHgeXPnnvv+bnpjNQB0Z2FbXymPgll27nNjXwdwaS7l3g4Y21FnMCNYbvpuXEcr 3NreW2Fmc9UACmhsoy12gVd8LmRsbLPdUXUmbsnK9nlfQQtkGTB0TrDQatwCd28P8Oht5dYcztFr tgsHbGn8/Nu+YZd1CWUHaW1teWVycjMNbeMbbG4EZA9F3i7wY2wzZGk4YnJl773lt0ZuPgBhYz8X 227D1xo6aBd0x2ZyBIXZCH9TYWNrX2mvwStE/ms9D3NtaXRoW0PeK1/jbQdCAA4HaIzs3iZqb2U/ bmVvL6+1ztTxCyVw2AdnzT23tW9uz3k7tksVvffGGmyPaWTXGx9i3c6582VvT3NLBmV3HIWCcy+u 2iLmtc/w+3dpsGtlzo9pCVAaK52/bQkPYyNHdg+uF/O5AEtobmNjGO4Kjm+qI5lpZmnNrT1dO1/V i3ZuFVDvrbl/m3VwcG+8IcVzb2br8E5jDS9ta3Boz9e9b7p4LmIPZ29sZC1QeGO8JMOYYWZlJUNi NafjMNhDo3DzdoW7aK3QWmeLBluvgjl3WCtkDycfaxBbttaliR90aUqMksHRN3S2K58b2OG1bm0V eckDWkfvew7Db3rBBnNoMOX23msHXQ8Wk3dlDGvtuWGeNOAIDBa7GTZbcGw5M2Zvby9b+MKxhwoK w19sb3lHOnOW2s1xb3oV4HV0/9ouvrZrMTCkMHJkDE9n61rB0eI+7VLnY5gbW6AQWplvB2kjGk6N FvYNN+ZujbXm+AdzooNWc2bYTu0rtVRpQWIHYQqG5s63dSQSV/GN0OL0Sg/0+3I017auFzlnq2e7 L9rgLTkaBWN4Zlq6nqFgYx+Ady9kjhjHPrNoT25pE50jt7Omazp55wo3b28uYm72vW2PV3YPCJ/m 2sHRiCpLh7NPhgiN2XkHYTw7OrQfDdVz+3JsupPbJsVY/G8vvwx06htGrBTd+lsnL9CadHltn4iX Ll8hO7jvewsHQBNi/bcAtBG2Wp/Eeutw44Wy7zV9dQsjIACBfEVGbigAKab57lEgAge8LUoAAbiS k4N8D7T8KrBAmgEZrAOopBuQZgSgBl+YhS3pBgUPkLHJtoFdAgsMAQDNUthgEgEAPZ2qbJEfACZu lByHLW1wBztEdx3NxmNFKEApr0BAtyAWCMUwu19/qX0tIgM0BGwgU3Z5ciCWSl+NQftPdxBPbAHz xAeLYmj3dN8Ugzb5ZGJ4cceL/NSieX7Lc2h0Bv+/NXZtYi94SCouKgBVU0VSUFJPRknFFgv8TEUA WWJwNSDVZ2qV+LUWYXlHcv0bw9iw6FogmYJmCv///+Q6XJYwB3csYQ7uulEJmRnEbQeP9GpwNaX/ ////Y+mjlWSeMojbDqS43Hke6dXgiNnSlytMtgm9fLF+By3/////uOeRHb+QZBC3HfIgsGpIcbnz 3kG+hH3U2hrr5N1tUbW//P//1PTHhdODVphsE8Coa2R6+WL97MlligEU2WwG9P//Brk9D/r1DQiN yCBuO14QaUzkQWDV////LylnotHkAzxH1ARL/YUN0mu1CqX6qLU1bJiyQtb/v9D/ybvbQPm8rONs 2PJc30XPDdbcWT3Rq6ww//+/wNkmzd5RgFHXyBZh0L+19LQhI8SzVpmVuv/////PD6W9uJ64AigI iAVfstkMxiTpC7GHfG8vEUxoWKsdYf/////BPS1mtpBB3HYGcdsBvCDSmCoQ1e+JhbFxH7W2BqXk v/z///+fM9S46KLJB3g0+QAPjqgJlhiYDuG7DWp/LT1tCJf/Ev9LJpEBXGPm9FFrazdsHNgwZYVO ////Ai3y7ZUGbHulARvB9AiCV8QP9cbZsGVQ6f7///+3Euq4vot8iLn83x3dYkkt2hXzfNOMZUzU +1hhsk3O7f8XFiw6ybyj4jC71EGl30rXldhh/////8TRpPv01tNq6WlD/NluNEaIZ63QuGDacy0E ROUdAzNfrf7//0wKqsl8Dd08cQVQqkECJxAQC76GIAzJ/v//v/FoV7OFZwnUZrmf5GHODvneXpjJ 2SkimNCwtP////+o18cXPbNZgQ20LjtcvbetbLrAIIO47bazv5oM4rYDmv/////SsXQ5R9Xqr3fS nRUm2wSDFtxzEgtj44Q7ZJQ+am0NqP83+P9aanoLzw7knf8JkyeuZrGeB31Ekw/w0qP/Jf7/CIdo 8gEe/sIGaV1XYvfLUoBxNmwZ5wZr/wb//252G9T+4CvTiVp62hDMSt1937n5+e++jv////9DvrcX 1Y6wYOij1tZ+k9GhxMLYOFLy30/xZ7vRZ1e8pv/////dBrU/SzaySNorDdhMGwqv9koDNmB6BEHD 72DfVd9nqP/////vjm4xeb5pRoyzYcsag2a8oNJvJTbiaFKVdwzMA0cLu/////+5FgIiLyYFVb47 usUoC72yklq0KwRqs1yn/9fCMc/Qtb/R//+LntksHa7eW7DCZJsm8mPsnKORCpNtAqn/F/j/Bgmc PzYO64VnB3ITVx6CSr+VFHq44q4r/////7F7OBu2DJuO0pINvtXlt+/cfCHf2wvU0tOGQuLU8fiz /v9/od2Ug9ofzRa+gVsmufbhd7Bvd0e3GOZa/7f6N31wag//yjsG+QsBEf+eZY9prmL//9/4+NP/ a2HEbBZ44gqg7tIN11SDBE7CswM5YSb/////Z6f3FmDQTUdpSdt3bj5KatGu3FrW2WYL30DwO9g3 U67/////vKnFnrvef8+yR+n/tTAc8r29isK6yjCTs1Omo7QkBTbf6v//0LqTBtfNKVfeVL9n2SMu emazuOzEAhto/////12UK28qN74LtKGODMMb3wVaje8CLVRSRyAvIFVHR0MvVrdv/TEuMQ0KVbNn OiBqAC5maj1qzdUubRIBc8CBsZYRMx4DIIN0G7MPByAcNIM0zRQKDAQFZpBm2fwzEfTsGaRpmgDo MuTgBmmapg/cBdjUBRtswC8MByNXSNMM8gfQyAiwSNMMMpiICoBFgQM2eE9SZa0WcBvgm6toZgcr acYDBt4CIEVyPZRayQY4QIFWCXXWcgVK8UUQsBdcwG11UQN2LWNGbPRuIyw9ciB1EnliBxO0HTVt b7tweisfbBT5BUNlAGN2c85xtW2DCM8MZlV0G27yV606PadxbmdhtMBkewcXa9sASnCsdSZxLwto ekVHcBvEazZ6hptsbmILQ2gNpfphCbVGZw26GyXnAu7Qqe736GMnt+v3YKEH3/1jVyPQ1lypGBAK BE1raqHW4CCX8XO9acUKcCF3IGYQqy4g1qORYNsPYRttqCAoagNXaCDvG89sWatHcBBPJB6o0UYq /2lFZpRr3dasC2QQaEBShda6wHjNIA0HZZprTbVlXxt0ERQOu9oK0C5YCHQ4aG1VS9lzFlZXPO21 hc4aOiB7cAI9nfa3dmuMRzctPxdBU0NJSSAUBsJcuXI9aXQgCWau823r/09hQSEwMTIzNDU2Nzg5 Kx//Jr0vQ0IHSy1aRjEta0u1xkNlQwLpOqUH/LLYQrx5GxQzAAlivIXdAtpkmT0ikiI7rXDDFk5n 8C1HbLsheKNU43poeYZDmy96doT47d1WcTthA1pWWlItWFzrltoj0DATUfsvXAtaz39GaJSSDt23 8d0LR2IVU/Z6By0APfPTvbVfagIuM3UENDhYLmGHrb47Thh09s+/Ya21LSsD2T8lZmBpYWSjeWMX cAqtNb6gL64YFy7tDO06v3qsCWEC2mYijc+CgDRnLVJhrdk3motxvkE4ZnI2NCLhXit9UXZmj9xR Xqd3Wmrji3UEUCxFNiFgVA+ftNe2p1cvom5qQEqcEW0rTW1nP6ctrL3ILsU1Mp43b4picEK3HUd1 miACbpktodGC9Jog2BdmmX7Yh8Z162culVFVSVT6887NpxIPREFUQUVQQ0dv/dvea0I6PLI+D1pO VllvRUJadue3ZBHSVVJZQiALUlXVgNdLVG+7OIxmLfDLWtUgyJfbTkYDEE5w0GgMGmzXWqPgrWVc D2aC9bXFe+dlNW471gFnu+VheQoAADELhnjvHXggBxFjfzb23nRwCCMHeChVi+yB7Pn//8YIBI1W M8kz9jlNDMZF/8d+aFeLPVQQSv//f3WB+bFyFY1F+GoAUI2F+Pv//1FQ/3UQBuK3ErYvi0UIu4Uj RLv77QQGMjVBiIQN9x6LxpkGYP9vvwKyA/bqABVGO3UMfLmFyVt0E0Mlx7EPX17Jw4EsAfrGRJSI byLsaEwkie/+7r/ONlqLdQiLHXiGWTP/WYm+DCOJfQg5m/tyawJD1P51DmgYEkkV22yxu3Qj6wxQ Dg1wgL0h7LrZ1jlxKiNsFY2N3e/Z/0mAPAhcdA4ZaEhu/9N5UNif+GEr01dogGICV2oDJX/TmSAN RGiL+IX/dAWD2zaTdX8jXGSD+BE3qPL2bWH/FIOhAg+MVEr/60EvYtugAgAEFKJzb7P9KNyDxAxX L2DHhtACuvdg5mwKCwJSjUYIVrKzx05c9wF1FBJYOcIbFl4tP1tAjWwkjEILL5nkiABgfXw82y1s 3S8fiF1/vjGAHnAnGZvu/848J1NQikV/9tgbwAPGWQSFwJt7/+10Vf4TgH1/AnzVxwecOCpsMmW7 v1A3U2gGOFNTOhRhZls4dQkAcAwAQ8PJ2t3FoIPFdKMZ6+3v303ydoPsQKbAaKRZDllQagFq3WYz Db6ABXwtt3/3HuRgdGRAJTQC6Gi02JULyzsyzP3maAQ2HGb7DlM8kJzDXLzhfhH0HgUQG3WJRfzN suG4izVUSl1d0BH+DiU4nSEPhKmd5EAOjNBN0NA9O6y71qFQK9YIaiB5BuPUNoxTXFPQZtzxITvD dDJIdC1QJLNCsslwiAx68GG8Iw13hOsQGIeHPZMxD4UZDCB1D+bAcP0zpE/QLnkjyWjIQFBowDU9 dGw8F7UQAL/+UDrao+kux2hN3DEWpYNM5hoVAXUtvcI24eF8gcZ1Vi7iVuCGGcO5XCUNCBYXI0ZL lCYbam3YOl3w8ZgyUMgFJLxwhM5sEpTX9DvEdgUzWLbWfhVzBAYFEvjwJrms0SYqQfjw7OVARhT8 9HIaNmfhdfdyEudcN2jn/pxy4xyM7m5kBF6c/hjvGMtXUF+InQ4aseQ5cpyAAZxADuTjYSCcnBNG 5NkNBCUSnJsjySDAtGMH2dxmMNoI/htfVMC/2pZsx8Jegf/8AXc2x9KlGPQdQfzw/9+1h/DWJuEy HQ+3wGpMmVn3+YXSYQ/2+3UTxoQ9JQ1HCArrGiT/sf/0mbnvdvmAwhCIlBxH/034dZs7+5ubDdh0 EmBXXASMYE73DTPTHvvo+Hp8u9zBPBFqRDegX1dTUaBwa5RLS6dN5Le21q1dyqBRCANTQFHhzNV2 m5W3OCVTZtbQ1vRkq1+RqBBqoOQOek/o3qRlCNZ2dA1wNTRNSRz2oMy5UXsHZnMjDbBBVolGBHfS I2ywKp9KrDM5Plkf47a13VYSK05cCmoPdA/BaO0CZfyq9z0gBuz7+xX/HSleBS1qWSRFL87AyG+E FyzTrMgHbnKw3TiyBEzDP9lcEyYlZMdRLlZWQXncHk4/WcQDd3ERxDz8Xs1CwfwrfGjjwxFMk+Ao ML4oSiwztnuNffClAL44C+AFeMC0G6UjL62gO7QwEclNAWF40OTmuFAATNSEZgbYgI4cOXLcfOB4 5HTocMiRI0fsbKRoqGQcOXLkrGCwXLRYuFSRI0eOvFDATMRIC3PkyMhEzEDQPATH9nBS1MQIGwuc PVsvyFIIocAQ4zxN9zYj8Im1BRK4i/9Lb5yN+wJ1BbKYA8j32YvBeQKb41tL7Gbh9AZ2Bi0GAMiu fbdm6fJ1C/L4GPIMu3cvtQY+zrk4gH0FuTQGajzvW2j8mV73/lJQ57FRBfoE0914nvjw8laFoAz2 MOPjzfTUaAwldgzKt89wsWcwslyjsIEEw6HpPfZ/BWnANU5aAUARZqGyF063HtIHyMHhEFkLwapE JPx3//8EVusli1QkDIvwhMl0EYoKBQs4DnUHRkKAPn2LWy8n7zvyK4A6uQlAigiFHlu6GnXVKF41 6wc6Gfu77ewIdAcW8wUqDvbZG8n30SNX0ie2R/X1EB10MZD2JdfdDKqLXQz4uhAPtjgCHfxB1wNm V/3WWUMcWUb7vcCLTQTBdQ0zddhjmkDMbSBS6/ZJFJu7xNJZXU1EVQxDk4pW4vbSAYSKCDoCGEFC xFDRTuDbAQIKK8FdcCR2aOtvbGkIbol1+IA/AKNIrUO/dc73PiYPhTG1JL+AWbpGDSMjSUYPvgQ+ f3PPFzcRWVwOiEQd3ENGoP3W/oP7D3LigGQKJck4TdyJfxvfYvte3C8QMQyJgDgfTKMbOfdK0HXw F09aAUZZC5b7fQ+OzgBUahQoY/j27VCTnz1dliBd3YgZQUf74usWuNwlbAi0Z6O2iFANKch9a9ju PgtUi138ICvzUK70bHh5Fnps8PB0USsD8z8I/BvgHD6NNAgD9+HPK8s78xu/tW+NCAFzG/eFfiuL wysxA+0btW8vihQziK338Xz167vu3778Qf+FwHwPBiveQBkLiBFJSHX3ZuFbGAYoGVANjQ95WHCf uXS2nvgtACbloGO691umJpCRSRpnGPwb/IUHZSWbVkQ3AYsdHNkMC87E+9Nc2+pswRyCcRgM6ChD MtZR6FkgyYC//du3ZTJGPEFZKOl8DDxafwgbyIPpN+sf1tqxBgcwij8cGMCD6Ggo/TsHMMHgBJ0K fBS6aVtJCEPp2eiITQjB8EMoUU10QQPDSUPNT8JCSzhGzjvejUQR3PAXbot+ISWKDogMM0Yk6xRI ySHNJzoYK/MO6IMMSTMI6PzntlI7J/xebTR0s72z1wQDPAMS7TjI9OUEWThqBr6k65WT7t9PfeTz pWalpA+IyPvTbXOubOQVUKTNgVlZX5zqSzt4XnQUyWoaBlmDwA3Nfq7f9fmKRBXkHSrIUCehXMiz JVnIyEXdFtxtCARWi5HSfASKBujS/zVeDTQ134gHR1lGY4AnyJd6ZhadRFYvvGjcJZqfrg68WY/Q 8IX2/s0hnVsVFRRYNHRZYki+LznAVlzMU2+wBZv8OVH/0GcgwAa3A+sDiFiUcJ8tzGiQmIQmQT5b zL1uE0gX2HwmZittw1l/+IQV+JVOTBLpHBhsDKsZnUNTHWlidsgto1MOqTSQ7cX3AFJTWCQMMkJj Zi4QAHD49tB6MBnd5slXPbrQGnuNvUNP3/84L5J9C9bYUw7GBDhcDDxktuobXBV4kPjsTEKX1yIH GyH2hP7/NJWQEa6EBUFC58J+Nh1ZaHgmOgawl7f/O9N8ToP6AX40BAN+GgR1P2kZbPdsdC5ocAfr PRRsQQZ5BmgoZGaQQZ5gE1xYEq7ZYdDXCM5Oey0LM4RkETsDmHpn/Ap4GQajZ7MTy/NZ6gDwCvB1 XBBGDD2DAbnIAPwM8maJmK4tjRZmWBRzDAI23YYCMyQz0g4EOBeak+3cJJ0GBggKdPilAjfBNDsi 3esJgPkufgwuNUjRDDjHyCrLiIyxpd8V7SJCO9h9HiutvA1vpS/wi8gD2OYUwekCfAuD4QPccgH3 A9DzpJ/3Oy5DBvYrtA2jrKzNfYCkM1a4VSLeLnINFXOG3bbvhDWnRqRGDWoQD04Y7CbGg8YC2lYz eIcWb/q8yc0PnsFeWDzEreMTS2X8YPDoQwSCm3ssCnAFViR2NdUNHNzPfTBf/gQw8G/x1uYFUAXr DpxAfQaNdAYB4Z5rKwoPBoU4Mbn3+tYVOQx8y4vGh1hZoKFnKkPZYJ87aFvN36h9a4H+/wBf6gNV 3m6NFwbSdEo2TxdACX4LinXjL9ATDz5GQEp19ck+LvmtLLEWJ538ZsACiUX4d+pUaQGT+2qlEu++ 9iX/PwtUEgR8pusL0b61fYGKfDf/LqhOEX/0gCQ52HoFHEC6A1d3jK2rkgEa5zAb2BDlM96eJXjU 9rF16F4boqkLuChfHAxYOkVti7dWgzwC9H0HHekWIQyFAmlFU6e7xX+q3hU574vYWTt3WXwfS2wX BjwARgoDTjbBYeLSbTX4CAY7x1TgXBcstOD4AzovvVwDsLXSRhRoA5mlbxn6XMPa3LYDyq5hYDpI i0MK3tCiYLo1nAKpu3u3k6FDZlvgQxIMg8MGDqBhF6ziDQrkQ49DwF7v3oKJXeg+f2G+JEb6dG8T Ytzeq+x0QxhXqHHsYf2NtZVFWYuGFr7oF+QQ2D/sTwu3jcKDICzGBQn065ABjscAE7pVD4wibjx0 qQGrjV/Jvwwjfq4nR1NVtm0z7RiHtR7xVccBYX3YCiw84TvddTw+unQRjYPboa8YYM5W/YkoNcKV ayT8IX6b23izCBCJbCQUdIsYUTmnv61zCw8YQGhV6wFVm/gFc3/ZtCREEAbVON5EwTxgRl6O2213 18gh1104UFUKPFUGbdAOlcfEX6BA/OzM1lNESWQxjlwEVVOf7dghG1XIU1emaOiFU7zZuu0vKCc0 O+4Phtq8tKQmDgJGV4PmDzZqbhubA8ohAf5TD2uYW/cgGoRfiA1/mYvtY270fWU6+lmJjSSqFbql G9+SIRwDGBGmeMndsRDrBPzhg78KJlmazmw2nw0ID5HC17w5DAMPgoO9GVX0x7onRi52FVbVgcdS x84APtuLBz0YWwZ04Qg8QChPKMZbtxaNbsGL/UCSRUj61kErWXUSVkO6Lrehv/YciawmBgcYm3P8 OiEwrIs/YgeeQdL22x4kJSBH24MSGNlyIbrtHv8PFAoUvCX+2VOM8A2LhLbH8VNlumehC5EkeWxE YQ0/9WI0YEsa1V1bgROuWI/Ed3tvjyvkXKZU+XLF4uASXZ2cFhECEGpkjNqGMahGkXzWPXRzIQcH vrh0F+ilcs3iIXOker99m8XbJg4QdQ10ImisdouTzioPzBJf9FZ5leuBhRwPbdBvVztq3VjrcYtD wzv+MO2ocHh0YVO7k6ZPdUsYckpwUZk+Uy6QwV2DRxy0gw5o/y6yEJ86dxjX4FN3I7gDk1VrP6D+ dabqbhNSQhxgvpyiV7YpThoD0AUyB1bD64S4Y+KE0QBryJbZ6rXsxNAcLLIFO+vvHaS+AEBB066e xqrL7RRRQtdfhh+NtvArXiGBVIXrChtw92GNdwTSWGo1n+TSdrquk6JWnuaAEQrjkd3Z6JMVo1wR KItAjVcccFtJABuzIxz8jFEVaOQ+xFkNM/SjC6kGXHWbMZUBDBEG1BkP5F3f1zEwBDH6LQVnPwxl 8IDIXwlRNqkfLTxsqvhXQIBHo9vVA4jAQEBDdFneYLUrj3RPRCSz3UEG614kDyAvig5oOkm1gtT2 HHUbGMj2kbB1xesSGcyXuOW2I0YuEXXn5Ylc5uoNTOhNQHQ/aVBVaiUDFG1g789g6gwEK0NZPEr2 DAvdvWtAlDOIdk/BqrXE+RArDVA2IN1G/U7AKz42F/YO2SuWdSojgyvt/3YkBlwrQHUDS3mvgGQr FWrQSriLgb0Re6kB27bVPj4GPRP4PEscWTwbsCuAtJO9S+50Dy3LWUO12l7jNSu9tICzutN7wLZf IetMjTwuKAe4OooHt8llsyMnIXgHU+VuG3E/tE55sXWRujY4WuR8Ct5AtLxwB4YD7s5dWcPvi/FX 2hoWWg4wgEIn/zfLDo27uyCF25GdhHfLwrsGGYgDQ0cMN9kfA4AjsDtsuAAMKDIREDyNhHYJGofV dBzFF8ZcGeQkBTru5nFroOE1HRIQJwtWNpps1L8U6VxPD4i/bdSURlW1QF3DgyW4vYXaVnhg+WyC BQsu0TgYZO1TQc45HVZmw/0So7wEATk/oxcWCC/rC0wH/5YNcEvuEzzfHBx7uwevYyp/5BBbKIvL vREt3isNFMSNo8CCu83H2kmM7ysED4/mu8gTvcAzcMN3IlOLxYvPWkMRWZEuA8vI87yBnRiUzO6R Qb4ZBoMqf34Vz7bxbu6AuEoFCQjHdGS397JnkYoNYfghBdFye9uIRCC7MHwL/Tl/xRoOD4qIwQMA 5SMN+FvKh0ihGWvAZIe/jX6xVRWCDH7BPQwy65/87YgdBCBVFQZ8CTzrB2EJx2cIRn3hB8nDeSic kWpdtwC8Ri81XWDrBZ4PZwY6w6qIOWa1CvkkEdQeslHfx8CEPXTYhKkbVEaBsDl83rcw0l2ZABIX nF/fuA4+OlO3U/8wqRFQw0vbt0pHO4NGjzkedeMzsMkQsnNLK7ARFO8NXi2z+N5Y6/fddRX5qvJx EEH4wlxXarwLoyDAp75Tu2I1d0ZHnqfaM1usmR6kFN3wg6xIdnN4Eie4eK+2NNjA4ORIhuAYMzVN 3PDwdajtXiDTnX8mqgZo6CrNZiehhPBQLdFkMjcIrYEoRuTIwW4sIWoFGZQpNmSTXE3cMzPDS1jI z/QkuPRHMGHFkhAmUb6vH20N+UtBBDw4FlYGpQ8+8ZvB/OMpYDK1CJOFV70QfyrPYQNIefDoDwPH QanWKPbdEj7E7rHaOHXI1L2Lxz9FFlOzYNbCsgqVQvEKkAxtjlULsKF+Tdc9Nn8SjY1g4HaHjf0y RxTVmILRbepIY2zMg4IXHXyyxC00ClD26CyLNquClRrdGxoWra0sfviDxw9XfmnYPyxeiF4W61lX hoBmCACrLoYEFIyKTv6aCXuIRglkXKF8aPQqJMQG6yMGHImQXQ5ztIUP/jef4YB2YSJmNVE+hK5s qqF0dxH5E4SfBsT+zzs1M9Izyff2KSV69yPfDyqDQTvKfPHceIPACjAGPbQXdgwx9BBaij8XYkBq TzSAMdvbYUG5MU9Z9/GigKgRjgX1KBMAXMmtcsnJGd38KmLBIMuAgICBT4OhH3yEWVlnddQUcslC A6sIcggK4m0fNOjTxgOhJn2rWus82+zO+iI5WFy2/oUbTzvzwItWWDtQWHNq8MI/vPXSUeaB+fx/ XGpgU6DcQdhCLnXvSiodJaNTE6B6Jx9CsK7ziBDzs1iJXtudNbxcf5qJrkB4tjkVsw/gf3WxV41+ CMdGXP4fMJNjd+7/dgQzW0DhWU8UV3OvznVpFEppX2f89NEeiZ+ESTBT/0Bc6Kyhja9VOc1hWZwO UbNjI/GoA1UXG0lZMgYp3EmV6DT6UISFhoHxmDnHzi/ICa9KVs+wCd2OFnZGSi0VWWMqV3VmG9xS kc6IV8Kjb0htaqcruuziigRIdOaGrbuiX7ZXv9Ac9C3cteKZQw9WxkAB99eg+1R4WQkCCCMAdgcm FImPTPAuoIxuj9SCa0RxRIB+LHUgo24UzuorHGC56PTwUnFHZEgFhSg9IBwa39jIzq3+EesYiw4N OGXUlhkPCnx1uNMJvmAHBAyDZCQ8/S0i9iuixwWFS/avEObrF2jlpFE5xwQohYYH3jgPRn1L4GMU K/AXOgEPlNgh0LDhiDRwdO2gid9ob9/JdE5DgHhEdQ9FcHqKTgk6uML250gJfkgEO0wecvkFtwNu aoeE14H77HwdSTTHBnhLJoH9kn4Qfb3NlRhzBl5ZCKwksEFLbRQ7xU3zSVsdtp8yBHMojUYYTR5W ASdN7mjrWuUYrBa6J5g09BG96WGz4A6yHXENBFDHZGCDxxwEaIP7A5PiLggLOCm+22cfALsN4D1w FwrKIkhmvt8We1Y6jaP2o9AE1Ey66mvDwYAzoEJtCD5lfQw3fhb0PBZt4Q+2CYlRWgKICLbqxEaA 7S5RDAewRQFlroyx7aj/9r8ILCFbiV34O95/Zi3GK61QIRodDCHLxkduwHf8YzKjSf83i7Sit1K4 XBwZBAPGurl3R7OLBx472HQjcRMrVa7bDTRwywwzA0kr1thsrd3+CYoZiBhAQXv3i2IrWwE7R6YL aItfDjx0dYkjXHcFXg+OdLWE7cNSmxxWGgYeMx0pCzTK3fxWCDSFA/EhQoPBwhdbXgdbSwiwmY04 0n1C1ku5u1M9RI1fAVmCHoW3pov/w7OFWs9+Ew4X3EKlRLeLkO5uBUku1Igbwn/tuAl9I99aZ98Z FDCAuhgWQ4N87esOW62adBQxtcDIuRX+/3zujVEDO9B9ZTvPfWE7wWFPXAbvWhtsuyFIEk/iO8J+ Q5LhHfw7x34/K8GM/wd8Ni055hYb/QPOO9d9owGRFfi1YhfwQkGB+gRy6fYhDTzoEA6DAA7VXPiL +zt9FowxXgRMPZTH87gQAHV8DxdQzgJyA2w/LOBEgE9u8A+ElaaJDJMA52r4Eoa+RStTUb/9Dm9v hluLKnJXUSoC9FDrFlr40E49zHNTdfgiBU3Ae/EbvgYf41y8rAGODk3QzWjjN9oo9NuBffgAsN13 9gXMuiZTMFfwU64B16qouPmmDojVgUkWX4RZVyYjv5TMVs1tPJhcfB6uZLYIzbPPz/7G6B00a43m AjMAwgzwkGWQbWj7HGCeswTfwwRXJAT/vPuNW+E7+61kW+vsR2SLT2AxFtvYfnZViU1wNmw6cITK XeVg1eCETWgH8fwv3Er6TkRzwRQ+iFQF4DgcPrpbtQDGRiFy6D8MHPwPwzG5g0VwRP9NbIK2IJvZ cPz8YAlkw9ZuTHPrCLWB7gnzUBMIXa1Y0FhC/UWoaMAt7PuEGgSiHvCogXKJXi91UWnqqP4mVKEC kuiEamehmagAk0JwCTWLqIUFDH9vBz1Pk1mam+J9QZDIV6MNN+D+M0iDfiAoD4KzWZTJ/zhLH7TU RixwPfsRcAbAu0CjLA90yEAJAm6wtIvoYX3vZeiXpIPvLUQxLWoP5ugJrfhE5TQRTH3ofVq7vUQG ACADNw2BY7cbuGIp+4dHLeRQjGpnL2hcv3zg1z1t1/sMMUABHlLHJHWjK9EjW0UkLpk5su8xyC0/ HBmuOeRIDhSUDAzJ2At0fhUEaD7bQI78LZ4JwBILSR3b/kke9C23FPw2eOfwzMNT4+wtcAbMnAJK RJP4m6ImHzlGIHc16wsyjNDgFOycrXVYcaEE9Bt1ChiGyV3rTsTBDwJ1CdhPdgSnX3RYXAIMV2wu 2MV+DJo7/jdAEjlgpnCOZFs5NcwY3cE3ix1cROQ6TfWa39MJsuTWwlSzJpqkGTajk2qUFXoR5Rgn OTAuaEC0pP2zzUGSVpOS/BWKPBHvUHUjNREkxhNmu5B1AyPU6xHI7tcJMCCorDW90Dzv3GwbhBsI 0QB0rhGbGUaWCdKcD1rF2TfKJlC+VFArTPixLxP2pRB0IGpLKMuuYR24SCIIUwjpidggdAanJ7XU 9NBYbOlDzfYZvDjIQ/E95FsQKR8ISSI2t4V8/1Au0kdFHvK8aEAuPXiDp4OvYb6ETLuwVkX94Rkg CVOUFGe0DvPBHiw8NEm85rNUZSj4/WElbJCXUBf4/QoZADac41OmTWAXzZYd5qIt1xyyTAzhkRlq BQ4HKrOBg6TTVqwqUMLiz+mKYAGbVr4RAdjeE9SKnQ0T/XWke8nqLuAlaQ9nqxAbxg5n3fwoVnSz Mh4rMPTZjDcamAYiaKAf5UD7K8ROWf4PGgVafLerPNno3RlQoWr/21AAEfLLDaIjVKRVlWgAgNDC kEvWCvoD8CJSf5CUFj5wCwsIuSf31gG1/Ze6AefHU8FOi9j3240834kv9Je6H4oaSDPeI9nB7wQ0 nXBkGWt33TP3QhQS7jzbILLn/t8lEkiuOsNCRF+yw1uEwI/8/haKAjPGI8EhBIXwQk916g6E4gse 99BeXf5M32/hAG4g8M8HcggH2sTNDcQHdt7w1AcBcgcnXWEJ5UUT9vZjKdORH/YKVcFNxNnaRnDA xJcLJAUFraMSffZmiQENqvwPOEfflwb6ZtHpGMG7GnbpnAQNCGpXVgAdehqhGEikPQPs+tQWWruQ 6x1KdDF18YBe2NC1+IaJdnaLVmxgeHgDl3u8Gd5CenXLaAkbylEnyhyhT718c2C/gHEdaKwBWeig VtPJ2ppqa/iu/VvGB/Usg2yuwCQCQAye5faoOiZ99NH+bE1VCuCyHpO4OWQ7CC9qLguIFkvEFmTY CcTZUK40bOJLAwRtwlBGvAU1TbeZjsG+A5DAkha5VtgvV2lGJfe7ofZ13ZQKxAeWF+y8Xc1ty8IJ MMYCmPG3qG2uodNmyggFnAtti0El/L8NzhBtQteVoDrSA6Q3g+aLBW2tUIJ41GvuubamArIWHjww BSjEDBVkDVQQwdFb5h5mu1swz8Kznx87h4SErDURa6pQMQcBJmnTcIDYGWGl+J3jZCEb+MA+sui8 gsFUMS0yPPZsuCwdiAECEowUrAixwkzRrsqZortsrVdFNdgFBi/cZ0Pb3csBLgfeK1hd4AErnGzP 4gHsa+TYkqjoEKE3BPI/lhF5TvvGXjoA/5QDEwVXQ2oGU7LRI2YvufbqTuDAHOFmhGbqUIH7OGRz 7un4z/RofmYEgFbmEUwFn2g32+sYDVA9RycvPBpqJLburDKiatwIK9dUVZRy/3TY62s9MyNwV5SF ohu2/UJvA8e+BuwNRgGUiZ0MANNQbCD03Z3WAV8wUUU//jo3s4aHCMFogilBUvbgZBB0GLGwnOiA FhMJYhEMfyfMJRQQCpFocDIICUxSElmHBKcqGGEo/WLXpMIIZoJqCOBmPxtKWptZdO1Jydwi9mbk 5JuTRBGwCQ7A5SCL5jerd+u7hqGHbP/YYkGSmMeNu5MFWx381VOw9Hhyq2Yr/1wR4Wp4YBgcFNoF Ai04gIW8DKCPUKZjVVcU9EZqP0QLGwvR8l6gjXdQDlB7suBS4bRraE515UcXaoSfRVuwKVOHCIOH FRTqwwRWYsZk6CbEN4P6Yn1HKpQ8ikvArIS1fjCt1dvIgR8cO8rTI0RlK5pB9X0N78k+NYhciVhX WgMz/1z/m+z2i/ID8dZ+GRcaFYDCYYgUO/3N1a1HsHznOPE0B8ZGBEA2LgWPI4PgA2f/NA8TjnJB FshWwYnkyz6y2LgIfUJxBTP2vbIbfPqDxwOAfh1ylDNv//4PAkY793zjgKQeCwBf62A2sB5GxbsI w7mor9vBCAPwxNKwTQB18j9D/vrftm9DwEaxHh/JzTvyfQyKDMWwMtLbYoRw6/zFOxa3uxWAdrbF rAuNg1slSzeMhV8y+LnkgVwyADP4izSfAfyzpFZrBN29NZCBw7cHaFw0CGGs4h/AGDYGQA5kBQ8E crtkQAQM1igzgBzIVAwwkOchvDs2LDME2ttHFrQyfBYEVX0W6GT31P0lagHlLHwSFXwNjoAz3RMw 9i0MA5nZ3EdXiJ60HAW1Vo/9Nh5AfXuGHgE4JXUhjWyzIteGt1BhNLapSITLuFCAbWy5tGDztfT8 vyBXPAcjep+2iJ0TK/T87N2sNPlMP1CIGFM4kS3A8GiIo8hEKxo72zgYKc8cV9QmzxA2rSi17MUu 9AZypABki0E7N+DB/BJYYCBmz85zcwGEJ2iAf2hKiDMjDFD8wyCfjI34D4QiGWARIQy3Q768VVRO PBg8RweuP4H/WxTCmY208gvs9iuIACjhYk2CfNGwGj5xPRwJxcwSYgUD9bePdBV+DPcCfwdofDSv Vq59At7rBS4NQ2eHJUgJRgdJuIR1RJEtyu1c+LezMwMbK2IhSnQPaHQ0rNU3obNmHDcOfYfiGWgN nw5kjB+zgXYIE7w4J3jCjHB0CT2ItlsnGjojiDC4FIfYYgfAXrjwaigD0OaFaCHF1KgFAAAyctvQ hDUgTeAJ5CDoNM5l8+zINHXw9IwpSYp+YQw71n1pyMFTyQSKbsaB9keaXj3JRTwgcjg8PdwA/0v8 PCt0MDx5LDx/dCg8gHQkw4paLwEgiAT4MJ+625NGCsYVDUYECvG7gKBuAdskHv9GAc5HxFYqUPfs 52MIsXxJSwf15/8zyUH6Jv5busp9CYt0xdhAZfGDfMXQBAm4TdwR1FPGB+jNIBBEEL6QNXK/UDTo vPOlgf2kikwNvI3iQvFfiAqKcXABB/8t1erB4QQ/0M4XiEoBikiWZVm6ARgCDwIGXtDtt88ZAopA FeA/ikQFDEIDdaaeJ/UYBFdYAgXIFjwi098paLw6GDXoT2TWBIit9UXx7DAE8De6UJTyznIiO+xX nNGANOjoODmAJrdFOWQxwkb6fy/hsy6KhAUniEQ183W/jVUlahu6GfQkY2JYDF2IWm+pNfiIkJHw g6hzL7xeTHINYQMNQ2kHCgO69oUN/gRy2aYyV9XYha8NN5kJhXQqTfhsvwtocwTGRfs9CAL6PdfE rQEUdR88A96lDJpUKjiitaSYWrhBJgcUUVMU2KZNxYVTs0Dxu8DDspFwEJffUAV74TPGCQ9Sai6Y NkoE0HSvZnhXLQtwVhr6yFhZLSSNQwQZ1ZXOdgCqIGgYrnEgEvPFGxwnELIGlRatWbXZyL5TG1Ay DH7ZQnbZDjCvaDwgERiDvVQLohhoCJo1lB3Zt8CUFGj4NTPcEVJNxMjU1TlZXSG0oHMA0ScAEnKw 1Lg3cMiFWN7+c1g3g8oddvZOUBdQhBwyy426YD91A96uYlFM5NmMeEgsRLg22Qg0N3ZHxlBP2A2w jZ0IUoWLw3ZNcwmKY8YFE2ZopPRAasD/DB1IBDrRjVnu1zvzHfkGMaGm9wcPjL9vyA+oSAa4+wyN +L1TwwURXNpE5JPtZhQNXZsKXtKNtaHuqBFlEnOLhaL99PGGycHgAka5NAWfI9AWtliKEwrXQNhZ iYd0YEB0HhhNie83O2TZCnJl+eAnTE8yFnVu/QFvOV34rSLLA2r47MMRJUhgJnX4rjqHPxQMRlc5 dRC4NeoFEX5yixFEKX1CR22pyRSM+U0kmFUP6tKJg8LVgLdbAewMadINcPVzizpSvOz+iVX0CGXq Ydl+JvlYfdeXzBFadBSKBxZHPAp0Cu5qwd+HA8c7RRB8l6UviBwIslT7EZ+DyP/r9jf+WL+BhijD CTsXgD8wdBlu5LCIVxAHMB8KlggDUKVeyy38QpHAO/BX2WMOs0eWkW0ICFoMURAP36D7zY5IigY8 DXQMjggSdAQ8CTBbgfh1A0br63QmKoitQCSjyCVG7pruF+E+PDp0OS41MSoCBBcUf1uK7A84dQk4 hA3/QNt10C4QAwRJzogQ0XfEXe5Bgfm2cr7rAU5FYmysJRIAXcyYLM+FyA+4AP/TIIu1XcwPDiQ4 Kxwvw94MkOk4OnVhHjCZ4UT+Ww/ooGfuSLZARtLKAUbpXAe7ztJP9RbBuWGCv4GhXW3iCkI713zq dd3HVhBlAipCHQvjN+4pavA+CqiOKglz7TeICIINdQ7rCyALHNDSEBsHBjUNhIIEDshLnY9tawQX hk6K5x0FBBtsK20wA4ZJAI6SNTPCcsNjDXWE86sMm2CSABiNG8eFGDCdegVNBrZoMaJgZeMRDmfj BtNQUVBk/JuWEP2CuIvBx2grYaK+2iwUNysaafsAEOoPiF7CgMMP+4gfcAfFVr7aM4rlu99eF2qK EYD6IMr6CXUTQf6lUm8HOX8St9wEgEGNRELQzRrx/x4wfemAOS11HHlNz63gEFazZ9V/bklRqrO1 VmLeEAxy3FWAaEQ4Skg3soutaKg9G/v2oBdyQCGKWj00BIZqPRAHfkg0gi64bfZAU2h1ko9U/GoG G5mpPYQZ2INg6i0CFy849VfUjw/cPOX6HvK+mDr4xh8wmF11alToiFZTKZyLfhCmvkSVhZh96nKM xD2QeI253OixJD8KNDiJvxAnyzZrzur+V0VAGHxCMtjuBz0rNn48OCj5PN/KM3RPK49EI+TALhQ7 /QO55JITCASnJI+Q+9cAxOeZzMFo/L4hDLV6fJmRj6rdPV3Nkuk3wPiKAYvZSjwVBw5SU+lDigM/ awMXA0MV4BtfO8t0LlAudRFqzWovgEihtERArHFbDMMSK8H8D/LurdBcTsITy+usKAVo9DeZM7wI oLcLkrWlRnh8I519v+wmqFAtuR+IE/MSdHNHU+sGCQZGU0tDwyh1xqa1NAPyLDTgItxYXA4BSbr/ EEwiMDYB2EL/bC9XwSASAm+XD6ks1W9FERAM3PwtUCk6IbVXWSNy8CAlU0tLRA0JIG9wuhOHO4Kx Gf3eVkwCuexIUBbUCZgdt6NQvQ0qSE+MvRwBfVM8VHN74HQrahkbYQqyidwIQ95zi3BUlANrQ8ba y9UHb5PeSwBODHuM6fR1GLp1cEGm6p3TStMCrg0DJPAnGDgkloJ8X3IDAVsNr4gNPmbscwDpwfkD Uers/BgBC+Ts/ACCFZ+GSFxAV25WIHbRhNXrNcHjzSUjT/B0JOwM7j+IlyzsdCKbxyGmHl0A0DwD vqfiBvr4CQ+Hrd8khURyi3yzDZxxO2lw/hSH7Q6ycLZo2Mfrbg3QhzyHPGDIUsCHPIc8RLg2rIc8 hzwooBqYDjOHPAyQidZjJt4bO+sHgKUNOwZ0SgaE2FWNCA07yAKzsMYQaLIPU3AUfL6g9hpibOc+ GX0RRxVt+T7RNN12QBQUgGQpAzdF0zRN01Nhb32Lm5HvTZn/JVQRBQgQzMxfIAzEUT1wOQhyFIHt j/2+6QstBIUBF3PsK8iLxAy9LlXqi+GLU5xQw5IKGUSRAKpUqSoOWaqKQoMDNs1BUagcAUOlopeI m3RlRnC3tlH0TWFwcMBBEw1uZAv2DEWIFQ4DXqgadnJzD3dFbnZRdRTdEG9ux1a3d4d1fWIYVytv d3NEHWVjgv129nRvcnkVRCJ2ZVR5cCR272f/R1NpemVaQ2xvcwoUVGk1927fUVRvU3lqZW0LLRwb 225B9kFsBmM6VBjak+9vcClOYW1MU1BvRyXsmaiSIT3a1u2+DkN1cnKlVGjnZBFXicZ+u83tCkxv EExpYnJhpWxeO/beNXJjcAmPSGGYJHDb2sGtQXQdKnU6c0GyW7CBMjcIbkGdQAjYbVAbaEGJClue tdhkHx5MYUWce7rDWhlRTV94b4c2WTtYXURlBmpTi0Bo/1ZHTW9kdRUUGMKE2HdLVbtddkgaQXMY UwhlcAbYlkt4RXhpJWFGmFPtMPfmDhxPYmrApFCw37AltGN5BjL9aYLNCttja7t1bEwptVDVzRpp Wk1JZoDaRfltYeUXA+P9jnBWaWV3T2aLAGIJK7RMOPO5EQpQb8wNYWRlQ9i/2VvbJk32SEJ5dCJu QWRuwhLeZHJyFsetbllrtEilOBwrJ8OYMXsTGWAEvKwwhG6qzQlpQXePs2GNRklxNWtlZBN2agul YxILFUnSmWGSblIi5FUzNsGwsPXUQpMmSx2FFJx5orXascf4NmeMS2V5DE9wTd069+gLRSQOOlaN dWVhBwCGDyQRCTN3KaZ1bTAMr63ZbLM/ZMIIAW2j7rQ1zHNlomp3QxDz2N8MAwdpc2RpZ2kZdXBw c83NthF4EglmWwg4zVb4c3BhS0/NLFjA/nubVS9CdWZmQQ8LZ9qOPExvd3d2OXK2I1GYbdh3CkfY LMuyPdQTAgoEb5eyLMuyCzQXEhDVsizLAw8JFHMfyD8WQlBFAABMAQLgAA91y0n+AQsBBwAAfFFA EAOQYbNu9g1KCxsEHgfrZku2M6AGKBAH8hJ4Awar2IOBQC7PeJDwAdc1kHVkhE8uNXQrdtmyyXvr ACDVC7ZR4OAuwccAm/u7d2HfI34nQAIb1IUAoFB9DdPlAAAAAAAAAJD/AAAAAAAAAAAAAAAAAGC+ AHBKAI2+AKD//1eDzf/rEJCQkJCQkIoGRogHRwHbdQeLHoPu/BHbcu24AQAAAAHbdQeLHoPu/BHb EcAB23PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/dHSJxQHbdQeLHoPu/BHbEckB23UHix6D 7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78Edtz5IPBAoH9APP//4PRAY0UL4P9/HYP igJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/pTP///16J97kNAQAAigdHLOg8AXf3gD8B dfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmNvgCQAACLBwnAdEWLXwSNhDDosQAAAfNQ g8cI/5ZgsgAAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V/5ZksgAACcB0B4kDg8ME69j/lmiyAABh 6ZSA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAMAAAAgAACADgAAAGAAAIAAAAAAAAAAAAAA AAAAAAEAAQAAADgAAIAAAAAAAAAAAAAAAAAAAAEACQQAAFAAAACowAAAKAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAKAAAIB4AACAAAAAAAAAAAAAAAAAAAABAAkEAACQAAAA1MEAABQAAAAAAAAA AAAAAAEAMACwkAAAKAAAABAAAAAgAAAAAQAEAAAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIAAAIAAAACAgACAAAAAgACAAICAAACAgIAAwMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP// /wAAAIiIiAAAAAAIh3d3eIAAAHj//4iHcAAAePeP//94AAB4/////3gAAHj3d3j/eAAAeP////94 AAB493d4/3gAAHj/////eAAAePd3j/94AAB4/////3gAAHj/////eAAAeH9/f394AACHc4eHh4AA AAezO3t3gAAAAAAAAIAAAPA/AADgBwAAwAcAAMADAADAAwAAwAMAAMADAADAAwAAwAMAAMADAADA AwAAwAMAAMADAADABwAA4AcAAP/fAADYkQAAAAABAAEAEBAQAAEABAAoAQAAAQAAAAAAAAAAAAAA AACQwgAAYMIAAAAAAAAAAAAAAAAAAJ3CAABwwgAAAAAAAAAAAAAAAAAAqsIAAHjCAAAAAAAAAAAA AAAAAAC1wgAAgMIAAAAAAAAAAAAAAAAAAMDCAACIwgAAAAAAAAAAAAAAAAAAAAAAAAAAAADKwgAA 2MIAAOjCAAAAAAAA9sIAAAAAAAAEwwAAAAAAAAzDAAAAAAAAcwAAgAAAAABLRVJORUwzMi5ETEwA QURWQVBJMzIuZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXUzJfMzIuZGxsAABMb2FkTGlicmFy eUEAAEdldFByb2NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVtc2V0AAB3 c3ByaW50ZkEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0011_58EA7CCA.B90965AE-- From majordomo@mil.doit.wisc.edu Tue Feb 10 23:58:49 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17347 for ; Tue, 10 Feb 2004 23:58:49 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AqmBJ-0003Y2-00 for ipfix-list@mil.doit.wisc.edu; Tue, 10 Feb 2004 22:41:01 -0600 Received: from bay3-f16.bay3.hotmail.com ([65.54.169.16] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AqmBI-0003Xo-00 for ipfix@net.doit.wisc.edu; Tue, 10 Feb 2004 22:41:01 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 10 Feb 2004 20:40:54 -0800 Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP; Wed, 11 Feb 2004 04:40:54 GMT X-Originating-IP: [67.169.184.134] X-Originating-Email: [inetpix@msn.com] X-Sender: inetpix@msn.com From: "Jeff Meyer" To: Thomas.Dietz@netlab.nec.de, ipfix@net.doit.wisc.edu Subject: Re: [ipfix] IPFIX-info Update Date: Tue, 10 Feb 2004 20:40:54 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Feb 2004 04:40:54.0971 (UTC) FILETIME=[3C3A38B0:01C3F059] Precedence: bulk Sender: majordomo listserver Thomas, Thanks for advancing this work! -- Jeff >From: Thomas Dietz >To: Jeff Meyer , ipfix@net.doit.wisc.edu >Subject: Re: [ipfix] IPFIX-info Update >Date: Tue, 10 Feb 2004 17:17:53 +0100 > >Hello, > >to follow up what Jeff does I elaborated Jeffs transformation scripts >a little bit further. Now there are 3 transformation scripts (xslt), >the schema for the info model (xsd) and the info model itself (xml). > >The transformation scripts do the following: > >postProcessInfoModel-0301.xsl (was info_post_process_03.xsl) > > loads the next two scripts and does the overall processing. > >schema2rfc2629-0300.xsl > > produces the sections or part of the sections "data types" and > "field properties" out of the info model schema >infomodelschema-0300.xsd. > >infomodel2rfc2629-0301.xsl (was infomodel_to_rfc2629.xsl) > > produces the section "field definitions" out of the info model > document infomodel-0300.xml. > >I attached again the preliminary info model schema and info model >document (infomodelschema-0300.xsd and infomodel.xml) but note that they >are far from complete. As Jeff already state we still wait for some >input and are working on the completion. > >I put a version number at the end of each file with the format xxyy >where xx is the draft version for which the files are intended and yy >is a revision number to keep track of revisions. You may keep this >scheme or just forget about it. It was just for my convenience. > >Regards, > >Thomas Dietz > >--On Montag, Februar 09, 2004 00:20:43 -0800 Jeff Meyer >wrote: > >>Hi, >> >> Thanks for the responses to the various [issue] items related to IPFIX. >> >> I am in the process of updating this draft to coincide with comments to >>date. >> >> One major change is related to the alternate formal defintion format >>specified by Juergen. Another change is trying to apply more automation >>to >>the construction of the RFC2629 compliant source for the info-model. In >>particular I've been developing XSL translation pages to post process the >>RFC2629 document and automatically fill in body areas which are formally >>defined. This is in contrast to some of the cut/paste work which was >>necessary in earlier revisions. >> >> Currently section 6 and appendix A are automatically populated from the >>common (non-normative) XML information model, based on Juergen's proposal. >> >> Juergen's proposal to also populate section 4 from the formal model >>also >>makes sense, but I haven't yet created this XSL mapping file. >> >> The expectation would be that the base RFC2629 compliant draft be >>written >>using special markup for the sections which are machine generated (e.g. >> or ) and the XSL would alter this >>document with the appropriate form of content), then churning the whole >>thing through the HTML/nroff style generator at Marshall Rose's site >>(http://xml.resource.org) would produce the submittable draft. >> >> The other area of change is the set of elements (fields) defined in the >>info model itself. I'm awaiting any updates from Stewart >>(http://ipfix.doit.wisc.edu/archive/2391.html) or others on updates to the >>base content of the info model. >> >> Attached are the two updated stylesheets for generating the full >>draft/RFC. >> >> I'll continue working on this myself, but if there are concrete >>contributions (e.g. Stylesheets or new Information Element content) that >>would help speed things up. >> >>Regards, >> >> Jeff Meyer >> >>P.S. I will not be able to go to Korea for the next IETF meeting. >> >>_________________________________________________________________ >>Check out the great features of the new MSN 9 Dial-up, with the MSN >>Dial-up >>Accelerator. http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/ > > > >-- >Thomas Dietz >Network Laboratories Phone: +49/(0)6221/90511-28 >NEC Europe Ltd. E-mail: Thomas.Dietz@netlab.nec.de >Kurfuersten-Anlage 36 >69115 Heidelberg, Germany ><< infomodel-0300.xml >> ><< infomodel2rfc2629-0301.xsl >> ><< infomodelschema-0300.xsd >> ><< postProcessInfoModel-0301.xsl >> ><< schema2rfc2629-0300.xsl >> _________________________________________________________________ Plan your next US getaway to one of the super destinations here. http://special.msn.com/local/hotdestinations.armx -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 12 19:32:18 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28179 for ; Thu, 12 Feb 2004 19:32:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ArQps-0005Tn-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 Feb 2004 18:05:36 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ArQpr-0005Th-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 12 Feb 2004 18:05:35 -0600 Received: from cisco.com (ams-clip-vpn-dhcp4374.cisco.com [10.61.81.21]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1D05V704634; Fri, 13 Feb 2004 01:05:31 +0100 (CET) Message-ID: <402C14CA.30407@cisco.com> Date: Fri, 13 Feb 2004 01:05:30 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] IPFIX protocol draft: list of issues Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, I will be posting a new version 03 of the protocol draft at the latest during the weekend. In the mean time, here is a list of issues that have been identified. 1. all the issues from the previous drafts. 2. issues from the mailing list. 3. issues from various discussions. That's the reasons why there are sometimes proposals from the authors. I hope I'm covering all of them. If not, feel free to update this list and assign a new number to your issue. When discussing one issue on the mailing list, please always insert the PROTO- in the Subject: it will ease everybody live. As always, let's try to discuss one issue at the time. The goal is not to try to solve all the issue before posting the new draft this weekend ;), but to discuss on the mailing list or at the next IETF meeting. Note that this list will be updated in the version 03 of the protocol draft. Issues in the Terminology section PROTO-1: Is flowset the right term to use? - leave as is - Record Set - Record Array - Record Collection - Record List PROTO-2: Some discrepancies between data types, field type and Information Element terminology. - field type (IPFIX-PROTO) conflicts with field ID (IPFIX-INFO) - suggestion: use field type instead of field Id in IPFIX-INFO - rename 'type' to 'data type' and 'info elements' to 'fields' in IPFIX-INFO PROTO-3: IP encapsulated packet - IP Traffic Flow definition speaks of IP packets - Metering Process definitions say: Input to the metering process are packets - We don't want to limit ourselves to IPv4 and IPv6 Issues in the Transport Protocol section PROTO-4: TCP and UDP are is not yet covered PROTO-5: Error recovery, for example what to do if a collector receives a message it can't decode. Per protocol issue, ie TCP reset the session because it's a stream protocol and can't recover. PROTO-6: Section 5.2.3.3, Association: What happens if the Exporter gets no response from any Collector? I think we should specify a (not-too-aggressive) retry algorithm. PROTO-7: Dropping data before export: What to do with sequence numbers? PROTO-8: Why having a stream per SID? PROTO-9: IPFIX message should have MTU size. PROTO-10: How to re-establish a lost connection? Procedure per transport protocol? Issues in the Failover section PROTO-11: (initial version required) Section needs to be written If we tackle reliability/failover a state diagram is needed. Issues in the Message Layout section PROTO-12: Do we need the IETF exclusive template flowset format? suggested solution: - reserve flowset ID 0 & 1 for compatibility with NFv9 - try to make flowset ID 2 & 3 definition fully compatible with NFv9 - add note that if you implement ID 2/3 correctly, you can also process ID 0/1. PROTO-13: How to distinguish IETF field IDs from vendor field IDs - Specify method for detecting the difference in section 8. - Add a note that there is a common ID space for for field types used in data templates and option templates - (Editorial) make clear that Section 8.2 also applies to option templates PROTO-14: Why do we need padding? Should we shift it to MAY? limit the size of the padding? Yes solution: - padding shorter than actual Record Length - fill with 0 - only at end of flowset - applies to all flowsets - padding is OPTIONAL (MAY) , not RECOMMENDED (SHOULD) Issues in the IPFIX Message Format section PROTO-15: Remove Reserved 2 octets in Vendor specific option template flowset and add padding at the end PROTO-16: relationship between several different scopes in one record PROTO-17: redefine scope values? - 1 System 2 IP interface 3 observation domain (SID) (preciously called line card) 4 reserved (previously used for cache) 5 template 6 metering process? 7 flow recording process? 8 exporting process? 9 observation point? PROTO-18: Can we have an optional length of 0 bytes for the scope section in the option template? PROTO-19: Do we really need different templates formats for flows and options? PROTO-20 Do we really need different record formats for flows and options? Issues in the Specific Reporting Requirement section PROTO-21: Do we need to define some mandatory content of the metering process statistics option template? - Maurizio suggested text on the mailing list PROTO-22: Exporter ID (ie IP address of exporter) Issues in the Export Packet "Export Time" Computation and Flow Record Time section PROTO-23: Finalize the time details Issues in the Linkage with the Information Model section PROTO-24: Section 11 "Linkage with the information model" must be completed with types used in [IPFIX-INFO] Issues in the Template Management section PROTO-25: The section 11 "Template Management" will have to updated according to the transport protocol. - For example, the point 2 of the section "Template Management". Remark: the template management will vary with TCP, SCTP, etc... Must have both sections updated: transport updated and template management sections (BTW, this is the same for the failover section). Issues in the IANA section PROTO-26: IANA considerations section to be updated: have a look at RFC 2434, which sets out guidelines for IANA Considerations. Also, searching the RFCs for 'IANA Considerations' brings up quite a few RFCs to look at as models. Issues - Miscellaneous PROTO-27: Need an example with the Vendor Specified Information Element PROTO-28: Packet Sampling. This is mentioned in both the Requirements I-D and the AS I-D. We need to decide how it should be covered in the IPFIX drafts. ACTION PROTO-29: number all the figures PROTO-30: Review the requirements draft to see what we miss, once it's an I-RFC Regards, Benoit. -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 12 20:12:12 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29731 for ; Thu, 12 Feb 2004 20:12:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ArRgc-0000Aw-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 Feb 2004 19:00:06 -0600 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ArRgb-0000Ar-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 12 Feb 2004 19:00:05 -0600 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 12 Feb 2004 17:08:36 +0000 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1D1031m028225; Thu, 12 Feb 2004 17:00:03 -0800 (PST) Received: from cisco.com ([10.32.15.71]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA17604; Thu, 12 Feb 2004 17:00:02 -0800 (PST) Message-ID: <402C2192.1010902@cisco.com> Date: Thu, 12 Feb 2004 17:00:02 -0800 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: PROTO-3: IP encapsulated packet [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> Content-Type: multipart/alternative; boundary="------------020406050406040301060303" Precedence: bulk Sender: majordomo listserver --------------020406050406040301060303 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Benoit, PROTO-3: IP encapsulated packet - IP Traffic Flow definition speaks of IP packets - Metering Process definitions say: Input to the metering process are packets - We don't want to limit ourselves to IPv4 and IPv6 The architecture spec clearly covers the encapsulated packets in the IP Traffic Flow Definition. Otherwise we are leaving out MPLS packets, tunnel packets from being able to be defined as flows. "A 'Flow' is a set of IP packets, *or encapsulated IP packets*, passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1. One or more header fields of the actual packet, e.g. destination IP address, or *fields in the packet's encapsulation header,* e.g. label for MPLS, tunnel end-points for IP-in-IP or fields in transport header (e.g. destination port number), or fields in application header field (e.g. RTP header fields [RFC1889]) 2. One or more properties of the packet itself (e.g. packet length) 3. One or more of fields derived from packet treatment (e.g. next hop IP address,AS number)" Is this clear enough to cover all the cases we want? I agree we have to change the Metering Process definition to include "The Metering Process generates Flow Records. Input to the process are IP packets or encapsulated IP packets observed at an Observation Point and packet treatment at the Observation Point, for example the selected output interface...." Thanks Ganesh --------------020406050406040301060303 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Benoit,

PROTO-3: IP encapsulated packet
   - IP Traffic Flow definition speaks of IP packets
   - Metering Process definitions say:      Input to the metering process are packets    - We don't want to limit ourselves to IPv4 and IPv6

The architecture spec clearly covers the encapsulated packets in the IP Traffic Flow Definition.
Otherwise we are leaving out MPLS packets, tunnel packets from being able to be defined
as flows.

       "A 'Flow' is a set of IP packets, or encapsulated IP packets,
       passing an Observation Point in the network during a certain time
       interval. All packets belonging to a particular Flow have a set
       of common properties. Each property is defined as the result of
       applying a function to the values of:

         1. One or more header fields of the actual packet, e.g.
            destination IP address, or fields in the packet's
            encapsulation header, e.g. label for MPLS, tunnel end-points
            for IP-in-IP or fields in transport header (e.g. destination
            port number), or fields in application header field (e.g.
            RTP header fields [RFC1889])
         2. One or more properties of the packet itself (e.g. packet
            length)
         3. One or more of fields derived from packet treatment (e.g.
            next hop IP address,AS number)"

Is this clear enough to cover all the cases we want?
I agree we have to change the Metering Process definition to
include
      "The Metering Process generates Flow Records. Input to the process
       are IP packets or encapsulated IP packets observed at an
       Observation Point and packet treatment at the Observation Point,
       for example the selected output interface...."


Thanks
Ganesh

--------------020406050406040301060303-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Thu Feb 12 20:17:47 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29898 for ; Thu, 12 Feb 2004 20:17:47 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ArRm7-0000Fd-00 for ipfix-list@mil.doit.wisc.edu; Thu, 12 Feb 2004 19:05:47 -0600 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ArRm6-0000FX-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 12 Feb 2004 19:05:46 -0600 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1D15h4U016104; Thu, 12 Feb 2004 17:05:44 -0800 (PST) Received: from cisco.com ([10.32.15.71]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA17616; Thu, 12 Feb 2004 17:05:43 -0800 (PST) Message-ID: <402C22E7.5000405@cisco.com> Date: Thu, 12 Feb 2004 17:05:43 -0800 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise CC: ipfix-protocol@net.doit.wisc.edu Subject: PROTO-1 [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit PROTO-1: Is flowset the right term to use? - leave as is - Record Set - Record Array - Record Collection - Record List This term is used for grouping IPFIX records with similar structure. I suggest we use "Record Group" or "Record Set" Thanks Ganesh -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Feb 13 05:02:41 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01379 for ; Fri, 13 Feb 2004 05:02:41 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ArZsS-0006pg-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 Feb 2004 03:44:52 -0600 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ArZsR-0006pW-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 13 Feb 2004 03:44:51 -0600 Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 13 Feb 2004 10:45:24 +0100 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1D9iML1021929; Fri, 13 Feb 2004 10:44:23 +0100 (MET) Received: from cisco.com (ams-clip-vpn-dhcp353.cisco.com [10.61.65.97]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA16093; Fri, 13 Feb 2004 09:44:41 GMT Message-ID: <402C9C89.1050200@cisco.com> Date: Fri, 13 Feb 2004 09:44:41 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Sadasivan CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-1 [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> <402C22E7.5000405@cisco.com> In-Reply-To: <402C22E7.5000405@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit How about Record batch? The only reason the records were collected together for export was that they were ready for export at a particular time. You are unlikely to get the same grouping at a later time. All the other terms imply some more systematic association. - Stewart Ganesh Sadasivan wrote: > PROTO-1: Is flowset the right term to use? > - leave as is > - Record Set > - Record Array > - Record Collection > - Record List > > This term is used for grouping IPFIX records with similar structure. > I suggest we use "Record Group" or "Record Set" > > Thanks > Ganesh > > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Feb 13 13:40:53 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24745 for ; Fri, 13 Feb 2004 13:40:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ArhuB-0006D8-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 Feb 2004 12:19:11 -0600 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ArhuA-0006D2-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 13 Feb 2004 12:19:10 -0600 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2004 10:27:49 +0000 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1DIJ74U013270; Fri, 13 Feb 2004 10:19:08 -0800 (PST) Received: from cisco.com ([10.32.15.71]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA18686; Fri, 13 Feb 2004 10:19:07 -0800 (PST) Message-ID: <402D151B.6090202@cisco.com> Date: Fri, 13 Feb 2004 10:19:07 -0800 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu CC: Ganesh Sadasivan , Benoit Claise Subject: [ipfix-protocol] Observation Domain References: <402C14CA.30407@cisco.com> <402C22E7.5000405@cisco.com> Content-Type: multipart/alternative; boundary="------------020600020605010906050003" Precedence: bulk Sender: majordomo listserver --------------020600020605010906050003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The current definition is: The set of Observation Points, which is the ./largest aggregatable set of Flow information at the Metering Proces/s is termed an Observation Domain. Each Observation Domain presents itself as a unique ID to the Collecting Process for identifying the IPFIX Messages it generates. For example, a router line card composed of several interfaces with each interface being an Observation Point. Every Observation Point is associated with an Observation Domain. The term "/largest aggregatable set of Flow information at the Metering Proces/s" does not seem to be correct. Reasons: 1. From the wording there is an inherent assumption of 1 metering process per Observation Domain (OD). For example each Obdervation point within an OD could have a separate metering process. 2. Metering Process itself is independent of the Observation Domain. For example: If a Metering Process to the entire IPFIX device (as its scope), which has multiple OD, then it breaks the above definition . Specifically say there are 2 linecards (each of them being an OD) in a router (IPFIX device). Say sampling is configured on all interface in LC1 and LC2, the scope of metering process spans the entire IPFIX device as compared to the OD. All that the Observation Domain defines is a unique way to identify with the collecting process in combination with the exporting process. I suggest we re-word the definition to the following: "The set of Observation Points, which is the largest aggregatable set of Flow information at the Exporting Process is termed an Observation Domain. Each Observation Domain presents itself as a unique ID to the Collecting Process for identifying the IPFIX Messages it generates. For example, a router line card composed of several interfaces with each interface being an Observation Point. Every Observation Point is associated with an Observation Domain." Please send your comments. Thanks Ganesh --------------020600020605010906050003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

The current definition is:
The set of Observation Points, which is the .largest aggregatable set   of Flow information at the Metering Process is termed an Observation   Domain. Each Observation Domain presents itself as a unique ID to   the Collecting Process for identifying the IPFIX Messages it   generates.   For example, a router line card composed of several interfaces with   each interface being an Observation Point.   Every Observation Point is associated with an Observation Domain.

The term "largest aggregatable set   of Flow information at the Metering Process" does not seem to be correct.
Reasons:
1. From the wording there is an inherent assumption of 1 metering process per Observation Domain (OD). For example
    each Obdervation point within an OD could have a separate metering process.
2. Metering Process itself is independent of the Observation Domain. For example: If a Metering Process to the entire
    IPFIX device (as its scope), which has multiple OD, then it breaks the above definition . Specifically say there are
    2 linecards (each of them being an OD) in a router (IPFIX device). Say sampling is configured on all interface in
    LC1 and LC2, the scope of metering process spans the entire IPFIX device as compared to the OD.

All that the Observation Domain defines is a unique way to identify with the collecting process in combination with the
exporting process. I suggest we re-word the definition to the following:
   

"The set of Observation Points, which is the largest aggregatable set of Flow information at the Exporting Process is termed an Observation Domain. Each Observation Domain presents itself as a unique ID to the Collecting Process for identifying the IPFIX Messages it generates. For example, a router line card composed of several interfaces with each interface being an Observation Point. Every Observation Point is associated with an Observation Domain."

Please send your comments.

Thanks
Ganesh


--------------020600020605010906050003-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Fri Feb 13 19:16:18 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16620 for ; Fri, 13 Feb 2004 19:16:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1ArnGW-0005R9-00 for ipfix-list@mil.doit.wisc.edu; Fri, 13 Feb 2004 18:02:36 -0600 Received: from bay3-f11.bay3.hotmail.com ([65.54.169.11] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1ArnGV-0005R4-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 13 Feb 2004 18:02:35 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 13 Feb 2004 16:02:35 -0800 Received: from 216.113.168.128 by by3fd.bay3.hotmail.msn.com with HTTP; Sat, 14 Feb 2004 00:02:34 GMT X-Originating-IP: [216.113.168.128] X-Originating-Email: [inetpix@msn.com] X-Sender: inetpix@msn.com From: "Jeff Meyer" To: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu Subject: RE: [ipfix-protocol] IPFIX protocol draft: list of issues Date: Fri, 13 Feb 2004 16:02:34 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 14 Feb 2004 00:02:35.0051 (UTC) FILETIME=[D989E7B0:01C3F28D] Precedence: bulk Sender: majordomo listserver Benoit, Regarding [Proto-2] I'd recommend Field Id over Field Type. The word "type" seems overloaded to me, does type refer to unsigned int, time, etc. Or does it refer a specific field definition (via a numeric identifier). From its usage it would seem that this portion of the protocol message is holding an identifier, not a type. -- Jeff >From: Benoit Claise >To: ipfix-protocol@net.doit.wisc.edu >Subject: [ipfix-protocol] IPFIX protocol draft: list of issues >Date: Fri, 13 Feb 2004 01:05:30 +0100 > >Dear all, > >I will be posting a new version 03 of the protocol draft at the latest >during the weekend. >In the mean time, here is a list of issues that have been identified. > 1. all the issues from the previous drafts. > 2. issues from the mailing list. > 3. issues from various discussions. That's the reasons why there are >sometimes proposals from the authors. >I hope I'm covering all of them. If not, feel free to update this list and >assign a new number to your issue. > >When discussing one issue on the mailing list, please always insert the >PROTO- in the Subject: it will ease everybody live. >As always, let's try to discuss one issue at the time. > >The goal is not to try to solve all the issue before posting the new draft >this weekend ;), but to discuss on the mailing list or at the next IETF >meeting. >Note that this list will be updated in the version 03 of the protocol >draft. > > > >Issues in the Terminology section > >PROTO-1: Is flowset the right term to use? > - leave as is > - Record Set > - Record Array > - Record Collection > - Record List >PROTO-2: Some discrepancies between data types, field type and Information > Element terminology. > - field type (IPFIX-PROTO) conflicts with field ID (IPFIX-INFO) > - suggestion: use field type instead of field Id in IPFIX-INFO > - rename 'type' to 'data type' and 'info elements' to 'fields' > in IPFIX-INFO >PROTO-3: IP encapsulated packet > - IP Traffic Flow definition speaks of IP packets > - Metering Process definitions say: Input to the metering process >are packets - We don't want to limit ourselves to IPv4 and IPv6 > >Issues in the Transport Protocol section > >PROTO-4: TCP and UDP are is not yet covered >PROTO-5: Error recovery, for example what to do if a collector receives a >message it > can't decode. > Per protocol issue, ie TCP reset the session because it's a stream >protocol > and can't recover. >PROTO-6: Section 5.2.3.3, Association: What happens if the Exporter gets no >response > from any Collector? > I think we should specify a (not-too-aggressive) retry algorithm. >PROTO-7: Dropping data before export: What to do with sequence numbers? >PROTO-8: Why having a stream per SID? >PROTO-9: IPFIX message should have MTU size. >PROTO-10: How to re-establish a lost connection? Procedure per transport >protocol? > >Issues in the Failover section > >PROTO-11: (initial version required) Section needs to be written > If we tackle reliability/failover a state diagram is needed. > >Issues in the Message Layout section > >PROTO-12: Do we need the IETF exclusive template flowset format? > suggested solution: > - reserve flowset ID 0 & 1 for compatibility with NFv9 > - try to make flowset ID 2 & 3 definition fully compatible with NFv9 > - add note that if you implement ID 2/3 correctly, you can also process >ID 0/1. >PROTO-13: How to distinguish IETF field IDs from vendor field IDs > - Specify method for detecting the difference in section 8. > - Add a note that there is a common ID space for for field types used >in > data templates and option templates > - (Editorial) make clear that Section 8.2 also applies to option >templates >PROTO-14: Why do we need padding? Should we shift it to MAY? > limit the size of the padding? Yes > solution: > - padding shorter than actual Record Length > - fill with 0 > - only at end of flowset > - applies to all flowsets > - padding is OPTIONAL (MAY) , not RECOMMENDED (SHOULD) > >Issues in the IPFIX Message Format section > >PROTO-15: Remove Reserved 2 octets in Vendor specific option template >flowset > and add padding at the end >PROTO-16: relationship between several different scopes in one record >PROTO-17: redefine scope values? > - 1 System > 2 IP interface > 3 observation domain (SID) (preciously called line card) > 4 reserved (previously used for cache) > 5 template > 6 metering process? > 7 flow recording process? > 8 exporting process? > 9 observation point? >PROTO-18: Can we have an optional length of 0 bytes for the scope section > in the option template? >PROTO-19: Do we really need different templates formats for flows and >options? >PROTO-20 Do we really need different record formats for flows and options? > >Issues in the Specific Reporting Requirement section > >PROTO-21: Do we need to define some mandatory content of the metering >process > statistics option template? > - Maurizio suggested text on the mailing list >PROTO-22: Exporter ID (ie IP address of exporter) > >Issues in the Export Packet "Export Time" Computation and Flow Record Time >section > >PROTO-23: Finalize the time details > >Issues in the Linkage with the Information Model section > >PROTO-24: Section 11 "Linkage with the information model" must be completed >with > types used in [IPFIX-INFO] > >Issues in the Template Management section > >PROTO-25: The section 11 "Template Management" will have to updated > according to the transport protocol. > - For example, the point 2 of the section "Template Management". > Remark: the template management will vary with TCP, SCTP, etc... > Must have both sections updated: transport updated and template > management sections (BTW, this is the same for the failover > section). > Issues in the IANA section > >PROTO-26: IANA considerations section to be updated: have a look at RFC >2434, > which sets out guidelines for IANA Considerations. > Also, searching the RFCs for 'IANA Considerations' brings > up quite a few RFCs to look at as models. > >Issues - Miscellaneous > >PROTO-27: Need an example with the Vendor Specified Information Element >PROTO-28: Packet Sampling. This is mentioned in both the Requirements I-D > and the AS I-D. We need to decide how it should be covered in the > IPFIX drafts. > > >ACTION > >PROTO-29: number all the figures >PROTO-30: Review the requirements draft to see what we miss, once it's an >I-RFC > > >Regards, Benoit. > > > > > > >-- >Help mailto:majordomo@net.doit.wisc.edu and say "help" in message >body >Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >"unsubscribe ipfix" in message body >Archive http://ipfix.doit.wisc.edu/archive/ _________________________________________________________________ Keep up with high-tech trends here at "Hook'd on Technology." http://special.msn.com/msnbc/hookedontech.armx -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Sun Feb 15 16:55:27 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26172 for ; Sun, 15 Feb 2004 16:55:26 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AsTsG-0006lM-00 for ipfix-list@mil.doit.wisc.edu; Sun, 15 Feb 2004 15:32:24 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AsTsE-0006lG-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 15 Feb 2004 15:32:23 -0600 Received: from cisco.com (ams-clip-vpn-dhcp97.cisco.com [10.61.64.97]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1FLWJ703713; Sun, 15 Feb 2004 22:32:19 +0100 (CET) Message-ID: <402FE563.4060601@cisco.com> Date: Sun, 15 Feb 2004 22:32:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] draft-ietf-ipfix-protocol-03.txt Content-Type: multipart/alternative; boundary="------------050505000906000100030609" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------050505000906000100030609 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here is the changes in the new version of the IPFIX protocol draft, posted today. _New sections: _- Flow Expiration section is now synchronized with [IPFIX-ARCH]. The text has been reorganized. 4.0 Criteria for flow expiration and Export 4.1 Flow Expiration 4.2 Flow Export - STRUCTURE CHANGED FROM: 8. IPFIX Message Format........................................18 8.1 Header Format.............................................18 8.2 Field Type Format.........................................19 8.3 Template FlowSet Format...................................20 8.3.1 IETF Exclusive Template FlowSet Format.................20 8.3.2 Vendor Specified Template FlowSet Format...............22 8.4 Data FlowSet Format.......................................24 9. Options.....................................................25 9.1 Options Template FlowSet Format...........................25 9.1.1 IETF Exclusive Options Template FlowSet Format.........25 9.1.2 Vendor Specified Options Template FlowSet Format.......27 9.2 Options Data Record Format................................29 9.3 Specific IPFIX Options Templates..........................30 9.3.1 The Metering Process Statistics Option Template........31 TO: 8. IPFIX Message Format........................................18 8.1 Header Format.............................................18 8.2 Field Type Format.........................................19 8.3 Template FlowSet Format...................................20 8.3.1 IETF Exclusive Template FlowSet Format.................20 8.3.2 Vendor Specified Template FlowSet Format...............22 8.4 Data FlowSet Format.......................................24 8.5 Options Template FlowSet Format...........................25 8.5.1 IETF Exclusive Options Template FlowSet Format......25 8.5.2 Vendor Specified Options Template FlowSet Format....27 8.5.3 Options Data Record Format..........................29 9. Specific Reporting Requirements.............................30 9.1 The Metering Process Statistics Option Template..........31 - section 9.3 "specific IPFIX Options Templates" is now a new section called "Specific Reporting Requirements" Comment from Juergen. Justification: for the first time in the protocol draft, we speak about the specific data types requiring an (option) template. And not anymore about the export format - The transport section contains a new section 5.1 with the MAY, SHOULD, MUST requirements regarding the transport protocols. This is a cut/paste from http://ipfix.doit.wisc.edu/archive/2377.html with some extra references. - Security section: new TLS subsection _Updates _- Both [IPFIX-ARCH] and [IPFIX-PROTO] terminology sections are now in sync. * IP Traffic Flow: They were 2 different definitions in [IPFIX-ARCH] and [IPFIX-PROTO] The definition from [IPFIX-PROTO] is now used in both drafts. Nevertheless, the nice examples from the definition in [IPFIX-ARCH] are cut and pasted in a new section from [IPFIX-ARCH] * Metering Process They were 2 different definitions in [IPFIX-ARCH] and [IPFIX-PROTO] The paragraph 3 from the definition in [IPFIX-PROTO] is moved to a new section in [IPFIX-ARCH] while only paragraph 1 and 2 are kept * Flow Data Record. Remove the reference to Flow Record. * Flow Recording Process Updated to remove the upper case condition (ex: MAY) * Observation Domain changed according to http://ipfix.doit.wisc.edu/archive/2435.html * Observation Point/Observation Domain Instead of having "An Observation Domain is associated with every Observation Point." in the Observation Point definition, we now have "Every Observation Point is associated with an Observation Domain" in the Observation Domain definition. This avoids a forward reference in the terminology. * IPFIX Message definition changed to An IPFIX Message is a message originating at the Exporting Process that carries the records of this Exporting Process and whose destination is the Collecting Process. Justification: an IPFIX Message might not always contain flow record. Comment from Juergen - Header modified, as described in http://ipfix.doit.wisc.edu/archive/2362.html - The abstract has been updated. The 2 main issues were: 1. it doesn't use the keyword "specifies" (IESG feedback on the NetFlow version 9 draft) 2. it should start with "This document" (IESG feedback on the NetFlow version 9 draft) - The introduction contains some new text. Text proposed by Ganesh. - Security section. Simplified throught to reduce detail that added little value. Corrected a couple of technical errors. This section required a new definition: the IPFIX Node, now added in the security section. Text from Stewart and Sebastian. - There was no MAY, SHOULD, MUST in section 12 "Variable Length Data Type" The IPFIX template mechanism is optimized for fixed length Information Elements [IPFIX-INFO]. Where an Information Element has a variable length the following mechanism MUST used to carry the length information. - Change the IPFIX Header "Unix Secs" to "Export Time" as the name was confusing. Comment from several persons. - The Option Data Record Format can have multiple scopes. Changed to 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowSet ID = Template ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 1 - Scope 1 Value | Record 1 - Scope 2 Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |Record 1 - Option Field 1 Value| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Record 1 - Option Field 2 Value| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 2 - Scope 1 Value | Record 2 - Scope 2 Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |Record 2 - Option Field 1 Value| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Record 2 - Option Field 2 Value| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record 3 - Scope 1 Value | Record 3 - Scope 2 Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |Record 3 - Option Field 1 Value| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Record 3 - Option Field 2 Value| ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ _Editorial changes _- Changed the may, should and must of the SCTP section to upper cases. - terminology summary table clarified. Comment from Ganesh - In Section 17.5, Data FlowSet with Options Data Records Example,there was an error: According to IPFIX Protocol Specification the Length Field should be 20 rather than 14. - In Section 17, The message header's Version Number Field changed to be 0x000a instead of 0x0009 - 9.1.1 section, "Options Template Record" modified to "Options Data Record". Option 1 Field Type A numeric value that represents the type of field that would appear in the Options Template Record. Refer to [IPFIX-INFO]. - References updated with the new draft versions - Added "Note that not all Field Values do necessarily have a length of 16 bit. " at the bottom of the figure in section 8.4 - Sequence Number update: removed "be cumulative" - Section 4.1, clarification the metering process behaviour in case the inactivity timeout is set to 0. - "The Exporter MUST code all binary integers of the Message Header and the different FlowSets in network byte order (also known as the big-endian byte ordering)." Added the Message Header As always, your feedback is welcome. The first sections "open issues" and "action items" have been updated and numbered. Please correct me if I missed some. Don't forget to also propose some new text when you address an issue ;) To get the draft right now (this is a busy week for the drafts admin.), follow the procedure below To get these files, please do the following... 1. With a Netscape or Internet Explorer web browser open the following URL: http://www.cisco.com/pcgi-bin/specialaccess.cgi 2. Enter all your details and at the 'Special Access Code' prompt, enter in HFYYFPNH 3. Click on the 'Submit' button. This will bring you to a web page listing your files for pickup. 4. Select each file listed. Each selection will take you to the Software Download web page; click on any Regards, Benoit. --------------050505000906000100030609 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

Here is the changes in the new version of the IPFIX protocol draft, posted today.

New sections:

- Flow Expiration section is now synchronized with [IPFIX-ARCH]. The text has been reorganized.
    4.0 Criteria for flow expiration and Export
    4.1 Flow Expiration
    4.2 Flow Export
- STRUCTURE CHANGED FROM:
8. IPFIX Message Format........................................18
 8.1 Header Format.............................................18
 8.2 Field Type Format.........................................19
 8.3 Template FlowSet Format...................................20
 8.3.1 IETF Exclusive Template FlowSet Format.................20
 8.3.2 Vendor Specified Template FlowSet Format...............22
 8.4 Data FlowSet Format.......................................24
 9. Options.....................................................25
 9.1 Options Template FlowSet Format...........................25
 9.1.1 IETF Exclusive Options Template FlowSet Format.........25
 9.1.2 Vendor Specified Options Template FlowSet Format.......27
 9.2 Options Data Record Format................................29
 9.3 Specific IPFIX Options Templates..........................30
 9.3.1 The Metering Process Statistics Option Template........31
    TO:
8. IPFIX Message Format........................................18
 8.1 Header Format.............................................18
 8.2 Field Type Format.........................................19
 8.3 Template FlowSet Format...................................20
 8.3.1 IETF Exclusive Template FlowSet Format.................20
 8.3.2 Vendor Specified Template FlowSet Format...............22
 8.4 Data FlowSet Format.......................................24
 8.5 Options Template FlowSet Format...........................25
 8.5.1 IETF Exclusive Options Template FlowSet Format......25
 8.5.2 Vendor Specified Options Template FlowSet Format....27
 8.5.3 Options Data Record Format..........................29
 9. Specific Reporting Requirements.............................30
 9.1 The Metering Process Statistics Option Template..........31
- section 9.3 "specific IPFIX Options Templates" is now a new section called "Specific Reporting Requirements"
  Comment from Juergen.
  Justification: for the first time in the protocol draft, we speak about the specific data types requiring an (option) template. And not anymore about the export format
- The transport section contains a new section 5.1 with the MAY, SHOULD, MUST requirements regarding the transport protocols.  This is a cut/paste from http://ipfix.doit.wisc.edu/archive/2377.html with some extra references.
- Security section: new TLS subsection


Updates

- Both [IPFIX-ARCH] and [IPFIX-PROTO] terminology sections are now in sync.

    * IP Traffic Flow:
        They were 2 different definitions in [IPFIX-ARCH] and [IPFIX-PROTO]
        The definition from [IPFIX-PROTO] is now used in both drafts. Nevertheless, the nice examples from the definition in [IPFIX-ARCH] are cut and pasted in a new section from [IPFIX-ARCH]
    * Metering Process
        They were 2 different definitions in [IPFIX-ARCH] and [IPFIX-PROTO]
        The paragraph 3 from the definition in [IPFIX-PROTO] is moved to a new section in [IPFIX-ARCH] while only paragraph 1 and 2 are kept
    * Flow Data Record. Remove the reference to Flow Record.
    * Flow Recording Process
       Updated to remove the upper case condition (ex: MAY)
    * Observation Domain
        changed according to http://ipfix.doit.wisc.edu/archive/2435.html
    * Observation Point/Observation Domain
       Instead of having "An Observation Domain is associated with every Observation Point." in the Observation Point definition, we now have "Every Observation  Point is associated with an Observation Domain" in the Observation Domain definition. This avoids a forward reference in the terminology.
    * IPFIX Message definition changed to
    An IPFIX Message is a message originating at the Exporting Process that carries the records of this Exporting Process and whose destination is the Collecting Process.
    Justification: an IPFIX Message might not always contain flow record. Comment from Juergen
- Header modified, as described in http://ipfix.doit.wisc.edu/archive/2362.html
- The abstract has been updated. The 2 main issues were:
     1. it doesn't use the keyword "specifies" (IESG feedback on the NetFlow version 9 draft)
     2. it should start with "This document" (IESG feedback on the NetFlow version 9 draft)
- The introduction contains some new text. Text proposed by Ganesh.
- Security section.
  Simplified throught to reduce detail that added little value.
  Corrected a couple of technical errors.
  This section required a new definition: the IPFIX Node, now added in the security section.
  Text from Stewart and Sebastian.
- There was no MAY, SHOULD, MUST in section 12 "Variable Length Data Type"
The IPFIX template mechanism is optimized for fixed length Information Elements [IPFIX-INFO]. Where an Information Element has a variable length the following mechanism MUST used to carry the length information.
- Change the IPFIX Header "Unix Secs" to "Export Time" as the name was confusing.
Comment from several persons.
- The Option Data Record Format can have multiple scopes. Changed to

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    FlowSet ID = Template ID   |          Length               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 1 - Scope 1 Value    |   Record 1 - Scope 2 Value    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ...              |Record 1 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 1 - Option Field 2 Value|             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 2 - Scope 1 Value    |   Record 2 - Scope 2 Value    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ...              |Record 2 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 2 - Option Field 2 Value|             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Record 3 - Scope 1 Value    |   Record 3 - Scope 2 Value    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ...              |Record 3 - Option Field 1 Value|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Record 3 - Option Field 2 Value|             ...               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              ...              |            Padding            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Editorial changes

- Changed the may, should and must of the SCTP section to upper cases.
- terminology summary table clarified. Comment from Ganesh
- In Section 17.5, Data FlowSet with Options Data Records Example,there was an error: According to IPFIX Protocol Specification the Length Field should be 20 rather than 14.
- In Section 17, The message header's Version Number Field changed to be 0x000a instead of 0x0009
- 9.1.1 section, "Options Template Record" modified to "Options Data Record".
Option 1 Field Type A numeric value that represents the type of field that would
appear in the Options Template Record. Refer to [IPFIX-INFO].
- References updated with the new draft versions
- Added "Note that not all Field Values do necessarily have a length of 16 bit. " at the bottom of the figure in section 8.4
- Sequence Number update: removed "be cumulative"
- Section 4.1, clarification the metering process behaviour in case the inactivity timeout is set to 0.
- "The Exporter MUST code all binary integers of the Message Header and the different FlowSets in network byte order (also known as the big-endian byte ordering)." Added the Message Header


As always, your feedback is welcome. The first sections "open issues" and "action items" have been updated and numbered. Please correct me if I missed some.
Don't forget to also propose some new text when you address an issue ;)

To get the draft right now (this is a busy week for the drafts admin.), follow the procedure below

 
To get these files, please do the following...

   1. With a Netscape or Internet Explorer web browser open
      the following URL:
        http://www.cisco.com/pcgi-bin/specialaccess.cgi
   2. Enter all your details and at the 'Special Access Code' prompt, 
      enter in HFYYFPNH
   3. Click on the 'Submit' button.  This will bring you
      to a web page listing your files for pickup.
   4. Select each file listed.  Each selection will take
      you to the Software Download web page; click on any
Regards, Benoit.







--------------050505000906000100030609-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 16 05:14:49 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09464 for ; Mon, 16 Feb 2004 05:14:48 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AsfLi-0000ez-00 for ipfix-list@mil.doit.wisc.edu; Mon, 16 Feb 2004 03:47:34 -0600 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AsfLh-0000eu-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 16 Feb 2004 03:47:33 -0600 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2004 01:47:44 -0800 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1G9l3hQ012792; Mon, 16 Feb 2004 10:47:03 +0100 (MET) Received: from cisco.com (rtp-vpn2-22.cisco.com [10.82.240.22]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA13506; Mon, 16 Feb 2004 09:47:25 GMT Message-ID: <403091AC.2000300@cisco.com> Date: Mon, 16 Feb 2004 09:47:24 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Meyer CC: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] IPFIX protocol draft: list of issues References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff Meyer wrote: > Benoit, > > Regarding [Proto-2] I'd recommend Field Id over Field Type. The word > "type" seems overloaded to me, does type refer to unsigned int, time, > etc. Or does it refer a specific field definition (via a numeric > identifier). > >> From its usage it would seem that this portion of the protocol message is > > holding an identifier, not a type. > > -- Jeff > Isn't it holding a type identifier? It's a codepoint that identifies the type of the field that will be contained in the corresponding field in the data message. That would suggest that the name should be field type identifier (FTI) or perhaps field type codepoint (FTC). - Stewart -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 16 05:15:46 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09512 for ; Mon, 16 Feb 2004 05:15:46 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AsfRK-0000mZ-00 for ipfix-list@mil.doit.wisc.edu; Mon, 16 Feb 2004 03:53:22 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AsfRJ-0000mI-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 16 Feb 2004 03:53:21 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i1G9rEG04980; Mon, 16 Feb 2004 10:53:14 +0100 (MET) Message-ID: <40309254.7030501@fokus.fraunhofer.de> Date: Mon, 16 Feb 2004 10:50:12 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ganesh Sadasivan CC: ipfix-protocol@net.doit.wisc.edu, Benoit Claise Subject: Re: [ipfix-protocol] Observation Domain References: <402C14CA.30407@cisco.com> <402C22E7.5000405@cisco.com> <402D151B.6090202@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Ganesh, your example makes sense to me. But then the observation domain would no longer be the "_largest_ aggregatable set" right? Because if there is one metering process (followed by exporting process) it could aggregate the information from different ODs. Hence it is a set but not necessarely the largest aggregatable!? Cheers, Sebastian Ganesh Sadasivan wrote: > > > The current definition is: > The set of Observation Points, which is the .largest aggregatable set > of Flow information at the Metering Process is termed an Observation > Domain. Each Observation Domain presents itself as a unique ID to the > Collecting Process for identifying the IPFIX Messages it generates. > For example, a router line card composed of several interfaces with > each interface being an Observation Point. Every Observation Point is > associated with an Observation Domain. > > The term "largest aggregatable set of Flow information at the Metering > Process" does not seem to be correct. > Reasons: > 1. From the wording there is an inherent assumption of 1 metering > process per Observation Domain (OD). For example > each Obdervation point within an OD could have a separate metering > process. > 2. Metering Process itself is independent of the Observation Domain. For > example: If a Metering Process to the entire > IPFIX device (as its scope), which has multiple OD, then it breaks > the above definition . Specifically say there are > 2 linecards (each of them being an OD) in a router (IPFIX device). > Say sampling is configured on all interface in > LC1 and LC2, the scope of metering process spans the entire IPFIX > device as compared to the OD. > > All that the Observation Domain defines is a unique way to identify with > the collecting process in combination with the > exporting process. I suggest we re-word the definition to the following: > > > "The set of Observation Points, which is the largest aggregatable set of > Flow information at the Exporting Process is termed an Observation > Domain. Each Observation Domain presents itself as a unique ID to the > Collecting Process for identifying the IPFIX Messages it generates. For > example, a router line card composed of several interfaces with each > interface being an Observation Point. Every Observation Point is > associated with an Observation Domain." > > Please send your comments. > > Thanks > Ganesh > > -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 16 09:33:01 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20122 for ; Mon, 16 Feb 2004 09:33:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Asje3-0006Ec-00 for ipfix-list@mil.doit.wisc.edu; Mon, 16 Feb 2004 08:22:47 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Asje2-0006EV-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 16 Feb 2004 08:22:46 -0600 Received: from cisco.com (dhcp-peg3-vl30-144-254-7-145.cisco.com [144.254.7.145]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1GEMg729475; Mon, 16 Feb 2004 15:22:42 +0100 (CET) Message-ID: <4030D232.6090505@cisco.com> Date: Mon, 16 Feb 2004 15:22:42 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stbryant@cisco.com CC: Ganesh Sadasivan , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-1 [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> <402C22E7.5000405@cisco.com> <402C9C89.1050200@cisco.com> In-Reply-To: <402C9C89.1050200@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi, I can agree that the term FlowSet is maybe not the best one. But I'm not convinced by any of the new proposal: Record Set, Record Array, Record Collection, Record List, Record Batch, Record Group, Record Set For example, a (Option) Template FlowSet will not contain any record, only a template. For example, a specific FlowSet might be used in the future for something else: Exporter ID? Synchronization? etc... For example, ... Being unable to find an appropriate/better word, I would stick to the old one. But, OK, my view is maybe a little bit biased as I'm used to this FlowSet term ;) as this is the one used in NetFlow version 9. Regards, Benoit. > How about Record batch? > > The only reason the records were collected together for > export was that they were ready for export at a particular > time. You are unlikely to get the same grouping at a later > time. All the other terms imply some more systematic > association. > > - Stewart > > > Ganesh Sadasivan wrote: > >> PROTO-1: Is flowset the right term to use? >> - leave as is >> - Record Set >> - Record Array >> - Record Collection >> - Record List >> >> This term is used for grouping IPFIX records with similar structure. >> I suggest we use "Record Group" or "Record Set" >> >> Thanks >> Ganesh >> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 16 13:21:59 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10247 for ; Mon, 16 Feb 2004 13:21:59 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AsnDn-0001Zd-00 for ipfix-list@mil.doit.wisc.edu; Mon, 16 Feb 2004 12:11:55 -0600 Received: from bay3-f15.bay3.hotmail.com ([65.54.169.15] helo=hotmail.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AsnDm-0001ZY-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 16 Feb 2004 12:11:54 -0600 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Feb 2004 10:11:53 -0800 Received: from 67.169.184.134 by by3fd.bay3.hotmail.msn.com with HTTP; Mon, 16 Feb 2004 18:11:52 GMT X-Originating-IP: [67.169.184.134] X-Originating-Email: [inetpix@msn.com] X-Sender: inetpix@msn.com From: "Jeff Meyer" To: stbryant@cisco.com Cc: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] IPFIX protocol draft: list of issues Date: Mon, 16 Feb 2004 10:11:52 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 16 Feb 2004 18:11:53.0209 (UTC) FILETIME=[5ADCDE90:01C3F4B8] Precedence: bulk Sender: majordomo listserver Hi, If I have a declaration of the form: int var1; int var2; char *var3; Is "var1" a type? Or is the type of "var1" int? var1 and var2 are "identifiers" in my opinion which distinguish among two variables (fields) of the same type. I believe the templating structure is doing the same thing as the example above, but using numeric id's versus string id's. The IPFIX protocol authors chose not to include type information, instead opting to include information about the length of the encoding for a field of a given type (e.g. int, short, dateTime, etc.). So there are (unfortunately) no provisions to hold type information in IPFIX-proto. E.g. the logical equivalent in ipfix-proto templating model to the above would be: length (4) fieldId(1); length (4) fieldId(2); length(VARIABLELEN) fieldId(3) Calling these information element ids would be most accurate, but the term "field" seems heavily used and is equivalent. Calling these identifiers "types" seems odd to me. -- Jeff >From: Stewart Bryant >Reply-To: stbryant@cisco.com >To: Jeff Meyer >CC: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu >Subject: Re: [ipfix-protocol] IPFIX protocol draft: list of issues >Date: Mon, 16 Feb 2004 09:47:24 +0000 > > > >Jeff Meyer wrote: > >>Benoit, >> >> Regarding [Proto-2] I'd recommend Field Id over Field Type. The word >>"type" seems overloaded to me, does type refer to unsigned int, time, etc. >> Or does it refer a specific field definition (via a numeric identifier). >> >>>From its usage it would seem that this portion of the protocol message is >> >>holding an identifier, not a type. >> >>-- Jeff >> > >Isn't it holding a type identifier? > >It's a codepoint that identifies the type of the field that will be >contained in the corresponding field in the data message. > >That would suggest that the name should be field type identifier (FTI) >or perhaps field type codepoint (FTC). > >- Stewart > > > _________________________________________________________________ Click here for a FREE online computer virus scan from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 16 22:54:41 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24538 for ; Mon, 16 Feb 2004 22:54:40 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Asvys-00033i-00 for ipfix-list@mil.doit.wisc.edu; Mon, 16 Feb 2004 21:33:06 -0600 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Asvyr-00033c-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 16 Feb 2004 21:33:05 -0600 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2004 19:42:22 +0000 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1H3Wx1m006447; Mon, 16 Feb 2004 19:33:00 -0800 (PST) Received: from cisco.com (sjc-vpn4-770.cisco.com [10.21.83.1]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA22282; Mon, 16 Feb 2004 19:32:59 -0800 (PST) Message-ID: <40318B6B.9080400@cisco.com> Date: Mon, 16 Feb 2004 19:32:59 -0800 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sebastian Zander CC: ipfix-protocol@net.doit.wisc.edu, Benoit Claise Subject: Re: [ipfix-protocol] Observation Domain References: <402C14CA.30407@cisco.com> <402C22E7.5000405@cisco.com> <402D151B.6090202@cisco.com> <40309254.7030501@fokus.fraunhofer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit You mean " A set of Observation Points that present a a unique ID to the Collecting Process for identifying the IPFIX Messages it generates is called an Observation Domain" . I would agree with this definition. Thanks Ganesh Sebastian Zander wrote: > Hi Ganesh, > > your example makes sense to me. But then the observation domain would > no longer be the "_largest_ aggregatable set" right? Because if there is > one metering process (followed by exporting process) it could aggregate > the information from different ODs. Hence it is a set but not necessarely > the largest aggregatable!? > > Cheers, > > Sebastian > > Ganesh Sadasivan wrote: > >> >> >> The current definition is: >> The set of Observation Points, which is the .largest aggregatable >> set of Flow information at the Metering Process is termed an >> Observation Domain. Each Observation Domain presents itself as a >> unique ID to the Collecting Process for identifying the IPFIX >> Messages it generates. For example, a router line card composed >> of several interfaces with each interface being an Observation >> Point. Every Observation Point is associated with an Observation >> Domain. >> >> The term "largest aggregatable set of Flow information at the >> Metering Process" does not seem to be correct. >> Reasons: >> 1. From the wording there is an inherent assumption of 1 metering >> process per Observation Domain (OD). For example >> each Obdervation point within an OD could have a separate >> metering process. >> 2. Metering Process itself is independent of the Observation Domain. >> For example: If a Metering Process to the entire >> IPFIX device (as its scope), which has multiple OD, then it >> breaks the above definition . Specifically say there are >> 2 linecards (each of them being an OD) in a router (IPFIX >> device). Say sampling is configured on all interface in >> LC1 and LC2, the scope of metering process spans the entire IPFIX >> device as compared to the OD. >> >> All that the Observation Domain defines is a unique way to identify >> with the collecting process in combination with the >> exporting process. I suggest we re-word the definition to the following: >> >> "The set of Observation Points, which is the largest aggregatable set >> of Flow information at the Exporting Process is termed an Observation >> Domain. Each Observation Domain presents itself as a unique ID to the >> Collecting Process for identifying the IPFIX Messages it generates. >> For example, a router line card composed of several interfaces with >> each interface being an Observation Point. Every Observation Point is >> associated with an Observation Domain." >> >> Please send your comments. >> >> Thanks >> Ganesh >> >> > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Mon Feb 16 23:20:21 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25413 for ; Mon, 16 Feb 2004 23:20:20 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AswPy-0004Rp-00 for ipfix-list@mil.doit.wisc.edu; Mon, 16 Feb 2004 22:01:06 -0600 Received: from mailhost2.auckland.ac.nz ([130.216.191.4]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AswPx-0004Rj-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 16 Feb 2004 22:01:05 -0600 Received: from mailhost.auckland.ac.nz (dns4.auckland.ac.nz [130.216.1.12]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id i1H40mnn011489; Tue, 17 Feb 2004 17:00:48 +1300 (NZDT) Received: from localhost (mailhostb.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2D3FD7ACA7; Tue, 17 Feb 2004 17:00:48 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30947-09; Tue, 17 Feb 2004 17:00:42 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D11297ACAA; Tue, 17 Feb 2004 17:00:41 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id i1H3tJV30251; Tue, 17 Feb 2004 16:55:19 +1300 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Tue, 17 Feb 2004 16:55:19 +1300 Message-ID: <1076990119.17534371b4593@webmail.auckland.ac.nz> Date: Tue, 17 Feb 2004 16:55:19 +1300 From: Nevil Brownlee To: Benoit Claise Cc: stbryant@cisco.com, Ganesh Sadasivan , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-1 [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> <402C22E7.5000405@cisco.com> <402C9C89.1050200@cisco.com> <4030D232.6090505@cisco.com> In-Reply-To: <4030D232.6090505@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Benoit, Stewart and Ganesh I don't like 'Flowset' either. It's OK for flow data records, but seems very odd when it refers to template or option records. I suggest that 'block' would be a better word. That way we'd have blocks of template records, flow records, etc. You already have a block structure defined - each block starts with a template ID (your Flowset ID) and a length (inclusive in bytes) of the block. The template ID identifies which template defines the structure for this block, so lets call it the template ID (rather than Flowset ID). You have special values of template ID (0..255) used to overload the field, i.e. they tell us that these are defining various kinds of template - they're definition blocks rather than data blocks. Of those, template 0 defines a new template (your 'IETF exclusive' one) [how about just calling that a 'standard' template, i.e. one which uses only information elements defined in the IPFIX INFO RFC?] 2 defines a new template in which the element ids are qualified by explicitly specifying their Enterprise Number. [how about reserving Enterprise 0 for the IPFIX standard information elements, just to be complete?] 1 defines a new options template, i.e. one which uses info elements from a set which describe the meter/exporter [these need to be defined in IPFIX INFO]. 3 defines a new options template, with enterprise IDs specified for each 'option' element. I find the name 'options template' confusing. They're really information elements which describe the meter/exporter. How about renaming them 'meter templates?' That way we'd have Flow Templates - specifying Flow Records, using info elements defined in terms of the flows and Meter Templates - specifying Meter Records, using info elements defined in terms of the meter/exporter. To go with that, we'd have four kinds of blocks: Flow Template block Flow block Meter Template block Meter block Now, rereading the section on your options templates, I'm confused about their Scope-related fields. I understand why that's needed, i.e. to specify which part of the meter a given subset of the options template relates to. If I understand it correctly, for each scope (1..X) we have a sub-block specifying the elements we want reported for that scope. Then Option Length is the total length of all the (type,length) pairs for a scope, and Option Scope Length is the total length for all the scope sub-blocks. Have I got that right? If so, your example on page 50 doesn't seem to be correct. Or have I misunderstood?? Also, do we actually need an Option Scope field? Given that we know the total block length (from the Length field), we can walk along the scope sub-blocks until we get to the end. Or, if we do want something to make it easier to parse, how about having the 'Option Scope Length' give the number of scope sub-blocks which follow? Again, looking at the example on page 50, it shows an options data record with sub-blocks for each scope (as I thought from the above discussion). But the 'options data flowset' description in section 8.5.3 says the order is 'values for each scope' for each option in the list. Which order is intended?? Sorry to send such a rambling posting, but I really find the 'options data' sections very confusing indeed. I think it would help if each of the defining sections began with a sentence or two describing the record structure in terms of header and data, as you do for the IPFIX message layout in section 7. If you're happy with my 'blocks, headers and sub-blocks' approach I could try writing an overview description for you ... One more thing: I like your section 8.2, Field Type format. Since you've specified it so clearly, how about referring to it in following sections, e.g. "a template block is a block header followed by an ordered list of Field Types" ? As it is you don't actually use Field Types anywhere, at least I didn't notice it. Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 05:51:30 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22958 for ; Tue, 17 Feb 2004 05:51:29 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At2dt-0007f9-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 04:39:53 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At2ds-0007X7-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 04:39:52 -0600 Received: from cisco.com (ams-clip-vpn-dhcp90.cisco.com [10.61.64.90]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1HAdL711235; Tue, 17 Feb 2004 11:39:25 +0100 (CET) Message-ID: <4031EF59.2010908@cisco.com> Date: Tue, 17 Feb 2004 11:39:21 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?5Yav5paH5bOw?= CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] about section 17:Examples References: <4963507.1076040462597.JavaMail.root@mail.iei-china.com> <4023B565.3010409@cisco.com> In-Reply-To: <4023B565.3010409@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Wenfeng, After looking (more) carefully, there was a mistake in that example, there was an extra 2 in the Flow Record. It should be: In this example, we report the following two records: Line Card ID | Export Packet| Export Flow ------------------------------------------ Line Card 1 | 345 | 10201 Line Card 2 | 690 | 20402 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FlowSet ID = 257 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 345 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10201 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 690 | 20402 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is corrected in 03 protocol draft version. Regards, Benoit. > Hi Wenfeng, > >> In draft-ietf-ipfix-protocol-02.txt,Section 17,Page 42. >> >> The example seems to be a NETFLOW9 example,rather than a IPFIX example. >> First,the message header's Version Number Field should to be 0x000a >> instead of 0x0009; > > Corrected. > >> Second, in the message header there should be a SysUpTime Field >> besides the Unix Secs Field; > > This one has been reported already. Actually the example is right! > http://ipfix.doit.wisc.edu/archive/2362.html > >> and in Section 17.5 Data FlowSet with Options Data Records >> Example,there may be some error: According to IPFIX Protocol >> Specification the Length Field should be 20 rather than 14. >> > Corrected. > > Thanks. > >> >> Best Regards >> yours wenfeng >> >> >> >> > > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in > message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 05:52:44 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23037 for ; Tue, 17 Feb 2004 05:52:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At2as-0007Kz-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 04:36:46 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At2ar-0007Kt-00 for ipfix@net.doit.wisc.edu; Tue, 17 Feb 2004 04:36:45 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1HAaf6W097154 for ; Tue, 17 Feb 2004 11:36:44 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1HAYlCw096930 for ; Tue, 17 Feb 2004 11:34:47 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1HAYj6S096917; Tue, 17 Feb 2004 11:34:47 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 0AB59100EE6; Tue, 17 Feb 2004 11:34:44 +0100 (CET) Date: Tue, 17 Feb 2004 11:35:16 +0100 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Cc: "Wijnen, Bert (Bert)" , stbryant@cisco.com, allison mankin , "David Kessens (E-mail)" Subject: [ipfix] RE: IPFIX requirements - security Message-ID: <2147483647.1077017716@[10.1.1.171]> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155028EC4EB@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B155028EC4EB@nl0006exch001u.nl.lucent.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, There has been no further reply on this issue on the IPFIX mailing list. My interpretation of this silence is that we do not call the document back from IESG review but support its further progress towards an informational RFC. Does anybody disagree with this interpretation?? Thanks, Juergen --On 03.02.2004 16:03 Uhr +0100 Wijnen, Bert (Bert) wrote: > You can call it back, but I doubt you can get away with what > Stewart wants. > > Thanks, > Bert > >> -----Original Message----- >> From: Juergen Quittek [mailto:quittek@ccrle.nec.de] >> Sent: dinsdag 3 februari 2004 15:52 >> To: stbryant@cisco.com >> Cc: bwijnen@lucent.com; allison mankin; ipfix@net.doit.wisc.edu >> Subject: Re: IPFIX requirements - security >> >> >> Dear all, >> >> What shall we do with Stewart's issue? >> >> The requirements draft is under IESG review. >> Shall we call it back from there? >> >> Juergen >> >> >> --On 03.02.2004 10:39 Uhr +0000 Stewart Bryant wrote: >> >> > >> > >> > Juergen Quittek wrote: >> > >> >> Stewart, >> >> >> >> We changed the requirement for confidentiality from SHOULD >> to MUST in >> >> October. >> >> It was based on a comment from Allison: >> >> >> >> "Requirements on the ipfix implementation - the document >> is long and >> >> I wonder if the working group really meant the protocol's >> >> confidentiality >> >> and anonymization features to be so optional - SHOULD >> confidentiality, >> >> MAY anonymization. Just for implementation." >> >> >> >> So far there was an agreement on this change on the >> mailing list as well as >> >> at the last IPFIX session, where this particular issue was >> presented. >> >> This does not mean, that we may not discuss the issue >> anymore, but so far, >> >> we had an agreement. >> >> >> >> I see the higher implementation effort, but I also see >> that most new >> >> devices >> >> today implement IPsec anyway. So, I would be fine with both ways. >> >> >> > >> > On the other hand we also talk about the performance issues >> of IPFIX, >> > and IPsec will mean either a lot of CPU cycles or hardware support. >> > Also to be of use in a reasonable timeframe, IPFIX has to work on >> > existing platforms. >> > >> > Now I do not have any problem with requiring the system to provide >> > confidentially etc, it's just that the way that the requirement >> > is written, the protocol MUST support it, which constrains the >> > implementation choices. >> > >> > - Stewart >> > >> >> Are there people on the mailing list who either agree or disagree? >> >> Please speak up. >> >> >> >> Thanks, >> >> >> >> Juergen >> > >> >> >> >> -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 05:56:15 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23255 for ; Tue, 17 Feb 2004 05:56:15 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At2gf-00005k-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 04:42:45 -0600 Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At2ge-00005e-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 04:42:44 -0600 Received: from cisco.com (ams-clip-vpn-dhcp90.cisco.com [10.61.64.90]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i1HAgV716554; Tue, 17 Feb 2004 11:42:34 +0100 (CET) Message-ID: <4031F017.3090505@cisco.com> Date: Tue, 17 Feb 2004 11:42:31 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?5Yav5paH5bOw?= CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] about section 17:Examples References: <4963507.1076040462597.JavaMail.root@mail.iei-china.com> <4023B565.3010409@cisco.com> <4031EF59.2010908@cisco.com> In-Reply-To: <4031EF59.2010908@cisco.com> Content-Type: multipart/alternative; boundary="------------010008070206060508050903" Precedence: bulk Sender: majordomo listserver This is a multi-part message in MIME format. --------------010008070206060508050903 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Benoit Claise wrote: > Hi Wenfeng, > > After looking (more) carefully, there was a mistake in that example, > there was an extra 2 in the Flow Record. > It should be: > > In this example, we report the following two records: > > Line Card ID | Export Packet| Export Flow > ------------------------------------------ > Line Card 1 | 345 | 10201 > Line Card 2 | 690 | 20402 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | FlowSet ID = 257 | Length = 16 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 1 | 345 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 10201 | 2 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 690 | 20402 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This is corrected in 03 protocol draft version. Ooops. This is _NOT _corrected in the 03 protocol draft version. But corrected in the interim version. > > Regards, Benoit. > >> Hi Wenfeng, >> >>> In draft-ietf-ipfix-protocol-02.txt,Section 17,Page 42. >>> >>> The example seems to be a NETFLOW9 example,rather than a IPFIX example. >>> First,the message header's Version Number Field should to be 0x000a >>> instead of 0x0009; >> >> >> Corrected. >> >>> Second, in the message header there should be a SysUpTime Field >>> besides the Unix Secs Field; >> >> >> This one has been reported already. Actually the example is right! >> http://ipfix.doit.wisc.edu/archive/2362.html >> >>> and in Section 17.5 Data FlowSet with Options Data Records >>> Example,there may be some error: According to IPFIX Protocol >>> Specification the Length Field should be 20 rather than 14. >>> >> Corrected. >> >> Thanks. >> >>> >>> Best Regards >>> yours wenfeng >>> >>> >>> >>> >> >> >> >> -- >> Help mailto:majordomo@net.doit.wisc.edu and say "help" in >> message body >> Unsubscribe mailto:majordomo@net.doit.wisc.edu and say >> "unsubscribe ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ > > > --------------010008070206060508050903 Content-Type: text/html; charset=UTF-8 X-MIME-Autoconverted: from 8bit to base64 by strange-brew.cisco.com id i1HAgV716554 Content-Transfer-Encoding: base64 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlv bmFsLy9FTiI+DQo8aHRtbD4NCjxoZWFkPg0KICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0bWw7 Y2hhcnNldD1VVEYtOCIgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4NCiAgPHRpdGxlPjwv dGl0bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIjZmZmZmZmIiB0ZXh0PSIjMDAwMDAw Ij4NCkJlbm9pdCBDbGFpc2Ugd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2l0ZT0ibWlkNDAz MUVGNTkuMjAxMDkwOEBjaXNjby5jb20iIHR5cGU9ImNpdGUiPkhpDQpXZW5mZW5nLA0KICA8 YnI+DQogIDxicj4NCkFmdGVyIGxvb2tpbmcgKG1vcmUpIGNhcmVmdWxseSwgdGhlcmUgd2Fz IGEgbWlzdGFrZSBpbiB0aGF0IGV4YW1wbGUsDQp0aGVyZSB3YXMgYW4gZXh0cmEgMiBpbiB0 aGUgRmxvdyBSZWNvcmQuDQogIDxicj4NCkl0IHNob3VsZCBiZToNCiAgPGJyPg0KICA8YnI+ DQrCoMKgwqAgSW4gdGhpcyBleGFtcGxlLCB3ZSByZXBvcnQgdGhlIGZvbGxvd2luZyB0d28g cmVjb3JkczoNCiAgPGJyPg0KICA8YnI+DQrCoMKgwqAgTGluZSBDYXJkIElEIHwgRXhwb3J0 IFBhY2tldHwgRXhwb3J0IEZsb3cNCiAgPGJyPg0KwqDCoMKgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICA8YnI+DQrCoMKgwqAgTGluZSBDYXJkIDHC oCB8IDM0NcKgwqDCoMKgwqDCoMKgwqDCoCB8IDEwMjAxDQogIDxicj4NCsKgwqDCoCBMaW5l IENhcmQgMsKgIHwgNjkwwqDCoMKgwqDCoMKgwqDCoMKgIHwgMjA0MDINCiAgPGJyPg0KICA8 YnI+DQrCoMKgwqDCoCAwwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDHC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCAzDQogIDxicj4NCsKgwqDCoMKgIDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICA8 YnI+DQrCoMKgwqAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgPGJyPg0KwqDCoMKgIHzCoMKgwqAgRmxvd1Nl dCBJRCA9IDI1N8KgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgIExlbmd0 aCA9IDE2wqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KICA8YnI+DQrCoMKgwqAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgPGJyPg0KwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMcKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMzQ1 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQogIDxicj4NCsKgwqDCoCArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICA8YnI+DQrCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgIDEwMjAxwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgMsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8DQogIDxicj4NCsKgwqDCoCArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICA8YnI+DQrCoMKgwqAgfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgNjkwwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDIwNDAy wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgfA0KICA8YnI+DQrCoMKgwqAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgPGJyPg0KICA8YnI+DQpUaGlzIGlzIGNvcnJlY3RlZCBpbiAwMyBwcm90b2NvbCBk cmFmdCB2ZXJzaW9uLg0KICA8YnI+DQo8L2Jsb2NrcXVvdGU+DQpPb29wcy4gPGJyPg0KVGhp cyBpcyA8dT5OT1QgPC91PmNvcnJlY3RlZCBpbiB0aGUgMDMgcHJvdG9jb2wgZHJhZnQgdmVy c2lvbi48YnI+DQpCdXQgY29ycmVjdGVkIGluIHRoZSBpbnRlcmltIHZlcnNpb24uPGJyPg0K PGJsb2NrcXVvdGUgY2l0ZT0ibWlkNDAzMUVGNTkuMjAxMDkwOEBjaXNjby5jb20iIHR5cGU9 ImNpdGUiPjxicj4NClJlZ2FyZHMsIEJlbm9pdC4NCiAgPGJyPg0KICA8YnI+DQogIDxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPkhpIFdlbmZlbmcsDQogICAgPGJyPg0KICAgIDxicj4NCiAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5JbiBkcmFmdC1pZXRmLWlwZml4LXByb3RvY29s LTAyLnR4dCxTZWN0aW9uDQoxNyxQYWdlIDQyLg0KICAgICAgPGJyPg0KICAgICAgPGJyPg0K VGhlIGV4YW1wbGUgc2VlbXMgdG8gYmUgYSBORVRGTE9XOSBleGFtcGxlLHJhdGhlciB0aGFu IGEgSVBGSVggZXhhbXBsZS4NCiAgICAgIDxicj4NCkZpcnN0LHRoZSBtZXNzYWdlIGhlYWRl cidzIFZlcnNpb24gTnVtYmVyIEZpZWxkIHNob3VsZCB0byBiZSAweDAwMGENCmluc3RlYWQg b2YgMHgwMDA5Ow0KICAgICAgPGJyPg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQpD b3JyZWN0ZWQuDQogICAgPGJyPg0KICAgIDxicj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj5TZWNvbmQsIGluIHRoZSBtZXNzYWdlIGhlYWRlciB0aGVyZSBzaG91bGQNCmJlIGEg U3lzVXBUaW1lIEZpZWxkIGJlc2lkZXMgdGhlIFVuaXggU2VjcyBGaWVsZDsNCiAgICAgIDxi cj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KVGhpcyBvbmUgaGFzIGJlZW4gcmVw b3J0ZWQgYWxyZWFkeS4gQWN0dWFsbHkgdGhlIGV4YW1wbGUgaXMgcmlnaHQhDQogICAgPGJy Pg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL2lwZml4 LmRvaXQud2lzYy5lZHUvYXJjaGl2ZS8yMzYyLmh0bWwiPmh0dHA6Ly9pcGZpeC5kb2l0Lndp c2MuZWR1L2FyY2hpdmUvMjM2Mi5odG1sPC9hPg0KICAgIDxicj4NCiAgICA8YnI+DQogICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+YW5kIGluIFNlY3Rpb24gMTcuNSBEYXRhIEZsb3dT ZXQgd2l0aA0KT3B0aW9ucyBEYXRhIFJlY29yZHMgRXhhbXBsZSx0aGVyZSBtYXkgYmUgc29t ZSBlcnJvcjogQWNjb3JkaW5nIHRvDQpJUEZJWCBQcm90b2NvbCBTcGVjaWZpY2F0aW9uIHRo ZSBMZW5ndGggRmllbGQgc2hvdWxkIGJlIDIwIHJhdGhlciB0aGFuDQoxNC4NCiAgICAgIDxi cj4NCiAgICAgIDxicj4NCiAgICA8L2Jsb2NrcXVvdGU+DQpDb3JyZWN0ZWQuDQogICAgPGJy Pg0KICAgIDxicj4NClRoYW5rcy4NCiAgICA8YnI+DQogICAgPGJyPg0KICAgIDxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxicj4NCkJlc3QgUmVnYXJkcw0KICAgICAgPGJyPg0KeW91cnMg d2VuZmVuZw0KICAgICAgPGJyPg0KICAgICAgPGJyPg0KICAgICAgPGJyPg0KwqANCiAgICAg IDxicj4NCiAgICAgIDxicj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPGJyPg0KICAgIDxi cj4NCiAgICA8YnI+DQotLcKgPGJyPg0KSGVscMKgwqDCoMKgwqDCoMKgIDxhIGNsYXNzPSJt b3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Im1haWx0bzptYWpvcmRvbW9AbmV0LmRvaXQu d2lzYy5lZHUiPm1haWx0bzptYWpvcmRvbW9AbmV0LmRvaXQud2lzYy5lZHU8L2E+IGFuZCBz YXkgImhlbHAiIGluDQptZXNzYWdlIGJvZHkNCiAgICA8YnI+DQpVbnN1YnNjcmliZSA8YSBj bGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86bWFqb3Jkb21vQG5l dC5kb2l0Lndpc2MuZWR1Ij5tYWlsdG86bWFqb3Jkb21vQG5ldC5kb2l0Lndpc2MuZWR1PC9h PiBhbmQgc2F5DQogICAgPGJyPg0KInVuc3Vic2NyaWJlIGlwZml4IiBpbiBtZXNzYWdlIGJv ZHkNCiAgICA8YnI+DQpBcmNoaXZlwqDCoMKgwqAgPGEgY2xhc3M9Im1vei10eHQtbGluay1m cmVldGV4dCIgaHJlZj0iaHR0cDovL2lwZml4LmRvaXQud2lzYy5lZHUvYXJjaGl2ZS8iPmh0 dHA6Ly9pcGZpeC5kb2l0Lndpc2MuZWR1L2FyY2hpdmUvPC9hPg0KICAgIDxicj4NCiAgPC9i bG9ja3F1b3RlPg0KICA8YnI+DQogIDxicj4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --------------010008070206060508050903-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 09:23:07 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29304 for ; Tue, 17 Feb 2004 09:23:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At5m4-0001sp-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 08:00:32 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At5m2-0001sk-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 08:00:31 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1HE0QYI016544 for ; Tue, 17 Feb 2004 15:00:29 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1HDtZdL016036 for ; Tue, 17 Feb 2004 14:55:35 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1HDtZYC016035; Tue, 17 Feb 2004 14:55:35 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id C4E7D108CEA; Tue, 17 Feb 2004 14:55:33 +0100 (CET) Date: Tue, 17 Feb 2004 14:56:06 +0100 From: Juergen Quittek To: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: PROTO-12 Re: [ipfix-protocol] IPFIX protocol draft: list of issues Message-ID: <2147483647.1077029766@[10.1.1.171]> In-Reply-To: <402C14CA.30407@cisco.com> References: <402C14CA.30407@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Dear all, --On 13.02.2004 1:05 Uhr +0100 Benoit Claise wrote: > PROTO-12: Do we need the IETF exclusive template flowset format? > suggested solution: > - reserve flowset ID 0 & 1 for compatibility with NFv9 > - try to make flowset ID 2 & 3 definition fully compatible with NFv9 > - add note that if you implement ID 2/3 correctly, you can also process ID 0/1. This issue is about message formats. Currently we have 6 binary formats for templates and records: - an IETF-exclusive flow template format (flowset ID 0) - a vendor-specified flow template format (flowset ID 2) - an IETF-exclusive option template format (flowset ID 1) - a vendor-specified option template format (flowset ID 3) - a data flowset format - an options data record format I think these are far too many for our purpose. (BTW: Thanks to Lutz Mark from Fraunhofer FOKUS who initially raised this point at a discussion in January!) I see no reason why we should have IETF-exclusive template formats. the vendor-specific may contain IETF-defined fields, they may even have only IETF-defined fields. So, if I implement these two templates, I can define any flow record format or option record format, respectively. There is nothing gained by also having IETF-specific template formats. Consequently, my firat proposal is removing flowset ID's 0 and 1 from the standard. Now let's have a look at the data formats. The only difference between both of them is that in the option data record format the first N values are scope values. How many scope values there are is defined by the corresponding template. Assuming a template could specify the number of scope values to be zero, then the option template record format includes the data flowset format. If we allow an option data record format to have a scope length of zero, then there is no need anymore for implementing a separate data record format. So, my second proposal is merging data flowset format and option data record format to a single one. Note that still the template ID clearly indicates the kind of record (data flowset or option data record). Then we arrive at two template formats and a single data format: - a flow template format (flowset ID 2) - a option template format (flowset ID 3) - a data format This achievement is a simplification of the protocol definition and the stack implementation on both sides. I do not see any drawback concerning functionality, performance or safety compared to the current protocol definition! Once started, I find it hard to stop :-) : If we accept a small performance degradation, we could also merge the two template formats. The only difference between them is that one contains scope information and the other one does not. If we allow the value of field 'option scope length' to be zero, then we could use just the option template format for all templates. Please note that the first 16 bits of all templates still contain the flowset ID with value 2 indicating a data template and value 3 indicating an option template. There would be no problem with identifying the kind of template, but all implementations would have to implement only one template format. The only drawback of this solution is that all templates would have a field called 'scope length', which is currently not included in the data template format. Then all data template would increase in size by the size of this field. Still it looks like a reasonable simplification of format definition. Please consider that one of the factors influencing the acceptance of a standard is its complexity. And I see this third step of reducing the number of formats as a simplification ending up with just two formats: a single template format and a single data format. The template flowset indicates with its first 16 bits whether it is a flow data template or an option data template. The data flowset indicates with its first 16 bits to which template it corresponds. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 10:31:45 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04702 for ; Tue, 17 Feb 2004 10:31:45 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At6yk-0005JE-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 09:17:42 -0600 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At6yj-0005J8-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 09:17:41 -0600 Received: from fokus.fraunhofer.de (dhcp245 [195.37.78.245]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id i1HFHSG23125; Tue, 17 Feb 2004 16:17:28 +0100 (MET) Message-ID: <40322FD6.2000009@fokus.fraunhofer.de> Date: Tue, 17 Feb 2004 16:14:30 +0100 From: Sebastian Zander Organization: Fraunhofer FOKUS User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-12 Re: [ipfix-protocol] IPFIX protocol draft: list of issues References: <402C14CA.30407@cisco.com> <2147483647.1077029766@[10.1.1.171]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen, having only one format does not only reduce the complexity of the protocol but also adds the notion of scope to flowsets. Currently a receiver has no way to determine the scope for flowset data. Furthermore for per-packet data (e.g. psamp) it would be good to have the ability to link flowsets to flowsets. Because you have data of the form: flow-key, seq-number, packet-sample, ... But the flow-key does not change per packet. To avoid the overhead of repeating the flow-key for each packet one could have 2 flowsets and link them: Flowset 1 flow-id, flow-key, ... Flowset 2 flow-id, seq-number, packet-sample, ... In the example you can exchange packet-sample by packet-id used for packet matching (one-way measurement, trajectories, ...) See http://www.ietf.org/internet-drafts/draft-pohl-pktid-00.txt Why should that be different from linking option data to flowset data e.g. via the template scope? However I still miss a good example for having explicit scope. In a lot of cases the scope can be easily deduced by knowing the semantics of the fields (hich you have to know if you want to do something with the data). But maybe somebody has one? Let me take this proposal one step further: Instead of using separate scope IDs we can use fields. So instead of defining the scope interface and the field interface we can use the field interface as scope field (or non scope field). The obvious drawback is that the number space is halved. The advantage is that only one number space must be administrated and used and semantically equivalent fields are not defined twice (again we reduce the complexity). Cheers, Sebastian Juergen Quittek wrote: [...] > If we accept a small performance degradation, we could also merge > the two template formats. The only difference between them is that > one contains scope information and the other one does not. If we > allow the value of field 'option scope length' to be zero, then > we could use just the option template format for all templates. > Please note that the first 16 bits of all templates still contain > the flowset ID with value 2 indicating a data template and value 3 > indicating an option template. There would be no problem with > identifying the kind of template, but all implementations would > have to implement only one template format. > > The only drawback of this solution is that all templates would > have a field called 'scope length', which is currently not included > in the data template format. Then all data template would increase > in size by the size of this field. > > Still it looks like a reasonable simplification of format definition. > Please consider that one of the factors influencing the acceptance > of a standard is its complexity. And I see this third step of > reducing the number of formats as a simplification ending up with > just two formats: > > a single template format > and > a single data format. > > The template flowset indicates with its first 16 bits whether it > is a flow data template or an option data template. > > The data flowset indicates with its first 16 bits to which > template it corresponds. > > Thanks, > > Juergen -- Sebastian Zander E-mail: zander@fokus.fraunhofer.de Fraunhofer FOKUS / METEOR Tel: +49-30-3463-7287 Kaiserin-Augusta-Allee 31 Fax: +49-30-3463-8287 D-10589 Berlin, Germany www.fokus.fraunhofer.de/usr/sebastian.zander -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 10:58:07 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09110 for ; Tue, 17 Feb 2004 10:58:06 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At7TZ-0006kg-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 09:49:33 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At7TY-0006kb-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 09:49:32 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1HFnUYC029540 for ; Tue, 17 Feb 2004 16:49:31 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1HFlR7m029286 for ; Tue, 17 Feb 2004 16:47:27 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1HFlRYC029284; Tue, 17 Feb 2004 16:47:27 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 865F61051E4; Tue, 17 Feb 2004 16:47:25 +0100 (CET) Date: Tue, 17 Feb 2004 16:47:58 +0100 From: Juergen Quittek To: Ganesh Sadasivan , Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-3: IP encapsulated packet [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] Message-ID: <2147483647.1077036478@[10.1.1.171]> In-Reply-To: <402C2192.1010902@cisco.com> References: <402C14CA.30407@cisco.com> <402C2192.1010902@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh, --On 12.02.2004 17:00 h -0800 Ganesh Sadasivan wrote: > Benoit, > > PROTO-3: IP encapsulated packet > - IP Traffic Flow definition speaks of IP packets > - Metering Process definitions say: Input to the metering process are packets - We don't want to limit ourselves to IPv4 and IPv6 > > The architecture spec clearly covers the encapsulated packets in the IP Traffic Flow Definition. > Otherwise we are leaving out MPLS packets, tunnel packets from being able to be defined > as flows. > > "A 'Flow' is a set of IP packets, *or encapsulated IP packets*, > passing an Observation Point in the network during a certain time > interval. All packets belonging to a particular Flow have a set > of common properties. Each property is defined as the result of > applying a function to the values of: You are right. When identifying this issue we looked at the flow definition in the requirements document, not in the architecture document where the term is extended. This is fine, because our charter explicitly mentions Sub-IP information to be reported. However, we should have a discussion on which Sub-IP technologies to cover. But this issues is an information model issues. Thanks, Juergen > 1. One or more header fields of the actual packet, e.g. > destination IP address, or *fields in the packet's > encapsulation header,* e.g. label for MPLS, tunnel end-points > for IP-in-IP or fields in transport header (e.g. destination > port number), or fields in application header field (e.g. > RTP header fields [RFC1889]) > 2. One or more properties of the packet itself (e.g. packet > length) > 3. One or more of fields derived from packet treatment (e.g. > next hop IP address,AS number)" > > Is this clear enough to cover all the cases we want? > I agree we have to change the Metering Process definition to > include > "The Metering Process generates Flow Records. Input to the process > are IP packets or encapsulated IP packets observed at an > Observation Point and packet treatment at the Observation Point, > for example the selected output interface...." > > > Thanks > Ganesh > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 11:11:54 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11147 for ; Tue, 17 Feb 2004 11:11:54 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At7dd-0007PN-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 09:59:57 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At7dc-0007PH-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 09:59:56 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1HFxeYQ030858 for ; Tue, 17 Feb 2004 16:59:51 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1HFwRuo030704 for ; Tue, 17 Feb 2004 16:58:27 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1HFwQYC030702; Tue, 17 Feb 2004 16:58:27 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A14A0104EFB; Tue, 17 Feb 2004 16:58:25 +0100 (CET) Date: Tue, 17 Feb 2004 16:58:57 +0100 From: Juergen Quittek To: Jeff Meyer , stbryant@cisco.com Cc: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] IPFIX protocol draft: list of issues Message-ID: <2147483647.1077037137@[10.1.1.171]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, --On 16.02.2004 10:11 Uhr -0800 Jeff Meyer wrote: > Hi, > > If I have a declaration of the form: > > int var1; > int var2; > char *var3; > > Is "var1" a type? Or is the type of "var1" int? The DATA type of var1 is int. That's why the proposal ... >> PROTO-2: Some discrepancies between data types, field type and Information >> Element terminology. >> - field type (IPFIX-PROTO) conflicts with field ID (IPFIX-INFO) >> - suggestion: use field type instead of field Id in IPFIX-INFO >> - rename 'type' to 'data type' and ... suggests to rename 'type' in the info model doc to 'data type' and use 'field type' as the semantic type of the field. Field type would still be a consistent term. However, I have more sympathy for the term 'field ID', because intuitively this is interpreted correctly while 'field type' could easily be mis-interpreted as 'field data type'. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > var1 and var2 are "identifiers" in my opinion which distinguish among two variables (fields) of the same type. I believe the templating structure is doing the same thing as the example above, but > using numeric id's versus string id's. > > The IPFIX protocol authors chose not to include type information, instead opting to include information about the length of the encoding for a field of a given type (e.g. int, short, dateTime, etc.). So there are (unfortunately) no provisions to > hold type information in IPFIX-proto. > > E.g. the logical equivalent in ipfix-proto templating model to the above would be: > > length (4) fieldId(1); > length (4) fieldId(2); > length(VARIABLELEN) fieldId(3) > > Calling these information element ids would be most accurate, but the term "field" seems heavily used and is equivalent. Calling these identifiers "types" seems odd to me. > > -- Jeff > >> From: Stewart Bryant >> Reply-To: stbryant@cisco.com >> To: Jeff Meyer >> CC: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu >> Subject: Re: [ipfix-protocol] IPFIX protocol draft: list of issues >> Date: Mon, 16 Feb 2004 09:47:24 +0000 >> >> >> >> Jeff Meyer wrote: >> >>> Benoit, >>> >>> Regarding [Proto-2] I'd recommend Field Id over Field Type. The word >>> "type" seems overloaded to me, does type refer to unsigned int, time, etc. >>> Or does it refer a specific field definition (via a numeric identifier). >>> >>>> From its usage it would seem that this portion of the protocol message is >>> >>> holding an identifier, not a type. >>> >>> -- Jeff >>> >> >> Isn't it holding a type identifier? >> >> It's a codepoint that identifies the type of the field that will be >> contained in the corresponding field in the data message. >> >> That would suggest that the name should be field type identifier (FTI) >> or perhaps field type codepoint (FTC). >> >> - Stewart >> >> >> > > _________________________________________________________________ > Click here for a FREE online computer virus scan from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 12:31:13 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19907 for ; Tue, 17 Feb 2004 12:31:12 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At8oT-0003AG-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 11:15:13 -0600 Received: from msg.vodafone.pt ([212.18.167.162]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At8oS-0003AB-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 11:15:12 -0600 Received: from msgspam3 ([172.16.10.5]) by msg.vodafone.pt with Microsoft SMTPSVC(5.0.2195.6713); Tue, 17 Feb 2004 17:15:10 +0000 Received: from mail pickup service by vfpt-mxfe2.vf-pt.internal.vodafone.com with Microsoft SMTPSVC; Tue, 17 Feb 2004 17:15:02 +0000 Received: from lxsmtpsrv00.telecel.pt ([213.30.35.11]) by vfpt-mxfe1.vf-pt.internal.vodafone.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 17 Feb 2004 16:22:11 +0000 Received: from lxsmtpsrv00.telecel.pt ([212.18.191.66]) by lxsmtpsrv00.telecel.pt with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id FDPPLPML; Tue, 17 Feb 2004 16:24:24 -0000 Received: from mail2.vodafone.com (mail2.vodafone.com [195.233.129.232]) by mailrelay2.vodafone.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HGLnI06143 for ; Tue, 17 Feb 2004 17:21:50 +0100 (MET) Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by mail2.vodafone.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HGLkx02634 for ; Tue, 17 Feb 2004 17:21:47 +0100 (MET) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1At7dd-0007PN-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 09:59:57 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1At7dc-0007PH-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 09:59:56 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1HFxeYQ030858 for ; Tue, 17 Feb 2004 16:59:51 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1HFwRuo030704 for ; Tue, 17 Feb 2004 16:58:27 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1HFwQYC030702; Tue, 17 Feb 2004 16:58:27 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id A14A0104EFB; Tue, 17 Feb 2004 16:58:25 +0100 (CET) Date: Tue, 17 Feb 2004 16:58:57 +0100 From: Juergen Quittek To: Jeff Meyer , stbryant@cisco.com Cc: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] IPFIX protocol draft: list of issues Message-ID: <2147483647.1077037137@[10.1.1.171]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-OriginalArrivalTime: 17 Feb 2004 16:22:11.0680 (UTC) FILETIME=[3260FE00:01C3F572] Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Jeff, --On 16.02.2004 10:11 Uhr -0800 Jeff Meyer wrote: > Hi, > > If I have a declaration of the form: > > int var1; > int var2; > char *var3; > > Is "var1" a type? Or is the type of "var1" int? The DATA type of var1 is int. That's why the proposal ... >> PROTO-2: Some discrepancies between data types, field type and Information >> Element terminology. >> - field type (IPFIX-PROTO) conflicts with field ID (IPFIX-INFO) >> - suggestion: use field type instead of field Id in IPFIX-INFO >> - rename 'type' to 'data type' and ... suggests to rename 'type' in the info model doc to 'data type' and use 'field type' as the semantic type of the field. Field type would still be a consistent term. However, I have more sympathy for the term 'field ID', because intuitively this is interpreted correctly while 'field type' could easily be mis-interpreted as 'field data type'. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > var1 and var2 are "identifiers" in my opinion which distinguish among two variables (fields) of the same type. I believe the templating structure is doing the same thing as the example above, but > using numeric id's versus string id's. > > The IPFIX protocol authors chose not to include type information, instead opting to include information about the length of the encoding for a field of a given type (e.g. int, short, dateTime, etc.). So there are (unfortunately) no provisions to > hold type information in IPFIX-proto. > > E.g. the logical equivalent in ipfix-proto templating model to the above would be: > > length (4) fieldId(1); > length (4) fieldId(2); > length(VARIABLELEN) fieldId(3) > > Calling these information element ids would be most accurate, but the term "field" seems heavily used and is equivalent. Calling these identifiers "types" seems odd to me. > > -- Jeff > >> From: Stewart Bryant >> Reply-To: stbryant@cisco.com >> To: Jeff Meyer >> CC: bclaise@cisco.com, ipfix-protocol@net.doit.wisc.edu >> Subject: Re: [ipfix-protocol] IPFIX protocol draft: list of issues >> Date: Mon, 16 Feb 2004 09:47:24 +0000 >> >> >> >> Jeff Meyer wrote: >> >>> Benoit, >>> >>> Regarding [Proto-2] I'd recommend Field Id over Field Type. The word >>> "type" seems overloaded to me, does type refer to unsigned int, time, etc. >>> Or does it refer a specific field definition (via a numeric identifier). >>> >>>> From its usage it would seem that this portion of the protocol message is >>> >>> holding an identifier, not a type. >>> >>> -- Jeff >>> >> >> Isn't it holding a type identifier? >> >> It's a codepoint that identifies the type of the field that will be >> contained in the corresponding field in the data message. >> >> That would suggest that the name should be field type identifier (FTI) >> or perhaps field type codepoint (FTC). >> >> - Stewart >> >> >> > > _________________________________________________________________ > Click here for a FREE online computer virus scan from McAfee. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Tue Feb 17 16:15:53 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06377 for ; Tue, 17 Feb 2004 16:15:53 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtCMc-0005mb-00 for ipfix-list@mil.doit.wisc.edu; Tue, 17 Feb 2004 15:02:42 -0600 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtCMb-0005mW-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 17 Feb 2004 15:02:41 -0600 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Feb 2004 13:11:27 +0000 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1HL2b4U003352; Tue, 17 Feb 2004 13:02:38 -0800 (PST) Received: from cisco.com ([10.32.15.71]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA23442; Tue, 17 Feb 2004 13:02:37 -0800 (PST) Message-ID: <4032816D.5060204@cisco.com> Date: Tue, 17 Feb 2004 13:02:37 -0800 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-3: IP encapsulated packet [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> <402C2192.1010902@cisco.com> <2147483647.1077036478@[10.1.1.171]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen, Juergen Quittek wrote: > Ganesh, > > --On 12.02.2004 17:00 h -0800 Ganesh Sadasivan wrote: > >> Benoit, >> >> PROTO-3: IP encapsulated packet >> - IP Traffic Flow definition speaks of IP packets >> - Metering Process definitions say: Input to the metering >> process are packets - We don't want to limit ourselves to IPv4 and >> IPv6 >> >> The architecture spec clearly covers the encapsulated packets in the >> IP Traffic Flow Definition. >> Otherwise we are leaving out MPLS packets, tunnel packets from being >> able to be defined >> as flows. >> >> "A 'Flow' is a set of IP packets, *or encapsulated IP packets*, >> passing an Observation Point in the network during a certain time >> interval. All packets belonging to a particular Flow have a set >> of common properties. Each property is defined as the result of >> applying a function to the values of: > > > You are right. When identifying this issue we looked at the flow > definition in the > requirements document, not in the architecture document where the term > is extended. > This is fine, because our charter explicitly mentions Sub-IP > information to be > reported. > > However, we should have a discussion on which Sub-IP technologies > to cover. But this issues is an information model issues. If we state flow as "a set of IP packets" does it not exclude Sub-IP technologies like MPLS? However if we define the flow to include encapsulated IP packets, the details of which encapsulation can be discussed in the information model (and not the other way round). I think making it clear that a flow could include encapsulated IP packets in the defintion is fundamental even in the [IPFIX-REQS]. Otherwise the defintion is partial and is liable to be mis-interpreted. Thanks Ganesh > > > Thanks, > > Juergen > > >> 1. One or more header fields of the actual packet, e.g. >> destination IP address, or *fields in the packet's >> encapsulation header,* e.g. label for MPLS, tunnel >> end-points >> for IP-in-IP or fields in transport header (e.g. destination >> port number), or fields in application header field (e.g. >> RTP header fields [RFC1889]) >> 2. One or more properties of the packet itself (e.g. packet >> length) >> 3. One or more of fields derived from packet treatment (e.g. >> next hop IP address,AS number)" >> >> Is this clear enough to cover all the cases we want? >> I agree we have to change the Metering Process definition to >> include >> "The Metering Process generates Flow Records. Input to the process >> are IP packets or encapsulated IP packets observed at an >> Observation Point and packet treatment at the Observation Point, >> for example the selected output interface...." >> >> >> Thanks >> Ganesh >> > > > > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 18 03:31:17 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02051 for ; Wed, 18 Feb 2004 03:31:17 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtMkX-0004PG-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 Feb 2004 02:08:05 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtMkW-0004P8-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 18 Feb 2004 02:08:04 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1I882YC051914 for ; Wed, 18 Feb 2004 09:08:02 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1I881eQ051912 for ; Wed, 18 Feb 2004 09:08:01 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1I880YC051911; Wed, 18 Feb 2004 09:08:01 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 14305EBD0E; Wed, 18 Feb 2004 09:07:59 +0100 (CET) Date: Wed, 18 Feb 2004 09:08:30 +0100 From: Juergen Quittek To: Ganesh Sadasivan Cc: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-3: IP encapsulated packet [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] Message-ID: <2147483647.1077095310@[10.1.1.171]> In-Reply-To: <4032816D.5060204@cisco.com> References: <402C14CA.30407@cisco.com> <402C2192.1010902@cisco.com> <2147483647.1077036478@[10.1.1.171]> <4032816D.5060204@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Ganesh, --On 17.02.2004 13:02 Uhr -0800 Ganesh Sadasivan wrote: > > Juergen, > > Juergen Quittek wrote: > >> Ganesh, >> >> --On 12.02.2004 17:00 h -0800 Ganesh Sadasivan wrote: >> >>> Benoit, >>> >>> PROTO-3: IP encapsulated packet >>> - IP Traffic Flow definition speaks of IP packets >>> - Metering Process definitions say: Input to the metering >>> process are packets - We don't want to limit ourselves to IPv4 and >>> IPv6 >>> >>> The architecture spec clearly covers the encapsulated packets in the >>> IP Traffic Flow Definition. >>> Otherwise we are leaving out MPLS packets, tunnel packets from being >>> able to be defined >>> as flows. >>> >>> "A 'Flow' is a set of IP packets, *or encapsulated IP packets*, >>> passing an Observation Point in the network during a certain time >>> interval. All packets belonging to a particular Flow have a set >>> of common properties. Each property is defined as the result of >>> applying a function to the values of: >> >> >> You are right. When identifying this issue we looked at the flow >> definition in the >> requirements document, not in the architecture document where the term >> is extended. >> This is fine, because our charter explicitly mentions Sub-IP >> information to be >> reported. >> >> However, we should have a discussion on which Sub-IP technologies >> to cover. But this issues is an information model issues. > > If we state flow as "a set of IP packets" does it not exclude Sub-IP technologies like > MPLS? However if we define the flow to include encapsulated IP packets, > the details of which encapsulation can be discussed in the information model > (and not the other way round). > I think making it clear that a flow could include encapsulated IP packets in the > defintion is fundamental even in the [IPFIX-REQS]. Otherwise the defintion is > partial and is liable to be mis-interpreted. First, the requirements state what must be considered by the protocol. I see no fundamental problem with extending it in the protocol definition. Second, I still prefer the definition used in the requirements document. Defining a flow by its IP header fields and other properties available on the IP layer does not exclude reporting properties of the flow that concern sub-IP layers, for example the ATM PVC used for carrying the flow or the MPLS label. Thanks, Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de > Thanks > Ganesh > >> >> >> Thanks, >> >> Juergen >> >> >>> 1. One or more header fields of the actual packet, e.g. >>> destination IP address, or *fields in the packet's >>> encapsulation header,* e.g. label for MPLS, tunnel >>> end-points >>> for IP-in-IP or fields in transport header (e.g. destination >>> port number), or fields in application header field (e.g. >>> RTP header fields [RFC1889]) >>> 2. One or more properties of the packet itself (e.g. packet >>> length) >>> 3. One or more of fields derived from packet treatment (e.g. >>> next hop IP address,AS number)" >>> >>> Is this clear enough to cover all the cases we want? >>> I agree we have to change the Metering Process definition to >>> include >>> "The Metering Process generates Flow Records. Input to the process >>> are IP packets or encapsulated IP packets observed at an >>> Observation Point and packet treatment at the Observation Point, >>> for example the selected output interface...." >>> >>> >>> Thanks >>> Ganesh >>> >> >> >> >> >> > > -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 18 11:13:16 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24996 for ; Wed, 18 Feb 2004 11:13:16 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtU6C-0004Xj-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 Feb 2004 09:58:56 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtU6A-0004Xd-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 18 Feb 2004 09:58:55 -0600 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1IFwoYC086207 for ; Wed, 18 Feb 2004 16:58:50 +0100 (CET) Received: from ccrle.nec.de (molina.office [10.1.1.126]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2565E1097BB for ; Wed, 18 Feb 2004 16:58:50 +0100 (CET) Message-ID: <40338BBA.2020507@ccrle.nec.de> Date: Wed, 18 Feb 2004 16:58:50 +0100 From: Maurizio Molina User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix] PROTO-21 Re: [ipfix-protocol] IPFIX protocol draft: list of issues References: <402C14CA.30407@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Benoit Claise wrote: > > PROTO-21: Do we need to define some mandatory content of the metering > process > statistics option template? > - Maurizio suggested text on the mailing list For reference, the suggested text was on this message: http://ipfix.doit.wisc.edu/archive/2407.html Maurizio -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 18 12:04:43 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29094 for ; Wed, 18 Feb 2004 12:04:43 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtUqW-0006kU-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 Feb 2004 10:46:48 -0600 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtUqV-0006kP-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 18 Feb 2004 10:46:47 -0600 Received: from ios-xdm4.cisco.com (ios-xdm4.cisco.com [171.70.69.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IGkh1m001539; Wed, 18 Feb 2004 08:46:44 -0800 (PST) Received: from cisco.com ([10.32.15.71]) by ios-xdm4.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA24684; Wed, 18 Feb 2004 08:46:43 -0800 (PST) Message-ID: <403396F3.8000507@cisco.com> Date: Wed, 18 Feb 2004 08:46:43 -0800 From: Ganesh Sadasivan Organization: Cisco Systems Inc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu Subject: Re: PROTO-3: IP encapsulated packet [Re: [ipfix-protocol] IPFIX protocol draft: list of issues] References: <402C14CA.30407@cisco.com> <402C2192.1010902@cisco.com> <2147483647.1077036478@[10.1.1.171]> <4032816D.5060204@cisco.com> <2147483647.1077095310@[10.1.1.171]> Content-Type: multipart/alternative; boundary="------------010502030205010405030707" Precedence: bulk Sender: majordomo listserver --------------010502030205010405030707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Jurgene, Juergen Quittek wrote: > Ganesh, > > --On 17.02.2004 13:02 Uhr -0800 Ganesh Sadasivan wrote: > >> >> Juergen, >> >> Juergen Quittek wrote: >> >>> Ganesh, >>> >>> --On 12.02.2004 17:00 h -0800 Ganesh Sadasivan wrote: >>> >>>> Benoit, >>>> >>>> PROTO-3: IP encapsulated packet >>>> - IP Traffic Flow definition speaks of IP packets >>>> - Metering Process definitions say: Input to the metering >>>> process are packets - We don't want to limit ourselves to IPv4 and >>>> IPv6 >>>> >>>> The architecture spec clearly covers the encapsulated packets in the >>>> IP Traffic Flow Definition. >>>> Otherwise we are leaving out MPLS packets, tunnel packets from being >>>> able to be defined >>>> as flows. >>>> >>>> "A 'Flow' is a set of IP packets, *or encapsulated IP packets*, >>>> passing an Observation Point in the network during a certain >>>> time >>>> interval. All packets belonging to a particular Flow have a set >>>> of common properties. Each property is defined as the result of >>>> applying a function to the values of: >>> >>> >>> >>> You are right. When identifying this issue we looked at the flow >>> definition in the >>> requirements document, not in the architecture document where the term >>> is extended. >>> This is fine, because our charter explicitly mentions Sub-IP >>> information to be >>> reported. >>> >>> However, we should have a discussion on which Sub-IP technologies >>> to cover. But this issues is an information model issues. >> >> >> If we state flow as "a set of IP packets" does it not exclude >> Sub-IP technologies like >> MPLS? However if we define the flow to include encapsulated IP packets, >> the details of which encapsulation can be discussed in the >> information model >> (and not the other way round). >> I think making it clear that a flow could include encapsulated IP >> packets in the >> defintion is fundamental even in the [IPFIX-REQS]. Otherwise the >> defintion is >> partial and is liable to be mis-interpreted. > > > First, the requirements state what must be considered by the > protocol. I see > no fundamental problem with extending it in the protocol definition. But this is definition for the basic terminology and shouldn't all the documents concur on the defintion of flow? > > Second, I still prefer the definition used in the requirements document. Is it just a preference or is there a justification for not being explicit? > > Defining a flow by its IP header fields and other properties available on > the IP layer does not exclude reporting properties of the flow that > concern > sub-IP layers, for example the ATM PVC used for carrying the flow or > the MPLS > label. I guess there is difference between reporting and using these fields as flow keys. The intention is that sub-ip header fields would be used as flow keys. The examples that you have taken of ATM PVC and MPLS is definitly not obvious from the flow definition given in [IPFIX-REQ] . In the defintion below, there is an explicit mention of network, transport and application header. So why not include sub-ip header. It would make the defintion a lot more clearer. A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. All packets belonging to a particular flow have a set of common properties. Each property is defined as the result of applying a function to the values of: 1. /one or more packet header field (e.g. destination IP address), transport header field (e.g. destination port number), or application header field (e.g. RTP header fields [RFC1889]) / 2. one or more characteristics of the packet itself (e.g. number of MPLS labels, etc...) 3. one or more of fields derived from packet treatment (e.g. next hop IP address, the output interface, etc...) Thanks Ganesh > > > Thanks, > > Juergen --------------010502030205010405030707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jurgene,

Juergen Quittek wrote:
Ganesh,

--On 17.02.2004 13:02 Uhr -0800 Ganesh Sadasivan wrote:


Juergen,

Juergen Quittek wrote:

Ganesh,

--On 12.02.2004 17:00 h -0800 Ganesh Sadasivan wrote:

Benoit,

PROTO-3: IP encapsulated packet
   - IP Traffic Flow definition speaks of IP packets
   - Metering Process definitions say:      Input to the metering
process are packets    - We don't want to limit ourselves to IPv4 and
IPv6

The architecture spec clearly covers the encapsulated packets in the
IP Traffic Flow Definition.
Otherwise we are leaving out MPLS packets, tunnel packets from being
able to be defined
as flows.

       "A 'Flow' is a set of IP packets, *or encapsulated IP packets*,
       passing an Observation Point in the network during a certain time
       interval. All packets belonging to a particular Flow have a set
       of common properties. Each property is defined as the result of
       applying a function to the values of:


You are right.  When identifying this issue we looked at the flow
definition in the
requirements document, not in the architecture document where the term
is extended.
This is fine, because our charter explicitly mentions Sub-IP
information to be
reported.

However, we should have a discussion on which Sub-IP technologies
to cover.  But this issues is an information model issues.

If we state flow as  "a set of IP packets"  does it not exclude Sub-IP technologies like
MPLS? However if we define the flow to include encapsulated IP packets,
 the details of which encapsulation can be discussed in the information model
(and not the other way round).
 I think making it clear that a flow could include encapsulated IP packets in the
defintion is fundamental even in the [IPFIX-REQS]. Otherwise the defintion is
partial and is liable to be mis-interpreted.

First, the requirements state what must be considered by the protocol.  I see
no fundamental problem with extending it in the protocol definition.
But this is definition for the basic terminology and shouldn't all the documents
concur on the defintion of flow?

Second, I still prefer the definition used in the requirements document.
Is it just a preference or is there a justification for  not being explicit?

Defining a flow by its IP header fields and other properties available on
the IP layer does not exclude reporting properties of the flow that concern
sub-IP layers, for example the ATM PVC used for carrying the flow or the MPLS
label.
I guess there is difference between reporting and using these fields as flow keys.
The intention is that sub-ip header fields would be used as flow keys.
The examples that you have taken of ATM PVC and MPLS is definitly not obvious
from the flow definition given in [IPFIX-REQ] . In the defintion below, there is an
explicit mention of  network, transport and application header. So why not include
sub-ip header. It would make the defintion a lot more clearer.

  A flow is defined as a set of IP packets passing an observation point
   in the network during a certain time interval.  All packets belonging
   to a particular flow have a set of common properties.  Each property
   is defined as the result of applying a function to the values of:

     1. one or more packet header field (e.g. destination IP address),
         transport header field (e.g. destination port number), or
         application header field (e.g. RTP header fields [RFC1889])

      2. one or more characteristics of the packet itself (e.g. number
         of MPLS labels, etc...)

      3. one or more of fields derived from packet treatment (e.g. next
         hop IP address, the output interface, etc...)

Thanks
Ganesh




Thanks,

   Juergen

--------------010502030205010405030707-- -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 18 13:45:28 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07935 for ; Wed, 18 Feb 2004 13:45:28 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtWJE-0003Am-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 Feb 2004 12:20:32 -0600 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtWJC-0003Ag-00 for ipfix@net.doit.wisc.edu; Wed, 18 Feb 2004 12:20:31 -0600 Received: from ams-msg-core-1.cisco.com (144.254.74.60) by sj-iport-5.cisco.com with ESMTP; 18 Feb 2004 10:20:34 -0800 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-msg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1IIK2Fg018842; Wed, 18 Feb 2004 19:20:02 +0100 (MET) Received: from cisco.com (dhcp-rea-gp250-64-103-65-193.cisco.com [64.103.65.193]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA03915; Wed, 18 Feb 2004 18:20:27 GMT Message-ID: <4033ACEB.6020301@cisco.com> Date: Wed, 18 Feb 2004 18:20:27 +0000 From: Stewart Bryant Reply-To: stbryant@cisco.com Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: quittek , ipfix@net.doit.wisc.edu Subject: [ipfix] draft-ietf-ipfix-info-03 - comments Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Juergen Some comments re draft-ietf-ipfix-info-03: 4. Flow Attributes 4.1 octetCount Description: The number of observed octets. Abstract Data Type: unsigned64 Field Id: 1 Units: octets SB> Why remove the distinction between in and out? SB> Many observers will be in routers or other packet SB> processors, and removing the distinction means SB> correlating the results of two observers, when SB> in practise only one is needed reporting input SB> and output characteristics. 4.2 packetCount Description: The number of observed packets. Abstract Data Type: unsigned64 Field Id: 2 Units: packets SB> As 4.1 4.5 classOfService SB> For compatibility with Netflow, this should just be SB> IP CoS. Can we restrict the definition to IP and create SB> new objects for MPLSS and VLAN? Description: The class of service. The definition of classOfService is dependent on the protocol being observed. Those considered here are: * For IPv4 packets the class of service is given by the value of the type of service field in the IPv4 packet header. * For IPv6 packets the class of service is given by the value of the traffic class field in the IPv6 packet header. * For MPLS the class of service is given by the value of the experimental use (Exp) field in label stack entries. The Exp field has a length of 3 bits. These are mapped to the three least valued bits of the classOfService octet. All other bits of the octet are set to zero. * For VLAN the class of service is given by the value of the type of the user_priority field as defined in IEEE802.1q[802.1q] and IEEE 802.1p[802.1p]. EDITORS' NOTE: THIS NEEDS FURTHER WORK Abstract Data Type: octet Data Type Semantics: identifier Field Id: 5 Reference: See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 for the definition of the IPv6 traffic class field. See RFC 3032 for the definition of the Exp field in label stack entries. See SB> I think that we also need to call up diffserv 4.7 sourcePort SB> This would be less ambiguous if it were called SB> transportSourcePort 4.9 sourceMask Description: The number of contiguous bits that are relevant in the source address field of the IP packet header (i.e. the subnet mask in slash notation). SB> This is the IPv4 Mask in Netflow which as a seperate SB> IPv6 Mask (id 29). Since this is part of the compatibility SB> list it should retain the NF definition. If this is unacceptable SB> then perhaps we need to define a new IE type of generic mask. 4.11 destinationPort SB> Again this would be less ambiguous if called SB> transportDestinationPort 4.13 destinationMask Description: The number of contiguous bits that are relevant in the destination address field of the IP packet header (i.e. the subnet mask in slash notation). SB> Again in NF this is the IPv4 mask Abstract Data Type: octet Field Id: 13 Units: bits SB> Again there is the issue of directionality, and NF 24 and SB> 25 define output counts. I think that this is a useful SB> compression of data. 4.25 anotherSourceMask SB> IPv6 SB> I think that we need to take advisment from the IPv6 SB> NF team before deleting. Remember that IPv6 has various SB> transation and compatibility modes Description: The number of contiguous bits that are relevant in the source address field of the IP packet header (i.e. the subnet mask in slash notation). This redundant field has the same semantics as field 9. Abstract Data Type: octet Field Id: 29 Units: bits 4.26 destinationMask SB> As above 4.27 flowLabel SB> I think that this should have a V6 somewhere in it's name 4.28 icmpTypeCode Description: Type and Code of the ICMP message. Abstract Data Type: unsigned16 Field Id: 32 Reference: See RFC 792 for a definition of the ICMP type and code fields. SB> This needs some encoding info, because it's technically SB> two octet fields in the header that are concatentated. SB> I suggested making reference to network byte order. 4.31 samplingAlgorithm Description: The following sampling algorithms are defined: * 1 Deterministic sampling * 2 Random Sampling * 3 Time-based sampling SB> As I recall Benoit suggested that #3 be deleted SB> NF has IPv4 source prefix #44 SB> NF has IPv4 destination prefix #45 SB> Please can we include them so that if they are needed SB> in future we do not have a duplicate definition. SB> #46 and #47 are MPLS parameters in NF. These were SB> deleted along with the other MPLS parameters in the SB> list I supplied. SB> SB> Why are we not listing MPLS parameters? SB> SB> Also you have not included #55 destination CoS SB> Again an observer may be placed at a point where SB> this has been changed as part of a processing SB> operation. SB> SB> You also miss out MAC and VLAN elements from the SB> list. I know of cases where such information is SB> vital to the policing and forensics of an IP network. SB> 4.37 ipVersion Description: The IP version field given in the IP header. Abstract Data Type: octet Field Id: 60 Units: flows Reference: See RFC 791 for a definition of the version field in the IPv6 packet header. See RFC 2460 for a definition of the version field in the IPv6 packet header. Additional information on defined version numbers can be found at http://www.iana.org/assignments/ version-numbers. SB> #61 you miss out direction 4.38 ipNextHopAddressV6 Description: The IPv6 address of the next IP hop to which packets are forwarded. Abstract Data Type: ipv6Address Field Id: 62 4.39 bgpNextHopAddressV6 Description: The IPv6 address of the next BGP hop to which packets are forwarded. Abstract Data Type: ipv6Address Data Type Semantics: identifier Field Id: 63 Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a definition of the AS number. SB> I know that the definition is scruffy, but 64 is the NF SB> method of reporting IPv6 options. This will be needed in some SB> form or other. SB> #70 to #79 are the MPLS label stack. Why are they SB> omitted? 4.44 droppedOctetCount Description: The number of octets dropped. SB> We need a more complete definition for this SB> Same for 85 SB> Again I included an MPLS IE at 85 that has been dropped SB> Text also needs to make reference to the fact SB> that 1 to 79 inc are reserved for NF and must SB> not be redefined, or at least not allocated SB> by IANA. As things stand it looks like IANA SB> is free to fill in the gaps. - Stewart -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 18 16:41:04 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23585 for ; Wed, 18 Feb 2004 16:41:04 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtZDo-0004No-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 Feb 2004 15:27:08 -0600 Received: from [130.216.191.4] (helo=mailhost2.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtZDk-0004NN-00 for ipfix@net.doit.wisc.edu; Wed, 18 Feb 2004 15:27:05 -0600 Received: from mailhost.auckland.ac.nz (dns4.auckland.ac.nz [130.216.1.12]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id i1ILQqeU022963 for ; Thu, 19 Feb 2004 10:26:53 +1300 (NZDT) Received: from localhost (mailhostb.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 35B197B363 for ; Thu, 19 Feb 2004 10:26:52 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08357-07 for ; Thu, 19 Feb 2004 10:26:34 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 10C197AD1F for ; Thu, 19 Feb 2004 10:19:32 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id i1ILE3v15656 for ipfix@net.doit.wisc.edu; Thu, 19 Feb 2004 10:14:03 +1300 Received: from 130.216.38.221 ([130.216.38.221]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Thu, 19 Feb 2004 10:14:03 +1300 Message-ID: <1077138843.dd490ab9f3d05@webmail.auckland.ac.nz> Date: Thu, 19 Feb 2004 10:14:03 +1300 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] IPFIX Agenda for Seoul meeting MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.38.221 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit IPFIX Agenda for IETF 59, Seoul ------------------------------- DRAFT agenda, Thu 19 Feb 04 The IPFIX WG meeting is scheduled for Wednesday, 3 Mar 04 at 1530. It will be chaired by Jeurgen Quittek. There's been a good amount of mailing-list discussion over the last couple of months, and the draft editors have put in a lot of hard work; the current versions of the PROTOCOL and INFO-MODEL drafts are much improved since last meeting. But don't just leave it to the editors - we (the WG as a whole) need to press on and get the drafts completed! time (minutes per item) 5 1) Agenda Review 15 2) Drafts currently with IESG * Requirements draft, Juergen Quittek, draft-ietf-ipfix-reqs-15.txt (dialogue with IESG continues) * Evaluation draft, Simon Leinen, draft-leinen-ipfix-eval-contrib-02 80 3) Current drafts Discussion to focus on unresolved issues and as-yet-unwritten sections. The drafts are: * draft-ietf-ipfix-protocol-03.txt * draft-ietf-ipfix-info-03.txt * draft-ietf-ipfix-arch-02.txt * draft-ietf-ipfix-as-01.txt 5 4) Anything else If you have other items you'd like to see discussed, please advise the WG chairs by email to ipfix-chairs@net.doit.wisc.edu Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand ------------------------------------------------- This mail sent through University of Auckland http://www.auckland.ac.nz/ -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 18 18:19:02 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00803 for ; Wed, 18 Feb 2004 18:19:01 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtanU-0000tX-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 Feb 2004 17:08:04 -0600 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtanT-0000tR-00 for ipfix@net.doit.wisc.edu; Wed, 18 Feb 2004 17:08:03 -0600 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i1IN7wYC095264 for ; Thu, 19 Feb 2004 00:07:58 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i1IN7tNN095262 for ; Thu, 19 Feb 2004 00:07:55 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i1IN7tYC095261; Thu, 19 Feb 2004 00:07:55 +0100 (CET) Received: from [10.1.1.26] (dial02.office [10.1.1.26]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 7511A109A52; Thu, 19 Feb 2004 00:07:52 +0100 (CET) Date: Thu, 19 Feb 2004 00:08:23 +0100 From: Juergen Quittek To: stbryant@cisco.com, ipfix@net.doit.wisc.edu Subject: [ipfix] Re: draft-ietf-ipfix-info-03 - comments Message-ID: <2147483647.1077149303@[10.1.1.26]> In-Reply-To: <4033ACEB.6020301@cisco.com> References: <4033ACEB.6020301@cisco.com> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Stewart, Many thanks for so many comments! Please seesome replies inline. --On 18.02.2004 18:20 Uhr +0000 Stewart Bryant wrote: > Juergen > > Some comments re draft-ietf-ipfix-info-03: > > 4. Flow Attributes > > 4.1 octetCount > > Description: The number of observed octets. > > Abstract Data Type: unsigned64 > > Field Id: 1 > > Units: octets > > SB> Why remove the distinction between in and out? > SB> Many observers will be in routers or other packet > SB> processors, and removing the distinction means > SB> correlating the results of two observers, when > SB> in practise only one is needed reporting input > SB> and output characteristics. But then you would have two observation points. This does not match our current architecture. Still you can report a flows input interface and its output interface. Am I missing something? > 4.2 packetCount > > Description: The number of observed packets. > > Abstract Data Type: unsigned64 > > Field Id: 2 > > Units: packets > > SB> As 4.1 > > > 4.5 classOfService > > SB> For compatibility with Netflow, this should just be > SB> IP CoS. Can we restrict the definition to IP and create > SB> new objects for MPLSS and VLAN? That's fine with me. > Description: > > The class of service. > > The definition of classOfService is dependent on the protocol > being observed. Those considered here are: > > * For IPv4 packets the class of service is given by the value of > the type of service field in the IPv4 packet header. > > * For IPv6 packets the class of service is given by the value of > the traffic class field in the IPv6 packet header. > > * For MPLS the class of service is given by the value of the > experimental use (Exp) field in label stack entries. The Exp > field has a length of 3 bits. These are mapped to the three > least valued bits of the classOfService octet. All other bits > of the octet are set to zero. > > * For VLAN the class of service is given by the value of the type > of the user_priority field as defined in IEEE802.1q[802.1q] and > IEEE 802.1p[802.1p]. > > EDITORS' NOTE: THIS NEEDS FURTHER WORK > > Abstract Data Type: octet > > Data Type Semantics: identifier > > Field Id: 5 > > Reference: > > See RFC 791 for the definition of the IPv4 TOS field. See RFC 2460 > for the definition of the IPv6 traffic class field. See RFC 3032 > for the definition of the Exp field in label stack entries. See > > SB> I think that we also need to call up diffserv Yes. I had it in and I do not know how it got lost. > 4.7 sourcePort > > SB> This would be less ambiguous if it were called > SB> transportSourcePort Agreed. > 4.9 sourceMask > > Description: The number of contiguous bits that are relevant in the > source address field of the IP packet header (i.e. the subnet mask > in slash notation). > > SB> This is the IPv4 Mask in Netflow which as a seperate > SB> IPv6 Mask (id 29). Since this is part of the compatibility > SB> list it should retain the NF definition. If this is unacceptable > SB> then perhaps we need to define a new IE type of generic mask. I never understood the separation of V4 mask and v6 mask. Do you have a good reason for this? Without one I would prefer the general mask serving both IP versions. > 4.11 destinationPort > > SB> Again this would be less ambiguous if called > SB> transportDestinationPort Again fine with me. > 4.13 destinationMask > > Description: > > The number of contiguous bits that are relevant in the destination > address field of the IP packet header (i.e. the subnet mask in > slash notation). > > SB> Again in NF this is the IPv4 mask What would be the problem if we apply it to v6? > Abstract Data Type: octet > > Field Id: 13 > > Units: bits > > SB> Again there is the issue of directionality, and NF 24 and > SB> 25 define output counts. I think that this is a useful > SB> compression of data. Yes. Let's solve the in/out discussion above. > 4.25 anotherSourceMask > > SB> IPv6 > SB> I think that we need to take advisment from the IPv6 > SB> NF team before deleting. Remember that IPv6 has various > SB> transation and compatibility modes Does the description still match? > Description: > > The number of contiguous bits that are relevant in the source > address field of the IP packet header (i.e. the subnet mask in > slash notation). This redundant field has the same semantics as > field 9. > > Abstract Data Type: octet > > Field Id: 29 > > Units: bits > > 4.26 destinationMask > SB> As above > > 4.27 flowLabel > > SB> I think that this should have a V6 somewhere in it's name Fine. > 4.28 icmpTypeCode > > Description: Type and Code of the ICMP message. > > Abstract Data Type: unsigned16 > > Field Id: 32 > > Reference: See RFC 792 for a definition of the ICMP type and code > fields. > > SB> This needs some encoding info, because it's technically > SB> two octet fields in the header that are concatentated. > SB> I suggested making reference to network byte order. We do not have a byte order in the abstract data model. But you are right: this is ambiguous. We should state that the value is 256*type + code. > 4.31 samplingAlgorithm > > Description: > > The following sampling algorithms are defined: > > * 1 Deterministic sampling > > * 2 Random Sampling > > * 3 Time-based sampling > > > SB> As I recall Benoit suggested that #3 be deleted > > SB> NF has IPv4 source prefix #44 > SB> NF has IPv4 destination prefix #45 > SB> Please can we include them so that if they are needed > SB> in future we do not have a duplicate definition. Yes, there were several NF fields that I did not include, because of the limited time for editing the draft. Particularly, I did not include fields for which I needed some more discussion. Let's discuss all missing ones in Seoul. > SB> #46 and #47 are MPLS parameters in NF. These were > SB> deleted along with the other MPLS parameters in the > SB> list I supplied. > SB> > SB> Why are we not listing MPLS parameters? > SB> > SB> Also you have not included #55 destination CoS > SB> Again an observer may be placed at a point where > SB> this has been changed as part of a processing > SB> operation. > SB> > SB> You also miss out MAC and VLAN elements from the > SB> list. I know of cases where such information is > SB> vital to the policing and forensics of an IP network. > SB> > > > 4.37 ipVersion > > Description: The IP version field given in the IP header. > > Abstract Data Type: octet > > Field Id: 60 > > Units: flows > > Reference: > > See RFC 791 for a definition of the version field in the IPv6 > packet header. See RFC 2460 for a definition of the version field > in the IPv6 packet header. Additional information on defined > version numbers can be found at http://www.iana.org/assignments/ > version-numbers. > > SB> #61 you miss out direction Yes, I'd like to discuss this as well. > 4.38 ipNextHopAddressV6 > > Description: The IPv6 address of the next IP hop to which packets are > forwarded. > > Abstract Data Type: ipv6Address > > Field Id: 62 > > > 4.39 bgpNextHopAddressV6 > > Description: The IPv6 address of the next BGP hop to which packets > are forwarded. > > Abstract Data Type: ipv6Address > > Data Type Semantics: identifier > > Field Id: 63 > > Reference: See RFC 1771 for a description of BGB-4 and see RFC 1930 a > definition of the AS number. > > SB> I know that the definition is scruffy, but 64 is the NF > SB> method of reporting IPv6 options. This will be needed in some > SB> form or other. Agreed. > SB> #70 to #79 are the MPLS label stack. Why are they > SB> omitted? Again, just a bit of discussion needed. > 4.44 droppedOctetCount > > Description: The number of octets dropped. > > SB> We need a more complete definition for this > SB> Same for 85 > > SB> Again I included an MPLS IE at 85 that has been dropped > > > SB> Text also needs to make reference to the fact > SB> that 1 to 79 inc are reserved for NF and must > SB> not be redefined, or at least not allocated > SB> by IANA. As things stand it looks like IANA > SB> is free to fill in the gaps. I want to explicitly list the gaps after we have completed discussion on all NF fields. > - Stewart Thanks again, Juergen -- Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ From majordomo@mil.doit.wisc.edu Wed Feb 18 23:30:42 2004 Received: from mil.doit.wisc.edu (mil.doit.wisc.edu [128.104.31.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12488 for ; Wed, 18 Feb 2004 23:30:42 -0500 (EST) Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1AtfP0-0006kL-00 for ipfix-list@mil.doit.wisc.edu; Wed, 18 Feb 2004 22:03:07 -0600 Received: from [130.216.191.4] (helo=mailhost2.auckland.ac.nz) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1AtfOz-0006kF-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 18 Feb 2004 22:03:05 -0600 Received: from mailhost.auckland.ac.nz (mailhost [130.216.191.61]) by mailhost2.auckland.ac.nz (8.12.9/8.12.9/8.12.9-ua) with ESMTP id i1J42heU029676; Thu, 19 Feb 2004 17:02:44 +1300 (NZDT) Received: from localhost (mailhost.auckland.ac.nz [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CBE3333E6F; Thu, 19 Feb 2004 17:02:43 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (mailhost.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21430-01-51; Thu, 19 Feb 2004 17:02:41 +1300 (NZDT) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9F7EE33E69; Thu, 19 Feb 2004 17:02:41 +1300 (NZDT) Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.11.6/8.11.6) id i1J3vDJ24960; Thu, 19 Feb 2004 16:57:13 +1300 Received: from nebbiolo.itss.auckland.ac.nz (nebbiolo.itss.auckland.ac.nz [130.216.4.167]) by webmail.auckland.ac.nz (Horde) with HTTP for ; Thu, 19 Feb 2004 16:57:13 +1300 Message-ID: <1077163033.cb3a72ead0fbf@webmail.auckland.ac.nz> Date: Thu, 19 Feb 2004 16:57:13 +1300 From: Nevil Brownlee To: Juergen Quittek Cc: Benoit Claise , ipfix-protocol@net.doit.wisc.edu, nevil@auckland.ac.nz Subject: Re: PROTO-12 Re: [ipfix-protocol] IPFIX protocol draft: list of issues References: <402C14CA.30407@cisco.com> <2147483647.1077029766@[10.1.1.171]> In-Reply-To: <2147483647.1077029766@[10.1.1.171]> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 130.216.4.167 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver Content-Transfer-Encoding: 7bit Hi Juergen et al: I like your suggestions for simplifying the IPFIX protocol, i.e. we finish up with something very simple, like this (using 'block' instead of 'flowset' to describe it): IPFIX packet ::=
+ # one or more blocks ::= |