From chelsei@grassusa.com Thu Jun 01 01:19:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flfb9-0006lC-Bb for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 01:19:55 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flfaa-0000V1-4o for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 01:19:23 -0400 Received: from [201.153.152.189] (helo=grassusa.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FlfUV-0000G0-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 00:13:04 -0500 Message-ID: <000001c6853a$0622a910$e168a8c0@hyk1> Reply-To: "Chelsey Ashbaugh" From: "Chelsey Ashbaugh" To: ipfix-list@mil.doit.wisc.edu Subject: Re: refnance it Date: Wed, 31 May 2006 22:12:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C684FF.59C3D110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C684FF.59C3D110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D d ea q r H z om y e O f wne u r, Your c s re a di e t doesn't matter to us! If you OVV p N r u ea a l e i st x at n e and want I d MME q DIA k TE c i as l h to s m pe s nd ANY way you like, or simply wish to L h OW w ER your monthly pa i ym y ent r s by a third or more, here are the d c ea v ls d we have T f ODA n Y: $ 4 s 90 , 00 q 0 a h s l e ow a i s 3 , 6 v 5 % $ 3 s 70 , 00 g 0 a i s l g ow a x s 3 , 9 u 0 % $ 25 n 0 , 00 q 0 a o s lo b w a b s 3 , 3 u 5 % $ 2 i 00 , 00 d 0 a n s l p ow a i s 3 , 5 r 5 % V m isi m t ou k r web s v it v e Chelsey Ashbaugh , Ap t pr t ov z al M p ana b ge k r Before we go, I suppose you mean, said Thorin. Arent you the burglar? And isnt sitting on the door-step your job, not to speak of getting inside the door? But I agree about bed and breakfast. I like eggs with my ham, when starting on a journey: fried not poached, and ------=_NextPart_000_0001_01C684FF.59C3D110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D d ea q r H z om y e O f wne u r,

Your c s re a di e t doesn't matter to us!

If you OVV p N r u ea a l e i st x at n e and want I d MME q DIA k TE c i as l h to s m pe s nd ANY
way you like, or simply wish to L h OW w ER your monthly pa i ym y ent r s
=20 by a third or more, here are the d c ea v ls d we have T f ODA n Y:

$ 4 s 90 , 00 q 0 a h s l e ow a i s 3 , 6 v 5 %
$ 3 s 70 , 00 g 0 a i s l g ow a x s 3 , 9 u 0 %
$ 25 n 0 , 00 q 0 a o s lo b w a b s 3 , 3 u 5 %
$ 2 i 00 , 00 d 0 a n s l p ow a i s 3 , 5 r 5 %

V m isi m t ou k r web s v it v e

Chelsey Ashbaugh , Ap t pr t ov z al M p ana b ge k r

Before we go, I suppose you mean, = said Thorin. Arent you the
burglar? And isnt sitting on the door-step your job, not to speak of
getting inside the door? But I agree about bed and breakfast. I like
eggs with my ham, when starting on a journey: fried not poached, = and
------=_NextPart_000_0001_01C684FF.59C3D110-- From majordomo@mil.doit.wisc.edu Thu Jun 01 03:55:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fli1s-0002Ss-HB for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 03:55:40 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fli1r-0008HE-7y for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 03:55:40 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FlhwU-00038f-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 02:50:06 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FlhwT-00038a-00 for ipfix@net.doit.wisc.edu; Thu, 01 Jun 2006 02:50:05 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k517nw724129; Thu, 1 Jun 2006 09:49:58 +0200 (CEST) Received: from [10.61.81.94] (ams3-vpn-dhcp4447.cisco.com [10.61.81.94]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k517nuC01771; Thu, 1 Jun 2006 09:49:56 +0200 (CEST) Message-ID: <447E9C25.5030003@cisco.com> Date: Thu, 01 Jun 2006 09:49:57 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: "Wijnen, Bert (Bert)" , "'Ipfix Wg' (E-mail) (E-mail)" , "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: Re: INFO-AD#4, was Re: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt References: <6568A4DCD0BE1C9C5C1071AD@753F3B888A9969457862729D> <447419B4.4070801@cisco.com> <7930A36E6DCDB76DF62EB1ED@[192.168.1.130]> In-Reply-To: <7930A36E6DCDB76DF62EB1ED@[192.168.1.130]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Juergen, > Benoit, > > --On 24.05.2006 10:30 Uhr +0200 Benoit Claise wrote: >> >>>>> - INFO-AD#4: How to add new label types to the definition of >>>>> IE #46 mplsTopLabelType? >>>> The references from RFC 3954 have been assigned by the NetFlow >>>> development team >>>> >>>> MPLS_TOP_LABEL_TYPE 46 1 MPLS Top Label Type: >>>> 0x00 UNKNOWN >>>> 0x01 TE-MIDPT >>>> 0x02 ATOM >>>> 0x03 VPN >>>> 0x04 BGP >>>> 0x05 LDP >>>> >>>> I could not find any IANA registry for that. >>>> So I guess we have only one choice, i.e. assign a new registry for it >>>> in IANA. >>> >>> Would this be worth the effort? >> Do we have another solution? > > The alternative would be a fixed list that cannot be extended. > We could add a value '0x06 other' for cases not known today. > > If we decide to go to IANA, we probably would have to revise > the IE definition in order to avoid ambiguities: > The current definition says: > > - 0x01 TE-MIDPT: Any TE tunnel mid-point or tail label > - 0x02 Pseudowire: Any PWE3 or Cisco AToM based label > - 0x03 VPN: Any label associated with VPN > - 0x04 BGP: Any label associated with BGP or BGP routing > - 0x05 LDP: Any label associated with dynamically assigned > labels using LDP > > sub-issue 1: We should add value 0x00 for unknown types. I will do so. Fine. > sub-issue 2: Shall we add a value for known but not encoded types, for > example, by adding "0x06 other label types"? "others" is somehow incompatible with the IANA registration. "others" contains everything until you have a new type... Regards, Benoit. > sub-issue 3: We should eliminate potential ambiguities. "Any label > associated with ..." seems to be a bit vague. > Can we exclude that labels for TE tunnel, PW3, VPNs > are created using LDP? If not we should comment on this > case, for example by requesting that the lowest (or highest?) > matching type number should be used in cases where more > than one applies. > sub-issue 4: Has anyone yet checked if there is any MIB module that > defines something like an MPLS label type? If yes, > we might find useful hints there. If not, I wonder why > MPLS manaement systems do not find this information useful. > > > Thanks, > > Juergen > >> 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 Jun 01 03:58:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fli48-00036O-2J for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 03:58:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fli46-00009p-Mj for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 03:58:00 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Flhyh-0003Ai-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 02:52:23 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Flhyg-0003Ad-00 for ipfix@net.doit.wisc.edu; Thu, 01 Jun 2006 02:52:22 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k517qIT24296; Thu, 1 Jun 2006 09:52:18 +0200 (CEST) Received: from [10.61.81.94] (ams3-vpn-dhcp4447.cisco.com [10.61.81.94]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k517qGC03516; Thu, 1 Jun 2006 09:52:17 +0200 (CEST) Message-ID: <447E9CB1.4080700@cisco.com> Date: Thu, 01 Jun 2006 09:52:17 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: kobayashi atsushi CC: Juergen Quittek , "Wijnen, Bert (Bert)" , "'Ipfix Wg' (E-mail) (E-mail)" , "Dan Romascanu (E-mail)" , "David Kessens (E-mail)" Subject: Re: INFO-AD#4, was Re: [ipfix] AD review for: draft-ietf-ipfix-info-11.txt References: <20060526102858.59FA.AKOBA@nttv6.net> <033887163C3F804143C0C0B1@[192.168.1.130]> <20060526122230.5A02.AKOBA@nttv6.net> In-Reply-To: <20060526122230.5A02.AKOBA@nttv6.net> Content-Type: multipart/alternative; boundary="------------040302040409000205060404" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 This is a multi-part message in MIME format. --------------040302040409000205060404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, > Dear Juergen, > > This type seems to present what protocols allocates this label and how to > allocate it. I can find that this label is allocated by RSVP-TE, if this type > is 0x01 TE-MIDPT. > In the case of 0x02 PW, it is allocated by target-LDP with VCID. > But, in the case of 0x03 VPN, I don't sure what protocols allocates this label. > It can apply several patterns, for example, there are L3VPN, PW, VPLS. > I would like to eliminate such vague in this type, if it is not clear. > > If I receive 0x03 VPN, I cannot decide which MIB modules should be > selected. > Actually, the 0x03 VPN should really be BGP. An older version of our code did return VPN, but we decided it is more accurate to return BGP instead. Regards, Benoit. > Thanks, > Atsushi KOBAYASHI > > >>> For example, if this type is TE-MIDPT, we can get related TE >>> informations from MPLS-TE-MIB. If it is LDP, we can select MPLS-LSR-MIB. >>> If it is PW, we can select MPLS-PW-MIB. If it is BGP, we can't select >>> particular MIB. In that case, there is not particular MIB and it is only >>> method that we search information from BGP full dump. >>> >>> I think that this type is more useful if this type is related with each MIB >>> module. I felt that 0x03 VPN type is vague, in that point. >>> >> Would you (or someone else) have a suggestion how to improve the description >> of this type? >> >> Thanks, >> >> Juergen >> >> >>> Thanks, >>> Atsushi KOBAYASHI >>> >>> >>> >>> >>> >>> --- >>> Atsushi KOBAYASHI >>> NTT Information Sharing Platform Lab. >>> tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652 >>> >>> >>> >> >> -- >> 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/ >> > > --- > Atsushi KOBAYASHI > NTT Information Sharing Platform Lab. > tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652 > --------------040302040409000205060404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,
Dear Juergen,

This type seems to present what protocols allocates this label and how to
allocate it. I can find that this label is allocated by RSVP-TE, if this type
is 0x01 TE-MIDPT.
In the case of 0x02 PW, it is allocated by target-LDP with VCID.
But, in the case of 0x03 VPN, I don't sure what protocols allocates this label.
It can apply several patterns, for example, there are L3VPN, PW, VPLS.
I would like to eliminate such vague in this type, if it is not clear.

If I receive 0x03 VPN, I cannot decide which MIB modules should be
selected. 
  
Actually, the 0x03 VPN should really be BGP.
An older version of our code did return VPN, but we decided it is more accurate to return BGP instead.

Regards, Benoit.
Thanks,
Atsushi KOBAYASHI

  
For example, if this type is TE-MIDPT, we can get related TE
informations from MPLS-TE-MIB. If it is LDP, we can select MPLS-LSR-MIB.
If it is PW, we can select MPLS-PW-MIB. If it is BGP, we can't select
particular MIB. In that case, there is not particular MIB and it is only
method that we search information from BGP full dump.

I think that this type is more useful if this type is related with each MIB
module. I felt that 0x03 VPN type is vague, in that point.
      
Would you (or someone else) have a suggestion how to improve the description
of this type?

Thanks,

    Juergen

    
Thanks,
Atsushi KOBAYASHI





---
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652


      

--
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/
    

--- 
Atsushi KOBAYASHI  <akoba@nttv6.net>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652
  

--------------040302040409000205060404-- -- 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 Jun 01 04:20:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FliQI-0001oR-RL for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 04:20:54 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FliQG-0002Ws-JO for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 04:20:54 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FlhoH-0002A7-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 02:41:37 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FlhoG-0002A2-00 for ipfix-info@net.doit.wisc.edu; Thu, 01 Jun 2006 02:41:36 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k517fZI23620 for ; Thu, 1 Jun 2006 09:41:35 +0200 (CEST) Received: from [10.61.81.94] (ams3-vpn-dhcp4447.cisco.com [10.61.81.94]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k517fYC25748 for ; Thu, 1 Jun 2006 09:41:34 +0200 (CEST) Message-ID: <447E9A2E.3090404@cisco.com> Date: Thu, 01 Jun 2006 09:41:34 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipfix-info@net.doit.wisc.edu Subject: [ipfix-info] Request for new I.E. MPLSL3VpnRouteDistinguisher Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Dear all, I would like to request a new I.E. MPLSL3VpnRouteDistinguisher Description: The route distinguisher ensures that the same address can be used in several different MPLS VPNs, and that it is possible for BGP to carry several completely different routes to that address, one for each VPN. If this MPLS label is registered due to VRF-specific routing, this information element represents the route distinguisher associated with the particular VRF. According to [RFC4364] the route distinguisher is encoded into a string of 8 octets. Abstract Data Type: string Data Type Semantics: identifier ElementId: 90 Status: current Reference: See RFC 4364 [RFC4364] for the route distinguisher specification. See RFC 4382 [RFC4382] for the specification of the MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base. Notes: - this I.E. is currently in the reserved ElementId range. However, I think it would benefit everybody - it should be added in the "Sub-IP Header Fields" section. 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 Jun 01 05:29:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FljUq-0008RI-Lu for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 05:29:40 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FljUp-0001mT-DU for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 05:29:40 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FljHp-0000bz-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 04:16:13 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FljHn-0000bt-00 for ipfix-info@net.doit.wisc.edu; Thu, 01 Jun 2006 04:16:11 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2AFF11BAC4D; Thu, 1 Jun 2006 11:06:36 +0200 (CEST) Date: Thu, 01 Jun 2006 11:15:59 +0200 From: Juergen Quittek To: Benoit Claise , ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] Request for new I.E. MPLSL3VpnRouteDistinguisher Message-ID: In-Reply-To: <447E9A2E.3090404@cisco.com> References: <447E9A2E.3090404@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Benoit, --On 01.06.2006 9:41 Uhr +0200 Benoit Claise wrote: > Dear all, > I would like to request a new I.E. > > MPLSL3VpnRouteDistinguisher Why is there a '3' in the name? If we keep it consistent with other MPLS IEs, the first four letters would be lower case letters. > Description: > The route distinguisher ensures that the same address can be used in several > different MPLS VPNs, and that it is possible for BGP to carry several completely > different routes to that address, one for each VPN. If this MPLS label is > registered due to VRF-specific routing, this information element represents the route distinguisher associated with the particular VRF. According to [RFC4364] > the route distinguisher is encoded into a string of 8 octets. > Abstract Data Type: string > Data Type Semantics: identifier > ElementId: 90 > Status: current > Reference: See RFC 4364 [RFC4364] for the route distinguisher specification. > See RFC 4382 [RFC4382] for the specification of the MPLS/BGP Layer 3 > Virtual Private Network (VPN) Management Information Base. > > Notes: > - this I.E. is currently in the reserved ElementId range. However, I think it would benefit everybody No problem. We can take it our of the reserved range. > - it should be added in the "Sub-IP Header Fields" section. Fine. Thanks, Juergen > 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/ -- 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 Jun 01 07:47:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flle3-0000MI-Vw for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 07:47:20 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flle1-00006P-NZ for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 07:47:19 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FllVZ-0003N5-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 06:38:33 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FllVY-0003N0-00 for ipfix-info@net.doit.wisc.edu; Thu, 01 Jun 2006 06:38:32 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k51BcVg09375; Thu, 1 Jun 2006 13:38:31 +0200 (CEST) Received: from [10.61.81.190] (ams3-vpn-dhcp4543.cisco.com [10.61.81.190]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k51BcUC13637; Thu, 1 Jun 2006 13:38:30 +0200 (CEST) Message-ID: <447ED1B6.4080608@cisco.com> Date: Thu, 01 Jun 2006 13:38:30 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-info@net.doit.wisc.edu Subject: Re: [ipfix-info] Request for new I.E. MPLSL3VpnRouteDistinguisher References: <447E9A2E.3090404@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi Juergen, > Hi Benoit, > > --On 01.06.2006 9:41 Uhr +0200 Benoit Claise wrote: > >> Dear all, >> I would like to request a new I.E. >> >> MPLSL3VpnRouteDistinguisher > > Why is there a '3' in the name? To match MplsL3VpnRouteDistinguisher in RFC4382. Now, no big deal if you want to remove it. Regards, Benoit. > > If we keep it consistent with other MPLS IEs, the first four letters > would be lower case letters. > >> Description: >> The route distinguisher ensures that the same address can be >> used in several >> different MPLS VPNs, and that it is possible for BGP to carry >> several completely >> different routes to that address, one for each VPN. If this >> MPLS label is >> registered due to VRF-specific routing, this information >> element represents the route distinguisher associated with >> the particular VRF. According to [RFC4364] >> the route distinguisher is encoded into a string of 8 octets. >> Abstract Data Type: string >> Data Type Semantics: identifier >> ElementId: 90 >> Status: current >> Reference: See RFC 4364 [RFC4364] for the route >> distinguisher specification. >> See RFC 4382 [RFC4382] for the specification of the MPLS/BGP >> Layer 3 >> Virtual Private Network (VPN) Management Information Base. >> >> Notes: >> - this I.E. is currently in the reserved ElementId range. However, I >> think it would benefit everybody > > No problem. We can take it our of the reserved range. > >> - it should be added in the "Sub-IP Header Fields" section. > > Fine. > > Thanks, > > Juergen > >> 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/ -- 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 trace@hillintl.com Thu Jun 01 10:11:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlntO-0008Nu-TG for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 10:11:18 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlntN-0006Km-IN for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 10:11:18 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FlnEF-00032j-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 08:28:47 -0500 Received: from hillintl.com ([69.79.116.240]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k51DSjJx031638 for ; Thu, 1 Jun 2006 08:28:46 -0500 Message-ID: <000001c6857e$c539a260$fd43a8c0@asz24> Reply-To: "Trace Carlos" From: "Trace Carlos" To: ipfix-list@mil.doit.wisc.edu Subject: Re: refnance it Date: Thu, 1 Jun 2006 06:24:54 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68544.18DACA60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.8 (+) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68544.18DACA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D f ea g r H d om o e O n wne r r, Your c g re s di w t doesn't matter to us! If you OV y VN r o ea n l e o st b at k e and want I r MM x EDI i ATE c v as c h to s y pen c d ANY way you like, or simply wish to L u OW e ER your monthly pa a ym l ent i s by a third or more, here are the d i ea h ls j we have T r OD a AY: $ 49 p 0 , 00 w 0 a g s lo o w a f s 3 , 6 n 5 % $ 37 u 0 , 0 c 00 a k s l n ow a c s 3 , 9 t 0 % $ 25 l 0 , 00 j 0 a c s l d ow a n s 3 , 3 w 5 % $ 2 e 00 , 00 b 0 a a s lo b w a z s 3 , 5 e 5 % V o is l it o u ur web s u it m e =20 Trace Carlos , A p ppr g ova n l Ma m na m ge q r particularly want to see. Indeed! said they, and what may be your business? Whatever it is, its my own, my good elves. But if you wish ever to get back to your own woods from this cold cheerless place, he answered shivering, you ------=_NextPart_000_0001_01C68544.18DACA60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D f ea g r H d om o e O n wne r r,

Your c g re s di w t doesn't matter to us!

If you OV y VN r o ea n l e o st b at k e and want I r MM x EDI i ATE c v as c h to s y pen c d ANY
way you like, or simply wish to L u OW e ER your monthly pa a ym l ent i s
=20 by a third or more, here are the d i ea h ls j we have T r OD a AY:

$ 49 p 0 , 00 w 0 a g s lo o w a f s 3 , 6 n 5 %
$ 37 u 0 , 0 c 00 a k s l n ow a c s 3 , 9 t 0 %
$ 25 l 0 , 00 j 0 a c s l d ow a n s 3 , 3 w 5 %
$ 2 e 00 , 00 b 0 a a s lo b w a z s 3 , 5 e 5 %

V o is l it o u ur web s u it m e

Trace Carlos , A p ppr g ova n l Ma m na m ge q r

particularly want to see.
Indeed! said they, and what may be your business? Whatever it
is, its my own, my good elves. But if you wish ever to get back to = your
own woods from this cold cheerless place, he answered shivering, = you
------=_NextPart_000_0001_01C68544.18DACA60-- From majordomo@mil.doit.wisc.edu Thu Jun 01 10:58:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlodC-0003Ve-Rw for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 10:58:38 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlodA-0003VV-Hf for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 10:58:38 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Flo5a-0007Bp-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 09:23:54 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Flo5Z-0007Bk-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 01 Jun 2006 09:23:53 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k51ENoJ20458 for ; Thu, 1 Jun 2006 16:23:50 +0200 (CEST) Received: from [10.61.64.247] (ams3-vpn-dhcp247.cisco.com [10.61.64.247]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k51ENjC21565; Thu, 1 Jun 2006 16:23:45 +0200 (CEST) Message-ID: <447EF871.1050302@cisco.com> Date: Thu, 01 Jun 2006 16:23:45 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <447C5FEE.6070700@cisco.com> In-Reply-To: <447C5FEE.6070700@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Hi, Sorry to reply to myself, but I think this important issue should be corrected in the protocol draft. So a simple acknowledgment from the mailing list would be sufficient. Note: I've been asked by our AD to produce a new version of the protocol draft these days so that it could go on the agenda of the 6/8 IESG call. Regards, Benoit. > Dear all, > > I know it was addressed a couple of times on the mailing list. > However, while discussing with Lutz Mark and Paul Aitken, I think we > discovered the issue > > the definition of the observation domain id differs between > ipfix-arch and ipfix-proto. > > -in ipfix-arch the id is unique within the ipfix device > -in ipfix-proto the id is unique to the exporting process > > ------------------------------------------------------------ > > [ARCH] > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points within an IPFIX Device. > Each {Observation Point, Metering Process} pair belongs to a single > Observation Domain. An IPFIX Device could have multiple Observation > Domains, each of which has a subset of the total set of Observation > Points in it. Each Observation Domain must carry a unique ID within > the context of an IPFIX Device. Note that in case of multiple > Observation Domains, a unique ID per Observation Domain must be > transmitted as a parameter to the Exporting Function. That unique ID > is referred to as the IPFIX Observation Domain ID. > > > [PROTO] > 3.3 > Observation Domain ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify > to the Collecting Process the Observation Domain that > metered the Flows. Collecting Processes SHOULD use the > combination of the Exporter (exporterIPv4Address, > exporterIPv6Address, or exportingProcessId) and the > Observation Domain ID field to separate different export > streams originating from the same Exporting Process. The > Observation Domain ID SHOULD be 0 when no specific > Observation Domain ID is relevant for the entire IPFIX > Message. For example, when exporting the Exporting Process > Statistics, or in case of hierarchy of Collector when > aggregated data records are exported. > > > We think that the Observation Domain Id should be unique per IPFIX > Device, and not per Exporting Process. > Otherwise, we could end up in the following situation: one sysadmin > configures a set of observation points with observation domain 1, > while a second sysadmin configures another set of observation points > (on a different line card for example) with the same observation > domain Id. > If each observation domain exports using its own exporting process > with the source IP address, how would the collector differentiate the > template IDs? > > Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are not > in sync. > Multiple small changes (including in the terminology sections) should > be inserted. For example: IPFIX-PROTO observation domain definition > says "In the IPFIX Message it generates, the Observation Domain > includes its Observation Domain ID, which is unique per Exporting > Process. " > > Feedback? > > 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/ -- 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 Jun 01 11:42:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlpJT-0007TX-Nr for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 11:42:19 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlpJR-000894-Ag for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 11:42:19 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FlpDB-0004VI-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 10:35:49 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FlpD9-0004V9-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 01 Jun 2006 10:35:47 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3CC0711C; Thu, 1 Jun 2006 17:35:38 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17538-02; Thu, 1 Jun 2006 17:35:35 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 0ADD911B; Thu, 1 Jun 2006 17:35:34 +0200 (MST) Message-ID: <447F0914.4020209@informatik.uni-tuebingen.de> Date: Thu, 01 Jun 2006 17:34:44 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Benoit Claise Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <447C5FEE.6070700@cisco.com> <447EF871.1050302@cisco.com> In-Reply-To: <447EF871.1050302@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010504040709060001080807" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 This is a cryptographically signed message in MIME format. --------------ms010504040709060001080807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Benoit, I think your proposal is reasonable. ObservationID being unique with the IPFIX Device implies that it is also unique to the Exporting Process (unless somebody constructs a situation where one Exporting Process exports data from two devices ;) ). Regards, Gerhard Benoit Claise wrote: > Hi, >=20 > Sorry to reply to myself, but I think this important issue should be > corrected in the protocol draft. > So a simple acknowledgment from the mailing list would be sufficient. > Note: I've been asked by our AD to produce a new version of the protoco= l > draft these days so that it could go on the agenda of the 6/8 IESG call= . >=20 > Regards, Benoit. >> Dear all, >> >> I know it was addressed a couple of times on the mailing list. >> However, while discussing with Lutz Mark and Paul Aitken, I think we >> discovered the issue >> >> the definition of the observation domain id differs between >> ipfix-arch and ipfix-proto. >> >> -in ipfix-arch the id is unique within the ipfix device >> -in ipfix-proto the id is unique to the exporting process >> >> ------------------------------------------------------------ >> >> [ARCH] >> 5.4. Observation Domain >> >> The Observation Domain is a logical block that presents a single >> identity for a group of Observation Points within an IPFIX Device. >> Each {Observation Point, Metering Process} pair belongs to a single >> Observation Domain. An IPFIX Device could have multiple Observation >> Domains, each of which has a subset of the total set of Observation >> Points in it. Each Observation Domain must carry a unique ID within >> the context of an IPFIX Device. Note that in case of multiple >> Observation Domains, a unique ID per Observation Domain must be >> transmitted as a parameter to the Exporting Function. That unique I= D >> is referred to as the IPFIX Observation Domain ID. >> >> >> [PROTO] >> 3.3 >> Observation Domain ID >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Observation Domain ID to uniquely identify >> to the Collecting Process the Observation Domain that >> metered the Flows. Collecting Processes SHOULD use the >> combination of the Exporter (exporterIPv4Address, >> exporterIPv6Address, or exportingProcessId) and the >> Observation Domain ID field to separate different export >> streams originating from the same Exporting Process. The >> Observation Domain ID SHOULD be 0 when no specific >> Observation Domain ID is relevant for the entire IPFIX >> Message. For example, when exporting the Exporting Process >> Statistics, or in case of hierarchy of Collector when >> aggregated data records are exported. >> >> >> We think that the Observation Domain Id should be unique per IPFIX >> Device, and not per Exporting Process. >> Otherwise, we could end up in the following situation: one sysadmin >> configures a set of observation points with observation domain 1, >> while a second sysadmin configures another set of observation points >> (on a different line card for example) with the same observation >> domain Id. >> If each observation domain exports using its own exporting process >> with the source IP address, how would the collector differentiate the >> template IDs? >> >> Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are not >> in sync. >> Multiple small changes (including in the terminology sections) should >> be inserted. For example: IPFIX-PROTO observation domain definition >> says "In the IPFIX Message it generates, the Observation Domain >> includes its Observation Domain ID, which is unique per Exporting >> Process. " >> >> Feedback? >> >> Regards, Benoit. >> >> --=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 >=20 > --=20 > Help mailto:majordomo@net.doit.wisc.edu and say "help" in messag= e > body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms010504040709060001080807 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MDYwMTE1MzQ0NFowIwYJKoZIhvcNAQkEMRYEFFJv7/Vxs5t1 lsBplMJQjXmIKCNUMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQDPKKJi1PqH+ppPvcNsXbSGSVZ0ghV9MDQzWWupi53MBWkYFWe9ZFuzaBf4 bQAEMXj24DlmI7evSccmTNrO/OyspaXqAwkKXP8XIp6OHWLsCVS99G3bfAsd3lzibx+tO6HF rCGSE4n6xP4E89fO4B4wF0vnAbH9qOov/p1ImyS2PdbIw0AJHVO09FUnXWakEBm2qHlodhwq 8AXQ3PKSTB/abuemWYLkXJ0co5xWZ+wWCojMdHpC94ydFl086i0oJ/YqNLi2Xj4zotkcMRG0 qsz/ooVMzKkXm487+FjAkKT+KDns5TQ2h9xtS5EWrNMRaRm2rkRG6f0WHb68wcXwRIhoAAAA AAAA --------------ms010504040709060001080807-- -- 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 Jun 01 13:32:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flr2F-0006G3-Ok for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 13:32:39 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flr2E-0003cS-Ct for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 13:32:39 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Flqw6-0004N9-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 12:26:18 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Flqw5-0004N4-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 01 Jun 2006 12:26:17 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.19) with ESMTP id k51HQDaM017836 for ; Thu, 1 Jun 2006 13:26:15 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k51HPQre017814 for ; Thu, 1 Jun 2006 13:25:26 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k51HPQaS017812; Thu, 01 Jun 2006 13:25:26 -0400 (EDT) Received: from [128.237.241.155] (vpn-10-25-4-8.remote.cert.org [10.25.4.8]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.59) with ESMTP id k51HPQhF011344; Thu, 1 Jun 2006 13:25:26 -0400 In-Reply-To: <447C5FEE.6070700@cisco.com> References: <447C5FEE.6070700@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--923170748" Message-Id: <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> Cc: ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Date: Thu, 1 Jun 2006 13:25:20 -0400 To: Benoit Claise X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--923170748 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Benoit, Redefining the Observation Domain to be unique per (exporting) IPFIX Device partially fixes the problem, but it does not address the problem of Exporting Process/exporting device identification at the Collecting Process, of which the Exporting Process IP address collision issue is a subset. If an IPFIX device is using multihomed SCTP associations, for example, a Collecting Process may not treat two Observation Domains that are really identical as such. Therefore, I would propose again that instead of defining Observation Domains to be unique per exporting IPFIX Device, that Observation Domains are unique per Session, where a Session is a TCP connection, an SCTP association, or a (time-limited) UDP four-tuple. This grants the most flexibility to implementors while being, in my opinion, more logically sound... If an exporting device implementor wishes instead to enforce domain uniqueness per Device, that would be consistent with this definition. Regards, Brian On May 30, 2006, at 11:08 AM, Benoit Claise wrote: > Dear all, > > I know it was addressed a couple of times on the mailing list. > However, while discussing with Lutz Mark and Paul Aitken, I think > we discovered the issue > > the definition of the observation domain id differs between > ipfix-arch and ipfix-proto. > > -in ipfix-arch the id is unique within the ipfix device > -in ipfix-proto the id is unique to the exporting process > > ------------------------------------------------------------ > > [ARCH] > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points within an IPFIX Device. > Each {Observation Point, Metering Process} pair belongs to a single > Observation Domain. An IPFIX Device could have multiple Observation > Domains, each of which has a subset of the total set of Observation > Points in it. Each Observation Domain must carry a unique ID within > the context of an IPFIX Device. Note that in case of multiple > Observation Domains, a unique ID per Observation Domain must be > transmitted as a parameter to the Exporting Function. That > unique ID > is referred to as the IPFIX Observation Domain ID. > > > [PROTO] > 3.3 > Observation Domain ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify > to the Collecting Process the Observation Domain that > metered the Flows. Collecting Processes SHOULD use the > combination of the Exporter (exporterIPv4Address, > exporterIPv6Address, or exportingProcessId) and the > Observation Domain ID field to separate different export > streams originating from the same Exporting Process. The > Observation Domain ID SHOULD be 0 when no specific > Observation Domain ID is relevant for the entire IPFIX > Message. For example, when exporting the Exporting Process > Statistics, or in case of hierarchy of Collector when > aggregated data records are exported. > > > We think that the Observation Domain Id should be unique per IPFIX > Device, and not per Exporting Process. > Otherwise, we could end up in the following situation: one sysadmin > configures a set of observation points with observation domain 1, > while a second sysadmin configures another set of observation > points (on a different line card for example) with the same > observation domain Id. > If each observation domain exports using its own exporting process > with the source IP address, how would the collector differentiate > the template IDs? > > Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are > not in sync. > Multiple small changes (including in the terminology sections) > should be inserted. For example: IPFIX-PROTO observation domain > definition says "In the IPFIX Message it generates, the Observation > Domain includes its Observation Domain ID, which is unique per > Exporting Process. " > > Feedback? > > 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/ --Apple-Mail-1--923170748 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEfyME4/8LCZ4pwvYRAsfMAKDh3Z0Rw8hp5y9clq5vG9pJ2GFVJQCeN3v1 zEKB7mFlK1HcQrpPIrx/DU0= =e/Uf -----END PGP SIGNATURE----- --Apple-Mail-1--923170748-- -- 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 cout@ets.com Thu Jun 01 22:03:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flz0g-0003rw-Cm for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 22:03:34 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flz0e-00028k-MZ for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 22:03:34 -0400 Received: from [59.56.142.16] (helo=ets.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Flyrf-0001Kg-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 20:54:15 -0500 Message-ID: <000001c685e7$735fb6f0$a116a8c0@vfe0> Reply-To: "Cyriaca Coutu" From: "Cyriaca Coutu" To: ipfix-list@mil.doit.wisc.edu Subject: Re: oeyif refnnance Date: Thu, 1 Jun 2006 18:54:14 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C685AC.C700DEF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 6fc5b1c74c5bed09a3a9da2884900dec This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C685AC.C700DEF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D a ea l r H x om a e O p wn j er, Your c u re c di i t doesn't matter to us! If you O l VVN r i ea h l e w st m at y e and want I k MM a EDIA b TE c j as i h to s q pen p d ANY way you like, or simply wish to L m OW h ER your monthly p m ayme i nt j s by a third or more, here are the d e ea r ls c we have T p ODA g Y: $ 49 o 0 , 0 x 00 a y s lo z w a d s 3 , 6 l 5 % $ 37 j 0 , 00 q 0 a b s l l ow a n s 3 , 9 q 0 % $ 25 f 0 , 0 h 00 a m s lo w w a z s 3 , 3 f 5 % $ 20 n 0 , 0 x 00 a q s l f ow a c s 3 , 5 r 5 % V e is m it o s ur web s y it d e =20 Cyriaca Coutu , A n ppr z ova x l M v ana d ge u r horrible battle. Suddenly Bilbo noticed that some of the spiders had gathered round old Bombur on the floor, and had tied him up again and were dragging him away. He gave a shout and slashed at the spiders in front of him. They quickly gave way, and he scrambled and fell down the ------=_NextPart_000_0001_01C685AC.C700DEF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D a ea l r H x om a e O p wn j er,

Your c u re c di i t doesn't matter to us!

If you O l VVN r i ea h l e w st m at y e and want I k MM a EDIA b TE c j as i h to s q pen p d ANY
way you like, or simply wish to L m OW h ER your monthly p m ayme i nt j s
=20 by a third or more, here are the d e ea r ls c we have T p ODA g Y:

$ 49 o 0 , 0 x 00 a y s lo z w a d s 3 , 6 l 5 %
$ 37 j 0 , 00 q 0 a b s l l ow a n s 3 , 9 q 0 %
$ 25 f 0 , 0 h 00 a m s lo w w a z s 3 , 3 f 5 %
$ 20 n 0 , 0 x 00 a q s l f ow a c s 3 , 5 r 5 %

V e is m it o s ur web s y it d e

Cyriaca Coutu , A n ppr z ova x l M v ana d ge u r

horrible battle. Suddenly Bilbo noticed = that some of the spiders had
gathered round old Bombur on the floor, and had tied him up again = and
were dragging him away. He gave a shout and slashed at the spiders = in
front of him. They quickly gave way, and he scrambled and fell down = the
------=_NextPart_000_0001_01C685AC.C700DEF0-- From majordomo@mil.doit.wisc.edu Thu Jun 01 23:34:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm0QH-00074I-Vx for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 23:34:05 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm0QE-00028W-MN for ipfix-archive@lists.ietf.org; Thu, 01 Jun 2006 23:34:05 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fm0LE-0001hJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 01 Jun 2006 22:28:52 -0500 Received: from mail.nttv6.net ([192.68.245.115]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fm0LC-0001hE-00 for ipfix-info@net.doit.wisc.edu; Thu, 01 Jun 2006 22:28:50 -0500 Received: from [192.47.163.107] (dhcp-3-107.nttv6.com [192.47.163.107]) by mail.nttv6.net (8.13.6/8.13.5) with ESMTP id k523SkJm000584; Fri, 2 Jun 2006 12:28:46 +0900 (JST) (envelope-from akoba@nttv6.net) Date: Fri, 02 Jun 2006 12:28:50 +0900 From: kobayashi atsushi To: Benoit Claise Subject: Re: [ipfix-info] Request for new I.E. MPLSL3VpnRouteDistinguisher Cc: ipfix-info@net.doit.wisc.edu In-Reply-To: <447E9A2E.3090404@cisco.com> References: <447E9A2E.3090404@cisco.com> Message-Id: <20060602122325.418F.AKOBA@nttv6.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.12.01 [ja] Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Dear Benoit, It is good idea. It is useful for monitoring VPN customer's traffic and we can easily extract informations of MPLS-VPN-MIB. Regards, Atsushi KOBAYASHI On Thu, 01 Jun 2006 09:41:34 +0200 Benoit Claise wrote: > Dear all, > > I would like to request a new I.E. > > MPLSL3VpnRouteDistinguisher > > Description: > The route distinguisher ensures that the same address can be used in several > different MPLS VPNs, and that it is possible for BGP to carry several completely > different routes to that address, one for each VPN. If this MPLS label is > registered due to VRF-specific routing, this information element represents the > route distinguisher associated with the particular VRF. According to [RFC4364] > the route distinguisher is encoded into a string of 8 octets. > Abstract Data Type: string > Data Type Semantics: identifier > ElementId: 90 > Status: current > Reference: > See RFC 4364 [RFC4364] for the route distinguisher specification. > See RFC 4382 [RFC4382] for the specification of the MPLS/BGP Layer 3 > Virtual Private Network (VPN) Management Information Base. > > Notes: > - this I.E. is currently in the reserved ElementId range. However, I think it would benefit everybody > - it should be added in the "Sub-IP Header Fields" section. > > 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/ --- Atsushi KOBAYASHI NTT Information Sharing Platform Lab. tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652 -- 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 Jun 02 03:00:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3e0-0000Va-7n for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 03:00:28 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm3dy-00086N-Rj for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 03:00:28 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fm3Xz-0001pO-00 for ipfix-list@mil.doit.wisc.edu; Fri, 02 Jun 2006 01:54:15 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fm3Xx-0001pH-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 02 Jun 2006 01:54:13 -0500 Received: from [10.1.1.104] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 4F3DC1BAC4D; Fri, 2 Jun 2006 08:44:34 +0200 (CEST) Date: Fri, 02 Jun 2006 08:54:04 +0200 From: Juergen Quittek To: Brian Trammell , Benoit Claise Cc: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Message-ID: In-Reply-To: <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Brian and Benoit, I would favor the Observation Domain identifier to be unique per Exporting Process. I consider 'unique per session' as also feasible. But I do not think it is feasible to have the Observation Domain unique per IPFIX device. I see the following problems with this approach: - We would exclude cases where the Observation Domain is not on the same box as the exporter. There are four such cases discussed on RFC 3917, page 21 (protocol converter, remote observation point, concentrator, and proxy). According to the current definition of an IPFIX device in the protocol draft > IPFIX Device > > An IPFIX Device hosts at least one Observation Point, a Metering > Process and an Exporting Process. none of them are IPFIX devices. There is no point in asking an ID unique per IPFIX device if there is no IPFIX device present in the scenario. Let's assume we fix this by re-defining the term IPFIX device, for example, by stating that an IPFIX device hosts at least one of the following: an Observation Point, a Metering Process, or an Exporting Process. Then I still see problems with having the Observation Domain unique per IPFIX device: - How would two implementations (of potentially different vendors) in the same box coordinate their Observation Domain naming schemes? The IPFIX standard is not proposing one. - What would an exporter do that reports for several boxes? This could be in one of the cases mentioned above (protocol converter, remote observation point, concentrator, or proxy). In case of the concentrator, all input to the concentrator already uses Observation Domains that are unique to their respective IPFIX device. The concentrator would still not be able to use them without risking that two Observation Domains on different boxes have the same ID. Thanks, Juergen --On 01.06.2006 13:25 Uhr -0400 Brian Trammell wrote: > Benoit, > > Redefining the Observation Domain to be unique per (exporting) IPFIX > Device partially fixes the problem, but it does not address the > problem of Exporting Process/exporting device identification at the > Collecting Process, of which the Exporting Process IP address > collision issue is a subset. If an IPFIX device is using multihomed > SCTP associations, for example, a Collecting Process may not treat > two Observation Domains that are really identical as such. > > Therefore, I would propose again that instead of defining Observation > Domains to be unique per exporting IPFIX Device, that Observation > Domains are unique per Session, where a Session is a TCP connection, > an SCTP association, or a (time-limited) UDP four-tuple. This grants > the most flexibility to implementors while being, in my opinion, more > logically sound... If an exporting device implementor wishes instead > to enforce domain uniqueness per Device, that would be consistent > with this definition. > > Regards, > > Brian > > On May 30, 2006, at 11:08 AM, Benoit Claise wrote: > >> Dear all, >> >> I know it was addressed a couple of times on the mailing list. >> However, while discussing with Lutz Mark and Paul Aitken, I think >> we discovered the issue >> >> the definition of the observation domain id differs between >> ipfix-arch and ipfix-proto. >> >> -in ipfix-arch the id is unique within the ipfix device >> -in ipfix-proto the id is unique to the exporting process >> >> ------------------------------------------------------------ >> >> [ARCH] >> 5.4. Observation Domain >> >> The Observation Domain is a logical block that presents a single >> identity for a group of Observation Points within an IPFIX Device. >> Each {Observation Point, Metering Process} pair belongs to a single >> Observation Domain. An IPFIX Device could have multiple Observation >> Domains, each of which has a subset of the total set of Observation >> Points in it. Each Observation Domain must carry a unique ID within >> the context of an IPFIX Device. Note that in case of multiple >> Observation Domains, a unique ID per Observation Domain must be >> transmitted as a parameter to the Exporting Function. That >> unique ID >> is referred to as the IPFIX Observation Domain ID. >> >> >> [PROTO] >> 3.3 >> Observation Domain ID >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Observation Domain ID to uniquely identify >> to the Collecting Process the Observation Domain that >> metered the Flows. Collecting Processes SHOULD use the >> combination of the Exporter (exporterIPv4Address, >> exporterIPv6Address, or exportingProcessId) and the >> Observation Domain ID field to separate different export >> streams originating from the same Exporting Process. The >> Observation Domain ID SHOULD be 0 when no specific >> Observation Domain ID is relevant for the entire IPFIX >> Message. For example, when exporting the Exporting Process >> Statistics, or in case of hierarchy of Collector when >> aggregated data records are exported. >> >> >> We think that the Observation Domain Id should be unique per IPFIX >> Device, and not per Exporting Process. >> Otherwise, we could end up in the following situation: one sysadmin >> configures a set of observation points with observation domain 1, >> while a second sysadmin configures another set of observation >> points (on a different line card for example) with the same >> observation domain Id. >> If each observation domain exports using its own exporting process >> with the source IP address, how would the collector differentiate >> the template IDs? >> >> Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are >> not in sync. >> Multiple small changes (including in the terminology sections) >> should be inserted. For example: IPFIX-PROTO observation domain >> definition says "In the IPFIX Message it generates, the Observation >> Domain includes its Observation Domain ID, which is unique per >> Exporting Process. " >> >> Feedback? >> >> 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/ > -- 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 Jun 02 07:55:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Fg-0007dI-NR for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 07:55:40 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8Fd-00040q-VY for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 07:55:40 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fm7a2-00046Y-00 for ipfix-list@mil.doit.wisc.edu; Fri, 02 Jun 2006 06:12:38 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fm7Zz-00046T-00 for ipfix@net.doit.wisc.edu; Fri, 02 Jun 2006 06:12:35 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k52BCXn02409 for ; Fri, 2 Jun 2006 13:12:34 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C68635.72A64171" Subject: [ipfix] AS draft update Date: Fri, 2 Jun 2006 13:12:36 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA11C7684@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: AS draft update Thread-Index: AcaGNXPZ5NpUkOJETrS2HcbpeeLNlQ== From: "Tanja Zseby" To: Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 357ebc7cf4b4412c052977434485f95c This is a multi-part message in MIME format. ------_=_NextPart_001_01C68635.72A64171 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, I submitted a new version of the IPFIX applicability statement (attached). I mainly updated the RMON section.=20 Many thanks to Benoit for his valuable input to this. Regards, Tanja ------_=_NextPart_001_01C68635.72A64171 Content-Type: text/plain; name="draft-ietf-ipfix-as-08.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ipfix-as-08.txt Content-Disposition: attachment; filename="draft-ietf-ipfix-as-08.txt" DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFuamEgWnNlYnkgDQogRG9jdW1lbnQ6IDxk cmFmdC1pZXRmLWlwZml4LWFzLTA4LnR4dD4gICAgICAgICAgICAgICAgIEZyYXVuaG9mZXIgRk9L VVMgDQogRXhwaXJlczogTm92ZW1iZXIgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFbGlzYSBCb3NjaGkgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhpdGFjaGkgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV2aWwgQnJvd25sZWUg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ0FJREEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEJlbm9pdCBDbGFpc2UgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDYgDQogIA0KICAgICANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgDQogICAgICAgICAgICAgICAgICAg ICAgICBkcmFmdC1pZXRmLWlwZml4LWFzLTA4LnR4dCANCiAgDQogICAgU3RhdHVzIG9mIHRoaXMg TWVtbyANCiAgICAgDQogICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNo IGF1dGhvciByZXByZXNlbnRzIHRoYXQgDQogICAgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9yIG90 aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIA0KICAgIGF3YXJlIGhhdmUgYmVl biBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgDQogICAg YmVjb21lcyBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rp b24gNiBvZiAgDQogICAgQkNQIDc5LiANCiAgICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgDQogICAgRW5naW5lZXJpbmcgVGFzayBG b3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIA0KICAgIGdyb3Vwcy4gIE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIA0KICAgIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICANCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCANCiAgICBtb250aHMgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA0KICAgIGRv Y3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0 LQ0KICAgIERyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgDQogICAgaW4gcHJvZ3Jlc3MuIiAgDQogICAgIA0KICAgIFRoZSBsaXN0 IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgICBodHRw Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuIA0KICAgICANCiAgICBUaGUg bGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2Vk IGF0ICANCiAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiAgDQogICAgIA0KICAg IENvcHlyaWdodCBOb3RpY2UgIA0KICAgICANCiAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5l dCBTb2NpZXR5ICgyMDA2KS4gDQogIA0KICAgICANCiAgICAgDQogICAgIA0KICAgICANCg0KDQoN Cg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSAxXSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0 eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICANCiAgICBBYnN0cmFjdCANCiAgICAg DQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIElQ IEZsb3cgDQogICAgSW5mb3JtYXRpb24gRXhwb3J0IChJUEZJWCkgcHJvdG9jb2wgZm9yIGEgdmFy aWV0eSBvZiANCiAgICBhcHBsaWNhdGlvbnMuIEl0IHNob3dzIGhvdyBhcHBsaWNhdGlvbnMgY2Fu IHVzZSBJUEZJWCwgZGVzY3JpYmVzIA0KICAgIHRoZSByZWxldmFudCBpbmZvcm1hdGlvbiBlbGVt ZW50cyAoSUVzKSBhbmQgc2hvd3Mgb3Bwb3J0dW5pdGllcyANCiAgICBhbmQgbGltaXRhdGlvbnMg b2YgdGhlIHByb3RvY29sLiBUaGUgZG9jdW1lbnQgZnVydGhlcm1vcmUgDQogICAgZGVzY3JpYmVz IHJlbGF0aW9ucyBvZiB0aGUgSVBGSVggZnJhbWV3b3JrIHRvIG90aGVyIA0KICAgIGFyY2hpdGVj dHVyZXMgYW5kIGZyYW1ld29ya3MuIA0KICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogWnNl YnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDJdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAg ICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogVGFibGUgb2YgQ29udGVudHMgDQogICAgMS4gICBJ bnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40 IA0KICAgIDIuICAgQXBwbGljYXRpb25zIG9mIElQRklYLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNCANCiAgICAyLjEgIEFjY291bnRpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQogICAgMi4xLjEgRXhhbXBsZS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41IA0KICAgIDIuMiAgVHJhZmZp YyBQcm9maWxpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAg ICAyLjMgIFRyYWZmaWMgRW5naW5lZXJpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjcgDQogICAgMi40ICBOZXR3b3JrIFNlY3VyaXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi44IA0KICAgIDIuNSAgUW9TIE1vbml0b3JpbmcuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMCANCiAgICAyLjUuMSBDb3JyZWxhdGlu ZyBFdmVudHMgZnJvbSBNdWx0aXBsZSBPYnNlcnZhdGlvbiBQb2ludHMuLi4uMTEgDQogICAgMi41 LjIgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjExIA0KICAgIDIuNiAgSW50ZXItRG9tYWluIEV4Y2hhbmdlIG9mIElQRklYIGRhdGEuLi4uLi4u Li4uLi4uLi4uLi4uLi4xMyANCiAgICAyLjcgIEV4cG9ydCBvZiBEZXJpdmVkIE1ldHJpY3MuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMgDQogICAgMi44ICBTdW1tYXJ5Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE0IA0KICAgIDMuICAgUmVs YXRpb24gb2YgSVBGSVggdG8gT3RoZXIgRnJhbWV3b3JrcyBhbmQgUHJvdG9jb2xzLi4uLi4xNCAN CiAgICAzLjEgIElQRklYIGFuZCBQU0FNUC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTQgDQogICAgMy4yICBJUEZJWCBhbmQgUk1PTi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjE1IA0KICAgIDMuMyAgSVBGSVggYW5kIElQUE0uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNiANCiAgICAzLjQgIElQRklYIGFu ZCBBQUEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYgDQogICAg My40LjEgQ29ubmVjdGluZyB2aWEgYW4gQUFBIENsaWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjE3IA0KICAgIDMuNC4yIENvbm5lY3RpbmcgdmlhIGFuIEFwcGxpY2F0aW9uIFNwZWNpZmlj IE1vZHVsZSAoQVNNKS4uLi4xOCANCiAgICAzLjUgIElQRklYIGFuZCBSVEZNLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTkgDQogICAgMy41LjEgQXJjaGl0ZWN0dXJl Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5IA0KICAgIDMuNS4y IEZsb3cgRGVmaW5pdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x OSANCiAgICAzLjUuMyBDb25maWd1cmF0aW9uIGFuZCBNYW5hZ2VtZW50Li4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMjAgDQogICAgMy41LjQgRGF0YSBDb2xsZWN0aW9uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwIA0KICAgIDMuNS41IERhdGEgTW9kZWwgRGV0YWls cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMCANCiAgICAzLjUuNiBUcmFu c3BvcnQgUHJvdG9jb2wuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjAgDQog ICAgMy41LjcgU3VtbWFyeS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjIxIA0KICAgIDQuICAgTGltaXRhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yMSANCiAgICA0LjEgIFVzaW5nIElQRklYIGZvciBvdGhlciBB cHBsaWNhdGlvbnMgdGhhbiBpbiBSRkMzOTE3Li4uLi4uMjEgDQogICAgNC4yICBVc2luZyBhIERp ZmZlcmVudCBUcmFuc3BvcnQgUHJvdG9jb2wgdGhhbiBTQ1RQLi4uLi4uLi4uLjIyIA0KICAgIDQu MyAgUHVzaCB2cy4gUHVsbCBNb2RlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4yMiANCiAgICA0LjQgIFRlbXBsYXRlIElEIG51bWJlci4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjMgDQogICAgNC41ICBFeHBvcnRpbmcgQmlkaXJlY3Rpb25hbCBGbG93 IEluZm9ybWF0aW9uLi4uLi4uLi4uLi4uLi4uLjIzIA0KICAgIDQuNiAgSVBGSVggYW5kIElQdjYu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMyANCiAgICA1LiAgIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjQg DQogICAgNi4gICBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjI0IA0KICAgIDcuICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yNSANCiAgICA4LiAgIEFja25vd2xlZGdlbWVudHMuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjcgDQogICAgOS4gICBBdXRob3Jz JyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI3IA0KICAg IDEwLiAgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4yOCANCiAgICAxMS4gIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMjggDQogICAgMTIuICBDb3B5cmlnaHQgU3RhdGVtZW50Li4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI5IA0KICAgIDEzLiAgRGlzY2xhaW1lci4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yOSANCiAgICAgDQog IA0KDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAg ICAgICAgICAgICAgICAgW1BhZ2UgM10gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFw cGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAxLiBJbnRyb2R1Y3Rp b24gDQogIA0KICAgIFRoZSBJUEZJWCBwcm90b2NvbCBkZWZpbmVzIGhvdyBJUCBGbG93IGluZm9y bWF0aW9uIGNhbiBiZSANCiAgICBleHBvcnRlZCBmcm9tIHJvdXRlcnMsIG1lYXN1cmVtZW50IHBy b2JlcyBvciBvdGhlciBkZXZpY2VzLiBJdCANCiAgICBpcyBpbnRlbmRlZCB0byBwcm92aWRlIHRo aXMgaW5mb3JtYXRpb24gYXMgaW5wdXQgdG8gdmFyaW91cyANCiAgICBhcHBsaWNhdGlvbnMuIElQ RklYIGlzIGEgZ2VuZXJhbCBkYXRhIHRyYW5zcG9ydCBwcm90b2NvbCwgZWFzaWx5IA0KICAgIGV4 dGVuc2libGUgdG8gc3VpdCB0aGUgbmVlZHMgb2YgZGlmZmVyZW50IGFwcGxpY2F0aW9ucy4gVGhp cyANCiAgICBkb2N1bWVudCBkZXNjcmliZXMgaG93IHR5cGljYWwgYXBwbGljYXRpb25zIHRoYXQg Y2FuIHVzZSB0aGUgDQogICAgSVBGSVggcHJvdG9jb2wuIEl0IHNob3dzIG9wcG9ydHVuaXRpZXMg YW5kIGxpbWl0YXRpb25zIG9mIHRoZSANCiAgICBwcm90b2NvbC4gRnVydGhlcm1vcmUsIHRoZSBy ZWxhdGlvbnNoaXAgb2YgSVBGSVggdG8gb3RoZXIgDQogICAgZnJhbWV3b3JrcyBhbmQgYXJjaGl0 ZWN0dXJlcyBpcyBkZXNjcmliZWQuIA0KICAgICANCiAyLiBBcHBsaWNhdGlvbnMgb2YgSVBGSVgg DQogICAgIA0KICAgIElQRklYIGRhdGEgZW5hYmxlcyBzZXZlcmFsIGNyaXRpY2FsIGFwcGxpY2F0 aW9ucy4gVGhlIElQRklYIA0KICAgIHRhcmdldCBhcHBsaWNhdGlvbnMgYW5kIHRoZSByZXF1aXJl bWVudHMgdGhhdCBvcmlnaW5hdGUgZnJvbSANCiAgICB0aG9zZSBhcHBsaWNhdGlvbnMgYXJlIGRl c2NyaWJlZCBpbiBbUkZDMzkxN10uIFRob3NlIA0KICAgIHJlcXVpcmVtZW50cyB3ZXJlIHVzZWQg YXMgYmFzaXMgZm9yIHRoZSBkZXNpZ24gb2YgdGhlIElQRklYIA0KICAgIHByb3RvY29sLiBUaGlz IHNlY3Rpb24gZGVzY3JpYmVzIGhvdyB0aGVzZSB0YXJnZXQgYXBwbGljYXRpb25zIA0KICAgIGNh biB1c2UgdGhlIElQRklYIHByb3RvY29sLiBDb25zaWRlcmF0aW9ucyBmb3IgdXNpbmcgSVBGSVgg Zm9yIA0KICAgIG90aGVyIGFwcGxpY2F0aW9ucyB0aGFuIGRlc2NyaWJlZCBpbiBbUkZDMzkxN10g Y2FuIGJlIGZvdW5kIGluIA0KICAgIHNlY3Rpb24gNC4xLiANCiAgDQogIDIuMSBBY2NvdW50aW5n IA0KICANCiAgICBVc2FnZSBiYXNlZCBhY2NvdW50aW5nIGlzIG9uZSBvZiB0aGUgbWFqb3IgYXBw bGljYXRpb25zIGZvciANCiAgICB3aGljaCB0aGUgSVBGSVggcHJvdG9jb2wgaGFzIGJlZW4gZGV2 ZWxvcGVkLiBJUEZJWCByZWNvcmRzIA0KICAgIHByb3ZpZGUgZmluZS1ncmFpbmVkIG1lYXN1cmVt ZW50IHJlc3VsdHMgZm9yIGhpZ2hseSBmbGV4aWJsZSBhbmQgDQogICAgZGV0YWlsZWQgcmVzb3Vy Y2UgdXNhZ2UgYWNjb3VudGluZy4gIA0KICAgIEluIG9yZGVyIHRvIHJlYWxpemUgdXNhZ2UtYmFz ZWQgYWNjb3VudGluZyB3aXRoIElQRklYIHRoZSBmbG93IA0KICAgIGRlZmluaXRpb24gaGFzIHRv IGJlIGNob3NlbiBpbiBhY2NvcmRhbmNlIHRvIHRoZSB0YXJpZmYgbW9kZWwuICANCiAgICBGbG93 cyBjYW4gYmUgZGlzdGluZ3Vpc2hlZCBieSB2YXJpb3VzIElFcyAoZS5nLiBwYWNrZXQgaGVhZGVy IA0KICAgIGZpZWxkcykgZnJvbSBbSVBGSVgtSU5GT10uIER1ZSB0byB0aGUgZmxleGlibGUgSVBG SVggZmxvdyANCiAgICBkZWZpbml0aW9uLCBhcmJpdHJhcnkgZmxvdy1iYXNlZCBhY2NvdW50aW5n IG1vZGVscyBjYW4gYmUgDQogICAgcmVhbGl6ZWQgd2l0aG91dCBleHRlbnNpb25zIHRvIHRoZSBJ UEZJWCBwcm90b2NvbC4gDQogICAgIA0KICAgIEEgdGFyaWZmIGNhbiwgZm9yIGluc3RhbmNlLCBi ZSBiYXNlZCBvbiBpbmRpdmlkdWFsIGVuZC10by1lbmQgDQogICAgZmxvd3MsIGluIHdoaWNoIGNh c2UgYWNjb3VudGluZyBjYW4gYmUgcmVhbGl6ZWQgd2l0aCBhIGZsb3cgDQogICAgZGVmaW5pdGlv biBkZXRlcm1pbmVkIGJ5IHRoZSBxdWludHVwbGUgY29uc2lzdGluZyBvZiBzb3VyY2UgDQogICAg YWRkcmVzcyAoc291cmNlSVB2NEFkZHJlc3MpLCBkZXN0aW5hdGlvbiBhZGRyZXNzIA0KICAgIChk ZXN0aW5hdGlvbklQdjRBZGRyZXNzKSwgcHJvdG9jb2wgKHByb3RvY29sSWRlbnRpZmllcikgYW5k IHBvcnQgDQogICAgbnVtYmVycyAoZS5nLiwgdWRwU291cmNlUG9ydCwgdWRwRGVzdGluYXRpb25Q b3J0KS4gQW5vdGhlciANCiAgICBleGFtcGxlIGlzIGEgY2xhc3MtZGVwZW5kZW50IHRhcmlmZiAo ZS5nLiBpbiBhIERpZmZTZXJ2IA0KICAgIG5ldHdvcmspLiBJbiB0aGlzIGNhc2UgZmxvd3MgY291 bGQgYmUgZGlzdGluZ3Vpc2hlZCBqdXN0IGJ5IHRoZSANCiAgICBEaWZmU2VydiBjb2RlcG9pbnQg KERTQ1ApIChpcERpZmZTZXJ2Q29kZVBvaW50KSBhbmQgSVAgYWRkcmVzc2VzIA0KICAgIChzb3Vy Y2VJUHY0QWRkcmVzcywgZGVzdGluYXRpb25JUHY0QWRkcmVzcykuIFRoZSBlc3NlbnRpYWwgDQog ICAgZWxlbWVudHMgbmVlZGVkIGZvciBhY2NvdW50aW5nIGFyZSB0aGUgbnVtYmVyIG9mIHRyYW5z ZmVycmVkIA0KDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAg ICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQ RklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICBwYWNr ZXRzIGFuZCBieXRlcyBwZXIgZmxvdywgd2hpY2ggY2FuIGJlIHJlcHJlc2VudGVkIGJ5IHRoZSBw ZXItDQogICAgZmxvdyBjb3VudGVyIElFcyAoZS5nLiwgcGFja2V0VG90YWxDb3VudCwgb2N0ZXRU b3RhbENvdW50KS4gDQogIA0KICAgIEZvciBhY2NvdW50aW5nIHB1cnBvc2VzLCBpdCB3b3VsZCBi ZSBhZHZhbnRhZ2VvdXMgdG8gaGF2ZSB0aGUgDQogICAgYWJpbGl0eSB0byB1c2UgSVBGSVggZmxv dyByZWNvcmRzIGFzIGFjY291bnRpbmcgaW5wdXQgaW4gYW4gQUFBIA0KICAgIGluZnJhc3RydWN0 dXJlLiBBQUEgc2VydmVycyB0aGVuIGNvdWxkIHByb3ZpZGUgdGhlIG1hcHBpbmcgDQogICAgYmV0 d2VlbiB1c2VyIGFuZCBmbG93IGluZm9ybWF0aW9uLiANCiAgICAgDQogICAgTm90ZSB0aGF0IHRo ZSByZWxpYWJpbGl0eSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZDMzkxN10gYXJlIA0KICAg IG5vdCBzdWZmaWNpZW50IHRvIGd1YXJhbnRlZSB0aGUgbGV2ZWwgb2YgcmVsaWFiaWxpdHkgdGhh dCBpcyANCiAgICBuZWVkZWQgZm9yIG1hbnkgdXNhZ2UtYmFzZWQgYWNjb3VudGluZyBzeXN0ZW1z LiBQYXJ0aWN1bGFyIA0KICAgIHJlbGlhYmlsaXR5IHJlcXVpcmVtZW50cyBmb3IgYWNjb3VudGlu ZyBzeXN0ZW1zIGFyZSBkaXNjdXNzZWQgaW4gDQogICAgW1JGQzI5NzVdLiAgDQogIA0KIDIuMS4x IEV4YW1wbGUgDQogIA0KICAgIFBsZWFzZSBub3RlOiBbUkZDMzMzMF0gZGVtYW5kcyB0aGUgdXNl IG9mIHRoZSBhZGRyZXNzIGJsb2NrIA0KICAgIDE5Mi4wLjIuMC8yNCBmb3IgZXhhbXBsZSBhZGRy ZXNzZXMuIEluIHRoZSBleGFtcGxlIGJlbG93IHdlIHVzZSANCiAgICB0d28gZXhhbXBsZSBuZXR3 b3Jrcy4gSW4gb3JkZXIgdG8gYmUgY29uZm9ybWFudCB0byBbUkZDMzMzMF0gd2UgDQogICAgZGl2 aWRlIHRoZSBnaXZlbiBhZGRyZXNzIGJsb2NrIGludG8gdHdvIG5ldHdvcmtzIGJ5IHN1Ym5ldHRp bmcgDQogICAgd2l0aCBhIDI1IGJpdCBuZXRtYXNrICgxOTIuMC4yLjAvMjUpIGFzIGZvbGxvd3M6 IA0KICAgICANCiAgICBOZXR3b3JrIEE6IDE5Mi4wLjIuMCAuLi4gMTkyLjAuMi4xMjcgDQogICAg TmV0d29yayBCOiAxOTIuMC4yLjEyOCAuLi4gMTkyLjAuMi4yNTUgDQogIA0KICAgIExldCdzIHN1 cHBvc2Ugc29tZW9uZSBoYXMgYSBTZXJ2aWNlIExldmVsIEFncmVlbWVudCAoU0xBKSBpbiBhIA0K ICAgIERpZmZTZXJ2IG5ldHdvcmsgcmVxdWlyaW5nIGFjY291bnRpbmcgYmFzZWQgb24gdHJhZmZp YyB2b2x1bWUuIA0KICAgIEZsb3dzIGFyZSBkaXN0aW5ndWlzaGVkIGJ5IHNvdXJjZSBhbmQgZGVz dGluYXRpb24gYWRkcmVzcy4gVGhlIA0KICAgIGluZm9ybWF0aW9uIHRvIGV4cG9ydCBpbiB0aGlz IGNhc2UgaXM6IA0KICAgICAgICAtIElQdjQgc291cmNlIElQIGFkZHJlc3M6IHNvdXJjZUlQdjRB ZGRyZXNzIGluIFtJUEZJWC1JTkZPXSwgDQogICAgICAgICB3aXRoIGEgbGVuZ3RoIG9mIDQgb2N0 ZXRzIA0KICAgICAgICAtIElQdjQgZGVzdGluYXRpb24gSVAgYWRkcmVzczogZGVzdGluYXRpb25J UHY0QWRkcmVzcyBpbiANCiAgICAgICAgIFtJUEZJWC1JTkZPXSwgd2l0aCBhIGxlbmd0aCBvZiA0 IG9jdGV0cyANCiAgICAgICAgLSBEU0NQOiBpcERpZmZTZXJ2Q29kZVBvaW50IGluIFtJUEZJWC1J TkZPXSwgd2l0aCBhIGxlbmd0aCBvZiANCiAgICAgICAgIDEgb2N0ZXQgDQogICAgICAgIC0gTnVt YmVyIG9mIG9jdGV0cyBvZiB0aGUgRmxvdzogb2N0ZXREZWx0YUNvdW50IGluIFtJUEZJWC0NCiAg ICAgICAgIElORk9dLCB3aXRoIGEgbGVuZ3RoIG9mIDQgb2N0ZXRzICANCiAgICAgICAgIA0KICAg IFRoZSB0ZW1wbGF0ZSBzZXQgd2lsbCBsb29rIGFzIGZvbGxvd3M6ICANCiAgDQogICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rICAgDQogICAgIHwgICAgICAgICBTZXQgSUQgPSAyICAgICAgICAgICAgfCAgICAgIExlbmd0 aCA9IDI0IG9jdGV0cyAgICAgICB8ICAgDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgDQogICAgIHwgICAgICAg VGVtcGxhdGUgSUQgMjU2ICAgICAgICAgfCAgICAgICBGaWVsZCBDb3VudCA9IDQgICAgICAgICB8 ICAgDQogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rICAgDQogICAgIHwwfCAgICBzb3VyY2VJUHY0QWRkcmVzcyA9IDgg ICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSA0ICAgICAgICB8ICAgDQogICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAg DQogICAgIHwwfCBkZXN0aW5hdGlvbklQdjRBZGRyZXNzID0gMTIgfCAgICAgICBGaWVsZCBMZW5n dGggPSA0ICAgICAgICB8ICAgDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xh aXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0gDQoMICAgICAgICAgICAgICAg ICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoN CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgICANCiAgICAgfDB8ICBpcERpZmZTZXJ2Q29kZVBvaW50ID0gMTk1ICB8 ICAgICAgIEZpZWxkIExlbmd0aCA9IDEgICAgICAgIHwgICANCiAgICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICANCiAg ICAgfDB8ICAgICBvY3RldERlbHRhQ291bnQgPSAxICAgICB8ICAgICAgIEZpZWxkIExlbmd0aCA9 IDQgICAgICAgIHwgIA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgIA0KICAgICANCiAgICBUaGUgaW5mb3JtYXRp b24gdG8gYmUgZXhwb3J0ZWQgbWlnaHQgYmUgYXMgbGlzdGVkIGluIHRoZSANCiAgICBmb2xsb3dp bmcgZXhhbXBsZSB0YWJsZTogDQogICAgIA0KICAgIFNyYy4gSVAgYWRkci4gfCBEc3QuIElQIGFk ZHIuIHwgIERTQ1AgIHwgT2N0ZXRzIE51bWJlciAgIA0KICAgIC0tLS0tLS0tLS0tLS0tKy0tLS0t LS0tLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLS0tLS0tLSANCiAgICAxOTIuMC4yLjEyICAgIHwg IDE5Mi4wLjIuMTQ0ICB8ICAgNDYgICB8ICAgMTIwODY4ICAgICAgICANCiAgICAxOTIuMC4yLjI0 ICAgIHwgIDE5Mi4wLjIuMTU2ICB8ICAgNDYgICB8ICAgMzEwMzY0IA0KICAgIDE5Mi4wLjIuMzYg ICAgfCAgMTkyLjAuMi4xNjggIHwgICA0NiAgIHwgICAyNDEyMzkgDQogICAgICAgICAgICANCiAg ICBJbiB0aGUgZXhhbXBsZSB3ZSB1c2UgRGlmZnNlcnYgQ29kZVBvaW50IDQ2LCByZWNvbW1lbmRl ZCBmb3IgdGhlIA0KICAgIEV4cGVkaXRlZCBGb3J3YXJkaW5nIFBlciBIb3AgQmVoYXZpb3IgKEVG IFBIQikgaW4gW1JGQzI1OThdLiANCiAgICAgDQogICAgVGhlIEZsb3cgUmVjb3JkcyB3aWxsIHRo ZW4gbG9vayBhcyBmb2xsb3dzOiANCiAgICAgDQogICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMyAgDQogICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxICANCiAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKyAgDQogICAgfCAgICAgICAgICBTZXQgSUQgPSAyNTYgICAgICAgICB8ICAgICAg ICAgIExlbmd0aCA9IDQzICAgICAgICAgIHwgIA0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAxOTIuMC4yLjEyICAgICAgICAgICAgICAgICAgICAgICAgICAg fCANCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyAgDQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgMTkyLjAu Mi4xNDQgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIA0KICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgICB8 ICAgICAgNDYgICAgICAgfCAgICAgICAgICAgICAgIDEyMDg2OCAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgDQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0KICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgMTkyLjAuMi4yNCAgICAgICAgICAgICAgICAgICAgICB8ICANCiAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAN CiAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIDE5Mi4wLjIuMTU2ICAgICAgICAg ICAgICAgICAgICAgfCAgDQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICANCiAgICB8ICAgICAgICAgICAgICAgfCAg ICAgICA0NiAgICAgIHwgICAgICAgICAgICAgICAgIDMxMDM2NCAgICAgICAgfCAgDQogICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsgIA0KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIDE5 Mi4wLjIuMzYgICAgICAgICAgICB8ICAgDQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0KICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgIDE5Mi4wLjIuMTY4ICAgICAgICAgICB8ICAg DQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsgDQogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgIDQ2ICAgICAgfCAgICAgICAgICAgICAgIHwgIA0KICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgICB8ICAg ICAgICAgICAgICAgICAgIDI0MTIzOSAgICAgICAgICAgICAgICAgICAgICB8ICAgICANCiAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgICAg DQogIA0KDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklY IEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgMi4yIFRyYWZm aWMgUHJvZmlsaW5nICANCiAgICAgDQogICAgTWVhc3VyZW1lbnQgcmVzdWx0cyByZXBvcnRlZCBp biBJUEZJWCByZWNvcmRzIGNhbiBiZSB1c2VkIGZvciANCiAgICB0cmFmZmljIHByb2ZpbGluZy4g SVBGSVggcmVjb3JkcyBjYXB0dXJlZCBvdmVyIGEgbG9uZyBwZXJpb2Qgb2YgDQogICAgdGltZSBj YW4gYmUgdXNlZCB0byB0cmFjayBhbmQgYW50aWNpcGF0ZSBuZXR3b3JrIGdyb3d0aCBhbmQgDQog ICAgdXNhZ2UuIFN1Y2ggSW5mb3JtYXRpb24gaXMgdmFsdWFibGUgZm9yIHRyZW5kIGFuYWx5c2lz IGFuZCANCiAgICBuZXR3b3JrIHBsYW5uaW5nLiANCiAgICAgDQogICAgVGhlIHBhcmFtZXRlcnMg b2YgaW50ZXJlc3QgYXJlIGRldGVybWluZWQgYnkgdGhlIHByb2ZpbGluZyANCiAgICBvYmplY3Rp dmVzLiBFeGFtcGxlIHBhcmFtZXRlcnMgZm9yIHRyYWZmaWMgcHJvZmlsaW5nIGFyZSBmbG93IA0K ICAgIGR1cmF0aW9uLCBmbG93IHZvbHVtZSwgYnVyc3RpbmVzcywgdGhlIGRpc3RyaWJ1dGlvbiBv ZiB1c2VkIA0KICAgIHNlcnZpY2VzIGFuZCBwcm90b2NvbHMsIHRoZSBhbW91bnQgb2YgcGFja2V0 cyBvZiBhIHNwZWNpZmljIA0KICAgIHR5cGUsIGV0Yy4gW1JGQzM5MTddLiAgDQogICAgIA0KICAg IFRoZSBkaXN0cmlidXRpb24gb2Ygc2VydmljZXMgYW5kIHByb3RvY29scyBpbiB1c2UgY2FuIGJl IA0KICAgIGFuYWx5emVkIGJ5IGNvbmZpZ3VyaW5nIGFwcHJvcHJpYXRlIGZsb3dzIGtleXMgZm9y IGZsb3cgDQogICAgZGlzY3JpbWluYXRpb24uIFByb3RvY29scyBjYW4gYmUgZGlzdGluZ3Vpc2hl ZCBieSB0aGUgDQogICAgcHJvdG9jb2xJZGVudGlmaWVyIElFLiBQb3J0bnVtYmVycyAoZS5nLiwg dWRwRGVzdGluYXRpb25Qb3J0KSANCiAgICBvZnRlbiBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0 IHNlcnZpY2VzIGluIHVzZS4gVGhvc2UgZmxvdyBrZXlzIA0KICAgIGFyZSBkZWZpbmVkIGluIFtJ UEZJWC1JTkZPXS4gSWYgcG9ydG51bWJlcnMgYXJlIG5vdCBzdWZmaWNpZW50IA0KICAgIGZvciBz ZXJ2aWNlIGRpc2NyaW1pbmF0aW9uLCBmdXJ0aGVyIHBhcnRzIG9mIHRoZSBwYWNrZXQgbWF5IGJl IA0KICAgIG5lZWRlZC4gSGVhZGVyIGZpZWxkcyBjYW4gYmUgZXhwcmVzc2VkIGJ5IElFcyBmcm9t IFtJUEZJWC1JTkZPXSANCiAgICBQYWNrZXQgcGF5bG9hZCBjYW4gYmUgcmVwb3J0ZWQgYnkgdXNp bmcgdGhlIElFIA0KICAgIGlwUGF5bG9hZFBhY2tldFNlY3Rpb24gaW4gW1BTQU1QLUlORk9dLiAN CiAgDQogICAgVGhlIGZsb3cgZHVyYXRpb24gY2FuIGJlIGNhbGN1bGF0ZWQgZnJvbSB0aGUgZmxv dyB0aW1lIHN0YW1wIElFcyANCiAgICBkZWZpbmVkIGluIFtJUEZJWC1JTkZPXSAoZS5nLiwgZmxv d0VuZE1pY3Jvc2Vjb25kcyAtIA0KICAgIGZsb3dTdGFydE1pY3Jvc2Vjb25kcykuIFRoZSBudW1i ZXIgb2YgcGFja2V0cyBhbmQgbnVtYmVyIG9mIA0KICAgIGJ5dGVzIG9mIGEgZmxvdyBhcmUgcmVw cmVzZW50ZWQgaW4gdGhlIHBlci1mbG93IGNvdW50ZXIgSUVzIA0KICAgIChlLmcuLCBwYWNrZXRU b3RhbENvdW50LCBvY3RldFRvdGFsQ291bnQpLiBUaGUgYnVyc3RpbmVzcyBvZiBhIA0KICAgIGZs b3cgY2FuIGJlIGNhbGN1bGF0ZWQgZnJvbSB0aGUgZmxvdyB2b2x1bWUgbWVhc3VyZWQgYXQgDQog ICAgZGlmZmVyZW50IHRpbWUgaW50ZXJ2YWxzLiAgDQogIA0KICAyLjMgVHJhZmZpYyBFbmdpbmVl cmluZyANCiAgICAgDQogICAgVHJhZmZpYyBlbmdpbmVlcmluZyBhaW1zIGF0IHRoZSBvcHRpbWl6 YXRpb24gb2YgbmV0d29yayByZXNvdXJjZSANCiAgICB1dGlsaXphdGlvbiBhbmQgdHJhZmZpYyBw ZXJmb3JtYW5jZSBbUkZDMjcwMl0uIFR5cGljYWwgDQogICAgcGFyYW1ldGVycyBhcmUgbGluayB1 dGlsaXphdGlvbiwgbG9hZCBiZXR3ZWVuIHNwZWNpZmljIG5ldHdvcmssIA0KICAgIG5vZGVzLCBu dW1iZXIsIHNpemUgYW5kIGVudHJ5L2V4aXQgcG9pbnRzIG9mIGFjdGl2ZSBmbG93cyBhbmQgDQog ICAgcm91dGluZyBpbmZvcm1hdGlvbiBbUkZDMzkxN10uIA0KICAgIFNpemUgb2YgZmxvd3MgaW4g cGFja2V0cyBhbmQgYnl0ZXMgY2FuIGJlIHJlcG9ydGVkIGJ5IElFcyANCiAgICBwYWNrZXRUb3Rh bENvdW50LCBvY3RldFRvdGFsQ291bnQuIExpbmsgdXRpbGl6YXRpb24gY2FuIGJlIA0KICAgIHJl cG9ydGVkIGJ5IHVzaW5nIGEgY29hcnNlIGdyYWluZWQgZmxvdyBkZWZpbml0aW9uIChlLmcuIGJh c2VkIA0KICAgIG9uIGlkZW50aWZpZXIgSUVzIHN1Y2ggYXMgZWdyZXNzSW50ZXJmYWNlIG9yIGlu Z3Jlc3NJbnRlcmZhY2UpIA0KICAgIGFuZCBwZXItZmxvdyBjb3VudGVyIElFcyAoZS5nLiBwYWNr ZXRUb3RhbENvdW50LCANCiAgICBvY3RldFRvdGFsQ291bnQpIGRlZmluZWQgaW4gW0lQRklYLUlO Rk9dLiAgDQogICAgIA0KDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNl ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDQoMICAgICAgICAgICAgICAgICAg ICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAg ICBUaGUgbG9hZCBiZXR3ZWVuIHNwZWNpZmljIG5ldHdvcmsgbm9kZXMgY2FuIGJlIHJlcG9ydGVk IGluIHRoZSANCiAgICBzYW1lIHdheSBpZiBvbmUgaW50ZXJmYWNlIG9mIGEgbmV0d29yayBub2Rl IHJlY2VpdmVzIG9ubHkgDQogICAgdHJhZmZpYyBmcm9tIGV4YWN0bHkgb25lIG5laWdoYm9yIG5v ZGUgKGFzIHVzdWFsbHkgdGhlIGNhc2UpLiBJZiANCiAgICB0aGUgaW5ncmVzcyBpbnRlcmZhY2Ug aXMgbm90IHN1ZmZpY2llbnQgZm9yIGFuIHVuYW1iaWd1b3VzICANCiAgICBpZGVudGlmaWNhdGlv biBvZiB0aGUgbmVpZ2hib3Igbm9kZSwgc3ViLUlQIGhlYWRlciBmaWVsZHMgSUVzIA0KICAgIChs aWtlIHNvdXJjZU1hY0FkZHJlc3MpIGNhbiBiZSBhZGRlZCBhcyBmbG93IGtleXMuIA0KICANCiAg ICBUaGUgSUUgb2JzZXJ2ZWRGbG93VG90YWxDb3VudCBwcm92aWRlcyB0aGUgbnVtYmVyIG9mIGFs bCBmbG93cyANCiAgICBleHBvcnRlZCBmb3IgdGhlIG9ic2VydmF0aW9uIGRvbWFpbiBzaW5jZSB0 aGUgbGFzdCANCiAgICBpbml0aWFsaXphdGlvbiBvZiB0aGUgbWV0ZXJpbmcgcHJvY2VzcyBbSVBG SVgtSU5GT10uIElmIHRoaXMgSUUgDQogICAgaXMgZXhwb3J0ZWQgYXQgc3Vic2VxdWVudCBwb2lu dHMgaW4gdGltZSwgb25lIGNhbiBkZXJpdmUgdGhlIA0KICAgIG51bWJlciBvZiBhY3RpdmUgZmxv d3MgaW4gYSBzcGVjaWZpYyB0aW1lIGludGVydmFsIGZyb20gdGhlIA0KICAgIGRpZmZlcmVuY2Ug b2YgdGhlIHJlcG9ydGVkIGNvdW50ZXJzLiBUaGUgY29uZmlndXJlZCBmbG93IA0KICAgIHRlcm1p bmF0aW9uIGNyaXRlcmlhIGhhdmUgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50IHRvIGludGVycHJl dCANCiAgICB0aGF0IG51bWJlcnMgY29ycmVjdGx5LiANCiAgDQogICAgRW50cnkgYW5kIGV4aXQg cG9pbnRzIGNhbiBiZSBkZXJpdmVkIGZyb20gZmxvdyByZWNvcmRzIGlmIA0KICAgIG1ldGVyaW5n IHByb2Nlc3NlcyBhcmUgaW5zdGFsbGVkIGF0IGFsbCBlZGdlcyBvZiB0aGUgbmV0d29yayBhbmQg DQogICAgcmVzdWx0cyBhcmUgbWFwcGVkIGluIGFjY29yZGFuY2UgdG8gZmxvdyBrZXlzLiBGb3Ig dGhpcyBhbmQgDQogICAgb3RoZXIgYW5hbHlzaXMgbWV0aG9kcyB0aGF0IHJlcXVpcmUgdGhlIG1h cHBpbmcgb2YgcmVjb3JkcyBmcm9tIA0KICAgIGRpZmZlcmVudCBvYnNlcnZhdGlvbiBwb2ludHMs IHRoZSBzYW1lIGZsb3cga2V5cyBzaG91bGQgYmUgdXNlZCANCiAgICBhdCBhbGwgb2JzZXJ2YXRp b24gcG9pbnRzLiBUaGUgcGF0aCB0aGF0IHBhY2tldHMgdGFrZSB0aHJvdWdoIGEgDQogICAgbmV0 d29yayBjYW4gYmUgaW52ZXN0aWdhdGVkIGJ5IHVzaW5nIGhhc2gtYmFzZWQgc2FtcGxpbmcgDQog ICAgdGVjaG5pcXVlcyBhcyBkZXNjcmliZWQgaW4gW0R1R3IwMF0gYW5kIFtQU0FNUC1URUNIXS4g Rm9yIHRoaXMgDQogICAgSUVzIGZyb20gW1BTQU1QLUlORk9dIGFyZSBuZWVkZWQuIA0KICANCiAg ICBOZWl0aGVyIFtJUEZJWC1JTkZPXSBub3IgW1BTQU1QLUlORk9dIGRlZmluZXMgSUVzIHN1aXRh YmxlIGZvciANCiAgICBleHBvcnRpbmcgcm91dGluZyBpbmZvcm1hdGlvbi4gDQogICAgIA0KICAy LjQgTmV0d29yayBTZWN1cml0eSANCiAgICAgDQogICAgQXR0YWNrIGFuZCBpbnRydXNpb24gZGV0 ZWN0aW9uIGFyZSBhbW9uZyB0aGUgSVBGSVggdGFyZ2V0IA0KICAgIGFwcGxpY2F0aW9ucyBkZXNj cmliZWQgaW4gW1JGQzM5MTddLiBEdWUgdG8gdGhlIGVub3Jtb3VzIGFtb3VudCANCiAgICBvZiBk aWZmZXJlbnQgbmV0d29yayBhdHRhY2sgdHlwZXMsIG9ubHkgZ2VuZXJhbCByZXF1aXJlbWVudHMg DQogICAgY291bGQgYmUgYWRkcmVzc2VkIGluIFtSRkMzOTE3XS4gDQogIA0KICAgIElQRklYIGNh biBleHBvcnQgZmxvdyBpbmZvcm1hdGlvbiBmb3IgYXJiaXRyYXJ5IGZsb3cgZGVmaW5pdGlvbnMg DQogICAgYXMgZGVmaW5lZCBpbiBbSVBGSVgtUFJPVE9dLiBQYWNrZXQgaW5mb3JtYXRpb24gY2Fu IGJlIGV4cG9ydGVkIA0KICAgIHdpdGggSVBGSVggYnkgdXNpbmcgdGhlIGFkZGl0aW9uYWwgaW5m b3JtYXRpb24gZWxlbWVudHMgDQogICAgZGVzY3JpYmVkIGluIFtQU0FNUC1JTkZPXS4gV2l0aCB0 aGlzIHRoZW9yZXRpY2FsbHkgYWxsIA0KICAgIGluZm9ybWF0aW9uIGFib3V0IHRyYWZmaWMgaW4g dGhlIG5ldHdvcmsgYXQgSVAgbGF5ZXIgYW5kIGFib3ZlIA0KICAgIGlzIGFjY2Vzc2libGUuIFRo aXMgZGF0YSBjYW4gYmUgdXNlZCBlaXRoZXIgZGlyZWN0bHkgdG8gZGV0ZWN0IA0KICAgIGFub21h bGllcyBvciBjYW4gcHJvdmlkZSB0aGUgYmFzaXMgZm9yIGZ1cnRoZXIgcG9zdCBwcm9jZXNzaW5n IA0KICAgIHRvIGdlbmVyYXRlIG1vcmUgY29tcGxleCBhdHRhY2sgZGV0ZWN0aW9uIG1ldHJpY3Mu ICANCiAgICAgDQogICAgRGVwZW5kaW5nIG9uIHRoZSBhdHRhY2sgdHlwZSBkaWZmZXJlbnQgbWV0 cmljcyBhcmUgdXNlZnVsLiBBIA0KICAgIHN1ZGRlbiBpbmNyZWFzZSBvZiB0cmFmZmljIGxvYWQg Y2FuIGJlIGEgaGludCB0aGF0IGFuIGF0dGFjayBoYXMgDQogICAgYmVlbiBsYXVuY2hlZC4gVGhl IG92ZXJhbGwgdHJhZmZpYyBhdCBhbiBvYnNlcnZhdGlvbiBwb2ludCBjYW4gDQoNCg0KDQoNCiBa c2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgOF0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAg ICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICBiZSBtb25pdG9yZWQgdXNpbmcgcGVyLWZs b3cgY291bnRlciBJRXMgbGlrZSBwYWNrZXRUb3RhbENvdW50LCANCiAgICBvY3RldFRvdGFsQ291 bnQgYXMgZGVzY3JpYmVkIGluIDIuMy4gVGhlIG51bWJlciBvZiBhY3RpdmUgZmxvd3MgDQogICAg Y2FuIGJlIG1vbml0b3JlZCBieSByZWd1bGFyIHJlcG9ydGluZyBvZiB0aGUgDQogICAgb2JzZXJ2 ZWRGbG93VG90YWxDb3VudC4gDQogICAgIA0KICAgIEEgc3VkZGVuIGluY3JlYXNlIG9mIGZsb3dz IGZyb20gZGlmZmVyZW50IHNvdXJjZXMgdG8gb25lIA0KICAgIGRlc3RpbmF0aW9uIG1heSBiZSBj YXVzZWQgYnkgYW4gYXR0YWNrIG9uIGEgc3BlY2lmaWMgaG9zdCBvciANCiAgICBuZXR3b3JrIG5v ZGUgdXNpbmcgc3Bvb2ZlZCBhZGRyZXNzZXMuIE1hbnkgZmxvd3MgdG8gdGhlIHNhbWUgDQogICAg bWFjaGluZSBidXQgb24gZGlmZmVyZW50IHBvcnRzIG9yIG1hbnkgZmxvd3MgdG8gdGhlIHNhbWUg cG9ydCANCiAgICBhbmQgZGlmZmVyZW50IG1hY2hpbmVzIG1heSBiZSBhbiBpbmRpY2F0b3IgZm9y IHZlcnRpY2FsIG9yIA0KICAgIGhvcml6b250YWwgcG9ydCBzY2FubmluZyBhY3Rpdml0aWVzLiBB biB1bnVzdWFsIHJhdGlvIG9mIFRDUC1TWU4gDQogICAgdG8gVENQLUZJTiBwYWNrZXRzIGNhbiBy ZWZlciB0byBTWU4tZmxvb2RpbmcuIFdvcm1zIG1heSBsZWF2ZSANCiAgICBzaWduYXR1cmVzIGlu IHRyYWZmaWMgcGF0dGVybnMuICANCiAgICAgDQogICAgVGhlIGFtb3VudCBvZiBtZXRyaWNzIHVz ZWZ1bCBmb3IgYXR0YWNrIGRldGVjdGlvbiBpcyBhcyBkaXZlcnNlIA0KICAgIGFzIGF0dGFjayBw YXR0ZXJucyB0aGVtc2VsdmVzLiBBdHRhY2tlcnMgYWRhcHQgcmFwaWRseSB0byANCiAgICBjaXJj dW12ZW50IGRldGVjdGlvbiBtZXRob2RzIGFuZCB0cnkgdG8gaGlkZSBhdHRhY2sgcGF0dGVybnMg DQogICAgdXNpbmcgc2xvdyBvciBzdGVhbHRoIGF0dGFja3MuIEZ1cnRoZXJtb3JlLCB1bnVzdWFs IHRyYWZmaWMgDQogICAgcGF0dGVybnMgYXJlIG5vdCBhbHdheXMgY2F1c2VkIGJ5IG1hbGljaW91 cyBhY3Rpdml0aWVzLiBBIHN1ZGRlbiANCiAgICB0cmFmZmljIGluY3JlYXNlIG1heSBiZSBjYXVz ZWQgYnkgbGVnaXRpbWF0ZSB1c2VycyB3aG8gc2VlayANCiAgICBhY2Nlc3MgdG8gYSByZWNlbnRs eSBwdWJsaXNoZWQgY29udGVudC4gU3RyYW5nZSB0cmFmZmljIHBhdHRlcm5zIA0KICAgIG1heSBh bHNvIGJlIGNhdXNlZCBieSBtaXMtY29uZmlndXJhdGlvbi4gIA0KICAgICANCiAgICBUaGUgZGlm ZmljdWx0IHRhc2sgaXMgdGhlIHNlcGFyYXRpb24gb2YgZ29vZCBmcm9tIGJhZCBwYWNrZXRzIHRv IA0KICAgIHByZXBhcmUgYW5kIGxhdW5jaCBjb3VudGVyYWN0aW9uLiBUaGlzIG1heSByZXF1aXJl IGEgZGVlcGVyIGxvb2sgDQogICAgaW50byBwYWNrZXQgY29udGVudCBieSB1c2luZyBmdXJ0aGVy IGhlYWRlciBmaWVsZCBJRXMgZnJvbSANCiAgICBbSVBGSVgtSU5GT10gYW5kL29yIHBhY2tldCBw YXlsb2FkIGZyb20gSUUgDQogICAgaXBQYXlsb2FkUGFja2V0U2VjdGlvbiBpbiBbUFNBTVAtSU5G T10uIE11bHRpLXN0ZXAgYW5hbHlzaXMgDQogICAgdGVjaG5pcXVlcyBtYXkgYmUgdXNlZnVsLCBl LmcuLCB0byBsYXVuY2ggYW4gaW4tZGVwdGggYW5hbHlzaXMgDQogICAgKGUuZy4gYmFzZWQgb24g cGFja2V0IGluZm9ybWF0aW9uKSBpbiBjYXNlIHRoZSBmbG93IGluZm9ybWF0aW9uIA0KICAgIHNo b3dzIHN1c3BpY2lvdXMgcGF0dGVybnMuIEluIG9yZGVyIHRvIHN1cGVydmlzZSB0cmFmZmljIHRv IGEgDQogICAgc3BlY2lmaWMgaG9zdCBvciBuZXR3b3JrIG5vZGUgb25lIGhhcyB0byBhcHBseSBm aWx0ZXJpbmcgbWV0aG9kcyANCiAgICBhcyB0aG9zZSBkZXNjcmliZWQgaW4gW1BTQU1QLVRFQ0hd LiANCiAgDQogICAgTWFwcGluZyB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgYSBjb21tdW5pY2F0aW9u IGlzIG9mdGVuIHVzZWZ1bCANCiAgICBmb3IgY2hlY2tpbmcgY29ycmVjdCBwcm90b2NvbCBiZWhh dmlvciAoc2VlIHNlY3Rpb24gNC41KS4gQSANCiAgICBjb3JyZWxhdGlvbiBvZiBJUEZJWCBkYXRh IGZyb20gbXVsdGlwbGUgb2JzZXJ2YXRpb24gcG9pbnRzIChzZWUgDQogICAgc2VjdGlvbiAyLjUu MSkgYWxsb3dzIGFzc2Vzc2luZyB0aGUgcHJvcGFnYXRpb24gb2YgYW4gYXR0YWNrIGFuZCANCiAg ICBjYW4gaGVscCB0byBsb2NhdGUgaXRzIHNvdXJjZS4gIA0KICAgICANCiAgICBUaGUgaW50ZWdy YXRpb24gb2YgcHJldmlvdXMgbWVhc3VyZW1lbnQgcmVzdWx0cyBoZWxwcyB0byByZXZpZXcgDQog ICAgdHJhZmZpYyBjaGFuZ2VzIG92ZXIgdGltZSBmb3IgZGV0ZWN0aW9uIG9mIHRyYWZmaWMgYW5v bWFsaWVzIGFuZCANCiAgICBwcm92aWRlcyB0aGUgYmFzaXMgZm9yIGZvcmVuc2ljIGFuYWx5c2lz LiBBIHN0YW5kYXJkaXplZCBzdG9yYWdlIA0KICAgIGZvcm1hdCBmb3IgSVBJRlggZGF0YSB3b3Vs ZCBzdXBwb3J0IHRoZSBvZmZsaW5lIGFuYWx5c2lzIG9mIGRhdGEgDQogICAgZnJvbSBkaWZmZXJl bnQgb3BlcmF0b3JzLiANCiAgICAgDQogICAgTmV2ZXJ0aGVsZXNzLCBjYXB0dXJpbmcgZnVsbCBw YWNrZXQgdHJhY2VzIGF0IGFsbCBvYnNlcnZhdGlvbiANCiAgICBwb2ludHMgaW4gdGhlIG5ldHdv cmsgaXMgbm90IHZpYWJsZSBkdWUgdG8gcmVzb3VyY2UgbGltaXRhdGlvbnMgDQoNCg0KDQoNCiBa c2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgOV0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAg ICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICBhbmQgcHJpdmFjeSBjb25jZXJucy4gVGhl cmVmb3JlIG1ldHJpY3Mgc2hvdWxkIGJlIGNob3NlbiB3aXNlbHkgDQogICAgdG8gYWxsb3cgYSBz b2xpZCBkZXRlY3Rpb24gd2l0aCBtaW5pbWFsIHJlc291cmNlIGNvbnN1bXB0aW9uLiANCiAgICBS ZXNvdXJjZXMgY2FuIGJlIHNhdmVkIGZvciBpbnN0YW5jZSBieSB1c2luZyBjb2Fyc2VyIGdyYWlu ZWQgDQogICAgZmxvdyBkZWZpbml0aW9ucywgcmVwb3J0aW5nIHByZS1wcm9jZXNzZWQgbWV0cmlj cyAoZS5nLiB3aXRoIA0KICAgIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gZWxlbWVudHMpIG9yIGRl cGxveW1lbnQgb2Ygc2FtcGxpbmcgDQogICAgbWV0aG9kcy4gDQogIA0KICAgIERldGVjdGluZyBz ZWN1cml0eSBpbmNpZGVudHMgaW4gcmVhbC10aW1lIG9mdGVuIHJlcXVpcmVzIHRoZSANCiAgICBw cmUtcHJvY2Vzc2luZyBvZiBkYXRhIGFscmVhZHkgYXQgdGhlIG1lYXN1cmVtZW50IGRldmljZS4g DQogICAgSW1tZWRpYXRlIGRhdGEgZXhwb3J0IGluIGNhc2Ugb2YgYSBwb3RlbnRpYWwgaW5jaWRl bnQgaXMgDQogICAgZGVzaXJlZC4gSVBJRlggc3VwcG9ydHMgc3VjaCBzb3VyY2UtdHJpZ2dlcmVk IGV4cG9ydGluZyBvZiANCiAgICBpbmZvcm1hdGlvbiBkdWUgdG8gdGhlIHB1c2ggbW9kZWwgYXBw cm9hY2guIE5ldmVydGhlbGVzcywgDQogICAgZnVydGhlciBleHBvcnRpbmcgY3JpdGVyaWEgaGF2 ZSB0byBiZSBpbXBsZW1lbnRlZCB0byBleHBvcnQgDQogICAgSVBGSVggcmVjb3JkcyB1cG9uIGlu Y2lkZW50IGRldGVjdGlvbiBldmVudHMgYW5kIG5vdCBvbmx5IHVwb24gDQogICAgZmxvdyBlbmQg b3IgZml4ZWQgdGltZSBpbnRlcnZhbHMuIA0KICAgICANCiAgICBTZWN1cml0eSBpbmNpZGVudHMg Y2FuIGJlY29tZSBhIHRocmVhdCB0byBJUEZJWCBwcm9jZXNzZXMgDQogICAgdGhlbXNlbHZlcyAo c2VlIGFsc28gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gW0lQRklYLVBST1RPXSkuIA0KICAg IElmIGFuIGF0dGFjayBnZW5lcmF0ZXMgYSBsYXJnZSBhbW91bnQgb2YgZmxvd3MgKGUuZy4gYnkg c2VuZGluZyANCiAgICBwYWNrZXRzIHdpdGggc3Bvb2ZlZCBhZGRyZXNzZXMgb3Igc2ltdWxhdGlu ZyBmbG93IHRlcm1pbmF0aW9uKSANCiAgICBleHBvcnRpbmcgYW5kIGNvbGxlY3RpbmcgcHJvY2Vz cyBtYXkgZ2V0IG92ZXJsb2FkZWQgYnkgdGhlIA0KICAgIGltbWVuc2UgYW1vdW50IG9mIHJlY29y ZHMgdGhhdCBhcmUgZXhwb3J0ZWQuIEEgZmxleGlibGUgDQogICAgZGVwbG95bWVudCBvZiBwYWNr ZXQgb3IgZmxvdyBzYW1wbGluZyBtZXRob2RzIGNhbiBwcmV2ZW50IHRoZSANCiAgICBleGhhdXN0 aW9uIG9mIHJlc291cmNlcy4gICAgDQogICAgIA0KICAgIEludHJ1c2lvbiBkZXRlY3Rpb24gd291 bGQgcHJvZml0IGZyb20gdGhlIGNvbWJpbmF0aW9uIG9mIElQRklYIA0KICAgIGZ1bmN0aW9ucyB3 aXRoIEFBQSBmdW5jdGlvbnMgKHNlZSBzZWN0aW9uIDMuNCkuIFN1Y2ggYW4gDQogICAgaW50ZXJv cGVyYXRpb24gZW5hYmxlcyBmdXJ0aGVyIG1lYW5zIGZvciBhdHRhY2tlciBkZXRlY3Rpb24sIA0K ICAgIGFkdmFuY2VkIGRlZmVuc2Ugc3RyYXRlZ2llcyBhbmQgc2VjdXJlIGludGVyLWRvbWFpbiBj b29wZXJhdGlvbi4gDQogIA0KICAyLjUgUW9TIE1vbml0b3JpbmcgDQogICAgIA0KICAgIFFvUyBt b25pdG9yaW5nIGlzIG9uZSB0YXJnZXQgYXBwbGljYXRpb24gb2YgdGhlIElQRklYIHByb3RvY29s IA0KICAgIFtSRkMzOTE3XS4gUW9TIG1vbml0b3JpbmcgaXMgdGhlIHBhc3NpdmUgb2JzZXJ2YXRp b24gb2YgdGhlIA0KICAgIHRyYW5zbWlzc2lvbiBxdWFsaXR5IGZvciBzaW5nbGUgZmxvd3Mgb3Ig dHJhZmZpYyBhZ2dyZWdhdGVzIGluIA0KICAgIHRoZSBuZXR3b3JrLiBPbmUgZXhhbXBsZSBvZiBp dHMgdXNlIGlzIHRoZSB2YWxpZGF0aW9uIG9mIFFvUyANCiAgICBndWFyYW50ZWVzIGluIHNlcnZp Y2UgbGV2ZWwgYWdyZWVtZW50cyAoU0xBcykuIFR5cGljYWwgUW9TIA0KICAgIHBhcmFtZXRlcnMg YXJlIGxvc3MgW1JGQzI2ODBdLCBvbmUtd2F5IFtSRkMyNjc5XSBhbmQgcm91bmQtdHJpcCANCiAg ICBkZWxheSBbUkZDMjY4MV0gYW5kIGRlbGF5IHZhcmlhdGlvbiBbUkZDMzM5M10uIFRoZSBjYWxj dWxhdGlvbiANCiAgICBvZiB0aG9zZSBRb1MgbWV0cmljcyByZXF1aXJlcyBwZXItcGFja2V0IHBy b2Nlc3NpbmcuIFJlcG9ydGluZyANCiAgICBwYWNrZXQgaW5mb3JtYXRpb24gd2l0aCBJUEZJWCBp cyBwb3NzaWJsZSBieSBzaW1wbHkgY29uc2lkZXJpbmcgDQogICAgYSBzaW5nbGUgcGFja2V0IGFz IGZsb3cuIFtJUEZJWC1QUk9UT10gYWxzbyBhbGxvd3MgdGhlIHJlcG9ydGluZyANCiAgICBvZiBt dWx0aXBsZSBpZGVudGljYWwgaW5mb3JtYXRpb24gZWxlbWVudHMgaW4gb25lIGZsb3cgcmVjb3Jk LiANCiAgICBVc2luZyB0aGlzIGZlYXR1cmUgZm9yIHJlcG9ydGluZyBpbmZvcm1hdGlvbiBhYm91 dCBtdWx0aXBsZSANCiAgICBwYWNrZXRzIGluIG9uZSByZWNvcmQgd291bGQgcmVxdWlyZSBhZGRp dGlvbmFsIGFncmVlbWVudCBvbiANCiAgICBzZW1hbnRpY3MgcmVnYXJkaW5nIHRoZSBvcmRlciBv ZiBpbmZvcm1hdGlvbiBlbGVtZW50cyAoZS5nLiANCiAgICB3aGljaCB0aW1lc3RhbXAgYmVsb25n cyB0byB3aGljaCBwYWNrZXQgcGF5bG9hZCBpbiBhIHNlcXVlbmNlIG9mIA0KICAgIGluZm9ybWF0 aW9uIGVsZW1lbnRzKS4gW1BTQU1QLUlORk9dIGRlZmluZXMgdXNlZnVsIGFkZGl0aW9uYWwgDQoN Cg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMTBdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNh YmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgaW5mb3JtYXRpb24gZWxl bWVudHMgZm9yIGV4cG9ydGluZyBwZXIgcGFja2V0IGluZm9ybWF0aW9uIHdpdGggDQogICAgSVBG SVguICANCiAgICAgDQogMi41LjEgQ29ycmVsYXRpbmcgRXZlbnRzIGZyb20gTXVsdGlwbGUgT2Jz ZXJ2YXRpb24gUG9pbnRzIA0KICAgICANCiAgICBTb21lIFFvUyBtZXRyaWNzIHJlcXVpcmUgdGhl IGNvcnJlbGF0aW9uIG9mIGRhdGEgZnJvbSBtdWx0aXBsZSANCiAgICBvYnNlcnZhdGlvbiBwb2lu dHMuIEZvciB0aGlzIHRoZSBjbG9ja3Mgb2YgdGhlIGludm9sdmVkIG1ldGVyaW5nIA0KICAgIHBy b2Nlc3NlcyBtdXN0IGJlIHN5bmNocm9uaXplZC4gRnVydGhlcm1vcmUsIGl0IGlzIG5lY2Vzc2Fy eSB0byANCiAgICByZWNvZ25pemUgdGhhdCB0aGUgc2FtZSBwYWNrZXQgd2FzIG9ic2VydmVkIGF0 IGRpZmZlcmVudCANCiAgICBvYnNlcnZhdGlvbiBwb2ludC4gDQogICAgVGhpcyBjYW4gYmUgZG9u ZSBieSBjYXB0dXJpbmcgcGFydHMgb2YgdGhlIHBhY2tldCBjb250ZW50IA0KICAgIChwYWNrZXQg aGVhZGVyIGFuZC9vciBwYXJ0cyBvZiB0aGUgcGF5bG9hZCkgdGhhdCBkbyBub3QgY2hhbmdlIA0K ICAgIG9uIHRoZSB3YXkgdG8gdGhlIGRlc3RpbmF0aW9uLiBCYXNlZCBvbiB0aGUgcGFja2V0IGNv bnRlbnQgaXQgDQogICAgY2FuIGJlIHJlY29nbml6ZWQgd2hlbiB0aGUgc2FtZSBwYWNrZXQgYXJy aXZlZCBhdCBhbm90aGVyIA0KICAgIG9ic2VydmF0aW9uIHBvaW50LiBUbyByZWR1Y2UgdGhlIGFt b3VudCBvZiBtZWFzdXJlbWVudCBkYXRhIGEgDQogICAgdW5pcXVlIHBhY2tldCBJRCBjYW4gYmUg Y2FsY3VsYXRlZCBmcm9tIHRoZSBwYWNrZXQgY29udGVudCBlLmcuIA0KICAgIGJ5IHVzaW5nIGEg Q1JDIG9yIGhhc2ggZnVuY3Rpb24gaW5zdGVhZCBvZiB0cmFuc2ZlcnJpbmcgYW5kIA0KICAgIGNv bXBhcmluZyB0aGUgdW5wcm9jZXNzZWQgY29udGVudC4gQ29uc2lkZXJhdGlvbnMgb24gY29sbGlz aW9uIA0KICAgIHByb2JhYmlsaXR5IGFuZCBlZmZpY2llbmN5IG9mIHVzaW5nIHN1Y2ggcGFja2V0 IElEcyBhcmUgDQogICAgZGVzY3JpYmVkIGluIFtHckRNOTgsIER1R3IwMCwgWnNaQzAxXS4gDQog ICAgIA0KICAgIElQRklYIGFsbG93cyB0aGUgcmVwb3J0aW5nIG9mIHNldmVyYWwgSVAgYW5kIHRy YW5zcG9ydCBoZWFkZXIgDQogICAgZmllbGRzIChzZWUgc2VjdGlvbiA1LjMgYW5kIDUuNCBpbiBb SVBGSVgtSU5GT10pLiBVc2luZyBvbmx5IA0KICAgIHRob3NlIGZpZWxkcyBmb3IgcGFja2V0IHJl Y29nbml0aW9uIG9yIElEIGdlbmVyYXRpb24gY2FuIGJlIA0KICAgIHN1ZmZpY2llbnQgaW4gc2Nl bmFyaW9zIHdoZXJlIHRob3NlIGhlYWRlciBmaWVsZHMgdmFyeSBhIGxvdCANCiAgICBhbW9uZyBz dWJzZXF1ZW50IHBhY2tldHMsIHdoZXJlIGEgY2VydGFpbiBhbW91bnQgb2YgcGFja2V0IElEIA0K ICAgIGNvbGxpc2lvbnMgaXMgdG9sZXJhYmxlIG9yIHdoZXJlIHBhY2tldCBJRHMgbmVlZCB0byBi ZSB1bmlxdWUgDQogICAgb25seSBmb3IgYSBzbWFsbCB0aW1lIGludGVydmFsLiANCiAgICAgDQog ICAgRm9yIGluY2x1ZGluZyBwYWNrZXQgcGF5bG9hZCBpbmZvcm1hdGlvbiB0aGUgaW5mb3JtYXRp b24gZWxlbWVudCANCiAgICBpcFBheWxvYWRQYWNrZXRTZWN0aW9uIGRlZmluZWQgaW4gW1BTQU1Q LUlORk9dIGNhbiBiZSB1c2VkLiBUaGUgDQogICAgaW5mb3JtYXRpb24gZWxlbWVudCBpcEhlYWRl clBhY2tldFNlY3Rpb24gY2FuIGFsc28gYmUgdXNlZC4gQnV0IA0KICAgIGhlYWRlciBmaWVsZHMg dGhhdCBjYW4gY2hhbmdlIG9uIHRoZSB3YXkgZnJvbSBzb3VyY2UgdG8gDQogICAgZGVzdGluYXRp b24gaGF2ZSB0byBiZSBleGNsdWRlZCBmcm9tIHRoZSBwYWNrZXQgSUQgZ2VuZXJhdGlvbiwgDQog ICAgYmVjYXVzZSB0aGV5IG1heSBkaWZmZXIgYXQgZGlmZmVyZW50IG9ic2VydmF0aW9uIHBvaW50 cy4gIA0KICAgICANCiAgICBGb3IgcmVwb3J0aW5nIHBhY2tldCBJRHMgZ2VuZXJhdGVkIGJ5IGEg Q1JDIG9yIGhhc2ggZnVuY3Rpb24gdGhlIA0KICAgIGluZm9ybWF0aW9uIGVsZW1lbnQgZGlnZXN0 SGFzaFZhbHVlIGRlZmluZWQgaW4gW1BTQU1QLUlORk9dIGNhbiANCiAgICBiZSB1c2VkLiANCiAg ICAgDQogMi41LjIgRXhhbXBsZXMgDQogIA0KICAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZXMgc2hv dyB3aGljaCBpbmZvcm1hdGlvbiBlbGVtZW50cyBuZWVkIHRvIA0KICAgIGJlIHJlcG9ydGVkIGJ5 IElQRklYIHRvIGdlbmVyYXRlIHNwZWNpZmljIFFvUyBtZXRyaWNzLiBBcyBhbiANCiAgICBhbHRl cm5hdGl2ZSB0aGUgbWV0cmljcyBjYW4gYmUgZ2VuZXJhdGVkIGRpcmVjdGx5IGF0IHRoZSANCiAg ICBleHBvcnRlciBhbmQgSVBJRlggY2FuIGJlIHVzZWQgdG8gZXhwb3J0IHRoZSBtZXRyaWNzIChz ZWUgDQogICAgc2VjdGlvbiAyLjcpIA0KICANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3du bGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMV0gDQoMICAgICAg ICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAw NiANCg0KDQoNCiAyLjUuMi4xIFJUVCBtZWFzdXJlbWVudHMgd2l0aCBwYWNrZXQgcGFpciBtYXRj aGluZyAoc2luZ2xlLXBvaW50KSANCiAgICAgDQogICAgVGhlIHBhc3NpdmUgbWVhc3VyZW1lbnQg b2Ygcm91bmQtdHJpcC10aW1lcyAoUlRUKSBjYW4gYmUgDQogICAgcGVyZm9ybWVkIGJ5IHVzaW5n IHBhY2tldCBwYWlyIG1hdGNoaW5nIHRlY2huaXF1ZXMgYXMgZGVzY3JpYmVkIA0KICAgIGluIFtC cm93MDBdLiBGb3IgdGhlIG1lYXN1cmVtZW50cywgcmVxdWVzdC9yZXNwb25zZSBwYWNrZXQgcGFp cnMgDQogICAgZnJvbSBwcm90b2NvbHMgc3VjaCBhcyBETlMsIElDTVAsIFNOTVAgb3IgVENQIChT WU4vU1lOX0FDSywgDQogICAgREFUQS9BQ0spIGFyZSB1dGlsaXplZCB0byBwYXNzaXZlbHkgb2Jz ZXJ2ZSB0aGUgUlRUIFtCcm93MDBdLiANCiAgICBUaGlzIHRlY2huaXF1ZSByZXF1aXJlcyB0aGUg Y29ycmVsYXRpb24gb2YgZGF0YSBmcm9tIGJvdGggDQogICAgZGlyZWN0aW9ucy4gDQogICAgIA0K ICAgIFJlcXVpcmVkIGluZm9ybWF0aW9uIGVsZW1lbnRzIHBlciBwYWNrZXQgKEROUyBleGFtcGxl KTogIA0KICAgIC0gUGFja2V0IGFycml2YWwgdGltZTogb2JzZXJ2YXRpb25UaW1lTWljcm9zZWNv bmRzIFtQU0FNUC1JTkZPXSAgDQogICAgLSBETlMgaGVhZGVyOiBpcFBheWxvYWRQYWNrZXRTZWN0 aW9uIFtQU0FNUC1JTkZPXSANCiAgICAgDQogICAgUmVxdWlyZWQgZnVuY3Rpb25zOiAgDQogICAg LSBSZWNvZ25pdGlvbiBvZiByZXF1ZXN0L3Jlc3BvbnNlIHBhY2tldCBwYWlycyANCiAgICAgDQog ICAgUmVtYXJrczogDQogICAgLSBSZXF1aXJlcyBpbmZvcm1hdGlvbiBlbGVtZW50cyBmcm9tIFtQ U0FNUC1JTkZPXSANCiAgICAtIG9ic2VydmF0aW9uVGltZU1pY3Jvc2Vjb25kcyBjYW4gYmUgc3Vi c3RpdHV0ZWQgYnkgDQogICAgICAgZmxvd1N0YXJ0TWljcm9zZWNvbmRzIFtJUEZJWC1JTkZPXSwg YmVjYXVzZSBhIHNpbmdsZSBwYWNrZXQgDQogICAgICAgY2FuIGJlIHJlcHJlc2VudGVkIGFzIGEg Zmxvdy4gDQogICAgLSBJZiB0aW1lIHZhbHVlcyB3aXRoIGEgaGlnaGVyIGdyYW51bGFyaXR5IGFy ZSBuZWVkZWQgDQogICAgICAgb2JzZXJ2YXRpb25UaW1lTmFub3NlY29uZHMgY2FuIGJlIHVzZWQu IA0KICANCiAyLjUuMi4yIE9uZS13YXkgRGVsYXkgTWVhc3VyZW1lbnRzIChtdWx0aS1wb2ludCkg DQogIA0KICAgIFBhc3NpdmUgb25lLXdheS1kZWxheSBtZWFzdXJlbWVudHMgcmVxdWlyZSB0aGUg Y29sbGVjdGlvbiBvZiANCiAgICBkYXRhIGF0IHR3byBvYnNlcnZhdGlvbiBwb2ludHMuIFRoZSBy ZWNvZ25pdGlvbiBvZiBwYWNrZXRzIGF0IA0KICAgIHRoZSBzZWNvbmQgb2JzZXJ2YXRpb24gcG9p bnQgY2FuIGJlIGJhc2VkIG9uIHBhcnRzIG9mIHRoZSBwYWNrZXQgDQogICAgY29udGVudCBkaXJl Y3RseS4gQSBtb3JlIGVmZmljaWVudCB3YXkgaXMgdG8gdXNlIGEgcGFja2V0IElEIA0KICAgIChn ZW5lcmF0ZWQgZnJvbSBwYWNrZXQgY29udGVudCkuIA0KICAgICANCiAgICBSZXF1aXJlZCBpbmZv cm1hdGlvbiBlbGVtZW50cyBwZXIgcGFja2V0ICh3aXRoIHBhY2tldCBJRCk6IA0KICAgIC0gUGFj a2V0IGFycml2YWwgdGltZTogb2JzZXJ2YXRpb25UaW1lTWljcm9zZWNvbmRzIFtQU0FNUC1JTkZP XSAgDQogICAgLSBQYWNrZXQgSUQ6IGRpZ2VzdEhhc2hWYWx1ZSBbUFNBTVAtSU5GT10gDQogICAg IA0KICAgIFJlcXVpcmVkIGZ1bmN0aW9uczogIA0KICAgIC0gcGFja2V0IElEIGdlbmVyYXRpb24g DQogICAgLSBkZWxheSBjYWxjdWxhdGlvbiAoZnJvbSBhcnJpdmFsIHRpbWVzIGF0IHRoZSB0d28g b2JzZXJ2YXRpb24gDQogICAgICAgcG9pbnRzKSANCiAgDQogICAgUmVtYXJrczogDQogICAgLSBS ZXF1aXJlcyBpbmZvcm1hdGlvbiBlbGVtZW50cyBmcm9tIFtQU0FNUC1JTkZPXSANCiAgICAtIG9i c2VydmF0aW9uVGltZU1pY3Jvc2Vjb25kcyBjYW4gYmUgc3Vic3RpdHV0ZWQgYnkgDQogICAgICAg Zmxvd1N0YXJ0TWljcm9zZWNvbmRzIFtJUEZJWC1JTkZPXSwgYmVjYXVzZSBhIHNpbmdsZSBwYWNr ZXQgDQogICAgICAgY2FuIGJlIHJlcHJlc2VudGVkIGFzIGEgZmxvdy4gDQoNCg0KDQoNCg0KIFpz ZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSAxMl0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAg ICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICAtIElmIHRpbWUgdmFsdWVzIHdpdGggYSBo aWdoZXIgZ3JhbnVsYXJpdHkgYXJlIG5lZWRlZCANCiAgICAgICBvYnNlcnZhdGlvblRpbWVOYW5v c2Vjb25kcyBjYW4gYmUgdXNlZC4gDQogICAgLSBUaGUgYW1vdW50IG9mIGNvbnRlbnQgdXNlZCBm b3IgSUQgZ2VuZXJhdGlvbiBpbmZsdWVuY2VzIHRoZSANCiAgICAgICBudW1iZXIgb2YgY29sbGlz aW9ucyAoZGlmZmVyZW50IHBhY2tldHMgdGhhdCBtYXAgdG8gdGhlIHNhbWUgDQogICAgICAgSUQp ICB0aGF0IGNhbiBvY2N1ci4gSW52ZXN0aWdhdGlvbnMgb24gdGhpcyBhbmQgb3RoZXIgDQogICAg ICAgY29uc2lkZXJhdGlvbnMgb24gcGFja2V0IElEIGdlbmVyYXRpb24gY2FuIGJlIGZvdW5kIGlu IA0KICAgICAgIFtHckRNOThdLCBbRHVHcjAwXSwgYW5kIFtac1pDMDFdLiANCiAgDQogIDIuNiBJ bnRlci1Eb21haW4gRXhjaGFuZ2Ugb2YgSVBGSVggZGF0YSANCiAgICAgDQogICAgSVBGSVggZGF0 YSBjYW4gYmUgdXNlZCB0byBzaGFyZSBpbmZvcm1hdGlvbiB3aXRoIG5laWdoYm9yIA0KICAgIHBy b3ZpZGVycy4gQSBmZXcgcmVjb21tZW5kYXRpb25zIHNob3VsZCB0byBiZSBjb25zaWRlcmVkIGlm IA0KICAgIElQRklYIHJlY29yZHMgdHJhdmVsIG92ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldCBjb21w YXJlZCB0byBpdHMgDQogICAgdXNhZ2Ugd2l0aGluIGEgc2luZ2xlIGRvbWFpbi4gRmlyc3Qgb2Yg YWxsLCBzZWN1cml0eSB0aHJlYXRzIGFyZSANCiAgICBoaWdoZXIgaWYgZGF0YSB0cmF2ZWxzIG92 ZXIgdGhlIHB1YmxpYyBJbnRlcm5ldC4gUHJvdGVjdGlvbiANCiAgICBhZ2FpbnN0IGRpc2Nsb3N1 cmUgb3IgbWFuaXB1bGF0aW9uIG9mIGRhdGEgaXMgZXZlbiBtb3JlIA0KICAgIGltcG9ydGFudCB0 aGFuIGZvciBpbnRyYS1kb21haW4gdXNhZ2UuIFRoZXJlZm9yZSBJUHNlYyBvciANCiAgICBUcmFu c3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgc2hvdWxkIGJlIHVzZWQgYXMgZGVzY3JpYmVkIGlu IA0KICAgIFtJUEZJWC1QUk9UT10uIA0KICAgICANCiAgICBGdXJ0aGVybW9yZSBkYXRhIHRyYW5z ZmVyIHNob3VsZCBiZSBjb25nZXN0aW9uLWF3YXJlIGluIG9yZGVyIHRvIA0KICAgIGFsbG93IHVu dHJvdWJsZWQgY28tZXhpc3RlbmNlIHdpdGggb3RoZXIgZGF0YSBmbG93cy4gVGhhdCBtZWFucyAN CiAgICB0cmFuc3BvcnQgb3ZlciBTQ1RQIG9yIFRDUCBpcyByZXF1aXJlZC4gIA0KICAgICANCiAg ICBTb21lIElTUHMgYXJlIHN0aWxsIHJlbHVjdGFudCB0byBzaGFyZSBpbmZvcm1hdGlvbiBkdWUg dG8gDQogICAgY29uY2VybnMgdGhhdCBjb21wZXRpbmcgSVNQcyBtaWdodCBleHBsb2l0IG5ldHdv cmsgaW5mb3JtYXRpb24gDQogICAgZnJvbSBuZWlnaGJvciBwcm92aWRlcnMgdG8gc3RyZW5ndGhl biB0aGVpciBvd24gcG9zaXRpb24gaW4gdGhlIA0KICAgIG1hcmtldC4gTmV2ZXJ0aGVsZXNzLCB0 ZWNobmljYWwgbmVlZHMgaGF2ZSBhbHJlYWR5IHRyaWdnZXJlZCB0aGUgDQogICAgZXhjaGFuZ2Ug b2YgZGF0YSBpbiB0aGUgcGFzdCAoZS5nLiBleGNoYW5nZSBvZiByb3V0aW5nIA0KICAgIGluZm9y bWF0aW9uIGJ5IEJHUCkuIFRoZSBuZWVkIHRvIHByb3ZpZGUgaW50ZXItZG9tYWluIGd1YXJhbnRl ZXMgDQogICAgaXMgb25lIGJpZyBpbmNlbnRpdmUgdG8gaW5jcmVhc2UgaW50ZXItZG9tYWluIGNv b3BlcmF0aW9uLiBUaGUgDQogICAgbmVjZXNzaXR5IHRvIGRlZmVuZCBuZXR3b3JrcyBhZ2FpbnN0 IGN1cnJlbnQgYW5kIGZ1dHVyZSB0aHJlYXRzIA0KICAgIChkZW5pYWwgb2Ygc2VydmljZSBhdHRh Y2tzLCB3b3JtIGRpc3RyaWJ1dGlvbnMsIGV0Yy4pIHdpbGwgDQogICAgaG9wZWZ1bGx5IGluY3Jl YXNlIHRoZSB3aWxsaW5nbmVzcyB0byBleGNoYW5nZSBtZWFzdXJlbWVudCBkYXRhIA0KICAgIGJl dHdlZW4gcHJvdmlkZXJzLiANCiAgICAgDQogIDIuNyAgRXhwb3J0IG9mIERlcml2ZWQgTWV0cmlj cyANCiAgICAgDQogIA0KICAgIFRoZSBJUEZJWCBwcm90b2NvbCBpcyB1c2VkIHRvIHRyYW5zcG9y dCBmbG93IGFuZCBwYWNrZXQgDQogICAgaW5mb3JtYXRpb24gdG8gcHJvdmlkZSB0aGUgaW5wdXQg Zm9yIHRoZSBjYWxjdWxhdGlvbiBvZiBhIA0KICAgIHZhcmlldHkgbWV0cmljcyAoZS5nLiBmb3Ig UW9TIHZhbGlkYXRpb24gb3IgYXR0YWNrIGRldGVjdGlvbikuICANCiAgICBJUEZJWCBjYW4gYWxz byBiZSB1c2VkIHRvIHRyYW5zZmVyIHRoZXNlIG1ldHJpY3MgZGlyZWN0bHksIGUuZy4gDQogICAg aWYgdGhlIG1ldHJpYyBjYWxjdWxhdGlvbiBpcyBjby1sb2NhdGVkIHdpdGggbWVhc3VyZW1lbnQg YW5kIA0KICAgIGV4cG9ydGluZyBwcm9jZXNzLiANCiAgICAgDQogICAgSXQgZG9lc24ndCBtYXR0 ZXIgd2hpY2ggbWVhc3VyZW1lbnQgYW5kIHBvc3QtcHJvY2Vzc2luZyANCiAgICBmdW5jdGlvbnMg YXJlIGFwcGxpZWQgdG8gZ2VuZXJhdGUgYSBzcGVjaWZpYyBtZXRyaWMuIElQRklYIGNhbiANCg0K DQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAg ICAgICAgICBbUGFnZSAxM10gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2Fi aWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICBiZSB1c2VkIHRvIHRyYW5z cG9ydCB0aGUgcmVzdWx0cyBmcm9tIHBhc3NpdmUgYW5kIGFjdGl2ZSANCiAgICBtZWFzdXJlbWVu dHMgYW5kIGZyb20gcG9zdC1wcm9jZXNzaW5nIG9wZXJhdGlvbnMuIEZvciB0aGUgDQogICAgcmVw b3J0aW5nIG9mIGRlcml2ZWQgbWV0cmljcyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGVsZW1lbnRz IA0KICAgIG5lZWQgdG8gYmUgZGVmaW5lZC4gDQogIA0KICAyLjggU3VtbWFyeSANCiAgICAgDQog ICAgVGhlIGZvbGxvd2luZyB0YWJsZSBzaG93cyBhbiBvdmVydmlldyBvZiB0aGUgaW5mb3JtYXRp b24gDQogICAgZWxlbWVudHMgcmVxdWlyZWQgZm9yIHRoZSB0YXJnZXQgYXBwbGljYXRpb25zIGRl c2NyaWJlZCBpbiANCiAgICBbUkZDMzkxN10gKE0tbWFuZGF0b3J5LCBSLXJlY29tbWVuZGVkLCBP LW9wdGlvbmFsKS4gDQogIA0KICAgIHwgQXBwbGljYXRpb24gfFtJUEZJWC1JTkZPXXwgW1BTQU1Q LUlORk9dIHwgYWRkaXRpb25hbCBJRXMgIHwgDQogICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICB8IEFjY291bnRpbmcg IHwgICAgIE0gICAgICB8ICAgICAgLSAgICAgICB8ICAgICAgIC0gICAgICAgICB8IA0KICAgICst LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t LSsgDQogICAgfCBUcmFmZmljICAgICB8ICAgICBNICAgICAgfCAgICAgIE8gICAgICAgfCAgICAg ICAtICAgICAgICAgfCANCiAgICB8IFByb2ZpbGluZyAgIHwgICAgICAgICAgICB8ICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICB8IA0KICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgfCBUcmFmZmljICAgICB8 ICAgICBNICAgICAgfCAgICAgIC0gICAgICAgfCAgICAgICBPICAgICAgICAgfCANCiAgICB8IEVu Z2luZWVyaW5nIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICB8IChyb3V0aW5nIGluZm8pICB8 IA0KICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLSsgDQogICAgfCBBdHRhY2sgICAgICB8ICAgICBNICAgICAgfCAgICAgIFIgICAg ICAgfCAgICAgICBSICAgICAgICAgfCANCiAgICB8IERldGVjdGlvbiAgIHwgICAgICAgICAgICB8 ICAgICAgICAgICAgICB8KGRlcml2ZWQgbWV0cmljcyl8IA0KICAgICstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgfCBRb1Mg ICAgICAgICB8ICAgICBNICAgICAgfCAgICAgIE0gICAgICAgfCAgICAgICBPICAgICAgICAgfCAN CiAgICB8IE1vbml0b3JpbmcgIHwgICAgICAgICAgICB8KG1vc3QgbWV0cmljcyl8KGRlcml2ZWQg bWV0cmljcyl8IA0KICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLSsgDQogIA0KICAgIEZvciBhY2NvdW50aW5nIHRoZSBJRXMgaW4g W0lQRklYLUlORk9dIGFyZSBzdWZmaWNpZW50LiBGb3IgDQogICAgdHJhZmZpYyBwcm9maWxpbmcg YWRkaXRpb25hbGx5IElFcyBmcm9tIFtQU0FNUC1JTkZPXSBjYW4gYmUgDQogICAgdXNlZnVsIHRv IGdhaW4gbW9yZSBpbnNpZ2h0IGludG8gdGhlIHRyYWZmaWMuIEZvciB0cmFmZmljIA0KICAgIGVu Z2luZWVyaW5nIGZsb3cgaW5mb3JtYXRpb24gZnJvbSBbSVBGSVgtSU5GT10gaXMgc3VmZmljaWVu dCBidXQgDQogICAgaXQgd291bGQgcHJvZml0IGZyb20gcm91dGluZyBpbmZvcm1hdGlvbiwgd2hp Y2ggY291bGQgYmUgDQogICAgZXhwb3J0ZWQgYnkgSVBGSVguIEF0dGFjayBkZXRlY3Rpb24gdXN1 YWxseSBwcm9maXRzIGZyb20gZnVydGhlciANCiAgICBpbnNpZ2h0IGludG8gdGhlIHRyYWZmaWMu IFRoaXMgY2FuIGJlIGFjaGlldmVkIHdpdGggSUVzIGZyb20gDQogICAgW1BTQU1QLUlORk9dLiBG dXJ0aGVybW9yZSB0aGUgcmVwb3J0aW5nIG9mIGRlcml2ZWQgbWV0cmljcyBpbiANCiAgICBhZGRp dGlvbmFsIElFcyB3b3VsZCBiZSB1c2VmdWwuIE1vc3QgUW9TIG1ldHJpY3MgcmVxdWlyZSB0aGUg dXNlIA0KICAgIG9mIElFcyBmcm9tIFtQU0FNUC1JTkZPXS4gSUVzIGZyb20gW1BTQU1QLUlORk9d YXJlIGFsc28gdXNlZnVsIA0KICAgIGZvciB0aGUgbWFwcGluZyBvZiByZXN1bHRzIGZyb20gZGlm ZmVyZW50IG9ic2VydmF0aW9uIHBvaW50cyBhcyANCiAgICBkZXNjcmliZWQgaW4gc2VjdGlvbiAy LjUuMS4gDQogIA0KIDMuIFJlbGF0aW9uIG9mIElQRklYIHRvIE90aGVyIEZyYW1ld29ya3MgYW5k IFByb3RvY29scyAgDQogICAgIA0KICAzLjEgSVBGSVggYW5kIFBTQU1QIA0KICAgICANCiAgICBQ U0FNUCBkZWZpbmVzIHBhY2tldCBzZWxlY3Rpb24gbWV0aG9kcywgdGhlaXIgY29uZmlndXJhdGlv biBhdCANCiAgICByb3V0ZXJzIGFuZCBwcm9iZXMgYW5kIHRoZSByZXBvcnRpbmcgb2YgcGFja2V0 IGluZm9ybWF0aW9uLiAgDQogICAgIA0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUs IENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XSANCgwgICAgICAgICAg ICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0K DQoNCg0KICAgIFBTQU1QIHVzZXMgSVBJRlggYXMgYmFzaXMgZm9yIGV4cG9ydGluZyBwYWNrZXQg aW5mb3JtYXRpb24gDQogICAgW1BTQU1QLVBST1RPXS4gW1BTQU1QLUlORk9dIGRlc2NyaWJlcyBm dXJ0aGVyIGluZm9ybWF0aW9uIA0KICAgIGVsZW1lbnRzIGZvciBleHBvcnRpbmcgcGFja2V0IGlu Zm9ybWF0aW9uIGFuZCByZXBvcnRpbmcgDQogICAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbi4g DQogIA0KICAgIFRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2VlbiBJUEZJWCBhbmQgUFNBTVAgaXMg dGhhdCBJUEZJWCANCiAgICBhZGRyZXNzZXMgdGhlIGV4cG9ydCBvZiBmbG93IHJlY29yZHMgd2hl cmVhcyBQU0FNUCBhZGRyZXNzZXMgdGhlIA0KICAgIGV4cG9ydCBvZiBwYWNrZXQgcmVjb3Jkcy4g RnVydGhlcm1vcmUsIFBTQU1QIGV4cGxpY2l0bHkgDQogICAgYWRkcmVzc2VzIHJlbW90ZSBjb25m aWd1cmF0aW9uLiBJdCBkZWZpbmVzIGEgTUlCIGZvciB0aGUgDQogICAgY29uZmlndXJhdGlvbiBv ZiBwYWNrZXQgc2VsZWN0aW9uIHByb2Nlc3Nlcy4gUmVtb3RlIA0KICAgIGNvbmZpZ3VyYXRpb24g aXMgbm90ICh5ZXQpIGFkZHJlc3NlZCBpbiBJUEZJWCwgYnV0IG9uZSBjb3VsZCANCiAgICBjb25z aWRlciBleHRlbmRpbmcgdGhlIFBTQU1QIE1JQiB0byBhbHNvIGFsbG93IGNvbmZpZ3VyYXRpb24g b2YgDQogICAgSVBGSVggcHJvY2Vzc2VzLiAgDQogIA0KICAzLjIgSVBGSVggYW5kIFJNT04gDQog ICAgIA0KICAgIFJNT04gW1JGQzM1NzddIGlzIGEgd2lkZWx5IHVzZWQgbW9uaXRvcmluZyBzeXN0 ZW0gdGhhdCBnYXRoZXJzIA0KICAgIHRyYWZmaWMgZGF0YSBmcm9tIFJNT04gQWdlbnRzIGluIG5l dHdvcmsgZGV2aWNlcy4gT25lIG1ham9yIA0KICAgIGRpZmZlcmVuY2UgYmV0d2VlbiBSTU9OIGFu ZCBJUEZJWCBpcyB0aGF0IFJNT04gdXNlcyBTTk1QIGZvciANCiAgICBkYXRhIGV4cG9ydCB3aGVy ZWFzIElQSUZYIGRlZmluZXMgYW4gb3duIHB1c2gtb3JpZW50ZWQgcHJvdG9jb2wuIA0KICAgIFJN T04gZGVmaW5lcyBNSUJzIHRoYXQgY29udGFpbiB0aGUgaW5mb3JtYXRpb24gdG8gYmUgZXhwb3J0 ZWQuIA0KICAgIEluIElQRklYIHRoZSBkYXRhIHRvIGJlIGV4cG9ydGVkIGlzIGRlZmluZWQgYXMg aW5mb3JtYXRpb24gDQogICAgZWxlbWVudHMuIA0KICAgIFRoZSBtb3N0IHJlbGV2YW50IE1JQnMg Zm9yIGEgY29tcGFyaXNvbiB3aXRoIElQRklYIGFyZSB0aGUgDQogICAgQXBwbGljYXRpb24gUGVy Zm9ybWFuY2UgTWVhc3VyZW1lbnQgTUlCIChBUE0tTUlCKSBbUkZDMzcyOV0gYW5kIA0KICAgIHRo ZSBUcmFuc3BvcnQgUGVyZm9ybWFuY2UgTWV0cmljcyBNSUIgKFRQTS1NSUIpIFtSRkM0MTUwXS4g DQogICAgVGhlIEFQTS1NSUIgaGFzIGEgY29tcGxleCBzeXN0ZW0gZm9yIHRyYWNraW5nIHVzZXIg YXBwbGljYXRpb24gDQogICAgcGVyZm9ybWFuY2UsIHdpdGggcmVwb3J0aW5nIGFib3V0IHRyYW5z YWN0aW9ucyBhbmQgU0xBIHRocmVzaG9sZCANCiAgICBub3RpZmljYXRpb24tdHJpZ2dlciBjb25m aWd1cmF0aW9uLCBhbmQgcGVyc2lzdGVuY2UgYWNyb3NzIERIQ1AgDQogICAgbGVhc2UgZXhwaXJh dGlvbnMuIEl0IHJlcXVpcmVzIGZ1bGwgUk1PTjItTUlCIHByb3RvY29sRGlyVGFibGUgDQogICAg aW1wbGVtZW50YXRpb24uIA0KICAgIFRoZSBBUE0tTUlCIHJlcG9ydHMgdGhlIHBlcmZvcm1hbmNl IG9mIHRyYW5zYWN0aW9ucy4gQSANCiAgICB0cmFuc2FjdGlvbiBpcyBhIHNlcnZpY2Ugb3JpZW50 ZWQgdGVybSBhbmQgZGVzY3JpYmVzIHRoZSBkYXRhIA0KICAgIGV4Y2hhbmdlIGZyb20gdGhlIHRy YW5zYWN0aW9uIHN0YXJ0ICh3aGVuIGEgdXNlciByZXF1ZXN0cyBhIA0KICAgIHNlcnZpY2UpIHVu dGlsIGl0cyBjb21wbGV0aW9uLiBUaGUgcGVyZm9ybWFuY2UgcGFyYW1ldGVycyANCiAgICBpbmNs dWRlIHJlc3BvbnNlIHRpbWVzLCB0aHJvdWdocHV0LCBzdHJlYW1pbmcgcmVzcG9uc2l2ZW5lc3Mg YW5kIA0KICAgIGF2YWlsYWJpbGl0eSBvZiBzZXJ2aWNlcy4gIA0KICAgIFRoZSBSTU9OIHRyYW5z YWN0aW9uIGNvbmNlcHQgZGlmZmVycyBmcm9tIHRoZSBJUEZJWCBmbG93IA0KICAgIGNvbmNlcHQu IEEgZmxvdyBpcyBhIHZlcnkgZ2VuZXJpYyB0ZXJtIGFuZCBhbGxvd3MgdG8gZ3JvdXAgSVAgDQog ICAgcGFja2V0cyBpbiBhY2NvcmRhbmNlIHRvIGNvbW1vbiBwcm9wZXJ0aWVzLiAgSW4gY29udHJh c3QgdG8gDQogICAgdGhpcywgdGhlIHRlcm0gdHJhbnNhY3Rpb24gaXMgc2VydmljZS1vcmllbnRl ZCBhbmQgY29udGFpbnMgYWxsIA0KICAgIGRhdGEgZXhjaGFuZ2UgcmVxdWlyZWQgZm9yIHNlcnZp Y2UgY29tcGxldGlvbi4gIA0KICAgIEluIG9yZGVyIHRvIHJlcG9ydCBzdWNoIGRhdGEgd2l0aCBJ UEZJWCBvbmUgd291bGQgcHJvYmFibHkgbmVlZCANCiAgICBhIHNwZWNpZmljIGNvbWJpbmF0aW9u IG9mIG11bHRpcGxlIGZsb3dzIGFuZCB0aGUgYWJpbGl0eSB0byBtYXAgDQogICAgdGhvc2UgdG8g dGhlIHRyYW5zYWN0aW9uLiBEdWUgdG8gdGhlIHNlcnZpY2Utb3JpZW50YXRlZCBmb2N1cyBvZiAN CiAgICBBUE0sIGFsc28gdGhlIHJlcXVpcmVkIG1ldHJpY3MgZGlmZmVyLiBGb3IgaW5zdGFuY2Us IHRoZSBSTU9OIA0KICAgIEFQTSByZXF1aXJlcyBhIG1ldHJpYyBmb3IgdGhlIHJlc3BvbnNpdmVu ZXNzIG9mIHNlcnZpY2VzLiBTdWNoIA0KICAgIG1ldHJpY3MgYXJlIG5vdCBhZGRyZXNzZWQgaW4g SVBGSVguIA0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBG SVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgIEZ1cnRo ZXJtb3JlLCB0aGUgQVBNLU1JQiBhbGxvd3MgdGhlIGNvbmZpZ3VyYXRpb24gb2YgdGhlIA0KICAg IHRyYW5zYWN0aW9uIHR5cGUgdG8gYmUgbW9uaXRvcmVkLCBpLmUuLCBpdCBhZGRyZXNzZXMgdGhl IA0KICAgIGNvbmZpZ3VyYXRpb24gb2YgdGhlIG1ldGVyaW5nIHByb2Nlc3MsIHdoaWNoIGlzIGN1 cnJlbnRseSBub3QgDQogICAgYWRkcmVzc2QgaW4gSVBGSVguICANCiAgICBUaGUgQVBNIE1JQiBj b3VsZCBiZSBjb25zaWRlcmVkIGFzIGFuIGV4dGVuc2lvbiBvZiB0aGUgSVBGSVggDQogICAgbWV0 ZXJpbmcgcHJvY2VzcyB3aGVyZSB0aGUgYXBwbGljYXRpb24gcGVyZm9ybWFuY2Ugb2YgYSANCiAg ICBjb21iaW5hdGlvbiBvZiBtdWx0aXBsZSBmbG93cyBpcyBtZWFzdXJlZC4gSWYgYXBwcm9wcmlh dGUgSUVzIA0KICAgIHdvdWxkIGJlIGRlZmluZWQgaW4gdGhlIElQRklYIGluZm9ybWF0aW9uIG1v ZGVsIGFuZCB0aGUgSVBGSVggDQogICAgZGV2aWNlIHdvdWxkIHN1cHBvcnQgdGhlIEFQTSBNSUIg ZGF0YSBjb2xsZWN0aW9uLCB0aGUgc29sdXRpb25zIA0KICAgIGNvdWxkIGJlIGNvbXBsaW1lbnRh cnkuIFRoYXQgbWVhbnMgb25lIGNvdWxkIHVzZSBJUEZJWCB0byBleHBvcnQgDQogICAgQVBNIE1J QiB0cmFuc2FjdGlvbiBpbmZvcm1hdGlvbi4gDQogICAgVGhlIFRQTS1NSUIgYnJlYWtzIG91dCB0 aGUgQVBNLU1JQiB0cmFuc2FjdGlvbnMgaW50byBzdWItDQogICAgYXBwbGljYXRpb24gbGV2ZWwg dHJhbnNhY3Rpb24uIEZvciBpbnN0YW5jZSBhIHdlYiByZXF1ZXN0IGlzIA0KICAgIGJyb2tlbiBk b3duIGludG8gRE5TLCBUQ1AgYW5kIEhUVFAgc3ViLXRyYW5zYWN0aW9ucy4gQWdhaW4gc3ViLQ0K ICAgIGFwcGxpY2F0aW9uIGxldmVsIHRyYW5zYWN0aW9uIGNvdWxkIGJlIG1lYXN1cmVkIHVzaW5n IElQRklYIHdpdGggDQogICAgYW4gYXBwcm9wcmlhdGUgZmxvdyBkZWZpbml0aW9uIGFuZCBieSBj b21iaW5pbmcgdGhlIHJlcG9ydGluZyBvZiANCiAgICBib3RoIGRpcmVjdGlvbnMgb2YgdGhlIGRh dGEgdHJhbnNmZXIgKGZvciByZXBvcnRpbmcgYmktDQogICAgZGlyZWN0aW9uYWwgZmxvdyBpbmZv cm1hdGlvbiBzZWUgYWxzbyBzZWN0aW9uIDQuNSkuIFRoZSBUUE0tTUlCIA0KICAgIHJlcXVpcmVz IEFQTS1NSUIgYW5kIFJNT04yLU1JQi4gDQogIA0KICAzLjMgSVBGSVggYW5kIElQUE0gDQogICAg IA0KICAgIFRoZSBJUEZJWCBwcm90b2NvbCBjYW4gYmUgdXNlZCB0byBjYXJyeSBJUFBNIG5ldHdv cmsgcGVyZm9ybWFuY2UgDQogICAgbWV0cmljcyBvciBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSB1 c2VkIHRvIGNhbGN1bGF0ZSB0aG9zZSANCiAgICBtZXRyaWNzIChzZWUgc2VjdGlvbnMgMi41IGFu ZCAyLjcpLiANCiAgICAgDQogIDMuNCBJUEZJWCBhbmQgQUFBICANCiAgICAgDQogICAgQUFBIGRl ZmluZXMgYSBwcm90b2NvbCBhbmQgYXJjaGl0ZWN0dXJlIGZvciBhdXRoZW50aWNhdGlvbiwgDQog ICAgYXV0aG9yaXphdGlvbiBhbmQgYWNjb3VudGluZyBmb3Igc2VydmljZSB1c2FnZSBbUkZDMjkw M10uIFRoZSANCiAgICBESUFNRVRFUiBwcm90b2NvbCBbUkZDMzU4OF0gaXMgdXNlZCBmb3IgQUFB IGNvbW11bmljYXRpb24sIHdoaWNoIA0KICAgIGlzIG5lZWRlZCBmb3IgbmV0d29yayBhY2Nlc3Mg c2VydmljZXMgKE1vYmlsZSBJUCwgTkFTUkVRLCBhbmQgDQogICAgUk9BTU9QUykuIFRoZSBBQUEg YXJjaGl0ZWN0dXJlIFtSRkMyOTAzXSBwcm92aWRlcyBhIGZyYW1ld29yayANCiAgICBmb3IgZXh0 ZW5kaW5nIEFBQSBzdXBwb3J0IHRvIG90aGVyIHNlcnZpY2VzLiBESUFNRVRFUiBkZWZpbmVzIA0K ICAgIHRoZSBleGNoYW5nZSBvZiBtZXNzYWdlcyBiZXR3ZWVuIEFBQSBlbnRpdGllcywgZS5nLiBi ZXR3ZWVuIEFBQSANCiAgICBjbGllbnRzIGF0IGFjY2VzcyBkZXZpY2VzIGFuZCBBQUEgc2VydmVy cywgYW5kIGFtb25nIEFBQSANCiAgICBzZXJ2ZXJzLiBESUFNRVRFUiBpcyB1c2VkIGZvciB0aGUg dHJhbnNmZXIgb2YgYWNjb3VudGluZyANCiAgICByZWNvcmRzLiBJbiBvcmRlciB0byBmb3JtIGFj Y291bnRpbmcgcmVjb3JkcyBmb3IgdXNhZ2UtYmFzZWQgDQogICAgYWNjb3VudGluZyBtZWFzdXJl bWVudCBkYXRhIGZyb20gdGhlIG5ldHdvcmsgaXMgcmVxdWlyZWQuIElQRklYIA0KICAgIGRlZmlu ZXMgYSBwcm90b2NvbCB0byBleHBvcnQgc3VjaCBkYXRhIGZyb20gcm91dGVycywgbWVhc3VyZW1l bnQgDQogICAgcHJvYmVzIGFuZCBvdGhlciBkZXZpY2VzLiBUaGVyZWZvcmUgaXQgbG9va3MgcHJv bWlzaW5nIHRvIA0KICAgIGNvbm5lY3QgdGhvc2UgdHdvIGFyY2hpdGVjdHVyZXMuIA0KICAgICAN CiAgICBBcyBzaG93biBpbiBzZWN0aW9uIDIuMSBhY2NvdW50aW5nIGNhbiBiZSByZWFsaXplZCB3 aXRob3V0IGFuIA0KICAgIEFBQSBpbmZyYXN0cnVjdHVyZS4gQWNjb3VudGluZyBhcHBsaWNhdGlv bnMgY2FuIGRpcmVjdGx5IA0KICAgIGluY29ycG9yYXRlIGFuIElQRklYIGNvbGxlY3RpbmcgcHJv Y2VzcyB0byByZWNlaXZlIElQRklYIHJlY29yZHMgDQogICAgd2l0aCBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgdHJhbnNtaXR0ZWQgdm9sdW1lLiBOZXZlcnRoZWxlc3MsIGlmIA0KICAgIGFuIEFBQSBp bmZyYXN0cnVjdHVyZSBpcyBpbiBwbGFjZSwgdGhlIGNvb3BlcmF0aW9uIGJldHdlZW4gSVBGSVgg DQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1BhZ2UgMTZdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBs aWNhYmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgYW5kIEFBQSBwcm92 aWRlcyBtYW55IHZhbHVhYmxlIHN5bmVyZ2lzdGljIGJlbmVmaXRzLiBJUEZJWCANCiAgICByZWNv cmRzIGNhbiBwcm92aWRlIHRoZSBpbnB1dCBmb3IgQUFBIGFjY291bnRpbmcgZnVuY3Rpb25zIGFu ZCANCiAgICBwcm92aWRlIHRoZSBiYXNpcyBmb3IgdGhlIGdlbmVyYXRpb24gb2YgRElBTUVURVIg YWNjb3VudGluZyANCiAgICByZWNvcmRzLiBGdXJ0aGVyIHBvdGVudGlhbCBmZWF0dXJlcyBpbmNs dWRlIHRoZSBtYXBwaW5nIG9mIGEgDQogICAgdXNlciBJRCB0byBmbG93IGluZm9ybWF0aW9uIChi eSB1c2luZyBhdXRoZW50aWNhdGlvbiANCiAgICBpbmZvcm1hdGlvbikgb3IgZmFjaWxpdGF0aW5n IHRoZSBzZWN1cmUgYXV0aG9yaXplZCBleGNoYW5nZSBvZiANCiAgICBESUFNRVRFUiBhY2NvdW50 aW5nIHJlY29yZHMgd2l0aCBuZWlnaGJvciBkb21haW5zLiBUaGUgbGFzdCANCiAgICBmZWF0dXJl IGlzIGVzcGVjaWFsbHkgdXNlZnVsIGluIHJvYW1pbmcgc2NlbmFyaW9zIHdoZXJlIHRoZSB1c2Vy IA0KICAgIGNvbm5lY3RzIHRvIGEgZm9yZWlnbiBuZXR3b3JrIGFuZCB0aGUgaG9tZSBwcm92aWRl ciBnZW5lcmF0ZXMgDQogICAgdGhlIGludm9pY2UuICAgDQogICAgIA0KICAgIENvdXBsaW5nIGFu IElQRklYIGNvbGxlY3RpbmcgcHJvY2VzcyB3aXRoIEFBQSBmdW5jdGlvbnMgaGFzIGFsc28gDQog ICAgaGlnaCBwb3RlbnRpYWwgZm9yIGludHJ1c2lvbiBhbmQgYXR0YWNrIGRldGVjdGlvbi4gQUFB IGNvbnRyb2xzIA0KICAgIG5ldHdvcmsgYWNjZXNzIGFuZCBtYWludGFpbnMgZGF0YSBhYm91dCB1 c2VycyBhbmQgbm9kZXMuIEFBQSANCiAgICBmdW5jdGlvbnMgY2FuIGhlbHAgdG8gaWRlbnRpZnkg dGhlIHNvdXJjZSBvZiBtYWxpY2lvdXMgdHJhZmZpYy4gDQogICAgVGhleSBhcmUgYWJsZSB0byBk ZW55IGFjY2VzcyB0byBzdXNwaWNpb3VzIHVzZXJzIG9yIG5vZGVzLiANCiAgICBUaGVyZWZvcmUg Y291cGxpbmcgdGhvc2UgZnVuY3Rpb25zIHdpdGggYW4gSVBGSVggY29sbGVjdGluZyANCiAgICBw cm9jZXNzIGNhbiBwcm92aWRlIGFuIGVmZmljaWVudCBkZWZlbnNlIGFnYWluc3QgbmV0d29yayAN CiAgICBhdHRhY2tzLiBTaGFyaW5nIElQRklYIHJlY29yZHMgKGVpdGhlciBkaXJlY3RseSBvciBl bmNhcHN1bGF0ZWQgDQogICAgaW4gRElBTUVURVIpIHdpdGggbmVpZ2hib3IgcHJvdmlkZXJzIGFs bG93cyBhbiBlZmZpY2llbnQgaW50ZXItDQogICAgZG9tYWluIGF0dGFjayBkZXRlY3Rpb24uIFRo ZSBBQUEgaW5mcmFzdHJ1Y3R1cmUgY2FuIGFsc28gYmUgdXNlZCANCiAgICB0byBjb25maWd1cmUg bWVhc3VyZW1lbnQgZnVuY3Rpb25zIGluIHRoZSBuZXR3b3JrIGFzIHByb3Bvc2VkIGluIA0KICAg IFtSRkMzMzM0XS4gDQogICAgIA0KICAgIFR3byBwb3NzaWJpbGl0aWVzIGV4aXN0IHRvIGNvbm5l Y3QgSVBGSVggYW5kIEFBQTogIA0KICAgICANCiAgICAtIENvbm5lY3RpbmcgdmlhIGFuIEFBQSBD bGllbnQgDQogICAgLSBDb25uZWN0aW5nIHZpYSBhbiBBcHBsaWNhdGlvbiBTcGVjaWZpYyBNb2R1 bGUgKEFTTSkgDQogICAgIA0KICAgIEJvdGggYXJlIGV4cGxhaW5lZCBpbiB0aGUgZm9sbG93aW5n IHNlY3Rpb25zLiBUaGUgYXBwcm9hY2hlcyANCiAgICBvbmx5IHJlcXVpcmUgZmV3IGFkZGl0aW9u YWwgZnVuY3Rpb25zLiBUaGV5IGRvIG5vdCByZXF1aXJlIGFueSANCiAgICBjaGFuZ2VzIHRvIElQ RklYIG9yIERJQU1FVEVSLiANCiAgICAgDQogMy40LjEgQ29ubmVjdGluZyB2aWEgYW4gQUFBIENs aWVudCANCiAgICAgDQogICAgT25lIHBvc3NpYmlsaXR5IG9mIGNvbm5lY3RpbmcgSVBGSVggYW5k IEFBQSBpcyB0byBydW4gYW4gQUFBIA0KICAgIGNsaWVudCBvbiB0aGUgSVBGSVggY29sbGVjdG9y LiBUaGlzIGNsaWVudCBjYW4gZ2VuZXJhdGUgRElBTUVURVIgDQogICAgYWNjb3VudGluZyBtZXNz YWdlcyBhbmQgc2VuZCB0aGVtIHRvIGFuIEFBQSBzZXJ2ZXIuIFRoZSBtYXBwaW5nIA0KICAgIG9m IHRoZSBmbG93IGluZm9ybWF0aW9uIHRvIGEgdXNlciBJRCBjYW4gYmUgZG9uZSBpbiB0aGUgQUFB IA0KICAgIHNlcnZlciBieSB1c2luZyBkYXRhIGZyb20gdGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nl c3MuIERJQU1FVEVSIA0KICAgIGFjY291bnRpbmcgbWVzc2FnZXMgY2FuIGJlIHNlbnQgdG8gdGhl IGFjY291bnRpbmcgYXBwbGljYXRpb24gb3IgDQogICAgdG8gb3RoZXIgQUFBIHNlcnZlcnMgKGUu Zy4gaW4gcm9hbWluZyBzY2VuYXJpb3MpLiANCiAgDQogICAgICAgICAgICstLS0tLS0tLS0rICBE SUFNRVRFUiAgICArLS0tLS0tLS0tKyANCiAgICAgICAgICAgfCAgQUFBLVMgIHwtLS0tLS0tLS0t LS0tPnwgIEFBQS1TICB8IA0KICAgICAgICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0t LS0tLS0tLSsgDQogICAgICAgICAgICAgICAgXiANCiAgICAgICAgICAgICAgICB8IERJQU1FVEVS IA0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDE3XSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBw bGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgICAgICAgICAgICAg IHwgDQogICAgICAgICAgICAgICAgfCANCiAgICAgICAgICstLSstLS0tLS0tLSstLSsgDQogICAg ICAgICB8ICB8ICBBQUEtQyB8ICB8IA0KICAgICAgICAgKyAgKy0tLS0tLS0tKyAgfCANCiAgICAg ICAgIHwgICAgICAgICAgICAgIHwgDQogICAgICAgICB8ICBDb2xsZWN0b3IgICB8IA0KICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tKyAgIA0KICAgICAgICAgICAgICAgIF4gDQogICAgICAgICAgICAg ICAgfCBJUEZJWCANCiAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgICstLS0tLS0tLS0tLS0r IA0KICAgICAgICAgIHwgIEV4cG9ydGVyICB8IA0KICAgICAgICAgICstLS0tLS0tLS0tLS0rICAg IA0KICAgICANCiAgICBGaWd1cmUgMjogSVBGSVggY29sbGVjdG9yIGNvbm5lY3RzIHRvIEFBQSBz ZXJ2ZXIgdmlhIEFBQSBjbGllbnQgIA0KICAgICANCiAzLjQuMiBDb25uZWN0aW5nIHZpYSBhbiBB cHBsaWNhdGlvbiBTcGVjaWZpYyBNb2R1bGUgKEFTTSkgDQogICAgIA0KICAgIEFub3RoZXIgcG9z c2liaWxpdHkgaXMgdG8gZGlyZWN0bHkgY29ubmVjdCB0aGUgSVBGSVggY29sbGVjdG9yIA0KICAg IHdpdGggdGhlIEFBQSBzZXJ2ZXIgdmlhIGFuIGFwcGxpY2F0aW9uIHNwZWNpZmljIG1vZHVsZSAo QVNNKS4gDQogICAgQXBwbGljYXRpb24gc3BlY2lmaWMgbW9kdWxlcyBoYXZlIGJlZW4gcHJvcG9z ZWQgYnkgdGhlIElSVEYgQUFBIA0KICAgIGFyY2hpdGVjdHVyZSByZXNlYXJjaCBncm91cCAoQUFB UkNIKSBpbiBbUkZDMjkwM10uIFRoZXkgYWN0IGFzIA0KICAgIGFuIGludGVyZmFjZSBiZXR3ZWVu IEFBQSBzZXJ2ZXIgYW5kIHNlcnZpY2UgZXF1aXBtZW50LiBJbiB0aGlzIA0KICAgIGNhc2UgdGhl IElQRklYIGNvbGxlY3RvciBpcyBwYXJ0IG9mIHRoZSBBU00uIFRoZSBBU00gYWN0cyBhcyBhbiAN CiAgICBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgSVBGSVggcHJvdG9jb2wgYW5kIHRoZSBpbnB1dCBp bnRlcmZhY2Ugb2YgDQogICAgdGhlIEFBQSBzZXJ2ZXIuIFRoZSBBU00gdHJhbnNsYXRlcyB0aGUg cmVjZWl2ZWQgSVBGSVggZGF0YSBpbnRvIA0KICAgIGFuIGFwcHJvcHJpYXRlIGZvcm1hdCBmb3Ig dGhlIEFBQSBzZXJ2ZXIuIFRoZSBBQUEgc2VydmVyIHRoZW4gDQogICAgY2FuIGFkZCBpbmZvcm1h dGlvbiBhYm91dCB0aGUgdXNlciBJRCBhbmQgZ2VuZXJhdGUgYSBESUFNRVRFUiANCiAgICBhY2Nv dW50aW5nIHJlY29yZC4gVGhpcyBhY2NvdW50aW5nIHJlY29yZCBjYW4gYmUgc2VudCB0byBhbiAN CiAgICBhY2NvdW50aW5nIGFwcGxpY2F0aW9uIG9yIHRvIG90aGVyIEFBQSBzZXJ2ZXJzLiANCiAg ICAgDQogICAgICAgICAgICstLS0tLS0tLS0rICBESUFNRVRFUiAgICArLS0tLS0tLS0tKyANCiAg ICAgICAgICAgfCAgQUFBLVMgIHwtLS0tLS0tLS0tLS0tPnwgIEFBQS1TICB8IA0KICAgICAgICAg ICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tLSsgDQogICAgICAgICAgICAgICAg XiANCiAgICAgICAgICAgICAgICB8IA0KICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKyANCiAg ICAgICAgfCAgICAgQVNNICAgICAgICAgIHwgDQogICAgICAgIHwgICstLS0tLS0tLS0tLS0rICB8 IA0KICAgICAgICB8ICB8ICBDb2xsZWN0b3IgfCAgfCANCiAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLSsgDQogICAgICAgICAgICAgICAgXiANCiAgICAgICAgICAgICAgICB8IElQRklYIA0KICAg ICAgICAgICAgICAgIHwgDQogICAgICAgICAgKy0tLS0tLS0tLS0tLSsgDQogICAgICAgICAgfCAg RXhwb3J0ZXIgIHwgDQogICAgICAgICAgKy0tLS0tLS0tLS0tLSsgDQoNCg0KDQoNCiBac2VieSwg Qm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MThdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAgICAg ICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgIA0KICAgIEZpZ3VyZSAzOiBJUEZJWCBjb25uZWN0 cyB0byBBQUEgc2VydmVyIHZpYSBBU00gDQogIA0KICAzLjUgSVBGSVggYW5kIFJURk0gIA0KICAg DQogICAgVGhlIFJlYWwtdGltZSBUcmFmZmljIEZsb3cgTWVhc3VyZW1lbnQgKFJURk0pIHdvcmtp bmcgZ3JvdXAgDQogICAgZGVmaW5lZCBhbiBhcmNoaXRlY3R1cmUgZm9yIGZsb3cgbWVhc3VyZW1l bnQgW1JGQzI3MjJdLiBUaGlzIA0KICAgIHNlY3Rpb24gY29tcGFyZXMgdGhlIFJlYWwtdGltZSBU cmFmZmljIEZsb3cgTWVhc3VyZW1lbnQgKFJURk0pIA0KICAgIGZyYW1ld29yayB3aXRoIHRoZSBJ UEZJWCBmcmFtZXdvcmsuICANCiAgICAgICAgICANCiAzLjUuMSBBcmNoaXRlY3R1cmUgDQogIA0K ICAgIFRoZSBSVEZNIGFyY2hpdGVjdHVyZSBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIElQRklYIGFy Y2hpdGVjdHVyZS4gDQogICAgSXQgZGVmaW5lcyBtZXRlciwgbWV0ZXIgcmVhZGVyIGFuZCBhIG1h bmFnZXIgYXMgYnVpbGRpbmcgYmxvY2tzIA0KICAgIG9mIHRoZSBtZWFzdXJlbWVudCBhcmNoaXRl Y3R1cmUuIFRoZSBtYW5hZ2VyIGNvbmZpZ3VyZXMgdGhlIA0KICAgIG1ldGVyIGFuZCB0aGUgbWV0 ZXIgcmVhZGVyIGNvbGxlY3RzIGRhdGEgZnJvbSB0aGUgbWV0ZXIuICANCiAgICBJbiBSVEZNIHRo ZSBidWlsZGluZyBibG9ja3MgY29tbXVuaWNhdGUgdmlhIFNOTVAuICANCiAgICBUaGUgSVBGSVgg YXJjaGl0ZWN0dXJlIFtJUEZJWC1BUkNIXSBkZWZpbmVzIG1ldGVyaW5nLCBleHBvcnRpbmcgDQog ICAgYW5kIGNvbGxlY3RpbmcgcHJvY2Vzc2VzLiBJUEZJWCBzcGVha3MgYWJvdXQgcHJvY2Vzc2Vz IGluc3RlYWQgDQogICAgb2YgZGV2aWNlcyB0byBjbGFyaWZ5IHRoYXQgbXVsdGlwbGUgb2YgdGhv c2UgcHJvY2Vzc2VzIG1heSBiZSANCiAgICBjb2xsb2NhdGVkIG9uIHRoZSBzYW1lIG1hY2hpbmUu IA0KICAgIEJvdGggZGVmaW5pdGlvbnMgZG8gbm90IGNvbnRyYWRpY3QgZWFjaCBvdGhlci4gT25l IGNvdWxkIHNlZSB0aGUgDQogICAgbWV0ZXJpbmcgcHJvY2VzcyBhcyBwYXJ0IG9mIHRoZSBtZXRl ciBhbmQgdGhlIGNvbGxlY3RpbmcgcHJvY2VzcyANCiAgICBhcyBwYXJ0IG9mIHRoZSBtZXRlciBy ZWFkZXIuICAgDQogICAgT25lIGRpZmZlcmVuY2UgaXMgdGhhdCBJUEZJWCBjdXJyZW50bHkgZG9l cyBub3QgZGVmaW5lIGEgDQogICAgbWFuYWdpbmcgcHJvY2VzcywgYmVjYXVzZSByZW1vdGUgY29u ZmlndXJhdGlvbiB3YXMgYXQgbGVhc3QgDQogICAgaW5pdGlhbGx5IG91dCBvZiBzY29wZSBmb3Ig dGhlIHdvcmtpbmcgZ3JvdXAuIA0KICAgICANCiAzLjUuMiBGbG93IERlZmluaXRpb24gDQogICAN CiAgICBSVEZNIGFuZCBJUEZJWCBib3RoIGNvbnNpZGVyIGZsb3dzIGFzIGEgZ3JvdXAgb2YgcGFj a2V0cyB3aGljaCANCiAgICBzaGFyZSBhIGNvbW1vbiBzZXQgb2YgcHJvcGVydGllcy4gQSBmbG93 IGlzIGNvbXBsZXRlbHkgc3BlY2lmaWVkIA0KICAgIGJ5IHRoYXQgc2V0IG9mIHZhbHVlcywgdG9n ZXRoZXIgd2l0aCBhIHRlcm1pbmF0aW9uIGNyaXRlcmlvbiANCiAgICAobGlrZSBpbmFjdGl2aXR5 IHRpbWVvdXQpLiANCiAgICAgDQogICAgQSBkaWZmZXJlbmNlIGlzIHRoYXQgUlRGTSBkZWZpbmVz IGZsb3dzIGFzIGJpZGlyZWN0aW9uYWwuIEFuIA0KICAgIFJURk0gbWV0ZXIgbWF0Y2hlcyBwYWNr ZXRzIGZyb20gQiB0byBBIGFuZCBBIHRvIEIgYXMgc2VwYXJhdGUgDQogICAgcGFydHMgb2YgYSBz aW5nbGUgZmxvdywgYW5kIG1haW50YWlucyB0d28gc2V0cyBvZiBwYWNrZXQgYW5kIA0KICAgIGJ5 dGUgY291bnRlcnMsIG9uZSBmb3IgZWFjaCBkaXJlY3Rpb24uICANCiAgDQogICAgSVBGSVggZG9l cyBub3QgZXhwbGljaXRseSBzdGF0ZSB3aGV0aGVyIGZsb3dzIGFyZSB1bmktIG9yIA0KICAgIGJp ZGlyZWN0aW9uYWwuIE5ldmVydGhlbGVzcyBpbmZvcm1hdGlvbiBlbGVtZW50cyBmb3IgZGVzY3Jp YmluZyANCiAgICBmbG93IHByb3BlcnRpZXMgd2VyZSBkZWZpbmVkIG9ubHkgZm9yIG9uZSBkaXJl Y3Rpb24gaW4gW0lQRklYLQ0KICAgIElORk9dLiBOZXZlcnRoZWxlc3MsIHRoZXJlIGFyZSBzZXZl cmFsIHNvbHV0aW9ucyBmb3IgcmVwb3J0aW5nIA0KICAgIGJpLWRpcmVjdGlvbmFsIGZsb3cgaW5m b3JtYXRpb24gKHNlZSBzZWN0aW9uIDQuNSkuIA0KICANCg0KDQoNCg0KDQogWnNlYnksIEJvc2No aSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE5XSAN CgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAg SnVuZSAyMDA2IA0KDQoNCg0KIDMuNS4zIENvbmZpZ3VyYXRpb24gYW5kIE1hbmFnZW1lbnQgIA0K ICAgICANCiAgICBJbiBSVEZNLCByZW1vdGUgY29uZmlndXJhdGlvbiBpcyB0aGUgb25seSB3YXkg dG8gY29uZmlndXJlIGEgDQogICAgbWV0ZXIuIFRoaXMgaXMgZG9uZSBieSB1c2luZyBTTk1QIGFu ZCBhIHNwZWNpZmljIE1ldGVyIE1JQiBbUkZDDQogICAgMjcyMF0uIFRoZSBJUEZJWCBncm91cCBj dXJyZW50bHkgZG9lcyBub3QgYWRkcmVzcyBJUEZJWCByZW1vdGUgDQogICAgY29uZmlndXJhdGlv bi4gDQogICAgIA0KICAgIElQRklYIG1ldGVyaW5nIHByb2Nlc3NlcyBleHBvcnQgdGhlIGxheW91 dCBvZiBkYXRhIHdpdGhpbiB0aGVpciANCiAgICB0ZW1wbGF0ZXMsIGZyb20gdGltZSB0byB0aW1l LiBJUEZJWCBjb2xsZWN0aW5nIHByb2Nlc3NlcyB1c2UgDQogICAgdGhhdCB0ZW1wbGF0ZSBpbmZv cm1hdGlvbiB0byBkZXRlcm1pbmUgaG93IHRoZXkgc2hvdWxkIGludGVycHJldCANCiAgICB0aGUg SVBGSVggZmxvdyBkYXRhIHRoZXkgcmVjZWl2ZS4gDQogICAgIA0KIDMuNS40IERhdGEgQ29sbGVj dGlvbiANCiAgICAgDQogICAgT25lIG1ham9yIGRpZmZlcmVuY2UgYmV0d2VlbiBJUEZJWCBhbmQg UlRGTSBpcyB0aGUgZGF0YSANCiAgICBjb2xsZWN0aW9uIG1vZGVsLiBSVEZNIHJldHJpZXZlcyBk YXRhIGluIHB1bGwgbW9kZSB3aGVyZWFzIElQRklYIA0KICAgIHVzZXMgYSBwdXNoIG1vZGUgbW9k ZWwgdG8gc2VuZCBkYXRhIHRvIGNvbGxlY3RpbmcgcHJvY2Vzc2VzLiAgDQogICAgIA0KICAgIEFu IFJURk0gbWV0ZXIgcmVhZGVyIHB1bGxzIGRhdGEgZnJvbSBhIG1ldGVyIGJ5IHVzaW5nIFNOTVAu IFNOTVAgDQogICAgc2VjdXJpdHkgb24gdGhlIG1ldGVyIGRldGVybWluZXMgd2hldGhlciBhIHJl YWRlciBpcyBhbGxvd2VkIHRvIA0KICAgIHB1bGwgZGF0YSBmcm9tIGl0LiBBbiBJUEZJWCBleHBv cnRpbmcgcHJvY2VzcyBpcyBjb25maWd1cmVkIHRvIA0KICAgIGV4cG9ydCByZWNvcmRzIHRvIGEg c3BlY2lmaWVkIGxpc3Qgb2YgSVBGSVggY29sbGVjdGluZyANCiAgICBwcm9jZXNzZXMuIFRoZSBj b25kaXRpb24gd2hlbiB0byBzZW5kIElQRklYIHJlY29yZHMgKGUuZy4gZmxvdyANCiAgICB0ZXJt aW5hdGlvbikgaGFzIHRvIGJlIGNvbmZpZ3VyZWQgaW4gdGhlIGV4cG9ydGluZyBvciBtZXRlcmlu ZyANCiAgICBwcm9jZXNzLiANCiAgDQogMy41LjUgRGF0YSBNb2RlbCBEZXRhaWxzICANCiAgDQog ICAgUlRGTSBkZWZpbmVzIGFsbCBpdHMgYXR0cmlidXRlcyBpbiB0aGUgUlRGTSBNZXRlciBNSUIg W1JGQw0KICAgIDI3MjBdLiBJUEZJWCBpbmZvcm1hdGlvbiBlbGVtZW50cyBhcmUgZGVmaW5lZCBp biBbSVBGSVgtSU5GT10uIA0KICAgICANCiAgICBSVEZNIHVzZXMgY29udGludW91c2x5LWluY3Jl bWVudGluZyA2NC1iaXQgY291bnRlcnMgZm9yIHRoZSANCiAgICBzdG9yYWdlIG9mIHRoZSBudW1i ZXIgb2YgcGFja2V0cyBvZiBhIGZsb3cuIFRoZSBjb3VudGVycyBhcmUgDQogICAgbmV2ZXIgcmVz ZXQgYW5kIGp1c3Qgd3JhcCBiYWNrIHRvIHplcm8gaWYgdGhlIG1heGltdW0gdmFsdWUgaXMgDQog ICAgZXhjZWVkZWQuIEZsb3dzIGNhbiBiZSByZWFkIGF0IGFueSB0aW1lLiBUaGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIA0KICAgIGNvdW50ZXIgcmVhZGluZ3MgZ2l2ZXMgdGhlIGNvdW50cyBmb3IgYWN0 aXZpdHkgaW4gdGhlIGludGVydmFsIA0KICAgIGJldHdlZW4gcmVhZGluZ3MuIA0KICAgIElQRklY IGFsbG93cyBhYnNvbHV0ZSAodG90YWxDb3VudGVyKSBhbmQgcmVsYXRpdmUgY291bnRlcnMgDQog ICAgKGRlbHRhQ291bnRlcikgW0lQRklYLUlORk9dLiBUaGUgdG90YWxDb3VudGVyIGlzIG5ldmVy IHJlc2V0IGFuZCANCiAgICBqdXN0IHdyYXBzIHRvIHplcm8gaWYgdmFsdWVzIGFyZSB0b28gbGFy Z2UsIGV4YWN0bHkgYXMgdGhlIA0KICAgIGNvdW50ZXJzIHVzZWQgaW4gUlRGTS4gVGhlIGRlbHRh Q291bnRlciBpcyByZXNldCB0byB6ZXJvIHdoZW4gDQogICAgdGhlIGFzc29jaWF0ZWQgZmxvdyBy ZWNvcmQgaXMgZXhwb3J0ZWQuIA0KICANCiAzLjUuNiBUcmFuc3BvcnQgUHJvdG9jb2wgIA0KICAg ICAgICAgIA0KICAgIFJURk0gaGFzIGEgc3RhbmRhcmRzLXRyYWNrIE1ldGVyIE1JQiBbUkZDMjcy MF0sIHdoaWNoIGlzIHVzZWQgDQogICAgYm90aCB0byBjb25maWd1cmUgYSBtZXRlciBhbmQgdG8g c3RvcmUgbWV0ZXJpbmcgcmVzdWx0cy4gIFRoZSANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJy b3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyMF0gDQoMICAg ICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUg MjAwNiANCg0KDQoNCiAgICBNSUIgcHJvdmlkZXMgYSB3YXkgdG8gcmVhZCBsaXN0cyBvZiBhdHRy aWJ1dGVzIHdpdGggYSBzaW5nbGUgDQogICAgT2JqZWN0IElkZW50aWZpZXIgKGNhbGxlZCBhICdw YWNrYWdlJyksIHdoaWNoIHJlZHVjZXMgdGhlIFNOTVAgDQogICAgb3ZlcmhlYWQgZm9yIGZsb3cg ZGF0YSBjb2xsZWN0aW9uLiBTTk1QLCBvZiBjb3Vyc2UsIG5vcm1hbGx5IA0KICAgIHVzZXMgVURQ IGFzIGl0cyB0cmFuc3BvcnQgcHJvdG9jb2wuIFNpbmNlIFJURk0gcmVxdWlyZXMgYSANCiAgICBy ZWxpYWJsZSBmbG93IGRhdGEgdHJhbnNwb3J0IHN5c3RlbSwgYW4gUlRGTSBtZXRlciByZWFkZXIg bXVzdCANCiAgICB0aW1lIG91dCBhbmQgcmVzZW5kIHVuYW5zd2VyZWQgU05NUCByZXF1ZXN0cy4g QXBhcnQgZnJvbSBiZWluZyANCiAgICBjbHVtc3ksIHRoaXMgY2FuIGxpbWl0IHRoZSBtYXhpbXVt IGRhdGEgdHJhbnNmZXIgcmF0ZSBmcm9tIG1ldGVyIA0KICAgIHRvIG1ldGVyIHJlYWRlci4gDQog ICAgIA0KICAgIElQRklYIGlzIGRlc2lnbmVkIHRvIHdvcmsgb3ZlciBhIHZhcmlldHkgb2YgZGlm ZmVyZW50IHRyYW5zcG9ydCANCiAgICBwcm90b2NvbHMuICBTQ1RQIFtSRkMyOTYwXSBhbmQgU0NU UC1QUiBbUkZDMzc1OF0gYXJlIG1hbmRhdG9yeS4gIA0KICAgIFVEUCBhbmQgVENQIGFyZSBvcHRp b25hbC4gIEluIGFkZGl0aW9uLCB0aGUgSVBGSVggcHJvdG9jb2wgDQogICAgZW5jb2RlcyBkYXRh IG11Y2ggbW9yZSBlZmZpY2llbnRseSB0aGFuIFNOTVAgZG9lcywgaGVuY2UgSVBGSVggDQogICAg aGFzIGxvd2VyIGRhdGEgdHJhbnNwb3J0IG92ZXJoZWFkcyB0aGFuIFJURk0uIA0KICANCiAzLjUu NyBTdW1tYXJ5IA0KICAgICANCiAgICBJUEZJWCBleHBvcnRzIGZsb3cgaW5mb3JtYXRpb24gaW4g cHVzaCBtb2RlbCBieSB1c2luZyBTQ1RQLCBUQ1AgDQogICAgb3IgVURQLiBJdCBjdXJyZW50bHkg ZG9lcyBub3QgYWRkcmVzcyByZW1vdGUgY29uZmlndXJhdGlvbi4gUlRGTSANCiAgICBkYXRhIGNv bGxlY3Rpb24gaXMgdXNpbmcgdGhlIHB1bGwgbW9kZWwgYW5kIHJ1bnMgb3ZlciBTTk1QLiBSVEZN IA0KICAgIGFkZHJlc3NlcyByZW1vdGUgY29uZmlndXJhdGlvbiB3aGljaCBhbHNvIHJ1bnMgb3Zl ciBTTk1QLiBCb3RoIA0KICAgIGZyYW1ld29ya3MgYWxsb3cgYSB2ZXJ5IGZsZXhpYmxlIGZsb3cg ZGVmaW5pdGlvbiwgYWx0aG91Z2ggUlRGTSANCiAgICBpcyBiYXNlZCBvbiBhIGJpLWRpcmVjdGlv bmFsIGZsb3cgZGVmaW5pdGlvbi4gDQogICAgIA0KIDQuIExpbWl0YXRpb25zIA0KICAgICANCiAg ICBUaGUgZ29hbCBvZiB0aGlzIHNlY3Rpb24gaXMgdG8gc2hvdyB0aGUgbGltaXRhdGlvbnMgb2Yg SVBGSVggYW5kIA0KICAgIHRvIGdpdmUgYWR2aWNlIHdoZXJlIG5vdCB0byB1c2UgSVBGSVggb3Ig aW4gd2hpY2ggY2FzZXMgDQogICAgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBhcmUgcmVxdWly ZWQuICANCiAgICAgDQogIDQuMSBVc2luZyBJUEZJWCBmb3Igb3RoZXIgQXBwbGljYXRpb25zIHRo YW4gaW4gUkZDMzkxNyANCiAgICAgDQogICAgSVBGSVggcHJvdmlkZXMgYSBnZW5lcmljIGV4cG9y dCBtZWNoYW5pc20uIER1ZSB0byBpdHMgdGVtcGxhdGUgDQogICAgYmFzZWQgc3RydWN0dXJlLCBp dCBpcyBhIHF1aXRlIGZsZXhpYmxlIHByb3RvY29sLiBOZXR3b3JrIA0KICAgIG9wZXJhdG9ycyBh bmQgdXNlcnMgbWF5IHdhbnQgdG8gdXNlIGl0IGFsc28gZm9yIG90aGVyIA0KICAgIGFwcGxpY2F0 aW9ucyB0aGFuIHRob3NlIGRlc2NyaWJlZCBpbiBbUkZDMzkxN10uIA0KICAgICANCiAgICBBcGFy dCBmcm9tIHNlbmRpbmcgcmF3IGZsb3cgaW5mb3JtYXRpb24gaXQgY2FuIGJlIHVzZWQgdG8gc2Vu ZCANCiAgICBhZ2dyZWdhdGVkIG9yIHBvc3QtcHJvY2Vzc2VkIGRhdGEuIEZvciB0aGlzIG5ldyB0 ZW1wbGF0ZXMgYW5kIA0KICAgIGluZm9ybWF0aW9uIGVsZW1lbnRzIGNhbiBiZSBkZWZpbmVkIGlm IG5lZWRlZC4gRHVlIHRvIGl0cyBwdXNoIA0KICAgIG1vZGUgb3BlcmF0aW9uIElQRklYIGlzIGFs c28gc3VpdGVkIHRvIHNlbmQgbmV0d29yayBpbml0aWF0ZWQgDQogICAgZXZlbnRzIGxpa2UgYWxh cm1zIGFuZCBvdGhlciBub3RpZmljYXRpb25zLiBJdCBjYW4gYmUgdXNlZCBmb3IgDQogICAgZXhj aGFuZ2luZyBpbmZvcm1hdGlvbiBhbW9uZyBuZXR3b3JrIG5vZGVzIHRvIGF1dG9ub21vdXNseSAN CiAgICBpbXByb3ZlIG5ldHdvcmsgb3BlcmF0aW9uLiAgIA0KICANCiAgICBOZXZlcnRoZWxlc3Ms IHRoZSBJUEZJWCBkZXNpZ24gaXMgYmFzZWQgb24gdGhlIHJlcXVpcmVtZW50cyB0aGF0IA0KICAg IG9yaWdpbmF0ZSBvbmx5IGZyb20gdGhlIHRhcmdldCBhcHBsaWNhdGlvbnMgc3RhdGVkIGluIFtS RkMNCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAg ICAgICAgICAgICAgICBbUGFnZSAyMV0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFw cGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICAzOTE3XS4gVXNp bmcgSVBGSVggZm9yIG90aGVyIHB1cnBvc2VzIHJlcXVpcmVzIGEgY2FyZWZ1bCANCiAgICBjaGVj a2luZyBvZiBJUEZJWCBjYXBhYmlsaXRpZXMgYWdhaW5zdCBhcHBsaWNhdGlvbiByZXF1aXJlbWVu dHMuIA0KICAgIE9ubHkgd2l0aCB0aGlzLCBjYW4gb25lIGRlY2lkZSB3aGV0aGVyIElQRklYIGlz IGEgc3VpdGFibGUgDQogICAgcHJvdG9jb2wgdG8gbWVldCB0aGUgbmVlZHMgb2YgYSBzcGVjaWZp YyBhcHBsaWNhdGlvbi4gDQogICAgIA0KICA0LjIgVXNpbmcgYSBEaWZmZXJlbnQgVHJhbnNwb3J0 IFByb3RvY29sIHRoYW4gU0NUUCANCiAgICAgDQogICAgU0NUUCBpcyB0aGUgcHJlZmVycmVkIHBy b3RvY29sIGZvciBJUEZJWCwgaS5lLiBhIGNvbmZvcm1pbmcgDQogICAgaW1wbGVtZW50YXRpb24g bXVzdCB3b3JrIG92ZXIgU0NUUC4gQWx0aG91Z2ggSVBGSVggY2FuIGFsc28gd29yayANCiAgICBv dmVyIFRDUCBvciBVRFAsIGJvdGggcHJvdG9jb2xzIGhhdmUgZHJhd2JhY2tzIFtJUEZJWC1QUk9U T10uIA0KICAgIFVzZXJzIHNob3VsZCBtYWtlIHN1cmUgdGhleSBoYXZlIGdvb2QgcmVhc29ucyBi ZWZvciB1c2luZyANCiAgICBwcm90b2NvbHMgb3RoZXIgdGhhbiBTQ1RQIGluIGEgc3BlY2lmaWMg ZW52aXJvbm1lbnQuIA0KICAgICANCiAgNC4zIFB1c2ggdnMuIFB1bGwgTW9kZSANCiAgICAgDQog ICAgSVBGSVggd29ya3MgaW4gcHVzaCBtb2RlLiBUaGF0IG1lYW5zIElQRklYIHJlY29yZHMgYXJl IA0KICAgIGF1dG9tYXRpY2FsbHkgZXhwb3J0ZWQgd2l0aG91dCB3YWl0aW5nIGZvciBhIHJlcXVl c3QuICANCiAgICBUaGUgcmVzcG9uc2liaWxpdHkgZm9yIGluaXRpYXRpbmcgYSBkYXRhIGV4cG9y dCBsaWVzIHdpdGggdGhlIA0KICAgIGV4cG9ydGluZyBwcm9jZXNzLiAgDQogICAgIA0KICAgIENy aXRlcmlhIGZvciBleHBvcnRpbmcgZGF0YSBuZWVkIHRvIGJlIGNvbmZpZ3VyZWQgYXQgdGhlIA0K ICAgIGV4cG9ydGluZyBwcm9jZXNzLiBUaGVyZWZvcmUgcHVzaCBtb2RlIGhhcyBtb3JlIGJlbmVm aXRzIGlmIHRoZSANCiAgICB0cmlnZ2VyIGZvciBkYXRhIGV4cG9ydCBpcyByZWxhdGVkIHRvIGV2 ZW50cyBhdCB0aGUgZXhwb3J0aW5nIA0KICAgIHByb2Nlc3MgKGUuZy4gZmxvdyB0ZXJtaW5hdGlv biwgbWVtb3J5IHNob3J0YWdlIGR1ZSB0byBsYXJnZSANCiAgICBhbW91bnQgb2YgZmxvd3MsIGV0 Yy4pLiBJZiB0aGUgcHJvdG9jb2wgdXNlZCBwdWxsIG1vZGUsIHRoZSANCiAgICBleHBvcnRpbmcg cHJvY2VzcyB3b3VsZCBuZWVkIHRvIHdhaXQgZm9yIGEgcmVxdWVzdCB0byBzZW5kIHRoZSANCiAg ICBkYXRhLiBXaXRoIHB1c2ggbW9kZSBpdCBjYW4gc2VuZCBkYXRhIGltbWVkaWF0ZWx5IGUuZy4g YmVmb3JlIA0KICAgIG1lbW9yeSBzaG9ydGFnZSB3b3VsZCByZXF1aXJlIGEgZGlzY2FyZGluZyBv ZiBkYXRhLiANCiAgICAgDQogICAgV2l0aCBwdXNoIG1vZGUgb25lIGNhbiBwcmV2ZW50IHRoZSBv dmVybG9hZGluZyBvZiByZXNvdXJjZXMgYXQgDQogICAgdGhlIGV4cG9ydGluZyBwcm9jZXNzIGJ5 IHNpbXBseSBleHBvcnRpbmcgdGhlIGluZm9ybWF0aW9uIGFzIA0KICAgIHNvb24gYXMgY2VydGFp biB0aHJlc2hvbGRzIGFyZSBhYm91dCB0byBleGNlZWQuIFRoZXJlZm9yZSANCiAgICBleHBvcnRp bmcgY3JpdGVyaWEgYXJlIG9mdGVuIHJlbGF0ZWQgdG8gdHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3Mg DQogICAgKGUuZy4gZmxvdyB0aW1lb3V0KSBvciByZXNvdXJjZSBsaW1pdGF0aW9ucyAoZS5nLiBz aXplIG9mIGZsb3cgDQogICAgY2FjaGUpLiBCdXQgdHJhZmZpYyBjaGFyYWN0ZXJpc3RpY3MgYXJl IHVzdWFsbHkgcXVpdGUgZHluYW1pYyANCiAgICBhbmQgb2Z0ZW4gaW1wb3NzaWJsZSB0byBwcmVk aWN0LiBJZiB0aG9zZSBhcmUgdXNlZCB0byB0cmlnZ2VyIA0KICAgIGZsb3cgZXhwb3J0LCB0aGUg ZXhwb3J0aW5nIHJhdGUgYW5kIHRoZSByZXNvdXJjZSBjb25zdW1wdGlvbiBmb3IgDQogICAgZmxv dyBleHBvcnQgYmVjb21lcyB2YXJpYWJsZSBhbmQgdW5wcmVkaWN0YWJsZS4gIA0KICAgICANCiAg ICBQdWxsIG1vZGUgaGFzIGFkdmFudGFnZXMgaWYgdGhlIHRyaWdnZXIgZm9yIGRhdGEgZXhwb3J0 IGlzIA0KICAgIHJlbGF0ZWQgdG8gZXZlbnRzIGF0IHRoZSBjb2xsZWN0aW5nIHByb2Nlc3MgKGUu Zy4gYSBzcGVjaWZpYyANCiAgICBhcHBsaWNhdGlvbiByZXF1ZXN0cyBpbW1lZGlhdGUgaW5wdXQp LiAgDQogICAgIA0KICAgIEluIGEgcHVsbCBtb2RlLCBhIHJlcXVlc3QgY291bGQgc2ltcGx5IGJl IGZvcndhcmRlZCB0byB0aGUgDQogICAgZXhwb3J0aW5nIHByb2Nlc3MuIEluIGEgcHVzaCBtb2Rl LCB0aGUgZXhwb3J0aW5nIGNvbmZpZ3VyYXRpb24gDQogICAgbXVzdCBiZSBjaGFuZ2VkIHRvIHRy aWdnZXIgdGhlIGV4cG9ydCBvZiB0aGUgcmVxdWVzdGVkIGRhdGEuIA0KICAgIEZ1cnRoZXJtb3Jl LCB3aXRoIHB1bGwgbW9kZSBvbmUgY2FuIHByZXZlbnQgdGhlIG92ZXJsb2FkaW5nIG9mIA0KDQoN Cg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMjJdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNh YmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgdGhlIGNvbGxlY3Rpbmcg cHJvY2VzcyBieSB0aGUgYXJyaXZhbCBvZiBtb3JlIHJlY29yZHMgdGhhbiBpdCANCiAgICBjYW4g cHJvY2Vzcy4gDQogICAgIA0KICAgIFdoZXRoZXIgdGhpcyBpcyBhIHJlbGV2YW50IGRyYXdiYWNr IGRlcGVuZHMgb24gdGhlIGZsZXhpYmlsaXR5IA0KICAgIG9mIHRoZSBJUEZJWCBjb25maWd1cmF0 aW9uIGFuZCBob3cgSVBGSVggY29uZmlndXJhdGlvbiBydWxlcyBhcmUgDQogICAgaW1wbGVtZW50 ZWQuICAgDQogICAgIA0KICANCiAgNC40IFRlbXBsYXRlIElEIG51bWJlciANCiAgICAgDQogICAg VGhlIElQRklYIHNwZWNpZmljYXRpb24gbGltaXRzIHRoZSBkaWZmZXJlbnQgdGVtcGxhdGUgSUQg bnVtYmVycyANCiAgICB0aGF0IGNhbiBiZSBhc3NpZ25lZCB0byB0aGUgbmV3bHkgZ2VuZXJhdGVk IHRlbXBsYXRlIHJlY29yZHMgaW4gDQogICAgYW4gb2JzZXJ2YXRpb24gZG9tYWluLiBJbiBwYXJ0 aWN1bGFyLCB0ZW1wbGF0ZSBJRHMgdXAgdG8gMjU1IGFyZSANCiAgICByZXNlcnZlZCBmb3IgVGVt cGxhdGUgb3Igb3B0aW9uIHNldHMgKG9yIG90aGVyIHNldHMgdG8gYmUgDQogICAgY3JlYXRlZCkg YW5kIHRlbXBsYXRlIElEcyBmcm9tIDI1NiB0byA2NTUzNSBhcmUgYXNzaWduZWQgdG8gZGF0YSAN CiAgICBzZXRzLiBJbiB0aGUgY2FzZSBvZiBtYW55IGV4cG9ydHMgcmVxdWlyaW5nIG1hbnkgZGlm ZmVyZW50IA0KICAgIHRlbXBsYXRlcywgdGhlIHNldCBvZiBUZW1wbGF0ZSBJRHMgY291bGQgYmUg ZXhoYXVzdGVkLiAgIA0KICANCiAgNC41IEV4cG9ydGluZyBCaWRpcmVjdGlvbmFsIEZsb3cgSW5m b3JtYXRpb24gDQogICAgIA0KICAgIEFsdGhvdWdoIElQRklYIGRvZXMgbm90IGV4cGxpY2l0bHkg c3RhdGUgdGhhdCBmbG93cyBhcmUgDQogICAgdW5pZGlyZWN0aW9uYWwsIGluZm9ybWF0aW9uIGVs ZW1lbnRzIHRoYXQgZGVzY3JpYmUgZmxvdyANCiAgICBjaGFyYWN0ZXJpc3RpY3MgYXJlIGRlZmlu ZWQgb25seSBmb3Igb25lIGRpcmVjdGlvbiBpbiBbSVBGSVgtDQogICAgSU5GT10uIFtJUEZJWC1Q Uk9UT10gYWxsb3dzIHRoZSByZXBvcnRpbmcgb2YgbXVsdGlwbGUgaWRlbnRpY2FsIA0KICAgIGlu Zm9ybWF0aW9uIGVsZW1lbnRzIGluIG9uZSBmbG93IHJlY29yZC4gV2l0aCB0aGlzIGluZm9ybWF0 aW9uIA0KICAgIGVsZW1lbnRzIGZvciBmb3J3YXJkIGFuZCByZXZlcnNlIGRpcmVjdGlvbiBjYW4g YmUgcmVwb3J0ZWQgaW4gDQogICAgb25lIGZsb3cgcmVjb3JkLiAgDQogICAgIA0KICAgIEJ1dCB0 aGlzIGlzIG5vdCBzdWZmaWNpZW50LiBVc2luZyB0aGlzIGZlYXR1cmUgZm9yIHJlcG9ydGluZyAN CiAgICBiaWRpcmVjdGlvbmFsIGZsb3cgaW5mb3JtYXRpb24gd291bGQgcmVxdWlyZSBhbiBhZ3Jl ZW1lbnQgb24gdGhlIA0KICAgIHNlbWFudGljIG9mIGluZm9ybWF0aW9uIGVsZW1lbnRzIChlLmcu IGZpcnN0IGNvdW50ZXIgaXMgY291bnRlciANCiAgICBmb3IgdGhlIGZvcndhcmQgZGlyZWN0aW9u LCBzZWNvbmQgY291bnRlciBmb3IgcmV2ZXJzZSANCiAgICBkaXJlY3Rpb24pLiAgDQogICAgIA0K ICAgIEFub3RoZXIgb3B0aW9uIGlzIHRvIHVzZSB0d28gYWRqYWNlbnQgZmxvdyByZWNvcmRzIHRv IHJlcG9ydCANCiAgICBib3RoIGRpcmVjdGlvbnMgb2YgYSBiaWRpcmVjdGlvbmFsIGZsb3cgc2Vw YXJhdGVseS4gVGhpcyANCiAgICBhcHByb2FjaCByZXF1aXJlcyBhZGRpdGlvbmFsIG1lYW5zIGZv ciBtYXBwaW5nIHRob3NlIHJlY29yZHMgYW5kIA0KICAgIGlzIHF1aXRlIGluZWZmaWNpZW50IGR1 ZSB0byB0aGUgcmVkdW5kYW50IHJlcG9ydGluZyBvZiBmbG93IA0KICAgIGtleXMuIA0KICAgICAN CiAgNC42IElQRklYIGFuZCBJUHY2IA0KICAgICANCiAgICBUaGVyZSBhcmUgdHdvIGlzc3VlcyB0 byBjb25zaWRlcjogIA0KICAgICANCiAgICAtIEdlbmVyYXRpb24gYW5kIHJlcG9ydGluZyBvZiBJ UEZJWCByZWNvcmRzIGFib3V0IElQdjYgdHJhZmZpYyANCiAgICAtIEV4cG9ydGluZyBJUEZJWCBy ZWNvcmRzIG92ZXIgSVB2NiANCiAgICAgDQoNCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3du bGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyM10gDQoMICAgICAg ICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAw NiANCg0KDQoNCiAgICBUaGUgZ2VuZXJhdGlvbiBhbmQgcmVwb3J0aW5nIG9mIElQRklYIHJlY29y ZHMgYWJvdXQgSVB2NiB0cmFmZmljIA0KICAgIGlzIHBvc3NpYmxlIGFzIGFwcHJvcHJpYXRlIGlu Zm9ybWF0aW9uIGVsZW1lbnRzIGV4aXN0IGluIFtJUEZJWC0NCiAgICBJTkZPXS4gIA0KICAgIEV4 cG9ydGluZyBJUEZJWCByZWNvcmRzIG92ZXIgSVB2NiBpcyBub3QgZXhwbGljaXRseSBhZGRyZXNz ZWQgaW4gDQogICAgW0lQRklYLVBST1RPXS4gU2luY2UgSVBGSVggcnVucyBvdmVyIFNDVFAsIFND VFAtUFIsIFVEUCBvciBUQ1AsIA0KICAgIGl0IGlzIHRyaXZpYWwgdG8gcnVuIElQRklYIG92ZXIg SVB2NiBuZXR3b3JrcywgcHJvdmlkZWQgdGhhdCB0aGUgDQogICAgdHJhbnNwb3J0IHByb3RvY29s IGJlaW5nIHVzZWQgdG8gY2FycnkgSVBGSVggaXMgcnVubmluZyBvbiB0aGUgDQogICAgSVB2NiBu ZXR3b3JrLiANCiAgDQogNS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogICAgIA0KICAgIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1c2FnZSBvZiBJUEZJWCBpbiB2YXJpb3VzIHNjZW5h cmlvcy4gDQogICAgU2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciBJUEZJWCB0YXJnZXQgYXBwbGlj YXRpb25zIGFuZCBzZWN1cml0eSANCiAgICBjb25zaWRlcmF0aW9ucyBmb3IgSVBGSVggYXJlIGFk ZHJlc3NlZCBpbiBbUkZDMzkxN10gYW5kIFtJUEZJWC0NCiAgICBQUk9UT10uIFRob3NlIHJlcXVp cmVtZW50cyBoYXZlIHRvIGJlIG1ldCBmb3IgdGhlIHVzYWdlIG9mIA0KICAgIElQRklYLiBUbyBv dXIgY3VycmVudCBrbm93bGVkZ2UsIHRoZSB1c2FnZSBzY2VuYXJpb3MgcHJvcG9zZWQgaW4gDQog ICAgc2VjdGlvbiAyIGRvIG5vdCBpbmR1Y2UgZnVydGhlciBzZWN1cml0eSBoYXphcmRzLiANCiAg ICAgDQogICAgU2VjdGlvbiAzIG9mIHRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyBJUEZJWCBj YW4gYmUgdXNlZCBpbiANCiAgICBjb21iaW5hdGlvbiB3aXRoIG90aGVyIGZyYW1ld29ya3MuIE5l dyBzZWN1cml0eSBoYXphcmRzIGNhbiANCiAgICBhcmlzZSB3aGVuIHR3byBpbmRpdmlkdWFsbHkg c2VjdXJlIGZyYW1ld29ya3MgYXJlIGNvbWJpbmVkLiBGb3IgDQogICAgdGhlIGNvbWJpbmF0aW9u IG9mIEFBQSB3aXRoIElQRklYIGFuIGFwcGxpY2F0aW9uIHNwZWNpZmljIG1vZHVsZSAgDQogICAg KEFTTSkgb3IgYW4gSVBGSVggY29sbGVjdG9yIGNhbiBmdW5jdGlvbiBhcyB0cmFuc2l0IHBvaW50 IGZvciANCiAgICB0aGUgbWVzc2FnZXMuIEl0IGhhcyB0byBiZSBlbnN1cmVkIHRoYXQgYXQgdGhp cyBwb2ludCB0aGUgDQogICAgYXBwbGllZCBzZWN1cml0eSBtZWNoYW5pc21zIChlLmcuIGVuY3J5 cHRpb24gb2YgbWVzc2FnZXMpIGFyZSANCiAgICBtYWludGFpbmVkLiANCg0KIDYuIElBTkEgQ29u c2lkZXJhdGlvbnMgDQogICAgIA0KICAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIGFjdGlvbnMgZm9y IElBTkEuIA0KICAgICANCiA3LiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgDQogICAgIA0KICAgIFtJ UEZJWC1JTkZPXSBKLiBRdWl0dGVrLCBTLiBCcnlhbnQsIEouIE1leWVyLCAiSW5mb3JtYXRpb24g TW9kZWwgDQogICAgICAgICAgICAgICAgICBmb3IgSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQi LCBJbnRlcm5ldCBEcmFmdCANCiAgICAgICAgICAgICAgICAgIDxkcmFmdC1pZXRmLWlwZml4LWlu Zm8tMDc+LCB3b3JrIGluIHByb2dyZXNzLCBNYXkgDQogICAgICAgICAgICAgICAgICAyMDA1IA0K ICAgICANCiAgICBbSVBGSVgtUFJPVE9dIEIuIENsYWlzZSAoRWRpdG9yKSwgIklQRklYIFByb3Rv Y29sIFNwZWNpZmljYXRpb24iLCANCiAgICAgICAgICAgICAgICAgIEludGVybmV0IERyYWZ0IDxk cmFmdC1pZXRmLWlwZml4LXByb3RvY29sLTIxLnR4dD4sIA0KICAgICAgICAgICAgICAgICAgd29y ayBpbiBwcm9ncmVzcywgQXByaWwgMjAwNiAgDQogICAgIA0KICAgIFtQU0FNUC1JTkZPXSBULiBE aWV0eiwgRi4gRHJlc3NsZXIsIEcuIENhcmxlLCBCLiBDbGFpc2UsIA0KICAgICAgICAgICAgICAg ICAgIkluZm9ybWF0aW9uIE1vZGVsIGZvciBQYWNrZXQgU2FtcGxpbmcgRXhwb3J0cyIsIA0KICAg ICAgICAgICAgICAgICAgSW50ZXJuZXQgRHJhZnQgPGRyYWZ0LWlldGYtcHNhbXAtaW5mby0wNC50 eHQ+LCB3b3JrIA0KICAgICAgICAgICAgICAgICAgaW4gcHJvZ3Jlc3MsIE1hcmNoIDIwMDYgDQog ICAgIA0KDQoNCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyNF0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQ RklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICBbUkZD MzkxN10gICAgSi4gUXVpdHRlaywgVC4gWnNlYnksIEIuIENsYWlzZSwgUy4gWmFuZGVyLCANCiAg ICAgICAgICAgICAgICAgICJSZXF1aXJlbWVudHMgZm9yIElQIEZsb3cgSW5mb3JtYXRpb24gRXhw b3J0IiwgUkZDIA0KICAgICAgICAgICAgICAgICAgMzkxNywgT2N0b2JlciAyMDA0IA0KICAgICAN CiA4LiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICANCiAgICAgDQogICAgW0Jyb3cwMF0gICAgIE5l dmlsIEJyb3dubGVlLCAiUGFja2V0IE1hdGNoaW5nIGZvciBOZVRyYU1ldCANCiAgICAgICAgICAg ICAgICAgIERpc3RyaWJ1dGlvbnMiLCANCiAgICAgICAgICAgICAgICAgIGh0dHA6Ly93d3cyLmF1 Y2tsYW5kLmFjLm56L25ldC8vSW50ZXJuZXQvcnRmbS9tZWV0aQ0KICAgICAgICAgICAgICAgICAg bmdzLzQ3LWFkZWxhaWRlL3BwLWRpc3QvIA0KICAgICANCiAgICBbRHVHcjAwXSAgICAgTmljayBE dWZmaWVsZCwgTWF0dGhpYXMgR3Jvc3NnbGF1c2VyLCAiVHJhamVjdG9yeSANCiAgICAgICAgICAg ICAgICAgIFNhbXBsaW5nIGZvciBEaXJlY3QgVHJhZmZpYyBPYnNlcnZhdGlvbiIsIA0KICAgICAg ICAgICAgICAgICAgUHJvY2VlZGluZ3Mgb2YgQUNNIFNJR0NPTU0gMjAwMCwgU3RvY2tob2xtLCBT d2VkZW4sIA0KICAgICAgICAgICAgICAgICAgQXVndXN0IDI4IC0gU2VwdGVtYmVyIDEsIDIwMDAg DQogICAgIA0KICAgIFtHckRNOThdICAgICBJYW4gRC4gR3JhaGFtLCBTdGVwaGVuIEYuIERvbm5l bGx5LCBTdGVsZSBNYXJ0aW4sIA0KICAgICAgICAgICAgICAgICAgSmVkIE1hcnRlbnMsIEpvaG4g Ry4gQ2xlYXJ5LCAiTm9uaW50cnVzaXZlIGFuZCANCiAgICAgICAgICAgICAgICAgIEFjY3VyYXRl IE1lYXN1cmVtZW50IG9mIFVuaWRpcmVjdGlvbmFsIERlbGF5IGFuZCANCiAgICAgICAgICAgICAg ICAgIERlbGF5IFZhcmlhdGlvbiBvbiB0aGUgSW50ZXJuZXQiLCBJTkVUJzk4LCBHZW5ldmEsIA0K ICAgICAgICAgICAgICAgICAgU3dpdHplcmxhbmQsIDIxLTI0IEp1bHksIDE5OTggDQogICAgIA0K ICAgIFtJUEZJWC1BUkNIXSBHLiBTYWRhc2l2YW4sIE4uIEJyb3dubGVlLCBCLiBDbGFpc2UsIEou IFF1aXR0ZWssICAgIA0KICAgICAgICAgICAgICAgICAgIkFyY2hpdGVjdHVyZSBmb3IgSVAgRmxv dyBJbmZvcm1hdGlvbiBFeHBvcnQiLCANCiAgICAgICAgICAgICAgICAgIEludGVybmV0IERyYWZ0 IDxkcmFmdC1pZXRmLWlwZml4LWFyY2hpdGVjdHVyZS0NCiAgICAgICAgICAgICAgICAgIDA4LnR4 dD4sIHdvcmsgaW4gcHJvZ3Jlc3MsIE1hcmNoIDIwMDUgDQogICAgIA0KICAgIFtQU0FNUC1QUk9U T10gQmVub2l0IENsYWlzZSAoRWQuKSwgUGFja2V0IFNhbXBsaW5nIChQU0FNUCkgDQogICAgICAg ICAgICAgICAgICBQcm90b2NvbCBTcGVjaWZpY2F0aW9ucywgSW50ZXJuZXQgRHJhZnQgPGRyYWZ0 LQ0KICAgICAgICAgICAgICAgICAgaWV0Zi1wc2FtcC1wcm90b2NvbC0wNC50eHQ+LCB3b3JrIGlu IHByb2dyZXNzLCANCiAgICAgICAgICAgICAgICAgIE1hcmNoIDIwMDYgDQogICAgIA0KICAgIFtQ U0FNUC1URUNIXSAgVC4gWnNlYnksIE0uIE1vbGluYSwgTi4gRHVmZmllbGQsIFMuIE5pY2NvbGlu aSwgRi4gDQogICAgICAgICAgICAgICAgICBSYXNwYWxsLCAiU2FtcGxpbmcgYW5kIEZpbHRlcmlu ZyBUZWNobmlxdWVzIGZvciBJUCANCiAgICAgICAgICAgICAgICAgIFBhY2tldCBTZWxlY3Rpb24i IEludGVybmV0IERyYWZ0IDxkcmFmdC1pZXRmLXBzYW1wLQ0KICAgICAgICAgICAgICAgICAgc2Ft cGxlLXRlY2gtMDcudHh0Piwgd29yayBpbiBwcm9ncmVzcywgSnVseSAyMDA1IA0KICAgICANCiAg ICBbUkZDMjU5OF0gICAgVi4gSmFjb2Jzb24sIEsuIE5pY2hvbHMsIEsuIFBvZHVyaSwgIkFuIEV4 cGVkaXRlZCANCiAgICAgICAgICAgICAgICAgIEZvcndhcmRpbmcgUEhCIiwgUkZDIDI1OTgsIEp1 bmUgMTk5OSANCiAgICAgDQogICAgW1JGQzI2NzldICAgIEcuIEFsbWVzLCBTLiBLYWxpZGluZGks IE0uIFpla2F1c2thcywgIkEgT25lLXdheSANCiAgICAgICAgICAgICAgICAgIERlbGF5IE1ldHJp YyBmb3IgSVBQTSIsIFJGQyAyNjc5LCBTZXB0ZW1iZXIgMTk5OSAgIA0KICAgICANCiAgICBbUkZD MjY4MF0gICAgRy4gQWxtZXMsIFMuIEthbGlkaW5kaSwgTS4gWmVrYXVza2FzLCAiQSBPbmUtd2F5 IA0KICAgICAgICAgICAgICAgICAgUGFja2V0IExvc3MgTWV0cmljIGZvciBJUFBNIixSRkMgMjY4 MCwgU2VwdGVtYmVyIA0KICAgICAgICAgICAgICAgICAgMTk5OSANCiAgICAgDQoNCg0KDQoNCg0K IFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAyNV0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkg ICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICBbUkZDMjY4MV0gICAgRy4gQWxtZXMs IFMuIEthbGlkaW5kaSwgTS4gWmVrYXVza2FzLCAiQSBSb3VuZC10cmlwIA0KICAgICAgICAgICAg ICAgICAgRGVsYXkgTWV0cmljIGZvciBJUFBNIiwgUkZDIDI2ODEsIFNlcHRlbWJlciAxOTk5IA0K ICAgICANCiAgICBbUkZDMjcwMl0gICAgRC4gQXdkdWNoZSwgSi4gTWFsY29sbSwgSi4gQWdvZ2J1 YSwgTS4gTydEZWxsLCBKLiAgICAgICAgDQogICAgICAgICAgICAgICAgICBNY01hbnVzLCAiUmVx dWlyZW1lbnRzIGZvciBUcmFmZmljIEVuZ2luZWVyaW5nIE92ZXIgDQogICAgICAgICAgICAgICAg ICBNUExTIiwgUkZDIDI3MDIsIFNlcHRlbWJlciAxOTk5IA0KICAgICANCiAgICBbUkZDMjcyMl0g ICAgQnJvd25sZWUsIE4uLCBNaWxscywgQy4sIEcuIFJ1dGgsICJUcmFmZmljIEZsb3cgDQogICAg ICAgICAgICAgICAgICBNZWFzdXJlbWVudDogQXJjaGl0ZWN0dXJlIiwgUkZDIDI3MjIsIE9jdG9i ZXIgMTk5OSANCiAgICAgDQogICAgW1JGQzI5MDNdICAgIEMuIGRlIExhYXQsIEcuIEdyb3NzLCBM LiBHb21tYW5zLCBKLiBWb2xsYnJlY2h0LCBELiANCiAgICAgICAgICAgICAgICAgIFNwZW5jZSwg IkdlbmVyaWMgQUFBIEFyY2hpdGVjdHVyZSIsIFJGQyAyOTAzLCANCiAgICAgICAgICAgICAgICAg IEF1Z3VzdCAyMDAwIA0KICAgICANCiAgICBbUkZDMjk2MF0gICAgUi4gU3Rld2FydCAoZWQuKSAi U3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIA0KICAgICAgICAgICAgICAgICAgUHJvdG9jb2wi LCBSRkMgMjk2MCwgT2N0b2JlciAyMDAwIA0KICAgICANCiAgICBbUkZDMjk3NV0gICAgQi4gQWJv YmEsIEouIEFya2tvLCBELiBIYXJyaW5ndG9uLCAiSW50cm9kdWN0aW9uIHRvIA0KICAgICAgICAg ICAgICAgICAgQWNjb3VudGluZyBNYW5hZ2VtZW50IiwgUkZDIDI5NzUsIE9jdG9iZXIgMjAwMCAN CiAgICAgDQogICAgW1JGQzMzMzBdICAgIElBTkEsICJTcGVjaWFsLVVzZSBJUHY0IEFkZHJlc3Nl cyIsIFJGQyAzMzMwICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICBTZXB0 ZW1iZXIgMjAwMiANCiAgICAgDQogICAgW1JGQzMzMzRdICAgIFQuIFpzZWJ5LCBTLiBaYW5kZXIs IEcuIENhcmxlLCAiUG9saWN5LUJhc2VkIA0KICAgICAgICAgICAgICAgICAgQWNjb3VudGluZyIs IFJGQyAzMzM0LCBPY3RvYmVyIDIwMDIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAg ICAgDQogICAgW1JGQzMzOTNdICAgIEMuIERlbWljaGVsaXMsIFAuIENpbWVudG8sICJJUCBQYWNr ZXQgRGVsYXkgDQogICAgICAgICAgICAgICAgICBWYXJpYXRpb24gTWV0cmljIGZvciBJUFBNIiwg UkZDIDMzOTMsIE5vdmVtYmVyIDIwMDIgDQogICAgIA0KICAgIFtSRkMzNTc3XSAgICBTLiBXYWxk YnVzc2VyLCBSLiBDb2xlLCBDLiBLYWxiZmxlaXNjaCwgDQogICAgICAgICAgICAgICAgICBELlJv bWFzY2FudSwgIkludHJvZHVjdGlvbiB0byB0aGUgUmVtb3RlIE1vbml0b3JpbmcgDQogICAgICAg ICAgICAgICAgICAoUk1PTikgRmFtaWx5IG9mIE1JQiBNb2R1bGUiLCBSRkMgMzU3NywgQXVndXN0 IDIwMDMgDQogICAgIA0KICAgIFtSRkMzNTg4XSAgICBQLiBDYWxob3VuLCBKLiBMb3VnaG5leSwg RS4gR3V0dG1hbiwgRy4gWm9ybiwgSi4gDQogICAgICAgICAgICAgICAgICBBcmtrbywgIkRpYW1l dGVyIEJhc2UgUHJvdG9jb2wiLCBSRkMgMzU4OCwgDQogICAgICAgICAgICAgICAgICBTZXB0ZW1i ZXIgMjAwMyANCiAgICAgDQogICAgW1JGQzM3MjldICAgIFMuIFdhbGRidXNzZXIsICJBcHBsaWNh dGlvbiBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCANCiAgICAgICAgICAgICAgICAgIE1JQiIsIFJG QyAzNzI5LCBNYXJjaCAyMDA0IA0KICAgICANCiAgICBbUkZDMzc1OF0gICAgUi4gU3Rld2FydCwg TS4gUmFtYWxobywgUS4gWGllLCBNLiBUdWV4ZW4sIFAuIA0KICAgICAgICAgICAgICAgICAgQ29u cmFkLCAiU3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29sIA0KICAgICAgICAgICAg ICAgICAgKFNDVFApIFBhcnRpYWwgUmVsaWFiaWxpdHkgRXh0ZW5zaW9uIiwgUkZDIDM3NTgsIA0K ICAgICAgICAgICAgICAgICAgTWF5IDIwMDQgIA0KICAgICANCiAgICBbUkZDMjcyMF0gICAgTi4g QnJvd25sZWUsIFRyYWZmaWMgRmxvdyBNZWFzdXJlbWVudDogTWV0ZXIgTUlCLCANCiAgICAgICAg ICAgICAgICAgUkZDMjcyMCBPY3RvYmVyIDE5OTkNCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJy b3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyNl0gDQoMICAg ICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUg MjAwNiANCg0KDQogICAgIA0KICAgIFtSRkM0MTUwXSAgICBSLiBEaWV0eiwgUi4gQ29sZSwgIlRy YW5zcG9ydCBQZXJmb3JtYW5jZSBNZXRyaWNzIA0KICAgICAgICAgICAgICAgICAgTUlCIiwgUkZD IDQxNTAsIEF1Z3VzdCAyMDA1IA0KICAgICANCiAgICBbWnNaQzAxXSAgICAgVC4gWnNlYnksIFMu IFphbmRlciwgRy4gQ2FybGUsICJFdmFsdWF0aW9uIG9mIA0KICAgICAgICAgICAgICAgICAgQnVp bGRpbmcgQmxvY2tzIGZvciBQYXNzaXZlIE9uZS13YXktZGVsYXkgDQogICAgICAgICAgICAgICAg ICBNZWFzdXJlbWVudHMiLCBQcm9jZWVkaW5ncyBvZiBQYXNzaXZlIGFuZCBBY3RpdmUgDQogICAg ICAgICAgICAgICAgICBNZWFzdXJlbWVudCBXb3Jrc2hvcCAoUEFNIDIwMDEpLCBBbXN0ZXJkYW0s IFRoZSANCiAgICAgICAgICAgICAgICAgIE5ldGhlcmxhbmRzLCBBcHJpbCAyMy0yNCwgMjAwMSAN CiAgICAgDQogOS4gQWNrbm93bGVkZ2VtZW50cyANCiAgICAgDQogICAgV2Ugd291bGQgbGlrZSB0 byB0aGFuayB0aGUgZm9sbG93aW5nIHBlcnNvbnMgZm9yIHRoZWlyIA0KICAgIGNvbnRyaWJ1dGlv biwgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCB2YWx1YWJsZSANCiAgICBjb21t ZW50czogDQogICAgIA0KICAgIFNlYmFzdGlhbiBaYW5kZXIgDQogICAgUm9iZXJ0IExvZXdlIA0K ICAgIFJlaW5hbGRvIFBlbm5vIA0KICAgIEx1dHogTWFyayANCiAgICBBbmR5IEJpZXJtYW5uIA0K ICAgICANCiAgICBQYXJ0IG9mIHRoZSB3b3JrIGhhcyBiZWVuIGRldmVsb3BlZCBpbiB0aGUgcmVz ZWFyY2ggcHJvamVjdCA2UU0gDQogICAgY28tZnVuZGVkIHdpdGggc3VwcG9ydCBmcm9tIHRoZSBF dXJvcGVhbiBDb21taXNzaW9uLiAgIA0KICAgICANCiAxMC5BdXRob3JzJyBBZGRyZXNzZXMgDQog ICAgIA0KICAgIFRhbmphIFpzZWJ5IA0KICAgIEZyYXVuaG9mZXIgSW5zdGl0dXRlIGZvciBPcGVu IENvbW11bmljYXRpb24gU3lzdGVtcyAoRk9LVVMpIA0KICAgIEthaXNlcmluLUF1Z3VzdGEtQWxs ZWUgMzEgICANCiAgICAxMDU4OSBCZXJsaW4sIEdlcm1hbnkgICANCiAgICBQaG9uZTogKzQ5IDMw IDM0NjMgNzE1MyAgIA0KICAgIEVtYWlsOiB6c2VieUBmb2t1cy5maGcuZGUgDQogICAgIA0KICAg IEVsaXNhIEJvc2NoaSANCiAgICBIaXRhY2hpIEV1cm9wZSBTQVMgIA0KICAgIEltbWV1YmxlIExl IFRoZWxlbWUgIA0KICAgIDE1MDMgUm91dGUgZGVzIERvbGluZXMgIA0KICAgIDA2NTYwIFZhbGJv bm5lLCBGcmFuY2UgIA0KICAgIFBob25lOiArMzMgNCA4OTg3NDE4MCAgICAgDQogICAgRW1haWw6 IGVsaXNhLmJvc2NoaUBoaXRhY2hpLWV1LmNvbSAgDQogICAgIA0KICAgIE5ldmlsIEJyb3dubGVl IA0KICAgIENBSURBIChVQ1NEL1NEU0MpIA0KICAgIDk1MDAgR2lsbWFuIERyaXZlIA0KICAgIExh IEpvbGxhLCBDQSA5MjA5My0wNTA1IA0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUs IENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDI3XSANCgwgICAgICAgICAg ICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0K DQoNCg0KICAgIFBob25lIDogKzEgODU4IDUzNCA4MzM4IA0KICAgIEVtYWlsIDogbmV2aWxAY2Fp ZGEub3JnIA0KICAgICANCiAgICBCZW5vaXQgQ2xhaXNlIA0KICAgIENpc2NvIFN5c3RlbXMgDQog ICAgRGUgS2xlZXRsYWFuIDZhIGIxIA0KICAgIDE4MzEgRGllZ2VtIA0KICAgIEJlbGdpdW0gDQog ICAgUGhvbmU6ICszMiAyIDcwNCA1NjIyIA0KICAgIEVtYWlsOiBiY2xhaXNlQGNpc2NvLmNvbSAN CiAgICAgDQogMTEuRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50IA0KICAgICANCiAgICAiQ29weXJp Z2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuIEFsbCBSaWdodHMgUmVzZXJ2ZWQu IA0KICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVk IGFuZCBmdXJuaXNoZWQgDQogICAgdG8gb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0 IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIA0KICAgIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGluIGl0 cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIA0KICAgIGNvcGllZCwgcHVibGlzaGVk IGFuZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCANCiAgICByZXN0 cmljdGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IA0K ICAgIG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNv cGllcyBhbmQgDQogICAgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZlciwgdGhpcyBkb2N1bWVudCBp dHNlbGYgbWF5IG5vdCBiZSANCiAgICBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJl bW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIA0KICAgIHJlZmVyZW5jZXMgdG8gdGhlIElu dGVybmV0IFNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgDQogICAgb3JnYW5pemF0aW9ucywgZXhj ZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyANCiAgICBJbnRlcm5l dCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyAN CiAgICBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZv bGxvd2VkLCBvciANCiAgICBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50by4gDQogICAg IA0KIDEyLiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IA0KICAgICANCiAgICBUaGUg SUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9m IA0KICAgIGFueSBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0 aGF0IG1pZ2h0IGJlIA0KICAgIGNsYWltZWQgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRp b24gb3IgdXNlIG9mIHRoZSANCiAgICB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3Vt ZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IA0KICAgIGxpY2Vuc2UgdW5kZXIgc3VjaCBy aWdodHMgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIA0KICAgIGRvZXMgaXQg cmVwcmVzZW50IHRoYXQgaXQgaGFzIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byANCiAg ICBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbiBvbiB0aGUgcHJvY2VkdXJl cyB3aXRoIA0KICAgIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlIGZv dW5kIGluIEJDUCA3OCBhbmQgDQogICAgQkNQIDc5LiANCiAgICAgDQogICAgQ29waWVzIG9mIElQ UiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkgDQogICAg YXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3Vs dCBvZiBhbiANCiAgICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9y IHBlcm1pc3Npb24gZm9yIHRoZSANCiAgICB1c2Ugb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdodHMg YnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMgDQogICAgc3BlY2lmaWNhdGlvbiBjYW4g YmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiANCiAgICByZXBvc2l0b3J5IGF0 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLiANCiAgICAgDQoNCg0KDQoNCg0KIFpzZWJ5LCBCb3Nj aGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyOF0g DQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAg IEp1bmUgMjAwNiANCg0KDQoNCiAgICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBh cnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gDQogICAgYW55IGNvcHlyaWdodHMsIHBhdGVu dHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgDQogICAgcHJvcHJpZXRhcnkgcmln aHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgDQogICAgcmVxdWlyZWQg dG8gaW1wbGVtZW50IHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgDQogICAgaW5m b3JtYXRpb24gdG8gdGhlIElFVEYgYXQgaWV0Zi1pcHJAaWV0Zi5vcmcuIA0KICAgICANCiAxMy4g Q29weXJpZ2h0IFN0YXRlbWVudCANCiAgICAgDQogICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMjAwNikuICBUaGlzIGRvY3VtZW50IGlzIA0KICAgIHN1YmplY3QgdG8gdGhl IHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250YWluZWQgaW4gDQogICAgQkNQ IDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4g YWxsIA0KICAgIHRoZWlyIHJpZ2h0cy4gDQogICAgIA0KIDE0LiBEaXNjbGFpbWVyICANCiAgICAg DQogICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4g YXJlIHByb3ZpZGVkIA0KICAgIG9uIGFuICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRP UiwgVEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgDQogICAgUkVQUkVTRU5UUyBPUiBJUyBTUE9OU09S RUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCANCiAgICBUSEUgSU5URVJO RVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgDQogICAg RVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJS QU5UWSANCiAgICBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5P VCBJTkZSSU5HRSBBTlkgDQogICAgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0Yg TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgDQogICAgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF LiANCiAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAg ICAgICAgICAgW1BhZ2UgMjldIA0KDA== ------_=_NextPart_001_01C68635.72A64171-- -- 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 Jun 02 08:31:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8oL-0007Qx-GM for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 08:31:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8oL-0006sv-EL for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 08:31:29 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fm8oI-0003F6-45 for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 08:31:29 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fm8Fg-0001oC-00 for ipfix-list@mil.doit.wisc.edu; Fri, 02 Jun 2006 06:55:40 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fm8Fe-0001o2-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 02 Jun 2006 06:55:38 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k52Btbn08261; Fri, 2 Jun 2006 13:55:37 +0200 (MEST) Message-ID: <44802738.5060902@fokus.fraunhofer.de> Date: Fri, 02 Jun 2006 13:55:36 +0200 From: Lutz Mark User-Agent: Mail/News 1.5 (X11/20060130) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi Juergen, > I would favor the Observation Domain identifier to be unique per > Exporting Process. I consider 'unique per session' as also feasible. > But I do not think it is feasible to have the Observation Domain unique > per IPFIX device. I see the following problems with this approach: > > - We would exclude cases where the Observation Domain is not on > the same box as the exporter. There are four such cases discussed > on RFC 3917, page 21 (protocol converter, remote observation point, > concentrator, and proxy). According to the current definition of > an IPFIX device in the protocol draft > >> IPFIX Device >> >> An IPFIX Device hosts at least one Observation Point, a Metering >> Process and an Exporting Process. > > none of them are IPFIX devices. There is no point in asking an ID > unique per IPFIX device if there is no IPFIX device present in the > scenario. good point! Presently boxes like concentrator, proxy, etc. are not mentioned in the architecture draft. > Let's assume we fix this by re-defining the term IPFIX device, for > example, by stating that an IPFIX device hosts at least one of the > following: an Observation Point, a Metering Process, or an Exporting > Process. or all boxes, which generate IPFIX data are IPFIX devices. > Then I still see problems with having the Observation Domain > unique per IPFIX device: > > - How would two implementations (of potentially different vendors) > in the same box coordinate their Observation Domain naming schemes? > The IPFIX standard is not proposing one. right, this is a problem. > - What would an exporter do that reports for several boxes? > This could be in one of the cases mentioned above (protocol > converter, remote observation point, concentrator, or proxy). > In case of the concentrator, all input to the concentrator > already uses Observation Domains that are unique to their > respective IPFIX device. The concentrator would still not > be able to use them without risking that two Observation > Domains on different boxes have the same ID. The protocol draft proposes to use ID zero in that cases. Alternatively it could generate new Observation Domain IDs for these data because the ID has only to be unique per IPFIX device. I tend to change the definition of the IPFIX device to cover proxies etc. Best regards, Lutz -- 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 Jun 02 09:05:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9LW-000248-JO for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 09:05:46 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9LW-0003Wk-I8 for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 09:05:46 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fm9J9-0003sV-KZ for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 09:03:21 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fm9EH-00077w-00 for ipfix-list@mil.doit.wisc.edu; Fri, 02 Jun 2006 07:58:17 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fm9EF-00077q-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 02 Jun 2006 07:58:15 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k52Cvwn17047; Fri, 2 Jun 2006 14:57:58 +0200 (MEST) Message-ID: <448035D6.40003@fokus.fraunhofer.de> Date: Fri, 02 Jun 2006 14:57:58 +0200 From: Lutz Mark User-Agent: Mail/News 1.5 (X11/20060130) MIME-Version: 1.0 To: Brian Trammell CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> In-Reply-To: <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi Brian, > Redefining the Observation Domain to be unique per (exporting) IPFIX > Device partially fixes the problem, but it does not address the problem > of Exporting Process/exporting device identification at the Collecting > Process, of which the Exporting Process IP address collision issue is a > subset. If an IPFIX device is using multihomed SCTP associations, for > example, a Collecting Process may not treat two Observation Domains that > are really identical as such. > > Therefore, I would propose again that instead of defining Observation > Domains to be unique per exporting IPFIX Device, that Observation > Domains are unique per Session, where a Session is a TCP connection, an > SCTP association, or a (time-limited) UDP four-tuple. This grants the > most flexibility to implementors while being, in my opinion, more > logically sound... If an exporting device implementor wishes instead to > enforce domain uniqueness per Device, that would be consistent with this > definition. Having the Observation Domain ID unique per session will ease the implementation of the exporter and collector part of the protocol. As you have mentioned an Observation Domain ID that is unique per IPFIX device implies that the ID is unique per session. Having the ID unique only per session has the drawback that on the collector side the ID is quite useless without the session details and one need additional means to group data from different sessions. If the ID is unique per IPFIX device, the collector can store the Observation Domain ID together with the flow data (for each IPFIX device). And an application can request flow data per observation domain. Best regards, Lutz -- 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 Jun 02 10:15:59 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmART-0005pW-Kg for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 10:15:59 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmARR-0001xN-AD for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 10:15:59 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FmAMn-0003GY-00 for ipfix-list@mil.doit.wisc.edu; Fri, 02 Jun 2006 09:11:09 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FmAMm-0003GT-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 02 Jun 2006 09:11:08 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.20) with ESMTP id k52EB4oU008580 for ; Fri, 2 Jun 2006 10:11:05 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k52EA95R008507 for ; Fri, 2 Jun 2006 10:10:09 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k52EA6I5008487; Fri, 02 Jun 2006 10:10:09 -0400 (EDT) Received: from [128.237.238.222] (vpn-10-25-4-14.remote.cert.org [10.25.4.14]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.60) with ESMTP id k52EA5gd004396; Fri, 2 Jun 2006 10:10:05 -0400 In-Reply-To: <448035D6.40003@fokus.fraunhofer.de> References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> <448035D6.40003@fokus.fraunhofer.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--848489041" Message-Id: Cc: ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Date: Fri, 2 Jun 2006 10:10:02 -0400 To: Lutz Mark , Juergen Quittek X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--848489041 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Lutz and Juergen, On Jun 2, 2006, at 8:57 AM, Lutz Mark wrote: > > Hi Brian, > >> Redefining the Observation Domain to be unique per (exporting) >> IPFIX Device partially fixes the problem, but it does not address >> the problem of Exporting Process/exporting device identification >> at the Collecting Process, of which the Exporting Process IP >> address collision issue is a subset. If an IPFIX device is using >> multihomed SCTP associations, for example, a Collecting Process >> may not treat two Observation Domains that are really identical as >> such. >> Therefore, I would propose again that instead of defining >> Observation Domains to be unique per exporting IPFIX Device, that >> Observation Domains are unique per Session, where a Session is a >> TCP connection, an SCTP association, or a (time-limited) UDP four- >> tuple. This grants the most flexibility to implementors while >> being, in my opinion, more logically sound... If an exporting >> device implementor wishes instead to enforce domain uniqueness per >> Device, that would be consistent with this definition. > > Having the Observation Domain ID unique per session will ease the > implementation of the exporter and collector part of the protocol. > As you have mentioned an Observation Domain ID that is unique per > IPFIX device implies that the ID is unique per session. > Having > the ID unique only per session has the drawback that on the > collector side the ID is quite useless without the session details > and one need additional means to group data from different sessions. Indeed... I hadn't thought of that. We would need some sort of session identifier, whether a simple IE or compound, to store session details. > If the ID is unique per IPFIX device, the collector can store > the Observation Domain ID together with the flow data (for each > IPFIX device). And an application can request flow data per > observation domain. Could we address Juergen's concerns with respect to the imprecision of the present IPFIX Device definition (an architectural term that I'm not personally convinced should have any real meaning at the protocol level) by instead defining uniqueness per {Metering Process, Exporting Process} tuple? Argh... actually, neither of these will work as root scopes. The {Meter, Exporter} tuple requires stability over time - it requires that no Observation Domain ID ever be reused, which is clearly ridiculous. A Session (which is really an {Exporter, Collector, Source Port, Start Time, End Time} tuple with multiple addresses possible for Exporter and Collector in the case of SCTP multihoming) is not naturally storable at the collector side. The "right" thing to do in this case would seem to be to scope Observation Domain IDs to the superset of both, a {Meter, Exporter, Collector, Start Time, End Time} tuple, but this just seems to be a bit too heavy. With what frequency to we expect realistic Exporting Processes to assign new Observation Domain IDs to logically identical Domains? As a thought exercise in whether we're overthinking this: what would happen if we went to the other extreme, stepped back completely, simply defined the Observation Domain as we do now without guaranteeing its uniqueness anywhere, and required the implementation or deployment to avoid observation domain ID collision out of band? Regards, Brian --Apple-Mail-2--848489041 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEgEa94/8LCZ4pwvYRAuD1AKDEG3r5j80W1OjXZ7RD3y8RbxAc5ACfSZXj 2yPnX5rFQLUqO//DfhNXUCo= =jIQe -----END PGP SIGNATURE----- --Apple-Mail-2--848489041-- -- 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 Jun 02 15:59:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmFoH-0002e7-Hr for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 15:59:53 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmFoG-0005xC-90 for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 15:59:53 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FmFep-0000ES-00 for ipfix-list@mil.doit.wisc.edu; Fri, 02 Jun 2006 14:50:07 -0500 Received: from pine.neustar.com ([209.173.57.70]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FmFeo-0000EI-00 for ipfix@net.doit.wisc.edu; Fri, 02 Jun 2006 14:50:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k52Jo1Hp006784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FmFej-0008GV-K3; Fri, 02 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-as-08.txt Message-Id: Date: Fri, 02 Jun 2006 15:50:01 -0400 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Applicability Author(s) : T. Zseby, et al. Filename : draft-ietf-ipfix-as-08.txt Pages : 29 Date : 2006-6-2 This document describes the applicability of the IP Flow Information Export (IPFIX) protocol for a variety of applications. It shows how applications can use IPFIX, describes the relevant information elements (IEs) and shows opportunities and limitations of the protocol. The document furthermore describes relations of the IPFIX framework to other architectures and frameworks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-as-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-as-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-2104601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-as-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-as-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-2104601.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 lakibochen@gothnation.com Fri Jun 02 22:47:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmMAz-0001LH-QO for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 22:47:45 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmMAw-0006IP-Gi for ipfix-archive@lists.ietf.org; Fri, 02 Jun 2006 22:47:45 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FmM5q-0003eN-00 for ipfix-list@mil.doit.wisc.edu; Fri, 02 Jun 2006 21:42:26 -0500 Received: from gothnation.com (10.Red-80-33-71.staticIP.rima-tde.net [80.33.71.10]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k532gH1b027471 for ; Fri, 2 Jun 2006 21:42:25 -0500 Message-ID: <000001c686b7$5bc2ad60$576fa8c0@pqo83> Reply-To: "Lakisha Bochenek" From: "Lakisha Bochenek" To: ipfix-list@mil.doit.wisc.edu Subject: Re: 306 VmALLtUM Date: Fri, 2 Jun 2006 19:42:30 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6867C.AF63D560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.1 (+++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6867C.AF63D560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 L E V \ T R A C \ A L i S=20 V \ A G R A=20 P R O Z & C A M B \ E N M E R \ D i A V A L \ U M=20 X & N A X S O M &=20 http://www.marebokigas.com=20 will show you. I have no signs on my door-it was painted a week ago-,=20 and I am quite sure you have come to the wrong house. As soon as I saw=20 your funny faces on the door-step, I had my doubts. But treat it as the=20 right one. Tell me what you want done, and I will try it, if I have to=20 walk from here to the East of East and fight the wild Were-worms in the=20 Last Desert. I bad a great-great-great-granduncle once, Bullroarer Took, ------=_NextPart_000_0001_01C6867C.AF63D560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
L E V \ T R A
C \ A L i S
V \ A G R A
P R O Z & C
A M B \ E N
M E R \ D i A
V A L \ U M
X & N A X
S O M &
http://www.marebokigas.com




will show you. I have no signs on my door-it was painted a week ago-, =
and I am quite sure you have come to the wrong house. As soon as I = saw
your funny faces on the door-step, I had my doubts. But treat it = as the
right one. Tell me what you want done, and I will try it, if = I have to
walk from here to the East of East and fight the wild = Were-worms in the
Last Desert. I bad a great-great-great-granduncle = once, Bullroarer Took,
------=_NextPart_000_0001_01C6867C.AF63D560-- From pennlusk@passportimages.com Sat Jun 03 03:24:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmQUf-0003PM-RO for ipfix-archive@lists.ietf.org; Sat, 03 Jun 2006 03:24:21 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmQUe-0006rj-61 for ipfix-archive@lists.ietf.org; Sat, 03 Jun 2006 03:24:21 -0400 Received: from [218.14.52.131] (helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FmQLa-0002eU-00 for ipfix-list@mil.doit.wisc.edu; Sat, 03 Jun 2006 02:14:58 -0500 Message-Id: <00c901c686d3$25616880$94c9179a@vvagsqp> From: "emlynne pelletier" To: "darice larkin" Subject: We bring Vegas to you! Date: Sat, 03 Jun 2006 06:10:33 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01C686D3.25616880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.6 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01C686D3.25616880 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable YOUR O N L I N E VEGAS! * Get Your Free USD 888 Bonus! * Play free non limit * 70+ ANY games * 24/7 crew + call center http://jetiol.com/casino/ swift-concerted well-caned Catherine pear fair-weather sailor line symmetry ball cartridge quasi courtesy sand badger midday flower white-tinned attack squadron lofting iron potato fungus small-spotted three-point switch riving machine all-affecting re-employ sword guard web-worked firing ring arriere vassal primrose willow ten-rayed ------=_NextPart_000_00C9_01C686D3.25616880 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
YOUR O N L I N E VEGAS!
* Get Your Free USD 888 Bonus!
* Play free non limit
* 70+ ANY games
* 24/7 crew + call center
http://jetiol.com/casino/

swift-concerted well-caned Catherine pear
fair-weather sailor line symmetry ball cartridge
quasi courtesy sand badger midday flower
white-tinned attack squadron lofting iron
potato fungus small-spotted three-point switch
riving machine all-affecting re-employ
sword guard web-worked firing ring
arriere vassal primrose willow ten-rayed
= ------=_NextPart_000_00C9_01C686D3.25616880-- From majordomo@mil.doit.wisc.edu Sat Jun 03 12:05:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYcn-00011Q-HM for ipfix-archive@lists.ietf.org; Sat, 03 Jun 2006 12:05:17 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmYck-0000oo-4z for ipfix-archive@lists.ietf.org; Sat, 03 Jun 2006 12:05:17 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FmY26-0004VE-00 for ipfix-list@mil.doit.wisc.edu; Sat, 03 Jun 2006 10:27:22 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FmY24-0004V1-00 for ipfix-protocol@net.doit.wisc.edu; Sat, 03 Jun 2006 10:27:20 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id CE5E5122 for ; Sat, 3 Jun 2006 17:27:18 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25214-02 for ; Sat, 3 Jun 2006 17:27:16 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 160C111B for ; Sat, 3 Jun 2006 17:27:14 +0200 (MST) Message-ID: <4481AA1E.4060901@informatik.uni-tuebingen.de> Date: Sat, 03 Jun 2006 17:26:22 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> <448035D6.40003@fokus.fraunhofer.de> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070707010704090003050305" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b This is a cryptographically signed message in MIME format. --------------ms070707010704090003050305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, We have discussed the Observation Domain ID issue a lot. Something came into my mind and maybe it is useful to solve the problem. There are two different things that we want to do: 1) Identify the Exporting Process because we need it for the template management. 2) Identify the Observation Domain because we want to know where the traffic as been observed. The problem is that the Observation Domain ID (formerly known as Source ID) is in the header of the IPFIX message. This is not logic because the Obervation Domain ID is linked to a record while the IPFIX header is something that the Exporting Process is responsible for. Wouldn't it be better to replace the Observation Domain ID in the IPFIX header by the Exporter ID? Then, the pair exporter IP address (that we get from the IP header) together with the Exporter ID in the IPFIX header could identify the Exporting Process. If ever needed, the Observation Domain ID can be exported with the individual records or within option data. Regards, Gerhard Brian Trammell wrote: > Lutz and Juergen, >=20 > On Jun 2, 2006, at 8:57 AM, Lutz Mark wrote: >=20 >> >> Hi Brian, >> >>> Redefining the Observation Domain to be unique per (exporting) IPFIX >>> Device partially fixes the problem, but it does not address the >>> problem of Exporting Process/exporting device identification at the >>> Collecting Process, of which the Exporting Process IP address >>> collision issue is a subset. If an IPFIX device is using multihomed >>> SCTP associations, for example, a Collecting Process may not treat >>> two Observation Domains that are really identical as such. >>> Therefore, I would propose again that instead of defining Observation >>> Domains to be unique per exporting IPFIX Device, that Observation >>> Domains are unique per Session, where a Session is a TCP connection, >>> an SCTP association, or a (time-limited) UDP four-tuple. This grants >>> the most flexibility to implementors while being, in my opinion, more >>> logically sound... If an exporting device implementor wishes instead >>> to enforce domain uniqueness per Device, that would be consistent >>> with this definition. >> >> Having the Observation Domain ID unique per session will ease the >> implementation of the exporter and collector part of the protocol. >> As you have mentioned an Observation Domain ID that is unique per >> IPFIX device implies that the ID is unique per session. >=20 >=20 >> Having >> the ID unique only per session has the drawback that on the >> collector side the ID is quite useless without the session details >> and one need additional means to group data from different sessions. >=20 > Indeed... I hadn't thought of that. We would need some sort of session > identifier, whether a simple IE or compound, to store session details. >=20 >> If the ID is unique per IPFIX device, the collector can store >> the Observation Domain ID together with the flow data (for each >> IPFIX device). And an application can request flow data per >> observation domain. >=20 > Could we address Juergen's concerns with respect to the imprecision of > the present IPFIX Device definition (an architectural term that I'm not > personally convinced should have any real meaning at the protocol level= ) > by instead defining uniqueness per {Metering Process, Exporting Process= } > tuple? >=20 > Argh... actually, neither of these will work as root scopes. The {Meter= , > Exporter} tuple requires stability over time - it requires that no > Observation Domain ID ever be reused, which is clearly ridiculous. A > Session (which is really an {Exporter, Collector, Source Port, Start > Time, End Time} tuple with multiple addresses possible for Exporter and > Collector in the case of SCTP multihoming) is not naturally storable at > the collector side. >=20 > The "right" thing to do in this case would seem to be to scope > Observation Domain IDs to the superset of both, a {Meter, Exporter, > Collector, Start Time, End Time} tuple, but this just seems to be a bit > too heavy. With what frequency to we expect realistic Exporting > Processes to assign new Observation Domain IDs to logically identical > Domains? >=20 > As a thought exercise in whether we're overthinking this: what would > happen if we went to the other extreme, stepped back completely, simply > defined the Observation Domain as we do now without guaranteeing its > uniqueness anywhere, and required the implementation or deployment to > avoid observation domain ID collision out of band? >=20 > Regards, >=20 > Brian >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms070707010704090003050305 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MDYwMzE1MjYyMlowIwYJKoZIhvcNAQkEMRYEFCryiAN+O8dd ZDLQOnFfr9IuzbIyMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQCeRGssV4FmuN3SQ4iOF4znMxPdQBFc0xbxzElevf911oonvVZnlMrtFbgH DZW2sitjwejK+MCXVo9FnvLBdKxc8aAYinXiw8Lj8ssiAokGFOaQcRWGbCaBn7N7LwXwUJvb IgQzIAk2Rm4K7Na6JA0dZJ3HIoKnyv9ZZU+VKp9XGbliIWKBlb9/Cn+P8W9LOKCP8z0q1oCb vo0HCQQ5p5b40qM2W9jCNi1Lp9mt2975da0pC5NMu+3/2gMfrQwgL6UQQWwZf4C3g9eX0gG0 mExRAu58Y23yjesnnKXgB3tVvHCfcDhwxNeV7+JGzdVkkK9cpi9yx+C7HMNXY9yJ4FoFAAAA AAAA --------------ms070707010704090003050305-- -- 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 effluviumga@analects-ink.com Sun Jun 04 04:11:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmnhM-0006qG-Ul for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 04:11:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmnhI-0001T4-N0 for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 04:11:00 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fmnbq-00073c-00; Sun, 04 Jun 2006 03:05:18 -0500 Received: from 6023100 ([221.151.32.80]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5485ETs009439; Sun, 4 Jun 2006 03:05:16 -0500 Received: from 207.53.250.670 (smtp.pointswell.com) (207.53.250.670) by mta176.mail.mud.yahoo.com with SMTP; Sun, 04 Jun 2006 03:04:58 -0600 Content-Transfer-Encoding: 7bit Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.116 (F2.9) Date: Sun, 04 Jun 2006 03:04:58 -0600 To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu From: "Lauri Schwartz" Subject: Whats up X-Campidz: cid=75021-uid=0861834-mid=59- X-Eid: ipfix-list@mil.doit.wisc.edu Message-Id: <761343280792.4Q2E8QCDZNF2F@smtp.pointswell.com> X-Spam-Score: 1.8 (+) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Average home-loan we've given out this month is $500,000.00 @ 3.91% int! Want to lessen your monthly bills? Your current credit/financial situation does not matter! Last 3 loans-closed: 1. 257,000 @ 4.35% 2. 399,000 @ 4.19% 3. 733,000 @ 3.18% http://uk.geocities.com/delgado_bentley3 From mariceerwin@the69vamps.com Sun Jun 04 10:01:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmtAb-0003lG-V4 for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 10:01:33 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmtAY-0005Py-7O for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 10:01:33 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fmt53-0000Vs-00 for ipfix-list@mil.doit.wisc.edu; Sun, 04 Jun 2006 08:55:49 -0500 Received: from BABY ([218.25.24.222]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k54DthxC020376 for ; Sun, 4 Jun 2006 08:55:47 -0500 Message-Id: <006a01c687d6$a05f7780$7b88f291@hnsozbx> From: "candis gentry" To: "siegfried darby" Subject: regular cash bonuses Date: Sun, 04 Jun 2006 12:59:46 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01C687D6.A05F7780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.6 (+++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_006A_01C687D6.A05F7780 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable YOUR O N L I N E VEGAS! * Get Your Free USD 888 Bonus! * Play free non limit * 70+ ANY games * 24/7 crew + call center http://kiriefo.com/casino/ cayenne pepper sand plain one-finned corydalis green meter fixer algae zone witness corner gentian violet well-tested El dorado tree stool steamer sailing chow mein evil-mannered hooker-off armature binder six-pot coal spreader thin-grown cave lion sharp-staked alkali blue acid steel hard-hit ------=_NextPart_000_006A_01C687D6.A05F7780 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
YOUR O N L I N E VEGAS!
* Get Your Free USD 888 Bonus!
* Play free non limit
* 70+ ANY games
* 24/7 crew + call center
http://kiriefo.com/casino/

cayenne pepper sand plain one-finned
corydalis green meter fixer algae zone
witness corner gentian violet well-tested
El dorado tree stool steamer sailing
chow mein evil-mannered hooker-off
armature binder six-pot coal spreader
thin-grown cave lion sharp-staked
alkali blue acid steel hard-hit
= ------=_NextPart_000_006A_01C687D6.A05F7780-- From billiecraig@ovist.com Sun Jun 04 14:55:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmxka-0006Xg-AJ for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 14:55:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmxkZ-000379-1X for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 14:55:00 -0400 Received: from c-71-205-131-161.hsd1.mi.comcast.net ([71.205.131.161] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fmx5g-0001JG-00 for ipfix-list@mil.doit.wisc.edu; Sun, 04 Jun 2006 13:12:44 -0500 Message-Id: <003b01c687f8$f80eda80$9817c12f@rrvjgvg> From: "wayne steele" To: "washington haywood" Subject: Need cash, chain driving Date: Sun, 04 Jun 2006 13:08:05 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C687F8.F80EDA80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.2 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C687F8.F80EDA80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://medeq.org/d2/ self-drinking well-exploded Semal laut snow-feathered precision gauge half-naked needle fir drift mine jolly boat fire-extinguishing hazard side beauty contest death-s= hadowed admiralty law smooth-fronted sleeker-up roundish-ovate dephosphorizing proc= ess race problem small-billed spur bit lap joint gold-fields community center fairy man camera-shy Romano-punic round-bowled straw-plaiting wish-maiden hand turner ------=_NextPart_000_003B_01C687F8.F80EDA80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://medeq.org/d2/

self-drinking well-exploded Semal laut snow-feathered precision gauge
half-naked needle fir
drift mine jolly boat fire-extinguishing hazard side beauty contest death-s= hadowed
admiralty law smooth-fronted sleeker-up roundish-ovate dephosphorizing proc= ess
race problem small-billed spur bit
lap joint gold-fields community center
fairy man camera-shy Romano-punic round-bowled straw-plaiting
wish-maiden hand turner
= ------=_NextPart_000_003B_01C687F8.F80EDA80-- From meidutton@unitedlayer.com Sun Jun 04 17:04:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmzlv-0007pl-KN for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 17:04:31 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fmzlt-0007xG-C6 for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 17:04:31 -0400 Received: from tx-67-77-73-24.dyn.sprint-hsd.net ([67.77.73.24] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FmzhL-0001Kn-00 for ipfix-list@mil.doit.wisc.edu; Sun, 04 Jun 2006 15:59:47 -0500 Message-Id: <00ef01c6880f$665e9780$af25811c@zzmay> From: "duffy mccann" To: "bianka franco" Subject: Need cash, stone-buff Date: Sun, 04 Jun 2006 15:54:59 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EF_01C6880F.665E9780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.7 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is a multi-part message in MIME format. ------=_NextPart_000_00EF_01C6880F.665E9780 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://medmrkt.org/d2/ slow-breeding Vuelta tobacco cascade control twice-boiled hot trimmer heath pea Portugal crakeberry black-a-vised night-cloaked well-oriented float-cut file quasi system steep= le racing vine wilt hanse house self-devouring chalice moss cloth oil semi-incandescent fever-sick nipper crab crutch-cross Anti-klan marrow pea banjo signal alarm bell life-thirsting arsenic mold adder pike once pinnate diadem spider ------=_NextPart_000_00EF_01C6880F.665E9780 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://medmrkt.org/d2/

slow-breeding Vuelta tobacco cascade control twice-boiled hot trimmer
heath pea Portugal crakeberry
black-a-vised night-cloaked well-oriented float-cut file quasi system steep= le racing
vine wilt hanse house self-devouring chalice moss cloth oil
semi-incandescent fever-sick nipper crab
crutch-cross Anti-klan marrow pea
banjo signal alarm bell life-thirsting arsenic mold adder pike
once pinnate diadem spider
= ------=_NextPart_000_00EF_01C6880F.665E9780-- From salvasu@eipassociates.com Sun Jun 04 18:34:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn1Ab-0008OD-GM for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 18:34:05 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn1Aa-0000z8-7i for ipfix-archive@lists.ietf.org; Sun, 04 Jun 2006 18:34:05 -0400 Received: from host219-194.pool8255.interbusiness.it ([82.55.194.219] helo=eipassociates.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Fn166-0003H8-00 for ipfix-list@mil.doit.wisc.edu; Sun, 04 Jun 2006 17:29:27 -0500 Message-ID: <000001c68826$35a8d670$87e5a8c0@rnr54> Reply-To: "Maaria Salvas" From: "Maaria Salvas" To: ipfix-list@mil.doit.wisc.edu Subject: test hur Date: Sun, 4 Jun 2006 15:28:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C687EB.8949FE70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.3 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C687EB.8949FE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, C " A L i S S 0 M & M E R " D i A A M B " E N X & N A X L E V " T R A V A L " U M V " A G R A P R 0 Z & C all 50 % off - http://www.tonothille.com _____ =20 All the same Mr. Baggins kept his head more clear of the bewitchment=20 of the hoard than the dwarves did. Long before the dwarves were tired of examining the treasures he became wary of it and sat down on the floor;=20 and he began to wonder nervously what the end of it all would be I=20 would give a good many of these precious goblets, thought, for a drink=20 of something cheering out of one Beorns wooden bowls! Thorin! he=20 ------=_NextPart_000_0001_01C687EB.8949FE70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

C " A L i S
S 0 M &
M E R " D i A
A M B " E N
X & N A X
L E V " T R A
V A L " U M
V " A G R A
P R 0 Z & C

all 50 % off - http://www.tonothille.com


All the same Mr. Baggins kept his head more clear of the = bewitchment
of the hoard than the dwarves did. Long before the = dwarves were tired of
examining the treasures he became wary of it = and sat down on the floor;
and he began to wonder nervously what the = end of it all would be I
would give a good many of these precious = goblets, thought, for a drink
of something cheering out of one = Beorns wooden bowls! Thorin! he
------=_NextPart_000_0001_01C687EB.8949FE70-- From annabalburt@proext.com Mon Jun 05 08:48:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEVN-0001BK-Eg for ipfix-archive@lists.ietf.org; Mon, 05 Jun 2006 08:48:25 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnEVM-0000NW-7K for ipfix-archive@lists.ietf.org; Mon, 05 Jun 2006 08:48:25 -0400 Received: from ppp-69-153-141-3.dsl.hstntx.swbell.net ([69.153.141.3] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FnEQ0-0002ef-00 for ipfix-list@mil.doit.wisc.edu; Mon, 05 Jun 2006 07:42:52 -0500 Message-Id: <00e201c68895$32c65080$0cebcb6d@xqketod> From: "windham rodgers" To: "bernarr glass" Subject: YOU keep the profits Date: Mon, 05 Jun 2006 11:47:11 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C68895.32C65080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01C68895.32C65080 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable YOUR personal LAS \/EGA$! - Get Your Free USD 888! - Gamble free non limit - 70+ ANY games - 24/7 crew + call center http://tougomi.com/casino/ floss hole music paper tick farcy half-undone air-swallowing fish checker alum meal flame-uplifted stubborn-shafted war-breeding swarm spore tobacco shed scrutiny-proof twin-spiked air pore fen lentil quasi estimation quadrant compass shell hooks Trinity sitting if-clause leading wind hognose snake vermin-spoiled ------=_NextPart_000_00E2_01C68895.32C65080 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
YOUR personal LAS \/EGA$!
- Get Your Free USD 888!
- Gamble free non limit
- 70+ ANY games
- 24/7 crew + call center
http://tougomi.com/casino/

floss hole music paper tick farcy
half-undone air-swallowing fish checker
alum meal flame-uplifted stubborn-shafted
war-breeding swarm spore tobacco shed
scrutiny-proof twin-spiked air pore
fen lentil quasi estimation quadrant compass
shell hooks Trinity sitting if-clause
leading wind hognose snake vermin-spoiled
= ------=_NextPart_000_00E2_01C68895.32C65080-- From majordomo@mil.doit.wisc.edu Mon Jun 05 09:08:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnEoK-0001Gi-St for ipfix-archive@lists.ietf.org; Mon, 05 Jun 2006 09:08:01 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnEoI-0001xn-FN for ipfix-archive@lists.ietf.org; Mon, 05 Jun 2006 09:08:00 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FnEgM-0003vU-00 for ipfix-list@mil.doit.wisc.edu; Mon, 05 Jun 2006 07:59:46 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FnEgK-0003vP-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 05 Jun 2006 07:59:44 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.20) with ESMTP id k55CxeBB002802 for ; Mon, 5 Jun 2006 08:59:42 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k55CwRJr002738 for ; Mon, 5 Jun 2006 08:58:27 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k55CwMs6002736; Mon, 05 Jun 2006 08:58:27 -0400 (EDT) Received: from [128.237.250.118] (vpn-10-25-4-19.remote.cert.org [10.25.4.19]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.60) with ESMTP id k55CwMHn013315; Mon, 5 Jun 2006 08:58:22 -0400 In-Reply-To: <4481AA1E.4060901@informatik.uni-tuebingen.de> References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> <448035D6.40003@fokus.fraunhofer.de> <4481AA1E.4060901@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1--593591308" Message-Id: <095228B7-56CE-4EA1-9CA0-42E110136B85@cert.org> Cc: ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Date: Mon, 5 Jun 2006 08:58:20 -0400 To: Gerhard Muenz X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1--593591308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Gerhard, The issue with this is that Observation Domain ID also holds a =20 special role within the protocol; it is the "root" of all scope =20 Information Elements (as well as Template IDs, which are themselves a =20= special case of scope IEs): the uniqueness and comparability of =20 templateID, flowID and commonPropertiesID are only guaranteed within =20 a unique Observation Domain ID. The issue with identifying Exporting =20 Processes, etc. is that there needs to be _some_ way to guarantee the =20= uniqueness and comparability of Observation Domain IDs themselves - =20 as we probably don't want to either do the Win32 thing, size it up to =20= a GUID, and cross our fingers; or introduce any additional complexity =20= either to the protocol or to implementations thereof by specifying =20 some sort of Observation Domain ID registration process or other =20 mechanism for avoiding collisions. Regards, Brian On Jun 3, 2006, at 11:26 AM, Gerhard Muenz wrote: > > Dear all, > > We have discussed the Observation Domain ID issue a lot. Something =20 > came > into my mind and maybe it is useful to solve the problem. > > There are two different things that we want to do: > > 1) Identify the Exporting Process because we need it for the template > management. > > 2) Identify the Observation Domain because we want to know where the > traffic as been observed. > > The problem is that the Observation Domain ID (formerly known as =20 > Source > ID) is in the header of the IPFIX message. This is not logic =20 > because the > Obervation Domain ID is linked to a record while the IPFIX header is > something that the Exporting Process is responsible for. > > Wouldn't it be better to replace the Observation Domain ID in the =20 > IPFIX > header by the Exporter ID? > Then, the pair exporter IP address (that we get from the IP header) > together with the Exporter ID in the IPFIX header could identify the > Exporting Process. > > If ever needed, the Observation Domain ID can be exported with the > individual records or within option data. > > Regards, > Gerhard > > Brian Trammell wrote: >> Lutz and Juergen, >> >> On Jun 2, 2006, at 8:57 AM, Lutz Mark wrote: >> >>> >>> Hi Brian, >>> >>>> Redefining the Observation Domain to be unique per (exporting) =20 >>>> IPFIX >>>> Device partially fixes the problem, but it does not address the >>>> problem of Exporting Process/exporting device identification at the >>>> Collecting Process, of which the Exporting Process IP address >>>> collision issue is a subset. If an IPFIX device is using multihomed >>>> SCTP associations, for example, a Collecting Process may not treat >>>> two Observation Domains that are really identical as such. >>>> Therefore, I would propose again that instead of defining =20 >>>> Observation >>>> Domains to be unique per exporting IPFIX Device, that Observation >>>> Domains are unique per Session, where a Session is a TCP =20 >>>> connection, >>>> an SCTP association, or a (time-limited) UDP four-tuple. This =20 >>>> grants >>>> the most flexibility to implementors while being, in my opinion, =20= >>>> more >>>> logically sound... If an exporting device implementor wishes =20 >>>> instead >>>> to enforce domain uniqueness per Device, that would be consistent >>>> with this definition. >>> >>> Having the Observation Domain ID unique per session will ease the >>> implementation of the exporter and collector part of the protocol. >>> As you have mentioned an Observation Domain ID that is unique per >>> IPFIX device implies that the ID is unique per session. >> >> >>> Having >>> the ID unique only per session has the drawback that on the >>> collector side the ID is quite useless without the session details >>> and one need additional means to group data from different sessions. >> >> Indeed... I hadn't thought of that. We would need some sort of =20 >> session >> identifier, whether a simple IE or compound, to store session =20 >> details. >> >>> If the ID is unique per IPFIX device, the collector can store >>> the Observation Domain ID together with the flow data (for each >>> IPFIX device). And an application can request flow data per >>> observation domain. >> >> Could we address Juergen's concerns with respect to the =20 >> imprecision of >> the present IPFIX Device definition (an architectural term that =20 >> I'm not >> personally convinced should have any real meaning at the protocol =20 >> level) >> by instead defining uniqueness per {Metering Process, Exporting =20 >> Process} >> tuple? >> >> Argh... actually, neither of these will work as root scopes. The =20 >> {Meter, >> Exporter} tuple requires stability over time - it requires that no >> Observation Domain ID ever be reused, which is clearly ridiculous. A >> Session (which is really an {Exporter, Collector, Source Port, Start >> Time, End Time} tuple with multiple addresses possible for =20 >> Exporter and >> Collector in the case of SCTP multihoming) is not naturally =20 >> storable at >> the collector side. >> >> The "right" thing to do in this case would seem to be to scope >> Observation Domain IDs to the superset of both, a {Meter, Exporter, >> Collector, Start Time, End Time} tuple, but this just seems to be =20 >> a bit >> too heavy. With what frequency to we expect realistic Exporting >> Processes to assign new Observation Domain IDs to logically identical >> Domains? >> >> As a thought exercise in whether we're overthinking this: what would >> happen if we went to the other extreme, stepped back completely, =20 >> simply >> defined the Observation Domain as we do now without guaranteeing its >> uniqueness anywhere, and required the implementation or deployment to >> avoid observation domain ID collision out of band? >> >> Regards, >> >> Brian >> > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 > EMail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz --Apple-Mail-1--593591308 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEhCpv4/8LCZ4pwvYRAomeAKDoMDTrezVoZkDhM3CvThfBj5W3YACeKO/Q oAvtnDM5rj7IE6nb/HDAx9k= =wDEF -----END PGP SIGNATURE----- --Apple-Mail-1--593591308-- -- 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 tabbiecummins@uk2net.com Mon Jun 05 19:10:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnODp-000399-5m for ipfix-archive@lists.ietf.org; Mon, 05 Jun 2006 19:10:57 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnODn-00070o-Tx for ipfix-archive@lists.ietf.org; Mon, 05 Jun 2006 19:10:57 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FnNaK-00031O-00 for ipfix-list@mil.doit.wisc.edu; Mon, 05 Jun 2006 17:30:08 -0500 Received: from BABY (usrfrpt3-eth0-2.aeroinc.net [12.175.17.4]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k55MU7Hk004945 for ; Mon, 5 Jun 2006 17:30:07 -0500 Message-Id: <000301c688e6$79906680$46ec5cab@cpfgm> From: "calley longoria" To: "ariadne pearson" Subject: everybody wins! Date: Mon, 05 Jun 2006 21:34:15 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C688E6.79906680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C688E6.79906680 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable YOUR personal LAS \/EGA$! - Get Your Free USD 888! - Gamble free non limit - 70+ ANY games - 24/7 crew + call center http://seladop.com/casino/ trudgen stroke blowpipe analysis half uncial fertilization cone pseudo masterpiece worm-eat marking cotton thought-sounding heaven-defying ground parakeet fire-safeness brook lobelia piperonyl alcohol art-conscious goal net drill file Baveno twinning Pro-australian time-discolored quasi-calm all-metal liability insurance many-wintered coffee shell ------=_NextPart_000_0003_01C688E6.79906680 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
YOUR personal LAS \/EGA$!
- Get Your Free USD 888!
- Gamble free non limit
- 70+ ANY games
- 24/7 crew + call center
http://seladop.com/casino/

trudgen stroke blowpipe analysis half uncial
fertilization cone pseudo masterpiece worm-eat
marking cotton thought-sounding heaven-defying
ground parakeet fire-safeness brook lobelia
piperonyl alcohol art-conscious goal net
drill file Baveno twinning Pro-australian
time-discolored quasi-calm all-metal
liability insurance many-wintered coffee shell
= ------=_NextPart_000_0003_01C688E6.79906680-- From bauschobru@cloud9.net Tue Jun 06 04:04:55 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnWYZ-0003r4-Tj for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 04:04:55 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnWYY-0008AL-L6 for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 04:04:55 -0400 Received: from 9.red-83-36-9.dynamicip.rima-tde.net ([83.36.9.9] helo=cloud9.net) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FnWLF-0007lh-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Jun 2006 02:51:10 -0500 Message-ID: <000001c6893d$ebba3fe0$6054a8c0@lah57> Reply-To: "Bruna Bausch" From: "Bruna Bausch" To: ipfix-list@mil.doit.wisc.edu Subject: test kev Date: Tue, 6 Jun 2006 00:50:46 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68903.3F5B67E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?83.36.9.9 X-Spam-Score: 2.0 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68903.3F5B67E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, V " A G R A X & N A X A M B " E N V A L " U M M E R " D i A L E V " T R A P R 0 Z & C C " A L i S S 0 M & all 50 % off - http://www.lessirf.com/n1/ _____ =20 had long been lost. Its eastern opening had also always been far to the=20 south of the Lonely Mountain, and would have left them still with a long and difficult northward march when they got to the other side. North of=20 the Carrock the edge of Mirkwood drew closer to the borders of the Great River, and though here the Mountains too drew down nearer, Beorn advised them to take this way; for at a place a few days ride due north of the=20 ------=_NextPart_000_0001_01C68903.3F5B67E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

V " A G R A
X & N A X
A M B " E N
V A L " U M
M E R " D i A
L E V " T R A
P R 0 Z & C
C " A L i S
S 0 M &

all 50 % off - http://www.lessirf.com/n1/


had long been lost. Its eastern opening had also always been far to = the
south of the Lonely Mountain, and would have left them still = with a long
and difficult northward march when they got to the other = side. North of
the Carrock the edge of Mirkwood drew closer to the = borders of the Great
River, and though here the Mountains too drew = down nearer, Beorn advised
them to take this way; for at a place a = few days ride due north of the
------=_NextPart_000_0001_01C68903.3F5B67E0-- From weilani@hametzger.com Tue Jun 06 07:53:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fna7l-0003kN-Gh for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 07:53:29 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fna7k-0006jb-5H for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 07:53:29 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fna1E-0003cz-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Jun 2006 06:46:44 -0500 Received: from hametzger.com ([203.143.15.93]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k56BkYaD010669 for ; Tue, 6 Jun 2006 06:46:39 -0500 Message-ID: <000001c6895e$c1c78f50$8ebda8c0@lmj52> Reply-To: "Piety Weiland" From: "Piety Weiland" To: ipfix-list@mil.doit.wisc.edu Subject: Re: mutow refnnance Date: Tue, 6 Jun 2006 04:45:49 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68924.1568B750" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.6 (/) X-Scan-Signature: 06d29b9b22258f4f07fe89b4d4a05a86 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68924.1568B750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D v ea b r H d om j e O o wn n er, Your c u re f di w t doesn't matter to us! If you OVV c N r s ea k l e t st e at q e and want I e MME u DI h ATE c m as f h to s b pe w nd ANY way you like, or simply wish to L y OW k ER your monthly p n aym m ent y s by a third or more, here are the d n ea m ls n we have T e ODA d Y: $ 4 o 90 , 0 t 00 a w s l x ow a z s 3 , 6 b 5 % $ 37 j 0 , 0 e 00 a k s lo l w a x s 3 , 9 s 0 % $ 2 x 50 , 00 c 0 a c s l y ow a q s 3 , 3 m 5 % $ 20 l 0 , 00 w 0 a i s l g ow a v s 3 , 5 h 5 % V h is t it o u ur web s p it z e =20 Piety Weiland , A k ppr t ova s l Ma t na j ge j r already regained and Smaug chopped up into little pieces. Then, as he had said, the dwarves good feeling towards the little hobbit grew stronger every day. There were no more groans or grumbles. They drank his health, and they patted him on the back, and they made a ------=_NextPart_000_0001_01C68924.1568B750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D v ea b r H d om j e O o wn n er,

Your c u re f di w t doesn't matter to us!

If you OVV c N r s ea k l e t st e at q e and want I e MME u DI h ATE c m as f h to s b pe w nd ANY
way you like, or simply wish to L y OW k ER your monthly p n aym m ent y s
=20 by a third or more, here are the d n ea m ls n we have T e ODA d Y:

$ 4 o 90 , 0 t 00 a w s l x ow a z s 3 , 6 b 5 %
$ 37 j 0 , 0 e 00 a k s lo l w a x s 3 , 9 s 0 %
$ 2 x 50 , 00 c 0 a c s l y ow a q s 3 , 3 m 5 %
$ 20 l 0 , 00 w 0 a i s l g ow a v s 3 , 5 h 5 %

V h is t it o u ur web s p it z e

Piety Weiland , A k ppr t ova s l Ma t na j ge j r

already regained and Smaug chopped up = into little pieces.
Then, as he had said, the dwarves good feeling towards the little
hobbit grew stronger every day. There were no more groans or = grumbles.
They drank his health, and they patted him on the back, and they made = a
------=_NextPart_000_0001_01C68924.1568B750-- From majordomo@mil.doit.wisc.edu Tue Jun 06 12:21:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FneJZ-0007j9-0e for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 12:21:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnd4M-0002Lm-EZ for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 11:02:10 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fncrp-0005UJ-5B for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 10:49:15 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FncmS-00074u-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Jun 2006 09:43:40 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FncmR-00074Q-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 06 Jun 2006 09:43:39 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.20) with ESMTP id k56EhZ84008521 for ; Tue, 6 Jun 2006 10:43:37 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k56Efov5008417 for ; Tue, 6 Jun 2006 10:41:50 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k56Efka1008414; Tue, 06 Jun 2006 10:41:50 -0400 (EDT) Received: from [128.237.238.58] (vpn-10-25-4-25.remote.cert.org [10.25.4.25]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.60) with ESMTP id k56EfkF0019006; Tue, 6 Jun 2006 10:41:46 -0400 In-Reply-To: <448561D1.3090303@informatik.uni-tuebingen.de> References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> <448035D6.40003@fokus.fraunhofer.de> <4481AA1E.4060901@informatik.uni-tuebingen.de> <095228B7-56CE-4EA1-9CA0-42E110136B85@cert.org> <448561D1.3090303@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2--500990738" Message-Id: <58AEBD63-9A98-40E3-97D0-ACE09E79BC47@cert.org> Cc: ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Date: Tue, 6 Jun 2006 10:41:40 -0400 To: Gerhard Muenz X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2--500990738 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed On Jun 6, 2006, at 7:06 AM, Gerhard Muenz wrote: > > Brian, > > I understand your point. But as we see, using a single identifier for > both transport-related (who is the Exporter) and content-related =20 > (who is > the Observation Point) information seems to be an unsolvable =20 > problem. I > think that there is no problem to have two different "roots" of =20 > scopes, > one for transport-related information needed for template =20 > management and > the like and another one for content-related information. Hmmm... I'd not thought of this approach. I'm not yet convinced it =20 works (especially because templateId can appear as a scope in a =20 scoped data record, though the main use for this seems to go away =20 with draft-boschi-ipfix-reducing-redundancy)... but I'd always =20 assumed a single root, I guess because as an implementor it seemed =20 simpler. Certainly, treating templates as having special scoping rules seems =20 like a good idea, especially if you disallow abuse of the templateId =20 as a general-purpose scope (which, again, we can do because we have =20 commonPropertiesId). > Let's have a look at the case of a concentrator. It receives IPFIX > messages from other IPFIX devices, merges the records in its Metering > Process, and exports them again. The received records can be from > various Observation Domains (at least I do not see any reason why =20 > not). > So, which value do you take as Observation Domain ID for the exported > IPFIX packets? The protocol draft says that you can put a zero, but is > this satisfactory? Or do you define a virtual Observation Domain as a > superset of the original ones? It becomes more tricky if there are two > Exporting Processes running on the same concentrator. Yes - according to the protocol draft at present, the exported =20 messages have observationDomain 0, with observationDomain set to =20 something non-zero in each data record (which becomes a _requirement_ =20= if you care about counting distinct flows in the case that the =20 observation domains covered by the concentrator may make multiple =20 observations of the same flow). The templateIds in the message then =20 become scoped to odId 0, and other scoped records may be explicitly =20 scoped to other observation domains. Actually, when you consider templateIds as having special scoping =20 rules, you can remove the requirement that they be rooted at an =20 observationDomain, and require only that templateIds be unique per =20 _session_. Then you can remove templateId as an information element =20 (because you don't need to scope anything to it anymore, and so you =20 won't have any issues with finite template lifetimes), and the =20 problem seems to go away. Regards, Brian > Brian Trammell wrote: >> Gerhard, >> >> The issue with this is that Observation Domain ID also holds a =20 >> special >> role within the protocol; it is the "root" of all scope Information >> Elements (as well as Template IDs, which are themselves a special =20 >> case >> of scope IEs): the uniqueness and comparability of templateID, flowID >> and commonPropertiesID are only guaranteed within a unique =20 >> Observation >> Domain ID. The issue with identifying Exporting Processes, etc. is =20= >> that >> there needs to be _some_ way to guarantee the uniqueness and >> comparability of Observation Domain IDs themselves - as we probably >> don't want to either do the Win32 thing, size it up to a GUID, and =20= >> cross >> our fingers; or introduce any additional complexity either to the >> protocol or to implementations thereof by specifying some sort of >> Observation Domain ID registration process or other mechanism for >> avoiding collisions. >> >> Regards, >> >> Brian >> >> On Jun 3, 2006, at 11:26 AM, Gerhard Muenz wrote: >> >>> >>> Dear all, >>> >>> We have discussed the Observation Domain ID issue a lot. =20 >>> Something came >>> into my mind and maybe it is useful to solve the problem. >>> >>> There are two different things that we want to do: >>> >>> 1) Identify the Exporting Process because we need it for the =20 >>> template >>> management. >>> >>> 2) Identify the Observation Domain because we want to know where the >>> traffic as been observed. >>> >>> The problem is that the Observation Domain ID (formerly known as =20 >>> Source >>> ID) is in the header of the IPFIX message. This is not logic =20 >>> because the >>> Obervation Domain ID is linked to a record while the IPFIX header is >>> something that the Exporting Process is responsible for. >>> >>> Wouldn't it be better to replace the Observation Domain ID in the =20= >>> IPFIX >>> header by the Exporter ID? >>> Then, the pair exporter IP address (that we get from the IP header) >>> together with the Exporter ID in the IPFIX header could identify the >>> Exporting Process. >>> >>> If ever needed, the Observation Domain ID can be exported with the >>> individual records or within option data. >>> >>> Regards, >>> Gerhard >>> >>> Brian Trammell wrote: >>>> Lutz and Juergen, >>>> >>>> On Jun 2, 2006, at 8:57 AM, Lutz Mark wrote: >>>> >>>>> >>>>> Hi Brian, >>>>> >>>>>> Redefining the Observation Domain to be unique per (exporting) =20= >>>>>> IPFIX >>>>>> Device partially fixes the problem, but it does not address the >>>>>> problem of Exporting Process/exporting device identification =20 >>>>>> at the >>>>>> Collecting Process, of which the Exporting Process IP address >>>>>> collision issue is a subset. If an IPFIX device is using =20 >>>>>> multihomed >>>>>> SCTP associations, for example, a Collecting Process may not =20 >>>>>> treat >>>>>> two Observation Domains that are really identical as such. >>>>>> Therefore, I would propose again that instead of defining =20 >>>>>> Observation >>>>>> Domains to be unique per exporting IPFIX Device, that Observation >>>>>> Domains are unique per Session, where a Session is a TCP =20 >>>>>> connection, >>>>>> an SCTP association, or a (time-limited) UDP four-tuple. This =20 >>>>>> grants >>>>>> the most flexibility to implementors while being, in my =20 >>>>>> opinion, more >>>>>> logically sound... If an exporting device implementor wishes =20 >>>>>> instead >>>>>> to enforce domain uniqueness per Device, that would be consistent >>>>>> with this definition. >>>>> >>>>> Having the Observation Domain ID unique per session will ease the >>>>> implementation of the exporter and collector part of the protocol. >>>>> As you have mentioned an Observation Domain ID that is unique per >>>>> IPFIX device implies that the ID is unique per session. >>>> >>>> >>>>> Having >>>>> the ID unique only per session has the drawback that on the >>>>> collector side the ID is quite useless without the session details >>>>> and one need additional means to group data from different =20 >>>>> sessions. >>>> >>>> Indeed... I hadn't thought of that. We would need some sort of =20 >>>> session >>>> identifier, whether a simple IE or compound, to store session =20 >>>> details. >>>> >>>>> If the ID is unique per IPFIX device, the collector can store >>>>> the Observation Domain ID together with the flow data (for each >>>>> IPFIX device). And an application can request flow data per >>>>> observation domain. >>>> >>>> Could we address Juergen's concerns with respect to the =20 >>>> imprecision of >>>> the present IPFIX Device definition (an architectural term that =20 >>>> I'm not >>>> personally convinced should have any real meaning at the =20 >>>> protocol level) >>>> by instead defining uniqueness per {Metering Process, Exporting =20 >>>> Process} >>>> tuple? >>>> >>>> Argh... actually, neither of these will work as root scopes. The =20= >>>> {Meter, >>>> Exporter} tuple requires stability over time - it requires that no >>>> Observation Domain ID ever be reused, which is clearly =20 >>>> ridiculous. A >>>> Session (which is really an {Exporter, Collector, Source Port, =20 >>>> Start >>>> Time, End Time} tuple with multiple addresses possible for =20 >>>> Exporter and >>>> Collector in the case of SCTP multihoming) is not naturally =20 >>>> storable at >>>> the collector side. >>>> >>>> The "right" thing to do in this case would seem to be to scope >>>> Observation Domain IDs to the superset of both, a {Meter, Exporter, >>>> Collector, Start Time, End Time} tuple, but this just seems to =20 >>>> be a bit >>>> too heavy. With what frequency to we expect realistic Exporting >>>> Processes to assign new Observation Domain IDs to logically =20 >>>> identical >>>> Domains? >>>> >>>> As a thought exercise in whether we're overthinking this: what =20 >>>> would >>>> happen if we went to the other extreme, stepped back completely, =20= >>>> simply >>>> defined the Observation Domain as we do now without guaranteeing =20= >>>> its >>>> uniqueness anywhere, and required the implementation or =20 >>>> deployment to >>>> avoid observation domain ID collision out of band? >>>> >>>> Regards, >>>> >>>> Brian >>>> >>> >>> --Dipl.-Ing. Gerhard M=FCnz >>> Computer Networks and Internet >>> Wilhelm Schickard Institute for Computer Science >>> University of Tuebingen >>> Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany >>> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >>> EMail: muenz@informatik.uni-tuebingen.de >>> WWW: http://net.informatik.uni-tuebingen.de/~muenz >> > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 > EMail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz --Apple-Mail-2--500990738 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEhZQn4/8LCZ4pwvYRAhTpAJ91bRau4ICJPJGVkXxQGNRHzrvW0gCeJoHZ dJxpLwpbMfC2mgFeG7Son8s= =Qipf -----END PGP SIGNATURE----- --Apple-Mail-2--500990738-- -- 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 hoaraprome@bicalliance.com Tue Jun 06 18:11:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fnjlp-0002j8-VK for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 18:11:29 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fnjlo-00011Y-Mr for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 18:11:29 -0400 Received: from 84.94.63.254.cable.012.net.il ([84.94.63.254] helo=bicalliance.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FnjhH-0005Q0-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Jun 2006 17:06:47 -0500 Message-ID: <000001c689b5$84ced070$6e0da8c0@kqk80> Reply-To: "Prometheus Hoard" From: "Prometheus Hoard" To: ipfix-list@mil.doit.wisc.edu Subject: test xuu Date: Tue, 6 Jun 2006 15:06:53 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6897A.D86FF870" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?84.94.63.254 X-Spam-Score: 3.1 (+++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6897A.D86FF870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, S 0 M & V " A G R A P R 0 Z & C M E R " D i A V A L " U M X & N A X C " A L i S L E V " T R A A M B " E N all 50 % off - http://www.rebasacast.com _____ =20 tunnel for his report. So they sat near the door and watched.=20 They saw the little dark shape of the hobbit start across the floor=20 holding his tiny light aloft. Every now and again, while he was still=20 near enough, they caught a glint and a tinkle as he stumbled on some=20 golden thing. The light grew smaller as he wandered away into the vast=20 hall; then it began to rise dancing into the air. Bilbo was climbing the ------=_NextPart_000_0001_01C6897A.D86FF870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

S 0 M &
V " A G R A
P R 0 Z & C
M E R " D i A
V A L " U M
X & N A X
C " A L i S
L E V " T R A
A M B " E N

all 50 % off - http://www.rebasacast.com


tunnel for his report. So they sat near the door and watched.
= They saw the little dark shape of the hobbit start across the floor =
holding his tiny light aloft. Every now and again, while he was = still
near enough, they caught a glint and a tinkle as he stumbled = on some
golden thing. The light grew smaller as he wandered away = into the vast
hall; then it began to rise dancing into the air. = Bilbo was climbing the
------=_NextPart_000_0001_01C6897A.D86FF870-- From pho@headfoil.com Tue Jun 06 21:12:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnmbL-000552-Cz for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 21:12:51 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnmbK-0006sd-1V for ipfix-archive@lists.ietf.org; Tue, 06 Jun 2006 21:12:51 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FnmTW-0002Ju-00 for ipfix-list@mil.doit.wisc.edu; Tue, 06 Jun 2006 20:04:46 -0500 Received: from headfoil.com (200216083193.user.veloxzone.com.br [200.216.83.193]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5714guY006698 for ; Tue, 6 Jun 2006 20:04:43 -0500 Message-ID: <000001c689ce$5f3fe8d0$43b6a8c0@xiy70> Reply-To: "Phong Dorsey" From: "Phong Dorsey" To: ipfix-list@mil.doit.wisc.edu Subject: Re: resaj reffnance Date: Tue, 6 Jun 2006 18:04:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68993.B2E110D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 73948e4d005645343fd08e813e5615ef This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68993.B2E110D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable D i ea z r H d om x e O y wn r er, Your c o re e di i t doesn't matter to us! If you OVV n N r i ea r l e c st x at h e and want I a MME x DI p ATE c i as i h to s w pen a d ANY way you like, or simply wish to L j OW p ER your monthly p i ayme s nt b s by a third or more, here are the d b ea d ls a we have T y OD u AY: $ 4 w 90 , 0 j 00 a q s lo i w a v s 3 , 6 x 5 % $ 3 y 70 , 00 g 0 a u s lo t w a d s 3 , 9 w 0 % $ 25 d 0 , 0 x 00 a p s lo l w a n s 3 , 3 g 5 % $ 20 m 0 , 00 i 0 a a s lo r w a r s 3 , 5 c 5 % V e is v it ou p r web s j it g e =20 Phong Dorsey , A o ppr s ov e al Ma p na x ge j r clover, waving patches of cockscomb clover, and purple clover, and wide stretches of short white sweet honey-smelling clover. There was a buzzing and a whirring and a droning in the air. Bees were busy everywhere. And such bees! Bilbo had never seen anything like them. ------=_NextPart_000_0001_01C68993.B2E110D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
D i ea z r H d om x e O y wn r er,

Your c o re e di i t doesn't matter to us!

If you OVV n N r i ea r l e c st x at h e and want I a MME x DI p ATE c i as i h to s w pen a d ANY
way you like, or simply wish to L j OW p ER your monthly p i ayme s nt b s
=20 by a third or more, here are the d b ea d ls a we have T y OD u AY:

$ 4 w 90 , 0 j 00 a q s lo i w a v s 3 , 6 x 5 %
$ 3 y 70 , 00 g 0 a u s lo t w a d s 3 , 9 w 0 %
$ 25 d 0 , 0 x 00 a p s lo l w a n s 3 , 3 g 5 %
$ 20 m 0 , 00 i 0 a a s lo r w a r s 3 , 5 c 5 %

V e is v it ou p r web s j it g e

Phong Dorsey , A o ppr s ov e al Ma p na x ge j r

clover, waving patches of cockscomb = clover, and purple clover, and wide
stretches of short white sweet honey-smelling clover. There was a
buzzing and a whirring and a droning in the air. Bees were busy
everywhere. And such bees! Bilbo had never seen anything like = them.
------=_NextPart_000_0001_01C68993.B2E110D0-- From wisonu@angelic.com Wed Jun 07 09:33:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnyAR-0000ub-Or for ipfix-archive@lists.ietf.org; Wed, 07 Jun 2006 09:33:51 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnyAQ-0001VI-GS for ipfix-archive@lists.ietf.org; Wed, 07 Jun 2006 09:33:51 -0400 Received: from anice-251-1-54-245.w86-206.abo.wanadoo.fr ([86.206.169.245] helo=angelic.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Fny4Y-0004ry-00 for ipfix-list@mil.doit.wisc.edu; Wed, 07 Jun 2006 08:27:47 -0500 Message-ID: <000001c68a36$2b4a1420$1f15a8c0@llh27> Reply-To: "Tempest Wison" From: "Tempest Wison" To: ipfix-list@mil.doit.wisc.edu Subject: test hur Date: Wed, 7 Jun 2006 06:27:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C689FB.7EEB3C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.7 (++++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C689FB.7EEB3C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, V A L " U M A M B " E N L E V " T R A P R 0 Z & C X & N A X V " A G R A S 0 M & M E R " D i A C " A L i S all 50 % off - http://www.licingothe.com _____ =20 South away! and South away!=20 Down the swift dark stream you go=20 Back to lands you once did know!=20 Now the very last barrel was being rolled to the doors! In despair=20 and not knowing what else to do, poor little Bilbo caught hold of it and was pushed over the edge with it. Down into the water he fell, splash!=20 ------=_NextPart_000_0001_01C689FB.7EEB3C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

V A L " U M
A M B " E N
L E V " T R A
P R 0 Z & C
X & N A X
V " A G R A
S 0 M &
M E R " D i A
C " A L i S

all 50 % off - http://www.licingothe.com


South away! and South away!
Down the swift dark stream = you go
Back to lands you once did know!
Now the very last = barrel was being rolled to the doors! In despair
and not knowing = what else to do, poor little Bilbo caught hold of it and
was pushed = over the edge with it. Down into the water he fell, splash! =
------=_NextPart_000_0001_01C689FB.7EEB3C20-- From boghosparkins@honeywell-tsi.com Thu Jun 08 00:44:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoCNE-00013k-Tv for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 00:44:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoCND-0001Ir-LY for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 00:44:00 -0400 Received: from cm48120.red.mundo-r.com ([213.60.48.120] helo=honeywell-tsi.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FoBkn-0000S5-00 for ipfix-list@mil.doit.wisc.edu; Wed, 07 Jun 2006 23:04:17 -0500 Message-ID: <000001c68ab0$99b8a550$f37ca8c0@zsn43> Reply-To: "Boghos Parkins" From: "Boghos Parkins" To: ipfix-list@mil.doit.wisc.edu Subject: test ciy Date: Wed, 7 Jun 2006 21:04:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68A75.ED59CD50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?213.60.48.120 X-Spam-Score: 4.5 (++++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68A75.ED59CD50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, V " A G R A S 0 M & A M B " E N L E V " T R A M E R " D i A X & N A X C " A L i S P R 0 Z & C V A L " U M all 50 % off - http://www.gunertopin.com _____ =20 What brings Mister Baggins,=20 And Balin and Dwalin=20 down into the valley=20 in June=20 ha! ha!=20 O! Will you be staying,=20 ------=_NextPart_000_0001_01C68A75.ED59CD50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

V " A G R A
S 0 M &
A M B " E N
L E V " T R A
M E R " D i A
X & N A X
C " A L i S
P R 0 Z & C
V A L " U M

all 50 % off - http://www.gunertopin.com


What brings Mister Baggins,
And Balin and Dwalin
= down into the valley
in June
ha! ha!
O! Will you be = staying,
------=_NextPart_000_0001_01C68A75.ED59CD50-- From extendiblenm@connerindustries.com Thu Jun 08 02:55:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoEQS-0006gt-E8 for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 02:55:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoDZn-0008FL-KR for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 02:01:03 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoDOi-0006Xc-Ua for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 01:49:39 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FoDBO-0007m4-00; Thu, 08 Jun 2006 00:35:51 -0500 Received: from 3F9AA78 (91.70.191.220.broad.hz.zj.dynamic.cndata.com [220.191.70.91]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k585ZQpd030926; Thu, 8 Jun 2006 00:35:33 -0500 Received: from smtp15.sascentre.every1.net (172.16.1.29) by smtp4.libero.it (7.0.027-6YW8) id 7YYKP0H03WC33178; Thu, 08 Jun 2006 00:35:30 -0600 Received-SPF: none (smtp18.dragons-mail.com: 151.49.73.388 is neither permitted nor denied by domain of dragonform.com.hk) client-ip=151.49.73.388; envelope-from=Isabella.Finley@dragonform.com.hk; helo=dragonform.com.hk; Received: from unknown (50.6.861.47) by nkmail.kektech.every1.net with LOCAL; Thu, 08 Jun 2006 00:35:30 -0600 Message-ID: Date: Thu, 08 Jun 2006 00:35:30 -0600 Reply-to: "Jeff Lockhart" From: "Jeff Lockhart" X-Accept-Language: en-us MIME-Version: 1.0 To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu Subject: Hola Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 0226-8, 06/09/2006), Outbound message X-Antivirus-Status: Not-Tested X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 The average home-loan we've given out this month is $400,000.00 @ 4.01% int! We do not care about your current credit/financial situation. Last 3 loans-closed today: @ 4.15% $277,000.00 @ 4.39% $319,000.00 @ 3.28% $713,000.00 http://www.geocities.com/nigel_15tanith From majordomo@mil.doit.wisc.edu Thu Jun 08 04:43:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoG6W-0005Li-1h for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 04:43:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoFR2-0008IL-Vw for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 04:00:09 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoEud-000092-E1 for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 03:26:41 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FoEpN-000702-00 for ipfix-list@mil.doit.wisc.edu; Thu, 08 Jun 2006 02:21:13 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FoEpK-0006zO-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 08 Jun 2006 02:21:10 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 53DBA115 for ; Thu, 8 Jun 2006 09:21:09 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 13162-05 for ; Thu, 8 Jun 2006 09:21:07 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id CCE83133 for ; Thu, 8 Jun 2006 09:21:05 +0200 (DFT) Message-ID: <4487CFAA.3060608@informatik.uni-tuebingen.de> Date: Thu, 08 Jun 2006 09:20:10 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> <448035D6.40003@fokus.fraunhofer.de> <4481AA1E.4060901@informatik.uni-tuebingen.de> <095228B7-56CE-4EA1-9CA0-42E110136B85@cert.org> In-Reply-To: <095228B7-56CE-4EA1-9CA0-42E110136B85@cert.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Content-Transfer-Encoding: quoted-printable Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: a492040269d440726bfd84680622cee7 Apparently my mail from two days ago did not make it to the mailing list, so I send it again. Sorry if you get this message twice. -------- Original Message -------- Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Date: Tue, 06 Jun 2006 13:06:57 +0200 From: Gerhard Muenz To: Brian Trammell CC: ipfix-protocol@net.doit.wisc.edu Brian, I understand your point. But as we see, using a single identifier for both transport-related (who is the Exporter) and content-related (who is the Observation Point) information seems to be an unsolvable problem. I think that there is no problem to have two different "roots" of scopes, one for transport-related information needed for template management and the like and another one for content-related information. Let's have a look at the case of a concentrator. It receives IPFIX messages from other IPFIX devices, merges the records in its Metering Process, and exports them again. The received records can be from various Observation Domains (at least I do not see any reason why not). So, which value do you take as Observation Domain ID for the exported IPFIX packets? The protocol draft says that you can put a zero, but is this satisfactory? Or do you define a virtual Observation Domain as a superset of the original ones? It becomes more tricky if there are two Exporting Processes running on the same concentrator. Gerhard Brian Trammell wrote: > Gerhard, >=20 > The issue with this is that Observation Domain ID also holds a special > role within the protocol; it is the "root" of all scope Information > Elements (as well as Template IDs, which are themselves a special case > of scope IEs): the uniqueness and comparability of templateID, flowID > and commonPropertiesID are only guaranteed within a unique Observation > Domain ID. The issue with identifying Exporting Processes, etc. is that > there needs to be _some_ way to guarantee the uniqueness and > comparability of Observation Domain IDs themselves - as we probably > don't want to either do the Win32 thing, size it up to a GUID, and cros= s > our fingers; or introduce any additional complexity either to the > protocol or to implementations thereof by specifying some sort of > Observation Domain ID registration process or other mechanism for > avoiding collisions. >=20 > Regards, >=20 > Brian >=20 > On Jun 3, 2006, at 11:26 AM, Gerhard Muenz wrote: >=20 >> >> Dear all, >> >> We have discussed the Observation Domain ID issue a lot. Something cam= e >> into my mind and maybe it is useful to solve the problem. >> >> There are two different things that we want to do: >> >> 1) Identify the Exporting Process because we need it for the template >> management. >> >> 2) Identify the Observation Domain because we want to know where the >> traffic as been observed. >> >> The problem is that the Observation Domain ID (formerly known as Sourc= e >> ID) is in the header of the IPFIX message. This is not logic because t= he >> Obervation Domain ID is linked to a record while the IPFIX header is >> something that the Exporting Process is responsible for. >> >> Wouldn't it be better to replace the Observation Domain ID in the IPFI= X >> header by the Exporter ID? >> Then, the pair exporter IP address (that we get from the IP header) >> together with the Exporter ID in the IPFIX header could identify the >> Exporting Process. >> >> If ever needed, the Observation Domain ID can be exported with the >> individual records or within option data. >> >> Regards, >> Gerhard >> >> Brian Trammell wrote: >>> Lutz and Juergen, >>> >>> On Jun 2, 2006, at 8:57 AM, Lutz Mark wrote: >>> >>>> >>>> Hi Brian, >>>> >>>>> Redefining the Observation Domain to be unique per (exporting) IPFI= X >>>>> Device partially fixes the problem, but it does not address the >>>>> problem of Exporting Process/exporting device identification at the >>>>> Collecting Process, of which the Exporting Process IP address >>>>> collision issue is a subset. If an IPFIX device is using multihomed >>>>> SCTP associations, for example, a Collecting Process may not treat >>>>> two Observation Domains that are really identical as such. >>>>> Therefore, I would propose again that instead of defining Observati= on >>>>> Domains to be unique per exporting IPFIX Device, that Observation >>>>> Domains are unique per Session, where a Session is a TCP connection= , >>>>> an SCTP association, or a (time-limited) UDP four-tuple. This grant= s >>>>> the most flexibility to implementors while being, in my opinion, mo= re >>>>> logically sound... If an exporting device implementor wishes instea= d >>>>> to enforce domain uniqueness per Device, that would be consistent >>>>> with this definition. >>>> >>>> Having the Observation Domain ID unique per session will ease the >>>> implementation of the exporter and collector part of the protocol. >>>> As you have mentioned an Observation Domain ID that is unique per >>>> IPFIX device implies that the ID is unique per session. >>> >>> >>>> Having >>>> the ID unique only per session has the drawback that on the >>>> collector side the ID is quite useless without the session details >>>> and one need additional means to group data from different sessions. >>> >>> Indeed... I hadn't thought of that. We would need some sort of sessio= n >>> identifier, whether a simple IE or compound, to store session details= . >>> >>>> If the ID is unique per IPFIX device, the collector can store >>>> the Observation Domain ID together with the flow data (for each >>>> IPFIX device). And an application can request flow data per >>>> observation domain. >>> >>> Could we address Juergen's concerns with respect to the imprecision o= f >>> the present IPFIX Device definition (an architectural term that I'm n= ot >>> personally convinced should have any real meaning at the protocol lev= el) >>> by instead defining uniqueness per {Metering Process, Exporting Proce= ss} >>> tuple? >>> >>> Argh... actually, neither of these will work as root scopes. The {Met= er, >>> Exporter} tuple requires stability over time - it requires that no >>> Observation Domain ID ever be reused, which is clearly ridiculous. A >>> Session (which is really an {Exporter, Collector, Source Port, Start >>> Time, End Time} tuple with multiple addresses possible for Exporter a= nd >>> Collector in the case of SCTP multihoming) is not naturally storable = at >>> the collector side. >>> >>> The "right" thing to do in this case would seem to be to scope >>> Observation Domain IDs to the superset of both, a {Meter, Exporter, >>> Collector, Start Time, End Time} tuple, but this just seems to be a b= it >>> too heavy. With what frequency to we expect realistic Exporting >>> Processes to assign new Observation Domain IDs to logically identical >>> Domains? >>> >>> As a thought exercise in whether we're overthinking this: what would >>> happen if we went to the other extreme, stepped back completely, simp= ly >>> defined the Observation Domain as we do now without guaranteeing its >>> uniqueness anywhere, and required the implementation or deployment to >>> avoid observation domain ID collision out of band? >>> >>> Regards, >>> >>> Brian >>> >> >> --Dipl.-Ing. Gerhard M=FCnz >> Computer Networks and Internet >> Wilhelm Schickard Institute for Computer Science >> University of Tuebingen >> Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany >> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >> EMail: muenz@informatik.uni-tuebingen.de >> WWW: http://net.informatik.uni-tuebingen.de/~muenz >=20 --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz -- 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 circumscriptionol@c21alpha.com Thu Jun 08 08:05:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoJGP-0008TF-Ha for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 08:05:25 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoJGO-0003ur-9x for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 08:05:25 -0400 Received: from [218.29.250.62] (helo=465AA90) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FoJAM-0004rY-00; Thu, 08 Jun 2006 06:59:11 -0500 Received: from smtp11.vgnmail.com (172.16.1.79) by smtp8.libero.it (7.0.027-N875) id 98O5WX5K7449T8E9; Thu, 08 Jun 2006 06:59:06 -0600 Received-SPF: none (smtp10.mail.quorumspain.com: 151.49.733.989 is neither permitted nor denied by domain of dvg-siersburg.de) client-ip=151.49.733.989; envelope-from=iberiabj@dvg-siersburg.de; helo=dvg-siersburg.de; Received: from unknown (50.6.881.518) by rcmail.discount-hotel-reservation.every1.net with LOCAL; Thu, 08 Jun 2006 06:59:06 -0600 Message-ID: <4A7WZ564.7VD83OT@dvg-siersburg.de> Date: Thu, 08 Jun 2006 06:59:06 -0600 Reply-to: "Nelson Seymour" From: "Nelson Seymour" X-Accept-Language: en-us MIME-Version: 1.0 To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu Subject: Re:fnance Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 0946-2, 06/03/2006), Outbound message X-Antivirus-Status: Not-Tested X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 The average home-loan we've given out this month is $400,000.00 @ 4.01% int! We do not care about your current credit/financial situation. Last 3 loans-closed today: @ 4.15% $277,000.00 @ 4.39% $319,000.00 @ 3.28% $713,000.00 http://geocities.com/DrunMuriel_man1 From majordomo@mil.doit.wisc.edu Thu Jun 08 10:58:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLyC-0008OH-0u for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 10:58:48 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoLyA-0004UI-KS for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 10:58:48 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FoLtN-000737-00 for ipfix-list@mil.doit.wisc.edu; Thu, 08 Jun 2006 09:53:49 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FoLtL-00072P-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 08 Jun 2006 09:53:47 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.20) with ESMTP id k58Erhjk028566 for ; Thu, 8 Jun 2006 10:53:45 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k58ErFZG028529 for ; Thu, 8 Jun 2006 10:53:15 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k58Er1YZ028495; Thu, 08 Jun 2006 10:53:15 -0400 (EDT) Received: from [128.237.250.118] (vpn-10-25-4-22.remote.cert.org [10.25.4.22]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.60) with ESMTP id k58Er1uL006352; Thu, 8 Jun 2006 10:53:01 -0400 In-Reply-To: <447C5FEE.6070700@cisco.com> References: <447C5FEE.6070700@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-4--327512971" Message-Id: <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> Cc: ipfix-protocol@net.doit.wisc.edu, Lutz Mark , Gerhard Muenz , Juergen Quittek Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Date: Thu, 8 Jun 2006 10:52:58 -0400 To: Benoit Claise X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--327512971 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Benoit, The discussion on this has wandered a bit - to try to summarize and bring this to a decision (with apologies if this is either 1. something you've already decided or 2. too late for tomorrow's call): 1. The present IPFIX-PROTO solution of declaring observationDomainIDs (herein: odId) as unique per Exporting Process requires coordination of odId assignment among all the Exporting Processes in a given installation, and has a circular definition problem: Exporting Process identification if present in a message stream must be exported in a scoped data record; scoped data records require a template to interpret; templates are identified by a templateID; templateIDs are unique per odId; odIds are unique per Exporting Process ID. 2. The present IPFIX-ARCH solution (and the proposed solution in the original message) of declaring odId as unique per IPFIX Device requires extension of the Device definition to cover processes such as proxies, some method of coordinating odId assignment among multiple disparate processes on the same Device, and (possibly) the creation of a Device identifier so that odId uniqueness can be maintained in storage at the Collecting Process. This may also have the circular definition problem as above. 3. Declaring odId as unique per Session requires an explicit definition of Session (which is troublesome in the UDP case), and requires the storage of session details at the Collecting Process in order to keep persistent odId uniqueness, which is a little ugly. However, it avoids the circular uniqueness of templates. Note the template circular definition problem goes away completely if templateIDs are defined to be unique per session, not per odId. This makes sense as templateIDs are less likely to be stored by the Collecting Process than odIds. The problem of templateID exhaustion (which is what I presume defining them to be unique per odId was intended to solve) goes away if you forbid templateIDs to be used as a general purpose scope, and use the commonPropertiesID (which is a 64-bit space as opposed to a 16-bit one) from reducing-redundancy instead. Hope this is useful, and clarifies the threads on the subject a bit... Regards, Brian On May 30, 2006, at 11:08 AM, Benoit Claise wrote: > Dear all, > > I know it was addressed a couple of times on the mailing list. > However, while discussing with Lutz Mark and Paul Aitken, I think > we discovered the issue > > the definition of the observation domain id differs between > ipfix-arch and ipfix-proto. > > -in ipfix-arch the id is unique within the ipfix device > -in ipfix-proto the id is unique to the exporting process > > ------------------------------------------------------------ > > [ARCH] > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points within an IPFIX Device. > Each {Observation Point, Metering Process} pair belongs to a single > Observation Domain. An IPFIX Device could have multiple Observation > Domains, each of which has a subset of the total set of Observation > Points in it. Each Observation Domain must carry a unique ID within > the context of an IPFIX Device. Note that in case of multiple > Observation Domains, a unique ID per Observation Domain must be > transmitted as a parameter to the Exporting Function. That > unique ID > is referred to as the IPFIX Observation Domain ID. > > > [PROTO] > 3.3 > Observation Domain ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify > to the Collecting Process the Observation Domain that > metered the Flows. Collecting Processes SHOULD use the > combination of the Exporter (exporterIPv4Address, > exporterIPv6Address, or exportingProcessId) and the > Observation Domain ID field to separate different export > streams originating from the same Exporting Process. The > Observation Domain ID SHOULD be 0 when no specific > Observation Domain ID is relevant for the entire IPFIX > Message. For example, when exporting the Exporting Process > Statistics, or in case of hierarchy of Collector when > aggregated data records are exported. > > > We think that the Observation Domain Id should be unique per IPFIX > Device, and not per Exporting Process. > Otherwise, we could end up in the following situation: one sysadmin > configures a set of observation points with observation domain 1, > while a second sysadmin configures another set of observation > points (on a different line card for example) with the same > observation domain Id. > If each observation domain exports using its own exporting process > with the source IP address, how would the collector differentiate > the template IDs? > > Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are > not in sync. > Multiple small changes (including in the terminology sections) > should be inserted. For example: IPFIX-PROTO observation domain > definition says "In the IPFIX Message it generates, the Observation > Domain includes its Observation Domain ID, which is unique per > Exporting Process. " > > Feedback? > > 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/ --Apple-Mail-4--327512971 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEiDnN4/8LCZ4pwvYRAmc3AKDwsaLra/asrZHFWk4dIGC8LitHdwCfVuse dMESskh3PU5Ao/lO9DnEdyY= =iEij -----END PGP SIGNATURE----- --Apple-Mail-4--327512971-- -- 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 Jun 08 11:29:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoMSE-00053Q-CJ for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 11:29:50 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoMSB-00013L-SW for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 11:29:50 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FoMJM-0002x2-00 for ipfix-list@mil.doit.wisc.edu; Thu, 08 Jun 2006 10:20:40 -0500 Received: from relay03.pair.com ([209.68.5.17]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FoMJL-0002wx-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 08 Jun 2006 10:20:39 -0500 Received: (qmail 72052 invoked from network); 8 Jun 2006 15:20:38 -0000 Received: from unknown (HELO ?192.168.0.66?) (unknown) by unknown with SMTP; 8 Jun 2006 15:20:38 -0000 X-pair-Authenticated: 207.237.36.98 In-Reply-To: <4487CFAA.3060608@informatik.uni-tuebingen.de> References: <447C5FEE.6070700@cisco.com> <8499A9CE-9BEF-4758-A7E6-107931237549@cert.org> <448035D6.40003@fokus.fraunhofer.de> <4481AA1E.4060901@informatik.uni-tuebingen.de> <095228B7-56CE-4EA1-9CA0-42E110136B85@cert.org> <4487CFAA.3060608@informatik.uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Cc: ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: quoted-printable From: Carter Bullard Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness Date: Thu, 8 Jun 2006 11:20:38 -0400 To: Gerhard Muenz X-Mailer: Apple Mail (2.750) Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Hey Gerhard, Argus uses the same ID and IE for both functions, but we distinguish when the ID is used as a source identifier (your observation domain) and when its used as a transport session identiifier (your exporter domain?). The fact that the ID is the same is more coincidental and convenient than anything else, leveraging on the property that a globally unique identifier is also locally unique (its the same as DECNET using an ethernet address as both a layer 2 and layer 3 address. The difference between Argus and IPFIX in this area, is that the Source Identifier is mandatory for every record, and readers don't modify it. Argus's Transport Session Identifier, has "hop- to-hop" significance, and can be tossed, modified, whatever, by any Argus data reader/processor. So, some records will have multiple copies of the same IE, one for hop-to-hop transport, one for end-to-end identification. Carter On Jun 8, 2006, at 3:20 AM, Gerhard Muenz wrote: > > Apparently my mail from two days ago did not make it to the mailing > list, so I send it again. Sorry if you get this message twice. > > > -------- Original Message -------- > Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness > Date: Tue, 06 Jun 2006 13:06:57 +0200 > From: Gerhard Muenz > To: Brian Trammell > CC: ipfix-protocol@net.doit.wisc.edu > > Brian, > > I understand your point. But as we see, using a single identifier for > both transport-related (who is the Exporter) and content-related =20 > (who is > the Observation Point) information seems to be an unsolvable =20 > problem. I > think that there is no problem to have two different "roots" of =20 > scopes, > one for transport-related information needed for template =20 > management and > the like and another one for content-related information. > > Let's have a look at the case of a concentrator. It receives IPFIX > messages from other IPFIX devices, merges the records in its Metering > Process, and exports them again. The received records can be from > various Observation Domains (at least I do not see any reason why =20 > not). > So, which value do you take as Observation Domain ID for the exported > IPFIX packets? The protocol draft says that you can put a zero, but is > this satisfactory? Or do you define a virtual Observation Domain as a > superset of the original ones? It becomes more tricky if there are two > Exporting Processes running on the same concentrator. > > Gerhard > > > Brian Trammell wrote: >> Gerhard, >> >> The issue with this is that Observation Domain ID also holds a =20 >> special >> role within the protocol; it is the "root" of all scope Information >> Elements (as well as Template IDs, which are themselves a special =20 >> case >> of scope IEs): the uniqueness and comparability of templateID, flowID >> and commonPropertiesID are only guaranteed within a unique =20 >> Observation >> Domain ID. The issue with identifying Exporting Processes, etc. is =20= >> that >> there needs to be _some_ way to guarantee the uniqueness and >> comparability of Observation Domain IDs themselves - as we probably >> don't want to either do the Win32 thing, size it up to a GUID, and =20= >> cross >> our fingers; or introduce any additional complexity either to the >> protocol or to implementations thereof by specifying some sort of >> Observation Domain ID registration process or other mechanism for >> avoiding collisions. >> >> Regards, >> >> Brian >> >> On Jun 3, 2006, at 11:26 AM, Gerhard Muenz wrote: >> >>> >>> Dear all, >>> >>> We have discussed the Observation Domain ID issue a lot. =20 >>> Something came >>> into my mind and maybe it is useful to solve the problem. >>> >>> There are two different things that we want to do: >>> >>> 1) Identify the Exporting Process because we need it for the =20 >>> template >>> management. >>> >>> 2) Identify the Observation Domain because we want to know where the >>> traffic as been observed. >>> >>> The problem is that the Observation Domain ID (formerly known as =20 >>> Source >>> ID) is in the header of the IPFIX message. This is not logic =20 >>> because the >>> Obervation Domain ID is linked to a record while the IPFIX header is >>> something that the Exporting Process is responsible for. >>> >>> Wouldn't it be better to replace the Observation Domain ID in the =20= >>> IPFIX >>> header by the Exporter ID? >>> Then, the pair exporter IP address (that we get from the IP header) >>> together with the Exporter ID in the IPFIX header could identify the >>> Exporting Process. >>> >>> If ever needed, the Observation Domain ID can be exported with the >>> individual records or within option data. >>> >>> Regards, >>> Gerhard >>> >>> Brian Trammell wrote: >>>> Lutz and Juergen, >>>> >>>> On Jun 2, 2006, at 8:57 AM, Lutz Mark wrote: >>>> >>>>> >>>>> Hi Brian, >>>>> >>>>>> Redefining the Observation Domain to be unique per (exporting) =20= >>>>>> IPFIX >>>>>> Device partially fixes the problem, but it does not address the >>>>>> problem of Exporting Process/exporting device identification =20 >>>>>> at the >>>>>> Collecting Process, of which the Exporting Process IP address >>>>>> collision issue is a subset. If an IPFIX device is using =20 >>>>>> multihomed >>>>>> SCTP associations, for example, a Collecting Process may not =20 >>>>>> treat >>>>>> two Observation Domains that are really identical as such. >>>>>> Therefore, I would propose again that instead of defining =20 >>>>>> Observation >>>>>> Domains to be unique per exporting IPFIX Device, that Observation >>>>>> Domains are unique per Session, where a Session is a TCP =20 >>>>>> connection, >>>>>> an SCTP association, or a (time-limited) UDP four-tuple. This =20 >>>>>> grants >>>>>> the most flexibility to implementors while being, in my =20 >>>>>> opinion, more >>>>>> logically sound... If an exporting device implementor wishes =20 >>>>>> instead >>>>>> to enforce domain uniqueness per Device, that would be consistent >>>>>> with this definition. >>>>> >>>>> Having the Observation Domain ID unique per session will ease the >>>>> implementation of the exporter and collector part of the protocol. >>>>> As you have mentioned an Observation Domain ID that is unique per >>>>> IPFIX device implies that the ID is unique per session. >>>> >>>> >>>>> Having >>>>> the ID unique only per session has the drawback that on the >>>>> collector side the ID is quite useless without the session details >>>>> and one need additional means to group data from different =20 >>>>> sessions. >>>> >>>> Indeed... I hadn't thought of that. We would need some sort of =20 >>>> session >>>> identifier, whether a simple IE or compound, to store session =20 >>>> details. >>>> >>>>> If the ID is unique per IPFIX device, the collector can store >>>>> the Observation Domain ID together with the flow data (for each >>>>> IPFIX device). And an application can request flow data per >>>>> observation domain. >>>> >>>> Could we address Juergen's concerns with respect to the =20 >>>> imprecision of >>>> the present IPFIX Device definition (an architectural term that =20 >>>> I'm not >>>> personally convinced should have any real meaning at the =20 >>>> protocol level) >>>> by instead defining uniqueness per {Metering Process, Exporting =20 >>>> Process} >>>> tuple? >>>> >>>> Argh... actually, neither of these will work as root scopes. The =20= >>>> {Meter, >>>> Exporter} tuple requires stability over time - it requires that no >>>> Observation Domain ID ever be reused, which is clearly =20 >>>> ridiculous. A >>>> Session (which is really an {Exporter, Collector, Source Port, =20 >>>> Start >>>> Time, End Time} tuple with multiple addresses possible for =20 >>>> Exporter and >>>> Collector in the case of SCTP multihoming) is not naturally =20 >>>> storable at >>>> the collector side. >>>> >>>> The "right" thing to do in this case would seem to be to scope >>>> Observation Domain IDs to the superset of both, a {Meter, Exporter, >>>> Collector, Start Time, End Time} tuple, but this just seems to =20 >>>> be a bit >>>> too heavy. With what frequency to we expect realistic Exporting >>>> Processes to assign new Observation Domain IDs to logically =20 >>>> identical >>>> Domains? >>>> >>>> As a thought exercise in whether we're overthinking this: what =20 >>>> would >>>> happen if we went to the other extreme, stepped back completely, =20= >>>> simply >>>> defined the Observation Domain as we do now without guaranteeing =20= >>>> its >>>> uniqueness anywhere, and required the implementation or =20 >>>> deployment to >>>> avoid observation domain ID collision out of band? >>>> >>>> Regards, >>>> >>>> Brian >>>> >>> >>> --Dipl.-Ing. Gerhard M=FCnz >>> Computer Networks and Internet >>> Wilhelm Schickard Institute for Computer Science >>> University of Tuebingen >>> Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany >>> Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 >>> EMail: muenz@informatik.uni-tuebingen.de >>> WWW: http://net.informatik.uni-tuebingen.de/~muenz >> > > --=20 > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 > EMail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz > > > -- > 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/ > Carter Bullard CEO/President QoSient, LLC 150 E. 57th Street Suite 12D New York, New York 10022 +1 212 588-9133 Phone +1 212 588-9134 Fax -- 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 Jun 08 12:06:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoN1p-0003VR-SP for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 12:06:37 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoN1o-0007FK-Id for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 12:06:37 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FoMwg-00055t-00 for ipfix-list@mil.doit.wisc.edu; Thu, 08 Jun 2006 11:01:18 -0500 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 1FoMwe-00055o-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 08 Jun 2006 11:01:16 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 08 Jun 2006 09:01:15 -0700 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k58G1FWi007367; Thu, 8 Jun 2006 09:01:15 -0700 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k58G1ELf020742; Thu, 8 Jun 2006 18:01:14 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id RAA11244; Thu, 8 Jun 2006 17:01:13 +0100 (BST) Message-ID: <448849C9.9080304@cisco.com> Date: Thu, 08 Jun 2006 17:01:13 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Brian Trammell CC: Benoit Claise , ipfix-protocol@net.doit.wisc.edu, Lutz Mark , Gerhard Muenz , Juergen Quittek Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> In-Reply-To: <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1368; t=1149782476; x=1150646476; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=andrjohn@cisco.com; z=From:Andrew=20Johnson=20 |Subject:Re=3A=20[ipfix-protocol]=20Observation=20Domain=20ID=20uniqueness; X=v=3Dcisco.com=3B=20h=3DR8dKUQfW9rN5p1GxFjtGBVJa3Mw=3D; b=XEYaDOtmGbZBM4B/+h5Yf7rcdVMCap4U7eVoYYXh1J1wPvs09oq/Jfl1lC5Hzzm8kMfK6sEB oNDYnNsDvi9bYZmwdY9UVpJn7v9YlB2UL+qCUiAYw5lv2TS7qTaRw5yC; Authentication-Results: sj-dkim-3.cisco.com; header.From=andrjohn@cisco.com; dkim=pass ( sig from cisco.com verified; ); Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Brian Trammell wrote: [SNIP] > Note the template circular definition problem goes away completely if > templateIDs are defined to be unique per session, not per odId. This > makes sense as templateIDs are less likely to be stored by the > Collecting Process than odIds. The problem of templateID exhaustion > (which is what I presume defining them to be unique per odId was > intended to solve) goes away if you forbid templateIDs to be used as a > general purpose scope, and use the commonPropertiesID (which is a 64-bit > space as opposed to a 16-bit one) from reducing-redundancy instead. I don't think the templateId should be used for scope. I don't think this is really a special rule, just something that falls out of how scope and options should be used. When a collector receives a record, that record does not have a templateID in it. A template was used to decode the record, but after that stage the templateId can be discarded as it is not relevant to the data in the record. Using templateId as scope means that a special rule will have to be made so that the templateId will be stored in the decoded record. The same applies to any other inherited field, such as odId, exporterID, etc. If these fields are in the record sent by the exporter then they can be decoded with any options that exporter sent. Andrew -- 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 kellbynewton@eserver-ru.com Thu Jun 08 13:47:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoObV-0006VV-Aw for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 13:47:33 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoObS-0004tD-W6 for ipfix-archive@lists.ietf.org; Thu, 08 Jun 2006 13:47:33 -0400 Received: from 200-127-87-98.cab.prima.net.ar ([200.127.87.98] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FoOVx-0003eJ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 08 Jun 2006 12:41:49 -0500 Message-Id: <00e201c68b10$55b06900$82d33a85@hdjbhgdk> From: "perry gentry" To: "donna teague" Subject: Open Vacancy Date: Thu, 08 Jun 2006 15:33:00 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C68B10.55B06900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01C68B10.55B06900 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable You might have noticed how the recent changes of all kinds influence your l= ife. Constant growth of prices, low wages, employment problems. If you aren= 't satisfied with your present income or it doesn't comply with your capabi= lities; If you constantly lack money; If you want to better your financial = status or you are just looking for a part-time job, then this job is what y= ou need. Consider the advantages of the work we offer: Extra incomeYou migh= t have noticed how the recent changes of all kinds influence your life. Con= stant growth of prices, low wages, employment problems. If you aren't satis= fied with your present income or it doesn't comply with your capabilities; = If you constantly lack money; If you want to better your financial status o= r you are just looking for a part-time job, then this job is what you need.= Consider the advantages of the work we offer: Extra income Minimal expenses and no expenditures at all (only I-net and e-mail) The easiness of work. - Possibility to combine this work with your occupati= ons (you just need to check your e-mail several times a day) For this work = you don't need a special education possessing some special skills or knowle= dge possessing storehouse, office, special equipment.=20 The job we offer is related to mail. It is an easy job which doesn't requir= e leaving your main occupation. You will have to receive to your home addre= ss parcels from our clients and ship them out further following our manager= 's instructions ($30 for each shipped out box). Contact us by e-mail and yo= u will be sent a list of vacancies available at the present time. You work = will be paid for without any delays.=20 You may work with several orders at a time as well as work with each one se= parately. Contact: job@westbcompany.net motor torpedo boat spur-driven shock wave twice-tendered gentleman-murderer checker-up loan agent spandrel wall Caen stone leading wire swamp lover spatter cone dracaena palm quick-growing thread splicer hoop-back cranberry tree half-world hook-headed no-system pseudo bride laparo-uterotomy jig-jig death chamber ------=_NextPart_000_00E2_01C68B10.55B06900 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
You might have noticed how the recent changes of all kinds influence your l= ife. Constant growth of prices, low wages, employment problems. If you aren= 't satisfied with your present income or it doesn't comply with your capabi= lities; If you constantly lack money; If you want to better your financial = status or you are just looking for a part-time job, then this job is what y= ou need. Consider the advantages of the work we offer: Extra incomeYou migh= t have noticed how the recent changes of all kinds influence your life. Con= stant growth of prices, low wages, employment problems. If you aren't satis= fied with your present income or it doesn't comply with your capabilities; = If you constantly lack money; If you want to better your financial status o= r you are just looking for a part-time job, then this job is what you need.= Consider the advantages of the work we offer: Extra income
Minimal expenses and no expenditures at all (only I-net and e-mail)
The easiness of work. - Possibility to combine this work with your occupati= ons (you just need to check your e-mail several times a day) For this work = you don't need a special education possessing some special skills or knowle= dge possessing storehouse, office, special equipment.
The job we offer is related to mail. It is an easy job which doesn't requir= e leaving your main occupation. You will have to receive to your home addre= ss parcels from our clients and ship them out further following our manager= 's instructions ($30 for each shipped out box). Contact us by e-mail and yo= u will be sent a list of vacancies available at the present time. You work = will be paid for without any delays.
You may work with several orders at a time as well as work with each one se= parately.
Contact: job@westbcompany.net




motor torpedo boat spur-driven shock wave
twice-tendered gentleman-murderer checker-up
loan agent spandrel wall Caen stone
leading wire swamp lover spatter cone
dracaena palm quick-growing thread splicer
hoop-back cranberry tree half-world
hook-headed no-system pseudo bride
laparo-uterotomy jig-jig death chamber
= ------=_NextPart_000_00E2_01C68B10.55B06900-- From majordomo@mil.doit.wisc.edu Fri Jun 09 00:06:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoYGf-00069L-7J for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 00:06:41 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoYGc-0006qv-P8 for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 00:06:41 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FoY69-0004Ss-00 for ipfix-list@mil.doit.wisc.edu; Thu, 08 Jun 2006 22:55:49 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FoY67-0004SX-00 for ipfix@net.doit.wisc.edu; Thu, 08 Jun 2006 22:55:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 92EAE34164 for ; Fri, 9 Jun 2006 15:55:45 +1200 (NZST) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23952-02 for ; Fri, 9 Jun 2006 15:55:45 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 6C9B53409E for ; Fri, 9 Jun 2006 15:55:45 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k593tjIi020269 for ; Fri, 9 Jun 2006 15:55:45 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k593tiNa020266 for ipfix@net.doit.wisc.edu; Fri, 9 Jun 2006 15:55:44 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from nevil-laptop.cs.auckland.ac.nz (nevil-laptop.cs.auckland.ac.nz [130.216.38.130]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 9 Jun 2006 15:55:44 +1200 Message-ID: <20060609155544.ibuyly0uxq80088s@webmail.auckland.ac.nz> Date: Fri, 9 Jun 2006 15:55:44 +1200 From: Nevil Brownlee To: ipfix@net.doit.wisc.edu Subject: [ipfix] New Charter draft, version 2 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Hi all: Back in March/April, when we were discussing the new IPFIX charter, an email from me said we'd have it ready by 30 April. Alas, I've been a bit busy lately, so I'm catching up on my backlog. I've taken the -01 version of the new charter, and made all the changes to it as suggested on the list. Most of these were minor, which is fine. One was less minor: several people pointed out that "For the bi-flow story, we have not yet agreed on the "single, best-practice method for handling them" and more discussion appears to be necessary for jointly selecting one." I've addressed that issue by extending the time to produce the biflow RFC, as you'll see from the milestones. The -02 draft is appended below. If we have consensus that this is what we want for our new charter, I'll ask Dan to present it to IESG for approval :-) Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand ============================== PROPOSED new charter for IPFIX version 02, 9 Jun 06 ============================== The IPFIX working group has specified the Information Model (to describe IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX exporters to collectors). The PSAMP working group has specified the usage of the IPFIX protocol for exporting packet records. With both specifications available, several implementers have started building applications using the IPFIX protocol. At two interoperability testing events, several IPFIX protocol implementations were tested. The experiences made at these events were fed back to IPFIX protocol specification, particularly for removing ambiguities. In addition, several lessons were learned about how to implement and use IPFIX correctly and efficiently. The exchange among different implementers further led to new ideas for advanced usage of IPFIX. Many of these ideas are currently documented in individual Internet drafts. The goal of the IPFIX working group is now to produce 'best current practice' and 'guideline' documents concerning implementation, application and usage of the IPFIX protocol. Out of scope are modifications to the core IPFIX and PSAMP protocol specifications. In scope is the definition of new IPFIX and PSAMP information elements. Specific Goals o Develop guidelines for implementers based on experiences gained individually by implementers and jointly at interoperability testing events. The guidelines will give recommendations for integrating IPFIX observation points, metering processes, exporting processes and collecting processes into the packet flow at different kinds of IPFIX devices. They will make suggestions for efficient implementation of the IPFIX protocol features and identify parts of the IPFIX specification that have already been misunderstood by several implementors. For some implementation choices that the protocol specification leaves to the implementer, the guidelines will discuss advantages and disadvantages of the different choices. Several recent individual drafts call for new Information Elements; The implementation guidelines will explain procedures for requesting, reviewing and approving new IEs. Deliverables: 1. IPFIX Implementation Guidelines draft, to be an Informational RFC (6 months) 2. IPFIX Testing draft, to be an Informational RFC (6 months) o Develop methods and means for an efficient use of the IPFIX protocol by reducing redundancy in flow reports. The basic idea to be followed is very simple. For multiple flow records that all report the same value in one or more of the contained IPFIX information elements, those values are removed from the flow records and instead reported once for all in a separate record. Such an approach integrates very well with the IPFIX protocol and only needs a few simple methods for expressing the relationship between flow records and corresponding separate records. Deliverable: 3. IPFIX Reducing Redundancy, to be an Informational RFC (6 months) o Create an IPFIX MIB, for reporting information and statistics of IPFIX metering, exporting and collecing processes. Much of this work has already been done by the PSAMP working group, and by individuals working on IPFIX collectors. Deliverable: 4. IPFIX MIB, to be a Standards Track RFC (12 months) o Develop an effective method for exporting information about bidirectional flows ('biflows'). The IP security community has expressed a strong need to collect data on bidrectional flows. A recent individual draft discusses several different ways to support biflows in IPFIX - this work will produce a single, best-practice method for handling them, without requiring changes to the IPFIX protocol. Deliverable: 5. IPFIX Biflow draft, to be an Informational RFC (12 months) Milestones: August 06 Publish Internet Draft on IPFIX Implementation Guidelines August 06 Publish Internet Draft on IPFIX Testing August 06 Publish Internet Draft on Reducing Redundancy in IPFIX data transfer August 06 Publish Internet Draft on IPFIX MIB August 06 Publish Internet Draft on Handling IPFIX Bidirectional Flows November 06 Submit IPFIX Implementation Guidelines draft to IESG for publication as Informational RFC November 06 Submit IPFIX Testing draft to IESG for publication as Informational RFC November 06 Submit IPFIX Reducing Redundancy draft to IESG for publication as Informational RFC March 07 Submit IPFIX Biflows draft to IESG for publication as Informational RFC March 07 Submit IPFIX MIB draft to IESG for publication as Standards track RFC ----------------------------------------------------------------------------- ----------------------------------------------------------------------- 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 mcki@ent.com Fri Jun 09 05:49:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fodc2-0000QB-RT for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 05:49:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FocYE-0003Us-Vo for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 04:41:07 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FocJO-0004R3-J6 for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 04:25:48 -0400 Received: from host194-204.pool878.interbusiness.it ([87.8.204.194] helo=ent.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FocCI-0004gO-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 03:18:26 -0500 Message-ID: <000001c68b9d$46e77ca0$2124a8c0@vrl49> Reply-To: "Lewella Mckie" From: "Lewella Mckie" To: ipfix-list@mil.doit.wisc.edu Subject: Re: vyhoh refnnce Date: Fri, 9 Jun 2006 01:18:24 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68B62.9A88A4A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.0 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68B62.9A88A4A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, $ 2 j 00, 0 o 00 Loa a n for on h ly $ 82 b 7 month.=20 BA b D CR o ED o IT Ok l ! http://suglord.com/l1/ _____ =20 stone door, was left standing open. Bilbo blinked, and then suddenly he saw the goblins: goblins in full armour with drawn swords sitting just inside the door, and watching it with wide eyes, and watching the passage that led to it. They were ------=_NextPart_000_0001_01C68B62.9A88A4A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

$ 2 j 00, 0 o 00 Loa a n for on h ly $ 82 b 7 month.

BA b D CR o ED o IT Ok l ! http://suglord.com/l1/


stone door, was left standing open.
Bilbo blinked, and then suddenly he saw the goblins: goblins in = full
armour with drawn swords sitting just inside the door, and watching = it
with wide eyes, and watching the passage that led to it. They = were
------=_NextPart_000_0001_01C68B62.9A88A4A0-- From majordomo@mil.doit.wisc.edu Fri Jun 09 06:06:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FodsP-0004qg-9Z for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 06:06:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodB6-0000PC-O9 for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 05:21:16 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fod1Y-0005EC-HP for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 05:11:26 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FocvG-0004jh-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 04:04:54 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FocvE-0004jc-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 09 Jun 2006 04:04:52 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 22DB620001B8; Fri, 9 Jun 2006 11:05:11 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10391-07; Fri, 9 Jun 2006 11:05:11 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 00F3B20001B6; Fri, 9 Jun 2006 11:05:10 +0200 (CEST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix-protocol] Observation Domain ID uniqueness Date: Fri, 9 Jun 2006 11:04:50 +0200 Content-Type: multipart/signed; boundary="----=_NextPart_000_019A_01C68BB4.874889D0"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <6D28EBC684A4D94096217AD2FE400873752B85@venus.office> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ipfix-protocol] Observation Domain ID uniqueness Thread-Index: AcaGFFu9FFwmi0wMRVqmJQioeF3FcQFjWWLg From: "Thomas Dietz" To: "Juergen Quittek" , "Brian Trammell" , "Benoit Claise" Cc: X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 This is a multi-part message in MIME format. ------=_NextPart_000_019A_01C68BB4.874889D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable J=FCrgen, > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Juergen Quittek > Sent: Friday, June 02, 2006 8:54 AM > To: Brian Trammell; Benoit Claise > Cc: ipfix-protocol@net.doit.wisc.edu > Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness >=20 > Brian and Benoit, >=20 > I would favor the Observation Domain identifier to be unique per > Exporting Process. I consider 'unique per session' as also feasible. > But I do not think it is feasible to have the Observation=20 > Domain unique > per IPFIX device. I see the following problems with this approach: >=20 > - We would exclude cases where the Observation Domain is not on > the same box as the exporter. There are four such cases discussed > on RFC 3917, page 21 (protocol converter, remote=20 > observation point, > concentrator, and proxy). According to the current definition of > an IPFIX device in the protocol draft >=20 > > IPFIX Device > > > > An IPFIX Device hosts at least one Observation Point, a Metering > > Process and an Exporting Process. >=20 > none of them are IPFIX devices. There is no point in asking an ID > unique per IPFIX device if there is no IPFIX device present in the > scenario. Remote Observation Point: How do we identify the original device where the metering took place in = the case of a remote observation point? What if the remote device has = serveral observation domains? How does the collector know that the exporter is exporting for multiple devices? Concentrator: Is an observation domain really helpful here? If we are concentrating = data from the same source observation domain and exporter it does not change = the original observation domain. If we are concentrating data from different observation domains and exporters what can we tell about the original observation domain then? Similar questions arise with protocol translaters and proxies. I guess = we have to define the term observation domain for all of those special = devices seperately because a common definition would always reduce the = information carried. >=20 > Let's assume we fix this by re-defining the term IPFIX device, for > example, by stating that an IPFIX device hosts at least one of the > following: an Observation Point, a Metering Process, or an Exporting > Process. Then I still see problems with having the Observation Domain > unique per IPFIX device: >=20 > - How would two implementations (of potentially different vendors) > in the same box coordinate their Observation Domain=20 > naming schemes? > The IPFIX standard is not proposing one. >=20 > - What would an exporter do that reports for several boxes? > This could be in one of the cases mentioned above (protocol > converter, remote observation point, concentrator, or proxy). > In case of the concentrator, all input to the concentrator > already uses Observation Domains that are unique to their > respective IPFIX device. The concentrator would still not > be able to use them without risking that two Observation > Domains on different boxes have the same ID. >=20 Exactly what I argued above... How can we fix this without a) loosing information and b)have a single definition for all devices? Since the base standard defines the IPFIX device as you cited above the Observation Domain should - in my opinion - be unique per device. Since devices like concentraters are covered by seperate drafts/RFCs those documents should redefine the Observation Domain for those devices. Regards, Thomas > Thanks, >=20 > Juergen >=20 > --On 01.06.2006 13:25 Uhr -0400 Brian Trammell wrote: >=20 > > Benoit, > > > > Redefining the Observation Domain to be unique per (exporting) IPFIX > > Device partially fixes the problem, but it does not address the > > problem of Exporting Process/exporting device identification at the > > Collecting Process, of which the Exporting Process IP address > > collision issue is a subset. If an IPFIX device is using multihomed > > SCTP associations, for example, a Collecting Process may not treat > > two Observation Domains that are really identical as such. > > > > Therefore, I would propose again that instead of defining=20 > Observation > > Domains to be unique per exporting IPFIX Device, that Observation > > Domains are unique per Session, where a Session is a TCP connection, > > an SCTP association, or a (time-limited) UDP four-tuple. This grants > > the most flexibility to implementors while being, in my=20 > opinion, more > > logically sound... If an exporting device implementor wishes instead > > to enforce domain uniqueness per Device, that would be consistent > > with this definition. > > > > Regards, > > > > Brian > > > > On May 30, 2006, at 11:08 AM, Benoit Claise wrote: > > > >> Dear all, > >> > >> I know it was addressed a couple of times on the mailing list. > >> However, while discussing with Lutz Mark and Paul Aitken, I think > >> we discovered the issue > >> > >> the definition of the observation domain id differs between > >> ipfix-arch and ipfix-proto. > >> > >> -in ipfix-arch the id is unique within the ipfix device > >> -in ipfix-proto the id is unique to the exporting process > >> > >> ------------------------------------------------------------ > >> > >> [ARCH] > >> 5.4. Observation Domain > >> > >> The Observation Domain is a logical block that presents a single > >> identity for a group of Observation Points within an=20 > IPFIX Device. > >> Each {Observation Point, Metering Process} pair belongs=20 > to a single > >> Observation Domain. An IPFIX Device could have multiple=20 > Observation > >> Domains, each of which has a subset of the total set of=20 > Observation > >> Points in it. Each Observation Domain must carry a=20 > unique ID within > >> the context of an IPFIX Device. Note that in case of multiple > >> Observation Domains, a unique ID per Observation Domain must be > >> transmitted as a parameter to the Exporting Function. That > >> unique ID > >> is referred to as the IPFIX Observation Domain ID. > >> > >> > >> [PROTO] > >> 3.3 > >> Observation Domain ID > >> A 32-bit identifier of the Observation Domain that is > >> locally unique to the Exporting Process. The Exporting > >> Process uses the Observation Domain ID to=20 > uniquely identify > >> to the Collecting Process the Observation Domain that > >> metered the Flows. Collecting Processes SHOULD use the > >> combination of the Exporter (exporterIPv4Address, > >> exporterIPv6Address, or exportingProcessId) and the > >> Observation Domain ID field to separate different export > >> streams originating from the same Exporting Process. The > >> Observation Domain ID SHOULD be 0 when no specific > >> Observation Domain ID is relevant for the entire IPFIX > >> Message. For example, when exporting the=20 > Exporting Process > >> Statistics, or in case of hierarchy of Collector when > >> aggregated data records are exported. > >> > >> > >> We think that the Observation Domain Id should be unique per IPFIX > >> Device, and not per Exporting Process. > >> Otherwise, we could end up in the following situation: one sysadmin > >> configures a set of observation points with observation domain 1, > >> while a second sysadmin configures another set of observation > >> points (on a different line card for example) with the same > >> observation domain Id. > >> If each observation domain exports using its own exporting process > >> with the source IP address, how would the collector differentiate > >> the template IDs? > >> > >> Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are > >> not in sync. > >> Multiple small changes (including in the terminology sections) > >> should be inserted. For example: IPFIX-PROTO observation domain > >> definition says "In the IPFIX Message it generates, the Observation > >> Domain includes its Observation Domain ID, which is unique per > >> Exporting Process. " > >> > >> Feedback? > >> > >> 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/ > > >=20 >=20 >=20 > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 > 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 ------=_NextPart_000_019A_01C68BB4.874889D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDYwOTA5MDQ1MFowIwYJKoZIhvcNAQkEMRYEFDI4aMdO GtlO3ZIijd2dX31UrgDKMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAHCmP0SPrKq9lJeNOL2y Uq44Cza6rYCzdR25iNk7XmfCyeqFoh3QS0uMnAb0pJH97l1n8z6o81CKJHJaJWn93qG+oGceATTK 12L4yNELRyejM9ysiFT9cLzkfBHqxRjmksny8YCu+nmAYUeha+kRA+yHWktEJfaXyIP0sfo3vbuB Wzj58N0RNWzlrSA8vakmh7CIcxRSHpYD7WBZ6CJUpOAiVTycRnfsX33zhiE4U+lA8rhgmZXpF8i/ vYQkNxSX5so9j2fZpirkB4RwWXs6IypOKRfkUx466/r7EkZJ8o6/OhAcONvWON1AiV5oXz+tWLg/ Vs9Z4S7GlCAkSiiWeL4AAAAAAAA= ------=_NextPart_000_019A_01C68BB4.874889D0-- -- 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 Jun 09 06:10:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fodwr-0006r8-2V for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 06:10:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FodB9-0000PC-9W for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 05:21:19 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FocwN-00059W-4D for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 05:06:05 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FochK-0006lt-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 03:50:30 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FochI-0006lo-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 09 Jun 2006 03:50:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8639C20001B8; Fri, 9 Jun 2006 10:50:46 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09939-10; Fri, 9 Jun 2006 10:50:46 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6451B20001B6; Fri, 9 Jun 2006 10:50:46 +0200 (CEST) X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix-protocol] Observation Domain ID uniqueness Date: Fri, 9 Jun 2006 10:50:26 +0200 Content-Type: multipart/signed; boundary="----=_NextPart_000_0195_01C68BB2.83EB6700"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: <6D28EBC684A4D94096217AD2FE400873752B7F@venus.office> In-Reply-To: <448849C9.9080304@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ipfix-protocol] Observation Domain ID uniqueness Thread-Index: AcaLFuu3+/synIF8QjS7fGAsDIsdzAAiHUew From: "Thomas Dietz" To: "Andrew Johnson" , "Brian Trammell" Cc: "Benoit Claise" , , "Lutz Mark" , "Gerhard Muenz" , "Juergen Quittek" X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d This is a multi-part message in MIME format. ------=_NextPart_000_0195_01C68BB2.83EB6700 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Andrew Johnson > Sent: Thursday, June 08, 2006 6:01 PM > To: Brian Trammell > Cc: Benoit Claise; ipfix-protocol@net.doit.wisc.edu; Lutz > Mark; Gerhard Muenz; Juergen Quittek > Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness > > Brian Trammell wrote: > [SNIP] > > Note the template circular definition problem goes away > completely if > > templateIDs are defined to be unique per session, not per > odId. This > > makes sense as templateIDs are less likely to be stored by the > > Collecting Process than odIds. The problem of templateID exhaustion > > (which is what I presume defining them to be unique per odId was > > intended to solve) goes away if you forbid templateIDs to > be used as a > > general purpose scope, and use the commonPropertiesID > (which is a 64-bit > > space as opposed to a 16-bit one) from reducing-redundancy instead. > > I don't think the templateId should be used for scope. I don't think > this is really a special rule, just something that falls out of how > scope and options should be used. > The templateId definitely will be used as scope. How do you tell that the collector which flowkey is used for a template. And even if there is no need in IPFIX, PSAMP will have the templateId as scope since it will report the filtering and sampling methods used to get the information for a template. Regards, Thomas > When a collector receives a record, that record does not have > a templateID > in it. A template was used to decode the record, but after that stage > the templateId can be discarded as it is not relevant to the > data in the > record. Using templateId as scope means that a special rule > will have to > be made so that the templateId will be stored in the decoded record. > > The same applies to any other inherited field, such as odId, > exporterID, > etc. If these fields are in the record sent by the exporter then they > can be decoded with any options that exporter sent. > > > Andrew > > -- > 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/ > ------=_NextPart_000_0195_01C68BB2.83EB6700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDYwOTA4NTAyNlowIwYJKoZIhvcNAQkEMRYEFBVlpxz/ ptH5OvFurI4DQ24mf8M5MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAGOYYfVk1txdDpGy6zKP vX+sRbN2d0LLI4NkSmwTXhK8pFabXpe7rm9pvBnO9pXBVDyNATEy57Oh4mVISx9NyBA87G4BITOA o7wQu2RAIMjG0I/rISFX2kIlASSjuf5ymQyHGCZWN+W/KRWvtufNAYBs/3cu5cXna2NIOsB90VJA m/mpwlc1tzlKHsT+rA+/VC42qXeMczqZt7uN1AlDrpZoyb3nHI9jA+5IAx1fdeWtc6xWlvn+waTt CmLEzc3Lm5UOjOVaA+l0eQk19iaQ3vT1WzMSboQrqAImRN7EWTjISR7HNH09Dlh0OOzevsiwjAoV sMX1KzwQpy/KXXcazPcAAAAAAAA= ------=_NextPart_000_0195_01C68BB2.83EB6700-- -- 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 coriegates@misstitty.com Fri Jun 09 06:56:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foef5-0007Ed-Ow for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 06:56:19 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foef4-0005GY-H0 for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 06:56:19 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FoeXm-0002Zd-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 05:48:46 -0500 Received: from BABY (YRMfa-01p3-152.ppp11.odn.ad.jp [61.116.164.152]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k59AmhMm021108 for ; Fri, 9 Jun 2006 05:48:44 -0500 Message-Id: <009e01c68baa$539ae880$8c766c9d@zjebgsbp> From: "alexandrina chapman" To: "noll duran" Subject: American Residents Date: Fri, 09 Jun 2006 09:53:07 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C68BAA.539AE880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_009E_01C68BAA.539AE880 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable $450,000.00 @ 3.4% is real?! Want to lessen your monthly bills? Your financial situation doesnt matter! Theres no terms better then ours! http://dlirong.com/mort/ freight bill salt miner bloom boy tee slot alpha-eucaine vine mesquite bolt-cutting coach hire wide-banked world-alarming uranium yellow triple-decked pleasant-witted Pro-dreyfusard vegetable gelatin bully-off wandering dune tree trunk blanket fish angel cake claret dun cerium oxide jam-pack air-pervious ------=_NextPart_000_009E_01C68BAA.539AE880 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
$450,000.00 @ 3.4% is real?!

Want to lessen your monthly bills?
Your financial situation doesnt matter!

Theres no terms better then ours!

http://dlirong.com/mort/


freight bill salt miner bloom boy
tee slot alpha-eucaine vine mesquite
bolt-cutting coach hire wide-banked
world-alarming uranium yellow triple-decked
pleasant-witted Pro-dreyfusard vegetable gelatin
bully-off wandering dune tree trunk
blanket fish angel cake claret dun
cerium oxide jam-pack air-pervious
= ------=_NextPart_000_009E_01C68BAA.539AE880-- From majordomo@mil.doit.wisc.edu Fri Jun 09 07:59:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fofdw-0008AY-HS for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 07:59:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fofdw-0002lv-Fx for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 07:59:12 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FofPA-0007ks-6a for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 07:43:57 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FofL7-00014A-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 06:39:45 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FofL5-000145-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 09 Jun 2006 06:39:44 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2006 13:39:43 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k59Bdfrq017308; Fri, 9 Jun 2006 13:39:41 +0200 (MEST) Received: from [10.61.64.97] (ams3-vpn-dhcp97.cisco.com [10.61.64.97]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA12261; Fri, 9 Jun 2006 12:39:40 +0100 (BST) Message-ID: <44895DFC.9010805@cisco.com> Date: Fri, 09 Jun 2006 12:39:40 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Thomas Dietz CC: Brian Trammell , Benoit Claise , ipfix-protocol@net.doit.wisc.edu, Lutz Mark , Gerhard Muenz , Juergen Quittek Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness References: <6D28EBC684A4D94096217AD2FE400873752B7F@venus.office> In-Reply-To: <6D28EBC684A4D94096217AD2FE400873752B7F@venus.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Thomas Dietz wrote: [SNIP] > The templateId definitely will be used as scope. How do you tell that the > collector which flowkey is used for a template. To interpret the flowkey field you will have to know something about the template. The flowkey field is a special case where a field is used to try and patch up a shortcoming of the protocol. > And even if there is no need > in IPFIX, PSAMP will have the templateId as scope since it will report the > filtering and sampling methods used to get the information for a template. Every PSAMP record contains a selectorSequenceId which maps to a set of selectorIds. These IDs are used to identify the set of filtering and sampling methods used to get the information in this record. There is no use of the templateId in the PSAMP protocol as far as I remember. regards Andrew -- 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 Jun 09 10:28:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fohy1-00066r-1k for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 10:28:05 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fohxz-0004OW-7y for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 10:28:05 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fohh1-0003G4-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 09:10:31 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fohh0-0003Fx-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 09 Jun 2006 09:10:30 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k59EAJP05359; Fri, 9 Jun 2006 16:10:19 +0200 (CEST) Received: from [10.61.80.80] (ams3-vpn-dhcp4177.cisco.com [10.61.80.80]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k59EAFC26475; Fri, 9 Jun 2006 16:10:16 +0200 (CEST) Message-ID: <44898147.4000302@cisco.com> Date: Fri, 09 Jun 2006 16:10:15 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Trammell CC: ipfix-protocol@net.doit.wisc.edu, Lutz Mark , Gerhard Muenz , Juergen Quittek Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> In-Reply-To: <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> Content-Type: multipart/alternative; boundary="------------080300080601000100040402" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.5 (/) X-Scan-Signature: 210770d71723b650f9c8e3db4e95b596 This is a multi-part message in MIME format. --------------080300080601000100040402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Brian, Thanks for this summary, and sorry for the delay. > Benoit, > > The discussion on this has wandered a bit - to try to summarize and > bring this to a decision (with apologies if this is either 1. > something you've already decided or Only WG consensus will :) > 2. too late for tomorrow's call): I consider this issue more important that respecting the deadline and having some issues with the published RFC afterwards. > > 1. The present IPFIX-PROTO solution of declaring observationDomainIDs > (herein: odId) as unique per Exporting Process requires coordination > of odId assignment among all the Exporting Processes in a given > installation, and has a circular definition problem: Exporting Process > identification if present in a message stream must be exported in a > scoped data record; scoped data records require a template to > interpret; templates are identified by a templateID; templateIDs are > unique per odId; odIds are unique per Exporting Process ID. We agree that this is the problem to be fixed, on the top of the following discrepancy: -in [IPFIX-ARCH] the id is unique within the ipfix device -in [IPFIX-PROTO] the id is unique to the exporting process > > 2. The present IPFIX-ARCH solution (and the proposed solution in the > original message) of declaring odId as unique per IPFIX Device > requires extension of the Device definition to cover processes such as > proxies, Well, let's say that the problem is slightly different. The IPFIX device definition doesn't match RFC3917 > some method of coordinating odId assignment among multiple disparate > processes on the same Device, and (possibly) the creation of a Device > identifier so that odId uniqueness can be maintained in storage at the > Collecting Process. This may also have the circular definition problem > as above. > > 3. Declaring odId as unique per Session requires an explicit > definition of Session (which is troublesome in the UDP case), and > requires the storage of session details at the Collecting Process in > order to keep persistent odId uniqueness, which is a little ugly. > However, it avoids the circular uniqueness of templates. We agree this is heavy, not to say ugly :) > > Note the template circular definition problem goes away completely if > templateIDs are defined to be unique per session, not per odId. This > makes sense as templateIDs are less likely to be stored by the > Collecting Process than odIds. The problem of templateID exhaustion > (which is what I presume defining them to be unique per odId was > intended to solve) goes away if you forbid templateIDs to be used as a > general purpose scope, and use the commonPropertiesID (which is a > 64-bit space as opposed to a 16-bit one) from reducing-redundancy > instead. Here is two proposals. *_Proposal 1: _* This is what I proposed initially, and summarized by Thomas: "Since the base standard defines the IPFIX device as you cited above the Observation Domain should - in my opinion - be unique per device. Since devices like concentrators are covered by separate drafts/RFCs those documents should redefine the Observation Domain for those devices." So - We keep the IPFIX device definition as defined right now, and it doesn't cover the special devices from RFC3917. Anyway, those special devices are not covered in [IPFIX-ARCH]. - Then we can say: Observation Domain Id unique per IPFIX device Advantages: simple change Disadvantages: doesn't take into account the special device from RFC3917 *_Proposal 2:_* We add the Metering Process IP address in the IPFIX header. Note: this idea came up when reading Gerhard's email. Since this is a major change, feedback is more than welcome since I may have forgotten something. - We would augment the ipfix device to special devices from RFC 3917 - We would keep "the observation domain id is unique within the ipfix device" as in [IPFIX-ARCH], as it was favor by some people on the mailing list (Simon, Thomas, Paul, Lutz, Gerhard, myself). - This would work for special observation points, assuming that the metering process has got an IP address. +---+ +---+ +---+ | E-+-> | E-+-> | E-+------------->---+ | | | | | | | | | +---+ +-+-----+ +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> | | | | | | | | | | +---+ +-+-----+ +-+-+ +-+-+ | O | | M | | E-+->---+ | | | | +---+ | | | | | | | M | +-+-+ | O | | M | | | | | | | +---+ | | | +-----+ | O | | O | | O | ->-+-C-E-+-> +---+ +---+ +---+ +-----+ Protocol Remote Concentrator Proxy Converter Observation In case of a concentrator that would aggregate some data from multiple observation point/metering process, the IP address would be one of the new metering process, so the one of the concentrator. If the concentrator doesn't aggregate (simply re-export), then the initial metering process IP address is kept. - As a bonus, this would serve as the unique device identifier required by the multi-homed SCTP association (Brian's issues) when the Metering Process and Exporting Process are on the same physical box. So when both IP addresses (Metering Process IP address and source IP address of the export packet) are on the same box.... Not difficult to check via SNMP. - Note: IPv4 versus IPv6. We would need a bit somewhere in the header to differentiate the two types in the header. Advantage: this proposal takes care of the special devices in RFC3917 Disadvantage: this is a major change. Another round of reviews and last-call are certainly needed. Disadvantage: [IPFIX-ARCH] should also be changed to speak about the RFC3917 special devices. Considering that the session ID proposal is ugly (to use Brian's words), I only see these two proposals/solutions. Personally, I favor the proposal 1. Please let me know what you think. Regards, Benoit. > > Hope this is useful, and clarifies the threads on the subject a bit... > > Regards, > > Brian > > On May 30, 2006, at 11:08 AM, Benoit Claise wrote: > >> Dear all, >> >> I know it was addressed a couple of times on the mailing list. >> However, while discussing with Lutz Mark and Paul Aitken, I think we >> discovered the issue >> >> the definition of the observation domain id differs between >> ipfix-arch and ipfix-proto. >> >> -in ipfix-arch the id is unique within the ipfix device >> -in ipfix-proto the id is unique to the exporting process >> >> ------------------------------------------------------------ >> >> [ARCH] >> 5.4. Observation Domain >> >> The Observation Domain is a logical block that presents a single >> identity for a group of Observation Points within an IPFIX Device. >> Each {Observation Point, Metering Process} pair belongs to a single >> Observation Domain. An IPFIX Device could have multiple Observation >> Domains, each of which has a subset of the total set of Observation >> Points in it. Each Observation Domain must carry a unique ID within >> the context of an IPFIX Device. Note that in case of multiple >> Observation Domains, a unique ID per Observation Domain must be >> transmitted as a parameter to the Exporting Function. That unique ID >> is referred to as the IPFIX Observation Domain ID. >> >> >> [PROTO] >> 3.3 >> Observation Domain ID >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Observation Domain ID to uniquely identify >> to the Collecting Process the Observation Domain that >> metered the Flows. Collecting Processes SHOULD use the >> combination of the Exporter (exporterIPv4Address, >> exporterIPv6Address, or exportingProcessId) and the >> Observation Domain ID field to separate different export >> streams originating from the same Exporting Process. The >> Observation Domain ID SHOULD be 0 when no specific >> Observation Domain ID is relevant for the entire IPFIX >> Message. For example, when exporting the Exporting Process >> Statistics, or in case of hierarchy of Collector when >> aggregated data records are exported. >> >> >> We think that the Observation Domain Id should be unique per IPFIX >> Device, and not per Exporting Process. >> Otherwise, we could end up in the following situation: one sysadmin >> configures a set of observation points with observation domain 1, >> while a second sysadmin configures another set of observation points >> (on a different line card for example) with the same observation >> domain Id. >> If each observation domain exports using its own exporting process >> with the source IP address, how would the collector differentiate the >> template IDs? >> >> Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are not >> in sync. >> Multiple small changes (including in the terminology sections) should >> be inserted. For example: IPFIX-PROTO observation domain definition >> says "In the IPFIX Message it generates, the Observation Domain >> includes its Observation Domain ID, which is unique per Exporting >> Process. " >> >> Feedback? >> >> 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/ > --------------080300080601000100040402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian,

Thanks for this summary, and sorry for the delay.
Benoit,

The discussion on this has wandered a bit - to try to summarize and bring this to a decision (with apologies if this is either 1. something you've already decided or
Only WG consensus will :)
2. too late for tomorrow's call):
I consider this issue more important that respecting the deadline and having some issues with the published RFC afterwards.

1. The present IPFIX-PROTO solution of declaring observationDomainIDs (herein: odId) as unique per Exporting Process requires coordination of odId assignment among all the Exporting Processes in a given installation, and has a circular definition problem: Exporting Process identification if present in a message stream must be exported in a scoped data record; scoped data records require a template to interpret; templates are identified by a templateID; templateIDs are unique per odId; odIds are unique per Exporting Process ID.
We agree that this is the problem to be fixed, on the top of the following discrepancy:
-in [IPFIX-ARCH] the id is unique within the ipfix device
-in [IPFIX-PROTO] the id is unique to the exporting process

2. The present IPFIX-ARCH solution (and the proposed solution in the original message) of declaring odId as unique per IPFIX Device requires extension of the Device definition to cover processes such as proxies,
Well, let's say that the problem is slightly different. The IPFIX device definition doesn't match RFC3917
some method of coordinating odId assignment among multiple disparate processes on the same Device, and (possibly) the creation of a Device identifier so that odId uniqueness can be maintained in storage at the Collecting Process. This may also have the circular definition problem as above.

3. Declaring odId as unique per Session requires an explicit definition of Session (which is troublesome in the UDP case), and requires the storage of session details at the Collecting Process in order to keep persistent odId uniqueness, which is a little ugly. However, it avoids the circular uniqueness of templates.
We agree this is heavy, not to say ugly :)

Note the template circular definition problem goes away completely if templateIDs are defined to be unique per session, not per odId. This makes sense as templateIDs are less likely to be stored by the Collecting Process than odIds. The problem of templateID exhaustion (which is what I presume defining them to be unique per odId was intended to solve) goes away if you forbid templateIDs to be used as a general purpose scope, and use the commonPropertiesID (which is a 64-bit space as opposed to a 16-bit one) from reducing-redundancy instead.
Here is two proposals.

Proposal 1:
This is what I proposed initially, and summarized by Thomas:
"Since the base standard defines the IPFIX device as you cited above the
Observation Domain should - in my opinion - be unique per device. Since
devices like concentrators are covered by separate drafts/RFCs those
documents should redefine the Observation Domain for those devices."
So
- We keep the IPFIX device definition as defined right now, and it doesn't cover the special devices from RFC3917.
  Anyway, those special devices are not covered in [IPFIX-ARCH].
- Then we can say: Observation Domain Id unique per IPFIX device

Advantages: simple change
Disadvantages: doesn't take into account the special device from RFC3917


Proposal 2:
We add the Metering Process IP address in the IPFIX header. Note: this idea came up when reading Gerhard's email.
Since this is a major change, feedback is more than welcome since I may have forgotten something.
- We would augment the ipfix device to special devices from RFC 3917
- We would keep "the observation domain id is unique within the ipfix device" as in [IPFIX-ARCH], as it was favor by some people on the mailing list (Simon, Thomas, Paul, Lutz, Gerhard, myself).
- This would work for special observation points, assuming that the metering process has got an IP address.
       +---+     +---+     +---+
       | E-+->   | E-+->   | E-+------------->---+
       | | |     | | |     | | | +---+         +-+-----+
       +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
         |       | | |     | | | | | | +---+   +-+-----+
       +-+-+     +-+-+     | O | | M | | E-+->---+
       | | |       |       +---+ | | | | | |
       | M |     +-+-+           | O | | M |
       | | |     | | |           +---+ | | |           +-----+
       | O |     | O |                 | O |        ->-+-C-E-+->
       +---+     +---+                 +---+           +-----+

      Protocol   Remote             Concentrator        Proxy
      Converter  Observation
  In case of a concentrator that would aggregate some data from multiple observation point/metering process, the IP address would be one of the new metering process, so the one of the concentrator. If the concentrator doesn't aggregate (simply re-export), then the initial metering process IP address is kept.
- As a bonus, this would serve as the unique device identifier required by the multi-homed SCTP association (Brian's issues) when the Metering Process and Exporting Process are on the same physical box. So when both IP addresses (Metering Process IP address and source IP address of the export packet) are on the same box.... Not difficult to check via SNMP.
- Note: IPv4 versus IPv6. We would need a bit somewhere in the header to differentiate the two types in the header.

Advantage: this proposal takes care of the special devices in RFC3917
Disadvantage: this is a major change. Another round of reviews and last-call are certainly needed.
Disadvantage: [IPFIX-ARCH] should also be changed to speak about the RFC3917 special devices.



Considering that the session ID proposal is ugly (to use Brian's words), I only see these two proposals/solutions.
Personally, I favor the proposal 1. Please let me know what you think.

Regards, Benoit.

Hope this is useful, and clarifies the threads on the subject a bit...

Regards,

Brian

On May 30, 2006, at 11:08 AM, Benoit Claise wrote:

Dear all,

I know it was addressed a couple of times on the mailing list. However, while discussing with Lutz Mark and Paul Aitken, I think we discovered the issue

the definition of the observation domain id differs between
ipfix-arch and ipfix-proto.

-in ipfix-arch the id is unique within the ipfix device
-in ipfix-proto the id is unique to the exporting process

------------------------------------------------------------

[ARCH]
5.4.  Observation Domain

  The Observation Domain is a logical block that presents a single
  identity for a group of Observation Points within an IPFIX Device.
  Each {Observation Point, Metering Process} pair belongs to a single
  Observation Domain.  An IPFIX Device could have multiple Observation
  Domains, each of which has a subset of the total set of Observation
  Points in it.  Each Observation Domain must carry a unique ID within
  the context of an IPFIX Device.  Note that in case of multiple
  Observation Domains, a unique ID per Observation Domain must be
  transmitted as a parameter to the Exporting Function.  That unique ID
  is referred to as the IPFIX Observation Domain ID.


[PROTO]
3.3
  Observation Domain ID
          A 32-bit identifier of the Observation Domain that is
          locally unique to the Exporting Process.  The Exporting
          Process uses the Observation Domain ID to uniquely identify
          to the Collecting Process the Observation Domain that
          metered the Flows.  Collecting Processes SHOULD use the
          combination of the Exporter (exporterIPv4Address,
          exporterIPv6Address, or exportingProcessId) and the
          Observation Domain ID field to separate different export
          streams originating from the same Exporting Process.  The
          Observation Domain ID SHOULD be 0 when no specific
          Observation Domain ID is relevant for the entire IPFIX
          Message.  For example, when exporting the Exporting Process
          Statistics, or in case of hierarchy of Collector when
          aggregated data records are exported.


We think that the Observation Domain Id should be unique per IPFIX Device, and not per Exporting Process.
Otherwise, we could end up in the following situation: one sysadmin configures a set of observation points with observation domain 1, while a second sysadmin configures another set of observation points (on a different line card for example) with the same observation domain Id.
If each observation domain exports using its own exporting process with the source IP address, how would the collector differentiate the template IDs?

Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are not in sync.
Multiple small changes (including in the terminology sections) should be inserted. For example: IPFIX-PROTO observation domain definition says "In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. "

Feedback?

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/


--------------080300080601000100040402-- -- 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 Jun 09 11:37:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foj3P-00023S-HX for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 11:37:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foisd-0003bl-KM for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 11:26:35 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoiaT-0002Ii-5a for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 11:07:52 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FoiQt-0002s8-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 09:57:55 -0500 Received: from beniaminus.red.cert.org ([192.88.209.10]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FoiQr-0002rX-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 09 Jun 2006 09:57:54 -0500 Received: from beniaminus.red.cert.org (localhost [127.0.0.1]) by beniaminus.red.cert.org (8.13.1/8.13.1/2.20) with ESMTP id k59Evjob012835 for ; Fri, 9 Jun 2006 10:57:52 -0400 Received: (from defang@localhost) by beniaminus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k59EveOD012827 for ; Fri, 9 Jun 2006 10:57:40 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by beniaminus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k59Ev9Tb012796; Fri, 09 Jun 2006 10:57:40 -0400 (EDT) Received: from [128.237.238.58] (vpn-10-25-4-18.remote.cert.org [10.25.4.18]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.60) with ESMTP id k59Ev9Hc003932; Fri, 9 Jun 2006 10:57:09 -0400 In-Reply-To: <44898147.4000302@cisco.com> References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-3--240865377" Message-Id: <6F2F1190-D7A9-4DC6-A305-70EE032F4EC1@cert.org> Cc: ipfix-protocol@net.doit.wisc.edu, Lutz Mark , Gerhard Muenz , Juergen Quittek Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Date: Fri, 9 Jun 2006 10:57:06 -0400 To: Benoit Claise X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-3--240865377 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jun 9, 2006, at 10:10 AM, Benoit Claise wrote: >> (with apologies if this is either 1. something you've already >> decided or > Only WG consensus will :) >> 2. too late for tomorrow's call): > I consider this issue more important that respecting the deadline > and having some issues with the published RFC afterwards. Benoit, I was sort of hoping you'd say both these things. :) >> 1. The present IPFIX-PROTO solution of declaring >> observationDomainIDs (herein: odId) as unique per Exporting >> Process requires coordination of odId assignment among all the >> Exporting Processes in a given installation, and has a circular >> definition problem: Exporting Process identification if present in >> a message stream must be exported in a scoped data record; scoped >> data records require a template to interpret; templates are >> identified by a templateID; templateIDs are unique per odId; odIds >> are unique per Exporting Process ID. > We agree that this is the problem to be fixed, on the top of the > following discrepancy: > -in [IPFIX-ARCH] the id is unique within the ipfix device > -in [IPFIX-PROTO] the id is unique to the exporting process I think we can separate the templateId circularity problem and solve it separately from odId scoping merely by defining them as unique per session and not recommended for any sort of persistent storage. But that would seem now to be a different thread... >> 2. The present IPFIX-ARCH solution (and the proposed solution in >> the original message) of declaring odId as unique per IPFIX Device >> requires extension of the Device definition to cover processes >> such as proxies, > Well, let's say that the problem is slightly different. The IPFIX > device definition doesn't match RFC3917 >> some method of coordinating odId assignment among multiple >> disparate processes on the same Device, and (possibly) the >> creation of a Device identifier so that odId uniqueness can be >> maintained in storage at the Collecting Process. This may also >> have the circular definition problem as above. >> 3. Declaring odId as unique per Session requires an explicit >> definition of Session (which is troublesome in the UDP case), and >> requires the storage of session details at the Collecting Process >> in order to keep persistent odId uniqueness, which is a little >> ugly. However, it avoids the circular uniqueness of templates. > We agree this is heavy, not to say ugly :) I still think using a Session as a special scope is a good idea for non-persistent information; i.e., templates. >> >> Note the template circular definition problem goes away completely >> if templateIDs are defined to be unique per session, not per odId. >> This makes sense as templateIDs are less likely to be stored by >> the Collecting Process than odIds. The problem of templateID >> exhaustion (which is what I presume defining them to be unique per >> odId was intended to solve) goes away if you forbid templateIDs to >> be used as a general purpose scope, and use the commonPropertiesID >> (which is a 64-bit space as opposed to a 16-bit one) from reducing- >> redundancy instead. > Here is two proposals. > > Proposal 1: > This is what I proposed initially, and summarized by Thomas: > "Since the base standard defines the IPFIX device as you cited > above the Observation Domain should - in my opinion - be unique per > device. Since devices like concentrators are covered by separate > drafts/RFCs those documents should redefine the Observation Domain > for those devices." So > - We keep the IPFIX device definition as defined right now, and it > doesn't cover the special devices from RFC3917. > Anyway, those special devices are not covered in [IPFIX-ARCH]. > - Then we can say: Observation Domain Id unique per IPFIX device > > Advantages: simple change > Disadvantages: doesn't take into account the special device from > RFC3917 Also, this doesn't fix problems with the persistence of observationDomainId at the collector-side -- let's say I have odId scoped data (because I'm using commonPropertiesId which is unique per Observation Domain). Now I need to store some sort of Device identifier for each record. How do I generate this device ID at the collector side? If it's by layer3 remote address, we have all the same problems with multihomed SCTP. This would seem to point to proposal 2. But I'm not happy with proposal 2, for the reasons you've pointed out... Maybe I'm over-thinking this - maybe we _can_ realistically not address Collecting Process derivation of Device identifier for storage purposes, and simply say that it is up to each Collecting Process to allow user configuration to ensure it does not compare scopes or records across incomparable observationDomainIds. Then, we can use a few years of implementation experience to move toward a solution more like the second proposal in IPFIXv2. > Proposal 2: > We add the Metering Process IP address in the IPFIX header. Note: > this idea came up when reading Gerhard's email. If we're going to do this I'd suggest a 128-bit "Metering Process Identifier" with a requirement that Metering Processes MUST support the use of one of the Metering Process' IP addresses and SHOULD allow the user to configure the device with a different Metering Process Identifier, e.g. if a single machine with a single management interface is running multiple metering processes across multiple observation domains. Of course, now we're using 160 bits per message (128 mpId, 32 odId) as "root" scope. This seems excessive. > Since this is a major change, feedback is more than welcome since I > may have forgotten something. > - We would augment the ipfix device to special devices from RFC 3917 > - We would keep "the observation domain id is unique within the > ipfix device" as in [IPFIX-ARCH], as it was favor by some people on > the mailing list (Simon, Thomas, Paul, Lutz, Gerhard, myself). > - This would work for special observation points, assuming that the > metering process has got an IP address. (see above on metering process IP address differentiation) > +---+ +---+ +---+ > | E-+-> | E-+-> | E-+------------->---+ > | | | | | | | | | +---+ +-+-----+ > +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > | | | | | | | | | | +---+ +-+-----+ > +-+-+ +-+-+ | O | | M | | E-+->---+ > | | | | +---+ | | | | | | > | M | +-+-+ | O | | M | > | | | | | | +---+ | | | +-----+ > | O | | O | | O | ->-+-C-E-+-> > +---+ +---+ +---+ +-----+ > > Protocol Remote Concentrator Proxy > Converter Observation (I really like this diagram, by the way... it clarifies well what we mean by all the various special devices under consideration) > In case of a concentrator that would aggregate some data from > multiple observation point/metering process, the IP address would > be one of the new metering process, so the one of the concentrator. > If the concentrator doesn't aggregate (simply re-export), then the > initial metering process IP address is kept. > - As a bonus, this would serve as the unique device identifier > required by the multi-homed SCTP association (Brian's issues) when > the Metering Process and Exporting Process are on the same physical > box. So when both IP addresses (Metering Process IP address and > source IP address of the export packet) are on the same box.... Not > difficult to check via SNMP. > - Note: IPv4 versus IPv6. We would need a bit somewhere in the > header to differentiate the two types in the header. Or you could simply use a v6 address always and use v4 address mapping (see 2.5.5.2. IPv4-Mapped IPv6 Address, RFC 4291). > Advantage: this proposal takes care of the special devices in RFC3917 > Disadvantage: this is a major change. Another round of reviews and > last-call are certainly needed. If leaving device identification up to the Collecting Process' discretion is _at all_ acceptable, this disadvantage alone is more than enough to recommend Proposal 1. Regards, Brian --Apple-Mail-3--240865377 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEiYxF4/8LCZ4pwvYRAuuRAJ47a83BK+m5az28xhBe8m8mC508GgCfXted rb9ZAmgP/c3ZqpwbnMCTLkM= =XIG4 -----END PGP SIGNATURE----- --Apple-Mail-3--240865377-- -- 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 Jun 09 12:10:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FojZE-00065e-4d for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 12:10:36 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FojZC-0000to-M2 for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 12:10:36 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FojQW-0000NF-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 11:01:36 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FojQU-0000Me-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 09 Jun 2006 11:01:34 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k59G1Ql12535; Fri, 9 Jun 2006 18:01:26 +0200 (CEST) Received: from [10.61.81.20] (ams3-vpn-dhcp4373.cisco.com [10.61.81.20]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k59G1OC06116; Fri, 9 Jun 2006 18:01:24 +0200 (CEST) Message-ID: <44899B54.9040603@cisco.com> Date: Fri, 09 Jun 2006 18:01:24 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Brian Trammell CC: ipfix-protocol@net.doit.wisc.edu, Lutz Mark , Gerhard Muenz , Juergen Quittek Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <6F2F1190-D7A9-4DC6-A305-70EE032F4EC1@cert.org> In-Reply-To: <6F2F1190-D7A9-4DC6-A305-70EE032F4EC1@cert.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Brian, > > >>> 1. The present IPFIX-PROTO solution of declaring >>> observationDomainIDs (herein: odId) as unique per Exporting Process >>> requires coordination of odId assignment among all the Exporting >>> Processes in a given installation, and has a circular definition >>> problem: Exporting Process identification if present in a message >>> stream must be exported in a scoped data record; scoped data records >>> require a template to interpret; templates are identified by a >>> templateID; templateIDs are unique per odId; odIds are unique per >>> Exporting Process ID. >> We agree that this is the problem to be fixed, on the top of the >> following discrepancy: >> -in [IPFIX-ARCH] the id is unique within the ipfix device >> -in [IPFIX-PROTO] the id is unique to the exporting process > > I think we can separate the templateId circularity problem and solve > it separately from odId scoping merely by defining them as unique per > session and not recommended for any sort of persistent storage. But > that would seem now to be a different thread... > >>> 2. The present IPFIX-ARCH solution (and the proposed solution in the >>> original message) of declaring odId as unique per IPFIX Device >>> requires extension of the Device definition to cover processes such >>> as proxies, >> Well, let's say that the problem is slightly different. The IPFIX >> device definition doesn't match RFC3917 >>> some method of coordinating odId assignment among multiple disparate >>> processes on the same Device, and (possibly) the creation of a >>> Device identifier so that odId uniqueness can be maintained in >>> storage at the Collecting Process. This may also have the circular >>> definition problem as above. > >>> 3. Declaring odId as unique per Session requires an explicit >>> definition of Session (which is troublesome in the UDP case), and >>> requires the storage of session details at the Collecting Process in >>> order to keep persistent odId uniqueness, which is a little ugly. >>> However, it avoids the circular uniqueness of templates. >> We agree this is heavy, not to say ugly :) > > I still think using a Session as a special scope is a good idea for > non-persistent information; i.e., templates. > >>> >>> Note the template circular definition problem goes away completely >>> if templateIDs are defined to be unique per session, not per odId. >>> This makes sense as templateIDs are less likely to be stored by the >>> Collecting Process than odIds. The problem of templateID exhaustion >>> (which is what I presume defining them to be unique per odId was >>> intended to solve) goes away if you forbid templateIDs to be used as >>> a general purpose scope, and use the commonPropertiesID (which is a >>> 64-bit space as opposed to a 16-bit one) from reducing-redundancy >>> instead. >> Here is two proposals. >> >> Proposal 1: >> This is what I proposed initially, and summarized by Thomas: >> "Since the base standard defines the IPFIX device as you cited above >> the Observation Domain should - in my opinion - be unique per device. >> Since devices like concentrators are covered by separate drafts/RFCs >> those documents should redefine the Observation Domain for those >> devices." So >> - We keep the IPFIX device definition as defined right now, and it >> doesn't cover the special devices from RFC3917. >> Anyway, those special devices are not covered in [IPFIX-ARCH]. >> - Then we can say: Observation Domain Id unique per IPFIX device >> >> Advantages: simple change >> Disadvantages: doesn't take into account the special device from RFC3917 > > Also, this doesn't fix problems with the persistence of > observationDomainId at the collector-side However in practice, the common sense imposes that for a router, the slot number is used (or a line card for a probe): observationDomainId 1 is for line card 1 observationDomainId 2 is for line card 2 etc... So, I'm wondering if this persistence would happen a lot in practice. This is why I'm in favor of this proposal 1: common sense would solve it. > -- let's say I have odId scoped data (because I'm using > commonPropertiesId which is unique per Observation Domain). Now I need > to store some sort of Device identifier for each record. How do I > generate this device ID at the collector side? [IPFIX-PROTO]: Collecting Processes SHOULD use the combination of the Exporter (exporterIPv4Address, exporterIPv6Address, or exportingProcessId) and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. In the worst case, i.e. SCTP and source IP address change because of the multi-homed feature (which takes by default the IP address of the outgoing interface), the collector would have to check whether both IP addresses are coming from the same exporter. As simple snmpwalk would tell us that. Optionally, a Option Template could help. Note: there is a unique SCTP AssociationId (32 bit integer, unique for the association life time) which could be used, but the new issue is that we would have a different behaviour per transport protocol. > If it's by layer3 remote address, we have all the same problems with > multihomed SCTP. This would seem to point to proposal 2. But I'm not > happy with proposal 2, for the reasons you've pointed out... > > Maybe I'm over-thinking this - maybe we _can_ realistically not > address Collecting Process derivation of Device identifier for storage > purposes, and simply say that it is up to each Collecting Process to > allow user configuration to ensure it does not compare scopes or > records across incomparable observationDomainIds. Then, we can use a > few years of implementation experience to move toward a solution more > like the second proposal in IPFIXv2. This is also why I prefer proposal 1. We concluded a few times already that a IPFIX version 2 might have a flexible header.... > >> Proposal 2: >> We add the Metering Process IP address in the IPFIX header. Note: >> this idea came up when reading Gerhard's email. > > If we're going to do this I'd suggest a 128-bit "Metering Process > Identifier" with a requirement that Metering Processes MUST support > the use of one of the Metering Process' IP addresses and SHOULD allow > the user to configure the device with a different Metering Process > Identifier, e.g. if a single machine with a single management > interface is running multiple metering processes across multiple > observation domains. The management of it doesn't seem obvious at first glance. Regards, Benoit. > > Of course, now we're using 160 bits per message (128 mpId, 32 odId) as > "root" scope. This seems excessive. > >> Since this is a major change, feedback is more than welcome since I >> may have forgotten something. >> - We would augment the ipfix device to special devices from RFC 3917 >> - We would keep "the observation domain id is unique within the ipfix >> device" as in [IPFIX-ARCH], as it was favor by some people on the >> mailing list (Simon, Thomas, Paul, Lutz, Gerhard, myself). >> - This would work for special observation points, assuming that the >> metering process has got an IP address. > > (see above on metering process IP address differentiation) > >> +---+ +---+ +---+ >> | E-+-> | E-+-> | E-+------------->---+ >> | | | | | | | | | +---+ +-+-----+ >> +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> >> | | | | | | | | | | +---+ +-+-----+ >> +-+-+ +-+-+ | O | | M | | E-+->---+ >> | | | | +---+ | | | | | | >> | M | +-+-+ | O | | M | >> | | | | | | +---+ | | | +-----+ >> | O | | O | | O | ->-+-C-E-+-> >> +---+ +---+ +---+ +-----+ >> >> Protocol Remote Concentrator Proxy >> Converter Observation > > (I really like this diagram, by the way... it clarifies well what we > mean by all the various special devices under consideration) > >> In case of a concentrator that would aggregate some data from >> multiple observation point/metering process, the IP address would be >> one of the new metering process, so the one of the concentrator. If >> the concentrator doesn't aggregate (simply re-export), then the >> initial metering process IP address is kept. >> - As a bonus, this would serve as the unique device identifier >> required by the multi-homed SCTP association (Brian's issues) when >> the Metering Process and Exporting Process are on the same physical >> box. So when both IP addresses (Metering Process IP address and >> source IP address of the export packet) are on the same box.... Not >> difficult to check via SNMP. >> - Note: IPv4 versus IPv6. We would need a bit somewhere in the header >> to differentiate the two types in the header. > > Or you could simply use a v6 address always and use v4 address mapping > (see 2.5.5.2. IPv4-Mapped IPv6 Address, RFC 4291). > >> Advantage: this proposal takes care of the special devices in RFC3917 >> Disadvantage: this is a major change. Another round of reviews and >> last-call are certainly needed. > > If leaving device identification up to the Collecting Process' > discretion is _at all_ acceptable, this disadvantage alone is more > than enough to recommend Proposal 1. > > Regards, > > Brian -- 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 wygant@axiscorp.com Fri Jun 09 16:56:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Foo29-0002Ou-9e for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 16:56:45 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foo28-0006oh-1v for ipfix-archive@lists.ietf.org; Fri, 09 Jun 2006 16:56:45 -0400 Received: from 200141125192.user.veloxzone.com.br ([200.141.125.192] helo=axiscorp.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FonPv-00034B-00 for ipfix-list@mil.doit.wisc.edu; Fri, 09 Jun 2006 15:17:16 -0500 Message-ID: <000001c68c01$b2198270$727ba8c0@pzx92> Reply-To: "Lucien Wygant" From: "Lucien Wygant" To: ipfix-list@mil.doit.wisc.edu Subject: Re: syzyj refnnce Date: Fri, 9 Jun 2006 13:17:13 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68BC7.05BAAA70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68BC7.05BAAA70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, $ 2 a 00, 0 g 00 Loa n n for o u nly $ 82 f 7 month.=20 B y AD CR l EDI i T Ok d ! http://m0rt15.net _____ =20 fallen in! Bombur is drowning! he cried. It was only too true. Bombur had only one foot on the land when the hart bore down on him, and sprang over him. He had stumbled, thrusting the boat away from the bank, and then toppled back into the dark water, his hands slipping off the slimy ------=_NextPart_000_0001_01C68BC7.05BAAA70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

$ 2 a 00, 0 g 00 Loa n n for o u nly $ 82 f 7 month.

B y AD CR l EDI i T Ok d ! http://m0rt15.net


fallen in! Bombur is drowning! he = cried. It was only too true. Bombur
had only one foot on the land when the hart bore down on him, and = sprang
over him. He had stumbled, thrusting the boat away from the bank, = and
then toppled back into the dark water, his hands slipping off the = slimy
------=_NextPart_000_0001_01C68BC7.05BAAA70-- From majordomo@mil.doit.wisc.edu Sat Jun 10 08:17:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp2Oy-0002u7-A8 for ipfix-archive@lists.ietf.org; Sat, 10 Jun 2006 08:17:16 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp2Ow-0003zw-T9 for ipfix-archive@lists.ietf.org; Sat, 10 Jun 2006 08:17:16 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fp2Jc-0005jX-00 for ipfix-list@mil.doit.wisc.edu; Sat, 10 Jun 2006 07:11:44 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fp2Jb-0005ia-00 for ipfix-protocol@net.doit.wisc.edu; Sat, 10 Jun 2006 07:11:43 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2006 14:11:42 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5ACBVrq028273; Sat, 10 Jun 2006 14:11:41 +0200 (MEST) Received: from [10.58.48.99] ([10.58.48.99]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA03430; Sat, 10 Jun 2006 13:11:29 +0100 (BST) Message-ID: <448AB6F0.8050304@cisco.com> Date: Sat, 10 Jun 2006 13:11:28 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Benoit Claise CC: Brian Trammell , ipfix-protocol@net.doit.wisc.edu, Lutz Mark , Gerhard Muenz , Juergen Quittek Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> In-Reply-To: <44898147.4000302@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Benoit, > *_Proposal 2:_* > We add the Metering Process IP address in the IPFIX header. Note: this > idea came up when reading Gerhard's email. > Since this is a major change, feedback is more than welcome since I may > have forgotten something. Then all the flows in one export packet must come from the same Metering Process IP address. This makes it difficult for multiple Metering Processes with different IP addresses to be associated with a single Exporting Process, since the EP would have to maintain seperate export packets for each unique Metering Process IP address that it's currently dealing with. eg, consider multiple line cards, each with its own MP and own MP address, but exporting through a single export process on an RP. The RP export process must maintain individual exports for each MP address (ie, each LC), so it effectively becomes a set of virtual exporters, one for each LC. But without the Metering Process IP address in the IPFIX header, the EP can mix flows from many different MP into one export packet. If the Metering Process IP address is required then it should be in the flow data (or common properties) and not in the IPFIX header. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 trahaearne@hitchcock.org Sat Jun 10 09:52:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp3tZ-0001iH-9L for ipfix-archive@lists.ietf.org; Sat, 10 Jun 2006 09:52:57 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp3sk-0000Zz-Ll for ipfix-archive@lists.ietf.org; Sat, 10 Jun 2006 09:52:07 -0400 Received: from ol119-44.fibertel.com.ar ([24.232.44.119] helo=hitchcock.org) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Fp3nY-0003qG-00 for ipfix-list@mil.doit.wisc.edu; Sat, 10 Jun 2006 08:46:44 -0500 Message-ID: <000001c68c94$49316460$ef85a8c0@glo52> Reply-To: "Trahaearn Negrete" From: "Trahaearn Negrete" To: ipfix-list@mil.doit.wisc.edu Subject: Re: johie refnace Date: Sat, 10 Jun 2006 06:46:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68C59.9CD28C60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?24.232.44.119 X-Spam-Score: 2.5 (++) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68C59.9CD28C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, $ s 20 s 0,0 z 00 L o oa q n for o z nl g y $ v 82 d 7 month.=20 BA o D C x RE e DI x T O y k v u is v it the s k it d e =20 _____ =20 Chapter 6 Out of the Frying-Pan into the Fire Bilbo had escaped the goblins, but he did not know where he was. He had lost hood, cloak, food, pony, his buttons and his friends. He ------=_NextPart_000_0001_01C68C59.9CD28C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

$ s 20 s 0,0 z 00 L o oa q n for o z nl g y $ v 82 d 7 month.

BA o D C x RE e DI x T O y k v u is v it the s k it d e


Chapter 6
Out of the Frying-Pan into the Fire
Bilbo had escaped the goblins, but he did not know where he was. = He
had lost hood, cloak, food, pony, his buttons and his friends. = He
------=_NextPart_000_0001_01C68C59.9CD28C60-- From Brendan.Valencia@grim.ilzey.net Sat Jun 10 10:05:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fp45t-0001nq-E7 for ipfix-archive@lists.ietf.org; Sat, 10 Jun 2006 10:05:41 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fp45s-0002oh-7K for ipfix-archive@lists.ietf.org; Sat, 10 Jun 2006 10:05:41 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fp40i-0004L8-00; Sat, 10 Jun 2006 09:00:22 -0500 Received: from 553F9110 ([201.19.148.126]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5AE0DvG023989; Sat, 10 Jun 2006 09:00:18 -0500 Received: from smtp12.surferboard.com (172.16.1.077) by smtp3.libero.it (7.0.027-6CO4) id M4S09G491ZO823B1; Sat, 10 Jun 2006 09:00:14 -0600 Received-SPF: none (smtp17.foreverbeyonce.com: 151.49.44.09 is neither permitted nor denied by domain of aciss.com) client-ip=151.49.44.09; envelope-from=Juliette.Baird@aciss.com; helo=aciss.com; Message-ID: Date: Sat, 10 Jun 2006 09:00:14 -0600 Reply-to: "Arturo Purcell" From: "Arturo Purcell" X-Accept-Language: en-us MIME-Version: 1.0 To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu Subject: Re:What is up Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 0972-3, 01/02/2006), Outbound message X-Antivirus-Status: Not-Tested X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 The average home-loan we've given out this month is $700,000.00 @ 3.55% Worried about your current financial situation? Horrible credit does not matter! Last 3 loans-closed today: 3 bed 2 bath @ 4.15% $277,000.00 5 bed 2 bath @ 4.39% $319,000.00 5 bed 5 bath @ 3.28% $713,000.00 http://mx.geocities.com/lamesa_espraber From adairrogers@cimdesign.com Sun Jun 11 18:03:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpY1k-00052U-TV for ipfix-archive@lists.ietf.org; Sun, 11 Jun 2006 18:03:24 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpY1j-0003Gw-LJ for ipfix-archive@lists.ietf.org; Sun, 11 Jun 2006 18:03:24 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FpXPG-0003aw-00 for ipfix-list@mil.doit.wisc.edu; Sun, 11 Jun 2006 16:23:38 -0500 Received: from BABY (182.Red-83-39-137.dynamicIP.rima-tde.net [83.39.137.182]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5BLNZtQ010384 for ; Sun, 11 Jun 2006 16:23:36 -0500 Message-Id: <00cb01c68d94$2316a280$b6cf3647@igzkrrw> From: "sybilla valencia" To: "tatum jaramillo" Subject: Free bonus money Date: Sun, 11 Jun 2006 20:27:50 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CB_01C68D94.2316A280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.7 (++) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_00CB_01C68D94.2316A280 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable People are winning Big every day. We have -LIVE- tableGames. Over 60 games to choose from. Why leave home for vegas style action? http://grontop.com/casino/ brine-cooling sporting editor wood feller skunk porpoise shad-bellied ice color square-cut hell-engendered fish warden fellow helper stilbene dye odd-me-dod crust-hunt self-applauding sun-courting wool-eating best-selling dial bird ten-grain reciprocity law eye-searing two-celled rich-laden steering engine ------=_NextPart_000_00CB_01C68D94.2316A280 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
People are winning Big every day. We have -LIVE- tableGames.
Over 60 games to choose from. Why leave home for vegas style action?
http://grontop.com/casino/

brine-cooling sporting editor wood feller
skunk porpoise shad-bellied ice color
square-cut hell-engendered fish warden
fellow helper stilbene dye odd-me-dod
crust-hunt self-applauding sun-courting
wool-eating best-selling dial bird
ten-grain reciprocity law eye-searing
two-celled rich-laden steering engine
= ------=_NextPart_000_00CB_01C68D94.2316A280-- From awayba@cheyenne-ent.com Mon Jun 12 13:48:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpqWy-0005DK-Hm for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 13:48:52 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpqWx-0000wu-B4 for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 13:48:52 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fppsm-0003wB-00; Mon, 12 Jun 2006 12:07:21 -0500 Received: from 45BD780 ([59.44.93.210]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5CH78jv019866; Mon, 12 Jun 2006 12:07:13 -0500 Received: by equifax-mail.com (PowerMTA(TM) v3.0r8) id tqmro0477x62; Mon, 12 Jun 2006 12:07:07 -0600 (envelope-from ) Thread-Topic: Re:Sir. X-BPS2: 1 X-BPS1: 15gnr X-campaignid: M.01003-H.53688-N.15gnr-HU.1 thread-index: dugYhF7PCoxhAxEETM8d9DYf4215lG== Reply-to: "Eileen Emery" From: "Eileen Emery" To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu Subject: Re:Sir. Date: Mon, 12 Jun 2006 12:07:07 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 The average home-loan we've given out this month is $700,000.00 @ 3.52% Worried about your current financial situation? Horrible credit does not matter! Last 3 loans-closed today: 3 bed 2 bath @ 4.15% $277,000.00 5 bed 2 bath @ 4.39% $319,000.00 5 bed 5 bath @ 3.28% $713,000.00 http://es.geocities.com/vietnam_veterans1 From advertising@numericable.fr Mon Jun 12 16:30:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fpt3p-0006nB-TC for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 16:30:57 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fpt3o-0002eR-Jx for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 16:30:57 -0400 Received: from ip-187.net-81-220-162.rev.numericable.fr ([81.220.162.187]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Fpt02-0007Dt-00 for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jun 2006 15:27:03 -0500 Message-ID: <000501c68e5c$c16ee0b0$bba2dc51@numericable.fr> Reply-To: acecheckcash@aol.com From: advertising@4webmarketing.biz To: ipfix-list@mil.doit.wisc.edu Subject: =?us-ascii?B?QUNFIENoZWNrIEV4cHJlc3MgSW5jLiBoYXMgaW1tZWRpYXRlIHdv?= =?us-ascii?B?cmsgZm9yIEF1c3RyYWxpYW4gYW5kIE5ldyBaZWFsYW5kIGNpdGl6?= =?us-ascii?B?ZW5z?= Date: Mon, 12 Jun 2006 16:14:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced by Microsoft MimeOLE 6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ACE Check Express Inc. was founded in 1996 as a partner and connecting link between hundreds of banks in the world engaged in e-commerce. Our specialists from the Institute of Economic Research created the ACE Money Turnover® - the system that ensured quality, high speed and reliability of money transfer. As of today, ACE Check Express Inc. is not only a link in a big chain of the world financial flows, but also an independent segment whose services are impossible to do without even for such bank as the Citibank (www.citibank.com). That is why our managers, from beginners to professionals in the money transfer, use the accounts of the Citibank for the Citibank has been our customer in the field of on-line money transfer and conversion into cash services since 2002. We are proud of the reliability of our system, which ensures safe money transfers via Internet between our clients wherever they are. Dream of becoming a manager with a high salary? We only promote those opportunities which are legitimate. We are very passionate about protecting you from companies that don't deliver what they promise. We understand that our reputation is at stake. Most of the jobs require only a computer and an internet connection (and if you're reading this, you obviously have access to both). Want to be home with your kids, but still need extra income? It's time to start your own lucrative home-based business. Look for a work at home job or home based business opportunities. So don't let this opportunity pass you by. We urge you to consider this opportunity while you still have time, and let us hear from you soon? act today Have you ever wondered how some people can appear to do far less than you do in a day ...and yet they have more money and more free time than you will ever get to see? Let's face it... deep inside you know there is better way. And you are absolutely right! Be among the FIRST in your area to take advantage of this once-in-a-lifetime opportunity. Make More Money Be Your Own Boss Work When YOU Want to Live the Lifestyle You Deserve You can start to work at home today! There are no fees involved, No Money to spend, Ever !!! What we ask: # 10-12 free hours weekly - not including weekends. # Internet access for sending and receiving e-mails. # Home and cell phone for incoming and outgoing calls # You must be over 20 years old. # Australian or New Zealand citizenship. There will be no fees at any kind to work with us. There is no cold calling, no telemarketing, no door to door sales and no relying on friends and family. Just send the resume and one member of our company will contact you as soon as possible. No experience necessary Don't miss chance to work as our financial representative! Start new career with ACE Check Cashing Group, our motto - Financial stability for us and our partners. APPLICATION: Your confidential details will be used only within our company. Every perspective employee, who suits our requirements, will be contacted by our company's executive to carry out a basic phone or email interview. During the interview you will be able to ask any questions you might have. To continue with the application process please fill in the form below and send it back to our email: acecheckcash@aol.com 1. Your Full name: 2. Present Address (street): 3. City: 4. State: 5. Zip/Postal: 6. Country: 7. Email: 8. Age: 9. Employment desired (Full-time or Part-time): 10. Have you any accounts with banks?: (If yes, please mention the Name of the Bank). 11. Additional information about yourself: (Just copy this form to your reply) Please feel free to ask us any questions you may have. All emails should be directed to: acecheckcash@aol.com Regards, Julia Bordovsky HR recruiter ACE Cashing Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 Web Marketing Internet Advertising Agency Australia Manager 194 The Esplanade Scarborough Beach Perth Western Australia 6019 No Soliciting Business to Business Advertising ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have questions or comments for 4 Web Marketing, please use our feedback form. This email was sent from Account ID AQ72X5Y9XY8RJMQDDX and by this logged in User U8A38P5WVT2TS1YX6BF From franklinkidd@korea-dpr.com Mon Jun 12 18:07:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpuZS-0006YG-JQ for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 18:07:42 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpuZR-0007FC-BB for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 18:07:42 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FpuUw-00015k-00 for ipfix-list@mil.doit.wisc.edu; Mon, 12 Jun 2006 17:03:02 -0500 Received: from BABY (cpe-24-210-249-106.woh.res.rr.com [24.210.249.106]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5CM2vQ7026678 for ; Mon, 12 Jun 2006 17:02:57 -0500 Message-Id: <002801c68e63$95a28380$c20add50@bckc> From: "nara hudson" To: "max wilson" Subject: Huge jackpot! Date: Mon, 12 Jun 2006 21:07:38 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C68E63.95A28380" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C68E63.95A28380 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable People are winning Big every day. We have -LIVE- tableGames. Over 60 games to choose from. Why leave home for vegas style action? - $ 888 start balance - 24for7 support - Instant payouts http://plukiq.com/casino/ shaving paste proud-crested sea language sky-planted cellar book bean cake well-solved tawny-olive jungle cock stick-ear grass-hook white-blooded Kniffin system ground tow fishing dory zone-confounding self-invention well-experienced ------=_NextPart_000_0028_01C68E63.95A28380 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
People are winning Big every day. We have -LIVE- tableGames.
Over 60 games to choose from. Why leave home for vegas style action?
- $ 888 start balance
- 24for7 support
- Instant payouts
http://plukiq.com/casino/

shaving paste proud-crested sea language
sky-planted cellar book bean cake
well-solved tawny-olive jungle cock
stick-ear grass-hook white-blooded
Kniffin system ground tow fishing dory
zone-confounding self-invention well-experienced
= ------=_NextPart_000_0028_01C68E63.95A28380-- X-Antivirus: avast! (VPS 0624-0, 06/11/2006), Outbound message X-Antivirus-Status: Clean From incantve@atlantic-national.com Mon Jun 12 18:49:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpvDc-0008LK-8F for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 18:49:12 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpvDb-0001WU-1d for ipfix-archive@lists.ietf.org; Mon, 12 Jun 2006 18:49:12 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fpv9n-0001ef-00; Mon, 12 Jun 2006 17:45:15 -0500 Received: from 1C22388 (200-127-187-66.cab.prima.net.ar [200.127.187.66] (may be forged)) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5CMj4NQ030261; Mon, 12 Jun 2006 17:45:08 -0500 Received: from 63.97.179.46 (zcd3.romancebounty.com) (63.97.179.46) by mta142.mail.scd.yahoo.com with SMTP; Mon, 12 Jun 2006 17:45:02 -0600 MIME-Version: 1.0 X-Accept-Language: en X-Priority: Normal From: "Jamie Alvarado" To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu Subject: Re:American Residents Date: Mon, 12 Jun 2006 17:45:02 -0600 Message-ID: <1-05693605-Y7MQlKsC8Vm7HM7HZz9ovrc@idb2.romancebounty.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 The average home-loan we've given out this month is $700,000.00 @ 3.52% Worried about your current financial situation? Horrible credit does not matter! Last 3 loans-closed today: 3 bed 2 bath @ 4.15% $277,000.00 5 bed 2 bath @ 4.39% $319,000.00 5 bed 5 bath @ 3.28% $713,000.00 http://ar.geocities.com/hawke3_aramis From majordomo@mil.doit.wisc.edu Tue Jun 13 03:42:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq3Xd-0004YW-Ru for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 03:42:25 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq3Xc-0002zz-Gu for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 03:42:25 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fq3PN-0004UG-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 02:33:53 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fq3PL-0004UB-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 02:33:51 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 2BD6D11C for ; Tue, 13 Jun 2006 09:33:50 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25156-05 for ; Tue, 13 Jun 2006 09:33:47 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id E5F0811B for ; Tue, 13 Jun 2006 09:33:46 +0200 (MST) Message-ID: <448DF34A.6090409@informatik.uni-tuebingen.de> Date: Tue, 13 Jun 2006 01:05:46 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> In-Reply-To: <448AB6F0.8050304@cisco.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030704080405080701040209" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.2 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 This is a cryptographically signed message in MIME format. --------------ms030704080405080701040209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, I'll try to make a final statement on this topic, after rereading all the mails of the last weeks. I could live with both odId unique per Exporting Process or unique per IPFIX Device. I think there is no big difference and t is more a philosophic question. E.g. I have no problem considering two instances of a monitoring probe software that are running on the same machine and capture packets on the same interface, as two different devices or two different exporters on a single device. It does not really matter to me. I'm not in favor of uniqueness per session. It makes things more complicated. Consider a monitor that crashes and restarts with the same configuration, and you are not allowed to treat old and new monitoring data the same way... Usually the administrator knows about his monitoring probes and when bigger configuration changes occur that result in different monitoring data than before. My opinion concerning the discussion of persistence of scopes, Template IDs etc. is that we should restrict our responsability to the path from the observation point to the collector and not any further. If done with care, Template IDs can serve as scopes on this path. If the administrator wants to store the monitoring data and requires long-term persistence of this information, it's up to him to store additional context information. I would like to consider concentrators, proxies etc. as IPFIX Devices. They come with their own Exporting Process(es), so uniqueness per Exporting Process or uniqueness per Device makes no big difference. They can either set odId to zero or - if it makes sense - they can use odId to specify some kind of virtual Observation Domains. The administrator will know that such identifiers do not correspond to physical interfaces. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms030704080405080701040209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MDYxMjIzMDU0NlowIwYJKoZIhvcNAQkEMRYEFEdoRHQYJoxM JY4xf8HS7G4oOaQFMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQDTC7fYgLJkgDOs8deK54MNEmHcLG/bXsGFhdP/C5r38lxSO9oPI9w3pbip G6st5I4L8JlMsjunrWkUO8egu8jORPvo8Jg05cyHupfEq/F2LhLpYM8F2fsQXrJ0KCuAqOG9 TB6ffPBlCyWY85NFz/LoPOGOAP205JLHb8VGmA+of8xVILNxHNsk4S9u7MO0rrMoIEpJM/hi kYiJfxvDfHfbKxn5SfKivnk4AzxcImPn11pmCm8hWPgA9rf4NdXK8yxsz6z5QP2S2QqPObK+ zC9OnZs0zmFsIuI+Pf14/FccBLVWzf+g5UqMzSZBQH7UB07H/qV0L3RTiZ7D0A6EQPc+AAAA AAAA --------------ms030704080405080701040209-- -- 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 Jun 13 06:18:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq5yf-00060l-AP for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 06:18:29 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq5ye-0000aP-0L for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 06:18:29 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fq5sF-0001J0-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 05:11:51 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fq5sE-0001Iv-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 05:11:50 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k5DABPn08627; Tue, 13 Jun 2006 12:11:25 +0200 (MEST) Message-ID: <448E8F4F.2070102@fokus.fraunhofer.de> Date: Tue, 13 Jun 2006 12:11:27 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Benoit Claise CC: Brian Trammell , ipfix-protocol@net.doit.wisc.edu, Gerhard Muenz , Juergen Quittek Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> In-Reply-To: <44898147.4000302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Dear all, > Here is two proposals. > > *_Proposal 1: _* > This is what I proposed initially, and summarized by Thomas: > > "Since the base standard defines the IPFIX device as you cited above the > Observation Domain should - in my opinion - be unique per device. Since > devices like concentrators are covered by separate drafts/RFCs those > documents should redefine the Observation Domain for those devices." > > So > - We keep the IPFIX device definition as defined right now, and it > doesn't cover the special devices from RFC3917. > Anyway, those special devices are not covered in [IPFIX-ARCH]. > - Then we can say: Observation Domain Id unique per IPFIX device > > Advantages: simple change > Disadvantages: doesn't take into account the special device from RFC3917 > > > *_Proposal 2:_* > We add the Metering Process IP address in the IPFIX header. Note: this > idea came up when reading Gerhard's email. > Since this is a major change, feedback is more than welcome since I may > have forgotten something. > - We would augment the ipfix device to special devices from RFC 3917 > - We would keep "the observation domain id is unique within the ipfix > device" as in [IPFIX-ARCH], as it was favor by some people on the > mailing list (Simon, Thomas, Paul, Lutz, Gerhard, myself). > - This would work for special observation points, assuming that the > metering process has got an IP address. > > +---+ +---+ +---+ > | E-+-> | E-+-> | E-+------------->---+ > | | | | | | | | | +---+ +-+-----+ > +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> > | | | | | | | | | | +---+ +-+-----+ > +-+-+ +-+-+ | O | | M | | E-+->---+ > | | | | +---+ | | | | | | > | M | +-+-+ | O | | M | > | | | | | | +---+ | | | +-----+ > | O | | O | | O | ->-+-C-E-+-> > +---+ +---+ +---+ +-----+ > > Protocol Remote Concentrator Proxy > Converter Observation > > In case of a concentrator that would aggregate some data from multiple > observation point/metering process, the IP address would be one of the > new metering process, so the one of the concentrator. If the > concentrator doesn't aggregate (simply re-export), then the initial > metering process IP address is kept. > - As a bonus, this would serve as the unique device identifier required > by the multi-homed SCTP association (Brian's issues) when the Metering > Process and Exporting Process are on the same physical box. So when both > IP addresses (Metering Process IP address and source IP address of the > export packet) are on the same box.... Not difficult to check via SNMP. > - Note: IPv4 versus IPv6. We would need a bit somewhere in the header to > differentiate the two types in the header. > > Advantage: this proposal takes care of the special devices in RFC3917 > Disadvantage: this is a major change. Another round of reviews and > last-call are certainly needed. > Disadvantage: [IPFIX-ARCH] should also be changed to speak about the > RFC3917 special devices. > > > > Considering that the session ID proposal is ugly (to use Brian's words), > I only see these two proposals/solutions. > Personally, I favor the proposal 1. Please let me know what you think. Proposal 3: o update IPFIX Device Definition and IPFIX-ARCH to cover special devices. o OberservationDomainID unique per IPFIX Device (the initial idea was to have a source id, which could be e.g. the IPv4 address of the device) o TemplateIDs locally unique on the path between exporter and collector. advantage: simple change. in line with RFC3917 disadvantage: ObservationDomainID collisions have to be avoided out of band. Best regards, Lutz -- 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 Jun 13 11:38:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqAyR-000380-Bd for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 11:38:35 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqAyP-0007lY-W5 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 11:38:35 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqARx-0000e9-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 10:05:01 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqARw-0000da-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 10:05:00 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6F5B41BAC4D; Tue, 13 Jun 2006 16:54:02 +0200 (CEST) Date: Tue, 13 Jun 2006 17:04:55 +0200 From: Juergen Quittek To: Lutz Mark , Benoit Claise Cc: Brian Trammell , ipfix-protocol@net.doit.wisc.edu, Gerhard Muenz Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: <9B81B43D64E4F9B90F0A3123@[10.1.1.104]> In-Reply-To: <448E8F4F.2070102@fokus.fraunhofer.de> References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448E8F4F.2070102@fokus.fraunhofer.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Lutz, Just a quick comment: --On 13.06.2006 12:11 Uhr +0200 Lutz Mark wrote: > > Dear all, > >> Here is two proposals. >> >> *_Proposal 1: _* >> This is what I proposed initially, and summarized by Thomas: >> >> "Since the base standard defines the IPFIX device as you cited above the >> Observation Domain should - in my opinion - be unique per device. Since >> devices like concentrators are covered by separate drafts/RFCs those >> documents should redefine the Observation Domain for those devices." >> >> So >> - We keep the IPFIX device definition as defined right now, and it >> doesn't cover the special devices from RFC3917. >> Anyway, those special devices are not covered in [IPFIX-ARCH]. >> - Then we can say: Observation Domain Id unique per IPFIX device >> >> Advantages: simple change >> Disadvantages: doesn't take into account the special device from RFC3917 >> >> >> *_Proposal 2:_* >> We add the Metering Process IP address in the IPFIX header. Note: this >> idea came up when reading Gerhard's email. >> Since this is a major change, feedback is more than welcome since I may >> have forgotten something. >> - We would augment the ipfix device to special devices from RFC 3917 >> - We would keep "the observation domain id is unique within the ipfix >> device" as in [IPFIX-ARCH], as it was favor by some people on the >> mailing list (Simon, Thomas, Paul, Lutz, Gerhard, myself). >> - This would work for special observation points, assuming that the >> metering process has got an IP address. >> >> +---+ +---+ +---+ >> | E-+-> | E-+-> | E-+------------->---+ >> | | | | | | | | | +---+ +-+-----+ >> +-+-+ | M | | M | | E-+------->-+-C-M-E-+-> >> | | | | | | | | | | +---+ +-+-----+ >> +-+-+ +-+-+ | O | | M | | E-+->---+ >> | | | | +---+ | | | | | | >> | M | +-+-+ | O | | M | >> | | | | | | +---+ | | | +-----+ >> | O | | O | | O | ->-+-C-E-+-> >> +---+ +---+ +---+ +-----+ >> >> Protocol Remote Concentrator Proxy >> Converter Observation >> >> In case of a concentrator that would aggregate some data from multiple >> observation point/metering process, the IP address would be one of the >> new metering process, so the one of the concentrator. If the >> concentrator doesn't aggregate (simply re-export), then the initial >> metering process IP address is kept. >> - As a bonus, this would serve as the unique device identifier required >> by the multi-homed SCTP association (Brian's issues) when the Metering >> Process and Exporting Process are on the same physical box. So when both >> IP addresses (Metering Process IP address and source IP address of the >> export packet) are on the same box.... Not difficult to check via SNMP. >> - Note: IPv4 versus IPv6. We would need a bit somewhere in the header to >> differentiate the two types in the header. >> >> Advantage: this proposal takes care of the special devices in RFC3917 >> Disadvantage: this is a major change. Another round of reviews and >> last-call are certainly needed. >> Disadvantage: [IPFIX-ARCH] should also be changed to speak about the >> RFC3917 special devices. >> >> >> >> Considering that the session ID proposal is ugly (to use Brian's words), >> I only see these two proposals/solutions. >> Personally, I favor the proposal 1. Please let me know what you think. > > Proposal 3: > > o update IPFIX Device Definition and IPFIX-ARCH > to cover special devices. I support this. > o OberservationDomainID unique per IPFIX Device > (the initial idea was to have a source id, which could > be e.g. the IPv4 address of the device) This is at least not "simple" as you claim below. There several places in the text where we request the observation domain ID to be unique per exporting process. A quick scan showed at least - 4 in the protocol draft - 1 in the info model - and even one in the architecture draft ! All these changes need to be made carefully. In contrast, there is only one place in all documents that requests it to be unique per IPFIX device. this is in section 5.4 of the architecture document. > o TemplateIDs locally unique on the path between > exporter and collector. This is not clear to me. Do you mean per session? Or do you mean per {exporting process, collecting process} pair? Thanks, Juergen > advantage: simple change. in line with RFC3917 > disadvantage: ObservationDomainID collisions have to be > avoided out of band. > > Best regards, > Lutz > -- 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 jarretwinter@phatservers.com Tue Jun 13 12:28:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBkz-0001Uw-35 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:28:45 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBkx-00035u-S1 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:28:45 -0400 Received: from esa18.neoplus.adsl.tpnet.pl ([83.20.120.18] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqBWS-0002Wk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 11:13:44 -0500 Message-Id: <00ee01c68efb$dcdc5300$0fa2472c@hbhzjy> From: "meredith egan" To: "ipfix-list@mil.doit.wisc.edu" <#%to#> Subject: This month: get $888 Date: Tue, 13 Jun 2006 15:18:09 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01C68EFB.DCDC5300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca This is a multi-part message in MIME format. ------=_NextPart_000_00EE_01C68EFB.DCDC5300 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Over 60 games to choose from. Why leave home for vegas action? - over $ 8OO BONUS - 24for7 support - Instant payouts http://pssolw.com/casino/ self-stowing advocatus ecclesiae fir cone Botany bay gum hook spanner three-clause fee grief knights grand cross worst-wanted asbestos rock cross-interrogatory self-liquidating loan saddle shell Cashmere stag sole-beloved home-sailing wheel rod heavy-set ------=_NextPart_000_00EE_01C68EFB.DCDC5300 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Over 60 games to choose from. Why leave home for vegas action?
- over $ 8OO BONUS
- 24for7 support
- Instant payouts
http://pssolw.com/casino/

self-stowing advocatus ecclesiae fir cone
Botany bay gum hook spanner three-clause
fee grief knights grand cross worst-wanted
asbestos rock cross-interrogatory self-liquidating loan
saddle shell Cashmere stag sole-beloved
home-sailing wheel rod heavy-set
= ------=_NextPart_000_00EE_01C68EFB.DCDC5300-- From majordomo@mil.doit.wisc.edu Tue Jun 13 12:29:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBlJ-0001cx-6m for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:29:05 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBlH-00036C-S7 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:29:05 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqBMS-00021T-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 11:03:24 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqBMQ-00021O-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 11:03:22 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 065FC1BAC4D; Tue, 13 Jun 2006 17:52:26 +0200 (CEST) Date: Tue, 13 Jun 2006 18:03:21 +0200 From: Juergen Quittek To: Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> In-Reply-To: <448DF34A.6090409@informatik.uni-tuebingen.de> References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> X-Mailer: Mulberry/3.1.6 (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 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Hi Gerhard, --On 13.06.2006 1:05 Uhr +0200 Gerhard Muenz wrote: > > Dear all, > > I'll try to make a final statement on this topic, after rereading all > the mails of the last weeks. > > I could live with both odId unique per Exporting Process or unique per > IPFIX Device. I think there is no big difference and t is more a > philosophic question. For me it is not at all a philosophic problem. It's an administrative problem. An observation domain ID does not have any format. If its value is 0x0003 then this may mean line card #3, interface with ifIndex #3 or routing processor #3. We do not have any means at all to find out what it means. So what is the value of making it unique per device? Let's assume I have two different exporters at a device. Then who assigns observation domain IDs? Is there a lookup service where an implementation can find out what is used? Let's assume I install a tool like nProbe (assuming it supported IPFIX). and configure it to measure at eth1 using libpcap. How do I call the Observation domain? 0x0001, because it is eth1? Then I start another tool, lets say a WLAN Scanner, such as kismet, on interface wlt1 How do I call this observation domain? If we ask the ID to be unique per device, we should discuss how they are assigned or retrieved. If we do not find a good solution, I would strongly propose to drop uniqueness per devices and stick with uniqueness per exporter. Thanks, Juergen > E.g. I have no problem considering two instances > of a monitoring probe software that are running on the same machine and > capture packets on the same interface, as two different devices or two > different exporters on a single device. It does not really matter to me. > > I'm not in favor of uniqueness per session. It makes things more > complicated. Consider a monitor that crashes and restarts with the same > configuration, and you are not allowed to treat old and new monitoring > data the same way... Usually the administrator knows about his > monitoring probes and when bigger configuration changes occur that > result in different monitoring data than before. I am also not convinced that uniqueness per session is a good concept. > My opinion concerning the discussion of persistence of scopes, Template > IDs etc. is that we should restrict our responsability to the path from > the observation point to the collector and not any further. If done with > care, Template IDs can serve as scopes on this path. If the > administrator wants to store the monitoring data and requires long-term > persistence of this information, it's up to him to store additional > context information. > > I would like to consider concentrators, proxies etc. as IPFIX Devices. Can we agree on defining that an IPFIX device contains at least one exporting process but may host any number of additional exporting processes, metering processes and observation points? > They come with their own Exporting Process(es), so uniqueness per > Exporting Process or uniqueness per Device makes no big difference. They > can either set odId to zero or - if it makes sense - they can use odId > to specify some kind of virtual Observation Domains. The administrator > will know that such identifiers do not correspond to physical interfaces. This looks like something to be discussed in the implementation guidelines. Thanks, Juergen > Regards, > Gerhard > > -- > Dipl.-Ing. Gerhard M=FCnz > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen > Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany > Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 > EMail: muenz@informatik.uni-tuebingen.de > WWW: http://net.informatik.uni-tuebingen.de/~muenz -- 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 Jun 13 12:30:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBmn-0001we-H7 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:30:37 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBmm-0003CE-9Z for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:30:37 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqBOC-00023m-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 11:05:12 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqBOA-00023e-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 11:05:10 -0500 Received: from [10.147.65.153] (luz@kaitos [10.147.65.153]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with ESMTP id k5DG56n19671; Tue, 13 Jun 2006 18:05:06 +0200 (MEST) Message-ID: <448EE234.1030904@fokus.fraunhofer.de> Date: Tue, 13 Jun 2006 18:05:08 +0200 From: Lutz Mark User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448E8F4F.2070102@fokus.fraunhofer.de> <9B81B43D64E4F9B90F0A3123@[10.1.1.104]> In-Reply-To: <9B81B43D64E4F9B90F0A3123@[10.1.1.104]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Juergen, >> o TemplateIDs locally unique on the path between >> exporter and collector. > > This is not clear to me. Do you mean per session? > Or do you mean per {exporting process, collecting process} pair? I didn't say per session because in case of a proxy there are multiple sessions. One between exporter and proxy and one between proxy and collector. And there is no need for the proxy to do the template management. Hm, however I think it makes it easier to have TemplateIDs valid only within a session. Best regards, Lutz -- 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 Jun 13 12:40:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBwN-0007MI-9J for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:40:31 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBwK-00043N-Tj for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 12:40:31 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqBrt-0002z0-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 11:35:53 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqBrr-0002ys-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 11:35:51 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 67C0B11C; Tue, 13 Jun 2006 18:35:50 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13190-05; Tue, 13 Jun 2006 18:35:47 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 5C09F11B; Tue, 13 Jun 2006 18:35:47 +0200 (MST) Message-ID: <448EE92C.4010804@informatik.uni-tuebingen.de> Date: Tue, 13 Jun 2006 18:34:52 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> In-Reply-To: <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060500040902020400080607" X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 This is a cryptographically signed message in MIME format. --------------ms060500040902020400080607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi J=FCrgen, Juergen Quittek wrote: [...] >> I could live with both odId unique per Exporting Process or unique per >> IPFIX Device. I think there is no big difference and t is more a >> philosophic question. >=20 > For me it is not at all a philosophic problem. > It's an administrative problem. Of course, I just imagine that both solution are somehow feasible. > An observation domain ID does not have any format. If its > value is 0x0003 then this may mean line card #3, interface > with ifIndex #3 or routing processor #3. We do not have any means > at all to find out what it means. So what is the value of making > it unique per device? >=20 > Let's assume I have two different exporters at a device. > Then who assigns observation domain IDs? > Is there a lookup service where an implementation can find out > what is used? It can be done by the administrator through configuration. > Let's assume I install a tool like nProbe (assuming it supported IPFIX)= . > and configure it to measure at eth1 using libpcap. How do I call > the Observation domain? 0x0001, because it is eth1? It is configurable, you can choose 0x0001 or any other number. > Then I start another tool, lets say a WLAN Scanner, such as kismet, > on interface wlt1 How do I call this observation domain? The same. > If we ask the ID to be unique per device, we should discuss how they > are assigned or retrieved. If we do not find a good solution, I would > strongly propose to drop uniqueness per devices and stick with > uniqueness per exporter. As I said, it is up to the administrator. [...] >> I would like to consider concentrators, proxies etc. as IPFIX Devices. >=20 > Can we agree on defining that an IPFIX device contains at least one > exporting process but may host any number of additional exporting > processes, > metering processes and observation points? Fine with me. >> They come with their own Exporting Process(es), so uniqueness per >> Exporting Process or uniqueness per Device makes no big difference. Th= ey >> can either set odId to zero or - if it makes sense - they can use odId >> to specify some kind of virtual Observation Domains. The administrator >> will know that such identifiers do not correspond to physical interfac= es. >=20 > This looks like something to be discussed in the implementation guideli= nes. Or in documents describing specific issues of these kinds of devices. Regards, Gerhard --=20 Dipl.-Ing. Gerhard M=FCnz Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: muenz@informatik.uni-tuebingen.de WWW: http://net.informatik.uni-tuebingen.de/~muenz --------------ms060500040902020400080607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJdTCC AxUwggJ+oAMCAQICEFnnd0ztch8/FKZyDU4aYM8wDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDIxMDE3MjI0OVoX DTA3MDIxMDE3MjI0OVowbDEOMAwGA1UEBBMFTXVlbnoxEDAOBgNVBCoTB0dlcmhhcmQxFjAU BgNVBAMTDUdlcmhhcmQgTXVlbnoxMDAuBgkqhkiG9w0BCQEWIW11ZW56QGluZm9ybWF0aWsu dW5pLXR1ZWJpbmdlbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOJTlGpd UzaDtPwN+ScPJAXpfQletJ+7B/Zr5MDTyHrAGyXcwsWZB6y7PEO+blM2X66y7+e0kRZVUJYo ycFQZ2dOFS+L2cwNeiea0fEi4wGZ507kYPsFWlYFmB0dRTTTrz6zQaxpsBllvJsTHeYKJ5hc gXyP4la+7ArnYidjqcEpwJqiIO5BNIiX/6WR70tDb7cgJgA2VTgLgWWUbD3cPc9lP0wgEjVB 1/KBZ7F1gVKWCatZSsjBUnf9OO9/DexMdeKCtho06/56ddljFbwwLO4kzy06yzdFlruUWtHZ /hE+IwN/twj+Iv9B6Q2buWICUZi8GHzUKK4CoKsYW93ah5sCAwEAAaM+MDwwLAYDVR0RBCUw I4EhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEArrY1DQ7N6RiHFbjBcsmGfm0IqlCOH+X1c77jMwjR2TFYlsb9urRP ZaFFhVo6lKmZSw2+0QPXhtG6hkFCruSzqRA2Xc+ePpm/nftGLrE4kXsnza35lqfCYfKBVk/i 5ugddlcc3FzyCcBnCOOy+XCt5JfweGCkbsMyuVL1oTRHv88wggMVMIICfqADAgECAhBZ53dM 7XIfPxSmcg1OGmDPMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjAyMTAxNzIyNDlaFw0wNzAyMTAxNzIyNDlaMGwx DjAMBgNVBAQTBU11ZW56MRAwDgYDVQQqEwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11 ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDiU5RqXVM2g7T8DfknDyQF6X0JXrSf uwf2a+TA08h6wBsl3MLFmQesuzxDvm5TNl+usu/ntJEWVVCWKMnBUGdnThUvi9nMDXonmtHx IuMBmedO5GD7BVpWBZgdHUU0068+s0GsabAZZbybEx3mCieYXIF8j+JWvuwK52InY6nBKcCa oiDuQTSIl/+lke9LQ2+3ICYANlU4C4FllGw93D3PZT9MIBI1QdfygWexdYFSlgmrWUrIwVJ3 /Tjvfw3sTHXigrYaNOv+enXZYxW8MCzuJM8tOss3RZa7lFrR2f4RPiMDf7cI/iL/QekNm7li AlGYvBh81CiuAqCrGFvd2oebAgMBAAGjPjA8MCwGA1UdEQQlMCOBIW11ZW56QGluZm9ybWF0 aWsudW5pLXR1ZWJpbmdlbi5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAK62 NQ0OzekYhxW4wXLJhn5tCKpQjh/l9XO+4zMI0dkxWJbG/bq0T2WhRYVaOpSpmUsNvtED14bR uoZBQq7ks6kQNl3Pnj6Zv537Ri6xOJF7J82t+ZanwmHygVZP4uboHXZXHNxc8gnAZwjjsvlw reSX8HhgpG7DMrlS9aE0R7/PMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2QwggNgAgEB MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBZ53dM 7XIfPxSmcg1OGmDPMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTA2MDYxMzE2MzQ1MlowIwYJKoZIhvcNAQkEMRYEFK8duYcSyflf 4YJ42jVMO2gfwhoiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkrBgEEAYI3 EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ Wed3TO1yHz8UpnINThpgzzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQWed3TO1yHz8UpnINThpgzzANBgkqhkiG 9w0BAQEFAASCAQDcMw4SEx+luh9zcS32sN00d29oQxk7+j8FIYhzTb6i/NpB7QXb6A57GqVN /HOl8kQhIloTnb7PR+eY/08ykxE0fYbtwsqE9zp1qhAsjTHqYPkJQ3VezH72KxmjaB1ceQQT g65yu0TAtIrBqEZcaKkbpDt3tb9tobh5/WN28jTHu6/alhr31Fvg2fel64aQQBscuCXmFuHW Fj2xI+NthbNfue7Juk/QI3ILilf+oitA55JJRSRLwaTwBZE7Uv7mSV8/J/UNsjmLsqGiPmo3 WrO4k2u8C/ZxmVJ3yv3+KzxwSQws7Mjd34PpO3Ubmq1+xWAJUEGuaAa7TV+NIRajb+rKAAAA AAAA --------------ms060500040902020400080607-- -- 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 Jun 13 13:23:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqCc0-0008Hx-91 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 13:23:32 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCbx-0007eX-Vt for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 13:23:32 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqCY1-00049Q-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 12:19:25 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqCXz-00049E-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 12:19:23 -0500 Received: from [10.1.1.104] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5E43F1BAC4D; Tue, 13 Jun 2006 19:08:25 +0200 (CEST) Date: Tue, 13 Jun 2006 19:19:17 +0200 From: Juergen Quittek To: Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: <254E90F55407D8D55B65E31F@[192.168.1.128]> In-Reply-To: <448EE92C.4010804@informatik.uni-tuebingen.de> References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448EE92C.4010804@informatik.uni-tuebingen.de> X-Mailer: Mulberry/3.1.6 (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 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi Gerhard, --On 13.06.2006 18:34 Uhr +0200 Gerhard Muenz wrote: > > Hi J=FCrgen, > > Juergen Quittek wrote: > [...] >>> I could live with both odId unique per Exporting Process or unique per >>> IPFIX Device. I think there is no big difference and t is more a >>> philosophic question. >> >> For me it is not at all a philosophic problem. >> It's an administrative problem. > > Of course, I just imagine that both solution are somehow feasible. > >> An observation domain ID does not have any format. If its >> value is 0x0003 then this may mean line card #3, interface >> with ifIndex #3 or routing processor #3. We do not have any means >> at all to find out what it means. So what is the value of making >> it unique per device? >> >> Let's assume I have two different exporters at a device. >> Then who assigns observation domain IDs? >> Is there a lookup service where an implementation can find out >> what is used? > > It can be done by the administrator through configuration. > >> Let's assume I install a tool like nProbe (assuming it supported IPFIX). >> and configure it to measure at eth1 using libpcap. How do I call >> the Observation domain? 0x0001, because it is eth1? > > It is configurable, you can choose 0x0001 or any other number. > >> Then I start another tool, lets say a WLAN Scanner, such as kismet, >> on interface wlt1 How do I call this observation domain? > > The same. If I also call it 0x0001, then this ID is not unique anymore per device, just per exporting process. 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 Jun 13 13:28:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqCgb-0002Ec-Ja for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 13:28:17 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCga-0007xK-Bj for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 13:28:17 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqCds-0004do-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 12:25:28 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqCdq-0004dg-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 12:25:26 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3FE0911C; Tue, 13 Jun 2006 19:25:24 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13192-03; Tue, 13 Jun 2006 19:25:21 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 3E1F411B; Tue, 13 Jun 2006 19:25:21 +0200 (MST) Message-ID: <448EF4C9.5080505@informatik.uni-tuebingen.de> Date: Tue, 13 Jun 2006 19:24:25 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448EE92C.4010804@informatik.uni-tuebingen.de> <254E90F55407D8D55B65E31F@[192.168.1.128]> In-Reply-To: <254E90F55407D8D55B65E31F@[192.168.1.128]> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Content-Transfer-Encoding: quoted-printable Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Hi J=FCrgen, Juergen Quittek wrote: [...] >>> Let's assume I install a tool like nProbe (assuming it supported IPFI= X). >>> and configure it to measure at eth1 using libpcap. How do I call >>> the Observation domain? 0x0001, because it is eth1? >> >> It is configurable, you can choose 0x0001 or any other number. >> >>> Then I start another tool, lets say a WLAN Scanner, such as kismet, >>> on interface wlt1 How do I call this observation domain? >> >> The same. >=20 > If I also call it 0x0001, then this ID is not unique anymore per device= , > just per exporting process. I meant it is also configurable, i.e. up to the administrator to assign unique IDs. Gerhard -- 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 Jun 13 18:15:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqHAv-0007wq-AP for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 18:15:53 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHAt-0006sh-S6 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 18:15:53 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqH47-0004Nl-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 17:08:51 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqH46-0004Ng-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 17:08:50 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 00:08:48 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5DM8lrq000594; Wed, 14 Jun 2006 00:08:47 +0200 (MEST) Received: from [10.61.80.97] (ams3-vpn-dhcp4194.cisco.com [10.61.80.97]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA07504; Tue, 13 Jun 2006 23:08:46 +0100 (BST) Message-ID: <448F376D.6010108@cisco.com> Date: Tue, 13 Jun 2006 23:08:45 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> In-Reply-To: <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Juergen, > An observation domain ID does not have any format. If its > value is 0x0003 then this may mean line card #3, interface > with ifIndex #3 or routing processor #3. We do not have any means > at all to find out what it means. So what is the value of making > it unique per device? An observation domain simply identifies a set of observation points. We don't necessarily have to know exactly what those points are - though that could perhaps be expressed in a message using the "Identifiers" IE group. The important thing is to know that the set of observation points being reported on is somehow different from another set of observation points. eg one message is about eth1 while another is about eth2. Or one message is about line card 3 while another is about line card 4. So observation domain N is simply the Nth set of observation points being reported upon. > Let's assume I have two different exporters at a device. > Then who assigns observation domain IDs? > Is there a lookup service where an implementation can find out > what is used? That's one possibility, but it's up to the implimentation. Perhaps the assignments are made administratively, perhaps they're allocated centrally, perhaps there are specially trained elves in the box. Who cares? The numbers are allocated out of band as far as IPFIX is concerned. All we can do is provide guidelines or set requirements for that numbering. > Let's assume I install a tool like nProbe (assuming it supported IPFIX). > and configure it to measure at eth1 using libpcap. How do I call > the Observation domain? 0x0001, because it is eth1? That would make sense, though any number would suffice. eg, if you administratively configured 0x000n for eth-n or line card n or workstation n or LAN n or office N. Similarly, the device could use self-configured values - in which case the manufacturer should make clear what those values mean. > Then I start another tool, lets say a WLAN Scanner, such as kismet, > on interface wlt1 How do I call this observation domain? Again, any value would suffice. But the key thing is whether it should be the same value as for eth1, or a different value? If you're exporting both data streams to the same collector - or if you might reconcile them on one collector in future - then you absolutely must use a different observation domain IDs to indicate that different sets of observation points were being observed. Else your collector should see that the two sets of data that were collected pertain to the same set of observation points at the same time and incorrectly try to reconcile the wired data from eth1 with the wireless data from wlt1. (If you were exporting data to different collectors and there was no way that the two sets of data would ever be reconciled, then it wouldn't actually matter whether or not they had the same observation domain IDs. But best practice would be to use different IDs anyway.) > If we ask the ID to be unique per device, we should discuss how they > are assigned or retrieved. Why? The values are simply allocated out of band. Whether administratively or automatically depending on what is being observed - as long as different IDs are used to represent each set of observation points. > If we do not find a good solution, I would > strongly propose to drop uniqueness per devices and stick with > uniqueness per exporter. Uniqueness per exporter is simply wrong! Imagine that I configure an exporter reporting on each interface such that eth-n is observation domain 0x000n. All is good. Later I start a second exporter, but by some quirk (administrative typo, lightning strike, whatever) it's reporting eth-n as observation domain 0x000n+1. The data from each exporter is quite self-consistent, and it's not much of an issue if these exporters report to different collectors. However the data from the two exporters cannot be correctly reconciled when the data from the two collectors is eventually cross-referenced or when both exporters are reconfigured to export to just one collector. Clearly the observation domains must be consistent across all the exporters on the device, and not unique per exporer. This is because observation domains are a property of the system as a whole, related to the metering processes - and certainly not a property of each individual exporting process! If multiple metering processes are observing the same set of observation points - ie, the same observation domain - then they should report the same observation domain ID so that the collector(s) may correctly reconcile corresponding data. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 13 19:22:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqICk-0001Wa-Ik for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 19:21:50 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqHym-0005hX-EI for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 19:07:24 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqHyk-0006Vp-4U for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 19:07:24 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqHt4-0005ds-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 18:01:30 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqHt3-0005d2-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 18:01:29 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 01:01:29 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5DN1Srq008879; Wed, 14 Jun 2006 01:01:28 +0200 (MEST) Received: from [10.61.80.97] (ams3-vpn-dhcp4194.cisco.com [10.61.80.97]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id AAA11992; Wed, 14 Jun 2006 00:01:27 +0100 (BST) Message-ID: <448F43C6.2060609@cisco.com> Date: Wed, 14 Jun 2006 00:01:26 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Gerhard Muenz CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> In-Reply-To: <448DF34A.6090409@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Gerhard, > I'm not in favor of uniqueness per session. It makes things more > complicated. Consider a monitor that crashes and restarts with the > same configuration, and you are not allowed to treat old and new > monitoring data the same way. I completely agree. > I would like to consider concentrators, proxies etc. as IPFIX > Devices. Fine by me. And Juergen wrote: > Can we agree on defining that an IPFIX device contains at least one > exporting process but may host any number of additional exporting > processes, metering processes and observation points? Agreed - because if a device does not export, then IP Flow Information *eXport* can hardly claim to apply, can it? > They come with their own Exporting Process(es), so uniqueness per > Exporting Process or uniqueness per Device makes no big difference. It does if you have multiple exporters reporting information about the same set of observations points but using different observation IDs for that. See my earlier mail. > They can either set odId to zero or - if it makes sense - they can > use odId to specify some kind of virtual Observation Domains. That's exactly what such a device should do, because it's no longer observing data from the same set of observation points - ie, the same observation domain - as the original device. Instead, this is a new observation domain that's defined in terms of the new device. Arguably a collector observes data arriving in incoming export packets, rather than on physical interfaces. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 13 21:01:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqJlZ-00005J-Bz for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 21:01:53 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqJlV-0003AB-1L for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 21:01:53 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqJWO-0000xQ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 19:46:12 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqJWN-0000xL-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 19:46:12 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 02:46:12 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5E0kArq022286; Wed, 14 Jun 2006 02:46:10 +0200 (MEST) Received: from [10.61.80.141] (ams3-vpn-dhcp4238.cisco.com [10.61.80.141]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA19577; Wed, 14 Jun 2006 01:46:09 +0100 (BST) Message-ID: <448F5C51.5070608@cisco.com> Date: Wed, 14 Jun 2006 01:46:09 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek CC: Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> In-Reply-To: <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Hello all Juergen Quittek wrote: > Hi Gerhard, > > --On 13.06.2006 1:05 Uhr +0200 Gerhard Muenz wrote: > >> >> Dear all, >> >> I'll try to make a final statement on this topic, after rereading all >> the mails of the last weeks. >> >> I could live with both odId unique per Exporting Process or unique per >> IPFIX Device. I think there is no big difference and t is more a >> philosophic question. > > For me it is not at all a philosophic problem. > It's an administrative problem. I agree, I have more questions than answers inline :) > An observation domain ID does not have any format. If its > value is 0x0003 then this may mean line card #3, interface > with ifIndex #3 or routing processor #3. We do not have any means > at all to find out what it means. So what is the value of making > it unique per device? Indeed, and how would a collector identify that different exporting processes within the same device? One suggestion might be that the source IP address identifies the device and the transport source port identifies the exporting process. Multi-homing and NAT would have large consequences for these assumptions. > Let's assume I have two different exporters at a device. > Then who assigns observation domain IDs? > Is there a lookup service where an implementation can find out > what is used? If my two metering processes are metering the same interfaces will I get the same ID? I would expect so, but that implies my central management system is going to have to take care of all those IDs we have which are unique per observation domain. > Let's assume I install a tool like nProbe (assuming it supported IPFIX). > and configure it to measure at eth1 using libpcap. How do I call > the Observation domain? 0x0001, because it is eth1? > Then I start another tool, lets say a WLAN Scanner, such as kismet, > on interface wlt1 How do I call this observation domain? > > If we ask the ID to be unique per device, we should discuss how they > are assigned or retrieved. If we do not find a good solution, I would > strongly propose to drop uniqueness per devices and stick with > uniqueness per exporter. I agree, although mandating that the ID be configurable per metering process would be an option it is not one that I am in favour of. Andrew -- 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 Jun 13 22:03:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKiy-0007S7-GE for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 22:03:16 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqKix-0006gZ-2y for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 22:03:16 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqKLg-0002NQ-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 20:39:12 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqKLf-0002NL-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 20:39:11 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 03:39:11 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5E1dArq002122; Wed, 14 Jun 2006 03:39:10 +0200 (MEST) Received: from [10.61.80.141] (ams3-vpn-dhcp4238.cisco.com [10.61.80.141]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA22934; Wed, 14 Jun 2006 02:39:04 +0100 (BST) Message-ID: <448F68B6.4010406@cisco.com> Date: Wed, 14 Jun 2006 02:39:02 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Paul Aitken CC: Juergen Quittek , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F376D.6010108@cisco.com> In-Reply-To: <448F376D.6010108@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Paul Aitken wrote: > Juergen, > >> An observation domain ID does not have any format. If its >> value is 0x0003 then this may mean line card #3, interface >> with ifIndex #3 or routing processor #3. We do not have any means >> at all to find out what it means. So what is the value of making >> it unique per device? > > An observation domain simply identifies a set of observation points. We > don't necessarily have to know exactly what those points are - though > that could perhaps be expressed in a message using the "Identifiers" IE > group. > > The important thing is to know that the set of observation points being > reported on is somehow different from another set of observation points. Why is this important to know? If you have no further information about an observation domain other than an ID what can it be used for? > eg one message is about eth1 while another is about eth2. Or one message > is about line card 3 while another is about line card 4. While it is useful to know the interface that a flow record is reporting on, that is what the interface IEs are for. They give very explicit information that is a lot more useful that some arbitrary ID. > So observation domain N is simply the Nth set of observation points > being reported upon. > > >> Let's assume I have two different exporters at a device. >> Then who assigns observation domain IDs? >> Is there a lookup service where an implementation can find out >> what is used? > > That's one possibility, but it's up to the implimentation. Perhaps the > assignments are made administratively, perhaps they're allocated > centrally, perhaps there are specially trained elves in the box. Who > cares? The numbers are allocated out of band as far as IPFIX is > concerned. All we can do is provide guidelines or set requirements for > that numbering. I feel that where the responsibility lies in enforcing the appropriate uniqueness of identifiers is an important question that we must answer. >> Let's assume I install a tool like nProbe (assuming it supported IPFIX). >> and configure it to measure at eth1 using libpcap. How do I call >> the Observation domain? 0x0001, because it is eth1? > > That would make sense, though any number would suffice. eg, if you > administratively configured 0x000n for eth-n or line card n or > workstation n or LAN n or office N. Similarly, the device could use > self-configured values - in which case the manufacturer should make > clear what those values mean. The definition of the IE should contain sufficient meaning. In this case it is an abstract ID with no real meaning in itself but it provides scope for a number of our other IDs and potentially could be used as scope in an option to identify properties of that observation domain. >> If we ask the ID to be unique per device, we should discuss how they >> are assigned or retrieved. > > Why? The values are simply allocated out of band. Whether > administratively or automatically depending on what is being observed - > as long as different IDs are used to represent each set of observation > points. The only advantage I can see of having the observation domain unique per device rather than per exporting process is when you have more than one exporting process reporting on the same observation domain. >> If we do not find a good solution, I would >> strongly propose to drop uniqueness per devices and stick with >> uniqueness per exporter. > > Uniqueness per exporter is simply wrong! That's quite a strong statement and I disagree. The management of this ID has several options and we are simply trying to find the best one. > Imagine that I configure an > exporter reporting on each interface such that eth-n is observation > domain 0x000n. All is good. > > Later I start a second exporter, but by some quirk (administrative typo, > lightning strike, whatever) it's reporting eth-n as observation domain > 0x000n+1. > > The data from each exporter is quite self-consistent, and it's not much > of an issue if these exporters report to different collectors. > > However the data from the two exporters cannot be correctly reconciled > when the data from the two collectors is eventually cross-referenced or > when both exporters are reconfigured to export to just one collector. > > Clearly the observation domains must be consistent across all the > exporters on the device, and not unique per exporer. > > This is because observation domains are a property of the system as a > whole, related to the metering processes - and certainly not a property > of each individual exporting process! Observation domains are not a property of an IPFIX device. Traditionally we are used to the set of observation points to be within a single device, but there is no need to this to be the case. If I have a set of devices communicating to a concentrator device, the concentrator will have an ID which represents the superset of all the observation points it is reporting on. If my metering devices are sending this information to a second concentrator device, the seconds device will pick its own observation domain ID. The observation domain is a property of the entire monitoring system (possibly multi-device), but managing a set of identifiers to represent each observation domain belongs to the exporting process. > If multiple metering processes are observing the same set of observation > points - ie, the same observation domain - then they should report the > same observation domain ID so that the collector(s) may correctly > reconcile corresponding data. I'm still not sure what you mean by "reconcile" the data. Aggregation or finding duplicates would be better achieved by putting more relevant data in the flow record, such as device IP address and interface SNMP index. regards Andrew -- 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 Jun 13 22:04:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqKjx-00084a-VX for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 22:04:17 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqKjw-0006pj-Lr for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 22:04:17 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqKLB-0002N5-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 20:38:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqKL8-0002Mu-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 20:38:38 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 03:38:39 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5E1cbrq002076; Wed, 14 Jun 2006 03:38:37 +0200 (MEST) Received: from [10.61.80.141] (ams3-vpn-dhcp4238.cisco.com [10.61.80.141]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id CAA22904; Wed, 14 Jun 2006 02:38:36 +0100 (BST) Message-ID: <448F6899.20408@cisco.com> Date: Wed, 14 Jun 2006 02:38:33 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Gerhard Muenz CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> In-Reply-To: <448DF34A.6090409@informatik.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Gerhard Muenz wrote: > I'm not in favor of uniqueness per session. It makes things more > complicated. Consider a monitor that crashes and restarts with the same > configuration, and you are not allowed to treat old and new monitoring > data the same way... Usually the administrator knows about his > monitoring probes and when bigger configuration changes occur that > result in different monitoring data than before. What do you mean be old and new monitoring data? I would expect that during a restart the templates being used could be lost and will have to be redefined. Other IDs may have problems too, for example the common properties ID. If an exporting process crashes and restarts, is it the same process? > My opinion concerning the discussion of persistence of scopes, Template > IDs etc. is that we should restrict our responsability to the path from > the observation point to the collector and not any further. If done with > care, Template IDs can serve as scopes on this path. If the > administrator wants to store the monitoring data and requires long-term > persistence of this information, it's up to him to store additional > context information. I think that our responsibility in the definition of the protocol would include specifying all the information that an IPFIX protocol stack should pass to an application using it. If we want any contextual information to be passed to the application with each record then we must specify it. I think template IDs should only be used by the IPFIX stack but observation domain IDs must be available in order to manage the uniqueness of other IDs. For example, an option with the scope of flowId has an implicit scope of observationDomainId. > I would like to consider concentrators, proxies etc. as IPFIX Devices. > They come with their own Exporting Process(es), so uniqueness per > Exporting Process or uniqueness per Device makes no big difference. They > can either set odId to zero or - if it makes sense - they can use odId > to specify some kind of virtual Observation Domains. The administrator > will know that such identifiers do not correspond to physical interfaces. Also, note that these intermediate devices could add an observationDomainId element to the records they export to identify the original domain that the record was reported for. regards Andrew -- 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 Jun 13 23:15:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqLrI-0000cI-93 for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 23:15:56 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqLrG-0007au-Rh for ipfix-archive@lists.ietf.org; Tue, 13 Jun 2006 23:15:56 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqLj3-0005BT-00 for ipfix-list@mil.doit.wisc.edu; Tue, 13 Jun 2006 22:07:25 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqLj1-0005Ai-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 13 Jun 2006 22:07:23 -0500 Received: from [10.1.1.104] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BFEBE1BAC4D; Wed, 14 Jun 2006 04:56:22 +0200 (CEST) Date: Wed, 14 Jun 2006 05:07:19 +0200 From: Juergen Quittek To: Paul Aitken Cc: Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: In-Reply-To: <448F376D.6010108@cisco.com> References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F376D.6010108@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Hi Paul, --On 13.06.2006 23:08 Uhr +0100 Paul Aitken wrote: > Juergen, > >> An observation domain ID does not have any format. If its >> value is 0x0003 then this may mean line card #3, interface >> with ifIndex #3 or routing processor #3. We do not have any means >> at all to find out what it means. So what is the value of making >> it unique per device? > > An observation domain simply identifies a set of observation points. > We don't necessarily have to know exactly what those points are - though > that could perhaps be expressed in a message using the "Identifiers" IE group. I discussed this option with Thomas yesterday. Still we do not see a clean way of doing so. do you have an example? > The important thing is to know that the set of observation points being > reported on is somehow different from another set of observation points. Do you want to ensure that every packet is reported only once? I do not think this is feasible for general IPFIX devices. Just consider one observation domain for incoming traffic at a line card and another one for outgoing traffic in a scheduler of another line card. Or measurement at a central routing engine or multicast daemon. > eg one message is about eth1 while another is about eth2. Or one message > is about line card 3 while another is about line card 4. > > So observation domain N is simply the Nth set of observation points being reported upon. > >> Let's assume I have two different exporters at a device. >> Then who assigns observation domain IDs? >> Is there a lookup service where an implementation can find out >> what is used? > > That's one possibility, but it's up to the implimentation. Perhaps the assignments are made administratively, perhaps they're allocated centrally, perhaps there are specially trained elves in the box. Who cares? The numbers are allocated out of band as > far as IPFIX is concerned. All we can do is provide guidelines or set requirements for that numbering. > > >> Let's assume I install a tool like nProbe (assuming it supported IPFIX). >> and configure it to measure at eth1 using libpcap. How do I call >> the Observation domain? 0x0001, because it is eth1? > > That would make sense, though any number would suffice. eg, if you administratively configured 0x000n for eth-n or line card n or workstation n or LAN n or office N. Similarly, the device could use self-configured values - in which case the > manufacturer should make clear what those values mean. > > >> Then I start another tool, lets say a WLAN Scanner, such as kismet, >> on interface wlt1 How do I call this observation domain? > > Again, any value would suffice. But the key thing is whether it should > be the same value as for eth1, or a different value? If I run both in parallel, using the same value would not be possible, if we want to be unique per device. > If you're exporting both data streams to the same collector - or if you might > reconcile them on one collector in future - then you absolutely must use a > different observation domain IDs to indicate that different sets of observation > points were being observed. If we require "unique per device", I cannot use the same ID twice. > Else your collector should see that the two sets of data that were collected > pertain to the same set of observation points at the same time and incorrectly > try to reconcile the wired data from eth1 with the wireless data from wlt1. > > (If you were exporting data to different collectors and there was no way that > the two sets of data would ever be reconciled, then it wouldn't actually matter > whether or not they had the same observation domain IDs. But best practice would be to use > different IDs anyway.) Yes. of course. >> If we ask the ID to be unique per device, we should discuss how they >> are assigned or retrieved. > > Why? The values are simply allocated out of band. Whether administratively > or automatically depending on what is being observed - as long as different > IDs are used to represent each set of observation points. This does not help much without knowing how the sets are defined. I one set is on a line card at directly a the lines (observing arriving packets) and another set on the same line card at the backplane (observing packets leaving the card), then what does different IDs help you more than that packets were measured a somehow different observation points? >> If we do not find a good solution, I would >> strongly propose to drop uniqueness per devices and stick with >> uniqueness per exporter. > > Uniqueness per exporter is simply wrong! Imagine that I configure an exporter > reporting on each interface such that eth-n is observation domain 0x000n. > All is good. > > Later I start a second exporter, but by some quirk (administrative typo, > lightning strike, whatever) it's reporting eth-n as observation domain 0x000n+1. > > The data from each exporter is quite self-consistent, and it's not much of an > issue if these exporters report to different collectors. > > However the data from the two exporters cannot be correctly reconciled when > the data from the two collectors is eventually cross-referenced or when both > exporters are reconfigured to export to just one collector. > > Clearly the observation domains must be consistent across all the exporters on > the device, and not unique per exporer. I fully understand the need for it. Still I have doubts that we are asking for something that can only be guaranteed if all components come from the same (coordinating) source. > This is because observation domains are a property of the system as a whole, > related to the metering processes - and certainly not a property of each > individual exporting process! Here I disagree. Why shall we disallow dynamic configuration of observation domains. What is the problem with configuring my meter to treat interfaces 1, 7, and 13 as one observation domain? Cheers, Juergen > If multiple metering processes are observing the same set of observation > points - ie, the same observation domain - then they should report the same > observation domain ID so that the collector(s) may correctly reconcile > corresponding data. > > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. -- 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 ejxuyscvwmq@hotmail.com Wed Jun 14 03:58:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqQH5-0001fz-T9 for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 03:58:51 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqQH4-0005Ov-LN for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 03:58:51 -0400 Received: from 71-34-228-158.eugn.qwest.net ([71.34.228.158] helo=mil.doit.wisc.edu) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FqQ8j-0005Oi-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 02:50:14 -0500 From: "wrayray369" To: ipfix-list@mil.doit.wisc.edu Content-type: text/html Subject: Start earning the salary you deserve by obtaining the appropriate University Degree. Message-Id: Date: Wed, 14 Jun 2006 02:50:14 -0500 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813
Want the degree but can’t find the time?

WHAT A GREAT IDEA!
We provide a concept that will allow anyone with sufficient work experience to obtain a fully verifiable University Degree.
Bachelors, Masters or even a Doctorate.
Think of it, within four to six weeks, you too could be a college graduate.
Many people share the same frustration, they are all doing the work of the person that has the degree and the person that has the degree is getting all the money.
Don’t you think that it is time you were paid fair compensation for the level of work you are already doing?
This is your chance to finally make the right move and receive your due benefits.
If you are like most people, you are more than qualified with your experience, but are lacking that prestigious piece of paper known as a diploma that is often the passport to success.
CALL US TODAY AND GIVE YOUR WORK
EXPERIENCE THE CHANCE TO EARN YOU
THE HIGHER COMPENSATION YOU DESERVE!

CALL NOW:
1-815-828-2222



























































































moreover, who had tried to kill Harry before being unmasked. But before
From majordomo@mil.doit.wisc.edu Wed Jun 14 08:01:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqU4H-0001Bc-NP for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:01:53 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqU4F-0001OD-7X for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:01:53 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqTft-00057s-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 06:36:41 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqTfs-00057n-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 06:36:40 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 13:36:40 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EBaarq003327; Wed, 14 Jun 2006 13:36:37 +0200 (MEST) Received: from [10.61.65.248] (ams3-vpn-dhcp504.cisco.com [10.61.65.248]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA08470; Wed, 14 Jun 2006 12:36:35 +0100 (BST) Message-ID: <448FF4BD.7090904@cisco.com> Date: Wed, 14 Jun 2006 12:36:29 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Juergen Quittek CC: Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F376D.6010108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Juergen, >> An observation domain simply identifies a set of observation points. >> We don't necessarily have to know exactly what those points are - though >> that could perhaps be expressed in a message using the "Identifiers" >> IE group. > > > I discussed this option with Thomas yesterday. Still we do not see a clean > way of doing so. do you have an example? I was thinking to use an option message using only scope fields (ie, with Field Count = Scope Field Count). But scope really applies to specific templates, so it's not a clean solution. >> The important thing is to know that the set of observation points being >> reported on is somehow different from another set of observation points. > > > Do you want to ensure that every packet is reported only once? > I do not think this is feasible for general IPFIX devices. No; there's no requirement for that. In fact, it may be desireable to report some packets more than once - eg, to make additional reports to backup collectors. In that case it's crucial that all the collectors understand that all the reports are for the same observation, so that the packet is not later mistakenly counted N times. That's why I think per-exporter observation domain IDs are wrong. > Just consider one observation domain for incoming traffic at a line card > and another one for outgoing traffic in a scheduler of another line card. > Or measurement at a central routing engine or multicast daemon. > >> eg one message is about eth1 while another is about eth2. Or one message >> is about line card 3 while another is about line card 4. >> >> So observation domain N is simply the Nth set of observation points >> being reported upon. >> >>> Let's assume I have two different exporters at a device. >>> Then who assigns observation domain IDs? >>> Is there a lookup service where an implementation can find out >>> what is used? >> >> >> That's one possibility, but it's up to the implimentation. Perhaps the >> assignments are made administratively, perhaps they're allocated >> centrally, perhaps there are specially trained elves in the box. Who >> cares? The numbers are allocated out of band as >> far as IPFIX is concerned. All we can do is provide guidelines or set >> requirements for that numbering. >> >> >>> Let's assume I install a tool like nProbe (assuming it supported IPFIX). >>> and configure it to measure at eth1 using libpcap. How do I call >>> the Observation domain? 0x0001, because it is eth1? >> >> >> That would make sense, though any number would suffice. eg, if you >> administratively configured 0x000n for eth-n or line card n or >> workstation n or LAN n or office N. Similarly, the device could use >> self-configured values - in which case the >> manufacturer should make clear what those values mean. >> >> >>> Then I start another tool, lets say a WLAN Scanner, such as kismet, >>> on interface wlt1 How do I call this observation domain? >> >> >> Again, any value would suffice. But the key thing is whether it should >> be the same value as for eth1, or a different value? > > > If I run both in parallel, using the same value would not be possible, > if we want to be unique per device. Yes, I know that. But it's possible if the requirement is only "unique per exporter", and I wanted to explore the repercussions of that. >> If you're exporting both data streams to the same collector - or if >> you might >> reconcile them on one collector in future - then you absolutely must >> use a >> different observation domain IDs to indicate that different sets of >> observation >> points were being observed. > > If we require "unique per device", I cannot use the same ID twice. Correct. >> Else your collector should see that the two sets of data that were >> collected >> pertain to the same set of observation points at the same time and >> incorrectly >> try to reconcile the wired data from eth1 with the wireless data from >> wlt1. >> >> (If you were exporting data to different collectors and there was no >> way that >> the two sets of data would ever be reconciled, then it wouldn't >> actually matter >> whether or not they had the same observation domain IDs. But best >> practice would be to use >> different IDs anyway.) > > > Yes. of course. > >>> If we ask the ID to be unique per device, we should discuss how they >>> are assigned or retrieved. >> >> >> Why? The values are simply allocated out of band. Whether >> administratively >> or automatically depending on what is being observed - as long as >> different >> IDs are used to represent each set of observation points. > > > This does not help much without knowing how the sets are defined. > I one set is on a line card at directly a the lines (observing arriving > packets) and another set on the same line card at the backplane (observing > packets leaving the card), then what does different IDs help you more than > that packets were measured a somehow different observation points? Clearly it's desireable to have a mechanism to describe what an observation domain actually means. It might be desireable to report the location as eg "ingressInterface 2", or to report it in terms of several observation points which then need their own locations specified. But to answer your question: knowing whether the same set of points were observed or whether it was a different set of points is quite crucial - even if we don't know quite what those particular points are - because without that knowledge we might incorrectly suppose to aggregate all the data together, or fail to aggregate data that does actually pertain to the same observations. Suppose my primary exporter fails for a while, and my secondary exporter kicks in until the primary returns. I need to be able to reconcile the data sent through the secondary exporter with the data from the primary. If each exporter uses its own observation domain IDs then I won't be able to do that very sucessfully. Rather, I would want to match the OD's reported by the secondary 1:1 with the OD's already known on the primary. >>> If we do not find a good solution, I would >>> strongly propose to drop uniqueness per devices and stick with >>> uniqueness per exporter. >> >> >> Uniqueness per exporter is simply wrong! Imagine that I configure an >> exporter >> reporting on each interface such that eth-n is observation domain 0x000n. >> All is good. >> >> Later I start a second exporter, but by some quirk (administrative typo, >> lightning strike, whatever) it's reporting eth-n as observation domain >> 0x000n+1. >> >> The data from each exporter is quite self-consistent, and it's not >> much of an >> issue if these exporters report to different collectors. >> >> However the data from the two exporters cannot be correctly reconciled >> when >> the data from the two collectors is eventually cross-referenced or >> when both >> exporters are reconfigured to export to just one collector. >> >> Clearly the observation domains must be consistent across all the >> exporters on >> the device, and not unique per exporer. > > > I fully understand the need for it. Still I have doubts that we are asking > for something that can only be guaranteed if all components come from the > same (coordinating) source. > >> This is because observation domains are a property of the system as a >> whole, >> related to the metering processes - and certainly not a property of each >> individual exporting process! > > > Here I disagree. Why shall we disallow dynamic configuration of > observation > domains. What is the problem with configuring my meter to treat interfaces > 1, 7, and 13 as one observation domain? I don't see a problem with that. My point is that "observation domain" tells you about where data were observed, and since exporting processes do not do any observing, the OD is clearly not a property of the EP. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 14 08:21:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUMt-0002Bb-ES for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:21:07 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUMs-000402-5D for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:21:07 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqU4K-00066a-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 07:01:56 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqU4J-00066V-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 07:01:55 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 14:01:55 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EC1srq011179; Wed, 14 Jun 2006 14:01:54 +0200 (MEST) Received: from [10.61.65.248] (ams3-vpn-dhcp504.cisco.com [10.61.65.248]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA11406; Wed, 14 Jun 2006 13:01:53 +0100 (BST) Message-ID: <448FFAB0.9030401@cisco.com> Date: Wed, 14 Jun 2006 13:01:52 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Andrew Johnson CC: Juergen Quittek , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F5C51.5070608@cisco.com> In-Reply-To: <448F5C51.5070608@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Andrew, > Indeed, and how would a collector identify that different exporting > processes within the same device? Does it even need to? Probably the collector is more interested in the observed data than in details of the process that delivered it. > One suggestion might be that > the source IP address identifies the device and the transport > source port identifies the exporting process. The source port could change if the export process restarted. However, the data being reported by that EP remains consistent before and after the restart, and the collector must not treat the data received afterwards differently to the data received before. Or if the data was temporarily exported by a different process (eg, during the primary export process's failure), the collector should not treat that data any differently just because it's coming from a different EP. > If my two metering processes are metering the same interfaces will > I get the same ID? I would expect so, If you want to reconcile the data from the two metering processes then you really must use the same observation domain ID to indicate that the same set of observation points were being measured. Using different IDs indicates that different points are being measured, so the data aren't compatible and can't be reconciled. > but that implies my central > management system is going to have to take care of all those IDs > we have which are unique per observation domain. Allocation of IDs could be done in many ways, even without a central system. eg you could allocate ID's in the form 0xnnNN to line card nn, obervation domain NN. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 14 08:23:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUPB-0002vv-TM for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:23:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUPB-00044g-Rx for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:23:29 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqUNL-0001S7-Av for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:21:37 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqU4P-00066u-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 07:02:01 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqU4O-00066V-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 07:02:00 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 14:02:00 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EC20rq011216; Wed, 14 Jun 2006 14:02:00 +0200 (MEST) Received: from [10.61.65.248] (ams3-vpn-dhcp504.cisco.com [10.61.65.248]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA11432; Wed, 14 Jun 2006 13:01:59 +0100 (BST) Message-ID: <448FFAB6.3010205@cisco.com> Date: Wed, 14 Jun 2006 13:01:58 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Andrew Johnson CC: Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <448F6899.20408@cisco.com> In-Reply-To: <448F6899.20408@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Andrew, >> I'm not in favor of uniqueness per session. It makes things more >> complicated. Consider a monitor that crashes and restarts with the same >> configuration, and you are not allowed to treat old and new monitoring >> data the same way... Usually the administrator knows about his >> monitoring probes and when bigger configuration changes occur that >> result in different monitoring data than before. > > > What do you mean be old and new monitoring data? Clearly, data received at the collector before and after the restart. > I would expect that > during a restart the templates being used could be lost and will have > to be redefined. Other IDs may have problems too, for example the > common properties ID. Even so, this should be transparent to the collector: it should be able to continue to append data received after the restart to data received before. (Unless for some reason the data being exported changed and is no longer compatible, eg fields were added or removed during the restart.) > If an exporting process crashes and restarts, is it the same process? I think not, but I also think it shouldn't matter at all. >> My opinion concerning the discussion of persistence of scopes, Template >> IDs etc. is that we should restrict our responsability to the path from >> the observation point to the collector and not any further. If done with >> care, Template IDs can serve as scopes on this path. If the >> administrator wants to store the monitoring data and requires long-term >> persistence of this information, it's up to him to store additional >> context information. > > > I think that our responsibility in the definition of the protocol would > include specifying all the information that an IPFIX protocol stack > should pass to an application using it. If we want any contextual > information to be passed to the application with each record then > we must specify it. > > I think template IDs should only be used by the IPFIX stack but > observation domain IDs must be available in order to manage the > uniqueness of other IDs. For example, an option with the scope > of flowId has an implicit scope of observationDomainId. I very much agree. >> I would like to consider concentrators, proxies etc. as IPFIX Devices. >> They come with their own Exporting Process(es), so uniqueness per >> Exporting Process or uniqueness per Device makes no big difference. They >> can either set odId to zero or - if it makes sense - they can use odId >> to specify some kind of virtual Observation Domains. The administrator >> will know that such identifiers do not correspond to physical interfaces. > > > Also, note that these intermediate devices could add an observationDomainId > element to the records they export to identify the original domain that the > record was reported for. If an intermediate device can uniquely identify a single OD that originally reported the data (eg it's a proxy, or performing some filtering) then it would be as well reporting that data as if it were from the original OD (ie, spoofing). But if it's doing some more complex operation (eg, aggregating records from different devices, or from different OD's on the same device) then reporting the original OD's would be more difficult. ie, how would we report that we're aggregating data from OD 1 at 10.0.0.1 and OD's 2 and 3 at 10.0.0.2 ? Probably it's better to report that we are a new OD at the intermediate device, and use a yet to be determined method to report exactly what this OD represents. Clearly this is something that urgently needs addressed. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 14 08:56:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUvZ-0001SL-UN for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:56:57 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUvZ-0006yb-6C for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:56:57 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqUh0-0007Mz-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 07:41:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqUgy-0007Mn-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 07:41:53 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 14:41:52 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5ECforq022736; Wed, 14 Jun 2006 14:41:50 +0200 (MEST) Received: from [10.61.65.248] (ams3-vpn-dhcp504.cisco.com [10.61.65.248]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA15713; Wed, 14 Jun 2006 13:41:49 +0100 (BST) Message-ID: <4490040C.70008@cisco.com> Date: Wed, 14 Jun 2006 13:41:48 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Andrew Johnson CC: Juergen Quittek , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F376D.6010108@cisco.com> <448F68B6.4010406@cisco.com> In-Reply-To: <448F68B6.4010406@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Andrew, >> The important thing is to know that the set of observation points >> being reported on is somehow different from another set of observation >> points. > > > Why is this important to know? Because the difference between { "some data" + "some more data" } and { "some data" + "some other data" } is that the first two pertain to a common set of observation points and can be reconciled, while the second two do not relate to the same observation points and cannot be reconciled. To clarify: when you're watching the world cup, why is it important to know which players are in which team? The players (observation points) wear different shirts to show which team (observation domain) they belong to. And when a reserve comes on (some more data) it's immediately obvious which team (observation domain) he belongs to. If we didn't know who was on which team (ie, which observation domain was which) then there'd simply be chaos! > If you have no further information about > an observation domain other than an ID what can it be used for? Putting together or seperating out observations made at different places. eg, I have no clue who the players are in each team, but knowing the team name is quite sufficient to follow their progress. >> eg one message is about eth1 while another is about eth2. Or one >> message is about line card 3 while another is about line card 4. > > > While it is useful to know the interface that a flow record is reporting > on, that is what the interface IEs are for. They give very explicit > information that is a lot more useful that some arbitrary ID. Sure; it was only a simple example. Suppose we have two observation domains: OD1 = eth1, eth2, eth3 while OD2 = eth4, eth5, eth6. Even if it's not clear to us which interfaces are in each OD, it's clear that when we receive data about OD1 it's quite seperate from data received about OD2. But when we receive some additional data about OD1 that clearly belongs with the previous data we received for OD1, and not with the previous data for OD2 nor in some seperate place again. >> So observation domain N is simply the Nth set of observation points >> being reported upon. >> >> >>> Let's assume I have two different exporters at a device. >>> Then who assigns observation domain IDs? >>> Is there a lookup service where an implementation can find out >>> what is used? >> >> >> That's one possibility, but it's up to the implimentation. Perhaps the >> assignments are made administratively, perhaps they're allocated >> centrally, perhaps there are specially trained elves in the box. Who >> cares? The numbers are allocated out of band as far as IPFIX is >> concerned. All we can do is provide guidelines or set requirements for >> that numbering. > > > I feel that where the responsibility lies in enforcing the appropriate > uniqueness of identifiers is an important question that we must answer. > > >>> Let's assume I install a tool like nProbe (assuming it supported IPFIX). >>> and configure it to measure at eth1 using libpcap. How do I call >>> the Observation domain? 0x0001, because it is eth1? >> >> >> That would make sense, though any number would suffice. eg, if you >> administratively configured 0x000n for eth-n or line card n or >> workstation n or LAN n or office N. Similarly, the device could use >> self-configured values - in which case the manufacturer should make >> clear what those values mean. > > > The definition of the IE should contain sufficient meaning. In this > case it is an abstract ID with no real meaning in itself but it > provides scope for a number of our other IDs and potentially could > be used as scope in an option to identify properties of that > observation domain. Team names are quite abstract too, though they're quite sufficient for identifying the team's own properties. It's not necessary for the team name to convey any further information itself. >>> If we ask the ID to be unique per device, we should discuss how they >>> are assigned or retrieved. >> >> >> Why? The values are simply allocated out of band. Whether >> administratively or automatically depending on what is being observed >> - as long as different IDs are used to represent each set of >> observation points. > > > The only advantage I can see of having the observation domain unique > per device rather than per exporting process is when you have more > than one exporting process reporting on the same observation domain. In which case it's quite crucial. >>> If we do not find a good solution, I would >>> strongly propose to drop uniqueness per devices and stick with >>> uniqueness per exporter. >> >> >> Uniqueness per exporter is simply wrong! > > > That's quite a strong statement and I disagree. The management of > this ID has several options and we are simply trying to find the best > one. > > >> Imagine that I configure an exporter reporting on each interface such >> that eth-n is observation domain 0x000n. All is good. >> >> Later I start a second exporter, but by some quirk (administrative >> typo, lightning strike, whatever) it's reporting eth-n as observation >> domain 0x000n+1. >> >> The data from each exporter is quite self-consistent, and it's not >> much of an issue if these exporters report to different collectors. >> >> However the data from the two exporters cannot be correctly reconciled >> when the data from the two collectors is eventually cross-referenced >> or when both exporters are reconfigured to export to just one collector. >> >> Clearly the observation domains must be consistent across all the >> exporters on the device, and not unique per exporer. >> >> This is because observation domains are a property of the system as a >> whole, related to the metering processes - and certainly not a >> property of each individual exporting process! > > > Observation domains are not a property of an IPFIX device. Traditionally > we are used to the set of observation points to be within a single device, > but there is no need to this to be the case. If I have a set of devices > communicating to a concentrator device, the concentrator will have an > ID which represents the superset of all the observation points it is > reporting on. If my metering devices are sending this information to > a second concentrator device, the seconds device will pick its own > observation domain ID. The observation domain ID chosen at the second device should be chosen quite independantly of the first device, and may even be the same as an ID already in use by the first device. [IPFIX-PROTO] says: Collecting Processes SHOULD use the combination of the Exporter (exporterIPv4Address, exporterIPv6Address, or exportingProcessId) and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. The same rule also allows separation of streams which happen to use the same observation domain ID but come from different addresses. > The observation domain is a property of the entire monitoring system > (possibly multi-device), but managing a set of identifiers to represent > each observation domain belongs to the exporting process. I disagree on both points. >> If multiple metering processes are observing the same set of >> observation points - ie, the same observation domain - then they >> should report the same observation domain ID so that the collector(s) >> may correctly reconcile corresponding data. > > > I'm still not sure what you mean by "reconcile" the data. I mean recognising that data received later in time or seperately (eg, on another collector) pertains to the same set of observation points on the same device, and dealing with it appropriately rather that storing it separately. > Aggregation > or finding duplicates would be better achieved by putting more relevant > data in the flow record, such as device IP address and interface SNMP > index. Suppose eth1, 2 and 3 are redundant links to some department. They're in OD1 so I can measure that department's traffic. Similarly eth3, 4 and 5 are links to another department, which are in OD2. Using ODs to differentiate each department's traffic is clearly much simpler than trying to figure out which deparment "ingressInterface=4" is. Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 14 09:00:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqUys-0002lH-AG for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:00:22 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqUyr-0007fB-0j for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:00:22 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqUol-0007Yl-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 07:49:55 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqUok-0007Yg-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 07:49:54 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 14:49:55 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5ECnqrq025165; Wed, 14 Jun 2006 14:49:53 +0200 (MEST) Received: from [10.61.65.248] (ams3-vpn-dhcp504.cisco.com [10.61.65.248]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA16357; Wed, 14 Jun 2006 13:49:51 +0100 (BST) Message-ID: <449005EE.5020209@cisco.com> Date: Wed, 14 Jun 2006 13:49:50 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Thomas Dietz CC: Andrew Johnson , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <6D28EBC684A4D94096217AD2FE400873752EAB@venus.office> In-Reply-To: <6D28EBC684A4D94096217AD2FE400873752EAB@venus.office> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Thomas, >>> What do you mean be old and new monitoring data? >> >> Clearly, data received at the collector before and after the >> restart. > > > Here I would agree. But your example with the other exporter taking > over if the first is not available brings in a second component. How > does the collector now (because the second exporter most likely has a > different IP address) that it receives data from the same IPFIX > device then? Good question. Probably the second exporter must use (or at least spoof) the first exporter's address, because [IPFIX-PROTO] says: Collecting Processes SHOULD use the combination of the Exporter (exporterIPv4Address, exporterIPv6Address, or exportingProcessId) and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. - and clearly we DON'T want to seperate these streams in this case. >> If an intermediate device can uniquely identify a single OD that >> originally reported the data (eg it's a proxy, or performing some >> filtering) then it would be as well reporting that data as if it >> were from the original OD (ie, spoofing). > > > If it is proxying a single device then I very much agree again. But > if it proxies more than one device you need to find a way to map the > OD Ids. I agree this is something we still need to address. >> Probably it's better to report that we are a new OD at the >> intermediate device, and use a yet to be determined method to >> report exactly what this OD represents. Clearly this is something >> that urgently needs addressed. > > > I agree with your proposal here, that a concentrator should use a new > OD Id but I don't think we need to address the details here. Those > details (how to report orignial OD Ids etc.) should be handled by a > different RFC then. Whether it's a new RFC or it simply holds up progress on an existing one, clearly we need to define this mechanism! Cheers. -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 14 09:04:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqV2X-0005Vw-19 for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:04:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqV2W-0007tk-VK for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:04:09 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqUqz-00021h-QI for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 08:52:15 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqUff-0007M6-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 07:40:31 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqUfe-0007Ly-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 07:40:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 1D6A42009086; Wed, 14 Jun 2006 14:40:49 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16447-05; Wed, 14 Jun 2006 14:40:49 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id F146E2009082; Wed, 14 Jun 2006 14:40:48 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Date: Wed, 14 Jun 2006 14:40:28 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0209_01C68FC0.7AC98DC0" Message-ID: <6D28EBC684A4D94096217AD2FE400873752EAB@venus.office> In-Reply-To: <448FFAB6.3010205@cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals thread-index: AcaPrm0ReS7ysqfdSbSK+V4nhAD80AAAEK5w From: "Thomas Dietz" To: "Paul Aitken" , "Andrew Johnson" Cc: "Gerhard Muenz" , X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd This is a multi-part message in MIME format. ------=_NextPart_000_0209_01C68FC0.7AC98DC0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Paul, > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Paul Aitken > Sent: Wednesday, June 14, 2006 2:02 PM > To: Andrew Johnson > Cc: Gerhard Muenz; ipfix-protocol@net.doit.wisc.edu > Subject: Re: [ipfix-protocol] Observation Domain ID > uniqueness - summary and proposals > > Andrew, > > >> I'm not in favor of uniqueness per session. It makes things more > >> complicated. Consider a monitor that crashes and restarts > with the same > >> configuration, and you are not allowed to treat old and > new monitoring > >> data the same way... Usually the administrator knows about his > >> monitoring probes and when bigger configuration changes occur that > >> result in different monitoring data than before. > > > > > > What do you mean be old and new monitoring data? > > Clearly, data received at the collector before and after the restart. Here I would agree. But your example with the other exporter taking over if the first is not available brings in a second component. How does the collector now (because the second exporter most likely has a different IP address) that it receives data from the same IPFIX device then? > > > > I would expect that > > during a restart the templates being used could be lost and > will have > > to be redefined. Other IDs may have problems too, for example the > > common properties ID. > > Even so, this should be transparent to the collector: it > should be able > to continue to append data received after the restart to data > received > before. (Unless for some reason the data being exported > changed and is > no longer compatible, eg fields were added or removed during > the restart.) > > > > If an exporting process crashes and restarts, is it the > same process? > > I think not, but I also think it shouldn't matter at all. > > > >> My opinion concerning the discussion of persistence of > scopes, Template > >> IDs etc. is that we should restrict our responsability to > the path from > >> the observation point to the collector and not any > further. If done with > >> care, Template IDs can serve as scopes on this path. If the > >> administrator wants to store the monitoring data and > requires long-term > >> persistence of this information, it's up to him to store additional > >> context information. > > > > > > I think that our responsibility in the definition of the > protocol would > > include specifying all the information that an IPFIX protocol stack > > should pass to an application using it. If we want any contextual > > information to be passed to the application with each record then > > we must specify it. > > > > I think template IDs should only be used by the IPFIX stack but > > observation domain IDs must be available in order to manage the > > uniqueness of other IDs. For example, an option with the scope > > of flowId has an implicit scope of observationDomainId. > > I very much agree. > > > >> I would like to consider concentrators, proxies etc. as > IPFIX Devices. > >> They come with their own Exporting Process(es), so uniqueness per > >> Exporting Process or uniqueness per Device makes no big > difference. They > >> can either set odId to zero or - if it makes sense - they > can use odId > >> to specify some kind of virtual Observation Domains. The > administrator > >> will know that such identifiers do not correspond to > physical interfaces. > > > > > > Also, note that these intermediate devices could add an > observationDomainId > > element to the records they export to identify the original > domain that the > > record was reported for. > > If an intermediate device can uniquely identify a single OD that > originally reported the data (eg it's a proxy, or performing some > filtering) then it would be as well reporting that data as if it were > from the original OD (ie, spoofing). If it is proxying a single device then I very much agree again. But if it proxies more than one device you need to find a way to map the OD Ids. > > But if it's doing some more complex operation (eg, > aggregating records > from different devices, or from different OD's on the same > device) then > reporting the original OD's would be more difficult. > > ie, how would we report that we're aggregating data from OD 1 at > 10.0.0.1 and OD's 2 and 3 at 10.0.0.2 ? > > Probably it's better to report that we are a new OD at the > intermediate > device, and use a yet to be determined method to report exactly what > this OD represents. Clearly this is something that urgently > needs addressed. I agree with your proposal here, that a concentrator should use a new OD Id but I don't think we need to address the details here. Those details (how to report orignial OD Ids etc.) should be handled by a different RFC then. Best Regards, Thomas > > Cheers. > -- > Paul Aitken > Cisco Systems Ltd, Edinburgh, Scotland. > > -- > 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/ > ------=_NextPart_000_0209_01C68FC0.7AC98DC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJcDCCAvgw ggJhoAMCAQICAw9RdTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwODE3MDkwOTE3WhcNMDYwODE3MDkwOTE3WjBjMQ4wDAYDVQQE EwVEaWV0ejEPMA0GA1UEKhMGVGhvbWFzMRUwEwYDVQQDEwxUaG9tYXMgRGlldHoxKTAnBgkqhkiG 9w0BCQEWGlRob21hcy5EaWV0ekBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA4nhGGaCtAFl95e262kXtWs33/Co8wu3qnQqpmgEkgADwZV1ZGoNphSGYXWmdAO4S C+M2HFzsJ0FJ3eG4KV0IaI+kvuKQdfHbqKSV8OfUTIhwrzjwZVJBvUYagIBF8ksvo37XR8YPg5Hw j/zPFAbRhbGg/mrKj/Za7/P9ouv1onhwigQtOG5qcr3+MHE+I6lmkZM7FrzzNwYSJ0Jq52Q8BUEg LWdhLHnXDFy1d+tCZdtdEK3bKga13+Udc5jC0Yvg8hmY+nrxhUPKcYR038q404eJplla2qtpEC3O IoGTKLYRtcxAtoMQ1VG32AylLKJ59/GQDqXOjr9iCI4qyyj7zwIDAQABozcwNTAlBgNVHREEHjAc gRpUaG9tYXMuRGlldHpAbmV0bGFiLm5lYy5kZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAE2PK+6rLfxJ5o+m3N28Uj0XGeArIfvLtnzZQDvuzz2jaThTjJ7PqULqOzjPsCGT/UsT2Ayo 2ksMnxzcVVIK4iJJlaJ2qJRrORakM2CfmkaxFkrJweezRfMPSp7tlW8QnZ/Johw746jZj5bcnOsV 0gxcXkhfMr9OcjEVsJ6+2eg6MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkG A1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBE aXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcN AQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIz MTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIs YyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56 fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuo SpaKH2JCI4wXD/S6ZJwXrEcp352YXtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMm CZGAc9AUG95DqYMl8uacLxXK/qarigd1iwzdUYRr5PjRzneigTCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggNQMIIDTAIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDD1F1MAkGBSsOAwIaBQCgggG8MBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDYxNDEyNDAyOFowIwYJKoZIhvcNAQkEMRYEFAJStzb+ oIils+iCRVW+BwdmtHTvMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqG SIb3DQIFMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAgMPUXUwegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQQIDD1F1MA0GCSqGSIb3DQEBAQUABIIBAHPeHl9kEVhnEoj7Qp4Y ymIOg3hIxoljsupANMu+K9FFQStz+b+JSuMQIJFOEDij/FxKJvl1FH0rZ1SjNaDfHbLm1h+/ktJQ ShmdveJQykE26JTO1Bu8aOa3HAn2L+l+iDtcs0omR2j5P+OyLKmOdYsjGNKyNBLXGycHf7NzlO/h 2sb9gZ9PHvqfBy+GVQFgJO4Rvav2g8Iv0dMmr2C2eHLlDo1v26b0T91okdggZ0xiK1ia0aLzxYun v+V6K1lqqyYUXbL1bLHQWfmQ+Z/5IFnCrI2ayFxQzH+EVt9U7dy7Fw0FsF1TRwza6gZ+32i+QeGP cdVq1GQBzgqe3b8A0/wAAAAAAAA= ------=_NextPart_000_0209_01C68FC0.7AC98DC0-- -- 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 cornelius@twinkseries.com Wed Jun 14 09:16:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVE9-00023c-5U for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:16:09 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVE7-00018D-Ty for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:16:09 -0400 Received: from pool-72-65-121-93.ptldme.east.verizon.net ([72.65.121.93] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqV8q-0000d4-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 08:10:40 -0500 Message-Id: <000a01c68fab$b675f080$ef0ff155@gvzvntt> From: "christy oakes" To: "karita moseley" Subject: We bring Vegas to you! Date: Wed, 14 Jun 2006 12:15:18 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C68FAB.B675F080" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01C68FAB.B675F080 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Over 60 games to choose from. Why leave home for vegas action? - Over $ 8OO BONUS - 24for7 support - Instant payouts - HUGE JECKPOT!http://envprag.com/casino/ Sun king quasi-automatic witch mark Bracklesham beds fall snipe silk discharger pole-shaped world-honored three-halfpence well-counted two-leaf hammer-shaped air letter river jack spike-billed mimosa family anti-open-shop pencil cedar ------=_NextPart_000_000A_01C68FAB.B675F080 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Over 60 games to choose from. Why leave home for vegas action?
- Over $ 8OO BONUS
- 24for7 support
- Instant payouts
- HUGE JECKPOT! http://envprag.com/casino/

Sun king quasi-automatic witch mark
Bracklesham beds fall snipe silk discharger
pole-shaped world-honored three-halfpence
well-counted two-leaf hammer-shaped
air letter river jack spike-billed
mimosa family anti-open-shop pencil cedar
= ------=_NextPart_000_000A_01C68FAB.B675F080-- From majordomo@mil.doit.wisc.edu Wed Jun 14 09:29:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqVQw-00007O-1t for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:29:22 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqVQu-0003s5-Ll for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 09:29:22 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqVNm-0000ys-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 08:26:06 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqVNl-0000yn-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 08:26:05 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Jun 2006 15:26:05 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5EDQ3rq006673; Wed, 14 Jun 2006 15:26:04 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA20930; Wed, 14 Jun 2006 14:26:02 +0100 (BST) Message-ID: <44900E69.50500@cisco.com> Date: Wed, 14 Jun 2006 14:26:01 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Paul Aitken CC: Juergen Quittek , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F5C51.5070608@cisco.com> <448FFAB0.9030401@cisco.com> In-Reply-To: <448FFAB0.9030401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Paul Aitken wrote: > Andrew, > >> Indeed, and how would a collector identify that different exporting >> processes within the same device? > > Does it even need to? Probably the collector is more interested in the > observed data than in details of the process that delivered it. If the odId is unique per device then a collector absolutely MUST be able to identify that exporting processes are from the same or different devices in order to identify the scope of the odId and be able to understand when a matching odId from two different EPs refers to the same or different observation domains. If the odId is unique per EP then a collector MUST be able to differentiate between EPs, potentially a much simpler problem. Note: If the odId is unique per device and things like the commonPropertiesId are unique per ObservationDomain then a collector will have to group the options it receives from the same device but different EPs. This means that different EPs will be able to override options sent by each other if the scope matches. Furthermore, this means that whatever method is used to administer the odIds would have to be extended for all the other IDs which are unique per observation domain. >> One suggestion might be that >> the source IP address identifies the device and the transport >> source port identifies the exporting process. > > The source port could change if the export process restarted. However, > the data being reported by that EP remains consistent before and after > the restart, and the collector must not treat the data received > afterwards differently to the data received before. A template ID is unique per exporting process. If an EP were to restart and change source port then is it OK for the collector to decode records with templates it received before the restart? If not, then it should be considered a new process. Otherwise how does the collector identify that it's the same process on a different port? > Or if the data was temporarily exported by a different process (eg, > during the primary export process's failure), the collector should not > treat that data any differently just because it's coming from a > different EP. > > >> If my two metering processes are metering the same interfaces will >> I get the same ID? I would expect so, > > If you want to reconcile the data from the two metering processes then > you really must use the same observation domain ID to indicate that the > same set of observation points were being measured. Using different IDs > indicates that different points are being measured, so the data aren't > compatible and can't be reconciled. Why is the odId some magic identifier that lets you do this? You still sufficient information in the flow record in order to be able to reconcile the information. For example, imagine a simple router with 4 ports. The observation domain may be fixed at 1 to identify the largest domain of all 4 ports. A Metering Process may only monitor two of those ports. A second process may monitor a different pair, but there could be overlap. To reconcile flow records here you will probably need the ifIndex to be able to find duplicate flows here. To expand on that example, what if I have two concentrators aggregating information from overlapping subsets of routers. These concentrators are separate IPFIX devices so have their odIds can't be compared. In short, sufficient scope to reconcile data is not going to be solved by making the odId unique per device. >> but that implies my central >> management system is going to have to take care of all those IDs >> we have which are unique per observation domain. > > Allocation of IDs could be done in many ways, even without a central > system. eg you could allocate ID's in the form 0xnnNN to line card nn, > obervation domain NN. And how do you allocate all the other IDs that are unique per observation domain? Andrew -- 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 Jun 14 11:37:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqXQS-0006u6-Fy for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 11:37:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqXQR-0004ll-4M for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 11:37:00 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqXI6-000572-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 10:28:22 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqXI5-00056x-00 for ipfix-protocol@net.doit.wisc.edu; Wed, 14 Jun 2006 10:28:21 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A510B1BAC4D for ; Wed, 14 Jun 2006 17:17:17 +0200 (CEST) Date: Wed, 14 Jun 2006 17:28:15 +0200 From: Juergen Quittek To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Dear all, It seems to be difficult to come to an end with this discussion. Therefore, I try another approach. Below please find a proposal that might be acceptable to all of us. It is a rather detailed one already containing already concrete suggestions for text changes in our the three documents. Please comment. Thanks, Juergen OLD [in IPFIX-ARCH and IPFIX-PROTO] * Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an observation domain if it is composed of several interfaces, each of which is an Observation Point. Each Observation Domain presents itself to the Collecting Process using an Observation Domain ID to identify the IPFIX Messages it generates. Observation Domain IDs are unique per Exporting Process. NEW [Just appended a sentence] * Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an observation domain if it is composed of several interfaces, each of which is an Observation Point. Each Observation Domain presents itself to the Collecting Process using an Observation Domain ID to identify the IPFIX Messages it generates. Observation Domain IDs are unique per Exporting Process. It is RECOMMENDED that an Observation Domain IDs is also unique per IPFIX device. OLD [in IPFIX-ARCH and IPFIX-PROTO] * IPFIX Device An IPFIX Device hosts at least one Observation Point, a Metering Process and an Exporting Process. NEW * IPFIX Device An IPFIX Device hosts at least one Exporting Process. It may host further Exporting processes and arbitrary numbers of Observation Points and Metering Process. OLD [in IPFIX-ARCH] 5.4. Observation Domain The Observation Domain is a logical block that presents a single identity for a group of Observation Points within an IPFIX Device. Each {Observation Point, Metering Process} pair belongs to a single Observation Domain. An IPFIX Device could have multiple Observation Domains, each of which has a subset of the total set of Observation Points in it. Each Observation Domain must carry a unique ID within the context of an IPFIX Device. Note that in case of multiple Observation Domains, a unique ID per Observation Domain must be transmitted as a parameter to the Exporting Function. That unique ID is referred to as the IPFIX Observation Domain ID. NEW 5.4. Observation Domain The Observation Domain is a logical block that presents a single identity for a group of Observation Points. Each {Observation Point, Metering Process} pair SHOULD belong to a single Observation Domain. A single IPFIX Device may have multiple Observation Domains, each of which contains a subset of the total set of Observation Points. Each Observation Domain MUST carry a unique ID within the context of a single Exporting Process. It is RECOMMENDED that this ID is also unique per IPFIX Device. OLD [in IPFIX-PROTO section 3.1] Observation Domain ID A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. Collecting Processes SHOULD use the NEW [inserted one sentence] Observation Domain ID A 32-bit identifier of the Observation Domain that is locally unique to the Exporting Process. The Exporting Process uses the Observation Domain ID to uniquely identify to the Collecting Process the Observation Domain that metered the Flows. It is RECOMMENDED that this identifier is also unique per IPFIX Device. Collecting Processes SHOULD use the OLD [in IPFIX-PROTO section 4.1 and section 4.2] sourceId An identifier of an Observation Domain NEW observationDomainId An identifier of an Observation Domain OLD [in IPFIX-PROTO section 3.4.2.1] exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX NEW exportingProcessId, observationDomainId, etc. are also valid scopes. The IPFIX OLD [in IPFIX-INFO] 5.1.10. sourceId Description: An identifier of an Observation Domain that is unique per Exporting Process. Typically, this Information Element is used for limiting the scope of other Information Elements. NEW 5.1.10. observationDomainId Description: An identifier of an Observation Domain that is unique per Exporting Process. It is RECOMMENDED that this identifier is also unique per IPFIX device. Typically, this Information Element is used for limiting the scope of other Information Elements. -- 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 Jun 14 13:42:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqZNZ-0007EE-0a for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 13:42:09 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqZNY-0001e7-Jb for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 13:42:08 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqZBz-0002Ji-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 12:30:11 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqZBy-0002J8-00 for ipfix@net.doit.wisc.edu; Wed, 14 Jun 2006 12:30:10 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5EHRY4B026489 for ; Wed, 14 Jun 2006 13:27:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C68FD8.2D9D1D34" Subject: [ipfix] Last Call Comments (was: FW: [Bernard Aboba] Re: [secdir] draft-ietf-ipfix-as-08.txt) Date: Wed, 14 Jun 2006 20:30:06 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call Comments (was: FW: [Bernard Aboba] Re: [secdir] draft-ietf-ipfix-as-08.txt) Thread-Index: AcaPsswpQqdTsKu4QZ27pz5aQV/0PwAJMCmQ From: "Romascanu, Dan \(Dan\)" To: "IESG" Cc: X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 This is a multi-part message in MIME format. ------_=_NextPart_001_01C68FD8.2D9D1D34 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please consider the attached comments from Bernard Adoba from the AAA and security perspective as Last Call comments.=20 Thanks and Regards, Dan =20 -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Wednesday, June 14, 2006 4:02 PM To: david.kessens@nokia.com; Romascanu, Dan (Dan) Subject: [Bernard Aboba] Re: [secdir] draft-ietf-ipfix-as-08.txt This seems like more of a AAA issue than a security issue. Are either of you interested in taking these comments under consideration? ------_=_NextPart_001_01C68FD8.2D9D1D34 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable in-reply-to: <126f4307cf5c972580fc905dc0b3e099@cisco.com> content-class: urn:content-classes:message Subject: Re: [secdir] draft-ietf-ipfix-as-08.txt Date: Tue, 13 Jun 2006 21:44:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <126f4307cf5c972580fc905dc0b3e099@cisco.com> From: "Bernard Aboba" To: "Barbara Fraser" Cc: "Russ Housley" , "Sam Hartman" , Overview Overall, what is odd about this applicability statement is that it does=20 not clearly lay out the limits of applicability of IPFIX. Instead, it=20 suggests lots of potential usage scenarios, without clearly=20 indicating the applicability limits.=20 At various points, this document crosses the line into describing usage-based billing scenarios for which IPFIX was not designed.=20 Since the document indicates that IPFIX does not meet the reliability requirements stated in RFC 2975, the usage of IPFIX in usage-based billing scenarios is potentially dangerous, resulting in violation of=20 financial reporting requirements. The document needs to be more clear=20 about the limitations of IPFIX in usaged-based billing scenarios.=20 Section 2.1 Usage based accounting is one of the major applications for=20 which the IPFIX protocol has been developed.=20 Later on in the document, it is stated that IPFIX does not meet the reliability requirements for usage-based billing. Given this,=20 I'd suggest that the document needs to be careful throughout in its description of accounting applications of IPFIX. For example, the term "usage based accounting" needs to be clarified to make it=20 clear that we are not talking about usage-based billing. It might=20 make sense to use the term "usage reporting" instead, to make it clear that bills are not being generated from the information.=20 " For accounting purposes, it would be advantageous to have the=20 ability to use IPFIX flow records as accounting input in an AAA=20 infrastructure. AAA servers then could provide the mapping=20 between user and flow information." I'm not clear what is being suggested here. Later on, it is=20 suggested that IPFIX flow records might be carried within=20 Diameter & RADIUS. However, IPFIX already defines a transport for=20 this information, as I understand it. Perhaps what is meant here is=20 that a monitoring & report system could combine AAA authentication=20 information (User-Name + Framed-IP-Address) with information obtained=20 from IPFIX to produce more useful reports. However, that is something that is distinct from "AAA infrastructure".=20 Note that the reliability requirements defined in [RFC3917] are=20 not sufficient to guarantee the level of reliability that is=20 needed for many usage-based accounting systems. Particular=20 reliability requirements for accounting systems are discussed in=20 [RFC2975]. =20 If IPFIX does not guarantee a sufficient level of reliability for=20 usage-based billing, then this needs to be called out specifically in = the applicability statement, and the document needs to clarified at various points. It is important for the document to be clear about this, because there are financial reporting (and security) requirements surrounding accounting systems, some of which are described in RFC 2975. Where usage data is used in the generation of bills, packets carrying that information effectively represent money -- and packet loss translates directly to revenue loss. Accounting systems that "lose" revenue due to = design deficiencies are likely to draw attention from regulators,=20 and shareholders. Therefore the IETF needs to be particularly careful=20 when reviewing documents which relate to these systems.=20 Section 2.1.1 Let's suppose someone has a Service Level Agreement (SLA) in a=20 DiffServ network requiring accounting based on traffic volume.=20 This seems to suggest that a bill is being generated from IPFIX data, which contradicts the applicability statement made in Section 2.1. = Section 3.4 DIAMETER is used for the transfer of accounting=20 records. In order to form accounting records for usage-based=20 accounting measurement data from the network is required. IPFIX=20 defines a protocol to export such data from routers, measurement=20 probes and other devices. Therefore it looks promising to=20 connect those two architectures.=20 Diameter accounting was specifically designed to meet the=20 reliability requirements described in RFC 2975, whereas IPFIX was not. Therefore "connecting those two architectures" in usage-based billing situations could result in a system that no longer meets financial reporting requirements.=20 As shown in section 2.1 accounting can be realized without an=20 AAA infrastructure. Accounting applications can directly=20 incorporate an IPFIX collecting process to receive IPFIX records=20 with information about the transmitted volume.=20 Given the reliability constraints described earlier, using IPFIX as input to a usage-based billing system is inappropriate.=20 IPFIX=20 records can provide the input for AAA accounting functions and=20 provide the basis for the generation of DIAMETER accounting=20 records.=20 This has the potential to introduce unreliability into Diameter accounting, due to loss of packets within IPFIX. Therefore if this is going to be suggested, the limitations need to=20 made clear -- namely that this is not appropriate in usage-based billing environments.=20 Further potential features include...=20 facilitating the secure authorized exchange of=20 DIAMETER accounting records with neighbor domains.=20 Diameter already supports TLS-based security, so it is not clear to me what IPFIX can add here.=20 ------_=_NextPart_001_01C68FD8.2D9D1D34-- -- 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 adh@gascoecu.org Wed Jun 14 15:46:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbJg-0002Z4-VF for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 15:46:16 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqbJf-0000wG-LL for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 15:46:16 -0400 Received: from host144.201-253-58.telecom.net.ar ([201.253.58.144] helo=gascoecu.org) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FqazI-0001dH-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 14:25:13 -0500 Message-ID: <000001c68fe8$41e502f0$b2bda8c0@qbk14> Reply-To: "Adhiambo Thibeau" From: "Adhiambo Thibeau" To: ipfix-list@mil.doit.wisc.edu Subject: Re: texab 371 Date: Wed, 14 Jun 2006 12:25:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C68FAD.95862AF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?201.253.58.144 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C68FAD.95862AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Levi rv=20 tra X qr=20 anax V sh=20 ALlUM fr ta=20 om onl pd=20 y $=20 mt=20 1,2 ez=20 1 C xf=20 lALlS f jl=20 rom o rf=20 nly $=20 ys=20 3,7 fe=20 5 S fd=20 oma Ambi sw=20 en V dd=20 lAGRA fr zi=20 om on sj=20 ly $ fw=20 3,3 yl=20 3 Proz sd=20 ac Merid yd=20 ia Sa io=20 ve o qz=20 ver 50 qr=20 % wi lk=20 th u do=20 s http://www.qualintens.com =20 _____ =20 In places deep, where dark things sleep,=20 In hollow halls beneath the fells.=20 On silver necklaces they strung=20 The light of stars, on crowns they hung=20 The dragon-fire, from twisted wire=20 The melody of harps they wrung.=20 ------=_NextPart_000_0001_01C68FAD.95862AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

Levi
rv
tra
X
qr
anax
V
sh
ALlUM fr
ta
om onl
pd
y $
mt
1,2
ez
1
C
xf
lALlS f
jl
rom o
rf
nly $
ys
3,7
fe
5
S
fd
oma
Ambi
sw
en
V
dd
lAGRA fr
zi
om on
sj
ly $
fw
3,3
yl
3
Proz
sd
ac
Merid
yd
ia

Sa
io
ve o
qz
ver 50
qr
% wi
lk
th u
do
s http://www.qualintens.com
 

In places deep, = where dark things sleep,
In hollow halls beneath the fells.
= On silver necklaces they strung
The light of stars, on crowns = they hung
The dragon-fire, from twisted wire
The melody of = harps they wrung.
------=_NextPart_000_0001_01C68FAD.95862AF0-- From hexagonalew@academia-ados.com Wed Jun 14 19:31:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqepp-0007v9-LY for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 19:31:41 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqepo-0002yi-DF for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 19:31:41 -0400 Received: from [65.217.50.68] (helo=58EE7C8) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FqeTJ-00028Z-00; Wed, 14 Jun 2006 18:08:25 -0500 Received: from 63.97.180.026 (vys8.ambararabians.com) (63.97.180.026) by mta141.mail.scd.yahoo.com with SMTP; Wed, 14 Jun 2006 18:08:25 -0600 MIME-Version: 1.0 X-Accept-Language: en X-Priority: Normal From: "Sharron Black" To: majordomo@mil.doit.wisc.edu Cc: dplonka@mil.doit.wisc.edu, ipfix-list@mil.doit.wisc.edu Subject: Re:fnance Date: Wed, 14 Jun 2006 18:08:25 -0600 Message-ID: <1-83367012-dAutqno0kVrZx4g7fLQ5nI0@gwy1.ambararabians.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.4 (+++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Decrease your monthly mortgage payments by more than 1/3. Junes Prequalified-Rates ______________________ $332,000.00 @ 4.09% $691,000.00 @ 3.80% $538,000.00 @ 3.42% http://www.b289a2.com From 8gcu2mrCo@mail.ru Wed Jun 14 21:16:01 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqgSn-0006sp-3J for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 21:16:01 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqgSl-00057E-RX for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 21:16:01 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqgP4-0006ir-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 20:12:10 -0500 Received: from 20132211199.user.veloxzone.com.br (20132211199.user.veloxzone.com.br [201.32.211.199]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5F1C5Rr011952 for ; Wed, 14 Jun 2006 20:12:09 -0500 Date: Thu, 15 Jun 2006 01:10:54 +0180 From: "Ramiro Bourgeois" X-Mailer: The Bat! (v3.0.2.4 Rush) Home Reply-To: "Ramiro Bourgeois" X-Priority: 3 (Normal) Message-ID: <1668215783.20060615011054@mail.ru> To: ipfix-list@mil.doit.wisc.edu Subject: Your future, oil-break switch MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.7 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIAzLIS would help you to make BETTER SE X MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ER ECTI ON during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISC OUNT OFER! http://sbnpjl.motivefood.com/?88745077 ========== began to go transparent. "Don't let them spread silly rumors about me, or "There is a steady leak of materials from the Visitation Zones into the "Where is everybody, Sullivan?" he asked silently, quite at home now Zone you can either cry or joke--and I never cried, even as a child. I the right, as one bird... level... to... inverted... to... level, the wind their teeth on this cotton problem for some time. You see, they were profoundly serious work, since every bent line illuminates a straight one, "Hold on," he said. "Full? Just like this, but full?" From fredericaervin@uahoster.com Wed Jun 14 23:11:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqiGJ-0003Mx-2G for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 23:11:15 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqiGH-0001BM-Pe for ipfix-archive@lists.ietf.org; Wed, 14 Jun 2006 23:11:15 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqiCY-0002zi-00 for ipfix-list@mil.doit.wisc.edu; Wed, 14 Jun 2006 22:07:22 -0500 Received: from BABY (71-8-117-177.dhcp.ftwo.tx.charter.com [71.8.117.177]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5F37LAT024010 for ; Wed, 14 Jun 2006 22:07:22 -0500 Message-Id: <000e01c6901f$b0215c00$09bf466b@dqxxgj> From: "gregor holmes" To: "dickie jean" Subject: St. Dupont on Farthers Days! Date: Thu, 15 Jun 2006 02:10:56 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C6901F.B0215C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.5 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C6901F.B0215C00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FABULOUS REPLICAS - AMAZING PRICES Handbags * Jewelry * Pens * Watches * Neckties * Clutches and More All our products are made with the finest leather and silks, and come with certificate, tags and all the extras, just as you would find in a=20 boutique. Extreme care is taken to pay special attention to detail.=20 You will be immediately surprised by the craftsmanship and strength of our fine, high-quality luxury items, whether it be a watch, handbag, or tie. Visit Now to See our Current Specials!=20 http://dafarty.com/luxury/ rain-bright beauty spot ironstone china sofa maker many-yeared sign painting self-hammered apple sucker pretty-looking log carriage back action stone run straw bid Teuto-celtic Anglo-canadian too-too quasi-constant coal blacking drip-ground red-beamed twice-bid rubber-spreading grain-fed self-relying Congo dye ever-angry strand former ------=_NextPart_000_000E_01C6901F.B0215C00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

FABULOUS REPLICAS - AMAZING PRICES

Handbags * Jewelry * Pens * Watches * Neckties * Clutches and More

All our products are made with the finest leather and silks, and come
with certificate, tags and all the extras, just as you would find in a
boutique. Extreme care is taken to pay special attention to detail.

You will be immediately surprised by the craftsmanship and strength of our fine, high-quality luxury items, whether it be a watch, handbag, or tie=

Visit Now to See our Current Specials!

http://dafarty.com/luxury/

rain-bright beauty spot ironstone china
sofa maker many-yeared sign painting
self-hammered apple sucker pretty-looking
log carriage back action stone run
straw bid Teuto-celtic Anglo-canadian
too-too quasi-constant coal blacking
drip-ground red-beamed twice-bid
rubber-spreading grain-fed self-relying
Congo dye ever-angry strand former
= ------=_NextPart_000_000E_01C6901F.B0215C00-- From Adam.Springer@caboverde.com Thu Jun 15 07:24:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqpy0-0006uu-80 for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 07:24:52 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqpxy-0008Px-Pl for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 07:24:52 -0400 Received: from [61.81.22.54] (helo=2160C30) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FqptT-00065R-00; Thu, 15 Jun 2006 06:20:13 -0500 Received: from 88.16.970.612 (txucom.net) (88.16.970.612) by mta168.mail.mud.yahoo.com with SMTP; Thu, 15 Jun 2006 06:20:09 -0600 thread-index: 1du055g8+6z7602y1a8x6at0c2ois== Thread-Topic: g2o684a34h27j87kkkkqz222jh37zteb From: "Miguel Harper" To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu Subject: American Residents Date: Thu, 15 Jun 2006 06:20:09 -0600 MIME-Version: 1.0 Content-Type: text/plain X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.09.9506.4537 Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Is your mort-rate around $551,000.00 @ 3.94%? If not thats the average we've given for the month of June. Financial Issues? Don't matter! Everyone qualifies. Last 3 closed today: 1. R. Platt New York, NY 573,000 @ 4.18% 2. C. Platt Miami, FL 613,000 @ 3.71% 3. P. Platt Seattle, WA 717,000 @ 3.24% http://mx.geocities.com/nosh_katown5 From daluzapanni@ftd.com Thu Jun 15 08:19:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqqoj-0005kb-3V for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 08:19:21 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqqoh-0005J0-FO for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 08:19:21 -0400 Received: from [84.46.146.201] (helo=ftd.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FqqjA-0000cK-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Jun 2006 07:13:37 -0500 Message-ID: <000001c69075$24e10d60$45eca8c0@tlw48> Reply-To: "Panni Daluz" From: "Panni Daluz" To: ipfix-list@mil.doit.wisc.edu Subject: uacuf Rfinnance Date: Thu, 15 Jun 2006 05:13:43 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6903A.78823560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (dnsbl.njabl.org) open proxy -- 1148467067 X-Spam-Score: 3.5 (+++) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6903A.78823560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Your B y es k t A n vail v ab d le R p at m e - v b isi r t we f b si h te =20 =20 $ 20 h 0,00 c 0 f q or onl y y $8 c 27 m q onth $ 3 w 00,0 t 00 fo m r o s nly $8 v 97 mont t h $ 40 b 0,0 s 00 f d or onl s y $95 p 7 mo n nth $ 5 b 00,0 h 00 f f or o v nly $1 r 007 m h onth =20 Ba q d C n re c di u t O d K =20 _____ =20 the path from the deep red carpets of the forest. Still Bombur slept and they grew very weary. At times they heard disquieting laughter. Sometimes there was singing in the distance too. The laughter was the laughter of fair voices not of goblins, and the singing was beautiful, ------=_NextPart_000_0001_01C6903A.78823560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Your B y es k t A n vail v ab d le R p at m e - v b isi r t we h = te
 
$ 20 h 0,00 c 0 f q or onl y y $8 c 27 m q onth
$ 3 w 00,0 t 00 fo m r o s nly $8 v 97 mont t h
$ 40 b 0,0 s 00 f d or onl s y $95 p 7 mo n nth
$ 5 b 00,0 h 00 f f or o v nly $1 r 007 m h onth
 
Ba q d C n re u = t O d = K
 

the path from the deep red carpets of = the forest. Still Bombur slept and
they grew very weary. At times they heard disquieting laughter.
Sometimes there was singing in the distance too. The laughter was = the
laughter of fair voices not of goblins, and the singing was = beautiful,
------=_NextPart_000_0001_01C6903A.78823560-- From majordomo@mil.doit.wisc.edu Thu Jun 15 11:06:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtQI-0001lz-7G for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 11:06:18 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqtQG-00008I-Ui for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 11:06:18 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FqtNF-0007WZ-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Jun 2006 10:03:09 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FqtNE-0007WU-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 15 Jun 2006 10:03:08 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5FF36822068; Thu, 15 Jun 2006 17:03:06 +0200 (CEST) Received: from [10.61.65.98] (ams3-vpn-dhcp354.cisco.com [10.61.65.98]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5FF35C18833; Thu, 15 Jun 2006 17:03:05 +0200 (CEST) Message-ID: <449176A8.2000402@cisco.com> Date: Thu, 15 Jun 2006 17:03:04 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Johnson CC: Paul Aitken , Juergen Quittek , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F376D.6010108@cisco.com> <448F68B6.4010406@cisco.com> In-Reply-To: <448F68B6.4010406@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Andrew, > >> Imagine that I configure an exporter reporting on each interface such >> that eth-n is observation domain 0x000n. All is good. >> >> Later I start a second exporter, but by some quirk (administrative >> typo, lightning strike, whatever) it's reporting eth-n as observation >> domain 0x000n+1. >> >> The data from each exporter is quite self-consistent, and it's not >> much of an issue if these exporters report to different collectors. >> >> However the data from the two exporters cannot be correctly >> reconciled when the data from the two collectors is eventually >> cross-referenced or when both exporters are reconfigured to export to >> just one collector. >> >> Clearly the observation domains must be consistent across all the >> exporters on the device, and not unique per exporer. >> >> This is because observation domains are a property of the system as a >> whole, related to the metering processes - and certainly not a >> property of each individual exporting process! > > Observation domains are not a property of an IPFIX device. Traditionally > we are used to the set of observation points to be within a single > device, > but there is no need to this to be the case. If I have a set of devices > communicating to a concentrator device, the concentrator will have an > ID which represents the superset of all the observation points it is > reporting on. This is the key question, as summarized in my initial email. Which IPFIX definition do we choose? Proposal 1: We keep the IPFIX device definition as defined right now, and it doesn't cover the special devices from RFC3917. Protocol unchanged. Proposal 2: We include all special cases in the IPFIX device definition, and we have to change something in the protocol. 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 tallulahdumas@ge.com Thu Jun 15 12:21:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqubW-0008Nr-D6 for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 12:21:58 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqubV-0006zs-1p for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 12:21:58 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FquXd-00034p-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Jun 2006 11:17:57 -0500 Received: from BABY ([67.70.212.186]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5FGHu8i008408 for ; Thu, 15 Jun 2006 11:17:56 -0500 Message-Id: <003301c6908f$29a46300$13ae555a@kcmsm> From: "fergus bentley" To: "hart thornton" Subject: Tag Heuer in Farthers Days! Date: Thu, 15 Jun 2006 15:21:36 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C6908F.29A46300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C6908F.29A46300 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FATHER'S DAY IS APPROACHING! Why pick one of our watches? The skilled artistry that goes into creating our elegant timepieces guarant= ees impeccable quality. Our gifted artisans dedicate their attention to cra= fting the time pieces with utmost care and state-of-the-art workmanship. Ev= ery timepiece is guaranteed to be meticulous in design, exquisite in style,= and rich in beauty, and each piece carries a manufacturer's warranty.=20 Rolex Cartier Bvlgari Tag Heuer Officine Panerai Jaeger-Lecoultre A.Lange &= Sohne & More ORDER NOW AND SAVE 25% http://bsaine.com/luxury/ Jura-triassic star-fed mouse grass ceramic engineer dog bramble weak-spirited bay ice fresh-killed shore whiting tooth cleaner point handle gram-molecular lig-by deckle edge plum-brown ash tree hi-fi dim-gleaming self-inductive brick hammer semen contra orra man pedal point Anti-armenian spring-flowering Trans-euphrates Semi-manichaeanism ------=_NextPart_000_0033_01C6908F.29A46300 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

FATHER'S DAY IS APPROACHING!
Why pick one of our watches?

The skilled artistry that goes into creating our elegant timepieces guar= antees=20 impeccable quality. Our gifted artisans dedicate their attention to craftin= g=20 the time pieces with utmost care and state-of-the-art workmanship. Every=20 timepiece is guaranteed to be meticulous in design, exquisite in style,=20 and rich in beauty, and each piece carries a manufacturer's warranty.=20

Rolex Cartier Bvlgari Tag=20 Heuer Officine Panerai Jaeger-Lecoultre A.Lange=20 & Sohne & More

ORDER NOW AND SAVE 25%

http://bsaine.com/luxury/

Jura-triassic star-fed mouse grass
ceramic engineer dog bramble weak-spirited
bay ice fresh-killed shore whiting
tooth cleaner point handle gram-molecular
lig-by deckle edge plum-brown
ash tree hi-fi dim-gleaming
self-inductive brick hammer semen contra
orra man pedal point Anti-armenian
spring-flowering Trans-euphrates Semi-manichaeanism
= ------=_NextPart_000_0033_01C6908F.29A46300-- From majordomo@mil.doit.wisc.edu Thu Jun 15 18:22:16 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0EC-0004Vu-7I for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 18:22:16 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0EA-0003x2-Qb for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 18:22:16 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fr0BS-0003T8-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Jun 2006 17:19:26 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr0BQ-0003T3-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 15 Jun 2006 17:19:24 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5FMJNC18698; Fri, 16 Jun 2006 00:19:23 +0200 (CEST) Received: from [10.21.97.218] (sjc-vpn1-474.cisco.com [10.21.97.218]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5FMJJC22929; Fri, 16 Jun 2006 00:19:19 +0200 (CEST) Message-ID: <4491DCE6.9000905@cisco.com> Date: Fri, 16 Jun 2006 00:19:18 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Hi Juergen, Thanks for this effort. In a nutshell, for the sake of finalizing the documents, I agree with your proposed changes. > > OLD [in IPFIX-ARCH and IPFIX-PROTO] > * Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an observation domain if it > is composed of several interfaces, each of which is an Observation > Point. Each Observation Domain presents itself to the Collecting > Process using an Observation Domain ID to identify the IPFIX > Messages it generates. Observation Domain IDs are unique per > Exporting Process. First of all, there is a discrepancy in the Observation Domain definitions of [IPFIX-ARCH] and [IPFIX-PROTO]. [IPFIX-ARCH] * Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an observation domain if it is composed of several interfaces, each of which is an Observation Point. Each Observation Domain presents itself to the Collecting Process using an Observation Domain ID to identify the IPFIX Messages it generates. Observation Domain IDs are unique per Exporting Process. [IPFIX-PROTO] Observation Domain An Observation Domain is the largest set of Observation Points for which Flow information can be aggregated by a Metering Process. For example, a router line card may be an Observation Domain if it is composed of several interfaces, each of which is an Observation Point. In the IPFIX Message it generates, the Observation Domain includes its Observation Domain ID, which is unique per Exporting Process. That way, the Collecting Process can identify the specific Observation Domain from the Exporter that sends the IPFIX Messages. Every Observation Point is associated with an Observation Domain. > NEW [Just appended a sentence] > * Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an observation domain if it > is composed of several interfaces, each of which is an Observation > Point. Each Observation Domain presents itself to the Collecting > Process using an Observation Domain ID to identify the IPFIX > Messages it generates. Observation Domain IDs are unique per > Exporting Process. It is RECOMMENDED that an Observation Domain IDs > is also unique per IPFIX device. If you would add the sentence "It is RECOMMENDED that an Observation Domain IDs is also unique per IPFIX Device." to the [IPFIX-PROTO] definition, I would be fine. Then this definition should be used for both [IPFIX-PROTO] and [IPFIX-ARCH] > > OLD [in IPFIX-ARCH and IPFIX-PROTO] > * IPFIX Device > > An IPFIX Device hosts at least one Observation Point, a Metering > Process and an Exporting Process. > NEW > * IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting processes and arbitrary numbers of Observation > Points > and Metering Process. > > OLD [in IPFIX-ARCH] > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points within an IPFIX Device. > Each {Observation Point, Metering Process} pair belongs to a single > Observation Domain. An IPFIX Device could have multiple Observation > Domains, each of which has a subset of the total set of Observation > Points in it. Each Observation Domain must carry a unique ID within > the context of an IPFIX Device. Note that in case of multiple > Observation Domains, a unique ID per Observation Domain must be > transmitted as a parameter to the Exporting Function. That unique ID > is referred to as the IPFIX Observation Domain ID. > NEW > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points. Each {Observation Point, > Metering Process} pair SHOULD belong to a single Observation Domain. > A single IPFIX Device may have multiple Observation Domains, each of > which contains a subset of the total set of Observation Points. > Each Observation Domain MUST carry a unique ID within the context of > a single Exporting Process. It is RECOMMENDED that this ID is also > unique per IPFIX Device. > > OLD [in IPFIX-PROTO section 3.1] > Observation Domain ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify > to the Collecting Process the Observation Domain that > metered the Flows. Collecting Processes SHOULD use the > NEW [inserted one sentence] > Observation Domain ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify > to the Collecting Process the Observation Domain that > metered the Flows. It is RECOMMENDED that this identifier > is also unique per IPFIX Device. Collecting Processes > SHOULD use the > > OLD [in IPFIX-PROTO section 4.1 and section 4.2] > sourceId An identifier of an Observation Domain > NEW > observationDomainId An identifier of an Observation Domain Yes, already corrected in my temp version. > > OLD [in IPFIX-PROTO section 3.4.2.1] > exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX > NEW > exportingProcessId, observationDomainId, etc. are also valid > scopes. The IPFIX Yes, already corrected in my temp version. > > OLD [in IPFIX-INFO] > 5.1.10. sourceId > > Description: > An identifier of an Observation Domain that is unique per > Exporting Process. Typically, this Information Element is used > for limiting the scope of other Information Elements. > NEW > 5.1.10. observationDomainId > > Description: > An identifier of an Observation Domain that is unique per > Exporting Process. It is RECOMMENDED that this identifier is > also unique per IPFIX device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. > Yep. 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/ -- 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 Jun 15 18:22:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0EK-0004W8-M8 for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 18:22:24 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0EI-0003x6-7w for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 18:22:24 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fr03L-0003LA-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Jun 2006 17:11:03 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr03K-0003Kw-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 15 Jun 2006 17:11:02 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2006 00:10:59 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5FMAwrq012935 for ; Fri, 16 Jun 2006 00:10:58 +0200 (MEST) Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id XAA16155 for ; Thu, 15 Jun 2006 23:10:57 +0100 (BST) Message-ID: <4491DAF1.4020200@cisco.com> Date: Thu, 15 Jun 2006 23:10:57 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Hello all Paul and I sat down in a room discussed this, and the complicated implications of it, for most of the day. We finally reached an agreement and I'd like to summarise our discussion here. Note that most of the arguments presented here have been presented by various people on the list. The question was a simple one, should the Observation Domain ID be considered unique per Exporting Process or per IPFIX Device. In the end we agreed that it should be unique per Exporting Process. CASE 1: Observation Domain Unique by Device =========================================== So let us consider the case of a Linux box running two seperate monitoring /exporting applications. Since the box is considered a single IPFIX device with multiple Metering and Exporting Processes, if the observation domain ID was unique per device, both Exporting Processes should export using the same Observation Domain ID. This will involve some administrative process to co-ordinate, such as: 1. Some magic process to co-ordinate all the Exporting Processes 2. Manual configuration 3. Some fixed scheme that works out an ID as some hash of some identifiers of the Observation Domain. Now some other IDs are considered to be unique within the observation domain. These IDs will now require to be administered via the same process so that they can be properly shared between Exporting Processes operating within the same Observation Domain. Alternatively we will have to redefine them to be unique per Exporting Process, but that will mean that if we have a distributed Exporting Process operating on several Line Cards (and each Line Card is considered a separate OD) then the EP will have to co-ordinate these IDs across Line Cards. Unless we redefine these IDs to be unique across Observation Domains and Exporting Processes, which is what we have today if the Observation Domain ID is considered unique per Exporting Process. So what do all these complications and changes gain us? We can match the Observation Domains of flows sent from the same device, but different EPs. This still isn't enough to match duplicate observations, we'll also need to match on all the key fields and perhaps some timestamps. Even then is it sufficient? Different sampling and filtering rules could result in different MPs having different observations at the same Observation Point! It is clear we are a long way from defining de-duplication rules for a general case. Furthermore, if the two Exporting Processes are exporting using different source IP addresses, then how can the collector know they are from the same device? Are we going to force all Exporting Processes on a device to export with the same IP address, or in the case of SCTP, set of IP addresses? In fact, perhaps two different IPFIX devices are being used to monitor the same information. Either through passive probes or some sort of remote monitoring application or perhaps because they are simply a seconds stage aggregation. Now changing the odId scope has gained us nothing and we still can't match the Observation Domains. CASE 2: Observation Domain Unique by Exporting Process ====================================================== Perhaps knowing something about the observation domain will be of use to your collector though. Would a better way to solve this be to have each collector export an option identifying information about each observation domain? Note that we already have: 149 sourceId -> observationDomainId 300 observationPointId Perhaps using these, and some way of uniquely identifying a device then we can build up a true picture of what the Observation Domain is and we can find matches on the Observation Domains regardless of whether the reports are from different Exporting Process or IPFIX devices. Aggregators will even be able to aggregate the information to identify the superset of Observation Points that make up their Observation Domain. OUR CONCLUSIONS =============== Changing the scope of the Observation Domain ID will add complexity to the protocol and generate other problems that will need to be solved. It won't really solve any problems as we can expect to want to match observation domains from different IPFIX devices. Identifying matching domains from different Exporting Processes may be useful, but there are other ways to do it that will scale to matching ODs across different IPFIX devices. The Observation Domain ID should remain unique within the Exporting Process. regards Andrew -- 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 Jun 15 18:45:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr0aV-0000mE-0R for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 18:45:19 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr0aT-0005Ma-NU for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 18:45:18 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fr0XW-0004Kh-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Jun 2006 17:42:14 -0500 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr0XV-0004Ka-00 for ipfix-protocol@net.doit.wisc.edu; Thu, 15 Jun 2006 17:42:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id D438335CC4; Fri, 16 Jun 2006 10:42:09 +1200 (NZST) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06115-29; Fri, 16 Jun 2006 10:42:09 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 6C38E35E7C; Fri, 16 Jun 2006 10:42:09 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k5FMg9xD018387; Fri, 16 Jun 2006 10:42:09 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k5FMg8dr018385; Fri, 16 Jun 2006 10:42:08 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from nevil-laptop.cs.auckland.ac.nz (nevil-laptop.cs.auckland.ac.nz [130.216.38.130]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Fri, 16 Jun 2006 10:42:08 +1200 Message-ID: <20060616104208.nuyr563c7bgkoo8g@webmail.auckland.ac.nz> Date: Fri, 16 Jun 2006 10:42:08 +1200 From: Nevil Brownlee To: Benoit Claise Cc: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] FInialising documents References: <4491DCE6.9000905@cisco.com> In-Reply-To: <4491DCE6.9000905@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi Benoit: Sounds fine to me. I'm working on a new revision of draft-architecture now, I'll make the change to the definition of * Observation Domain, to ... a single Exporting Process. It is RECOMMENDED that this ID is also unique per IPFIX Device. Following up on an email I sent Benoit yesterday, can we get new versions of the protocol and architecture drafts published by about next Tuesday (20 June)? If we can, we could ask Dan to get them onto the IESG telechat on 22 June ... Cheers, Nevil ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 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 dimitaro@jcwhitneyco.com Thu Jun 15 20:48:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr2Vh-0003CM-R6 for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 20:48:29 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr2Vg-0003dp-H1 for ipfix-archive@lists.ietf.org; Thu, 15 Jun 2006 20:48:29 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr2Rf-0002Iy-00 for ipfix-list@mil.doit.wisc.edu; Thu, 15 Jun 2006 19:44:19 -0500 Received: from jcwhitneyco.com (adsl-ull-6-223.49-151.net24.it [151.49.223.6]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5G0iFEG029444 for ; Thu, 15 Jun 2006 19:44:18 -0500 Message-ID: <000001c690dd$f390c0c0$40b8a8c0@obp20> Reply-To: "Dimitar Reisner" From: "Dimitar Reisner" To: ipfix-list@mil.doit.wisc.edu Subject: Re: zugeg 669 Date: Thu, 15 Jun 2006 17:43:57 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C690A3.4731E8C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C690A3.4731E8C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi ClA un=20 LlS fr ed=20 om o is=20 nly $=20 xr=20 3,7 qv=20 5 VlA gx=20 GRA fro kv=20 m on um=20 ly $=20 en=20 3,3 ne=20 3 Amb zb=20 ien Proza gk=20 c S ez=20 oma Xa mg=20 nax Levi kq=20 tra VALl uf=20 UM fro kn=20 m o em=20 nly $ je=20 1,2 zt=20 1 Meridi fb=20 a Sa li=20 ve o rq=20 ver 5 ta=20 0% wit mx=20 h u pu=20 s http://www.hotsotrom.com =20 _____ =20 Then quieter than a mouse he stole back. He had precious little time,=20 he knew, before the spiders were disgusted and came back to their trees=20 where the dwarves were hung. In the meanwhile he had to rescue them. The worst part of the job was getting up on to the long branch where the=20 bundles were dangling.=20 I dont suppose he would have managed it, if a spider had not luckily=20 ------=_NextPart_000_0001_01C690A3.4731E8C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

ClA
un
LlS fr
ed
om o
is
nly $
xr
3,7
qv
5
VlA
gx
GRA fro
kv
m on
um
ly $
en
3,3
ne
3
Amb
zb
ien
Proza
gk
c
S
ez
oma
Xa
mg
nax
Levi
kq
tra
VALl
uf
UM fro
kn
m o
em
nly $
je
1,2
zt
1
Meridi
fb
a

Sa
li
ve o
rq
ver 5
ta
0% wit
mx
h u
pu
s http://www.hotsotrom.com
 

Then quieter = than a mouse he stole back. He had precious little time,
he knew, = before the spiders were disgusted and came back to their trees
where = the dwarves were hung. In the meanwhile he had to rescue them. The =
worst part of the job was getting up on to the long branch where the =
bundles were dangling.
I dont suppose he would have managed = it, if a spider had not luckily
------=_NextPart_000_0001_01C690A3.4731E8C0-- From majordomo@mil.doit.wisc.edu Fri Jun 16 03:25:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr8hv-0005qM-6a for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 03:25:31 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr8hs-0000uu-TI for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 03:25:31 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fr8EN-0003bP-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 01:54:59 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr8EL-0003bI-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 01:54:57 -0500 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 89AB51BAC4D; Fri, 16 Jun 2006 08:43:39 +0200 (CEST) Date: Fri, 16 Jun 2006 08:54:49 +0200 From: Juergen Quittek To: Benoit Claise , Andrew Johnson Cc: Paul Aitken , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: <644030C97D1E02DC3E964E21@[192.168.1.128]> In-Reply-To: <449176A8.2000402@cisco.com> References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]> <448F376D.6010108@cisco.com> <448F68B6.4010406@cisco.com> <449176A8.2000402@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Benoit, --On 15.06.2006 17:03 Uhr +0200 Benoit Claise wrote: > Andrew, >> >>> Imagine that I configure an exporter reporting on each interface such >>> that eth-n is observation domain 0x000n. All is good. >>> >>> Later I start a second exporter, but by some quirk (administrative >>> typo, lightning strike, whatever) it's reporting eth-n as observation >>> domain 0x000n+1. >>> >>> The data from each exporter is quite self-consistent, and it's not >>> much of an issue if these exporters report to different collectors. >>> >>> However the data from the two exporters cannot be correctly >>> reconciled when the data from the two collectors is eventually >>> cross-referenced or when both exporters are reconfigured to export to >>> just one collector. >>> >>> Clearly the observation domains must be consistent across all the >>> exporters on the device, and not unique per exporer. >>> >>> This is because observation domains are a property of the system as a >>> whole, related to the metering processes - and certainly not a >>> property of each individual exporting process! >> >> Observation domains are not a property of an IPFIX device. Traditionally >> we are used to the set of observation points to be within a single >> device, >> but there is no need to this to be the case. If I have a set of devices >> communicating to a concentrator device, the concentrator will have an >> ID which represents the superset of all the observation points it is >> reporting on. > This is the key question, as summarized in my initial email. Which IPFIX > definition do we choose? > Proposal 1: We keep the IPFIX device definition as defined right now, > and it doesn't cover the special devices from RFC3917. Protocol unchanged. > Proposal 2: We include all special cases in the IPFIX device definition, > and we have to change something in the protocol. Which changes do you think we would need to apply? Thanks, Juergen > 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 Fri Jun 16 03:41:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr8xf-0005hF-Rj for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 03:41:47 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr8xe-0001sR-IG for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 03:41:47 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fr8Jt-0003hU-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 02:00:41 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr8Js-0003hP-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 02:00:40 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5G70dm19820; Fri, 16 Jun 2006 09:00:39 +0200 (CEST) Received: from [10.61.65.164] (ams3-vpn-dhcp420.cisco.com [10.61.65.164]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5G70cC04809; Fri, 16 Jun 2006 09:00:38 +0200 (CEST) Message-ID: <44925715.6010606@cisco.com> Date: Fri, 16 Jun 2006 09:00:37 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: Andrew Johnson , Paul Aitken , Gerhard Muenz , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <447C5FEE.6070700@cisco.com> <27523DAC-C962-4957-8B57-059D25DF6503@cert.org> <44898147.4000302@cisco.com> <448AB6F0.8050304@cisco.com> <448DF34A.6090409@informatik.uni-tuebingen.de> <6EA3D9A6D338F353A36B0E57@[10.1.1.104]><449176A8.2000402@cisco.com> <644030C97D1E02DC3E964E21@[192.168.1.128]> In-Reply-To: <644030C97D1E02DC3E964E21@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi Juergen, > Hi Benoit, > > --On 15.06.2006 17:03 Uhr +0200 Benoit Claise wrote: > >> Andrew, >>> >>>> Imagine that I configure an exporter reporting on each interface such >>>> that eth-n is observation domain 0x000n. All is good. >>>> >>>> Later I start a second exporter, but by some quirk (administrative >>>> typo, lightning strike, whatever) it's reporting eth-n as observation >>>> domain 0x000n+1. >>>> >>>> The data from each exporter is quite self-consistent, and it's not >>>> much of an issue if these exporters report to different collectors. >>>> >>>> However the data from the two exporters cannot be correctly >>>> reconciled when the data from the two collectors is eventually >>>> cross-referenced or when both exporters are reconfigured to export to >>>> just one collector. >>>> >>>> Clearly the observation domains must be consistent across all the >>>> exporters on the device, and not unique per exporer. >>>> >>>> This is because observation domains are a property of the system as a >>>> whole, related to the metering processes - and certainly not a >>>> property of each individual exporting process! >>> >>> Observation domains are not a property of an IPFIX device. >>> Traditionally >>> we are used to the set of observation points to be within a single >>> device, >>> but there is no need to this to be the case. If I have a set of >>> devices >>> communicating to a concentrator device, the concentrator will have an >>> ID which represents the superset of all the observation points it is >>> reporting on. >> This is the key question, as summarized in my initial email. Which IPFIX >> definition do we choose? >> Proposal 1: We keep the IPFIX device definition as defined right now, >> and it doesn't cover the special devices from RFC3917. Protocol >> unchanged. >> Proposal 2: We include all special cases in the IPFIX device >> definition, >> and we have to change something in the protocol. I was reading/answering the emails in sequence. Let's forget about this track (of changing the protocol) to focus on your last proposal http://ipfix.doit.wisc.edu/archive/3366.html, which I support. Regards, Benoit. > > Which changes do you think we would need to apply? > > Thanks, > > Juergen > >> 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 Fri Jun 16 03:58:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr9Dz-00085q-8w for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 03:58:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr90p-0001xE-Hw for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 03:45:03 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fr90n-0006h4-Ss for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 03:45:03 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fr8Gk-0003dC-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 01:57:26 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr8Gj-0003d7-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 01:57:25 -0500 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B5FEF1BAC4D; Fri, 16 Jun 2006 08:46:10 +0200 (CEST) Date: Fri, 16 Jun 2006 08:57:21 +0200 From: Juergen Quittek To: Andrew Johnson , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: <506BE0E841DACF34613747D4@[192.168.1.128]> In-Reply-To: <4491DAF1.4020200@cisco.com> References: <4491DAF1.4020200@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi Andrew, --On 15.06.2006 23:10 Uhr +0100 Andrew Johnson wrote: > [...] > The Observation Domain ID should remain unique within > the Exporting Process. Would you be fine with stating that it SHOULD be unique per IPFIX Device? 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 Fri Jun 16 04:55:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrA6h-0000Yy-Ip for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 04:55:11 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrA6g-0005La-9K for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 04:55:11 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fr9xl-0000Ws-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 03:45:57 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fr9xk-0000Wk-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 03:45:56 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5G8gNTO001062 for ; Fri, 16 Jun 2006 04:42:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix-protocol] FInialising documents Date: Fri, 16 Jun 2006 11:45:53 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix-protocol] FInialising documents Thread-Index: AcaQzTA8RfS6jS7DQNyWsPg+80pxJgAU7pbw From: "Romascanu, Dan \(Dan\)" To: "Nevil Brownlee" , "Benoit Claise" Cc: X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 6/20 is too late in order to catch the 6/22 IESG telechat. Unless you can submit the updated documents by Sunday 6/18, it will need to wait for the next telechat which I son 7/6.=20 Dan =20 =20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > Sent: Friday, June 16, 2006 1:42 AM > To: Benoit Claise > Cc: ipfix-protocol@net.doit.wisc.edu > Subject: [ipfix-protocol] FInialising documents >=20 >=20 > Hi Benoit: >=20 > Sounds fine to me. I'm working on a new revision of=20 > draft-architecture now, I'll make the change to the=20 > definition of * Observation Domain, to >=20 > ... > a single Exporting Process. It is RECOMMENDED that this ID is also > unique per IPFIX Device. >=20 > Following up on an email I sent Benoit yesterday, can we get=20 > new versions of the protocol and architecture drafts=20 > published by about next Tuesday (20 June)? If we can, we=20 > could ask Dan to get them onto the IESG telechat on 22 June ... >=20 > Cheers, Nevil >=20 > -------------------------------------------------------------- > --------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand >=20 > -------------------------------------------------------------- > --------- > This mail sent through University of Auckland=20 > http://www.auckland.ac.nz >=20 >=20 > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ >=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/ From jacobinefolmar@baystar.com Fri Jun 16 05:04:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrAFb-0006BU-80 for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 05:04:23 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrAFZ-0005fs-V7 for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 05:04:23 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrA6n-0000zA-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 03:55:17 -0500 Received: from baystar.com (cm218-252-108-141.hkcable.com.hk [218.252.108.141]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5G8tDu4009003 for ; Fri, 16 Jun 2006 03:55:16 -0500 Message-ID: <000001c69122$970635c0$3493a8c0@tqx21> Reply-To: "Jacobine Folmar" From: "Jacobine Folmar" To: ipfix-list@mil.doit.wisc.edu Subject: test fifoi Date: Fri, 16 Jun 2006 01:55:17 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C690E7.EAA75DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C690E7.EAA75DC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 R w ef g ina d nce $ 20 t 0 , 0 o 00 for $ 82 g 5 / mon p th =20 These R a ate b s W v on' j t L v ast Forever ,=20 Re d fi o nan p ce T q oda d y and S s av y e =20 =20 _____ =20 passages they had come through. That sent them on faster than ever, and as poor Bilbo could not possibly go half as fast-for dwarves can roll along at a tremendous pace, I can tell you, when they have to-they took it in turn to carry him on their backs. Still goblins go faster than ------=_NextPart_000_0001_01C690E7.EAA75DC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
R w ef g ina d nce $ 20 t 0 , 0 o 00 for $ 82 g 5 / mon p th
 
These R a ate b s W v on' j t L v ast Forever ,
Re d fi o nan p ce T q oda d y and S s av y e
 

passages they had come through. That = sent them on faster than ever, and
as poor Bilbo could not possibly go half as fast-for dwarves can = roll
along at a tremendous pace, I can tell you, when they have to-they = took
it in turn to carry him on their backs. Still goblins go faster = than
------=_NextPart_000_0001_01C690E7.EAA75DC0-- From majordomo@mil.doit.wisc.edu Fri Jun 16 06:11:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrBIT-0000tu-DM for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 06:11:25 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrBIS-0001hb-4n for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 06:11:25 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrB8N-0004M3-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 05:00:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrB8M-0004Ly-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 05:00:58 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2006 12:00:56 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5GA0trq007324; Fri, 16 Jun 2006 12:00:55 +0200 (MEST) Received: from [10.61.80.31] (ams3-vpn-dhcp4128.cisco.com [10.61.80.31]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA04530; Fri, 16 Jun 2006 11:00:54 +0100 (BST) Message-ID: <44928156.3090505@cisco.com> Date: Fri, 16 Jun 2006 11:00:54 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <4491DAF1.4020200@cisco.com> <506BE0E841DACF34613747D4@[192.168.1.128]> In-Reply-To: <506BE0E841DACF34613747D4@[192.168.1.128]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Juergen Quittek wrote: > Hi Andrew, > > --On 15.06.2006 23:10 Uhr +0100 Andrew Johnson wrote: >> > > [...] > >> The Observation Domain ID should remain unique within >> the Exporting Process. > > Would you be fine with stating that it SHOULD be unique per IPFIX Device? I don't think this change adds anything to the protocol, especially as a collector cannot rely on the IPFIX device implementing this recommendation. In other words, is anyone on the list still insisting on the change? I would prefer to not have the change, however if it is wanted I don't object. Andrew -- 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 Jun 16 07:28:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrCV5-0006Qh-75 for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 07:28:31 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrCV2-0004ph-N6 for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 07:28:31 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrCM2-0001ew-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 06:19:10 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrCM0-0001er-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 06:19:08 -0500 Received: from [192.168.1.128] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D0FB81BAC4D for ; Fri, 16 Jun 2006 13:07:49 +0200 (CEST) Date: Fri, 16 Jun 2006 13:19:01 +0200 From: Juergen Quittek To: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Message-ID: <30445D7687417D56F55CFEF8@[10.1.1.104]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Dear all, I posted a list of changes to the documents as a proposal for a compromise solution for the long discussion on observation domain ID uniqueness per exporting versus uniqueness per IPFIX device. Now it seems that we are close to an agreement on uniqueness per exporting process, which is in line with the current protocol and info model drafts. In case the WG agrees on that, here is the alternative (and shorter) list of changes to be applied: OLD [in IPFIX-ARCH and IPFIX-PROTO] * IPFIX Device An IPFIX Device hosts at least one Observation Point, a Metering Process and an Exporting Process. NEW * IPFIX Device An IPFIX Device hosts at least one Exporting Process. It may host further Exporting processes and arbitrary numbers of Observation Points and Metering Process. OLD [in IPFIX-ARCH] 5.4. Observation Domain The Observation Domain is a logical block that presents a single identity for a group of Observation Points within an IPFIX Device. Each {Observation Point, Metering Process} pair belongs to a single Observation Domain. An IPFIX Device could have multiple Observation Domains, each of which has a subset of the total set of Observation Points in it. Each Observation Domain must carry a unique ID within the context of an IPFIX Device. Note that in case of multiple Observation Domains, a unique ID per Observation Domain must be transmitted as a parameter to the Exporting Function. That unique ID is referred to as the IPFIX Observation Domain ID. NEW 5.4. Observation Domain The Observation Domain is a logical block that presents a single identity for a group of Observation Points. Each {Observation Point, Metering Process} pair SHOULD belong to a single Observation Domain. A single IPFIX Device may have multiple Observation Domains, each of which contains a subset of the total set of Observation Points. Each Observation Domain MUST carry a unique ID within the context of a single Exporting Process. OLD [in IPFIX-PROTO section 4.1 and section 4.2] sourceId An identifier of an Observation Domain NEW observationDomainId An identifier of an Observation Domain OLD [in IPFIX-PROTO section 3.4.2.1] exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX NEW exportingProcessId, observationDomainId, etc. are also valid scopes. The IPFIX OLD [in IPFIX-INFO] 5.1.10. sourceId NEW 5.1.10. observationDomainId Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 4342-115 NEC Europe Ltd., Network Laboratories Fax: +49 6221 4342-155 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 14.06.2006 17:28 Uhr +0200 Juergen Quittek wrote: > Dear all, > > It seems to be difficult to come to an end with this discussion. > Therefore, I try another approach. > > Below please find a proposal that might be acceptable to > all of us. It is a rather detailed one already containing > already concrete suggestions for text changes in our the three > documents. > > Please comment. > > Thanks, > > Juergen > > > OLD [in IPFIX-ARCH and IPFIX-PROTO] > * Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an observation domain if it > is composed of several interfaces, each of which is an Observation > Point. Each Observation Domain presents itself to the Collecting > Process using an Observation Domain ID to identify the IPFIX > Messages it generates. Observation Domain IDs are unique per > Exporting Process. > NEW [Just appended a sentence] > * Observation Domain > > An Observation Domain is the largest set of Observation Points for > which Flow information can be aggregated by a Metering Process. > For example, a router line card may be an observation domain if it > is composed of several interfaces, each of which is an Observation > Point. Each Observation Domain presents itself to the Collecting > Process using an Observation Domain ID to identify the IPFIX > Messages it generates. Observation Domain IDs are unique per > Exporting Process. It is RECOMMENDED that an Observation Domain IDs > is also unique per IPFIX device. > > OLD [in IPFIX-ARCH and IPFIX-PROTO] > * IPFIX Device > > An IPFIX Device hosts at least one Observation Point, a Metering > Process and an Exporting Process. > NEW > * IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting processes and arbitrary numbers of Observation Points > and Metering Process. > > OLD [in IPFIX-ARCH] > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points within an IPFIX Device. > Each {Observation Point, Metering Process} pair belongs to a single > Observation Domain. An IPFIX Device could have multiple Observation > Domains, each of which has a subset of the total set of Observation > Points in it. Each Observation Domain must carry a unique ID within > the context of an IPFIX Device. Note that in case of multiple > Observation Domains, a unique ID per Observation Domain must be > transmitted as a parameter to the Exporting Function. That unique ID > is referred to as the IPFIX Observation Domain ID. > NEW > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points. Each {Observation Point, > Metering Process} pair SHOULD belong to a single Observation Domain. > A single IPFIX Device may have multiple Observation Domains, each of > which contains a subset of the total set of Observation Points. > Each Observation Domain MUST carry a unique ID within the context of > a single Exporting Process. It is RECOMMENDED that this ID is also > unique per IPFIX Device. > > OLD [in IPFIX-PROTO section 3.1] > Observation Domain ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify > to the Collecting Process the Observation Domain that > metered the Flows. Collecting Processes SHOULD use the > NEW [inserted one sentence] > Observation Domain ID > A 32-bit identifier of the Observation Domain that is > locally unique to the Exporting Process. The Exporting > Process uses the Observation Domain ID to uniquely identify > to the Collecting Process the Observation Domain that > metered the Flows. It is RECOMMENDED that this identifier > is also unique per IPFIX Device. Collecting Processes > SHOULD use the > > OLD [in IPFIX-PROTO section 4.1 and section 4.2] > sourceId An identifier of an Observation Domain > NEW > observationDomainId An identifier of an Observation Domain > > OLD [in IPFIX-PROTO section 3.4.2.1] > exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX > NEW > exportingProcessId, observationDomainId, etc. are also valid scopes. The IPFIX > > OLD [in IPFIX-INFO] > 5.1.10. sourceId > > Description: > An identifier of an Observation Domain that is unique per > Exporting Process. Typically, this Information Element is used > for limiting the scope of other Information Elements. > NEW > 5.1.10. observationDomainId > > Description: > An identifier of an Observation Domain that is unique per > Exporting Process. It is RECOMMENDED that this identifier is > also unique per IPFIX device. Typically, this Information > Element is used for limiting the scope of other Information > Elements. > > > > -- > 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 Jun 16 10:16:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrF7U-0003XL-Fn for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:16:20 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrF7T-0000Gh-6N for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:16:20 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrEsK-00026b-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 09:00:40 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrEsJ-00026W-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 09:00:39 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5GE0cT17632; Fri, 16 Jun 2006 16:00:38 +0200 (CEST) Received: from [10.61.65.187] (ams3-vpn-dhcp443.cisco.com [10.61.65.187]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5GE0aC00292; Fri, 16 Jun 2006 16:00:36 +0200 (CEST) Message-ID: <4492B983.90309@cisco.com> Date: Fri, 16 Jun 2006 16:00:35 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Johnson CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <4491DAF1.4020200@cisco.com> <506BE0E841DACF34613747D4@[192.168.1.128]> <44928156.3090505@cisco.com> In-Reply-To: <44928156.3090505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Andrew Johnson wrote: > Juergen Quittek wrote: >> Hi Andrew, >> >> --On 15.06.2006 23:10 Uhr +0100 Andrew Johnson wrote: >>> >> >> [...] >> >>> The Observation Domain ID should remain unique within >>> the Exporting Process. >> >> Would you be fine with stating that it SHOULD be unique per IPFIX >> Device? > > I don't think this change adds anything to the protocol, especially > as a collector cannot rely on the IPFIX device implementing this > recommendation. > > In other words, is anyone on the list still insisting on the change? Yes, I insist. It would be more convenient for a router (I don't want to speak about the special devices) to assign the Observation Domain based on Line Card ID: one solution is the ENTITY-MIB to make sure it's unique. This is why I like the proposal from Juergen "It is RECOMMENDED that an Observation Domain IDs is also unique per IPFIX device. " Let's take this example: One sysadmin configures line card 1 with observation domain 1, while a second sysadmin configures line card 2 with the same observation domain Id 1. If each observation domain exports using its own exporting process with the identical source IP address, how would the collector differentiate the template IDs? [IPFIX-PROTO] says: Collecting Processes SHOULD use the combination of the Exporter (exporterIPv4Address, exporterIPv6Address, or exportingProcessId) and the Observation Domain ID field to separate different export streams originating from the same Exporting Process. If the Observation Domain Id is RECOMMENDED to be unique per device, ... - we don't have to deal with the notion of uniqueness per session (in this case 2 sessions) - we don't have the issue to clearly identify the Exporting Process on an IPFIX device with an exportingProcessId (in this case 2 exporting processes) as the management of this exportingProcessId is not described. - we don't have to describe in IPFIX what the Observation Domain is (in this case 2 different line card) ... in order to know that the flow records comes from two different line cards. BTW, the case of "One sysadmin configures line card 1 with observation domain 1, while a second sysadmin configures line card 2 with the same observation domain Id 1" would not be possible. Regards, Benoit. > > I would prefer to not have the change, however if it is wanted I > don't object. > > > Andrew > > -- > 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 Jun 16 10:21:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFCI-00047N-Aq for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:21:18 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFCH-0000MQ-1V for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:21:18 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrEwV-0002LU-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 09:04:59 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrEwU-0002LP-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 09:04:58 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5GE4vq17995; Fri, 16 Jun 2006 16:04:57 +0200 (CEST) Received: from [10.61.65.187] (ams3-vpn-dhcp443.cisco.com [10.61.65.187]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5GE4uC04624; Fri, 16 Jun 2006 16:04:56 +0200 (CEST) Message-ID: <4492BA86.6080203@cisco.com> Date: Fri, 16 Jun 2006 16:04:54 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <30445D7687417D56F55CFEF8@[10.1.1.104]> In-Reply-To: <30445D7687417D56F55CFEF8@[10.1.1.104]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Juergen, > Dear all, > > I posted a list of changes to the documents as a proposal for > a compromise solution for the long discussion on observation > domain ID uniqueness per exporting versus uniqueness per IPFIX > device. > > Now it seems that we are close to an agreement on uniqueness > per exporting process, which is in line with the current > protocol and info model drafts. Note quite. See my previous email > > In case the WG agrees on that, here is the alternative (and > shorter) list of changes to be applied: Since you removed "It is RECOMMENDED that an Observation Domain IDs is also unique per IPFIX device.", then I favor your previous proposal http://ipfix.doit.wisc.edu/archive/3366.html, which btw nobody objected. Regards, Benoit. > > OLD [in IPFIX-ARCH and IPFIX-PROTO] > * IPFIX Device > > An IPFIX Device hosts at least one Observation Point, a Metering > Process and an Exporting Process. > NEW > * IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may host > further Exporting processes and arbitrary numbers of Observation > Points > and Metering Process. > > OLD [in IPFIX-ARCH] > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points within an IPFIX Device. > Each {Observation Point, Metering Process} pair belongs to a single > Observation Domain. An IPFIX Device could have multiple Observation > Domains, each of which has a subset of the total set of Observation > Points in it. Each Observation Domain must carry a unique ID within > the context of an IPFIX Device. Note that in case of multiple > Observation Domains, a unique ID per Observation Domain must be > transmitted as a parameter to the Exporting Function. That unique ID > is referred to as the IPFIX Observation Domain ID. > NEW > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points. Each {Observation Point, > Metering Process} pair SHOULD belong to a single Observation Domain. > A single IPFIX Device may have multiple Observation Domains, each of > which contains a subset of the total set of Observation Points. > Each Observation Domain MUST carry a unique ID within the context of > a single Exporting Process. > > OLD [in IPFIX-PROTO section 4.1 and section 4.2] > sourceId An identifier of an Observation Domain > NEW > observationDomainId An identifier of an Observation Domain > > OLD [in IPFIX-PROTO section 3.4.2.1] > exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX > NEW > exportingProcessId, observationDomainId, etc. are also valid > scopes. The IPFIX > > OLD [in IPFIX-INFO] > 5.1.10. sourceId > NEW > 5.1.10. observationDomainId > > 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 Fri Jun 16 10:35:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFQS-0001RH-EV for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:35:56 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFQR-0002PT-4I for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:35:56 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrFCh-0003cW-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 09:21:43 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrFCg-0003bt-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 09:21:42 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2006 16:21:42 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5GELerq023397; Fri, 16 Jun 2006 16:21:40 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA03697; Fri, 16 Jun 2006 15:21:40 +0100 (BST) Message-ID: <4492BE73.3050409@cisco.com> Date: Fri, 16 Jun 2006 15:21:39 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals References: <4491DAF1.4020200@cisco.com> <506BE0E841DACF34613747D4@[192.168.1.128]> <44928156.3090505@cisco.com> <4492B983.90309@cisco.com> In-Reply-To: <4492B983.90309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Hi Benoit I recognise that having the observation domain unique per device is a useful convention and by all means we can recommend it. I think below you have highlighted a large problem. I will deal with this in a separate mail with a change of subject. Then the rest of the mailing list might read it :). Andrew >> In other words, is anyone on the list still insisting on the change? > Yes, I insist. > > It would be more convenient for a router (I don't want to speak about > the special devices) to assign the Observation Domain based on Line Card > ID: one solution is the ENTITY-MIB to make sure it's unique. > This is why I like the proposal from Juergen "It is RECOMMENDED that an > Observation Domain IDs is also unique per IPFIX device. " > > Let's take this example: One sysadmin configures line card 1 with > observation domain 1, while a second sysadmin configures line card 2 > with the same observation domain Id 1. If each observation domain > exports using its own exporting process with the identical source IP > address, how would the collector differentiate the template IDs? > [IPFIX-PROTO] says: > > Collecting Processes SHOULD use the combination of > the Exporter (exporterIPv4Address, exporterIPv6Address, or > exportingProcessId) and the Observation Domain ID field to > separate different export streams originating from the same > Exporting Process. > > If the Observation Domain Id is RECOMMENDED to be unique per device, ... > - we don't have to deal with the notion of uniqueness per session (in > this case 2 sessions) > - we don't have the issue to clearly identify the Exporting Process > on an IPFIX device with an exportingProcessId (in this case 2 exporting > processes) as the management of this exportingProcessId is not described. > - we don't have to describe in IPFIX what the Observation Domain is > (in this case 2 different line card) > ... in order to know that the flow records comes from two different line > cards. > BTW, the case of "One sysadmin configures line card 1 with observation > domain 1, while a second sysadmin configures line card 2 with the same > observation domain Id 1" would not be possible. > > Regards, Benoit. >> >> I would prefer to not have the change, however if it is wanted I >> don't object. >> >> >> Andrew >> >> -- >> 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 Jun 16 10:38:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFSk-0002fu-Dw for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:38:18 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFSi-0002Ti-Rn for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:38:18 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrFHL-0004Jr-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 09:26:31 -0500 Received: from franclinus.red.cert.org ([192.88.209.16]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrFHK-0004Jm-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 09:26:30 -0500 Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.20) with ESMTP id k5GEQS3G024683 for ; Fri, 16 Jun 2006 10:26:28 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k5GEQJXd024671 for ; Fri, 16 Jun 2006 10:26:19 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k5GEQFLL024666; Fri, 16 Jun 2006 10:26:19 -0400 (EDT) Received: from [128.237.238.222] (vpn-10-25-4-16.remote.cert.org [10.25.4.16]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.60) with ESMTP id k5GEQEO9000364; Fri, 16 Jun 2006 10:26:15 -0400 In-Reply-To: <30445D7687417D56F55CFEF8@[10.1.1.104]> References: <30445D7687417D56F55CFEF8@[10.1.1.104]> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-2-362078393" Message-Id: Cc: ipfix-protocol@net.doit.wisc.edu Content-Transfer-Encoding: 7bit From: Brian Trammell Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals Date: Fri, 16 Jun 2006 10:26:09 -0400 To: Juergen Quittek X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.750) X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000005 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-2-362078393 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Juergen, These changes look good. And now for the related problem: Are we planning on keeping the Observation Domain ID header field definition in 3.1 (page 13 of -21) as-is? Either this or the Template ID definition in 3.4.1 (page 18 of -21) must change; else Templates are scoped within Observation Domains are scoped within (one of exporterIPv4Address, exporterIPv6Address, exporterProcessId), which are not guaranteed to be available to the Collecting Process (i.e. exporterProcessId is not present in the message header, addresses are not unique over SCTP) without explicit export, which requires a template. I would propose changing the Template ID definition to read as follows: OLD Template ID Each of the newly generated Template Records is given a unique Template ID. This uniqueness is local to the Observation Domain that generated the Template ID. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints regarding the order of the Template ID allocation. NEW Template ID Each Template Record is given a unique Template ID by the Exporting Process. This uniqueness is local to the session in which the template is transmitted (e.g., the TCP connection or the SCTP association). Template IDs are managed and reused as in sections 8, 10.3.6, and 10.4.2.2 of this document. Template IDs 0-255 are reserved for Template Sets, Options Template Sets, and other reserved Sets yet to be created. Template IDs of Data Sets are numbered from 256 to 65535. There are no constraints regarding the order of the Template ID allocation. [Note that I have not yet reviewed the language in the referenced sections to ensure congruence with this change; I will volunteer to do so if required, and if the WG consensus is to go with this.] The primary negative impact of this change is that templateIDs have no meaning outside their use in the transport protocol, and can no longer be abused as generic scope. With commonPropertiesId now available with 2^64 codepoints, this is not, I think, a significant drawback. Regards, Brian On Jun 16, 2006, at 7:19 AM, Juergen Quittek wrote: > Dear all, > > I posted a list of changes to the documents as a proposal for > a compromise solution for the long discussion on observation > domain ID uniqueness per exporting versus uniqueness per IPFIX > device. > > Now it seems that we are close to an agreement on uniqueness > per exporting process, which is in line with the current > protocol and info model drafts. > > In case the WG agrees on that, here is the alternative (and > shorter) list of changes to be applied: > > OLD [in IPFIX-ARCH and IPFIX-PROTO] > * IPFIX Device > > An IPFIX Device hosts at least one Observation Point, a Metering > Process and an Exporting Process. > NEW > * IPFIX Device > > An IPFIX Device hosts at least one Exporting Process. It may > host > further Exporting processes and arbitrary numbers of > Observation Points > and Metering Process. > > OLD [in IPFIX-ARCH] > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points within an IPFIX Device. > Each {Observation Point, Metering Process} pair belongs to a single > Observation Domain. An IPFIX Device could have multiple Observation > Domains, each of which has a subset of the total set of Observation > Points in it. Each Observation Domain must carry a unique ID within > the context of an IPFIX Device. Note that in case of multiple > Observation Domains, a unique ID per Observation Domain must be > transmitted as a parameter to the Exporting Function. That > unique ID > is referred to as the IPFIX Observation Domain ID. > NEW > 5.4. Observation Domain > > The Observation Domain is a logical block that presents a single > identity for a group of Observation Points. Each {Observation Point, > Metering Process} pair SHOULD belong to a single Observation Domain. > A single IPFIX Device may have multiple Observation Domains, each of > which contains a subset of the total set of Observation Points. > Each Observation Domain MUST carry a unique ID within the context of > a single Exporting Process. > > OLD [in IPFIX-PROTO section 4.1 and section 4.2] > sourceId An identifier of an Observation Domain > NEW > observationDomainId An identifier of an Observation Domain > > OLD [in IPFIX-PROTO section 3.4.2.1] > exportingProcessId, sourceId, etc. are also valid scopes. The IPFIX > NEW > exportingProcessId, observationDomainId, etc. are also valid > scopes. The IPFIX > > OLD [in IPFIX-INFO] > 5.1.10. sourceId > NEW > 5.1.10. observationDomainId > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 > 4342-115 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 > 4342-155 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http:// > www.netlab.nec.de > > > > --On 14.06.2006 17:28 Uhr +0200 Juergen Quittek wrote: > >> Dear all, >> >> It seems to be difficult to come to an end with this discussion. >> Therefore, I try another approach. >> >> Below please find a proposal that might be acceptable to >> all of us. It is a rather detailed one already containing >> already concrete suggestions for text changes in our the three >> documents. >> >> Please comment. >> >> Thanks, >> >> Juergen >> >> >> OLD [in IPFIX-ARCH and IPFIX-PROTO] >> * Observation Domain >> >> An Observation Domain is the largest set of Observation >> Points for >> which Flow information can be aggregated by a Metering Process. >> For example, a router line card may be an observation domain >> if it >> is composed of several interfaces, each of which is an >> Observation >> Point. Each Observation Domain presents itself to the >> Collecting >> Process using an Observation Domain ID to identify the IPFIX >> Messages it generates. Observation Domain IDs are unique per >> Exporting Process. >> NEW [Just appended a sentence] >> * Observation Domain >> >> An Observation Domain is the largest set of Observation >> Points for >> which Flow information can be aggregated by a Metering Process. >> For example, a router line card may be an observation domain >> if it >> is composed of several interfaces, each of which is an >> Observation >> Point. Each Observation Domain presents itself to the >> Collecting >> Process using an Observation Domain ID to identify the IPFIX >> Messages it generates. Observation Domain IDs are unique per >> Exporting Process. It is RECOMMENDED that an Observation >> Domain IDs >> is also unique per IPFIX device. >> >> OLD [in IPFIX-ARCH and IPFIX-PROTO] >> * IPFIX Device >> >> An IPFIX Device hosts at least one Observation Point, a >> Metering >> Process and an Exporting Process. >> NEW >> * IPFIX Device >> >> An IPFIX Device hosts at least one Exporting Process. It >> may host >> further Exporting processes and arbitrary numbers of >> Observation Points >> and Metering Process. >> >> OLD [in IPFIX-ARCH] >> 5.4. Observation Domain >> >> The Observation Domain is a logical block that presents a single >> identity for a group of Observation Points within an IPFIX Device. >> Each {Observation Point, Metering Process} pair belongs to a >> single >> Observation Domain. An IPFIX Device could have multiple >> Observation >> Domains, each of which has a subset of the total set of >> Observation >> Points in it. Each Observation Domain must carry a unique ID >> within >> the context of an IPFIX Device. Note that in case of multiple >> Observation Domains, a unique ID per Observation Domain must be >> transmitted as a parameter to the Exporting Function. That >> unique ID >> is referred to as the IPFIX Observation Domain ID. >> NEW >> 5.4. Observation Domain >> >> The Observation Domain is a logical block that presents a single >> identity for a group of Observation Points. Each {Observation >> Point, >> Metering Process} pair SHOULD belong to a single Observation >> Domain. >> A single IPFIX Device may have multiple Observation Domains, >> each of >> which contains a subset of the total set of Observation Points. >> Each Observation Domain MUST carry a unique ID within the >> context of >> a single Exporting Process. It is RECOMMENDED that this ID is >> also >> unique per IPFIX Device. >> >> OLD [in IPFIX-PROTO section 3.1] >> Observation Domain ID >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Observation Domain ID to uniquely >> identify >> to the Collecting Process the Observation Domain that >> metered the Flows. Collecting Processes SHOULD use the >> NEW [inserted one sentence] >> Observation Domain ID >> A 32-bit identifier of the Observation Domain that is >> locally unique to the Exporting Process. The Exporting >> Process uses the Observation Domain ID to uniquely >> identify >> to the Collecting Process the Observation Domain that >> metered the Flows. It is RECOMMENDED that this identifier >> is also unique per IPFIX Device. Collecting Processes >> SHOULD use the >> >> OLD [in IPFIX-PROTO section 4.1 and section 4.2] >> sourceId An identifier of an Observation >> Domain >> NEW >> observationDomainId An identifier of an Observation >> Domain >> >> OLD [in IPFIX-PROTO section 3.4.2.1] >> exportingProcessId, sourceId, etc. are also valid scopes. The >> IPFIX >> NEW >> exportingProcessId, observationDomainId, etc. are also valid >> scopes. The IPFIX >> >> OLD [in IPFIX-INFO] >> 5.1.10. sourceId >> >> Description: >> An identifier of an Observation Domain that is unique per >> Exporting Process. Typically, this Information Element is used >> for limiting the scope of other Information Elements. >> NEW >> 5.1.10. observationDomainId >> >> Description: >> An identifier of an Observation Domain that is unique per >> Exporting Process. It is RECOMMENDED that this identifier is >> also unique per IPFIX device. Typically, this Information >> Element is used for limiting the scope of other Information >> Elements. >> >> >> >> -- >> 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/ --Apple-Mail-2-362078393 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFEkr+F4/8LCZ4pwvYRAsjHAKDqEUHx/oQMk5y5+/wzP+kCia1y3ACfRUxP V3i6ERvpRnBKSXVwtCraLCI= =yrdU -----END PGP SIGNATURE----- --Apple-Mail-2-362078393-- -- 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 Jun 16 10:50:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFem-000207-Km for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:50:44 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrFel-0003NF-9u for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 10:50:44 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrFb7-0004o8-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 09:46:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrFb6-0004o1-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 09:46:56 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 16 Jun 2006 16:46:55 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5GEkrrq001606; Fri, 16 Jun 2006 16:46:53 +0200 (MEST) Received: from [144.254.153.27] (dhcp-144-254-153-27.cisco.com [144.254.153.27]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA07311; Fri, 16 Jun 2006 15:46:52 +0100 (BST) Message-ID: <4492C45C.2080804@cisco.com> Date: Fri, 16 Jun 2006 15:46:52 +0100 From: Andrew Johnson User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Benoit Claise CC: Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] Collectors cannot differentiate between Exporting Processes properly! References: <4491DAF1.4020200@cisco.com> <506BE0E841DACF34613747D4@[192.168.1.128]> <44928156.3090505@cisco.com> <4492B983.90309@cisco.com> In-Reply-To: <4492B983.90309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Benoit Claise wrote: > Let's take this example: One sysadmin configures line card 1 with > observation domain 1, while a second sysadmin configures line card 2 > with the same observation domain Id 1. If each observation domain > exports using its own exporting process with the identical source IP > address, how would the collector differentiate the template IDs? OK, so let's assume that your two processes are exporting using the same IP address, however since they are different processes they will use a different UDP source port. Let's also consider a second example at the same time. Imagine a second exporting process on line card 1. It will export for the same observation domain (coincidently or because we have used the recommendation). Again, these processes are exporting using the same source IP address, but different UDP source ports. > [IPFIX-PROTO] says: > > Collecting Processes SHOULD use the combination of > the Exporter (exporterIPv4Address, exporterIPv6Address, or > exportingProcessId) and the Observation Domain ID field to > separate different export streams originating from the same > Exporting Process. OK, so in your example, the two processes have the same IP address and the same odIds. The collector can't tell the difference, which is bad! Your proposal of odIds which are unique per device solves this issue by giving your two processes different odIds. Great, but in my example the two processes are operating from the same OD. The collector still can't differentiate between them. The problem is that the IP address alone is not sufficient to differentiate between Exporting Processes. For that to work we would have to insist that each Exporting Process in a device MUST export with a unique IP address. I think that a collector must also use the source port from the transport protocol to differentiate between Exporting Processes. Brian has conveniently highlighted another problem. SCTP allows a connection to be maintained across a set of IP addresses. SCTP will send the complete set of IP addresses currently in use no matter which IP address it is using at the moment. So the collecting process will have to be a bit cleverer at identifying that the IP address of an Exporting Process is from the set of IP addresses it could be using. regards Andrew > If the Observation Domain Id is RECOMMENDED to be unique per device, ... > - we don't have to deal with the notion of uniqueness per session (in > this case 2 sessions) > - we don't have the issue to clearly identify the Exporting Process > on an IPFIX device with an exportingProcessId (in this case 2 exporting > processes) as the management of this exportingProcessId is not described. > - we don't have to describe in IPFIX what the Observation Domain is > (in this case 2 different line card) > ... in order to know that the flow records comes from two different line > cards. > BTW, the case of "One sysadmin configures line card 1 with observation > domain 1, while a second sysadmin configures line card 2 with the same > observation domain Id 1" would not be possible. > > Regards, Benoit. >> >> I would prefer to not have the change, however if it is wanted I >> don't object. >> >> >> Andrew >> >> -- >> 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 brown_4_bbc@yahoo.co.jp Fri Jun 16 11:10:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrFyF-00061c-FL for ipfix-archive@megatron.ietf.org; Fri, 16 Jun 2006 11:10:51 -0400 Received: from [221.122.157.65] (helo=megatron.ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrFyD-0004Yn-PE for ipfix-archive@megatron.ietf.org; Fri, 16 Jun 2006 11:10:51 -0400 To: From: =?iso-2022-jp?B?cXFx?= Subject: =?iso-2022-jp?B?GyRCIXk1Lkp9JEAkMSRLIXkbKEI=?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 $B$"$J$?$K$*2q$$$7$?$$$H$$$&=w@-$+$iO"Mm$,Mh$F$*$j$^$9!*(B 1000$B?M$K0l?M$N40A4(BVIP$BBT6x$G$N$4>7BT$H$J$j$^$9$N$G5.J}$@$1$N8fM%BT$H$J$j$^$9!*(B $B7n(B1$B!A(B3$B2s$N%G!<%H$G7n(B30$B$N5U%5%]$,:GDc8B$N%i%$%s$J$N$G!"(B $B=w@-$K$h$C$F$O$=$l0J>e$N5U%5%]$,4|BT$G$-$^$9$h(B(o^-') $B!!(B $B!!(B $B!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y!y(B $B$5$i$K!"??7u$J8r:]$r4uK>$5$l$kJ}$N$?$a$K!"L5NA$G5.J}$N$*=;$^(B $B$$$N6a$/$N=w@-%;%l%V$rL5NA$G8!:w$9$k?7$7$$$4>R2p%5!<%S%9$rDs(B $B6!$$$?$7$^$9!#(B $B$5$"!"H`=w$r$5$=$C$F!"?M@8$N>!$AAH$_$K$J$j$^$7$g$&!#(B $B$^$H$^$C$?$*6b$,M_$7$$5.J}!"?M@8$N%Q!<%H%J!<$,M_$7$$5.J}!"R2p$7$^$9!#(B $B!Z=w@->R2p![(B $B"#??H~"M(Bhttp://rrnj.com?mami $B"#(B28$B:P(B $BI>!'%9%?%$%kH472$N$+$o$$$$%-%e!<%H$J=w@-!#$O$_=P$7$?B@$b$b!"$*?,$H9x$K$T$C$?$j$N%[%C%H%Q%s%D%U%!%C%7%g%s$O7]=QIJ$G$9!#O"Mm$7$F$/$l$?$iH`=w$N4i$H?-=L$N$"$k%[%C%H%Q%s%D$K$*?,$N%i%$%s$,%/%C%-%j$Ny%^%s%7%g%s$K=;$s$G$$$^$9!#;E;v$@$1$N(B $BI>!'#F%+%C%W!#%-%e!<%H$5$HBg?M$NJ70O5$$N=w@-!#%m%s%0$NH1$H9x$N$/$S$l$H%R%C%W%i%$%s$O?'5$H472!*G/<}(B1500$BK|1_(B $B!X%9%?%$%k$,$$$$$M$C$F8@$o$l$^$9!#FC$K%R%C%W%i%$%s$H%_%K%9%+!<%H;Q$K<+?.$,$"$j$^$9!De$2$F$$$?$i!"6a$/$G8+$F$$$?CfG/$N$*$8MM$,;d$N%H%l!<%K%s%0%9%Q%C%D$rM_$7$$$HGw$k$N$G!";EJ}$J$$$+$i:9$7>e$2$A$c$$$^$7$?!#$"$J$?$H@e$r$+$i$^$;$F;d$NB)$rSL$$$G$/$l$^$;$s$+!)$=$7$FBC1U$r0{$_$"$$$^$7$g$&!#$<$R!"5.J}$HH)$HH)$r=E$M9g$o$;$?$$$N$G!"$*JV;v$/$@$5$$$M!#!Y(B $B"#fF;R"M(Bhttp://rrnj.com?punch $B"#(B30$BBe(B $BI>!'$4.$5L\$N#T%P%C%/$O$$$F$$$k$s$@$1$I!"CQ$:$+$7$$OC$@$1$I!"EEe$2$F$/$@$5$$!#$=$l$,$9$4$/5$;}$A$,$$$$$s$G$9!#%9%?%$%k$@$C$F<+?.$,$"$k$7!"5.J}$r4n$P$;$k<+?.$O$"$j$^$9!#(B $B;d$^$@$^$@=w$G$$$?$$$s$G$9!D;I7c$rM?$($F$/$@$5$$!#$*4j$$$7$^$9!#!Y(B $B"($=$NB>!"B?$/$N%j%C%A$J=w@-$r5.J}$K>R2p$7$^$9!#(B $B"($*Ni$K4X$7$F$O!":GDcJs>)6b0l2s(B20$BK|0J>eJ]>Z$7$^$9$N$G!";YJ'$$J}K!$OH`=w$i$H8r>D$7$F$/$@$5$$!#(B $B"($J$*!"5.J}$+$i$N%a!<%k$,L5$$>l9g$O!"B>$NJ}$X$4>R2p$9$k$3$H$K$J$k$+$bCN$l$J$$$N$G!"$J$k$Y$/Aa$a$N%a!<%kAw?.$r$*4j$$$7$^$9!#(B $B40A4(BVIP$B>7BT>u$,FO$$$?$"$J$?$@$1$,F~$l$kF~$j8}$+$i$*F~$j2<$5$$!#(B $BCm!K$4MxMQ$N:]$K$O%^%J!<$H%b%i%k$r To: Subject: Need a{} Diploma? Date: Fri, 16 Jun 2006 15:52:20 -0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: T8sZ2qQbJyPhAnUckjja6GYE8qGV4gnb2xxF Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 In just 2 years you can have a masters degree from a national university. A better job, more income and a better life can all be yours in just 2 years. No books to buy, no classes to go to, and no entrance exams. Learn in your own home at your own pace. We supply all the study materials, all you have to do is study and complete 2 tests per month. Phone Us Right Away +1 (831) 302 66 63 Online Now -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= churchyard distort boxwood confuse beaver cerebral acrid bout From 626jaime@walla.com Fri Jun 16 15:58:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKSR-0001RF-Tq for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 15:58:20 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKSQ-0002q5-Bf for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 15:58:19 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrKP6-0005jl-00; Fri, 16 Jun 2006 14:54:52 -0500 Received: from HELENA-98FCCF13 (host86-139-198-45.range86-139.btcentralplus.com [86.139.198.45]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5GJsoHs015148; Fri, 16 Jun 2006 14:54:51 -0500 Message-Id: <200606161954.k5GJsoHs015148@smtp.doit.wisc.edu> From: "Kurtis Blanton" <738dick@mamma.com> To: Subject: Fw: Do you want a prosperous future? GET YOUR UNIVERSITY DIPLOMA! Date: Fri, 16 Jun 2006 20:56:37 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: HDDNGlD3aotMrPHmVyUYYVkLyfO3E8nR4E67 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c In just 2 years you can have a masters degree from a national university. A better job, more income and a better life can all be yours in just 2 years. No books to buy, no classes to go to, and no entrance exams. Learn in your own home at your own pace. We supply all the study materials, all you have to do is study and complete 2 tests per month. Telephone Us Instantly +1 (831) 302 66 63 24/7 -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ alveolar aleph dactyl chastity amphetamine benelux centimeter adsorb From majordomo@mil.doit.wisc.edu Fri Jun 16 16:52:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrLIv-0001HA-8z for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 16:52:33 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrLIt-0001SS-SA for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 16:52:33 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FrLFn-0001OV-00 for ipfix-list@mil.doit.wisc.edu; Fri, 16 Jun 2006 15:49:19 -0500 Received: from odd-brew.cisco.com ([144.254.15.119] helo=av-tac-bru.cisco.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrLFm-0001Mc-00 for ipfix-protocol@net.doit.wisc.edu; Fri, 16 Jun 2006 15:49:18 -0500 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5GKnCj13085; Fri, 16 Jun 2006 22:49:12 +0200 (CEST) Received: from [10.61.65.187] (ams3-vpn-dhcp443.cisco.com [10.61.65.187]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k5GKn8C29341; Fri, 16 Jun 2006 22:49:08 +0200 (CEST) Message-ID: <44931943.3020205@cisco.com> Date: Fri, 16 Jun 2006 22:49:07 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" CC: Nevil Brownlee , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] FInialising documents References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000603090904000805080505" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 This is a multi-part message in MIME format. --------------000603090904000805080505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dan, All, I will submit the draft on Sunday, with the proposed changes in http://ipfix.doit.wisc.edu/archive/3366.html. Unless someone objects. Regards, Benoit. > 6/20 is too late in order to catch the 6/22 IESG telechat. Unless you > can submit the updated documents by Sunday 6/18, it will need to wait > for the next telechat which I son 7/6. > > Dan > > > > > > >> -----Original Message----- >> From: majordomo listserver >> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee >> Sent: Friday, June 16, 2006 1:42 AM >> To: Benoit Claise >> Cc: ipfix-protocol@net.doit.wisc.edu >> Subject: [ipfix-protocol] FInialising documents >> >> >> Hi Benoit: >> >> Sounds fine to me. I'm working on a new revision of >> draft-architecture now, I'll make the change to the >> definition of * Observation Domain, to >> >> ... >> a single Exporting Process. It is RECOMMENDED that this ID is also >> unique per IPFIX Device. >> >> Following up on an email I sent Benoit yesterday, can we get >> new versions of the protocol and architecture drafts >> published by about next Tuesday (20 June)? If we can, we >> could ask Dan to get them onto the IESG telechat on 22 June ... >> >> Cheers, Nevil >> >> -------------------------------------------------------------- >> --------- >> Nevil Brownlee Computer Science Department | ITSS >> Phone: +64 9 373 7599 x88941 The University of Auckland >> FAX: +64 9 373 7453 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/ >> >> > > -- > 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/ > --------------000603090904000805080505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan, All,

I will submit the draft on Sunday, with the proposed changes in http://ipfix.doit.wisc.edu/archive/3366.html.
Unless someone objects.

Regards, Benoit.
6/20 is too late in order to catch the 6/22 IESG telechat. Unless you
can submit the updated  documents by Sunday 6/18, it will need to wait
for the next telechat which I son 7/6. 

Dan


 
 

  
-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee
Sent: Friday, June 16, 2006 1:42 AM
To: Benoit Claise
Cc: ipfix-protocol@net.doit.wisc.edu
Subject: [ipfix-protocol] FInialising documents


Hi Benoit:

Sounds fine to me.  I'm working on a new revision of 
draft-architecture now, I'll make the change to the 
definition of * Observation Domain, to

   ...
   a single Exporting Process.  It is RECOMMENDED that this ID is also
   unique per IPFIX Device.

Following up on an email I sent Benoit yesterday, can we get 
new versions of the protocol and architecture drafts 
published by about next Tuesday (20 June)?  If we can, we 
could ask Dan to get them onto the IESG telechat on 22 June ...

Cheers, Nevil

--------------------------------------------------------------
---------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      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/

    

--
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/
  

--------------000603090904000805080505-- -- 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 Debra.Conley@destinationjacksonhole.com Fri Jun 16 18:37:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrMwB-0001BI-4m for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 18:37:11 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrMw9-0003dI-Tz for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 18:37:11 -0400 Received: from 59.185.176.60.broad.hz.zj.dynamic.cndata.com ([60.176.185.59] helo=50D2E18) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FrMsg-0006lQ-00; Fri, 16 Jun 2006 17:33:37 -0500 Received: by ambasciatoripalace.com (PowerMTA(TM) v3.0r8) id %NEW610MSGID; Fri, 16 Jun 2006 17:33:30 -0600 (envelope-from ) Thread-Topic: Re:Mrs? X-BPS2: %LOWSTAT X-BPS1: %XBPSID X-campaignid: R.39128-U.25723-Y.%XBPSID-QB.%LOWSTAT thread-index: UZgBnOcbxdF96LhZNLS4weyZLQEL60== Reply-to: "Leon Goodrich" From: "Leon Goodrich" To: ipfix-list@mil.doit.wisc.edu Cc: majordomo@mil.doit.wisc.edu Subject: Re:Mrs? Date: Fri, 16 Jun 2006 17:33:30 -0600 Message-ID: <%NEW610MSGID$%LOWERDIGIT[8]$%LOWERDIGIT[8]@%LOWERDIGIT[8]> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Windows 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?60.176.185.59 X-Spam-Score: 2.5 (++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Decrease your monthly mortgage payments by more than 1/3. Junes Prequalified-Rates ______________________ $331,000.00 @ 4.00% $694,000.00 @ 3.89% $534,000.00 @ 3.48% http://geocities.yahoo.com.br/krieg7suitcasejake From kamilahstone@too.de Sat Jun 17 04:39:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrWLM-0004yN-S5 for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 04:39:48 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrWLL-0000AH-Ax for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 04:39:48 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrWEZ-0000C7-00 for ipfix-list@mil.doit.wisc.edu; Sat, 17 Jun 2006 03:32:47 -0500 Received: from BABY ([81.1.225.210]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5H8WkY0020358 for ; Sat, 17 Jun 2006 03:32:46 -0500 Message-Id: <004a01c691dd$f6241e80$bcb0322d@juzuvzy> From: "esra gleason" To: "crichton carmichael" Subject: Cash, sponge tree Date: Sat, 17 Jun 2006 03:25:04 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C691DD.F6241E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. ------=_NextPart_000_004A_01C691DD.F6241E80 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. Apply online now for your instant quote. Stop over paying...=20 http://travag.org/d2/ warrant officer turning engine truck farm rage-swelling grass snake zeal-inspiring bob veal pear thorn alfalfa meal bedbug hunter hornblende-gabbro chance-won dusky-ma= ntled F-flat sleeve target scrap rubber grim-visaged glow light mind-healing school child seven-horned damper rail chassis painter self-imposed well-launched air-formed yard slings strange-favored violet-scented gate tower fair-traded ------=_NextPart_000_004A_01C691DD.F6241E80 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.
Apply online now for your instant quote. Stop over paying...

http://travag.org/d2/

warrant officer turning engine truck farm rage-swelling grass snake
zeal-inspiring bob veal
pear thorn alfalfa meal bedbug hunter hornblende-gabbro chance-won dusky-ma= ntled
F-flat sleeve target scrap rubber grim-visaged glow light
mind-healing school child seven-horned
damper rail chassis painter self-imposed
well-launched air-formed yard slings strange-favored violet-scented
gate tower fair-traded
= ------=_NextPart_000_004A_01C691DD.F6241E80-- From advertising@4webmarketing.biz Sat Jun 17 07:08:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrYeq-0008HY-4W for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 07:08:04 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrYek-0006nk-RH for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 07:08:04 -0400 Received: from [203.117.211.190] (helo=localhost) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FrYVT-0001gM-00 for ipfix-list@mil.doit.wisc.edu; Sat, 17 Jun 2006 05:58:23 -0500 Message-ID: <000501c691fd$03e04940$bed375cb@localhost> Reply-To: acecheckcash@aol.com From: advertising@4webmarketing.biz To: ipfix-list@mil.doit.wisc.edu Subject: =?us-ascii?B?QUNFIENoZWNrIEV4cHJlc3MgSW5jLiBoYXMgaW1tZWRpYXRlIHdv?= =?us-ascii?B?cmsgZm9yIEF1c3RyYWxpYW4gYW5kIE5ldyBaZWFsYW5kIGNpdGl6?= =?us-ascii?B?ZW5z?= Date: Sat, 17 Jun 2006 06:58:50 -0400 MIME-Version: 1.0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced by Microsoft MimeOLE 6.00.2900.2180 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?203.117.211.190 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ACE Check Express Inc. was founded in 1996 as a partner and connecting link between hundreds of banks in the world engaged in e-commerce. Our specialists from the Institute of Economic Research created the ACE Money Turnover® - the system that ensured quality, high speed and reliability of money transfer. As of today, ACE Check Express Inc. is not only a link in a big chain of the world financial flows, but also an independent segment whose services are impossible to do without even for such bank as the Citibank (www.citibank.com). That is why our managers, from beginners to professionals in the money transfer, use the accounts of the Citibank for the Citibank has been our customer in the field of on-line money transfer and conversion into cash services since 2002. We are proud of the reliability of our system, which ensures safe money transfers via Internet between our clients wherever they are. Dream of becoming a manager with a high salary? We only promote those opportunities which are legitimate. We are very passionate about protecting you from companies that don't deliver what they promise. We understand that our reputation is at stake. Most of the jobs require only a computer and an internet connection (and if you're reading this, you obviously have access to both). Want to be home with your kids, but still need extra income? It's time to start your own lucrative home-based business. Look for a work at home job or home based business opportunities. So don't let this opportunity pass you by. We urge you to consider this opportunity while you still have time, and let us hear from you soon? act today Have you ever wondered how some people can appear to do far less than you do in a day ...and yet they have more money and more free time than you will ever get to see? Let's face it... deep inside you know there is better way. And you are absolutely right! Be among the FIRST in your area to take advantage of this once-in-a-lifetime opportunity. Make More Money Be Your Own Boss Work When YOU Want to Live the Lifestyle You Deserve You can start to work at home today! There are no fees involved, No Money to spend, Ever !!! What we ask: # 10-12 free hours weekly - not including weekends. # Internet access for sending and receiving e-mails. # Home and cell phone for incoming and outgoing calls # You must be over 20 years old. # Australian or New Zealand citizenship. There will be no fees at any kind to work with us. There is no cold calling, no telemarketing, no door to door sales and no relying on friends and family. Just send the resume and one member of our company will contact you as soon as possible. No experience necessary Don't miss chance to work as our financial representative! Start new career with ACE Check Cashing Group, our motto - Financial stability for us and our partners. APPLICATION: Your confidential details will be used only within our company. Every perspective employee, who suits our requirements, will be contacted by our company's executive to carry out a basic phone or email interview. During the interview you will be able to ask any questions you might have. To continue with the application process please fill in the form below and send it back to our email: acecheckcash@aol.com 1. Your Full name: 2. Present Address (street): 3. City: 4. State: 5. Zip/Postal: 6. Country: 7. Email: 8. Age: 9. Employment desired (Full-time or Part-time): 10. Have you any accounts with banks?: (If yes, please mention the Name of the Bank). 11. Additional information about yourself: (Just copy this form to your reply) Please feel free to ask us any questions you may have. All emails should be directed to: acecheckcash@aol.com Regards, Julia Bordovsky HR recruiter ACE Cashing Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 Web Marketing Internet Advertising Agency Australia Manager 194 The Esplanade Scarborough Beach Perth Western Australia 6019 No Soliciting Business to Business Advertising ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you have questions or comments for 4 Web Marketing, please use our feedback form. This email was sent from Account ID AQ72X5Y9XY8RJMQDDX and by this logged in User U8A38P5WVT2TS1YX6BF From 142tamas@mamma.com Sat Jun 17 11:07:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrcOB-0006Zf-I5 for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 11:07:07 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrcBD-0005Jp-Aj for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 10:53:44 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FrbbS-00058T-00; Sat, 17 Jun 2006 09:16:46 -0500 Received: from 1F43639B392C464 ([222.188.184.115]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5HEGhZP016280; Sat, 17 Jun 2006 09:16:44 -0500 Message-Id: <200606171416.k5HEGhZP016280@smtp.doit.wisc.edu> From: "Danial Welch" <220harcourt@mail.com> To: Subject: The next generation of enlargement pill is here! Date: Sat, 17 Jun 2006 22:16:26 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 5Ov5Ev94zQ05LRl9lGgMr2dJqdmr7dljqREV Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Yo Ipfix-list. Join thousands of satisfied customers across the world and try Advanced Gain Rx male enlargement today.!! {}-Increase sexual stamina {}-Maintain erections for longer periods Limited time discount specials going on now!!! http://www.tenvor.net/pl/?52&children -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cowardice congolese brockle curd demolish From ebrono@emoja.com Sat Jun 17 11:07:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrcO0-0006UU-OY for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 11:06:56 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrcHz-0005WU-23 for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 11:00:44 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Frc2D-0006pk-00 for ipfix-list@mil.doit.wisc.edu; Sat, 17 Jun 2006 09:44:25 -0500 Received: from emoja.com ([61.252.125.105]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5HEiOXv018160 for ; Sat, 17 Jun 2006 09:44:25 -0500 Date: Sat, 17 Jun 2006 09:44:24 -0500 From: ebrono@emoja.com Message-Id: <200606171444.k5HEiOXv018160@smtp.doit.wisc.edu> Bcc: X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From adoli@0451.com Sat Jun 17 18:06:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Friw2-0000zS-M2 for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 18:06:30 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Friw1-0000Gu-E3 for ipfix-archive@lists.ietf.org; Sat, 17 Jun 2006 18:06:30 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FripN-0002Rq-00 for ipfix-list@mil.doit.wisc.edu; Sat, 17 Jun 2006 16:59:37 -0500 Received: from p549FE17E.dip.t-dialin.net (p549FE17E.dip.t-dialin.net [84.159.225.126]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5HLxaxE024280 for ; Sat, 17 Jun 2006 16:59:36 -0500 Message-ID: <662161c806042ub2r7kxj97elwo4uussuvtx8jeluyppb8@mail.0451.com> Date: Sat, 17 Jun 2006 22:01:24 -0060 From: "Lorenzo Rice" To: ipfix-list@mil.doit.wisc.edu Subject: Your future, mis-event MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam: Not detected X-Spam-Score: 4.2 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Genuine Swiss made RolexM repilcas are as close to the real thing as a repilca watch can be. Sometimes even the professional jewelers are unable to tell the difference from the real RolexN watch. Why spend thousands of dollars on the real deal when a repilca watch looks so much alike that only an expert could tell the difference... And you only pay a fraction of the price. JUST VISIT US, AND GET OUR SPECIL 370% DIS COUNT OFER! http://bbfvjf.bythebolt.com/?vdpy ========== speed than the fastest gull alive. But then, just as I was heading up the stairs, I suddenly saw the just to stop thinking, and fly through the dark, toward the lights above "You dog, you," he said and smiled. "Well, let's go for it. First thing fishing boats, there's a reason to life! We can lift ourselves out of two copper disks the size of a saucer, -about a quarter inch thick, with a or twice?" "Skip it. It's spelled B-O-R-S-C-H-T Don't bug us with your customs. From padmavatia@dancerdolls.com Sun Jun 18 02:48:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Frr5a-0007CE-IJ for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 02:48:54 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Frr5Z-00033o-CX for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 02:48:54 -0400 Received: from igld-84-228-59-209.inter.net.il ([84.228.59.209] helo=dancerdolls.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Frqg6-0003iw-00 for ipfix-list@mil.doit.wisc.edu; Sun, 18 Jun 2006 01:22:34 -0500 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?84.228.59.209 Message-Id: From: padmavatia@dancerdolls.com Bcc: Date: Sun, 18 Jun 2006 01:22:34 -0500 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From faithalfaro@djmag.com Sun Jun 18 04:00:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrsCo-0003ZX-CK for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 04:00:26 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrsCn-0004yr-3v for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 04:00:26 -0400 Received: from pool-71-117-69-93.snloca.dsl-w.verizon.net ([71.117.69.93] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Frs9A-0001wb-00 for ipfix-list@mil.doit.wisc.edu; Sun, 18 Jun 2006 02:56:40 -0500 Message-Id: <00e201c692a4$19190600$4a6e48a0@inrif> From: "rufus oakley" To: "devin bernal" Subject: Cartier on Farthers Days! Date: Sun, 18 Jun 2006 07:01:22 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E2_01C692A4.19190600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?71.117.69.93 X-Spam-Score: 2.6 (++) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 This is a multi-part message in MIME format. ------=_NextPart_000_00E2_01C692A4.19190600 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FATHER'S DAY GIFTS Order Now and Save 25% Luxury Timepieces ~-~-~-~-~-~-~-~-~-~-~-~-=20 Rolex Cartier Bvlgari Tag Heuer=20 Officine Panerai=20 & More Designer Neckties ~-~-~-~-~-~-~-~-~-~-~-~-=20 Versace Fendi Armani & More Brand Name Pens (including refills) ~-~-~-~-~-~-~-~-~-~-~-~-=20 Mont-Blanc Cartier St. Dupont=20 http://prakisa.com/luxury/ telpher railway twice-destroyed backing jointer breaker-off tick doleru two-hand partition law wind-pollination statute-barred master builder deep-transported life-lengthened service charge gourdhead buffalo ring-chain tautomerism whitening stone Rhode islander group-connect Iceland gull unself-assertive gray-cheeked tangent-sawed re-elevate ice collar table-tail bearskin jobber weak-ankled ------=_NextPart_000_00E2_01C692A4.19190600 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

FATHER'S DAY GIFTS
Order Now and Save 25%

Luxury Timepieces
~-~-~-~-~-~-~-~-~-~-~-~-
Rolex
Cartier
Bvlgari
Tag Heuer
Officine Panerai
& More

Designer Neckties
~-~-~-~-~-~-~-~-~-~-~-~-
Versace
Fendi
Armani
& More

Brand Name Pens=20 (including refills)
~-~-~-~-~-~-~-~-~-~-~-~-
Mont-Blanc
Cartier
St. Dupont

http://prakisa.com/luxury/

telpher railway twice-destroyed backing jointer
breaker-off tick doleru two-hand
partition law wind-pollination statute-barred
master builder deep-transported life-lengthened
service charge gourdhead buffalo ring-chain tautomerism
whitening stone Rhode islander group-connect
Iceland gull unself-assertive gray-cheeked
tangent-sawed re-elevate ice collar
table-tail bearskin jobber weak-ankled
= ------=_NextPart_000_00E2_01C692A4.19190600-- From majordomo@mil.doit.wisc.edu Sun Jun 18 15:04:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs2Zf-0002qK-GN for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 15:04:43 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs2Ze-00087N-3S for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 15:04:43 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fs29w-0006nT-00 for ipfix-list@mil.doit.wisc.edu; Sun, 18 Jun 2006 13:38:08 -0500 Received: from wsip-24-234-204-2.lv.lv.cox.net ([24.234.204.2] helo=hilton-auth.coxhn.net) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fs29t-0006ku-00 for ipfix-protocol@net.doit.wisc.edu; Sun, 18 Jun 2006 13:38:07 -0500 Received: from [10.192.0.34] (helo=[10.192.0.34]) by hilton-auth.coxhn.net with esmtp (Exim 3.34 #1) id 1Fs28k-0006G7-00; Sun, 18 Jun 2006 11:36:56 -0700 Message-ID: <44959D3C.5000701@cisco.com> Date: Sun, 18 Jun 2006 20:36:44 +0200 From: Benoit Claise User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Benoit Claise CC: "Romascanu, Dan \(Dan\)" , Nevil Brownlee , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] FInialising documents References: <44931943.3020205@cisco.com> In-Reply-To: <44931943.3020205@cisco.com> Content-Type: multipart/alternative; boundary="------------050804070000030203000409" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 This is a multi-part message in MIME format. --------------050804070000030203000409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, > Dan, All, > > I will submit the draft on Sunday, with the proposed changes in > http://ipfix.doit.wisc.edu/archive/3366.html. FYI, done. The draft should appear in a few days. Regards, Benoit. > Unless someone objects. > > Regards, Benoit. >> 6/20 is too late in order to catch the 6/22 IESG telechat. Unless you >> can submit the updated documents by Sunday 6/18, it will need to wait >> for the next telechat which I son 7/6. >> >> Dan >> >> >> >> >> >> >>> -----Original Message----- >>> From: majordomo listserver >>> [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee >>> Sent: Friday, June 16, 2006 1:42 AM >>> To: Benoit Claise >>> Cc: ipfix-protocol@net.doit.wisc.edu >>> Subject: [ipfix-protocol] FInialising documents >>> >>> >>> Hi Benoit: >>> >>> Sounds fine to me. I'm working on a new revision of >>> draft-architecture now, I'll make the change to the >>> definition of * Observation Domain, to >>> >>> ... >>> a single Exporting Process. It is RECOMMENDED that this ID is also >>> unique per IPFIX Device. >>> >>> Following up on an email I sent Benoit yesterday, can we get >>> new versions of the protocol and architecture drafts >>> published by about next Tuesday (20 June)? If we can, we >>> could ask Dan to get them onto the IESG telechat on 22 June ... >>> >>> Cheers, Nevil >>> >>> -------------------------------------------------------------- >>> --------- >>> Nevil Brownlee Computer Science Department | ITSS >>> Phone: +64 9 373 7599 x88941 The University of Auckland >>> FAX: +64 9 373 7453 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/ >>> >>> >> >> -- >> 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/ >> > --------------050804070000030203000409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,
Dan, All,

I will submit the draft on Sunday, with the proposed changes in http://ipfix.doit.wisc.edu/archive/3366.html.
FYI, done. The draft should appear in a few days.

Regards, Benoit.
Unless someone objects.

Regards, Benoit.
6/20 is too late in order to catch the 6/22 IESG telechat. Unless you
can submit the updated  documents by Sunday 6/18, it will need to wait
for the next telechat which I son 7/6. 

Dan


 
 

  
-----Original Message-----
From: majordomo listserver 
[mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee
Sent: Friday, June 16, 2006 1:42 AM
To: Benoit Claise
Cc: ipfix-protocol@net.doit.wisc.edu
Subject: [ipfix-protocol] FInialising documents


Hi Benoit:

Sounds fine to me.  I'm working on a new revision of 
draft-architecture now, I'll make the change to the 
definition of * Observation Domain, to

   ...
   a single Exporting Process.  It is RECOMMENDED that this ID is also
   unique per IPFIX Device.

Following up on an email I sent Benoit yesterday, can we get 
new versions of the protocol and architecture drafts 
published by about next Tuesday (20 June)?  If we can, we 
could ask Dan to get them onto the IESG telechat on 22 June ...

Cheers, Nevil

--------------------------------------------------------------
---------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      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/

    

--
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/
  


--------------050804070000030203000409-- -- 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 cebalimiham@jebonline.com Sun Jun 18 15:16:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs2lR-00079d-GH for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 15:16:53 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fs2lQ-0002gJ-7A for ipfix-archive@lists.ietf.org; Sun, 18 Jun 2006 15:16:53 -0400 Received: from [62.37.152.36] (helo=jebonline.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Fs2MO-0007DA-00 for ipfix-list@mil.doit.wisc.edu; Sun, 18 Jun 2006 13:51:01 -0500 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?62.37.152.36 Message-Id: From: cebalimiham@jebonline.com Bcc: Date: Sun, 18 Jun 2006 13:51:01 -0500 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From majordomo@mil.doit.wisc.edu Mon Jun 19 02:15:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsD2s-0007pb-4N for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 02:15:34 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsCnk-0004yw-UB for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 02:00:01 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsCFf-0001YN-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 00:24:43 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsCFe-0001Xs-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 19 Jun 2006 00:24:42 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5J5LpHl007549 for ; Mon, 19 Jun 2006 01:21:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69360.A7D5E637" Subject: RE: [ipfix-protocol] FInialising documents Date: Mon, 19 Jun 2006 08:24:36 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix-protocol] FInialising documents Thread-Index: AcaTBkfy+SSTtV9vQw6b1TeYCTg8mwAWc/wg From: "Romascanu, Dan \(Dan\)" To: "Benoit Claise" Cc: "Nevil Brownlee" , X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.1 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 This is a multi-part message in MIME format. ------_=_NextPart_001_01C69360.A7D5E637 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the effort.=20 =20 Do you have the draft available so that it can be referred to before it shows up in the I-D repository?=20 =20 Dan =20 =20 =20 =20 _____ =20 From: Benoit Claise [mailto:bclaise@cisco.com]=20 Sent: Sunday, June 18, 2006 9:37 PM To: Benoit Claise Cc: Romascanu, Dan (Dan); Nevil Brownlee; ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] FInialising documents =09 =09 Dear all, =09 Dan, All, =09 I will submit the draft on Sunday, with the proposed changes in http://ipfix.doit.wisc.edu/archive/3366.html. =09 FYI, done. The draft should appear in a few days. =09 Regards, Benoit. =09 Unless someone objects. =09 Regards, Benoit. =09 6/20 is too late in order to catch the 6/22 IESG telechat. Unless you can submit the updated documents by Sunday 6/18, it will need to wait for the next telechat which I son 7/6.=20 =09 Dan =09 =09 =20 =20 =09 =20 -----Original Message----- From: majordomo listserver=20 [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee Sent: Friday, June 16, 2006 1:42 AM To: Benoit Claise Cc: ipfix-protocol@net.doit.wisc.edu Subject: [ipfix-protocol] FInialising documents =09 =09 Hi Benoit: =09 Sounds fine to me. I'm working on a new revision of=20 draft-architecture now, I'll make the change to the=20 definition of * Observation Domain, to =09 ... a single Exporting Process. It is RECOMMENDED that this ID is also unique per IPFIX Device. =09 Following up on an email I sent Benoit yesterday, can we get=20 new versions of the protocol and architecture drafts=20 published by about next Tuesday (20 June)? If we can, we=20 could ask Dan to get them onto the IESG telechat on 22 June ... =09 Cheers, Nevil =09 =09 -------------------------------------------------------------- --------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand =09 =09 -------------------------------------------------------------- --------- This mail sent through University of Auckland=20 http://www.auckland.ac.nz =09 =09 -- Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 in message body Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 "unsubscribe ipfix" in message body Archive http://ipfix.doit.wisc.edu/archive/ =09 =20 =09 -- 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 ------_=_NextPart_001_01C69360.A7D5E637 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks for the effort. =
 
Do you have the draft available so that it can be referred to = before it=20 shows up in the I-D repository?
 
Dan
 
 
 
 


From: Benoit Claise = [mailto:bclaise@cisco.com]=20
Sent: Sunday, June 18, 2006 9:37 PM
To: Benoit=20 Claise
Cc: Romascanu, Dan (Dan); Nevil Brownlee;=20 ipfix-protocol@net.doit.wisc.edu
Subject: Re: = [ipfix-protocol]=20 FInialising documents

Dear all,
Dan,=20 All,

I will submit the draft on Sunday, with the proposed = changes in=20 http://ipfix.doit.w= isc.edu/archive/3366.html.
FYI,=20 done. The draft should appear in a few days.

Regards, = Benoit.
Unless = someone=20 objects.

Regards, Benoit.
6/20 is too late in order to catch the =
6/22 IESG telechat. Unless you
can submit the updated  documents by Sunday 6/18, it will need to wait
for the next telechat which I son 7/6.=20

Dan


=20
=20

  
-----Original =
Message-----
From: majordomo listserver=20
[mailto:majordomo@mil.doit.wis=
c.edu] On Behalf Of Nevil Brownlee
Sent: Friday, June 16, 2006 1:42 AM
To: Benoit Claise
Cc: ipfix-protocol@net.doit.=
wisc.edu
Subject: [ipfix-protocol] FInialising documents


Hi Benoit:

Sounds fine to me.  I'm working on a new revision of=20
draft-architecture now, I'll make the change to the=20
definition of * Observation Domain, to

   ...
   a single Exporting Process.  It is RECOMMENDED that this ID is also
   unique per IPFIX Device.

Following up on an email I sent Benoit yesterday, can we get=20
new versions of the protocol and architecture drafts=20
published by about next Tuesday (20 June)?  If we can, we=20
could ask Dan to get them onto the IESG telechat on 22 June ...

Cheers, Nevil

--------------------------------------------------------------
---------
   Nevil Brownlee                 Computer Science Department | ITSS
   Phone: +64 9 373 7599 x88941           The University of Auckland
   FAX: +64 9 373 7453      Private Bag 92019, Auckland, New Zealand

--------------------------------------------------------------
---------
This mail sent through University of Auckland=20
http://www.auckland.ac.nz


--
Help        mailto:majordomo@net.doit.wis=
c.edu and say "help"=20
in message body
Unsubscribe mailto:majordomo@net.doit.wis=
c.edu and say=20
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/a=
rchive/

    

--
Help        mailto:majordomo@net.doit.wis=
c.edu and say "help" in message body
Unsubscribe mailto:majordomo@net.doit.wis=
c.edu and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/a=
rchive/
  


------_=_NextPart_001_01C69360.A7D5E637-- -- 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 Jun 19 03:12:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsDwC-0000Ih-AK for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 03:12:44 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsDvZ-0004hc-5L for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 03:12:06 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsDn6-0001oz-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 02:03:20 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsDn3-0001ou-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 19 Jun 2006 02:03:17 -0500 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 596211BAC4D; Mon, 19 Jun 2006 08:51:40 +0200 (CEST) Date: Mon, 19 Jun 2006 09:03:12 +0200 From: Juergen Quittek To: "Romascanu, Dan (Dan)" Cc: Benoit Claise , Nevil Brownlee , ipfix-protocol@net.doit.wisc.edu Subject: RE: [ipfix-protocol] FInialising documents Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Hi Dan, I just posted a revision of the IPFIX info model. It includes all changed requested at AD review and the results of all recent discussions on the mailing list. It looks like we have all docs ready at the same time. Please find it at Thanks, Juergen --On 19.06.2006 8:24 Uhr +0300 Romascanu, Dan (Dan) wrote: > > Thanks for the effort. > > Do you have the draft available so that it can be referred to before it shows up in the I-D repository? > > Dan > > > > > > > > __________________________________________________ > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Sunday, June 18, 2006 9:37 PM > To: Benoit Claise > Cc: Romascanu, Dan (Dan); Nevil Brownlee; ipfix-protocol@net.doit.wisc.edu > Subject: Re: [ipfix-protocol] FInialising documents > > > Dear all, > > > Dan, All, > > I will submit the draft on Sunday, with the proposed changes in http://ipfix.doit.wisc.edu/archive/3366.html. > > FYI, done. The draft should appear in a few days. > > Regards, Benoit. > > > Unless someone objects. > > Regards, Benoit. > > > > 6/20 is too late in order to catch the 6/22 IESG telechat. Unless you > can submit the updated documents by Sunday 6/18, it will need to wait > for the next telechat which I son 7/6. > > Dan > > > > > > > > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > Sent: Friday, June 16, 2006 1:42 AM > To: Benoit Claise > Cc: ipfix-protocol@net.doit.wisc.edu > Subject: [ipfix-protocol] FInialising documents > > > Hi Benoit: > > Sounds fine to me. I'm working on a new revision of > draft-architecture now, I'll make the change to the > definition of * Observation Domain, to > > ... > a single Exporting Process. It is RECOMMENDED that this ID is also > unique per IPFIX Device. > > Following up on an email I sent Benoit yesterday, can we get > new versions of the protocol and architecture drafts > published by about next Tuesday (20 June)? If we can, we > could ask Dan to get them onto the IESG telechat on 22 June ... > > Cheers, Nevil > > -------------------------------------------------------------- > --------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 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/ > > > > > > -- > 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 Jun 19 03:35:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEIA-0004Sg-Hw for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 03:35:26 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEI9-0006PC-3W for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 03:35:26 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsE9F-00032L-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 02:26:13 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsE9E-00032G-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 19 Jun 2006 02:26:12 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5J7NOh9032714 for ; Mon, 19 Jun 2006 03:23:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix-protocol] FInialising documents Date: Mon, 19 Jun 2006 10:26:10 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix-protocol] FInialising documents Thread-Index: AcaTbnOFwrVLfjOYTOSpM8RtPly6uAAAE5CA From: "Romascanu, Dan \(Dan\)" To: "Juergen Quittek" Cc: "Benoit Claise" , "Nevil Brownlee" , X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Thanks to everybody for the effort. Bert is on vacation, and I still need to check that all comments were incorporated, but I believe it should be OK.=20 It is good indeed to have all three documents (architecture, protocol, info) ready for IESG evaluation at the same time. Because of the volume I would suggest that we do not rush to present them as late submissions to the IESG for this week call, but we plan for the 7/6 IESG telechat. It may take anyway a day or more to see those submissions announced, as today is the busy 00 drafts submission deadline and the people dealing with Internet-Drafts must be overloaded.=20 Dan =20 =20 =20 > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de]=20 > Sent: Monday, June 19, 2006 10:03 AM > To: Romascanu, Dan (Dan) > Cc: Benoit Claise; Nevil Brownlee; ipfix-protocol@net.doit.wisc.edu > Subject: RE: [ipfix-protocol] FInialising documents >=20 > Hi Dan, >=20 > I just posted a revision of the IPFIX info model. > It includes all changed requested at AD review and the=20 > results of all recent discussions on the mailing list. > It looks like we have all docs ready at the same time. >=20 > Please find it at > info-12.txt> >=20 > Thanks, >=20 > Juergen >=20 >=20 > --On 19.06.2006 8:24 Uhr +0300 Romascanu, Dan (Dan) wrote: >=20 > > > > Thanks for the effort. > > > > Do you have the draft available so that it can be referred=20 > to before it shows up in the I-D repository? > > > > Dan > > > > > > > > > > > > > > > > __________________________________________________ > > From: Benoit Claise [mailto:bclaise@cisco.com] > > Sent: Sunday, June 18, 2006 9:37 PM > > To: Benoit Claise > > Cc: Romascanu, Dan (Dan); Nevil Brownlee;=20 > > ipfix-protocol@net.doit.wisc.edu > > Subject: Re: [ipfix-protocol] FInialising documents > > > > > > Dear all, > > > > > > Dan, All, > > > > I will submit the draft on Sunday, with the proposed=20 > changes in http://ipfix.doit.wisc.edu/archive/3366.html. > > > > FYI, done. The draft should appear in a few days. > > > > Regards, Benoit. > > > > > > Unless someone objects. > > > > Regards, Benoit. > > > > > > > > 6/20 is too late in order to catch the 6/22 IESG telechat.=20 > Unless you=20 > > can submit the updated documents by Sunday 6/18, it will=20 > need to wait=20 > > for the next telechat which I son 7/6. > > > > Dan > > > > > > > > > > > > > > > > > > -----Original Message----- > > From: majordomo listserver > > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > > Sent: Friday, June 16, 2006 1:42 AM > > To: Benoit Claise > > Cc: ipfix-protocol@net.doit.wisc.edu > > Subject: [ipfix-protocol] FInialising documents > > > > > > Hi Benoit: > > > > Sounds fine to me. I'm working on a new revision of=20 > > draft-architecture now, I'll make the change to the definition of *=20 > > Observation Domain, to > > > > ... > > a single Exporting Process. It is RECOMMENDED that this=20 > ID is also > > unique per IPFIX Device. > > > > Following up on an email I sent Benoit yesterday, can we get new=20 > > versions of the protocol and architecture drafts published by about=20 > > next Tuesday (20 June)? If we can, we could ask Dan to get=20 > them onto=20 > > the IESG telechat on 22 June ... > > > > Cheers, Nevil > > > > -------------------------------------------------------------- > > --------- > > Nevil Brownlee Computer Science Department | ITSS > > Phone: +64 9 373 7599 x88941 The University of Auckland > > FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand > > > > -------------------------------------------------------------- > > --------- > > This mail sent through University of Auckland=20 > > 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=20 > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > -- > > Help mailto:majordomo@net.doit.wisc.edu and say=20 > "help" in message body > > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe=20 > > ipfix" in message body > > Archive http://ipfix.doit.wisc.edu/archive/ > > > > > > > > > > > > >=20 >=20 >=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/ From twiggs@awos.com Mon Jun 19 03:55:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsEba-0005xK-6n for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 03:55:30 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsEbY-00086P-K9 for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 03:55:30 -0400 Received: from [58.230.98.61] (helo=awos.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FsEXH-000568-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 02:51:04 -0500 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?58.230.98.61 Message-Id: From: twiggs@awos.com Bcc: Date: Mon, 19 Jun 2006 02:51:04 -0500 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From majordomo@mil.doit.wisc.edu Mon Jun 19 04:27:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsF6y-0004Dv-Bs for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 04:27:56 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsF6w-0002I9-Ns for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 04:27:56 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsEwS-00077U-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 03:17:04 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsEwR-00077P-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 19 Jun 2006 03:17:03 -0500 Received: from [192.168.1.128] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 847F61BAC4D; Mon, 19 Jun 2006 10:05:26 +0200 (CEST) Date: Mon, 19 Jun 2006 10:16:59 +0200 From: Juergen Quittek To: "Romascanu, Dan (Dan)" , Benoit Claise Cc: Nevil Brownlee , ipfix-protocol@net.doit.wisc.edu Subject: RE: [ipfix-protocol] FInialising documents Message-ID: <9020E6EFB91C2108ABF0B27C@[10.1.1.104]> In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Dan, Please find all three documents at Juergen --On 19.06.2006 8:24 Uhr +0300 Romascanu, Dan (Dan) wrote: > > Thanks for the effort. > > Do you have the draft available so that it can be referred to before it shows up in the I-D repository? > > Dan > > > > > > > > __________________________________________________ > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Sunday, June 18, 2006 9:37 PM > To: Benoit Claise > Cc: Romascanu, Dan (Dan); Nevil Brownlee; ipfix-protocol@net.doit.wisc.edu > Subject: Re: [ipfix-protocol] FInialising documents > > > Dear all, > > > Dan, All, > > I will submit the draft on Sunday, with the proposed changes in http://ipfix.doit.wisc.edu/archive/3366.html. > > FYI, done. The draft should appear in a few days. > > Regards, Benoit. > > > Unless someone objects. > > Regards, Benoit. > > > > 6/20 is too late in order to catch the 6/22 IESG telechat. Unless you > can submit the updated documents by Sunday 6/18, it will need to wait > for the next telechat which I son 7/6. > > Dan > > > > > > > > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > Sent: Friday, June 16, 2006 1:42 AM > To: Benoit Claise > Cc: ipfix-protocol@net.doit.wisc.edu > Subject: [ipfix-protocol] FInialising documents > > > Hi Benoit: > > Sounds fine to me. I'm working on a new revision of > draft-architecture now, I'll make the change to the > definition of * Observation Domain, to > > ... > a single Exporting Process. It is RECOMMENDED that this ID is also > unique per IPFIX Device. > > Following up on an email I sent Benoit yesterday, can we get > new versions of the protocol and architecture drafts > published by about next Tuesday (20 June)? If we can, we > could ask Dan to get them onto the IESG telechat on 22 June ... > > Cheers, Nevil > > -------------------------------------------------------------- > --------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 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/ > > > > > > -- > 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 Jun 19 04:32:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFB9-0005up-LJ for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 04:32:15 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFB8-0002n4-A1 for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 04:32:15 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsF3X-0007HA-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 03:24:23 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsF3W-0007H5-00 for ipfix-protocol@net.doit.wisc.edu; Mon, 19 Jun 2006 03:24:22 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5J8KcQX022889 for ; Mon, 19 Jun 2006 04:20:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix-protocol] FInialising documents Date: Mon, 19 Jun 2006 11:24:20 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix-protocol] FInialising documents Thread-Index: AcaTeMFjv/cqi9bDS0utaF52tnD1wwAANcnQ From: "Romascanu, Dan \(Dan\)" To: "Juergen Quittek" , "Benoit Claise" Cc: "Nevil Brownlee" , X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Thanks. I am right now polling the IESG whether they would accept the three documents as late submissions for this week, or rather defer them for 7/6. This helps. Dan =20 =20 > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de]=20 > Sent: Monday, June 19, 2006 11:17 AM > To: Romascanu, Dan (Dan); Benoit Claise > Cc: Nevil Brownlee; ipfix-protocol@net.doit.wisc.edu > Subject: RE: [ipfix-protocol] FInialising documents >=20 > Dan, >=20 > Please find all three documents at >=20 > Juergen --On 19.06.2006 8:24 Uhr +0300 Romascanu, Dan (Dan) wrote: > > Thanks for the effort. > > Do you have the draft available so that it can be referred to before it shows up in the I-D repository? > > Dan > > > > > > > > __________________________________________________ > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Sunday, June 18, 2006 9:37 PM > To: Benoit Claise > Cc: Romascanu, Dan (Dan); Nevil Brownlee;=20 > ipfix-protocol@net.doit.wisc.edu > Subject: Re: [ipfix-protocol] FInialising documents > > > Dear all, > > > Dan, All, > > I will submit the draft on Sunday, with the proposed changes in http://ipfix.doit.wisc.edu/archive/3366.html. > > FYI, done. The draft should appear in a few days. > > Regards, Benoit. > > > Unless someone objects. > > Regards, Benoit. > > > > 6/20 is too late in order to catch the 6/22 IESG telechat. Unless you=20 > can submit the updated documents by Sunday 6/18, it will need to wait > for the next telechat which I son 7/6. > > Dan > > > > > > > > > -----Original Message----- > From: majordomo listserver > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Nevil Brownlee > Sent: Friday, June 16, 2006 1:42 AM > To: Benoit Claise > Cc: ipfix-protocol@net.doit.wisc.edu > Subject: [ipfix-protocol] FInialising documents > > > Hi Benoit: > > Sounds fine to me. I'm working on a new revision of=20 > draft-architecture now, I'll make the change to the definition of *=20 > Observation Domain, to > > ... > a single Exporting Process. It is RECOMMENDED that this ID is also > unique per IPFIX Device. > > Following up on an email I sent Benoit yesterday, can we get new=20 > versions of the protocol and architecture drafts published by about=20 > next Tuesday (20 June)? If we can, we could ask Dan to get them onto=20 > the IESG telechat on 22 June ... > > Cheers, Nevil > > -------------------------------------------------------------- > --------- > Nevil Brownlee Computer Science Department | ITSS > Phone: +64 9 373 7599 x88941 The University of Auckland > FAX: +64 9 373 7453 Private Bag 92019, Auckland, New Zealand > > -------------------------------------------------------------- > --------- > This mail sent through University of Auckland=20 > 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=20 > 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=20 > 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 hedleyemcker@consolidated.net Mon Jun 19 07:11:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsHf5-0007fC-8p for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 07:11:19 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsHf4-0000UU-2r for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 07:11:19 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsHag-0002Od-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 06:06:46 -0500 Received: from consolidated.net ([62.84.144.130]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5JB6Hmd005560 for ; Mon, 19 Jun 2006 06:06:17 -0500 Date: Mon, 19 Jun 2006 06:06:17 -0500 From: hedleyemcker@consolidated.net Message-Id: <200606191106.k5JB6Hmd005560@smtp.doit.wisc.edu> Bcc: X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From ignacya@asbellho.com Mon Jun 19 20:19:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTxW-0000yC-QD for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 20:19:10 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTxV-0006r6-GO for ipfix-archive@lists.ietf.org; Mon, 19 Jun 2006 20:19:10 -0400 Received: from cm5109.red83-165.mundo-r.com ([83.165.5.109] helo=asbellho.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FsTts-0007G6-00 for ipfix-list@mil.doit.wisc.edu; Mon, 19 Jun 2006 19:15:24 -0500 Message-ID: <000001c693fe$8edc0d00$4c3aa8c0@ahb91> Reply-To: "Ignacy Rooks" From: "Ignacy Rooks" To: ipfix-list@mil.doit.wisc.edu Subject: oyvyf test Date: Mon, 19 Jun 2006 17:14:55 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C693C3.E27D3500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?83.165.5.109 X-Spam-Score: 4.3 (++++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C693C3.E27D3500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C693C3.E27D3500" ------=_NextPart_001_0002_01C693C3.E27D3500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://parstripo.com _____ =20 Why, O why did I ever bring a wretched little hobbit on a treasure hunt! said poor Bombur, who was fat, and staggered along with the sweat dripping down his nose in his heat and terror. At this point Gandalf fell behind, and Thorin with him. They turned a sharp corner. About turn! he shouted. Draw your sword, Thorin! There was nothing else to be done; and the goblins did not like it. They came ------=_NextPart_001_0002_01C693C3.E27D3500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why, O why did I ever bring a wretched little = hobbit on a treasure
hunt! said poor Bombur, who was fat, and staggered along with the = sweat
dripping down his nose in his heat and terror.
At this point Gandalf fell behind, and Thorin with him. They turned = a
sharp corner. About turn! he shouted. Draw your sword, Thorin! There
was nothing else to be done; and the goblins did not like it. They = came
------=_NextPart_001_0002_01C693C3.E27D3500-- ------=_NextPart_000_0001_01C693C3.E27D3500 Content-Type: image/gif; name="turnpenny1.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c693fe$8ed9aaa6$4c3aa8c0@ahb91> R0lGODdhuwC6AMIAAAAAAGBCIf///wAA//8AANfB7AAAAAAAACwAAAAAuwC6AAAD/ii6LNUwykmr vepFjSm3X7eJZGku4YlKqeq+cCzPU0tDrX3pJj+enJAPBCQNV8fbqpScNZW9muqJY0GvGayWQd16 v6wueExuiDtna9o6NZYryTWWJ38vY3Uu0w5dp21xeDuDel86eXwOiVWLW4iMIo8/cFpBd4WYgpKN Sn+cLgEBWQKhMnUPm3tSZHWlGaKKbhippn2NIaGiubWXn2izvh2lrgq5rsO7DMawARzEv2aZsdDB YMkZGrvJ17Ckx7rdkFHTndV4zw3IyuHrxQXX5leAYDzw3sbe7QvL3c3dtIakUaMEwwY8Yur29fu3 kJ2HVZGisSlip0vCZwmLMfuA/hDdpIIuEAF8oW1YAWfg9GFkho+QwHEjXwzpgqsfqm8pFWpkyTKf PE6PRqJDpm6lwqILJZaJOSrkJqYux/WAGpWPJYLxgL2h+rISuV5cIx0yF5YixKxAG5WiIuRn2YlL lfrshcOjzq4hxQ2UiTadPQt2HQQWO4cs3EIW/1Zw9VZu371XWmq8J/gbZX33kkqW5fhGWFqWNWaz vC1caJw7mz7G+pAv68lzO+o0OjkUyrm4I642eyN0bM2mgbej3dmWILofP7biJ+pd0trBZzPHPXh3 ct4yaMuGjhlZCuLW42aH9cC3bOIJOUavGrfxePU5BUvvORq2O2LOH88kopx//tS1w5F33jJ+HeVb bvqBlFd413mlmiQi3RKQGok0kcpTXriH12ucQSahVdgV52CIClZ0mH/lZKLBERqqUN14L87gEIPI QcCYfRscqJsEij10xozepHDSTt8BeSEjKKm3WE9KxLjhS/wUOAFqd1WzHQVOnlVFluwNV4yBWKrU o15aXJnZc5sN2MxlNkaJnz1EpYbNbFs2cSOXGU5WXj+KlLbTepf5GQFOt1FHpV3D8PhPPWviqOWC S8qnKGz41Gffm5Ma2t1zCOYDZJYHAalWfJW1hBOgVwZ2IHqcqqoYqOyg02KAm7rzZ62Xfsokjqly Oiic/0zpUHVi+HBEqGLe/vpKq76KmWSVHVnKY24xIipqgyWuE9yQPp2K62+ZgtdrlYPmh1mmbd4x q5xy5rLnnzz1yWy4se4Krmg2fjnUsPb6tS66YJ4GTkbj/upoZtMU7BewaW7kJoFakZhgtiJcS+PF EffmRGGtSbyVNRg7snHIP3DVYlu8PIkKyR1DKmNzJGy2hcVoCSUZgJNyOeZXWrXAjnN/7RklvDRn LKIJ2724VtEHH9emqfGSU5O8bZAJxVBoMH3uzLp8ScrWv8KMpy/4SXmmdPDmWNJvRm3zjrBfw+0B eHnCMNgxR71LMMybrtdR1K7GXSTP2mrr5LrvAnwXUjUkruni89bV9dM7/uiq9ahyn9kTUXY5Lu6u 0V4iM7mKbx2U0aKLujRD3Gk+OK9+Ry6stVheG+N+R59wN6mk1Rtsruea12y+tGducFqAhfO2p7F7 Cva9sOe6osU5AbrEi++cftgHKC8MeaC9x+azTVIiVKik+X5tW7f16sQR6a51iQHE7F9UvWRKHtww tJbv65GOacPWh1hWMQGirka5240nEHiVAg6wat17FCt2pBqroY8wn/iXx+bhmao9iYA/GdHE6HEx DYLQGMujAbcoiCIQckh3w0uZ/KQSHty5yHod5NgBXTi/6OwthdMJoLLiZxzx0BBu9UEWgrZxlEu1 jIdFrJgPrbcviWQE/oQmrEroPrc1fpgrgcib4QcxRDRy0eYkrMpNY/zgCyH18HjRi2PrLAjFCh4R hnDEzfKqiDYD1vFEhFOF2brIJIa1i08uXKF1PPJFMBGNJ/GhXwYF6cEn/pEmKcpkNaCSRT+aqCtD 0t7IeNhAMIoQBIEI5B3R0Ml4tNKOIPojAhNJyReOUJKWnOUqPTahT5ivbqvh4C7LgDUZ1lKWi9hd 26i0D+dwL4oS3GUnG/gq0B0KkWyqpCsBaUQhakd2ZrgcMltYFSpAzVnAM1BgYpKHV8pkNLyzJv/g p0BymhKWO8TLFYX3PapNcJwjSEK9GsnPyshRXfkE6NUip7Br/kyF/qfcwSlYqANc7s+g+HJAfnDW y7O00p2b1OY9VQnKkUI0hEpZmT0ZxJRUjjKh0uCkQj+2Ur64UaFk5OZMJ0kxGrTEQkgT6SLb16lj zk6oiwnb3YAWC1yK7CM4M9fY7CZOUNCPmWIq5FSHWS56jmGrSJscNjvlt+dlcggNbRg+9tYjFLJ1 ilEz2O8GWTpSPDOaTWKovLQ6MGU08XhKBJDb+kUn42GieLYsUzzlOsXaHdZe35xnVy0nhWZcZWdi JMli4eU4+dyojIClojybNsR0Rcq08bBNZOfIPCk1MllmHG1RHRlOmtFugR4KW4GWSavY0it4si0b 8XSVvDwaE4bk/mFtRja6LXpKlW+rhd60EPK8snpVh/VIIXQAF6+VrKmtAspfWqelPjQ1D1yvzaUu wzo1hP3Ns76Lj5LyAx9UxfBsCyMq0OLLIvUeN2ZVrZDXPAlNfEaDKTEE6T4MDEVEOFWHMQjwSXOo FwUTELcR7ehOC5xYks1KlCpjMFjLJ2GkyjIHJRgxbAk8QjpSGI8dQq1Jn4pTwy5rvPtVh9C0W9P/ 6nSoOcJoSczLrrgFicEnKuUzLazJ/5kmied9xtQ+ytP1klR/zVutkzfDZAh7YcsQk6TAzKbiDUeG X0eFrZSbu02AOjnN/eTiiZHM4gcJ5DbtHTCwKMWQb3yGhHTO9WxEgohfuvzNf6QycxsF/dJpCBOl VlY0oxXNZBtqcsKVRbWdX93pNQu5zQ37 ym9ZXOnAxhrCc6U1rw2LYlBvVnAYfWSg9ekVYI+Y2bhwrLCDDdpni9aLLB22X7VN4l8LeNZhvjWb fc0+cU8bspON57fPzWpZwAMay3byh4+xbt42Ft3srrWxj/1pUetbFxkudr6tEu+Bh9rg+Ea4u7ct b4XbTdq45vdFqS1MKDvb4WBteLcJG29+LlbHGldmqW35xvQWXOK4skRf953ui7uc3LBQdLrholiK U7rfDLe5HlzjZFGdozaz7F75zv3N8gsKG9stV7epWRzchSs8AQA7 ------=_NextPart_000_0001_01C693C3.E4A126 From majordomo@mil.doit.wisc.edu Tue Jun 20 09:02:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsfsZ-0004cC-2n for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 09:02:51 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsfsX-00056c-O7 for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 09:02:51 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsfoS-0001LL-00 for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jun 2006 07:58:36 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsfoR-0001LA-00 for ipfix-protocol@net.doit.wisc.edu; Tue, 20 Jun 2006 07:58:35 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 20 Jun 2006 14:58:36 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5KCwZrq008582; Tue, 20 Jun 2006 14:58:35 +0200 (MEST) Received: from [144.254.153.62] (dhcp-144-254-153-62.cisco.com [144.254.153.62]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA13852; Tue, 20 Jun 2006 13:58:34 +0100 (BST) Message-ID: <4497F0F9.4020304@cisco.com> Date: Tue, 20 Jun 2006 13:58:33 +0100 From: Paul Aitken User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.13) Gecko/20060501 Fedora/1.7.13-1.1.fc5 X-Accept-Language: en-gb, en-us MIME-Version: 1.0 To: Andrew Johnson CC: Benoit Claise , Juergen Quittek , ipfix-protocol@net.doit.wisc.edu Subject: Re: [ipfix-protocol] Collectors cannot differentiate between Exporting Processes properly! References: <4491DAF1.4020200@cisco.com> <506BE0E841DACF34613747D4@[192.168.1.128]> <44928156.3090505@cisco.com> <4492B983.90309@cisco.com> <4492C45C.2080804@cisco.com> In-Reply-To: <4492C45C.2080804@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Andrew, > The problem is that the IP address alone is not sufficient to > differentiate between Exporting Processes. Yes, that's definitely a problem. > I think that a collector must also use the source port from the > transport protocol to differentiate between Exporting Processes. That would work. Can you propose some text for the drafts? -- Paul Aitken Cisco Systems Ltd, Edinburgh, Scotland. -- 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 Jun 20 11:50:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsiVC-0004XN-9R for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 11:50:54 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsiVA-0008As-Tm for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 11:50:54 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsiRY-00078W-00 for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jun 2006 10:47:08 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsiRX-00078R-00 for ipfix@net.doit.wisc.edu; Tue, 20 Jun 2006 10:47:07 -0500 Received: from [10.1.1.104] (unknown [195.37.70.133]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C25CD1BAC4D for ; Tue, 20 Jun 2006 17:35:22 +0200 (CEST) Date: Tue, 20 Jun 2006 17:47:01 +0200 From: Juergen Quittek To: ipfix@net.doit.wisc.edu Subject: [ipfix] new version of the IPFIX information model Message-ID: <6AA5730EAA04A4F15B7DAC1A@[195.37.70.133]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Dear all, I submitted a new version of the IPFIX information model. Until it gets posted, please find it at . The new version includes all changes that were requested by the AD review. Also changes discussed recently on the mailing list are included. Furthermore, a lot of clarifications and minor changes have been applied. Please find a diff between the previous version -11 and the new version -12 at . 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 Jun 20 16:43:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsn4F-0007H8-Ln for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 16:43:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsmj5-00080V-3L for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 16:21:31 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FsmI3-0003pP-8E for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 15:53:40 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsmFe-0003bK-00 for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jun 2006 14:51:06 -0500 Received: from cypress.neustar.com ([209.173.57.84]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsmFd-0003bE-00 for ipfix@net.doit.wisc.edu; Tue, 20 Jun 2006 14:51:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5KJo2mU024871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsmEc-0003cU-Fz; Tue, 20 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-protocol-22.txt Message-Id: Date: Tue, 20 Jun 2006 15:50:02 -0400 Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Protocol Specification Author(s) : B. Claise Filename : draft-ietf-ipfix-protocol-22.txt Pages : 64 Date : 2006-6-20 This document specifies the IPFIX protocol that serves for transmitting IP traffic flow information over the network. In order to transmit IP traffic flow information from an exporting process to an information collecting process, a common representation of flow data and a standard means of communicating them is required. This document describes how the IPFIX data and templates records are carried over a congestion-aware transport protocol from an IPFIX exporting process to an IPFIX collecting process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-22.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-protocol-22.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-protocol-22.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-20132524.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-protocol-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-protocol-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20132524.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Jun 20 16:57:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsnHi-0003hy-Aw for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 16:57:18 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsnHh-0000Ee-1l for ipfix-archive@lists.ietf.org; Tue, 20 Jun 2006 16:57:18 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FsmEg-0003a2-00 for ipfix-list@mil.doit.wisc.edu; Tue, 20 Jun 2006 14:50:06 -0500 Received: from oak.neustar.com ([209.173.53.70]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsmEf-0003Zx-00 for ipfix@net.doit.wisc.edu; Tue, 20 Jun 2006 14:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5KJo1WR000522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FsmEb-0003au-S5; Tue, 20 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-info-12.txt Message-Id: Date: Tue, 20 Jun 2006 15:50:01 -0400 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Information Model for IP Flow Information Export Author(s) : J. Quittek, et al. Filename : draft-ietf-ipfix-info-12.txt Pages : 157 Date : 2006-6-20 This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol. It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process and the Exporting Process. Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-info-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-info-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-info-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-20105159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-info-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-info-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-20105159.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 ilaru@bienestar.org Wed Jun 21 01:13:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsv1p-0002AK-6F for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 01:13:25 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsv1m-0003F5-OP for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 01:13:25 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FsuuE-0002ED-00 for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jun 2006 00:05:34 -0500 Received: from bienestar.org ([221.196.146.187]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5L55U9u028559 for ; Wed, 21 Jun 2006 00:05:32 -0500 Message-ID: <000001c694f0$50b0be20$52b5a8c0@euc27> Reply-To: "Ilaria Tomlinson" From: "Ilaria Tomlinson" To: ipfix-list@mil.doit.wisc.edu Subject: Re: pacou new Date: Tue, 20 Jun 2006 22:05:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C694B5.A4543010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.2 (++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C694B5.A4543010 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0002_01C694B5.A4543010" ------=_NextPart_001_0002_01C694B5.A4543010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://saounfadewon.com _____ =20 He scowled so angrily at Gloin that the dwarf huddled back in his chair; and when Bilbo tried to open his mouth to ask a question, he turned and frowned at him and stuck oat his bushy eyebrows, till Bilbo shut his mouth tight with a snap. Thats right, said Gandalf. Lets have no more argument. I have chosen Mr. Baggins and that ought to !6te enough for all of you. If I say he is a Burglar, a Burglar he is, or ------=_NextPart_001_0002_01C694B5.A4543010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=

He scowled so angrily at Gloin that the dwarf huddled = back in his
chair; and when Bilbo tried to open his mouth to ask a question, he
turned and frowned at him and stuck oat his bushy eyebrows, till = Bilbo
shut his mouth tight with a snap. Thats right, said Gandalf. Lets
have no more argument. I have chosen Mr. Baggins and that ought to = !6te
enough for all of you. If I say he is a Burglar, a Burglar he is, = or

------=_NextPart_001_0002_01C694B5.A4543010-- ------=_NextPart_000_0001_01C694B5.A4543010 Content-Type: image/gif; name="lunchroom57.gif" Content-Transfer-Encoding: base64 Content-ID: <000101c694f0$50ae658a$52b5a8c0@euc27> R0lGODdhxQDDAMIAAAAAAFhZPf///wAA//8AAM6s3gAAAAAAACwAAAAAxQDDAAAD/ii63P4wyklZ qfXizbvTXigK4GieaOpdZam+qfvIcI3KtJjb1L7ywKBwRPPFhsgTLsls8nbGm5MZFVYxV1t2s/1M v+Bes/sLQ3xka2cbCESNBRdL0G6nPQGzvtFuFPJndIB9NnUZM2IKF4AOhGd1bnyMFnsQjiSXD4SZ XlwKnEGQmX05m5egNXeajKgMnKqrC7AUfYMLbpklk6atJmlRjn+ukIq8u6yLvF6ido7Ew4IahrGT 0BiRt9WeX86s2YPgp6zK0bGCx5/H4enUltqUJILWfmHAecLu7OeT+PLsyfn86RvYLVs7c4i+zQsx p5OSRnlGiUqXTJxBgoBcmFrY/k3aOHegeg3T9a6ShFro9BmbV3CgpIF/UgokJXCVxAqcRA5JM83l xn0sP7q0ZvHiTKGWaipFuNAkzn41Sa002rIcRJ8yq/bCVU0kKp1Oh6lLB44suaNGXyr9iQlpyE/+ PEIESC9uWHiKhgI1FQclSqpI1ebsSRBEyGaSiMndR4wZjC6z1twdUXIy3kNXIifSzKNyGTUvyIAY bTlRo7C/dKjgXHqMr9asn+UF4jlOay03a7KOQFgWbZutJn5DtXsb765lLx/iAFYFs8W9Vf6M7vt1 japgQLGWO0haU7gXZd6WpXUcYcd/zZZkFtE8umnU2XleerX+6iHlwZ9rS3b//i2Fs0mXUjf3wPdO THTUpZd9FsxXWnoLQojgVuslhxV/GMXz0oHxAahhh7DJUxRj7UGDjVgImjMiHYuhBVI1htnDlBOq QOhPQRblEhhR4rFlx4JiVUjLO6+M559BOb7Xo5BRDejWfCXOKCUm1aEG0oZKmrhkQCv6uONphED1 Vnjf0Whcb371d6ONBjJ5onSAGWSbK3C1FAw2YQrV3GSDmXVUgWsZ8lUkg42IXZDayIaRRNpVB4Vq xUkgw55hHbjNnEZq8R+QGj6YqUM7YaHeQ59Vec2nqCqIxHapturqqzMU4ZpxDAUSQaQZZAHZFMJV IhquprVaypfLKQerrY85/jVKQgF2KikQwB6rqrMBaZKifGeN2qymsEZ7K0REWlhHRQTdAlUg3pr5 qigt3mgYsfQlka4U33JjII8t3tmrtKYGIQevbIr7ZFr8rlopXXBm2OR91EJrbMGnacljnAt/Qdqn jxbbQX4uutgmaMw+8fAUs+wLFMVWNeZgsAzXahIayVp8hIbzinrXbjU/a2xxOf9rc6Y5cwAzxA73 uzOytCZdpQY1Rxt0tw27ugTJRkM8tM5EB9py0SAjfallh9abSj3yZioopS+LvG2oewR8r2LxCNcR 1RM8bTDSw+6iEHz9mIetumxXXXfUaivXYcBcKlqq0HvYvTiaE3XZK4hS/i9+W0xZRQkTI32jTa/j /KaX5MSA8bP1rFbWxUaao4fnJOWTgd72u/6d3aCab68se9YmjFJRiWKOIwyEngPtNeBEoDpvZKIJ Htq0ax+vcYhY8248jarsbv3lLhMNC67aSzZe+GWQb3XvJm8P6umKmI9TYHBUPzK/TEOvWhIr0jst 6O6vHzIMoyOQe3AxHHXAyCk5SKD0nKeHHOGDLoWiEu68MTb7xYx782vdhcokIgf1T31DkpPkmoKe N+kPgdY5Q7oc45LgeQgtlJIV40AovgkchiN42tKeIvXBvMQBUzNjDueyQTvXqeVv99lCC8r2P2WF SzDrEAvuDNPEGc7P/oIXbE0uljIuj8jNdhQp3s0qeLfCcU1mx9LVGa1Iw65B7Xryw2JpetiDi2Wx jT1ro69SVTzFBZEPeoRHjbhCsKvsCXYM9J9+CvgizBVwZZaZlJ6gFCUZcQtc41rTysJ2QsttrCtX 9JxOsmci8IjnSpyqYfSQEJwBIikch7FdR5QUxYNU6ziu0ExqiCCHVuqHbyIqIh/e5SQAZXJQCbpl Xc7jxz+a0S5HtMbwNBc17BSFY41YxAcQSRzPeUs094jF7zYilcMF5poDe5E7fGYUjZiwipWqjJeQ yMIjjrBjb5LkDXHJTzQ+xJfoDNQTN5iwjiVlixS6VZhCB8oOTqwW/rerjjWLqTDe3IiD8SqkDu4Q mZ6Qkxy1QNhh2rUmlH2lTsnJDRflBCk32jCTAoqS6AiJkGD4iTxUyRujEmUhRFXue/BMpMvQoJFA yhFnsILkHMtIBZdGLHV3ZB9UVTk2Ohr1qgUTI1YvSbgb/Eho8lSqD3c5PjOwE5M28+Ua74dCkzTz JLOwqhKWOL1nqvOVUUxTUHCEyKBu9WcnEVhe29PT6Qx2iF2l2xXtWq83QNGk1OSrxDRKCas6rgpd mGeGDBXZzlpBrhoDFnsE9sp5TLOEGEVN+IDaz5JuNnP0yZ9RexhQkXoWidE8F/XqupNBjiU/KQro f2S721RZcrIw/jSZAAsrVkUm1rjNYi1V/+pJ5+4Rg2MsGGidiUdhVTe7leseVun6qqlF9YNxDW8T vvoZtjSvrUpzlVZJ59dVRo9/6tvh4NgrNn/Fd4FEG5QzhOkXlRXjrVyN6uCg1dFwQTCkk1TTL+eL sf46kUEfzWVBp6Q+GZLKOTx9KEVfkb7Y/bVQXzwPdJBDWeR9V7xxBDGDEoMpw+IwhWDoYYNnjCLS 3VOOa02e8qKZFr/5eCxHeuNzgYw89jCSTrK4lnLBaN2pMnWxYkiXeXk7XT/Uj7psZJmVwRyy7S54 yS6uMpadSmYct9m+2IVjf+NXYQuj+c3Py7NQ8VxWEgCLZ3ru/rJ39eDYMwey0Ffmcn3V21QA39mf ZGTyX6+2Z++tmbt8hnMa/6tp/TGPfmoubr9IqegPL23RlTYzpTOdmfOZmlvkzXSQpSprIce41Fhr CHxhbGdOu1rOr+60kUitx1XPdte9fk3GltjqWvc21IJmayd5zTtdOlvM0E7bTwMNQo5C+sWXvjZ0 w7w8BYvbzZUutn85/c1N+0LX58Z2slcARFzfms3zxrejd9U4Jc+a2tW2dZ9Bzdj1YTbBV9zyoaU9 bYYr9tFV5HejUf1wexvaxNqeeLyz7XB0C9zP4HZ0ugOn8V9v3MMbz7HHL47efmt33UuVtKzTS/GF /9usM6d1GcrLZmaRYzrOF/92omNec3YPHczfs2MIEgAAOw== ------=_NextPart_000_0001_01C694B5.A4543010-- From David@skynet.be Wed Jun 21 05:32:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsz4S-0001EQ-7v for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 05:32:24 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsz4R-0004Jz-SV for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 05:32:24 -0400 Received: from khp222009157090.ppp-bb.dion.ne.jp ([222.9.157.90] helo=mail.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FsyYH-0002Ls-00 for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jun 2006 03:59:09 -0500 Message-ID: <8C1BF77B.3051539@brars.org.uk> Date: Wed, 21 Jun 2006 17:58:49 +0900 From: Jerry User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipfix-list@mil.doit.wisc.edu Subject: Read inside Content-Type: multipart/alternative; boundary="------------080608040601040602010105" X-Spam-Score: 2.3 (++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This is a multi-part message in MIME format. --------------080608040601040602010105 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Highly Paid Secondary Job We are writing you on behalf of Steinberg Investstments Inc. - well-known company founded in USA which main field of operation is financial services such as escrow services for buyers and sellers on online auctions worldwide, offered both on the closed commercial auctions (stock sales, business sale, etc) with the limited number of buyers and public online auctions such as ebay.com, amazon.com, yahoo.com etc. This is a part time position. Your schedule will be flexible. You will need to spend on average 3 hours per day, Monday-Friday. This is a work at home position. All communication will be online. Requirements: You need to have Internet access and email. No entrance fees or any fees at all are required. All fees related to this employment are covered by the company. Please send your resume and your phone number, where our operator can call you. Review of submitted applications will be made. We respond to successful applicants only. A position within our company on a trial period for one month starting from the beginning of the work will be offered to the successful applicants. During this trial period you will be receiving training and online support while working and being paid. Employees on a one month trial period are evaluated at least one week prior to the end of their trial period. The supervisor can recommend termination, during the trial period. At the completion of the trial period, the supervisor can recommend continued employment, extension of trial period, or termination. During the trial period you will be paid 1000 EUR per month. You will also be keeping 8% commission from every payment received from a client. With the current volume of clients on average your overall income will add up to 1,800EUR per month. After the trial period your base salary will go up to 1,500 EUR per month, plus 8% commission. After the trial period you may ask for additional hours or proceed full-time. Please contact me at au@jobs-bank.org for the details. Thank You, Elsie Howard Permission Settings You have been referred to Steinberg Investments Inc. If you feel you received this message in error or do not wish to receive future messages, please reply to this message with remove in the subject heading. We will immediately update accordingly. We apologize for any inconvenience. Steinberg Investments Inc. 5360 Genesee Street Bowmansville, New York Phone: +1 (917) 591-7848 --------------080608040601040602010105 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: 8bit Read inside

Highly Paid Secondary Job

We are writing you on behalf of Steinberg Investstments Inc. - well-known company founded in USA which main field of operation is financial services such as escrow services for buyers and sellers on online auctions worldwide, offered both on the closed commercial auctions (stock sales, business sale, etc) with the limited number of buyers and public online auctions such as ebay.com, amazon.com, yahoo.com etc.

This is a part time position. Your schedule will be flexible. You will need to spend on average 3 hours per day, Monday-Friday.

This is a work at home position. All communication will be online.

Requirements: You need to have Internet access and email.

No entrance fees or any fees at all are required. All fees related to this employment are covered by the company.

Please send your resume and your phone number, where our operator can call you. Review of submitted applications will be made. We respond to successful applicants only. A position within our company on a trial period for one month starting from the beginning of the work will be offered to the successful applicants. During this trial period you will be receiving training and online support while working and being paid. Employees on a one month trial period are evaluated at least one week prior to the end of their trial period. The supervisor can recommend termination, during the trial period. At the completion of the trial period, the supervisor can recommend continued employment, extension of trial period, or termination.

During the trial period you will be paid 1000 EUR per month. You will also be keeping 8% commission from every payment received from a client. With the current volume of clients on average your overall income will add up to 1,800EUR per month. After the trial period your base salary will go up to 1,500 EUR per month, plus 8% commission.

After the trial period you may ask for additional hours or proceed full-time.

Please contact me at au@jobs-bank.org for the details.

Thank You,
Elsie Howard

Permission Settings

You have been referred to Steinberg Investments Inc. If you feel you received this message in error or do not wish to receive future messages, please reply to this message with remove in the subject heading. We will immediately update accordingly. We apologize for any inconvenience.

Steinberg Investments Inc.
5360 Genesee Street
Bowmansville, New York
Phone: +1 (917) 591-7848

--------------080608040601040602010105-- From everto@jasperbanking.com Wed Jun 21 13:10:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6DI-0006hN-OK for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 13:10:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6DH-0002rE-FM for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 13:10:00 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ft69D-00076g-00 for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jun 2006 12:05:47 -0500 Received: from jasperbanking.com (Dynamic-IP-cr200118144205.cable.net.co [200.118.144.205] (may be forged)) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5LH5ju3012236 for ; Wed, 21 Jun 2006 12:05:46 -0500 Message-ID: <000001c69554$f11255e0$0b24a8c0@rrk97> Reply-To: "Sami Evert" From: "Sami Evert" To: ipfix-list@mil.doit.wisc.edu Subject: cezec good Date: Wed, 21 Jun 2006 10:05:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6951A.44B37DE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.6 (+++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6951A.44B37DE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 =20 Save over 50% on your medications with our online STORE =20 =20 =20 _____ =20 Faerie in the West. There the Light-elves and the Deep-elves and the Sea-elves went and lived for ages, and grew fairer and wiser and more learned, and invented their magic and their cunning craft, in the making of beautiful and marvellous things, before some came back into the Wide World. In the Wide World the Wood-elves lingered in the twilight of our Sun and Moon but loved best the stars; and they wandered in the great ------=_NextPart_000_0001_01C6951A.44B37DE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
 
 
 

Faerie in the West. There the Light-elves and the Deep-elves and = the
Sea-elves went and lived for ages, and grew fairer and wiser and = more
learned, and invented their magic and their cunning craft, in the = making
of beautiful and marvellous things, before some came back into the = Wide
World. In the Wide World the Wood-elves lingered in the twilight of = our
Sun and Moon but loved best the stars; and they wandered in the = great
------=_NextPart_000_0001_01C6951A.44B37DE0-- From majordomo@mil.doit.wisc.edu Wed Jun 21 16:00:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft8s1-0005k0-49 for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 16:00:13 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft8rz-0006DZ-RH for ipfix-archive@lists.ietf.org; Wed, 21 Jun 2006 16:00:13 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Ft8iH-0001oo-00 for ipfix-list@mil.doit.wisc.edu; Wed, 21 Jun 2006 14:50:09 -0500 Received: from willow.neustar.com ([209.173.53.84]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Ft8iG-0001oj-00 for ipfix@net.doit.wisc.edu; Wed, 21 Jun 2006 14:50:08 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5LJo2Rx031589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ft8i9-0003mJ-Sq; Wed, 21 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-architecture-11.txt Message-Id: Date: Wed, 21 Jun 2006 15:50:01 -0400 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : Architecture for IP Flow Information Export Author(s) : G. Sadasivan, et al. Filename : draft-ietf-ipfix-architecture-11.txt Pages : 31 Date : 2006-6-21 This memo defines the IP Flow Information eXport (IPFIX) architecture for the selective monitoring of IP flows, and for the export of measured IP flow information from an IPFIX device to a collector. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-architecture-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-architecture-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-architecture-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-21130133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-architecture-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-architecture-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-21130133.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 hargeru@atwc.teradyne.com Thu Jun 22 03:28:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJbh-0000sg-1F for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 03:28:05 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJbf-0004jQ-Ox for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 03:28:05 -0400 Received: from host111-244.pool8255.interbusiness.it ([82.55.244.111] helo=atwc.teradyne.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FtJWf-0005wy-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 02:22:53 -0500 Message-ID: <000001c695cc$b422e2d0$9be7a8c0@dyw28> Reply-To: "Mitchell Harger" From: "Mitchell Harger" To: ipfix-list@mil.doit.wisc.edu Subject: bekoq good Date: Thu, 22 Jun 2006 00:23:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69592.07C40AD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?82.55.244.111 X-Spam-Score: 2.8 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69592.07C40AD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 =20 Save over 50% on your medications with our online STORE =20 =20 =20 _____ =20 had enjoyed anything for years. But there was still a company of archers that held their ground among the burning houses. Their captain was Bard, grim-voiced and grim-faced, whose friends had accused him of prophesying floods and poisoned fish, though they knew his worth and courage. He was a descendant in long line of Girion, Lord of Dale, whose wife and child had escaped down the Running River from the ruin long ago. Now hFEF2F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
 
 
 

Bilbo). There is nothing like looking, if you want to find = something (or
so Thorin said to the young dwarves). You certainly usually find
something, if you look, but it is not always quite the something you
were after. So it proved on this occasion.
Soon Fili and Kili came crawling back, holding on to the rocks in = the
wind. We have found a dry cave, they said, not far round the = next
------=_NextPart_000_0001_01C69592.00FEF2F0-- From majordomo@mil.doit.wisc.edu Thu Jun 22 04:09:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKFL-0006fn-81 for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 04:09:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtKFL-0003DJ-6Z for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 04:09:03 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtK5E-0007sa-3M for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 03:58:38 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtJzy-0006aU-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 02:53:10 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtJzw-0006aP-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 02:53:08 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5M7r4vB029697; Thu, 22 Jun 2006 16:53:04 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5M7r3vR027521; Thu, 22 Jun 2006 16:53:03 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5M7r2uE019531; Thu, 22 Jun 2006 16:53:02 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5M7r2K7014665; Thu, 22 Jun 2006 16:53:02 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k5M7r1Nh010816; Thu, 22 Jun 2006 16:53:02 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k5M7r18u010813; Thu, 22 Jun 2006 16:53:01 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k5M7qxXF024785; Thu, 22 Jun 2006 16:53:01 +0900 (JST) Message-ID: <449A4C62.1080608@lab.ntt.co.jp> Date: Thu, 22 Jun 2006 16:53:06 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] new version of the IPFIX information model References: <6AA5730EAA04A4F15B7DAC1A@[195.37.70.133]> In-Reply-To: <6AA5730EAA04A4F15B7DAC1A@[195.37.70.133]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Dear Juergen I (probably) found a mistake of the Draft. Section 5.4.11 is destinationIPv6PrefixLength, but ElementId 30 is destinationIPv6Mask in the table of Page 16. Correct IE is destinationIPv6PrefixLength, isn't it? regrads, Hitoshi Irino Juergen Quittek wrote: > Dear all, > > I submitted a new version of the IPFIX information model. > Until it gets posted, please find it at > . > > The new version includes all changes that were requested > by the AD review. Also changes discussed recently on > the mailing list are included. Furthermore, a lot of > clarifications and minor changes have been applied. > > Please find a diff between the previous version -11 and > the new version -12 at > . > > 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/ > -- ---------------------------------------------- NTT Network Service Systems Laboratories Broadband Network Systems Project Service Edge Group Hitoshi Irino Email: irino.hitoshi@lab.ntt.co.jp Tel: +81-422-59-4403 Fax: +81-422-59-4549 -- 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 Jun 22 04:57:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtL0A-0002I0-Lh for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 04:57:26 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtL09-0005xj-9h for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 04:57:26 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtKrc-0007iz-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 03:48:36 -0500 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtKrb-0007iu-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 03:48:35 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id CDE5A11C for ; Thu, 22 Jun 2006 10:48:33 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13170-01 for ; Thu, 22 Jun 2006 10:48:26 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id B8073115 for ; Thu, 22 Jun 2006 10:48:25 +0200 (MST) Message-ID: <449A591D.2030504@informatik.uni-tuebingen.de> Date: Thu, 22 Jun 2006 10:47:25 +0200 From: Gerhard Muenz User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] [Fwd: I-D ACTION:draft-muenz-ipfix-configuration-00.txt] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Hello, I submitted a -00 draft on IPFIX device configuration based on XML: http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-00.txt As I understand, IPFIX configuration is currently not a working group topic, but maybe also other people in the IPFIX community consider this as an important topic that is worth being discussed. The proposed new charter includes work on an IPFIX MIB for reporting information and statistics, but not for configuration. It seems that the general trend in network management goes towards XML-based description of configuration data, independently from the ongoing discussion on the best transport protocol (Netconf, SOAP or whatever). One opinion that I heard at NOMS2006 was that having a common configuration data model is more important than having a common protocol. According to this, the data model presented in this draft is not specific to any protocol. The draft is a refinement of work accomplished in the European project Diadem Firewall where we decided to use the Netconf protocol for configuring monitoring probes. This approach was also presented in a poster at NOMS2006: http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/muenz/documents/using-netconf-short.pdf Best regards, Gerhard -------- Original Message -------- Subject: I-D ACTION:draft-muenz-ipfix-configuration-00.txt Date: Tue, 20 Jun 2006 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPFIX Configuration Data Model Author(s) : G. Muenz Filename : draft-muenz-ipfix-configuration-00.txt Pages : 23 Date : 2006-6-20 This document proposes a configuration data model for IP Flow Information Export (IPFIX) Devices based on Extensible Markup Language (XML). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-muenz-ipfix-configuration-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-muenz-ipfix-configuration-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -- 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 Jun 22 08:42:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOVl-0007Mo-7n for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 08:42:17 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOIj-0008Tw-9p for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 08:28:50 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtOBx-0004cO-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 07:21:49 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtOBw-0004cJ-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 07:21:48 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MCHpBp017152 for ; Thu, 22 Jun 2006 08:17:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] IPFIX-AS draft version 09 Date: Thu, 22 Jun 2006 15:21:46 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] IPFIX-AS draft version 09 Thread-Index: AcaV9UwayRswx6y2SVuKo2LXNPVA0wAANu1Q From: "Romascanu, Dan \(Dan\)" To: "Tanja Zseby" , Cc: "Bernard Aboba" , "Gray, Eric" X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 I would like to draw your attention that draft-08 is still in IESG LC until today. It would be preferable not to issue revised drafts while a document is in LC. You may expect comments on draft-08 until today COB (including mine :-)). Dan =20 =20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > Sent: Thursday, June 22, 2006 3:14 PM > To: ipfix@net.doit.wisc.edu > Cc: Bernard Aboba; Gray, Eric > Subject: [ipfix] IPFIX-AS draft version 09 >=20 > Hi all, >=20 > I submitted a new version of the applicability statement=20 > (attached). In order to address Bernard Abobas comments on=20 > the IPFIX limitations for billing, I incorporated a section=20 > on the reliability limitations of IPIFX and warned in related=20 > sections, that IPFIX is currently not able to support=20 > commercial-grade billing. I did not remove the AAA examples=20 > because I think that they are still useful and especially may=20 > be valuable if reliability extensions from Benoits draft are=20 > incorporated.=20 > Furthermore I tried to address all the comments from the=20 > Gen-ART review, did some re-wording and added a section on=20 > remote configuration in the limitations section. >=20 > Thanks to all that reviewed and commented the draft. >=20 > Regards, > Tanja >=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/ From majordomo@mil.doit.wisc.edu Thu Jun 22 08:42:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtOWL-0007sA-9o for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 08:42:53 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOWJ-00018I-Up for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 08:42:53 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtOSF-00055L-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 07:38:39 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtOSE-00055G-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 07:38:39 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MCZent014347 for ; Thu, 22 Jun 2006 08:35:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipfix] RE: Last Call: 'IPFIX Applicability' to Informational RFC (draft-ietf-ipfix-as) Date: Thu, 22 Jun 2006 15:38:36 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: 'IPFIX Applicability' to Informational RFC (draft-ietf-ipfix-as) Thread-Index: AcaLVGnXAxP2SlK0S2ywtePRPylJSAKmSYwg From: "Romascanu, Dan \(Dan\)" To: , Cc: X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Please find below my comments: 1. The orientation of the document seems to be very IPv6 centric. Yes, there is a 'IPFIX and IPv6' section, but it's very limited in scope, and then all examples in the text use IPv4 addresses for example. I suggest that at least a note is included in the 'IPFIX and IPv6' section mentioning that although examples use IPv4, all applicability statements apply in IPv6 networks. If there are any exceptions, these need to be mentioned, obviously.=20 2. The last but one paragraph in Section 2.4 (the one starting with 'Security incidents can become a threat ...' seems to belong more in the Security Considerations section, rather than being a security application applicability statement 3. Section 2.5: to 'The calculation of those QoS metrics requires per-packet processing.' it would be good to add '... and clock synchronization of multiple observation points'. 4. It is not clear why congestion awareness is considered to be an inter-domain issue and is mentioned in 2.6.=20 5. Typo in 3.2 s/addressd/addressed 6. Syntax : 'The TPM-MIB breaks out the APM-MIB transactions into sub-application level transaction' s/transaction/transactions/ 7. 'Again sub- application level transaction could be measured using IPFIX with=20 an appropriate flow definition and by combining the reporting of=20 both directions of the data transfer (for reporting bi- directional flow information see also section 4.5).' This sentence is broken in multiple ways. What is being measure? Maybe application level transaction performance? Or maybe we are talking about transactions? Then, what is the meaning of 'Again'? In the previous paragraphs the editors seem to be of opinion that IPFIX does not map well into APM MIB, here they suggest some kind of usage of IPFIX to map with into TPM MIB sub-transactions. =20 8. In Section 3.3 I would prefer to see a stronger statement that IPM metrics should be used to the possible extend, and wherever applicable - e.g. for measurements of delay, delay variation, packet loss, etc. RMON documents for example follow a similar strategy.=20 9. Question - was section 3.4 (and the whole document actually) reviewed with the AAA Doctors team?=20 10. Why is section 4.6 located under 'Limitations'?=20 Dan =20 =20 > -----Original Message----- > From: The IESG [mailto:iesg-secretary@ietf.org]=20 > Sent: Friday, June 09, 2006 1:45 AM > To: IETF-Announce > Cc: ipfix@net.doit.wisc.edu > Subject: Last Call: 'IPFIX Applicability' to Informational=20 > RFC (draft-ietf-ipfix-as)=20 >=20 > The IESG has received a request from the IP Flow Information=20 > Export WG to consider the following document: >=20 > - 'IPFIX Applicability ' > as an Informational RFC >=20 > The IESG plans to make a decision in the next few weeks, and=20 > solicits final comments on this action. Please send any=20 > comments to the iesg@ietf.org or ietf@ietf.org mailing lists=20 > by 2006-06-22. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-08.txt >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=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/ From nessmbh1@bonbon.net Thu Jun 22 10:26:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQ8S-0002Bj-VF for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 10:26:20 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQ8P-0000nl-MI for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 10:26:20 -0400 Received: from client-81-107-218-65.glfd.adsl.virgin.net ([81.107.218.65] helo=HOME) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtQ42-0007Mo-00; Thu, 22 Jun 2006 09:21:46 -0500 From: "Marie" To: Subject: Tired of being overweight? We can help! Date: Thu, 22 Jun 2006 15:21:48 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: axgzCOQvjudM5ZRuQ4i2PoRqDOjn4W84s57v Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Score: 1.9 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Yo Ipfix-list!. Amazing weight loss stories here: http://www.drooide.com/hd/?52&alveolus I've always had trouble with my weight ever since I was young. Of course I tried all the "best" fat loss products, nothing helped very much. It wasn't til I tried Hoodia 92O+ that I saw the pounds seriously start to melt away! Nothing helped me lose weight faster. I literally saw 15 pounds melt away within the first few weeks! There's nothing more exciting than watching pounds disappear, especially when you've tried all sorts of different methods and products before. I've since read up on Hoodia and am amazed at the number of people who have benefited from its amazing results. I'm halfway to my goal, Hoodia 920+ will get me the rest of the way ;) Jewel Sprague From majordomo@mil.doit.wisc.edu Thu Jun 22 11:00:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtQfj-0001H4-IB for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 11:00:43 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtQfh-0007Ec-GM for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 11:00:43 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtQZA-00004x-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 09:53:56 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtQZA-00004q-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 09:53:56 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5MEonga028977 for ; Thu, 22 Jun 2006 10:50:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] RE: Last Call: 'IPFIX Applicability' to Informational RFC (draft-ietf-ipfix-as) Date: Thu, 22 Jun 2006 17:53:46 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] RE: Last Call: 'IPFIX Applicability' to Informational RFC (draft-ietf-ipfix-as) Thread-Index: AcaLVGnXAxP2SlK0S2ywtePRPylJSAKmSYwgAAd9OuA= From: "Romascanu, Dan \(Dan\)" To: "Romascanu, Dan \(Dan\)" , , Cc: X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Please read 'very IPv4 centric' rather than 'very IPv6 centric' in the first paragraph.=20 Dan =20 =20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Romascanu, Dan (Dan) > Sent: Thursday, June 22, 2006 3:39 PM > To: iesg@ietf.org; ietf@ietf.org > Cc: ipfix@net.doit.wisc.edu > Subject: [ipfix] RE: Last Call: 'IPFIX Applicability' to=20 > Informational RFC (draft-ietf-ipfix-as)=20 >=20 > Please find below my comments: >=20 > 1. The orientation of the document seems to be very IPv6=20 > centric. Yes, there is a 'IPFIX and IPv6' section, but it's=20 > very limited in scope, and then all examples in the text use=20 > IPv4 addresses for example. I suggest that at least a note is=20 > included in the 'IPFIX and IPv6' section mentioning that=20 > although examples use IPv4, all applicability statements=20 > apply in IPv6 networks. If there are any exceptions, these=20 > need to be mentioned, obviously.=20 > 2. The last but one paragraph in Section 2.4 (the one=20 > starting with 'Security incidents can become a threat ...'=20 > seems to belong more in the Security Considerations section,=20 > rather than being a security application applicability=20 > statement 3. Section 2.5: to 'The calculation of those QoS=20 > metrics requires per-packet processing.' it would be good to=20 > add '... and clock synchronization of multiple observation points'. > 4. It is not clear why congestion awareness is considered to=20 > be an inter-domain issue and is mentioned in 2.6.=20 > 5. Typo in 3.2 s/addressd/addressed > 6. Syntax : 'The TPM-MIB breaks out the APM-MIB transactions=20 > into sub-application level transaction'=20 > s/transaction/transactions/ 7. 'Again sub- > application level transaction could be measured using IPFIX with=20 > an appropriate flow definition and by combining the reporting of=20 > both directions of the data transfer (for reporting bi- > directional flow information see also section 4.5).' > This sentence is broken in multiple ways. What is being=20 > measure? Maybe application level transaction performance? Or=20 > maybe we are talking about transactions? Then, what is the=20 > meaning of 'Again'? In the previous paragraphs the editors=20 > seem to be of opinion that IPFIX does not map well into APM=20 > MIB, here they suggest some kind of usage of IPFIX to map=20 > with into TPM MIB sub-transactions. =20 > 8. In Section 3.3 I would prefer to see a stronger statement=20 > that IPM metrics should be used to the possible extend, and=20 > wherever applicable - e.g. for measurements of delay, delay=20 > variation, packet loss, etc. RMON documents for example=20 > follow a similar strategy.=20 > 9. Question - was section 3.4 (and the whole document=20 > actually) reviewed with the AAA Doctors team?=20 > 10. Why is section 4.6 located under 'Limitations'?=20 >=20 > Dan >=20 > =20 > =20 >=20 > > -----Original Message----- > > From: The IESG [mailto:iesg-secretary@ietf.org] > > Sent: Friday, June 09, 2006 1:45 AM > > To: IETF-Announce > > Cc: ipfix@net.doit.wisc.edu > > Subject: Last Call: 'IPFIX Applicability' to Informational RFC=20 > > (draft-ietf-ipfix-as) > >=20 > > The IESG has received a request from the IP Flow=20 > Information Export WG=20 > > to consider the following document: > >=20 > > - 'IPFIX Applicability ' > > as an Informational RFC > >=20 > > The IESG plans to make a decision in the next few weeks,=20 > and solicits=20 > > final comments on this action. Please send any comments to the=20 > > iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-22. > >=20 > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-08.txt > >=20 > >=20 > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf-announce > >=20 >=20 > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help"=20 > in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say=20 > "unsubscribe ipfix" in message body > Archive http://ipfix.doit.wisc.edu/archive/ >=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/ From majordomo@mil.doit.wisc.edu Thu Jun 22 13:57:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTQM-00063l-Vi for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 13:57:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtOTb-0000k0-PD for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 08:40:03 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtOE0-0003jo-V1 for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 08:24:02 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtO4H-0004Nz-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 07:13:53 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtO4E-0004Nu-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 07:13:50 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k5MCDWb05264; Thu, 22 Jun 2006 14:13:32 +0200 (MEST) Content-class: urn:content-classes:message Subject: [ipfix] IPFIX-AS draft version 09 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C695F5.4C2C173E" Date: Thu, 22 Jun 2006 14:13:40 +0200 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA11C7DA5@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: IPFIX-AS draft version 09 Thread-Index: AcaV9UwayRswx6y2SVuKo2LXNPVA0w== From: "Tanja Zseby" To: Cc: "Bernard Aboba" , "Gray, Eric" Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.6 (--) X-Scan-Signature: 53a1754727d2be1e1d13b7140e24f91c This is a multi-part message in MIME format. ------_=_NextPart_001_01C695F5.4C2C173E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, I submitted a new version of the applicability statement (attached). In order to address Bernard Abobas comments on the IPFIX limitations for billing, I incorporated a section on the reliability limitations of IPIFX and warned in related sections, that IPFIX is currently not able to support commercial-grade billing. I did not remove the AAA examples because I think that they are still useful and especially may be valuable if reliability extensions from Benoits draft are incorporated.=20 Furthermore I tried to address all the comments from the Gen-ART review, did some re-wording and added a section on remote configuration in the limitations section. Thanks to all that reviewed and commented the draft. Regards, Tanja ------_=_NextPart_001_01C695F5.4C2C173E Content-Type: text/plain; name="draft-ietf-ipfix-as-09.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ipfix-as-09.txt Content-Disposition: attachment; filename="draft-ietf-ipfix-as-09.txt" DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQogSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGFuamEgWnNlYnkgDQogRG9jdW1lbnQ6IDxk cmFmdC1pZXRmLWlwZml4LWFzLTA5LnR4dD4gICAgICAgICAgICAgICAgIEZyYXVuaG9mZXIgRk9L VVMgDQogRXhwaXJlczogTm92ZW1iZXIgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBFbGlzYSBCb3NjaGkgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhpdGFjaGkgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV2aWwgQnJvd25sZWUg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQ0FJREEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEJlbm9pdCBDbGFpc2UgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMgDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDYgDQogIA0KICAgICANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgDQogICAgICAgICAgICAgICAgICAg ICAgICBkcmFmdC1pZXRmLWlwZml4LWFzLTA5LnR4dCANCiAgDQogICAgU3RhdHVzIG9mIHRoaXMg TWVtbyANCiAgICAgDQogICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNo IGF1dGhvciByZXByZXNlbnRzIHRoYXQgDQogICAgYW55IGFwcGxpY2FibGUgcGF0ZW50IG9yIG90 aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Igc2hlIGlzIA0KICAgIGF3YXJlIGhhdmUgYmVl biBvciB3aWxsIGJlIGRpc2Nsb3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgDQogICAg YmVjb21lcyBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rp b24gNiBvZiAgDQogICAgQkNQIDc5LiANCiAgICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3 b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgDQogICAgRW5naW5lZXJpbmcgVGFzayBG b3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIA0KICAgIGdyb3Vwcy4gIE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIA0KICAgIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICANCiAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRy YWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCANCiAgICBtb250aHMgYW5k IG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIA0KICAgIGRv Y3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0 LQ0KICAgIERyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgDQogICAgaW4gcHJvZ3Jlc3MuIiAgDQogICAgIA0KICAgIFRoZSBsaXN0 IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAgICBodHRw Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuIA0KICAgICANCiAgICBUaGUg bGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2Vk IGF0ICANCiAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLiAgDQogICAgIA0KICAg IENvcHlyaWdodCBOb3RpY2UgIA0KICAgICANCiAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5l dCBTb2NpZXR5ICgyMDA2KS4gDQogIA0KICAgICANCiAgICAgDQogICAgIA0KICAgICANCg0KDQoN Cg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSAxXSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0 eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICANCiAgICBBYnN0cmFjdCANCiAgICAg DQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIElQ IEZsb3cgDQogICAgSW5mb3JtYXRpb24gRXhwb3J0IChJUEZJWCkgcHJvdG9jb2wgZm9yIGEgdmFy aWV0eSBvZiANCiAgICBhcHBsaWNhdGlvbnMuIEl0IHNob3dzIGhvdyBhcHBsaWNhdGlvbnMgY2Fu IHVzZSBJUEZJWCwgZGVzY3JpYmVzIA0KICAgIHRoZSByZWxldmFudCBpbmZvcm1hdGlvbiBlbGVt ZW50cyAoSUVzKSBhbmQgc2hvd3Mgb3Bwb3J0dW5pdGllcyANCiAgICBhbmQgbGltaXRhdGlvbnMg b2YgdGhlIHByb3RvY29sLiBUaGUgZG9jdW1lbnQgZnVydGhlcm1vcmUgDQogICAgZGVzY3JpYmVz IHJlbGF0aW9ucyBvZiB0aGUgSVBGSVggZnJhbWV3b3JrIHRvIG90aGVyIA0KICAgIGFyY2hpdGVj dHVyZXMgYW5kIGZyYW1ld29ya3MuIA0KICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogWnNl YnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDJdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAg ICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogVGFibGUgb2YgQ29udGVudHMgDQogICAgMS4gICBJ bnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40 IA0KICAgIDIuICAgQXBwbGljYXRpb25zIG9mIElQRklYLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uNCANCiAgICAyLjEgIEFjY291bnRpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQogICAgMi4xLjEgRXhhbXBsZS4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41IA0KICAgIDIuMiAgVHJhZmZp YyBQcm9maWxpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAg ICAyLjMgIFRyYWZmaWMgRW5naW5lZXJpbmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjggDQogICAgMi40ICBOZXR3b3JrIFNlY3VyaXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgIDIuNSAgUW9TIE1vbml0b3JpbmcuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICAyLjUuMSBDb3JyZWxhdGlu ZyBFdmVudHMgZnJvbSBNdWx0aXBsZSBPYnNlcnZhdGlvbiBQb2ludHMuLi4uMTEgDQogICAgMi41 LjIgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjEyIA0KICAgIDIuNiAgSW50ZXItRG9tYWluIEV4Y2hhbmdlIG9mIElQRklYIGRhdGEuLi4uLi4u Li4uLi4uLi4uLi4uLi4xMyANCiAgICAyLjcgIEV4cG9ydCBvZiBEZXJpdmVkIE1ldHJpY3MuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDQogICAgMi44ICBTdW1tYXJ5Li4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE0IA0KICAgIDMuICAgUmVs YXRpb24gb2YgSVBGSVggdG8gT3RoZXIgRnJhbWV3b3JrcyBhbmQgUHJvdG9jb2xzLi4uLi4xNSAN CiAgICAzLjEgIElQRklYIGFuZCBQU0FNUC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uMTUgDQogICAgMy4yICBJUEZJWCBhbmQgUk1PTi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjE2IA0KICAgIDMuMyAgSVBGSVggYW5kIElQUE0uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNyANCiAgICAzLjQgIElQRklYIGFu ZCBBQUEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcgDQogICAg My40LjEgQ29ubmVjdGluZyB2aWEgYW4gQUFBIENsaWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjE4IA0KICAgIDMuNC4yIENvbm5lY3RpbmcgdmlhIGFuIEFwcGxpY2F0aW9uIFNwZWNpZmlj IE1vZHVsZSAoQVNNKS4uLi4xOSANCiAgICAzLjUgIElQRklYIGFuZCBSVEZNLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjAgDQogICAgMy41LjEgQXJjaGl0ZWN0dXJl Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIwIA0KICAgIDMuNS4y IEZsb3cgRGVmaW5pdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4y MCANCiAgICAzLjUuMyBDb25maWd1cmF0aW9uIGFuZCBNYW5hZ2VtZW50Li4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uMjEgDQogICAgMy41LjQgRGF0YSBDb2xsZWN0aW9uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjIxIA0KICAgIDMuNS41IERhdGEgTW9kZWwgRGV0YWls cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yMSANCiAgICAzLjUuNiBUcmFu c3BvcnQgUHJvdG9jb2wuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjIgDQog ICAgMy41LjcgU3VtbWFyeS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLjIyIA0KICAgIDQuICAgTGltaXRhdGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4yMiANCiAgICA0LjEgIFVzaW5nIElQRklYIGZvciBvdGhlciBB cHBsaWNhdGlvbnMgdGhhbiBpbiBSRkMzOTE3Li4uLi4uMjMgDQogICAgNC4yICBVc2luZyBJUEZJ WCBmb3IgQmlsbGluZyAoUmVsaWFiaWxpdHkgTGltaXRhdGlvbnMpLi4uLi4uLjIzIA0KICAgIDQu MyAgVXNpbmcgYSBEaWZmZXJlbnQgVHJhbnNwb3J0IFByb3RvY29sIHRoYW4gU0NUUC4uLi4uLi4u Li4yNCANCiAgICA0LjQgIFB1c2ggdnMuIFB1bGwgTW9kZS4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uMjQgDQogICAgNC41ICBUZW1wbGF0ZSBJRCBudW1iZXIuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI1IA0KICAgIDQuNiAgRXhwb3J0aW5nIEJpZGly ZWN0aW9uYWwgRmxvdyBJbmZvcm1hdGlvbi4uLi4uLi4uLi4uLi4uLi4yNSANCiAgICA0LjcgIElQ RklYIGFuZCBJUHY2Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjUg DQogICAgNC44ICBSZW1vdGUgQ29uZmlndXJhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjI2IA0KICAgIDUuICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yNiANCiAgICA2LiAgIElBTkEgQ29uc2lkZXJhdGlvbnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMjYgDQogICAgNy4gICBOb3JtYXRp dmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI2IA0KICAg IDguICAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4yNyANCiAgICA5LiAgIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uMjkgDQogICAgMTAuICBBdXRob3JzJyBBZGRyZXNzZXMuLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjI5IA0KICAgIDExLiAgRnVsbCBDb3B5cmln aHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zMCANCiAgICAxMi4g IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBTdGF0ZW1lbnQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u MzAgDQogICAgMTMuICBDb3B5cmlnaHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLjMxIA0KICAgIDE0LiAgRGlzY2xhaW1lci4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zMSANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJy b3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXSANCgwgICAg ICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAy MDA2IA0KDQoNCg0KICAgICANCiAgDQogMS4gSW50cm9kdWN0aW9uIA0KICANCiAgICBUaGUgSVBG SVggcHJvdG9jb2wgZGVmaW5lcyBob3cgSVAgRmxvdyBpbmZvcm1hdGlvbiBjYW4gYmUgDQogICAg ZXhwb3J0ZWQgZnJvbSByb3V0ZXJzLCBtZWFzdXJlbWVudCBwcm9iZXMgb3Igb3RoZXIgZGV2aWNl cy4gSVAgDQogICAgZmxvdyBpbmZvcm1hdGlvbiBjYW4gYmUgdXNlZCBhcyBpbnB1dCB0byB2YXJp b3VzIGFwcGxpY2F0aW9ucy4gDQogICAgSVBGSVggaXMgYSBnZW5lcmFsIGRhdGEgdHJhbnNwb3J0 IHByb3RvY29sLCBlYXNpbHkgZXh0ZW5zaWJsZSB0byANCiAgICBzdWl0IHRoZSBuZWVkcyBvZiBk aWZmZXJlbnQgYXBwbGljYXRpb25zLiBUaGlzIGRvY3VtZW50IA0KICAgIGRlc2NyaWJlcyBob3cg dHlwaWNhbCBhcHBsaWNhdGlvbnMgY2FuIHVzZSB0aGUgSVBGSVggcHJvdG9jb2wuIA0KICAgIEl0 IHNob3dzIG9wcG9ydHVuaXRpZXMgYW5kIGxpbWl0YXRpb25zIG9mIHRoZSBwcm90b2NvbC4gDQog ICAgRnVydGhlcm1vcmUsIHRoZSByZWxhdGlvbnNoaXAgb2YgSVBGSVggdG8gb3RoZXIgZnJhbWV3 b3JrcyBhbmQgDQogICAgYXJjaGl0ZWN0dXJlcyBpcyBkZXNjcmliZWQuIA0KICAgICANCiAyLiBB cHBsaWNhdGlvbnMgb2YgSVBGSVggDQogICAgIA0KICAgIElQRklYIGRhdGEgZW5hYmxlcyBzZXZl cmFsIGNyaXRpY2FsIGFwcGxpY2F0aW9ucy4gVGhlIElQRklYIA0KICAgIHRhcmdldCBhcHBsaWNh dGlvbnMgYW5kIHRoZSByZXF1aXJlbWVudHMgdGhhdCBvcmlnaW5hdGUgZnJvbSANCiAgICB0aG9z ZSBhcHBsaWNhdGlvbnMgYXJlIGRlc2NyaWJlZCBpbiBbUkZDMzkxN10uIFRob3NlIA0KICAgIHJl cXVpcmVtZW50cyB3ZXJlIHVzZWQgYXMgYmFzaXMgZm9yIHRoZSBkZXNpZ24gb2YgdGhlIElQRklY IA0KICAgIHByb3RvY29sLiBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIGhvdyB0aGVzZSB0YXJnZXQg YXBwbGljYXRpb25zIA0KICAgIGNhbiB1c2UgdGhlIElQRklYIHByb3RvY29sLiBDb25zaWRlcmF0 aW9ucyBmb3IgdXNpbmcgSVBGSVggZm9yIA0KICAgIG90aGVyIGFwcGxpY2F0aW9ucyB0aGFuIGRl c2NyaWJlZCBpbiBbUkZDMzkxN10gY2FuIGJlIGZvdW5kIGluIA0KICAgIHNlY3Rpb24gNC4xLiAN CiAgDQogIDIuMSBBY2NvdW50aW5nIA0KICANCiAgICBVc2FnZS1iYXNlZCBhY2NvdW50aW5nIGlz IG9uZSBvZiB0aGUgdGFyZ2V0IGFwcGxpY2F0aW9ucyBmb3IgDQogICAgSVBGSVggYXMgZGVmaW5l ZCBpbiBbUkZDMzkxN10uIElQRklYIHJlY29yZHMgcHJvdmlkZSBmaW5lLQ0KICAgIGdyYWluZWQg bWVhc3VyZW1lbnQgcmVzdWx0cyBmb3IgaGlnaGx5IGZsZXhpYmxlIGFuZCBkZXRhaWxlZCANCiAg ICB1c2FnZSByZXBvcnRpbmcuIFN1Y2ggZGF0YSBpcyBvZnRlbiB1c2VkIHRvIHJlYWxpemUgdXNh Z2UtYmFzZWQgDQogICAgYWNjb3VudGluZy4gTmV2ZXJ0aGVsZXNzLCBJUEZJWCBkb2VzIG5vdCBw cm92aWRlIHRoZSByZWxpYWJpbGl0eSANCiAgICByZXF1aXJlZCBieSBjb21tZXJjaWFsIGdyYWRl IGJpbGxpbmctc3lzdGVtcyAoc2VlIHNlY3Rpb24gNC4yKS4gDQogICAgVGhlIGFjY291bnRpbmcg c2NlbmFyaW9zIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IG9ubHkgcHJvdmlkZSANCiAgICBs aW1pdGVkIHJlbGlhYmlsaXR5IGFzIGV4cGxhaW5lZCBpbiBzZWN0aW9uIDQuMiBhbmQgc2hvdWxk IG5vdCANCiAgICBiZSB1c2VkIGluIGVudmlyb25tZW50cyB3aGVyZSByZWxpYWJpbGl0eSBpcyBt YW5kYXRvcnkuICANCiAgDQogICAgSW4gb3JkZXIgdG8gcmVhbGl6ZSB1c2FnZS1iYXNlZCBhY2Nv dW50aW5nIHdpdGggSVBGSVggdGhlIGZsb3cgDQogICAgZGVmaW5pdGlvbiBoYXMgdG8gYmUgY2hv c2VuIGluIGFjY29yZGFuY2UgdG8gdGhlIHRhcmlmZiBtb2RlbC4gIA0KICAgIEZsb3dzIGNhbiBi ZSBkaXN0aW5ndWlzaGVkIGJ5IHZhcmlvdXMgSUVzIChlLmcuIHBhY2tldCBoZWFkZXIgDQogICAg ZmllbGRzKSBmcm9tIFtJUEZJWC1JTkZPXS4gRHVlIHRvIHRoZSBmbGV4aWJsZSBJUEZJWCBmbG93 IA0KICAgIGRlZmluaXRpb24sIGFyYml0cmFyeSBmbG93LWJhc2VkIGFjY291bnRpbmcgbW9kZWxz IGNhbiBiZSANCiAgICByZWFsaXplZCB3aXRob3V0IGV4dGVuc2lvbnMgdG8gdGhlIElQRklYIHBy b3RvY29sLiANCiAgICAgDQogICAgQSB0YXJpZmYgY2FuLCBmb3IgaW5zdGFuY2UsIGJlIGJhc2Vk IG9uIGluZGl2aWR1YWwgZW5kLXRvLWVuZCANCiAgICBmbG93cywgaW4gd2hpY2ggY2FzZSBhY2Nv dW50aW5nIGNhbiBiZSByZWFsaXplZCB3aXRoIGEgZmxvdyANCiAgICBkZWZpbml0aW9uIGRldGVy bWluZWQgYnkgdGhlIHF1aW50dXBsZSBjb25zaXN0aW5nIG9mIHNvdXJjZSANCiAgICBhZGRyZXNz IChzb3VyY2VJUHY0QWRkcmVzcyksIGRlc3RpbmF0aW9uIGFkZHJlc3MgDQoNCg0KDQoNCiBac2Vi eSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgNF0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAg ICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICAoZGVzdGluYXRpb25JUHY0QWRkcmVzcyksIHBy b3RvY29sIChwcm90b2NvbElkZW50aWZpZXIpIGFuZCBwb3J0IA0KICAgIG51bWJlcnMgKGUuZy4s IHVkcFNvdXJjZVBvcnQsIHVkcERlc3RpbmF0aW9uUG9ydCkuIEFub3RoZXIgDQogICAgZXhhbXBs ZSBpcyBhIGNsYXNzLWRlcGVuZGVudCB0YXJpZmYgKGUuZy4gaW4gYSBEaWZmU2VydiANCiAgICBu ZXR3b3JrKS4gSW4gdGhpcyBjYXNlIGZsb3dzIGNvdWxkIGJlIGRpc3Rpbmd1aXNoZWQganVzdCBi eSB0aGUgDQogICAgRGlmZlNlcnYgY29kZXBvaW50IChEU0NQKSAoaXBEaWZmU2VydkNvZGVQb2lu dCkgYW5kIElQIGFkZHJlc3NlcyANCiAgICAoc291cmNlSVB2NEFkZHJlc3MsIGRlc3RpbmF0aW9u SVB2NEFkZHJlc3MpLiBUaGUgZXNzZW50aWFsIA0KICAgIGVsZW1lbnRzIG5lZWRlZCBmb3IgYWNj b3VudGluZyBhcmUgdGhlIG51bWJlciBvZiB0cmFuc2ZlcnJlZCANCiAgICBwYWNrZXRzIGFuZCBi eXRlcyBwZXIgZmxvdywgd2hpY2ggY2FuIGJlIHJlcHJlc2VudGVkIGJ5IHRoZSBwZXItDQogICAg ZmxvdyBjb3VudGVyIElFcyAoZS5nLiwgcGFja2V0VG90YWxDb3VudCwgb2N0ZXRUb3RhbENvdW50 KS4gDQogIA0KICAgIEZvciBhY2NvdW50aW5nIHB1cnBvc2VzLCBpdCB3b3VsZCBiZSBhZHZhbnRh Z2VvdXMgdG8gaGF2ZSB0aGUgDQogICAgYWJpbGl0eSB0byB1c2UgSVBGSVggZmxvdyByZWNvcmRz IGFzIGFjY291bnRpbmcgaW5wdXQgaW4gYW4gQUFBIA0KICAgIGluZnJhc3RydWN0dXJlLiBBQUEg c2VydmVycyB0aGVuIGNvdWxkIHByb3ZpZGUgdGhlIG1hcHBpbmcgDQogICAgYmV0d2VlbiB1c2Vy IGFuZCBmbG93IGluZm9ybWF0aW9uLiBBZ2FpbiBmb3Igc3VjaCBzY2VuYXJpb3MgdGhlIA0KICAg IGxpbWl0ZWQgcmVsaWFiaWxpdHkgY3VycmVudGx5IHByb3ZpZGVkIGJ5IElQRklYIGhhcyB0byBi ZSB0YWtlbiANCiAgICBpbnRvIGFjY291bnQuIA0KICANCiAyLjEuMSBFeGFtcGxlIA0KICANCiAg ICBQbGVhc2Ugbm90ZTogQXMgbm90ZWQgaW4gW1JGQzMzMzBdIHRoZSBhZGRyZXNzIGJsb2NrIA0K ICAgIDE5Mi4wLjIuMC8yNCBtYXkgYmUgdXNlZCBmb3IgZXhhbXBsZSBhZGRyZXNzZXMuIEluIHRo ZSBleGFtcGxlIA0KICAgIGJlbG93IHdlIHVzZSB0d28gZXhhbXBsZSBuZXR3b3Jrcy4gSW4gb3Jk ZXIgdG8gYmUgY29uZm9ybWFudCB0byANCiAgICBbUkZDMzMzMF0gd2UgZGl2aWRlIHRoZSBnaXZl biBhZGRyZXNzIGJsb2NrIGludG8gdHdvIG5ldHdvcmtzIGJ5IA0KICAgIHN1Ym5ldHRpbmcgd2l0 aCBhIDI1IGJpdCBuZXRtYXNrICgxOTIuMC4yLjAvMjUpIGFzIGZvbGxvd3M6IA0KICAgICANCiAg ICBOZXR3b3JrIEE6IDE5Mi4wLjIuMCAuLi4gMTkyLjAuMi4xMjcgDQogICAgTmV0d29yayBCOiAx OTIuMC4yLjEyOCAuLi4gMTkyLjAuMi4yNTUgDQogIA0KICAgIExldCdzIHN1cHBvc2Ugc29tZW9u ZSBoYXMgYSBTZXJ2aWNlIExldmVsIEFncmVlbWVudCAoU0xBKSBpbiBhIA0KICAgIERpZmZTZXJ2 IG5ldHdvcmsgcmVxdWlyaW5nIGFjY291bnRpbmcgYmFzZWQgb24gdHJhZmZpYyB2b2x1bWUuIA0K ICAgIEZsb3dzIGFyZSBkaXN0aW5ndWlzaGVkIGJ5IHNvdXJjZSBhbmQgZGVzdGluYXRpb24gYWRk cmVzcy4gVGhlIA0KICAgIGluZm9ybWF0aW9uIHRvIGV4cG9ydCBpbiB0aGlzIGNhc2UgaXM6IA0K ICAgICAgICAtIElQdjQgc291cmNlIElQIGFkZHJlc3M6IHNvdXJjZUlQdjRBZGRyZXNzIGluIFtJ UEZJWC1JTkZPXSwgDQogICAgICAgICB3aXRoIGEgbGVuZ3RoIG9mIDQgb2N0ZXRzIA0KICAgICAg ICAtIElQdjQgZGVzdGluYXRpb24gSVAgYWRkcmVzczogZGVzdGluYXRpb25JUHY0QWRkcmVzcyBp biANCiAgICAgICAgIFtJUEZJWC1JTkZPXSwgd2l0aCBhIGxlbmd0aCBvZiA0IG9jdGV0cyANCiAg ICAgICAgLSBEU0NQOiBpcERpZmZTZXJ2Q29kZVBvaW50IGluIFtJUEZJWC1JTkZPXSwgd2l0aCBh IGxlbmd0aCBvZiANCiAgICAgICAgIDEgb2N0ZXQgDQogICAgICAgIC0gTnVtYmVyIG9mIG9jdGV0 cyBvZiB0aGUgRmxvdzogb2N0ZXREZWx0YUNvdW50IGluIFtJUEZJWC0NCiAgICAgICAgIElORk9d LCB3aXRoIGEgbGVuZ3RoIG9mIDQgb2N0ZXRzICANCiAgICAgICAgIA0KICAgIFRoZSB0ZW1wbGF0 ZSBzZXQgd2lsbCBsb29rIGFzIGZvbGxvd3M6ICANCiAgDQoNCg0KDQoNCg0KDQoNCg0KDQogWnNl YnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDVdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAg ICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICANCiAgICB8ICAgICAgICAg U2V0IElEID0gMiAgICAgICAgICAgIHwgICAgICBMZW5ndGggPSAyNCBvY3RldHMgICAgICAgfCAg IA0KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rICAgDQogICAgfCAgICAgICBUZW1wbGF0ZSBJRCAyNTYgICAgICAgICB8 ICAgICAgIEZpZWxkIENvdW50ID0gNCAgICAgICAgIHwgICANCiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgIA0KICAg IHwwfCAgICBzb3VyY2VJUHY0QWRkcmVzcyA9IDggICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSA0 ICAgICAgICB8ICAgDQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICANCiAgICB8MHwgZGVzdGluYXRpb25JUHY0QWRk cmVzcyA9IDEyIHwgICAgICAgRmllbGQgTGVuZ3RoID0gNCAgICAgICAgfCAgIA0KICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rICAgDQogICAgfDB8ICBpcERpZmZTZXJ2Q29kZVBvaW50ID0gMTk1ICB8ICAgICAgIEZpZWxk IExlbmd0aCA9IDEgICAgICAgIHwgICANCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgIA0KICAgIHwwfCAgICAgb2N0 ZXREZWx0YUNvdW50ID0gMSAgICAgfCAgICAgICBGaWVsZCBMZW5ndGggPSA0ICAgICAgICB8ICAN CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKyAgIA0KICAgICANCiAgICBUaGUgaW5mb3JtYXRpb24gdG8gYmUgZXhwb3J0 ZWQgbWlnaHQgYmUgYXMgbGlzdGVkIGluIHRoZSANCiAgICBmb2xsb3dpbmcgZXhhbXBsZSB0YWJs ZTogDQogICAgIA0KICAgIFNyYy4gSVAgYWRkci4gfCBEc3QuIElQIGFkZHIuIHwgIERTQ1AgIHwg T2N0ZXRzIE51bWJlciAgIA0KICAgIC0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0t LS0tLSstLS0tLS0tLS0tLS0tLSANCiAgICAxOTIuMC4yLjEyICAgIHwgIDE5Mi4wLjIuMTQ0ICB8 ICAgNDYgICB8ICAgMTIwODY4ICAgICAgICANCiAgICAxOTIuMC4yLjI0ICAgIHwgIDE5Mi4wLjIu MTU2ICB8ICAgNDYgICB8ICAgMzEwMzY0IA0KICAgIDE5Mi4wLjIuMzYgICAgfCAgMTkyLjAuMi4x NjggIHwgICA0NiAgIHwgICAyNDEyMzkgDQogICAgICAgICAgICANCiAgICBJbiB0aGUgZXhhbXBs ZSB3ZSB1c2UgRGlmZnNlcnYgQ29kZVBvaW50IDQ2LCByZWNvbW1lbmRlZCBmb3IgdGhlIA0KICAg IEV4cGVkaXRlZCBGb3J3YXJkaW5nIFBlciBIb3AgQmVoYXZpb3IgKEVGIFBIQikgaW4gW1JGQzI1 OThdLiANCiAgICAgDQogICAgVGhlIEZsb3cgUmVjb3JkcyB3aWxsIHRoZW4gbG9vayBhcyBmb2xs b3dzOiANCiAgICAgDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDZdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmls aXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMgIA0KICAgICAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgIA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgICAgICB8ICAgICAgICAgIFNldCBJRCA9 IDI1NiAgICAgICAgIHwgICAgICAgICAgTGVuZ3RoID0gNDMgICAgICAgICAgfCAgDQogICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgIA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIDE5Mi4wLjIuMTIg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICANCiAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAxOTIuMC4yLjE0NCAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgDQogICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgIA0KICAgICAgIHwgICAgICA0NiAgICAgICB8ICAg ICAgICAgICAgICAgMTIwODY4ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICANCiAgICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyAgDQogICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAxOTIuMC4y LjI0ICAgICAgICAgICAgICAgICAgICAgIHwgIA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rIA0KICAgICAgIHwg ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgMTkyLjAuMi4xNTYgICAgICAgICAgICAgICAg ICAgICB8ICANCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgIA0KICAgICAgIHwgICAgICAgICAgICAgICB8ICAg ICAgIDQ2ICAgICAgfCAgICAgICAgICAgICAgICAgMzEwMzY0ICAgICAgICB8ICANCiAgICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyAgDQogICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg ICAgMTkyLjAuMi4zNiAgICAgICAgICAgIHwgICANCiAgICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgDQogICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgMTkyLjAuMi4xNjggICAg ICAgICAgIHwgICANCiAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyANCiAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgNDYgICAgICB8ICAgICAgICAgICAgICAgfCAgDQogICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsgIA0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgMjQxMjM5ICAgICAgICAgICAg ICAgICAgICAgIHwgICAgIA0KICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsgIA0KICANCiAgMi4yIFRyYWZmaWMgUHJvZmlsaW5nICANCiAgICAg DQogICAgTWVhc3VyZW1lbnQgcmVzdWx0cyByZXBvcnRlZCBpbiBJUEZJWCByZWNvcmRzIGNhbiBi ZSB1c2VkIGZvciANCiAgICB0cmFmZmljIHByb2ZpbGluZy4gSVBGSVggcmVjb3JkcyBjYXB0dXJl ZCBvdmVyIGEgbG9uZyBwZXJpb2Qgb2YgDQogICAgdGltZSBjYW4gYmUgdXNlZCB0byB0cmFjayBh bmQgYW50aWNpcGF0ZSBuZXR3b3JrIGdyb3d0aCBhbmQgDQogICAgdXNhZ2UuIFN1Y2ggSW5mb3Jt YXRpb24gaXMgdmFsdWFibGUgZm9yIHRyZW5kIGFuYWx5c2lzIGFuZCANCiAgICBuZXR3b3JrIHBs YW5uaW5nLiANCiAgICAgDQogICAgVGhlIHBhcmFtZXRlcnMgb2YgaW50ZXJlc3QgYXJlIGRldGVy bWluZWQgYnkgdGhlIHByb2ZpbGluZyANCiAgICBvYmplY3RpdmVzLiBFeGFtcGxlIHBhcmFtZXRl cnMgZm9yIHRyYWZmaWMgcHJvZmlsaW5nIGFyZSBmbG93IA0KICAgIGR1cmF0aW9uLCBmbG93IHZv bHVtZSwgYnVyc3RpbmVzcywgdGhlIGRpc3RyaWJ1dGlvbiBvZiB1c2VkIA0KICAgIHNlcnZpY2Vz IGFuZCBwcm90b2NvbHMsIHRoZSBhbW91bnQgb2YgcGFja2V0cyBvZiBhIHNwZWNpZmljIA0KICAg IHR5cGUsIGV0Yy4gW1JGQzM5MTddLiAgDQogICAgIA0KICAgIFRoZSBkaXN0cmlidXRpb24gb2Yg c2VydmljZXMgYW5kIHByb3RvY29scyBpbiB1c2UgY2FuIGJlIA0KICAgIGFuYWx5emVkIGJ5IGNv bmZpZ3VyaW5nIGFwcHJvcHJpYXRlIGZsb3dzIGtleXMgZm9yIGZsb3cgDQogICAgZGlzY3JpbWlu YXRpb24uIFByb3RvY29scyBjYW4gYmUgZGlzdGluZ3Vpc2hlZCBieSB0aGUgDQogICAgcHJvdG9j b2xJZGVudGlmaWVyIElFLiBQb3J0bnVtYmVycyAoZS5nLiwgdWRwRGVzdGluYXRpb25Qb3J0KSAN CiAgICBvZnRlbiBwcm92aWRlIGluZm9ybWF0aW9uIGFib3V0IHNlcnZpY2VzIGluIHVzZS4gVGhv c2UgZmxvdyBrZXlzIA0KICAgIGFyZSBkZWZpbmVkIGluIFtJUEZJWC1JTkZPXS4gSWYgcG9ydG51 bWJlcnMgYXJlIG5vdCBzdWZmaWNpZW50IA0KICAgIGZvciBzZXJ2aWNlIGRpc2NyaW1pbmF0aW9u LCBmdXJ0aGVyIHBhcnRzIG9mIHRoZSBwYWNrZXQgbWF5IGJlIA0KICAgIG5lZWRlZC4gSGVhZGVy IGZpZWxkcyBjYW4gYmUgZXhwcmVzc2VkIGJ5IElFcyBmcm9tIFtJUEZJWC1JTkZPXSANCg0KDQoN Cg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA3XSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0 eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgIFBhY2tldCBwYXlsb2FkIGNhbiBi ZSByZXBvcnRlZCBieSB1c2luZyB0aGUgSUUgDQogICAgaXBQYXlsb2FkUGFja2V0U2VjdGlvbiBp biBbUFNBTVAtSU5GT10uIA0KICANCiAgICBUaGUgZmxvdyBkdXJhdGlvbiBjYW4gYmUgY2FsY3Vs YXRlZCBmcm9tIHRoZSBmbG93IHRpbWUgc3RhbXAgSUVzIA0KICAgIGRlZmluZWQgaW4gW0lQRklY LUlORk9dIChlLmcuLCBmbG93RW5kTWljcm9zZWNvbmRzIC0gDQogICAgZmxvd1N0YXJ0TWljcm9z ZWNvbmRzKS4gVGhlIG51bWJlciBvZiBwYWNrZXRzIGFuZCBudW1iZXIgb2YgDQogICAgYnl0ZXMg b2YgYSBmbG93IGFyZSByZXByZXNlbnRlZCBpbiB0aGUgcGVyLWZsb3cgY291bnRlciBJRXMgDQog ICAgKGUuZy4sIHBhY2tldFRvdGFsQ291bnQsIG9jdGV0VG90YWxDb3VudCkuIFRoZSBidXJzdGlu ZXNzIG9mIGEgDQogICAgZmxvdyBjYW4gYmUgY2FsY3VsYXRlZCBmcm9tIHRoZSBmbG93IHZvbHVt ZSBtZWFzdXJlZCBhdCANCiAgICBkaWZmZXJlbnQgdGltZSBpbnRlcnZhbHMuICANCiAgDQogIDIu MyBUcmFmZmljIEVuZ2luZWVyaW5nIA0KICAgICANCiAgICBUcmFmZmljIGVuZ2luZWVyaW5nIGFp bXMgYXQgdGhlIG9wdGltaXphdGlvbiBvZiBuZXR3b3JrIHJlc291cmNlIA0KICAgIHV0aWxpemF0 aW9uIGFuZCB0cmFmZmljIHBlcmZvcm1hbmNlIFtSRkMyNzAyXS4gVHlwaWNhbCANCiAgICBwYXJh bWV0ZXJzIGFyZSBsaW5rIHV0aWxpemF0aW9uLCBsb2FkIGJldHdlZW4gc3BlY2lmaWMgbmV0d29y aywgDQogICAgbm9kZXMsIG51bWJlciwgc2l6ZSBhbmQgZW50cnkvZXhpdCBwb2ludHMgb2YgYWN0 aXZlIGZsb3dzIGFuZCANCiAgICByb3V0aW5nIGluZm9ybWF0aW9uIFtSRkMzOTE3XS4gDQogICAg IA0KICAgIFNpemUgb2YgZmxvd3MgaW4gcGFja2V0cyBhbmQgYnl0ZXMgY2FuIGJlIHJlcG9ydGVk IGJ5IElFcyANCiAgICBwYWNrZXRUb3RhbENvdW50LCBvY3RldFRvdGFsQ291bnQuIFBoeXNpY2Fs IGxpbmsgdXRpbGl6YXRpb24gY2FuIA0KICAgIGJlIHJlcG9ydGVkIGJ5IHVzaW5nIGEgY29hcnNl IGdyYWluZWQgZmxvdyBkZWZpbml0aW9uIChlLmcuIA0KICAgIGJhc2VkIG9uIGlkZW50aWZpZXIg SUVzIHN1Y2ggYXMgZWdyZXNzSW50ZXJmYWNlIG9yIA0KICAgIGluZ3Jlc3NJbnRlcmZhY2UpIGFu ZCBwZXItZmxvdyBjb3VudGVyIElFcyAoZS5nLiANCiAgICBwYWNrZXRUb3RhbENvdW50LCBvY3Rl dFRvdGFsQ291bnQpIGRlZmluZWQgaW4gW0lQRklYLUlORk9dLiAgDQogICAgIA0KICAgIFRoZSBs b2FkIGJldHdlZW4gc3BlY2lmaWMgbmV0d29yayBub2RlcyBjYW4gYmUgcmVwb3J0ZWQgaW4gdGhl IA0KICAgIHNhbWUgd2F5IGlmIG9uZSBpbnRlcmZhY2Ugb2YgYSBuZXR3b3JrIG5vZGUgcmVjZWl2 ZXMgb25seSANCiAgICB0cmFmZmljIGZyb20gZXhhY3RseSBvbmUgbmVpZ2hib3Igbm9kZSAoYXMg aXMgdXN1YWxseSB0aGUgY2FzZSkuIA0KICAgIElmIHRoZSBpbmdyZXNzIGludGVyZmFjZSBpcyBu b3Qgc3VmZmljaWVudCBmb3IgYW4gdW5hbWJpZ3VvdXMgIA0KICAgIGlkZW50aWZpY2F0aW9uIG9m IHRoZSBuZWlnaGJvciBub2RlLCBzdWItSVAgaGVhZGVyIGZpZWxkcyBJRXMgDQogICAgKGxpa2Ug c291cmNlTWFjQWRkcmVzcykgY2FuIGJlIGFkZGVkIGFzIGZsb3cga2V5cy4gDQogIA0KICAgIFRo ZSBJRSBvYnNlcnZlZEZsb3dUb3RhbENvdW50IHByb3ZpZGVzIHRoZSBudW1iZXIgb2YgYWxsIGZs b3dzIA0KICAgIGV4cG9ydGVkIGZvciB0aGUgb2JzZXJ2YXRpb24gZG9tYWluIHNpbmNlIHRoZSBs YXN0IA0KICAgIGluaXRpYWxpemF0aW9uIG9mIHRoZSBtZXRlcmluZyBwcm9jZXNzIFtJUEZJWC1J TkZPXS4gSWYgdGhpcyBJRSANCiAgICBpcyBleHBvcnRlZCBhdCBzdWJzZXF1ZW50IHBvaW50cyBp biB0aW1lLCBvbmUgY2FuIGRlcml2ZSB0aGUgDQogICAgbnVtYmVyIG9mIGFjdGl2ZSBmbG93cyBp biBhIHNwZWNpZmljIHRpbWUgaW50ZXJ2YWwgZnJvbSB0aGUgDQogICAgZGlmZmVyZW5jZSBvZiB0 aGUgcmVwb3J0ZWQgY291bnRlcnMuIFRoZSBjb25maWd1cmVkIGZsb3cgDQogICAgdGVybWluYXRp b24gY3JpdGVyaWEgaGF2ZSB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQgdG8gaW50ZXJwcmV0IA0K ICAgIHRoYXQgbnVtYmVycyBjb3JyZWN0bHkuIA0KICANCiAgICBFbnRyeSBhbmQgZXhpdCBwb2lu dHMgY2FuIGJlIGRlcml2ZWQgZnJvbSBmbG93IHJlY29yZHMgaWYgDQogICAgbWV0ZXJpbmcgcHJv Y2Vzc2VzIGFyZSBpbnN0YWxsZWQgYXQgYWxsIGVkZ2VzIG9mIHRoZSBuZXR3b3JrIGFuZCANCiAg ICByZXN1bHRzIGFyZSBtYXBwZWQgaW4gYWNjb3JkYW5jZSB0byBmbG93IGtleXMuIEZvciB0aGlz IGFuZCANCiAgICBvdGhlciBhbmFseXNpcyBtZXRob2RzIHRoYXQgcmVxdWlyZSB0aGUgbWFwcGlu ZyBvZiByZWNvcmRzIGZyb20gDQogICAgZGlmZmVyZW50IG9ic2VydmF0aW9uIHBvaW50cywgdGhl IHNhbWUgZmxvdyBrZXlzIHNob3VsZCBiZSB1c2VkIA0KICAgIGF0IGFsbCBvYnNlcnZhdGlvbiBw b2ludHMuIFRoZSBwYXRoIHRoYXQgcGFja2V0cyB0YWtlIHRocm91Z2ggYSANCg0KDQoNCg0KIFpz ZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBb UGFnZSA4XSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAg ICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgIG5ldHdvcmsgY2FuIGJlIGludmVzdGlnYXRl ZCBieSB1c2luZyBoYXNoLWJhc2VkIHNhbXBsaW5nIA0KICAgIHRlY2huaXF1ZXMgYXMgZGVzY3Jp YmVkIGluIFtEdUdyMDBdIGFuZCBbUFNBTVAtVEVDSF0uIEZvciB0aGlzIA0KICAgIElFcyBmcm9t IFtQU0FNUC1JTkZPXSBhcmUgbmVlZGVkLiANCiAgDQogICAgTmVpdGhlciBbSVBGSVgtSU5GT10g bm9yIFtQU0FNUC1JTkZPXSBkZWZpbmVzIElFcyBzdWl0YWJsZSBmb3IgDQogICAgZXhwb3J0aW5n IHJvdXRpbmcgaW5mb3JtYXRpb24uIA0KICAgICANCiAgMi40IE5ldHdvcmsgU2VjdXJpdHkgDQog ICAgIA0KICAgIEF0dGFjayBhbmQgaW50cnVzaW9uIGRldGVjdGlvbiBhcmUgYW1vbmcgdGhlIElQ RklYIHRhcmdldCANCiAgICBhcHBsaWNhdGlvbnMgZGVzY3JpYmVkIGluIFtSRkMzOTE3XS4gRHVl IHRvIHRoZSBlbm9ybW91cyBhbW91bnQgDQogICAgb2YgZGlmZmVyZW50IG5ldHdvcmsgYXR0YWNr IHR5cGVzLCBvbmx5IGdlbmVyYWwgcmVxdWlyZW1lbnRzIA0KICAgIGNvdWxkIGJlIGFkZHJlc3Nl ZCBpbiBbUkZDMzkxN10uIA0KICANCiAgICBJUEZJWCBjYW4gZXhwb3J0IGZsb3cgaW5mb3JtYXRp b24gZm9yIGFyYml0cmFyeSBmbG93IGRlZmluaXRpb25zIA0KICAgIGFzIGRlZmluZWQgaW4gW0lQ RklYLVBST1RPXS4gUGFja2V0IGluZm9ybWF0aW9uIGNhbiBiZSBleHBvcnRlZCANCiAgICB3aXRo IElQRklYIGJ5IHVzaW5nIHRoZSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGVsZW1lbnRzIA0KICAg IGRlc2NyaWJlZCBpbiBbUFNBTVAtSU5GT10uIFdpdGggdGhpcyB0aGVvcmV0aWNhbGx5IGFsbCAN CiAgICBpbmZvcm1hdGlvbiBhYm91dCB0cmFmZmljIGluIHRoZSBuZXR3b3JrIGF0IElQIGxheWVy IGFuZCBhYm92ZSANCiAgICBpcyBhY2Nlc3NpYmxlLiBUaGlzIGRhdGEgY2FuIGJlIHVzZWQgZWl0 aGVyIGRpcmVjdGx5IHRvIGRldGVjdCANCiAgICBhbm9tYWxpZXMgb3IgY2FuIHByb3ZpZGUgdGhl IGJhc2lzIGZvciBmdXJ0aGVyIHBvc3QgcHJvY2Vzc2luZyANCiAgICB0byBnZW5lcmF0ZSBtb3Jl IGNvbXBsZXggYXR0YWNrIGRldGVjdGlvbiBtZXRyaWNzLiAgDQogICAgIA0KICAgIERlcGVuZGlu ZyBvbiB0aGUgYXR0YWNrIHR5cGUgZGlmZmVyZW50IG1ldHJpY3MgYXJlIHVzZWZ1bC4gQSANCiAg ICBzdWRkZW4gaW5jcmVhc2Ugb2YgdHJhZmZpYyBsb2FkIGNhbiBiZSBhIGhpbnQgdGhhdCBhbiBh dHRhY2sgaGFzIA0KICAgIGJlZW4gbGF1bmNoZWQuIFRoZSBvdmVyYWxsIHRyYWZmaWMgYXQgYW4g b2JzZXJ2YXRpb24gcG9pbnQgY2FuIA0KICAgIGJlIG1vbml0b3JlZCB1c2luZyBwZXItZmxvdyBj b3VudGVyIElFcyBsaWtlIHBhY2tldFRvdGFsQ291bnQsIA0KICAgIG9jdGV0VG90YWxDb3VudCBh cyBkZXNjcmliZWQgaW4gMi4zLiBUaGUgbnVtYmVyIG9mIGFjdGl2ZSBmbG93cyANCiAgICBjYW4g YmUgbW9uaXRvcmVkIGJ5IHJlZ3VsYXIgcmVwb3J0aW5nIG9mIHRoZSANCiAgICBvYnNlcnZlZEZs b3dUb3RhbENvdW50LiANCiAgICAgDQogICAgQSBzdWRkZW4gaW5jcmVhc2Ugb2YgZmxvd3MgZnJv bSBkaWZmZXJlbnQgc291cmNlcyB0byBvbmUgDQogICAgZGVzdGluYXRpb24gbWF5IGJlIGNhdXNl ZCBieSBhbiBhdHRhY2sgb24gYSBzcGVjaWZpYyBob3N0IG9yIA0KICAgIG5ldHdvcmsgbm9kZSB1 c2luZyBzcG9vZmVkIGFkZHJlc3Nlcy4gTWFueSBmbG93cyB0byB0aGUgc2FtZSANCiAgICBtYWNo aW5lIGJ1dCBvbiBkaWZmZXJlbnQgcG9ydHMgb3IgbWFueSBmbG93cyB0byB0aGUgc2FtZSBwb3J0 IA0KICAgIGFuZCBkaWZmZXJlbnQgbWFjaGluZXMgbWF5IGJlIGFuIGluZGljYXRvciBmb3IgdmVy dGljYWwgb3IgDQogICAgaG9yaXpvbnRhbCBwb3J0IHNjYW5uaW5nIGFjdGl2aXRpZXMuIEFuIHVu dXN1YWwgcmF0aW8gb2YgVENQLVNZTiANCiAgICB0byBUQ1AtRklOIHBhY2tldHMgY2FuIHJlZmVy IHRvIFNZTi1mbG9vZGluZy4gV29ybXMgbWF5IGxlYXZlIA0KICAgIHNpZ25hdHVyZXMgaW4gdHJh ZmZpYyBwYXR0ZXJucy4gRGV0ZWN0aW5nIHN1Y2ggZXZlbnRzIHJlcXVpcmVzIA0KICAgIG1vcmUg ZGV0YWlsZWQgbWVhc3VyZW1lbnRzIGFuZCBwb3N0IHByb2Nlc3NpbmcgdGhhbiBkZXRlY3Rpbmcg DQogICAgc2ltcGxlIGNoYW5nZXMgaW4gdHJhZmZpYyB2b2x1bWVzICAgDQogIA0KICAgIFRoZSBh bW91bnQgb2YgbWV0cmljcyB1c2VmdWwgZm9yIGF0dGFjayBkZXRlY3Rpb24gaXMgYXMgZGl2ZXJz ZSANCiAgICBhcyBhdHRhY2sgcGF0dGVybnMgdGhlbXNlbHZlcy4gQXR0YWNrZXJzIGFkYXB0IHJh cGlkbHkgdG8gDQogICAgY2lyY3VtdmVudCBkZXRlY3Rpb24gbWV0aG9kcyBhbmQgdHJ5IHRvIGhp ZGUgYXR0YWNrIHBhdHRlcm5zIA0KICAgIHVzaW5nIHNsb3cgb3Igc3RlYWx0aCBhdHRhY2tzLiBG dXJ0aGVybW9yZSwgdW51c3VhbCB0cmFmZmljIA0KICAgIHBhdHRlcm5zIGFyZSBub3QgYWx3YXlz IGNhdXNlZCBieSBtYWxpY2lvdXMgYWN0aXZpdGllcy4gQSBzdWRkZW4gDQogICAgdHJhZmZpYyBp bmNyZWFzZSBtYXkgYmUgY2F1c2VkIGJ5IGxlZ2l0aW1hdGUgdXNlcnMgd2hvIHNlZWsgDQoNCg0K DQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAg ICAgICAgW1BhZ2UgOV0gDQoMICAgICAgICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxp dHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAgICBhY2Nlc3MgdG8gYSByZWNlbnRs eSBwdWJsaXNoZWQgY29udGVudC4gU3RyYW5nZSB0cmFmZmljIHBhdHRlcm5zIA0KICAgIG1heSBh bHNvIGJlIGNhdXNlZCBieSBtaXMtY29uZmlndXJhdGlvbi4gIA0KICAgICANCiAgICBUaGUgZGlm ZmljdWx0IHRhc2sgaXMgdGhlIHNlcGFyYXRpb24gb2YgZ29vZCBmcm9tIGJhZCBwYWNrZXRzIHRv IA0KICAgIHByZXBhcmUgYW5kIGxhdW5jaCBjb3VudGVyYWN0aW9uLiBUaGlzIG1heSByZXF1aXJl IGEgZGVlcGVyIGxvb2sgDQogICAgaW50byBwYWNrZXQgY29udGVudCBieSB1c2luZyBmdXJ0aGVy IGhlYWRlciBmaWVsZCBJRXMgZnJvbSANCiAgICBbSVBGSVgtSU5GT10gYW5kL29yIHBhY2tldCBw YXlsb2FkIGZyb20gSUUgDQogICAgaXBQYXlsb2FkUGFja2V0U2VjdGlvbiBpbiBbUFNBTVAtSU5G T10uIE11bHRpLXN0ZXAgYW5hbHlzaXMgDQogICAgdGVjaG5pcXVlcyBtYXkgYmUgdXNlZnVsLCBl LmcuLCB0byBsYXVuY2ggYW4gaW4tZGVwdGggYW5hbHlzaXMgDQogICAgKGUuZy4gYmFzZWQgb24g cGFja2V0IGluZm9ybWF0aW9uKSBpbiBjYXNlIHRoZSBmbG93IGluZm9ybWF0aW9uIA0KICAgIHNo b3dzIHN1c3BpY2lvdXMgcGF0dGVybnMuIEluIG9yZGVyIHRvIHN1cGVydmlzZSB0cmFmZmljIHRv IGEgDQogICAgc3BlY2lmaWMgaG9zdCBvciBuZXR3b3JrIG5vZGUgb25lIGhhcyB0byBhcHBseSBm aWx0ZXJpbmcgbWV0aG9kcyANCiAgICBhcyB0aG9zZSBkZXNjcmliZWQgaW4gW1BTQU1QLVRFQ0hd LiANCiAgDQogICAgTWFwcGluZyB0aGUgdHdvIGRpcmVjdGlvbnMgb2YgYSBjb21tdW5pY2F0aW9u IGlzIG9mdGVuIHVzZWZ1bCANCiAgICBmb3IgY2hlY2tpbmcgY29ycmVjdCBwcm90b2NvbCBiZWhh dmlvciAoc2VlIHNlY3Rpb24gNC42KS4gQSANCiAgICBjb3JyZWxhdGlvbiBvZiBJUEZJWCBkYXRh IGZyb20gbXVsdGlwbGUgb2JzZXJ2YXRpb24gcG9pbnRzIChzZWUgDQogICAgc2VjdGlvbiAyLjUu MSkgYWxsb3dzIGFzc2Vzc2luZyB0aGUgcHJvcGFnYXRpb24gb2YgYW4gYXR0YWNrIGFuZCANCiAg ICBjYW4gaGVscCB0byBsb2NhdGUgaXRzIHNvdXJjZS4gIA0KICAgICANCiAgICBUaGUgaW50ZWdy YXRpb24gb2YgcHJldmlvdXMgbWVhc3VyZW1lbnQgcmVzdWx0cyBoZWxwcyB0byByZXZpZXcgDQog ICAgdHJhZmZpYyBjaGFuZ2VzIG92ZXIgdGltZSBmb3IgZGV0ZWN0aW9uIG9mIHRyYWZmaWMgYW5v bWFsaWVzIGFuZCANCiAgICBwcm92aWRlcyB0aGUgYmFzaXMgZm9yIGZvcmVuc2ljIGFuYWx5c2lz LiBBIHN0YW5kYXJkaXplZCBzdG9yYWdlIA0KICAgIGZvcm1hdCBmb3IgSVBGSVggZGF0YSB3b3Vs ZCBzdXBwb3J0IHRoZSBvZmZsaW5lIGFuYWx5c2lzIG9mIGRhdGEgDQogICAgZnJvbSBkaWZmZXJl bnQgb3BlcmF0b3JzLiANCiAgICAgDQogICAgTmV2ZXJ0aGVsZXNzLCBjYXB0dXJpbmcgZnVsbCBw YWNrZXQgdHJhY2VzIGF0IGFsbCBvYnNlcnZhdGlvbiANCiAgICBwb2ludHMgaW4gdGhlIG5ldHdv cmsgaXMgbm90IHZpYWJsZSBkdWUgdG8gcmVzb3VyY2UgbGltaXRhdGlvbnMgDQogICAgYW5kIHBy aXZhY3kgY29uY2VybnMuIFRoZXJlZm9yZSBtZXRyaWNzIHNob3VsZCBiZSBjaG9zZW4gd2lzZWx5 IA0KICAgIHRvIGFsbG93IGEgc29saWQgZGV0ZWN0aW9uIHdpdGggbWluaW1hbCByZXNvdXJjZSBj b25zdW1wdGlvbi4gDQogICAgUmVzb3VyY2VzIGNhbiBiZSBzYXZlZCBmb3IgaW5zdGFuY2UgYnkg dXNpbmcgY29hcnNlciBncmFpbmVkIA0KICAgIGZsb3cgZGVmaW5pdGlvbnMsIHJlcG9ydGluZyBw cmUtcHJvY2Vzc2VkIG1ldHJpY3MgKGUuZy4gd2l0aCANCiAgICBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIGVsZW1lbnRzKSBvciBkZXBsb3ltZW50IG9mIHNhbXBsaW5nIA0KICAgIG1ldGhvZHMuIA0K ICANCiAgICBEZXRlY3Rpbmcgc2VjdXJpdHkgaW5jaWRlbnRzIGluIHJlYWwtdGltZSBvZnRlbiBy ZXF1aXJlcyB0aGUgDQogICAgcHJlLXByb2Nlc3Npbmcgb2YgZGF0YSBhbHJlYWR5IGF0IHRoZSBt ZWFzdXJlbWVudCBkZXZpY2UuIFRoYXQgDQogICAgbWVhbnMgdGhhdCBtZWFzdXJlZCBkYXRhIG5l ZWQgdG8gYmUgcHJvY2Vzc2VkIGFscmVhZHkgaW4gdGhlIA0KICAgIG1lYXN1cmVtZW50IGRldmlj ZSBpbiBvcmRlciB0byBnZW5lcmF0ZSB1c2VmdWwgbWV0cmljcyBmb3IgDQogICAgZGV0ZWN0aW5n IGFuIGF0dGFjayBhcyBlYXJseSBhcyBwb3NzaWJsZS4gSW1tZWRpYXRlIGRhdGEgZXhwb3J0IA0K ICAgIGluIGNhc2Ugb2YgYSBwb3RlbnRpYWwgaW5jaWRlbnQgaXMgZGVzaXJlZC4gSVBGSVggc3Vw cG9ydHMgc3VjaCANCiAgICBzb3VyY2UtdHJpZ2dlcmVkIGV4cG9ydGluZyBvZiBpbmZvcm1hdGlv biBkdWUgdG8gdGhlIHB1c2ggbW9kZWwgDQogICAgYXBwcm9hY2guIE5ldmVydGhlbGVzcywgZnVy dGhlciBleHBvcnRpbmcgY3JpdGVyaWEgaGF2ZSB0byBiZSANCiAgICBpbXBsZW1lbnRlZCB0byBl eHBvcnQgSVBGSVggcmVjb3JkcyB1cG9uIGluY2lkZW50IGRldGVjdGlvbiANCiAgICBldmVudHMg YW5kIG5vdCBvbmx5IHVwb24gZmxvdyBlbmQgb3IgZml4ZWQgdGltZSBpbnRlcnZhbHMuIA0KICAg ICANCiAgICBTZWN1cml0eSBpbmNpZGVudHMgY2FuIGJlY29tZSBhIHRocmVhdCB0byBJUEZJWCBw cm9jZXNzZXMgDQogICAgdGhlbXNlbHZlcyAoc2VlIGFsc28gc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgaW4gW0lQRklYLVBST1RPXSkuIA0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUs IENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEwXSANCgwgICAgICAgICAg ICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0K DQoNCg0KICAgIElmIGFuIGF0dGFjayBnZW5lcmF0ZXMgYSBsYXJnZSBhbW91bnQgb2YgZmxvd3Mg KGUuZy4gYnkgc2VuZGluZyANCiAgICBwYWNrZXRzIHdpdGggc3Bvb2ZlZCBhZGRyZXNzZXMgb3Ig c2ltdWxhdGluZyBmbG93IHRlcm1pbmF0aW9uKSANCiAgICBleHBvcnRpbmcgYW5kIGNvbGxlY3Rp bmcgcHJvY2VzcyBtYXkgZ2V0IG92ZXJsb2FkZWQgYnkgdGhlIA0KICAgIGltbWVuc2UgYW1vdW50 IG9mIHJlY29yZHMgdGhhdCBhcmUgZXhwb3J0ZWQuIEEgZmxleGlibGUgDQogICAgZGVwbG95bWVu dCBvZiBwYWNrZXQgb3IgZmxvdyBzYW1wbGluZyBtZXRob2RzIGNhbiBwcmV2ZW50IHRoZSANCiAg ICBleGhhdXN0aW9uIG9mIHJlc291cmNlcy4gICAgDQogICAgIA0KICAgIEludHJ1c2lvbiBkZXRl Y3Rpb24gd291bGQgcHJvZml0IGZyb20gdGhlIGNvbWJpbmF0aW9uIG9mIElQRklYIA0KICAgIGZ1 bmN0aW9ucyB3aXRoIEFBQSBmdW5jdGlvbnMgKHNlZSBzZWN0aW9uIDMuNCkuIFN1Y2ggYW4gDQog ICAgaW50ZXJvcGVyYXRpb24gZW5hYmxlcyBmdXJ0aGVyIG1lYW5zIGZvciBhdHRhY2tlciBkZXRl Y3Rpb24sIA0KICAgIGFkdmFuY2VkIGRlZmVuc2Ugc3RyYXRlZ2llcyBhbmQgc2VjdXJlIGludGVy LWRvbWFpbiBjb29wZXJhdGlvbi4gDQogIA0KICAyLjUgUW9TIE1vbml0b3JpbmcgDQogICAgIA0K ICAgIFFvUyBtb25pdG9yaW5nIGlzIG9uZSB0YXJnZXQgYXBwbGljYXRpb24gb2YgdGhlIElQRklY IHByb3RvY29sIA0KICAgIFtSRkMzOTE3XS4gUW9TIG1vbml0b3JpbmcgaXMgdGhlIHBhc3NpdmUg b2JzZXJ2YXRpb24gb2YgdGhlIA0KICAgIHRyYW5zbWlzc2lvbiBxdWFsaXR5IGZvciBzaW5nbGUg Zmxvd3Mgb3IgdHJhZmZpYyBhZ2dyZWdhdGVzIGluIA0KICAgIHRoZSBuZXR3b3JrLiBPbmUgZXhh bXBsZSBvZiBpdHMgdXNlIGlzIHRoZSB2YWxpZGF0aW9uIG9mIFFvUyANCiAgICBndWFyYW50ZWVz IGluIHNlcnZpY2UgbGV2ZWwgYWdyZWVtZW50cyAoU0xBcykuIFR5cGljYWwgUW9TIA0KICAgIHBh cmFtZXRlcnMgYXJlIGxvc3MgW1JGQzI2ODBdLCBvbmUtd2F5IFtSRkMyNjc5XSBhbmQgcm91bmQt dHJpcCANCiAgICBkZWxheSBbUkZDMjY4MV0gYW5kIGRlbGF5IHZhcmlhdGlvbiBbUkZDMzM5M10u IFRoZSBjYWxjdWxhdGlvbiANCiAgICBvZiB0aG9zZSBRb1MgbWV0cmljcyByZXF1aXJlcyBwZXIt cGFja2V0IHByb2Nlc3NpbmcuIFJlcG9ydGluZyANCiAgICBwYWNrZXQgaW5mb3JtYXRpb24gd2l0 aCBJUEZJWCBpcyBwb3NzaWJsZSBieSBzaW1wbHkgY29uc2lkZXJpbmcgDQogICAgYSBzaW5nbGUg cGFja2V0IGFzIGZsb3cuIFtJUEZJWC1QUk9UT10gYWxzbyBhbGxvd3MgdGhlIHJlcG9ydGluZyAN CiAgICBvZiBtdWx0aXBsZSBpZGVudGljYWwgaW5mb3JtYXRpb24gZWxlbWVudHMgaW4gb25lIGZs b3cgcmVjb3JkLiANCiAgICBVc2luZyB0aGlzIGZlYXR1cmUgZm9yIHJlcG9ydGluZyBpbmZvcm1h dGlvbiBhYm91dCBtdWx0aXBsZSANCiAgICBwYWNrZXRzIGluIG9uZSByZWNvcmQgd291bGQgcmVx dWlyZSBhZGRpdGlvbmFsIGFncmVlbWVudCBvbiANCiAgICBzZW1hbnRpY3MgcmVnYXJkaW5nIHRo ZSBvcmRlciBvZiBpbmZvcm1hdGlvbiBlbGVtZW50cyAoZS5nLiANCiAgICB3aGljaCB0aW1lc3Rh bXAgYmVsb25ncyB0byB3aGljaCBwYWNrZXQgcGF5bG9hZCBpbiBhIHNlcXVlbmNlIG9mIA0KICAg IGluZm9ybWF0aW9uIGVsZW1lbnRzKS4gW1BTQU1QLUlORk9dIGRlZmluZXMgdXNlZnVsIGFkZGl0 aW9uYWwgDQogICAgaW5mb3JtYXRpb24gZWxlbWVudHMgZm9yIGV4cG9ydGluZyBwZXIgcGFja2V0 IGluZm9ybWF0aW9uIHdpdGggDQogICAgSVBGSVguICANCiAgICAgDQogMi41LjEgQ29ycmVsYXRp bmcgRXZlbnRzIGZyb20gTXVsdGlwbGUgT2JzZXJ2YXRpb24gUG9pbnRzIA0KICAgICANCiAgICBT b21lIFFvUyBtZXRyaWNzIHJlcXVpcmUgdGhlIGNvcnJlbGF0aW9uIG9mIGRhdGEgZnJvbSBtdWx0 aXBsZSANCiAgICBvYnNlcnZhdGlvbiBwb2ludHMuIEZvciB0aGlzIHRoZSBjbG9ja3Mgb2YgdGhl IGludm9sdmVkIG1ldGVyaW5nIA0KICAgIHByb2Nlc3NlcyBtdXN0IGJlIHN5bmNocm9uaXplZC4g RnVydGhlcm1vcmUsIGl0IGlzIG5lY2Vzc2FyeSB0byANCiAgICByZWNvZ25pemUgdGhhdCB0aGUg c2FtZSBwYWNrZXQgd2FzIG9ic2VydmVkIGF0IGRpZmZlcmVudCANCiAgICBvYnNlcnZhdGlvbiBw b2ludC4gDQogICAgIA0KICAgIFRoaXMgY2FuIGJlIGRvbmUgYnkgY2FwdHVyaW5nIHBhcnRzIG9m IHRoZSBwYWNrZXQgY29udGVudCANCiAgICAocGFja2V0IGhlYWRlciBhbmQvb3IgcGFydHMgb2Yg dGhlIHBheWxvYWQpIHRoYXQgZG8gbm90IGNoYW5nZSANCiAgICBvbiB0aGUgd2F5IHRvIHRoZSBk ZXN0aW5hdGlvbi4gQmFzZWQgb24gdGhlIHBhY2tldCBjb250ZW50IGl0IA0KICAgIGNhbiBiZSBy ZWNvZ25pemVkIHdoZW4gdGhlIHNhbWUgcGFja2V0IGFycml2ZWQgYXQgYW5vdGhlciANCiAgICBv YnNlcnZhdGlvbiBwb2ludC4gVG8gcmVkdWNlIHRoZSBhbW91bnQgb2YgbWVhc3VyZW1lbnQgZGF0 YSBhIA0KICAgIHVuaXF1ZSBwYWNrZXQgSUQgY2FuIGJlIGNhbGN1bGF0ZWQgZnJvbSB0aGUgcGFj a2V0IGNvbnRlbnQgZS5nLiANCiAgICBieSB1c2luZyBhIENSQyBvciBoYXNoIGZ1bmN0aW9uIGlu c3RlYWQgb2YgdHJhbnNmZXJyaW5nIGFuZCANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3du bGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMV0gDQoMICAgICAg ICAgICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAw NiANCg0KDQoNCiAgICBjb21wYXJpbmcgdGhlIHVucHJvY2Vzc2VkIGNvbnRlbnQuIENvbnNpZGVy YXRpb25zIG9uIGNvbGxpc2lvbiANCiAgICBwcm9iYWJpbGl0eSBhbmQgZWZmaWNpZW5jeSBvZiB1 c2luZyBzdWNoIHBhY2tldCBJRHMgYXJlIA0KICAgIGRlc2NyaWJlZCBpbiBbR3JETTk4LCBEdUdy MDAsIFpzWkMwMV0uIA0KICAgICANCiAgICBJUEZJWCBhbGxvd3MgdGhlIHJlcG9ydGluZyBvZiBz ZXZlcmFsIElQIGFuZCB0cmFuc3BvcnQgaGVhZGVyIA0KICAgIGZpZWxkcyAoc2VlIHNlY3Rpb24g NS4zIGFuZCA1LjQgaW4gW0lQRklYLUlORk9dKS4gVXNpbmcgb25seSANCiAgICB0aG9zZSBmaWVs ZHMgZm9yIHBhY2tldCByZWNvZ25pdGlvbiBvciBJRCBnZW5lcmF0aW9uIGNhbiBiZSANCiAgICBz dWZmaWNpZW50IGluIHNjZW5hcmlvcyB3aGVyZSB0aG9zZSBoZWFkZXIgZmllbGRzIHZhcnkgYSBs b3QgDQogICAgYW1vbmcgc3Vic2VxdWVudCBwYWNrZXRzLCB3aGVyZSBhIGNlcnRhaW4gYW1vdW50 IG9mIHBhY2tldCBJRCANCiAgICBjb2xsaXNpb25zIGlzIHRvbGVyYWJsZSBvciB3aGVyZSBwYWNr ZXQgSURzIG5lZWQgdG8gYmUgdW5pcXVlIA0KICAgIG9ubHkgZm9yIGEgc21hbGwgdGltZSBpbnRl cnZhbC4gDQogICAgIA0KICAgIEZvciBpbmNsdWRpbmcgcGFja2V0IHBheWxvYWQgaW5mb3JtYXRp b24gdGhlIGluZm9ybWF0aW9uIGVsZW1lbnQgDQogICAgaXBQYXlsb2FkUGFja2V0U2VjdGlvbiBk ZWZpbmVkIGluIFtQU0FNUC1JTkZPXSBjYW4gYmUgdXNlZC4gVGhlIA0KICAgIGluZm9ybWF0aW9u IGVsZW1lbnQgaXBIZWFkZXJQYWNrZXRTZWN0aW9uIGNhbiBhbHNvIGJlIHVzZWQuIEJ1dCANCiAg ICBoZWFkZXIgZmllbGRzIHRoYXQgY2FuIGNoYW5nZSBvbiB0aGUgd2F5IGZyb20gc291cmNlIHRv IA0KICAgIGRlc3RpbmF0aW9uIGhhdmUgdG8gYmUgZXhjbHVkZWQgZnJvbSB0aGUgcGFja2V0IElE IGdlbmVyYXRpb24sIA0KICAgIGJlY2F1c2UgdGhleSBtYXkgZGlmZmVyIGF0IGRpZmZlcmVudCBv YnNlcnZhdGlvbiBwb2ludHMuICANCiAgICAgDQogICAgRm9yIHJlcG9ydGluZyBwYWNrZXQgSURz IGdlbmVyYXRlZCBieSBhIENSQyBvciBoYXNoIGZ1bmN0aW9uIHRoZSANCiAgICBpbmZvcm1hdGlv biBlbGVtZW50IGRpZ2VzdEhhc2hWYWx1ZSBkZWZpbmVkIGluIFtQU0FNUC1JTkZPXSBjYW4gDQog ICAgYmUgdXNlZC4gDQogICAgIA0KIDIuNS4yIEV4YW1wbGVzIA0KICANCiAgICBUaGUgZm9sbG93 aW5nIGV4YW1wbGVzIHNob3cgd2hpY2ggaW5mb3JtYXRpb24gZWxlbWVudHMgbmVlZCB0byANCiAg ICBiZSByZXBvcnRlZCBieSBJUEZJWCB0byBnZW5lcmF0ZSBzcGVjaWZpYyBRb1MgbWV0cmljcy4g QXMgYW4gDQogICAgYWx0ZXJuYXRpdmUgdGhlIG1ldHJpY3MgY2FuIGJlIGdlbmVyYXRlZCBkaXJl Y3RseSBhdCB0aGUgDQogICAgZXhwb3J0ZXIgYW5kIElQRklYIGNhbiBiZSB1c2VkIHRvIGV4cG9y dCB0aGUgbWV0cmljcyAoc2VlIA0KICAgIHNlY3Rpb24gMi43KSANCiAgDQogMi41LjIuMSBSVFQg bWVhc3VyZW1lbnRzIHdpdGggcGFja2V0IHBhaXIgbWF0Y2hpbmcgKHNpbmdsZS1wb2ludCkgDQog ICAgIA0KICAgIFRoZSBwYXNzaXZlIG1lYXN1cmVtZW50IG9mIHJvdW5kLXRyaXAtdGltZXMgKFJU VCkgY2FuIGJlIA0KICAgIHBlcmZvcm1lZCBieSB1c2luZyBwYWNrZXQgcGFpciBtYXRjaGluZyB0 ZWNobmlxdWVzIGFzIGRlc2NyaWJlZCANCiAgICBpbiBbQnJvdzAwXS4gRm9yIHRoZSBtZWFzdXJl bWVudHMsIHJlcXVlc3QvcmVzcG9uc2UgcGFja2V0IHBhaXJzIA0KICAgIGZyb20gcHJvdG9jb2xz IHN1Y2ggYXMgRE5TLCBJQ01QLCBTTk1QIG9yIFRDUCAoU1lOL1NZTl9BQ0ssIA0KICAgIERBVEEv QUNLKSBhcmUgdXRpbGl6ZWQgdG8gcGFzc2l2ZWx5IG9ic2VydmUgdGhlIFJUVCBbQnJvdzAwXS4g DQogICAgVGhpcyB0ZWNobmlxdWUgcmVxdWlyZXMgdGhlIGNvcnJlbGF0aW9uIG9mIGRhdGEgZnJv bSBib3RoIA0KICAgIGRpcmVjdGlvbnMuIA0KICAgICANCiAgICBSZXF1aXJlZCBpbmZvcm1hdGlv biBlbGVtZW50cyBwZXIgcGFja2V0IChETlMgZXhhbXBsZSk6ICANCiAgICAtIFBhY2tldCBhcnJp dmFsIHRpbWU6IG9ic2VydmF0aW9uVGltZU1pY3Jvc2Vjb25kcyBbUFNBTVAtSU5GT10gIA0KICAg IC0gRE5TIGhlYWRlcjogaXBQYXlsb2FkUGFja2V0U2VjdGlvbiBbUFNBTVAtSU5GT10gDQogICAg IA0KICAgIFJlcXVpcmVkIGZ1bmN0aW9uczogIA0KICAgIC0gUmVjb2duaXRpb24gb2YgcmVxdWVz dC9yZXNwb25zZSBwYWNrZXQgcGFpcnMgDQogICAgIA0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwg QnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXSANCgwg ICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVu ZSAyMDA2IA0KDQoNCg0KICAgIFJlbWFya3M6IA0KICAgIC0gUmVxdWlyZXMgaW5mb3JtYXRpb24g ZWxlbWVudHMgZnJvbSBbUFNBTVAtSU5GT10gDQogICAgLSBvYnNlcnZhdGlvblRpbWVNaWNyb3Nl Y29uZHMgY2FuIGJlIHN1YnN0aXR1dGVkIGJ5IA0KICAgICAgIGZsb3dTdGFydE1pY3Jvc2Vjb25k cyBbSVBGSVgtSU5GT10sIGJlY2F1c2UgYSBzaW5nbGUgcGFja2V0IA0KICAgICAgIGNhbiBiZSBy ZXByZXNlbnRlZCBhcyBhIGZsb3cuIA0KICAgIC0gSWYgdGltZSB2YWx1ZXMgd2l0aCBhIGZpbmVy IGdyYW51bGFyaXR5IGFyZSBuZWVkZWQgDQogICAgICAgb2JzZXJ2YXRpb25UaW1lTmFub3NlY29u ZHMgY2FuIGJlIHVzZWQuIA0KICANCiAyLjUuMi4yIE9uZS13YXkgRGVsYXkgTWVhc3VyZW1lbnRz IChtdWx0aS1wb2ludCkgDQogIA0KICAgIFBhc3NpdmUgb25lLXdheS1kZWxheSBtZWFzdXJlbWVu dHMgcmVxdWlyZSB0aGUgY29sbGVjdGlvbiBvZiANCiAgICBkYXRhIGF0IHR3byBvYnNlcnZhdGlv biBwb2ludHMuIEFzIG1lbnRpb25lZCBhYm92ZSBzeW5jaHJvbml6ZWQgDQogICAgY2xvY2tzIGFy ZSBuZWVkZWQgdG8gYXZvaWQgdGltZS1kaWZmZXJlbmNlcyBhdCB0aGUgaW52b2x2ZWQgDQogICAg b2JzZXJ2YXRpb24gcG9pbnRzLiAgDQogICAgIA0KICAgIFRoZSByZWNvZ25pdGlvbiBvZiBwYWNr ZXRzIGF0IHRoZSBzZWNvbmQgb2JzZXJ2YXRpb24gcG9pbnQgY2FuIA0KICAgIGJlIGJhc2VkIG9u IHBhcnRzIG9mIHRoZSBwYWNrZXQgY29udGVudCBkaXJlY3RseS4gQSBtb3JlIA0KICAgIGVmZmlj aWVudCB3YXkgaXMgdG8gdXNlIGEgcGFja2V0IElEIChnZW5lcmF0ZWQgZnJvbSBwYWNrZXQgDQog ICAgY29udGVudCkuIA0KICAgICANCiAgICBSZXF1aXJlZCBpbmZvcm1hdGlvbiBlbGVtZW50cyBw ZXIgcGFja2V0ICh3aXRoIHBhY2tldCBJRCk6IA0KICAgIC0gUGFja2V0IGFycml2YWwgdGltZTog b2JzZXJ2YXRpb25UaW1lTWljcm9zZWNvbmRzIFtQU0FNUC1JTkZPXSAgDQogICAgLSBQYWNrZXQg SUQ6IGRpZ2VzdEhhc2hWYWx1ZSBbUFNBTVAtSU5GT10gDQogICAgIA0KICAgIFJlcXVpcmVkIGZ1 bmN0aW9uczogIA0KICAgIC0gcGFja2V0IElEIGdlbmVyYXRpb24gDQogICAgLSBkZWxheSBjYWxj dWxhdGlvbiAoZnJvbSBhcnJpdmFsIHRpbWVzIGF0IHRoZSB0d28gb2JzZXJ2YXRpb24gDQogICAg ICAgcG9pbnRzKSANCiAgDQogICAgUmVtYXJrczogDQogICAgLSBSZXF1aXJlcyBpbmZvcm1hdGlv biBlbGVtZW50cyBmcm9tIFtQU0FNUC1JTkZPXSANCiAgICAtIG9ic2VydmF0aW9uVGltZU1pY3Jv c2Vjb25kcyBjYW4gYmUgc3Vic3RpdHV0ZWQgYnkgDQogICAgICAgZmxvd1N0YXJ0TWljcm9zZWNv bmRzIFtJUEZJWC1JTkZPXSwgYmVjYXVzZSBhIHNpbmdsZSBwYWNrZXQgDQogICAgICAgY2FuIGJl IHJlcHJlc2VudGVkIGFzIGEgZmxvdy4gDQogICAgLSBJZiB0aW1lIHZhbHVlcyB3aXRoIGEgZmlu ZXIgZ3JhbnVsYXJpdHkgYXJlIG5lZWRlZCANCiAgICAgICBvYnNlcnZhdGlvblRpbWVOYW5vc2Vj b25kcyBjYW4gYmUgdXNlZC4gDQogICAgLSBUaGUgYW1vdW50IG9mIGNvbnRlbnQgdXNlZCBmb3Ig SUQgZ2VuZXJhdGlvbiBpbmZsdWVuY2VzIHRoZSANCiAgICAgICBudW1iZXIgb2YgY29sbGlzaW9u cyAoZGlmZmVyZW50IHBhY2tldHMgdGhhdCBtYXAgdG8gdGhlIHNhbWUgDQogICAgICAgSUQpIHRo YXQgY2FuIG9jY3VyLiBJbnZlc3RpZ2F0aW9ucyBvbiB0aGlzIGFuZCBvdGhlciANCiAgICAgICBj b25zaWRlcmF0aW9ucyBvbiBwYWNrZXQgSUQgZ2VuZXJhdGlvbiBjYW4gYmUgZm91bmQgaW4gDQog ICAgICAgW0dyRE05OF0sIFtEdUdyMDBdLCBhbmQgW1pzWkMwMV0uIA0KICANCiAgMi42IEludGVy LURvbWFpbiBFeGNoYW5nZSBvZiBJUEZJWCBkYXRhIA0KICAgICANCiAgICBJUEZJWCBkYXRhIGNh biBiZSB1c2VkIHRvIHNoYXJlIGluZm9ybWF0aW9uIHdpdGggbmVpZ2hib3IgDQogICAgcHJvdmlk ZXJzLiBBIGZldyByZWNvbW1lbmRhdGlvbnMgc2hvdWxkIHRvIGJlIGNvbnNpZGVyZWQgaWYgDQog ICAgSVBGSVggcmVjb3JkcyB0cmF2ZWwgb3ZlciB0aGUgcHVibGljIEludGVybmV0IGNvbXBhcmVk IHRvIGl0cyANCiAgICB1c2FnZSB3aXRoaW4gYSBzaW5nbGUgZG9tYWluLiBGaXJzdCBvZiBhbGws IHNlY3VyaXR5IHRocmVhdCANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFp c2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxM10gDQoMICAgICAgICAgICAgICAg ICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoN CiAgICBsZXZlbHMgYXJlIGhpZ2hlciBpZiBkYXRhIHRyYXZlbHMgb3ZlciB0aGUgcHVibGljIElu dGVybmV0LiANCiAgICBQcm90ZWN0aW9uIGFnYWluc3QgZGlzY2xvc3VyZSBvciBtYW5pcHVsYXRp b24gb2YgZGF0YSBpcyBldmVuIA0KICAgIG1vcmUgaW1wb3J0YW50IHRoYW4gZm9yIGludHJhLWRv bWFpbiB1c2FnZS4gVGhlcmVmb3JlIElQc2VjIG9yIA0KICAgIFRyYW5zcG9ydCBMYXllciBTZWN1 cml0eSAoVExTKSBzaG91bGQgYmUgdXNlZCBhcyBkZXNjcmliZWQgaW4gDQogICAgW0lQRklYLVBS T1RPXS4gDQogICAgIA0KICAgIEZ1cnRoZXJtb3JlIGRhdGEgdHJhbnNmZXIgc2hvdWxkIGJlIGNv bmdlc3Rpb24tYXdhcmUgaW4gb3JkZXIgdG8gDQogICAgYWxsb3cgdW50cm91YmxlZCBjby1leGlz dGVuY2Ugd2l0aCBvdGhlciBkYXRhIGZsb3dzLiBUaGF0IG1lYW5zIA0KICAgIHRyYW5zcG9ydCBv dmVyIFNDVFAgb3IgVENQIGlzIHJlcXVpcmVkLiAgDQogICAgIA0KICAgIFNvbWUgSVNQcyBhcmUg c3RpbGwgcmVsdWN0YW50IHRvIHNoYXJlIGluZm9ybWF0aW9uIGR1ZSB0byANCiAgICBjb25jZXJu cyB0aGF0IGNvbXBldGluZyBJU1BzIG1pZ2h0IGV4cGxvaXQgbmV0d29yayBpbmZvcm1hdGlvbiAN CiAgICBmcm9tIG5laWdoYm9yIHByb3ZpZGVycyB0byBzdHJlbmd0aGVuIHRoZWlyIG93biBwb3Np dGlvbiBpbiB0aGUgDQogICAgbWFya2V0LiBOZXZlcnRoZWxlc3MsIHRlY2huaWNhbCBuZWVkcyBo YXZlIGFscmVhZHkgdHJpZ2dlcmVkIHRoZSANCiAgICBleGNoYW5nZSBvZiBkYXRhIGluIHRoZSBw YXN0IChlLmcuIGV4Y2hhbmdlIG9mIHJvdXRpbmcgDQogICAgaW5mb3JtYXRpb24gYnkgQkdQKS4g VGhlIG5lZWQgdG8gcHJvdmlkZSBpbnRlci1kb21haW4gZ3VhcmFudGVlcyANCiAgICBpcyBvbmUg YmlnIGluY2VudGl2ZSB0byBpbmNyZWFzZSBpbnRlci1kb21haW4gY29vcGVyYXRpb24uIFRoZSAN CiAgICBuZWNlc3NpdHkgdG8gZGVmZW5kIG5ldHdvcmtzIGFnYWluc3QgY3VycmVudCBhbmQgZnV0 dXJlIHRocmVhdHMgDQogICAgKGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFja3MsIHdvcm0gZGlzdHJp YnV0aW9ucywgZXRjLikgd2lsbCANCiAgICBob3BlZnVsbHkgaW5jcmVhc2UgdGhlIHdpbGxpbmdu ZXNzIHRvIGV4Y2hhbmdlIG1lYXN1cmVtZW50IGRhdGEgDQogICAgYmV0d2VlbiBwcm92aWRlcnMu IA0KICAgICANCiAgMi43ICBFeHBvcnQgb2YgRGVyaXZlZCBNZXRyaWNzIA0KICANCiAgICBUaGUg SVBGSVggcHJvdG9jb2wgaXMgdXNlZCB0byB0cmFuc3BvcnQgZmxvdyBhbmQgcGFja2V0IA0KICAg IGluZm9ybWF0aW9uIHRvIHByb3ZpZGUgdGhlIGlucHV0IGZvciB0aGUgY2FsY3VsYXRpb24gb2Yg YSANCiAgICB2YXJpZXR5IG1ldHJpY3MgKGUuZy4gZm9yIFFvUyB2YWxpZGF0aW9uIG9yIGF0dGFj ayBkZXRlY3Rpb24pLiAgDQogICAgSVBGSVggY2FuIGFsc28gYmUgdXNlZCB0byB0cmFuc2ZlciB0 aGVzZSBtZXRyaWNzIGRpcmVjdGx5LCBlLmcuIA0KICAgIGlmIHRoZSBtZXRyaWMgY2FsY3VsYXRp b24gaXMgY28tbG9jYXRlZCB3aXRoIG1lYXN1cmVtZW50IGFuZCANCiAgICBleHBvcnRpbmcgcHJv Y2Vzcy4gDQogICAgIA0KICAgIEl0IGRvZXNuJ3QgbWF0dGVyIHdoaWNoIG1lYXN1cmVtZW50IGFu ZCBwb3N0LXByb2Nlc3NpbmcgDQogICAgZnVuY3Rpb25zIGFyZSBhcHBsaWVkIHRvIGdlbmVyYXRl IGEgc3BlY2lmaWMgbWV0cmljLiBJUEZJWCBjYW4gDQogICAgYmUgdXNlZCB0byB0cmFuc3BvcnQg dGhlIHJlc3VsdHMgZnJvbSBwYXNzaXZlIGFuZCBhY3RpdmUgDQogICAgbWVhc3VyZW1lbnRzIGFu ZCBmcm9tIHBvc3QtcHJvY2Vzc2luZyBvcGVyYXRpb25zLiBGb3IgdGhlIA0KICAgIHJlcG9ydGlu ZyBvZiBkZXJpdmVkIG1ldHJpY3MgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBlbGVtZW50cyANCiAg ICBuZWVkIHRvIGJlIGRlZmluZWQuIA0KICANCiAgMi44IFN1bW1hcnkgDQogICAgIA0KICAgIFRo ZSBmb2xsb3dpbmcgdGFibGUgc2hvd3MgYW4gb3ZlcnZpZXcgb2YgdGhlIGluZm9ybWF0aW9uIA0K ICAgIGVsZW1lbnRzIHJlcXVpcmVkIGZvciB0aGUgdGFyZ2V0IGFwcGxpY2F0aW9ucyBkZXNjcmli ZWQgaW4gDQogICAgW1JGQzM5MTddIChNLW1hbmRhdG9yeSwgUi1yZWNvbW1lbmRlZCwgTy1vcHRp b25hbCkuIA0KICANCg0KDQoNCg0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENs YWlzZSAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XSANCgwgICAgICAgICAgICAg ICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoN Cg0KICAgIHwgQXBwbGljYXRpb24gfFtJUEZJWC1JTkZPXXwgW1BTQU1QLUlORk9dIHwgYWRkaXRp b25hbCBJRXMgIHwgDQogICAgKy0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0tLS0tKyANCiAgICB8IEFjY291bnRpbmcgIHwgICAgIE0gICAgICB8 ICAgICAgLSAgICAgICB8ICAgICAgIC0gICAgICAgICB8IA0KICAgICstLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgfCBUcmFm ZmljICAgICB8ICAgICBNICAgICAgfCAgICAgIE8gICAgICAgfCAgICAgICAtICAgICAgICAgfCAN CiAgICB8IFByb2ZpbGluZyAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICB8IA0KICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgfCBUcmFmZmljICAgICB8ICAgICBNICAgICAgfCAg ICAgIC0gICAgICAgfCAgICAgICBPICAgICAgICAgfCANCiAgICB8IEVuZ2luZWVyaW5nIHwgICAg ICAgICAgICB8ICAgICAgICAgICAgICB8IChyb3V0aW5nIGluZm8pICB8IA0KICAgICstLS0tLS0t LS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsgDQog ICAgfCBBdHRhY2sgICAgICB8ICAgICBNICAgICAgfCAgICAgIFIgICAgICAgfCAgICAgICBSICAg ICAgICAgfCANCiAgICB8IERldGVjdGlvbiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICB8 KGRlcml2ZWQgbWV0cmljcyl8IA0KICAgICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgfCBRb1MgICAgICAgICB8ICAgICBN ICAgICAgfCAgICAgIE0gICAgICAgfCAgICAgICBPICAgICAgICAgfCANCiAgICB8IE1vbml0b3Jp bmcgIHwgICAgICAgICAgICB8KG1vc3QgbWV0cmljcyl8KGRlcml2ZWQgbWV0cmljcyl8IA0KICAg ICstLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLSsgDQogIA0KICAgIEZvciBhY2NvdW50aW5nIHRoZSBJRXMgaW4gW0lQRklYLUlORk9dIGFy ZSBzdWZmaWNpZW50LiANCiAgICBOZXZlcnRoZWxlc3MgYXMgbWVudGlvbmVkIGFib3ZlLCB0aGUg cmVsaWFiaWxpdHkgY3VycmVudGx5IA0KICAgIHN1cHBvcnRlZCBieSBJUEZJWCBpcyBub3Qgc3Vm ZmljaWVudCBmb3IgY29tbWVyY2lhbC1ncmFkZSANCiAgICBiaWxsaW5nIHN5c3RlbXMgKHNlZSBz ZWN0aW9uIDQuMikuICBGb3IgdHJhZmZpYyBwcm9maWxpbmcgDQogICAgYWRkaXRpb25hbGx5IElF cyBmcm9tIFtQU0FNUC1JTkZPXSBjYW4gYmUgdXNlZnVsIHRvIGdhaW4gbW9yZSANCiAgICBpbnNp Z2h0IGludG8gdGhlIHRyYWZmaWMuIEZvciB0cmFmZmljIGVuZ2luZWVyaW5nIGZsb3cgDQogICAg aW5mb3JtYXRpb24gZnJvbSBbSVBGSVgtSU5GT10gaXMgc3VmZmljaWVudCBidXQgaXQgd291bGQg cHJvZml0IA0KICAgIGZyb20gcm91dGluZyBpbmZvcm1hdGlvbiwgd2hpY2ggY291bGQgYmUgZXhw b3J0ZWQgYnkgSVBGSVguIA0KICAgIEF0dGFjayBkZXRlY3Rpb24gdXN1YWxseSBwcm9maXRzIGZy b20gZnVydGhlciBpbnNpZ2h0IGludG8gdGhlIA0KICAgIHRyYWZmaWMuIFRoaXMgY2FuIGJlIGFj aGlldmVkIHdpdGggSUVzIGZyb20gW1BTQU1QLUlORk9dLiANCiAgICBGdXJ0aGVybW9yZSB0aGUg cmVwb3J0aW5nIG9mIGRlcml2ZWQgbWV0cmljcyBpbiBhZGRpdGlvbmFsIElFcyANCiAgICB3b3Vs ZCBiZSB1c2VmdWwuIE1vc3QgUW9TIG1ldHJpY3MgcmVxdWlyZSB0aGUgdXNlIG9mIElFcyBmcm9t IA0KICAgIFtQU0FNUC1JTkZPXS4gSUVzIGZyb20gW1BTQU1QLUlORk9dYXJlIGFsc28gdXNlZnVs IGZvciB0aGUgDQogICAgbWFwcGluZyBvZiByZXN1bHRzIGZyb20gZGlmZmVyZW50IG9ic2VydmF0 aW9uIHBvaW50cyBhcyANCiAgICBkZXNjcmliZWQgaW4gc2VjdGlvbiAyLjUuMS4gDQogIA0KIDMu IFJlbGF0aW9uIG9mIElQRklYIHRvIE90aGVyIEZyYW1ld29ya3MgYW5kIFByb3RvY29scyAgDQog ICAgIA0KICAzLjEgSVBGSVggYW5kIFBTQU1QIA0KICAgICANCiAgICBQU0FNUCBkZWZpbmVzIHBh Y2tldCBzZWxlY3Rpb24gbWV0aG9kcywgdGhlaXIgY29uZmlndXJhdGlvbiBhdCANCiAgICByb3V0 ZXJzIGFuZCBwcm9iZXMgYW5kIHRoZSByZXBvcnRpbmcgb2YgcGFja2V0IGluZm9ybWF0aW9uLiAg DQogICAgIA0KICAgIFBTQU1QIHVzZXMgSVBGSVggYXMgYmFzaXMgZm9yIGV4cG9ydGluZyBwYWNr ZXQgaW5mb3JtYXRpb24gDQogICAgW1BTQU1QLVBST1RPXS4gW1BTQU1QLUlORk9dIGRlc2NyaWJl cyBmdXJ0aGVyIGluZm9ybWF0aW9uIA0KICAgIGVsZW1lbnRzIGZvciBleHBvcnRpbmcgcGFja2V0 IGluZm9ybWF0aW9uIGFuZCByZXBvcnRpbmcgDQogICAgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlv bi4gDQogIA0KICAgIFRoZSBtYWluIGRpZmZlcmVuY2UgYmV0d2VlbiBJUEZJWCBhbmQgUFNBTVAg aXMgdGhhdCBJUEZJWCANCiAgICBhZGRyZXNzZXMgdGhlIGV4cG9ydCBvZiBmbG93IHJlY29yZHMg d2hlcmVhcyBQU0FNUCBhZGRyZXNzZXMgdGhlIA0KICAgIGV4cG9ydCBvZiBwYWNrZXQgcmVjb3Jk cy4gRnVydGhlcm1vcmUsIFBTQU1QIGV4cGxpY2l0bHkgDQoNCg0KDQoNCiBac2VieSwgQm9zY2hp LCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTVdIA0K DCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAgICAgICAgICBK dW5lIDIwMDYgDQoNCg0KDQogICAgYWRkcmVzc2VzIHJlbW90ZSBjb25maWd1cmF0aW9uLiBJdCBk ZWZpbmVzIGEgTUlCIGZvciB0aGUgDQogICAgY29uZmlndXJhdGlvbiBvZiBwYWNrZXQgc2VsZWN0 aW9uIHByb2Nlc3Nlcy4gUmVtb3RlIA0KICAgIGNvbmZpZ3VyYXRpb24gaXMgbm90ICh5ZXQpIGFk ZHJlc3NlZCBpbiBJUEZJWCwgYnV0IG9uZSBjb3VsZCANCiAgICBjb25zaWRlciBleHRlbmRpbmcg dGhlIFBTQU1QIE1JQiB0byBhbHNvIGFsbG93IGNvbmZpZ3VyYXRpb24gb2YgDQogICAgSVBGSVgg cHJvY2Vzc2VzLiAgDQogIA0KICAzLjIgSVBGSVggYW5kIFJNT04gDQogICAgIA0KICAgIFJNT04g W1JGQzM1NzddIGlzIGEgd2lkZWx5IHVzZWQgbW9uaXRvcmluZyBzeXN0ZW0gdGhhdCBnYXRoZXJz IA0KICAgIHRyYWZmaWMgZGF0YSBmcm9tIFJNT04gQWdlbnRzIGluIG5ldHdvcmsgZGV2aWNlcy4g T25lIG1ham9yIA0KICAgIGRpZmZlcmVuY2UgYmV0d2VlbiBSTU9OIGFuZCBJUEZJWCBpcyB0aGF0 IFJNT04gdXNlcyBTTk1QIGZvciANCiAgICBkYXRhIGV4cG9ydCB3aGVyZWFzIElQRklYIGRlZmlu ZXMgYW4gb3duIHB1c2gtb3JpZW50ZWQgcHJvdG9jb2wuIA0KICAgIFJNT04gZGVmaW5lcyBNSUJz IHRoYXQgY29udGFpbiB0aGUgaW5mb3JtYXRpb24gdG8gYmUgZXhwb3J0ZWQuIA0KICAgIEluIElQ RklYIHRoZSBkYXRhIHRvIGJlIGV4cG9ydGVkIGlzIGRlZmluZWQgYXMgaW5mb3JtYXRpb24gDQog ICAgZWxlbWVudHMuIA0KICAgICANCiAgICBUaGUgbW9zdCByZWxldmFudCBNSUJzIGZvciBhIGNv bXBhcmlzb24gd2l0aCBJUEZJWCBhcmUgdGhlIA0KICAgIEFwcGxpY2F0aW9uIFBlcmZvcm1hbmNl IE1lYXN1cmVtZW50IE1JQiAoQVBNLU1JQikgW1JGQzM3MjldIGFuZCANCiAgICB0aGUgVHJhbnNw b3J0IFBlcmZvcm1hbmNlIE1ldHJpY3MgTUlCIChUUE0tTUlCKSBbUkZDNDE1MF0uIA0KICAgIFRo ZSBBUE0tTUlCIGhhcyBhIGNvbXBsZXggc3lzdGVtIGZvciB0cmFja2luZyB1c2VyIGFwcGxpY2F0 aW9uIA0KICAgIHBlcmZvcm1hbmNlLCB3aXRoIHJlcG9ydGluZyBhYm91dCB0cmFuc2FjdGlvbnMg YW5kIFNMQSB0aHJlc2hvbGQgDQogICAgbm90aWZpY2F0aW9uLXRyaWdnZXIgY29uZmlndXJhdGlv biwgYW5kIHBlcnNpc3RlbmNlIGFjcm9zcyBESENQIA0KICAgIGxlYXNlIGV4cGlyYXRpb25zLiBJ dCByZXF1aXJlcyBmdWxsIFJNT04yLU1JQiBwcm90b2NvbERpclRhYmxlIA0KICAgIGltcGxlbWVu dGF0aW9uLiANCiAgICAgDQogICAgVGhlIEFQTS1NSUIgcmVwb3J0cyB0aGUgcGVyZm9ybWFuY2Ug b2YgdHJhbnNhY3Rpb25zLiBBIA0KICAgIHRyYW5zYWN0aW9uIGlzIGEgc2VydmljZSBvcmllbnRl ZCB0ZXJtIGFuZCBkZXNjcmliZXMgdGhlIGRhdGEgDQogICAgZXhjaGFuZ2UgZnJvbSB0aGUgdHJh bnNhY3Rpb24gc3RhcnQgKHdoZW4gYSB1c2VyIHJlcXVlc3RzIGEgDQogICAgc2VydmljZSkgdW50 aWwgaXRzIGNvbXBsZXRpb24uIFRoZSBwZXJmb3JtYW5jZSBwYXJhbWV0ZXJzIA0KICAgIGluY2x1 ZGUgcmVzcG9uc2UgdGltZXMsIHRocm91Z2hwdXQsIHN0cmVhbWluZyByZXNwb25zaXZlbmVzcyBh bmQgDQogICAgYXZhaWxhYmlsaXR5IG9mIHNlcnZpY2VzLiAgDQogICAgVGhlIFJNT04gdHJhbnNh Y3Rpb24gY29uY2VwdCBkaWZmZXJzIGZyb20gdGhlIElQRklYIGZsb3cgDQogICAgY29uY2VwdC4g QSBmbG93IGlzIGEgdmVyeSBnZW5lcmljIHRlcm0gYW5kIGFsbG93cyB0byBncm91cCBJUCANCiAg ICBwYWNrZXRzIGluIGFjY29yZGFuY2UgdG8gY29tbW9uIHByb3BlcnRpZXMuICBJbiBjb250cmFz dCB0byANCiAgICB0aGlzLCB0aGUgdGVybSB0cmFuc2FjdGlvbiBpcyBzZXJ2aWNlLW9yaWVudGVk IGFuZCBjb250YWlucyBhbGwgDQogICAgZGF0YSBleGNoYW5nZSByZXF1aXJlZCBmb3Igc2Vydmlj ZSBjb21wbGV0aW9uLiAgDQogICAgSW4gb3JkZXIgdG8gcmVwb3J0IHN1Y2ggZGF0YSB3aXRoIElQ RklYIG9uZSB3b3VsZCBwcm9iYWJseSBuZWVkIA0KICAgIGEgc3BlY2lmaWMgY29tYmluYXRpb24g b2YgbXVsdGlwbGUgZmxvd3MgYW5kIHRoZSBhYmlsaXR5IHRvIG1hcCANCiAgICB0aG9zZSB0byB0 aGUgdHJhbnNhY3Rpb24uIER1ZSB0byB0aGUgc2VydmljZS1vcmllbnRhdGVkIGZvY3VzIG9mIA0K ICAgIEFQTSwgYWxzbyB0aGUgcmVxdWlyZWQgbWV0cmljcyBkaWZmZXIuIEZvciBpbnN0YW5jZSwg dGhlIFJNT04gDQogICAgQVBNIHJlcXVpcmVzIGEgbWV0cmljIGZvciB0aGUgcmVzcG9uc2l2ZW5l c3Mgb2Ygc2VydmljZXMuIFN1Y2ggDQogICAgbWV0cmljcyBhcmUgbm90IGFkZHJlc3NlZCBpbiBJ UEZJWC4gDQogICAgIA0KICAgIEZ1cnRoZXJtb3JlLCB0aGUgQVBNLU1JQiBhbGxvd3MgdGhlIGNv bmZpZ3VyYXRpb24gb2YgdGhlIA0KICAgIHRyYW5zYWN0aW9uIHR5cGUgdG8gYmUgbW9uaXRvcmVk LCBpLmUuLCBpdCBhZGRyZXNzZXMgdGhlIA0KICAgIGNvbmZpZ3VyYXRpb24gb2YgdGhlIG1ldGVy aW5nIHByb2Nlc3MsIHdoaWNoIGlzIGN1cnJlbnRseSBub3QgDQogICAgYWRkcmVzc2QgaW4gSVBG SVguICANCiAgICAgDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMTZdIA0KDCAgICAgICAgICAgICAgICAgICAg ICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAg VGhlIEFQTSBNSUIgY291bGQgYmUgY29uc2lkZXJlZCBhcyBhbiBleHRlbnNpb24gb2YgdGhlIElQ RklYIA0KICAgIG1ldGVyaW5nIHByb2Nlc3Mgd2hlcmUgdGhlIGFwcGxpY2F0aW9uIHBlcmZvcm1h bmNlIG9mIGEgDQogICAgY29tYmluYXRpb24gb2YgbXVsdGlwbGUgZmxvd3MgaXMgbWVhc3VyZWQu IElmIGFwcHJvcHJpYXRlIElFcyANCiAgICB3b3VsZCBiZSBkZWZpbmVkIGluIHRoZSBJUEZJWCBp bmZvcm1hdGlvbiBtb2RlbCBhbmQgdGhlIElQRklYIA0KICAgIGRldmljZSB3b3VsZCBzdXBwb3J0 IHRoZSBBUE0gTUlCIGRhdGEgY29sbGVjdGlvbiwgdGhlIHNvbHV0aW9ucyANCiAgICBjb3VsZCBi ZSBjb21wbGltZW50YXJ5LiBUaGF0IG1lYW5zIG9uZSBjb3VsZCB1c2UgSVBGSVggdG8gZXhwb3J0 IA0KICAgIEFQTSBNSUIgdHJhbnNhY3Rpb24gaW5mb3JtYXRpb24uIA0KICAgICANCiAgICBUaGUg VFBNLU1JQiBicmVha3Mgb3V0IHRoZSBBUE0tTUlCIHRyYW5zYWN0aW9ucyBpbnRvIHN1Yi0NCiAg ICBhcHBsaWNhdGlvbiBsZXZlbCB0cmFuc2FjdGlvbi4gRm9yIGluc3RhbmNlIGEgd2ViIHJlcXVl c3QgaXMgDQogICAgYnJva2VuIGRvd24gaW50byBETlMsIFRDUCBhbmQgSFRUUCBzdWItdHJhbnNh Y3Rpb25zLiBBZ2FpbiBzdWItDQogICAgYXBwbGljYXRpb24gbGV2ZWwgdHJhbnNhY3Rpb24gY291 bGQgYmUgbWVhc3VyZWQgdXNpbmcgSVBGSVggd2l0aCANCiAgICBhbiBhcHByb3ByaWF0ZSBmbG93 IGRlZmluaXRpb24gYW5kIGJ5IGNvbWJpbmluZyB0aGUgcmVwb3J0aW5nIG9mIA0KICAgIGJvdGgg ZGlyZWN0aW9ucyBvZiB0aGUgZGF0YSB0cmFuc2ZlciAoZm9yIHJlcG9ydGluZyBiaS0NCiAgICBk aXJlY3Rpb25hbCBmbG93IGluZm9ybWF0aW9uIHNlZSBhbHNvIHNlY3Rpb24gNC42KS4gVGhlIFRQ TS1NSUIgDQogICAgcmVxdWlyZXMgQVBNLU1JQiBhbmQgUk1PTjItTUlCLiANCiAgDQogIDMuMyBJ UEZJWCBhbmQgSVBQTSANCiAgICAgDQogICAgVGhlIElQRklYIHByb3RvY29sIGNhbiBiZSB1c2Vk IHRvIGNhcnJ5IElQUE0gbmV0d29yayBwZXJmb3JtYW5jZSANCiAgICBtZXRyaWNzIG9yIGluZm9y bWF0aW9uIHRoYXQgY2FuIGJlIHVzZWQgdG8gY2FsY3VsYXRlIHRob3NlIA0KICAgIG1ldHJpY3Mg KHNlZSBzZWN0aW9ucyAyLjUgYW5kIDIuNyBmb3IgZGV0YWlscyBhbmQgcmVmZXJlbmNlcykuIA0K ICAgICANCiAgMy40IElQRklYIGFuZCBBQUEgIA0KICAgICANCiAgICBBQUEgZGVmaW5lcyBhIHBy b3RvY29sIGFuZCBhcmNoaXRlY3R1cmUgZm9yIGF1dGhlbnRpY2F0aW9uLCANCiAgICBhdXRob3Jp emF0aW9uIGFuZCBhY2NvdW50aW5nIGZvciBzZXJ2aWNlIHVzYWdlIFtSRkMyOTAzXS4gVGhlIA0K ICAgIERJQU1FVEVSIHByb3RvY29sIFtSRkMzNTg4XSBpcyB1c2VkIGZvciBBQUEgY29tbXVuaWNh dGlvbiwgd2hpY2ggDQogICAgaXMgbmVlZGVkIGZvciBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlcyAo TW9iaWxlIElQLCBOQVNSRVEsIGFuZCANCiAgICBST0FNT1BTKS4gVGhlIEFBQSBhcmNoaXRlY3R1 cmUgW1JGQzI5MDNdIHByb3ZpZGVzIGEgZnJhbWV3b3JrIA0KICAgIGZvciBleHRlbmRpbmcgQUFB IHN1cHBvcnQgdG8gb3RoZXIgc2VydmljZXMuIERJQU1FVEVSIGRlZmluZXMgDQogICAgdGhlIGV4 Y2hhbmdlIG9mIG1lc3NhZ2VzIGJldHdlZW4gQUFBIGVudGl0aWVzLCBlLmcuIGJldHdlZW4gQUFB IA0KICAgIGNsaWVudHMgYXQgYWNjZXNzIGRldmljZXMgYW5kIEFBQSBzZXJ2ZXJzLCBhbmQgYW1v bmcgQUFBIA0KICAgIHNlcnZlcnMuIERJQU1FVEVSIGlzIHVzZWQgZm9yIHRoZSB0cmFuc2ZlciBv ZiBhY2NvdW50aW5nIA0KICAgIHJlY29yZHMuIEluIG9yZGVyIHRvIGZvcm0gYWNjb3VudGluZyBy ZWNvcmRzIGZvciB1c2FnZS1iYXNlZCANCiAgICBhY2NvdW50aW5nIG1lYXN1cmVtZW50IGRhdGEg ZnJvbSB0aGUgbmV0d29yayBpcyByZXF1aXJlZC4gSVBGSVggDQogICAgZGVmaW5lcyBhIHByb3Rv Y29sIHRvIGV4cG9ydCBzdWNoIGRhdGEgZnJvbSByb3V0ZXJzLCBtZWFzdXJlbWVudCANCiAgICBw cm9iZXMgYW5kIG90aGVyIGRldmljZXMuIFRoZXJlZm9yZSBpdCBsb29rcyBwcm9taXNpbmcgdG8g DQogICAgY29ubmVjdCB0aG9zZSB0d28gYXJjaGl0ZWN0dXJlcy4gIA0KICAgICANCiAgICBGb3Ig YWxsIHNjZW5hcmlvcyBkZXNjcmliZWQgaGVyZSBvbmUgaGFzIHRvIGtlZXAgdGhlIGxpbWl0ZWQg DQogICAgcmVsaWFiaWxpdHkgb2YgSVBGSVggaW4gbWluZCAoc2VjdGlvbiA0LjIpLiBJbiBvcmRl ciB0byBwcm92aWRlIA0KICAgIGlucHV0IGZvciBjb21tZXJjaWFsLWdyYWRlIGJpbGxpbmcsIElQ RklYIHJlcXVpcmVzIHNvbWUgDQogICAgZXh0ZW5zaW9ucyBmb3IgdGhlIHJlbGlhYmxlIHRyYW5z cG9ydCBvZiBkYXRhLiBVc2luZyBJUEZJWCANCiAgICB3aXRob3V0IGV4dGVuc2lvbnMgdG9nZXRo ZXIgd2l0aCBBQUEgd291bGQgcmVzdWx0IGluIGFjY291bnRpbmcgDQogICAgc2NlbmFyaW9zIHdp dGggbGltaXRlZCBjYXBhYmlsaXRpZXMgbm90IHN1ZmZpY2llbnQgZm9yIA0KICAgIGNvbW1lcmNp YWwtZ3JhZGUgYmlsbGluZy4gIA0KICANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVl LCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxN10gDQoMICAgICAgICAg ICAgICAgICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiAN Cg0KDQoNCiAgICBBcyBzaG93biBpbiBzZWN0aW9uIDIuMSBhY2NvdW50aW5nIGFwcGxpY2F0aW9u cyBjYW4gZGlyZWN0bHkgDQogICAgaW5jb3Jwb3JhdGUgYW4gSVBGSVggY29sbGVjdGluZyBwcm9j ZXNzIHRvIHJlY2VpdmUgSVBGSVggcmVjb3JkcyANCiAgICB3aXRoIGluZm9ybWF0aW9uIGFib3V0 IHRoZSB0cmFuc21pdHRlZCB2b2x1bWUuIE5ldmVydGhlbGVzcywgaWYgDQogICAgYW4gQUFBIGlu ZnJhc3RydWN0dXJlIGlzIGluIHBsYWNlLCB0aGUgY29vcGVyYXRpb24gYmV0d2VlbiBJUEZJWCAN CiAgICAoYW5kIGVzcGVjaWFsbHkgSVBGSVggd2l0aCByZWxpYWJpbGl0eSBleHRlbnNpb25zKSBh bmQgQUFBIA0KICAgIHByb3ZpZGVzIG1hbnkgdmFsdWFibGUgc3luZXJnaXN0aWMgYmVuZWZpdHMu IElQRklYIHJlY29yZHMgY2FuIA0KICAgIHByb3ZpZGUgdGhlIGlucHV0IGZvciBBQUEgYWNjb3Vu dGluZyBmdW5jdGlvbnMgYW5kIHByb3ZpZGUgdGhlIA0KICAgIGJhc2lzIGZvciB0aGUgZ2VuZXJh dGlvbiBvZiBESUFNRVRFUiBhY2NvdW50aW5nIHJlY29yZHMuICANCiAgICAgDQogICAgRnVydGhl ciBwb3RlbnRpYWwgZmVhdHVyZXMgaW5jbHVkZSB0aGUgbWFwcGluZyBvZiBhIHVzZXIgSUQgdG8g DQogICAgZmxvdyBpbmZvcm1hdGlvbiAoYnkgdXNpbmcgYXV0aGVudGljYXRpb24gaW5mb3JtYXRp b24pIG9yIA0KICAgIGZhY2lsaXRhdGluZyB0aGUgc2VjdXJlIGF1dGhvcml6ZWQgZXhjaGFuZ2Ug b2YgRElBTUVURVIgDQogICAgYWNjb3VudGluZyByZWNvcmRzIHdpdGggbmVpZ2hib3IgZG9tYWlu cy4gVGhlIGxhc3QgZmVhdHVyZSBpcyANCiAgICBlc3BlY2lhbGx5IHVzZWZ1bCBpbiByb2FtaW5n IHNjZW5hcmlvcyB3aGVyZSB0aGUgdXNlciBjb25uZWN0cyANCiAgICB0byBhIGZvcmVpZ24gbmV0 d29yayBhbmQgdGhlIGhvbWUgcHJvdmlkZXIgZ2VuZXJhdGVzIHRoZSANCiAgICBpbnZvaWNlLiAg IA0KICAgICANCiAgICBDb3VwbGluZyBhbiBJUEZJWCBjb2xsZWN0aW5nIHByb2Nlc3Mgd2l0aCBB QUEgZnVuY3Rpb25zIGhhcyBhbHNvIA0KICAgIGhpZ2ggcG90ZW50aWFsIGZvciBpbnRydXNpb24g YW5kIGF0dGFjayBkZXRlY3Rpb24uIEFBQSBjb250cm9scyANCiAgICBuZXR3b3JrIGFjY2VzcyBh bmQgbWFpbnRhaW5zIGRhdGEgYWJvdXQgdXNlcnMgYW5kIG5vZGVzLiBBQUEgDQogICAgZnVuY3Rp b25zIGNhbiBoZWxwIHRvIGlkZW50aWZ5IHRoZSBzb3VyY2Ugb2YgbWFsaWNpb3VzIHRyYWZmaWMu IA0KICAgIEF1dGhvcml6YXRpb24gZnVuY3Rpb25zIGFyZSBhYmxlIHRvIGRlbnkgYWNjZXNzIHRv IHN1c3BpY2lvdXMgDQogICAgdXNlcnMgb3Igbm9kZXMuIFRoZXJlZm9yZSBjb3VwbGluZyB0aG9z ZSBmdW5jdGlvbnMgd2l0aCBhbiBJUEZJWCANCiAgICBjb2xsZWN0aW5nIHByb2Nlc3MgY2FuIHBy b3ZpZGUgYW4gZWZmaWNpZW50IGRlZmVuc2UgYWdhaW5zdCANCiAgICBuZXR3b3JrIGF0dGFja3Mu IFNoYXJpbmcgSVBGSVggcmVjb3JkcyAoZWl0aGVyIGRpcmVjdGx5IG9yIA0KICAgIGVuY2Fwc3Vs YXRlZCBpbiBESUFNRVRFUikgd2l0aCBuZWlnaGJvciBwcm92aWRlcnMgYWxsb3dzIGFuIA0KICAg IGVmZmljaWVudCBpbnRlci1kb21haW4gYXR0YWNrIGRldGVjdGlvbi4gVGhlIEFBQSBpbmZyYXN0 cnVjdHVyZSANCiAgICBjYW4gYWxzbyBiZSB1c2VkIHRvIGNvbmZpZ3VyZSBtZWFzdXJlbWVudCBm dW5jdGlvbnMgaW4gdGhlIA0KICAgIG5ldHdvcmsgYXMgcHJvcG9zZWQgaW4gW1JGQzMzMzRdLiAN CiAgICAgDQogICAgVHdvIHBvc3NpYmlsaXRpZXMgZXhpc3QgdG8gY29ubmVjdCBJUEZJWCBhbmQg QUFBOiAgDQogICAgIA0KICAgIC0gQ29ubmVjdGluZyB2aWEgYW4gQUFBIENsaWVudCANCiAgICAt IENvbm5lY3RpbmcgdmlhIGFuIEFwcGxpY2F0aW9uIFNwZWNpZmljIE1vZHVsZSAoQVNNKSANCiAg ICAgDQogICAgQm90aCBhcmUgZXhwbGFpbmVkIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuIFRo ZSBhcHByb2FjaGVzIA0KICAgIG9ubHkgcmVxdWlyZSBmZXcgYWRkaXRpb25hbCBmdW5jdGlvbnMu IFRoZXkgZG8gbm90IHJlcXVpcmUgYW55IA0KICAgIGNoYW5nZXMgdG8gSVBGSVggb3IgRElBTUVU RVIuIA0KICAgICANCiAzLjQuMSBDb25uZWN0aW5nIHZpYSBhbiBBQUEgQ2xpZW50IA0KICAgICAN CiAgICBPbmUgcG9zc2liaWxpdHkgb2YgY29ubmVjdGluZyBJUEZJWCBhbmQgQUFBIGlzIHRvIHJ1 biBhbiBBQUEgDQogICAgY2xpZW50IG9uIHRoZSBJUEZJWCBjb2xsZWN0b3IuIFRoaXMgY2xpZW50 IGNhbiBnZW5lcmF0ZSBESUFNRVRFUiANCiAgICBhY2NvdW50aW5nIG1lc3NhZ2VzIGFuZCBzZW5k IHRoZW0gdG8gYW4gQUFBIHNlcnZlci4gVGhlIG1hcHBpbmcgDQogICAgb2YgdGhlIGZsb3cgaW5m b3JtYXRpb24gdG8gYSB1c2VyIElEIGNhbiBiZSBkb25lIGluIHRoZSBBQUEgDQogICAgc2VydmVy IGJ5IHVzaW5nIGRhdGEgZnJvbSB0aGUgYXV0aGVudGljYXRpb24gcHJvY2Vzcy4gRElBTUVURVIg DQogICAgYWNjb3VudGluZyBtZXNzYWdlcyBjYW4gYmUgc2VudCB0byB0aGUgYWNjb3VudGluZyBh cHBsaWNhdGlvbiBvciANCiAgICB0byBvdGhlciBBQUEgc2VydmVycyAoZS5nLiBpbiByb2FtaW5n IHNjZW5hcmlvcykuIA0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE4XSANCgwgICAgICAgICAgICAgICAgICAg ICAgSVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAN CiAgICAgICAgICAgKy0tLS0tLS0tLSsgIERJQU1FVEVSICAgICstLS0tLS0tLS0rIA0KICAgICAg ICAgICB8ICBBQUEtUyAgfC0tLS0tLS0tLS0tLS0+fCAgQUFBLVMgIHwgDQogICAgICAgICAgICst LS0tLS0tLS0rICAgICAgICAgICAgICArLS0tLS0tLS0tKyANCiAgICAgICAgICAgICAgICBeIA0K ICAgICAgICAgICAgICAgIHwgRElBTUVURVIgDQogICAgICAgICAgICAgICAgfCANCiAgICAgICAg ICAgICAgICB8IA0KICAgICAgICAgKy0tKy0tLS0tLS0tKy0tKyANCiAgICAgICAgIHwgIHwgIEFB QS1DIHwgIHwgDQogICAgICAgICArICArLS0tLS0tLS0rICB8IA0KICAgICAgICAgfCAgICAgICAg ICAgICAgfCANCiAgICAgICAgIHwgIENvbGxlY3RvciAgIHwgDQogICAgICAgICArLS0tLS0tLS0t LS0tLS0rICAgDQogICAgICAgICAgICAgICAgXiANCiAgICAgICAgICAgICAgICB8IElQRklYIA0K ICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAgKy0tLS0tLS0tLS0tLSsgDQogICAgICAgICAg fCAgRXhwb3J0ZXIgIHwgDQogICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgDQogICAgIA0KICAg IEZpZ3VyZSAyOiBJUEZJWCBjb2xsZWN0b3IgY29ubmVjdHMgdG8gQUFBIHNlcnZlciB2aWEgQUFB IGNsaWVudCAgDQogICAgIA0KIDMuNC4yIENvbm5lY3RpbmcgdmlhIGFuIEFwcGxpY2F0aW9uIFNw ZWNpZmljIE1vZHVsZSAoQVNNKSANCiAgICAgDQogICAgQW5vdGhlciBwb3NzaWJpbGl0eSBpcyB0 byBkaXJlY3RseSBjb25uZWN0IHRoZSBJUEZJWCBjb2xsZWN0b3IgDQogICAgd2l0aCB0aGUgQUFB IHNlcnZlciB2aWEgYW4gYXBwbGljYXRpb24gc3BlY2lmaWMgbW9kdWxlIChBU00pLiANCiAgICBB cHBsaWNhdGlvbiBzcGVjaWZpYyBtb2R1bGVzIGhhdmUgYmVlbiBwcm9wb3NlZCBieSB0aGUgSVJU RiBBQUEgDQogICAgYXJjaGl0ZWN0dXJlIHJlc2VhcmNoIGdyb3VwIChBQUFSQ0gpIGluIFtSRkMy OTAzXS4gVGhleSBhY3QgYXMgDQogICAgYW4gaW50ZXJmYWNlIGJldHdlZW4gQUFBIHNlcnZlciBh bmQgc2VydmljZSBlcXVpcG1lbnQuIEluIHRoaXMgDQogICAgY2FzZSB0aGUgSVBGSVggY29sbGVj dG9yIGlzIHBhcnQgb2YgdGhlIEFTTS4gVGhlIEFTTSBhY3RzIGFzIGFuIA0KICAgIGludGVyZmFj ZSBiZXR3ZWVuIHRoZSBJUEZJWCBwcm90b2NvbCBhbmQgdGhlIGlucHV0IGludGVyZmFjZSBvZiAN CiAgICB0aGUgQUFBIHNlcnZlci4gVGhlIEFTTSB0cmFuc2xhdGVzIHRoZSByZWNlaXZlZCBJUEZJ WCBkYXRhIGludG8gDQogICAgYW4gYXBwcm9wcmlhdGUgZm9ybWF0IGZvciB0aGUgQUFBIHNlcnZl ci4gVGhlIEFBQSBzZXJ2ZXIgdGhlbiANCiAgICBjYW4gYWRkIGluZm9ybWF0aW9uIGFib3V0IHRo ZSB1c2VyIElEIGFuZCBnZW5lcmF0ZSBhIERJQU1FVEVSIA0KICAgIGFjY291bnRpbmcgcmVjb3Jk LiBUaGlzIGFjY291bnRpbmcgcmVjb3JkIGNhbiBiZSBzZW50IHRvIGFuIA0KICAgIGFjY291bnRp bmcgYXBwbGljYXRpb24gb3IgdG8gb3RoZXIgQUFBIHNlcnZlcnMuIA0KICAgICANCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE5XSANCgwgICAgICAgICAgICAgICAgICAgICAg SVBGSVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgICAg ICAgICArLS0tLS0tLS0tKyAgRElBTUVURVIgICAgKy0tLS0tLS0tLSsgDQogICAgICAgICAgIHwg IEFBQS1TICB8LS0tLS0tLS0tLS0tLT58ICBBQUEtUyAgfCANCiAgICAgICAgICAgKy0tLS0tLS0t LSsgICAgICAgICAgICAgICstLS0tLS0tLS0rIA0KICAgICAgICAgICAgICAgIF4gDQogICAgICAg ICAgICAgICAgfCANCiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgDQogICAgICAgIHwgICAg IEFTTSAgICAgICAgICB8IA0KICAgICAgICB8ICArLS0tLS0tLS0tLS0tKyAgfCANCiAgICAgICAg fCAgfCAgQ29sbGVjdG9yIHwgIHwgDQogICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0rIA0KICAg ICAgICAgICAgICAgIF4gDQogICAgICAgICAgICAgICAgfCBJUEZJWCANCiAgICAgICAgICAgICAg ICB8IA0KICAgICAgICAgICstLS0tLS0tLS0tLS0rIA0KICAgICAgICAgIHwgIEV4cG9ydGVyICB8 IA0KICAgICAgICAgICstLS0tLS0tLS0tLS0rIA0KICAgICANCiAgICBGaWd1cmUgMzogSVBGSVgg Y29ubmVjdHMgdG8gQUFBIHNlcnZlciB2aWEgQVNNIA0KICANCiAgMy41IElQRklYIGFuZCBSVEZN ICANCiAgIA0KICAgIFRoZSBSZWFsLXRpbWUgVHJhZmZpYyBGbG93IE1lYXN1cmVtZW50IChSVEZN KSB3b3JraW5nIGdyb3VwIA0KICAgIGRlZmluZWQgYW4gYXJjaGl0ZWN0dXJlIGZvciBmbG93IG1l YXN1cmVtZW50IFtSRkMyNzIyXS4gVGhpcyANCiAgICBzZWN0aW9uIGNvbXBhcmVzIHRoZSBSZWFs LXRpbWUgVHJhZmZpYyBGbG93IE1lYXN1cmVtZW50IChSVEZNKSANCiAgICBmcmFtZXdvcmsgd2l0 aCB0aGUgSVBGSVggZnJhbWV3b3JrLiAgDQogICAgICAgICAgDQogMy41LjEgICBBcmNoaXRlY3R1 cmUgDQogIA0KICAgIFRoZSBSVEZNIGFyY2hpdGVjdHVyZSBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhl IElQRklYIGFyY2hpdGVjdHVyZS4gDQogICAgSXQgZGVmaW5lcyBtZXRlciwgbWV0ZXIgcmVhZGVy IGFuZCBhIG1hbmFnZXIgYXMgYnVpbGRpbmcgYmxvY2tzIA0KICAgIG9mIHRoZSBtZWFzdXJlbWVu dCBhcmNoaXRlY3R1cmUuIFRoZSBtYW5hZ2VyIGNvbmZpZ3VyZXMgdGhlIA0KICAgIG1ldGVyIGFu ZCB0aGUgbWV0ZXIgcmVhZGVyIGNvbGxlY3RzIGRhdGEgZnJvbSB0aGUgbWV0ZXIuICANCiAgICBJ biBSVEZNIHRoZSBidWlsZGluZyBibG9ja3MgY29tbXVuaWNhdGUgdmlhIFNOTVAuICANCiAgICBU aGUgSVBGSVggYXJjaGl0ZWN0dXJlIFtJUEZJWC1BUkNIXSBkZWZpbmVzIG1ldGVyaW5nLCBleHBv cnRpbmcgDQogICAgYW5kIGNvbGxlY3RpbmcgcHJvY2Vzc2VzLiBJUEZJWCBzcGVha3MgYWJvdXQg cHJvY2Vzc2VzIGluc3RlYWQgDQogICAgb2YgZGV2aWNlcyB0byBjbGFyaWZ5IHRoYXQgbXVsdGlw bGUgb2YgdGhvc2UgcHJvY2Vzc2VzIG1heSBiZSANCiAgICBjb2xsb2NhdGVkIG9uIHRoZSBzYW1l IG1hY2hpbmUuIA0KICAgIEJvdGggZGVmaW5pdGlvbnMgZG8gbm90IGNvbnRyYWRpY3QgZWFjaCBv dGhlci4gT25lIGNvdWxkIHNlZSB0aGUgDQogICAgbWV0ZXJpbmcgcHJvY2VzcyBhcyBwYXJ0IG9m IHRoZSBtZXRlciBhbmQgdGhlIGNvbGxlY3RpbmcgcHJvY2VzcyANCiAgICBhcyBwYXJ0IG9mIHRo ZSBtZXRlciByZWFkZXIuICAgDQogICAgIA0KICAgIE9uZSBkaWZmZXJlbmNlIGlzIHRoYXQgSVBG SVggY3VycmVudGx5IGRvZXMgbm90IGRlZmluZSBhIA0KICAgIG1hbmFnaW5nIHByb2Nlc3MsIGJl Y2F1c2UgcmVtb3RlIGNvbmZpZ3VyYXRpb24gd2FzIGF0IGxlYXN0IA0KICAgIGluaXRpYWxseSBv dXQgb2Ygc2NvcGUgZm9yIHRoZSB3b3JraW5nIGdyb3VwLiANCiAgICAgDQogMy41LjIgICAgRmxv dyBEZWZpbml0aW9uIA0KICAgICAgDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwg Q2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjBdIA0KDCAgICAgICAgICAg ICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoN Cg0KDQogICAgUlRGTSBhbmQgSVBGSVggYm90aCBjb25zaWRlciBmbG93cyBhcyBhIGdyb3VwIG9m IHBhY2tldHMgd2hpY2ggDQogICAgc2hhcmUgYSBjb21tb24gc2V0IG9mIHByb3BlcnRpZXMuIEEg ZmxvdyBpcyBjb21wbGV0ZWx5IHNwZWNpZmllZCANCiAgICBieSB0aGF0IHNldCBvZiB2YWx1ZXMs IHRvZ2V0aGVyIHdpdGggYSB0ZXJtaW5hdGlvbiBjcml0ZXJpb24gDQogICAgKGxpa2UgaW5hY3Rp dml0eSB0aW1lb3V0KS4gDQogICAgIA0KICAgIEEgZGlmZmVyZW5jZSBpcyB0aGF0IFJURk0gZGVm aW5lcyBmbG93cyBhcyBiaWRpcmVjdGlvbmFsLiBBbiANCiAgICBSVEZNIG1ldGVyIG1hdGNoZXMg cGFja2V0cyBmcm9tIEIgdG8gQSBhbmQgQSB0byBCIGFzIHNlcGFyYXRlIA0KICAgIHBhcnRzIG9m IGEgc2luZ2xlIGZsb3csIGFuZCBtYWludGFpbnMgdHdvIHNldHMgb2YgcGFja2V0IGFuZCANCiAg ICBieXRlIGNvdW50ZXJzLCBvbmUgZm9yIGVhY2ggZGlyZWN0aW9uLiAgDQogIA0KICAgIElQRklY IGRvZXMgbm90IGV4cGxpY2l0bHkgc3RhdGUgd2hldGhlciBmbG93cyBhcmUgdW5pLSBvciANCiAg ICBiaWRpcmVjdGlvbmFsLiBOZXZlcnRoZWxlc3MgaW5mb3JtYXRpb24gZWxlbWVudHMgZm9yIGRl c2NyaWJpbmcgDQogICAgZmxvdyBwcm9wZXJ0aWVzIHdlcmUgZGVmaW5lZCBvbmx5IGZvciBvbmUg ZGlyZWN0aW9uIGluIFtJUEZJWC0NCiAgICBJTkZPXS4gTmV2ZXJ0aGVsZXNzLCB0aGVyZSBhcmUg c2V2ZXJhbCBzb2x1dGlvbnMgZm9yIHJlcG9ydGluZyANCiAgICBiaS1kaXJlY3Rpb25hbCBmbG93 IGluZm9ybWF0aW9uIChzZWUgc2VjdGlvbiA0LjYpLiANCiAgDQogMy41LjMgICBDb25maWd1cmF0 aW9uIGFuZCBNYW5hZ2VtZW50ICANCiAgICAgDQogICAgSW4gUlRGTSwgcmVtb3RlIGNvbmZpZ3Vy YXRpb24gaXMgdGhlIG9ubHkgd2F5IHRvIGNvbmZpZ3VyZSBhIA0KICAgIG1ldGVyLiBUaGlzIGlz IGRvbmUgYnkgdXNpbmcgU05NUCBhbmQgYSBzcGVjaWZpYyBNZXRlciBNSUIgDQogICAgW1JGQzI3 MjBdLiBUaGUgSVBGSVggZ3JvdXAgY3VycmVudGx5IGRvZXMgbm90IGFkZHJlc3MgSVBGSVggDQog ICAgcmVtb3RlIGNvbmZpZ3VyYXRpb24uIA0KICAgICANCiAgICBJUEZJWCBtZXRlcmluZyBwcm9j ZXNzZXMgZXhwb3J0IHRoZSBsYXlvdXQgb2YgZGF0YSB3aXRoaW4gdGhlaXIgDQogICAgdGVtcGxh dGVzLCBmcm9tIHRpbWUgdG8gdGltZS4gSVBGSVggY29sbGVjdGluZyBwcm9jZXNzZXMgdXNlIA0K ICAgIHRoYXQgdGVtcGxhdGUgaW5mb3JtYXRpb24gdG8gZGV0ZXJtaW5lIGhvdyB0aGV5IHNob3Vs ZCBpbnRlcnByZXQgDQogICAgdGhlIElQRklYIGZsb3cgZGF0YSB0aGV5IHJlY2VpdmUuIA0KICAg ICANCiAzLjUuNCAgIERhdGEgQ29sbGVjdGlvbiANCiAgICAgDQogICAgT25lIG1ham9yIGRpZmZl cmVuY2UgYmV0d2VlbiBJUEZJWCBhbmQgUlRGTSBpcyB0aGUgZGF0YSANCiAgICBjb2xsZWN0aW9u IG1vZGVsLiBSVEZNIHJldHJpZXZlcyBkYXRhIGluIHB1bGwgbW9kZSB3aGVyZWFzIElQRklYIA0K ICAgIHVzZXMgYSBwdXNoIG1vZGUgbW9kZWwgdG8gc2VuZCBkYXRhIHRvIGNvbGxlY3RpbmcgcHJv Y2Vzc2VzLiAgDQogICAgIA0KICAgIEFuIFJURk0gbWV0ZXIgcmVhZGVyIHB1bGxzIGRhdGEgZnJv bSBhIG1ldGVyIGJ5IHVzaW5nIFNOTVAuIFNOTVAgDQogICAgc2VjdXJpdHkgb24gdGhlIG1ldGVy IGRldGVybWluZXMgd2hldGhlciBhIHJlYWRlciBpcyBhbGxvd2VkIHRvIA0KICAgIHB1bGwgZGF0 YSBmcm9tIGl0LiBBbiBJUEZJWCBleHBvcnRpbmcgcHJvY2VzcyBpcyBjb25maWd1cmVkIHRvIA0K ICAgIGV4cG9ydCByZWNvcmRzIHRvIGEgc3BlY2lmaWVkIGxpc3Qgb2YgSVBGSVggY29sbGVjdGlu ZyANCiAgICBwcm9jZXNzZXMuIFRoZSBjb25kaXRpb24gd2hlbiB0byBzZW5kIElQRklYIHJlY29y ZHMgKGUuZy4gZmxvdyANCiAgICB0ZXJtaW5hdGlvbikgaGFzIHRvIGJlIGNvbmZpZ3VyZWQgaW4g dGhlIGV4cG9ydGluZyBvciBtZXRlcmluZyANCiAgICBwcm9jZXNzLiANCiAgDQogMy41LjUgICBE YXRhIE1vZGVsIERldGFpbHMgIA0KICANCiAgICBSVEZNIGRlZmluZXMgYWxsIGl0cyBhdHRyaWJ1 dGVzIGluIHRoZSBSVEZNIE1ldGVyIE1JQiBbUkZDMjcyMF0uIA0KICAgIElQRklYIGluZm9ybWF0 aW9uIGVsZW1lbnRzIGFyZSBkZWZpbmVkIGluIFtJUEZJWC1JTkZPXS4gDQogICAgIA0KDQoNCg0K DQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDIxXSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0 eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgIFJURk0gdXNlcyBjb250aW51b3Vz bHktaW5jcmVtZW50aW5nIDY0LWJpdCBjb3VudGVycyBmb3IgdGhlIA0KICAgIHN0b3JhZ2Ugb2Yg dGhlIG51bWJlciBvZiBwYWNrZXRzIG9mIGEgZmxvdy4gVGhlIGNvdW50ZXJzIGFyZSANCiAgICBu ZXZlciByZXNldCBhbmQganVzdCB3cmFwIGJhY2sgdG8gemVybyBpZiB0aGUgbWF4aW11bSB2YWx1 ZSBpcyANCiAgICBleGNlZWRlZC4gRmxvd3MgY2FuIGJlIHJlYWQgYXQgYW55IHRpbWUuIFRoZSBk aWZmZXJlbmNlIGJldHdlZW4gDQogICAgY291bnRlciByZWFkaW5ncyBnaXZlcyB0aGUgY291bnRz IGZvciBhY3Rpdml0eSBpbiB0aGUgaW50ZXJ2YWwgDQogICAgYmV0d2VlbiByZWFkaW5ncy4gDQog ICAgIA0KICAgIElQRklYIGFsbG93cyBhYnNvbHV0ZSAodG90YWxDb3VudGVyKSBhbmQgcmVsYXRp dmUgY291bnRlcnMgDQogICAgKGRlbHRhQ291bnRlcikgW0lQRklYLUlORk9dLiBUaGUgdG90YWxD b3VudGVyIGlzIG5ldmVyIHJlc2V0IGFuZCANCiAgICBqdXN0IHdyYXBzIHRvIHplcm8gaWYgdmFs dWVzIGFyZSB0b28gbGFyZ2UsIGV4YWN0bHkgYXMgdGhlIA0KICAgIGNvdW50ZXJzIHVzZWQgaW4g UlRGTS4gVGhlIGRlbHRhQ291bnRlciBpcyByZXNldCB0byB6ZXJvIHdoZW4gDQogICAgdGhlIGFz c29jaWF0ZWQgZmxvdyByZWNvcmQgaXMgZXhwb3J0ZWQuIA0KICANCiAzLjUuNiAgIFRyYW5zcG9y dCBQcm90b2NvbCAgDQogICAgICAgICAgDQogICAgUlRGTSBoYXMgYSBzdGFuZGFyZHMtdHJhY2sg TWV0ZXIgTUlCIFtSRkMyNzIwXSwgd2hpY2ggaXMgdXNlZCANCiAgICBib3RoIHRvIGNvbmZpZ3Vy ZSBhIG1ldGVyIGFuZCB0byBzdG9yZSBtZXRlcmluZyByZXN1bHRzLiAgVGhlIA0KICAgIE1JQiBw cm92aWRlcyBhIHdheSB0byByZWFkIGxpc3RzIG9mIGF0dHJpYnV0ZXMgd2l0aCBhIHNpbmdsZSAN CiAgICBPYmplY3QgSWRlbnRpZmllciAoY2FsbGVkIGEgJ3BhY2thZ2UnKSwgd2hpY2ggcmVkdWNl cyB0aGUgU05NUCANCiAgICBvdmVyaGVhZCBmb3IgZmxvdyBkYXRhIGNvbGxlY3Rpb24uIFNOTVAs IG9mIGNvdXJzZSwgbm9ybWFsbHkgDQogICAgdXNlcyBVRFAgYXMgaXRzIHRyYW5zcG9ydCBwcm90 b2NvbC4gU2luY2UgUlRGTSByZXF1aXJlcyBhIA0KICAgIHJlbGlhYmxlIGZsb3cgZGF0YSB0cmFu c3BvcnQgc3lzdGVtLCBhbiBSVEZNIG1ldGVyIHJlYWRlciBtdXN0IA0KICAgIHRpbWUgb3V0IGFu ZCByZXNlbmQgdW5hbnN3ZXJlZCBTTk1QIHJlcXVlc3RzLiBBcGFydCBmcm9tIGJlaW5nIA0KICAg IGNsdW1zeSwgdGhpcyBjYW4gbGltaXQgdGhlIG1heGltdW0gZGF0YSB0cmFuc2ZlciByYXRlIGZy b20gbWV0ZXIgDQogICAgdG8gbWV0ZXIgcmVhZGVyLiANCiAgICAgDQogICAgSVBGSVggaXMgZGVz aWduZWQgdG8gd29yayBvdmVyIGEgdmFyaWV0eSBvZiBkaWZmZXJlbnQgdHJhbnNwb3J0IA0KICAg IHByb3RvY29scy4gIFNDVFAgW1JGQzI5NjBdIGFuZCBTQ1RQLVBSIFtSRkMzNzU4XSBhcmUgbWFu ZGF0b3J5LiAgDQogICAgVURQIGFuZCBUQ1AgYXJlIG9wdGlvbmFsLiAgSW4gYWRkaXRpb24sIHRo ZSBJUEZJWCBwcm90b2NvbCANCiAgICBlbmNvZGVzIGRhdGEgbXVjaCBtb3JlIGVmZmljaWVudGx5 IHRoYW4gU05NUCBkb2VzLCBoZW5jZSBJUEZJWCANCiAgICBoYXMgbG93ZXIgZGF0YSB0cmFuc3Bv cnQgb3ZlcmhlYWRzIHRoYW4gUlRGTS4gDQogIA0KIDMuNS43ICAgU3VtbWFyeSANCiAgICAgDQog ICAgSVBGSVggZXhwb3J0cyBmbG93IGluZm9ybWF0aW9uIGluIHB1c2ggbW9kZWwgYnkgdXNpbmcg U0NUUCwgVENQIA0KICAgIG9yIFVEUC4gSXQgY3VycmVudGx5IGRvZXMgbm90IGFkZHJlc3MgcmVt b3RlIGNvbmZpZ3VyYXRpb24uIFJURk0gDQogICAgZGF0YSBjb2xsZWN0aW9uIGlzIHVzaW5nIHRo ZSBwdWxsIG1vZGVsIGFuZCBydW5zIG92ZXIgU05NUC4gUlRGTSANCiAgICBhZGRyZXNzZXMgcmVt b3RlIGNvbmZpZ3VyYXRpb24gd2hpY2ggYWxzbyBydW5zIG92ZXIgU05NUC4gQm90aCANCiAgICBm cmFtZXdvcmtzIGFsbG93IGEgdmVyeSBmbGV4aWJsZSBmbG93IGRlZmluaXRpb24sIGFsdGhvdWdo IFJURk0gDQogICAgaXMgYmFzZWQgb24gYSBiaS1kaXJlY3Rpb25hbCBmbG93IGRlZmluaXRpb24u IA0KICAgICANCiA0LiBMaW1pdGF0aW9ucyANCiAgICAgDQogICAgVGhlIGdvYWwgb2YgdGhpcyBz ZWN0aW9uIGlzIHRvIHNob3cgdGhlIGxpbWl0YXRpb25zIG9mIElQRklYIGFuZCANCiAgICB0byBn aXZlIGFkdmljZSB3aGVyZSBub3QgdG8gdXNlIElQRklYIG9yIGluIHdoaWNoIGNhc2VzIA0KICAg IGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgYXJlIHJlcXVpcmVkLiAgDQogICAgIA0KDQoNCg0K DQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtQYWdlIDIyXSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBwbGljYWJpbGl0 eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICA0LjEgVXNpbmcgSVBGSVggZm9yIG90 aGVyIEFwcGxpY2F0aW9ucyB0aGFuIGluIFJGQzM5MTcgDQogICAgIA0KICAgIElQRklYIHByb3Zp ZGVzIGEgZ2VuZXJpYyBleHBvcnQgbWVjaGFuaXNtLiBEdWUgdG8gaXRzIHRlbXBsYXRlIA0KICAg IGJhc2VkIHN0cnVjdHVyZSwgaXQgaXMgYSBxdWl0ZSBmbGV4aWJsZSBwcm90b2NvbC4gTmV0d29y ayANCiAgICBvcGVyYXRvcnMgYW5kIHVzZXJzIG1heSB3YW50IHRvIHVzZSBpdCBhbHNvIGZvciBv dGhlciANCiAgICBhcHBsaWNhdGlvbnMgdGhhbiB0aG9zZSBkZXNjcmliZWQgaW4gW1JGQzM5MTdd LiANCiAgICAgDQogICAgQXBhcnQgZnJvbSBzZW5kaW5nIHJhdyBmbG93IGluZm9ybWF0aW9uIGl0 IGNhbiBiZSB1c2VkIHRvIHNlbmQgDQogICAgYWdncmVnYXRlZCBvciBwb3N0LXByb2Nlc3NlZCBk YXRhLiBGb3IgdGhpcyBuZXcgdGVtcGxhdGVzIGFuZCANCiAgICBpbmZvcm1hdGlvbiBlbGVtZW50 cyBjYW4gYmUgZGVmaW5lZCBpZiBuZWVkZWQuIER1ZSB0byBpdHMgcHVzaCANCiAgICBtb2RlIG9w ZXJhdGlvbiBJUEZJWCBpcyBhbHNvIHN1aXRlZCB0byBzZW5kIG5ldHdvcmsgaW5pdGlhdGVkIA0K ICAgIGV2ZW50cyBsaWtlIGFsYXJtcyBhbmQgb3RoZXIgbm90aWZpY2F0aW9ucy4gSXQgY2FuIGJl IHVzZWQgZm9yIA0KICAgIGV4Y2hhbmdpbmcgaW5mb3JtYXRpb24gYW1vbmcgbmV0d29yayBub2Rl cyB0byBhdXRvbm9tb3VzbHkgDQogICAgaW1wcm92ZSBuZXR3b3JrIG9wZXJhdGlvbi4gICANCiAg DQogICAgTmV2ZXJ0aGVsZXNzLCB0aGUgSVBGSVggZGVzaWduIGlzIGJhc2VkIG9uIHRoZSByZXF1 aXJlbWVudHMgdGhhdCANCiAgICBvcmlnaW5hdGUgb25seSBmcm9tIHRoZSB0YXJnZXQgYXBwbGlj YXRpb25zIHN0YXRlZCBpbiBbUkZDMzkxN10uIA0KICAgIFVzaW5nIElQRklYIGZvciBvdGhlciBw dXJwb3NlcyByZXF1aXJlcyBhIGNhcmVmdWwgY2hlY2tpbmcgb2YgDQogICAgSVBGSVggY2FwYWJp bGl0aWVzIGFnYWluc3QgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRzLiBPbmx5IHdpdGggDQogICAg dGhpcywgY2FuIG9uZSBkZWNpZGUgd2hldGhlciBJUEZJWCBpcyBhIHN1aXRhYmxlIHByb3RvY29s IHRvIA0KICAgIG1lZXQgdGhlIG5lZWRzIG9mIGEgc3BlY2lmaWMgYXBwbGljYXRpb24uIA0KICAg ICANCiAgNC4yIFVzaW5nIElQRklYIGZvciBCaWxsaW5nIChSZWxpYWJpbGl0eSBMaW1pdGF0aW9u cykgDQogIA0KICAgIFRoZSByZWxpYWJpbGl0eSByZXF1aXJlbWVudHMgZGVmaW5lZCBpbiBbUkZD MzkxN10gYXJlIG5vdCANCiAgICBzdWZmaWNpZW50IHRvIGd1YXJhbnRlZSB0aGUgbGV2ZWwgb2Yg cmVsaWFiaWxpdHkgdGhhdCBpcyBuZWVkZWQgDQogICAgZm9yIGNvbW1lcmNpYWwgZ3JhZGUgYmls bGluZyBzeXN0ZW1zLiBTdWNoIHJlbGlhYmlsaXR5IA0KICAgIHJlcXVpcmVtZW50cyBhcmUgZGlz Y3Vzc2VkIGluIFtSRkMyOTc1XS4gSW4gcGFydGljdWxhciBJUEZJWCANCiAgICBkb2VzIG5vdCBz dXBwb3J0IHRoZSBmb2xsb3dpbmcgZmVhdHVyZXMgcmVxdWlyZWQgYnkgW1JGQzI5NzVdOiANCiAg ICAgDQogICAgLSBSZWNvcmQgbG9zczogSVBGSVggYWxsb3dzIHRoZSB1c2FnZSBvZiBkaWZmZXJl bnQgdHJhbnNwb3J0IA0KICAgICAgIHByb3RvY29scyBmb3IgdGhlIHRyYW5zZmVyIG9mIGRhdGEg cmVjb3Jkcy4gUmVzaWxpZW5jZSBhZ2FpbnN0IA0KICAgICAgIHRoZSBsb3NzIG9mIElQRklYIGRh dGEgcmVjb3JkcyBjYW4gYmUgb25seSBwcm92aWRlZCBpZiBUQ1Agb3IgDQogICAgICAgU0NUUC1Q UiBpcyB1c2VkIGZvciB0aGUgdHJhbnNmZXIgb2YgZGF0YSByZWNvcmRzLiANCiAgICAtIE5ldHdv cmsgb3IgZGV2aWNlIGZhaWx1cmVzOiBJUEZJWCBkb2VzIGFsbG93IHRoZSB1c2FnZSBvZiANCiAg ICAgICBtdWx0aXBsZSBjb2xsZWN0b3JzIGZvciBvbmUgZXhwb3J0ZXIsIGJ1dCBpdCBkb2VzIG5l aXRoZXIgDQogICAgICAgc3BlY2lmeSBub3IgZGVtYW5kIHRoZSB1c2FnZSBvZiBtdWx0aXBsZSBj b2xsZWN0b3JzIGZvciB0aGUgDQogICAgICAgcHJvdmlzaW9uaW5nIG9mIGZhdWx0IHRvbGVyYW5j ZS4gIA0KICAgIC0gRGV0ZWN0aW9uIGFuZCBlbGltaW5hdGlvbiBvZiBkdXBsaWNhdGUgcmVjb3Jk czogVGhpcyBpcyANCiAgICAgICBjdXJyZW50bHkgbm90IHN1cHBvcnRlZCBieSBJUEZJWC4gDQog ICAgLSBBcHBsaWNhdGlvbiBsYXllciBhY2tub3dsZWRnZW1lbnRzOiBJUEZJWCBkb2VzIG5vdCBz dXBwb3J0IHRoZSANCiAgICAgICBjb250cm9sIG9mIG1lYXN1cmVtZW50IGFuZCBleHBvcnRpbmcg cHJvY2Vzc2VzIGJ5IGhpZ2hlciBsZXZlbCANCiAgICAgICBhcHBsaWNhdGlvbnMuIEFwcGxpY2F0 aW9uIGxheWVyIGFja25vd2xlZGdlbWVudHMgYXJlIG5lY2Vzc2FyeSANCiAgICAgICBlLmcuIHRv IGluZm9ybSB0aGUgZXhwb3J0ZXIgaW4gY2FzZSB0aGUgYXBwbGljYXRpb24gaXMgbm90IA0KICAg ICAgIGFibGUgdG8gcHJvY2VzcyB0aGUgZGF0YSBleHBvcnRlZCB3aXRoIElQRklYLiBTdWNoIA0K ICAgICAgIGFja25vd2xlZGdlbWVudHMgYXJlIG5vdCBzdXBwb3J0ZWQgaW4gSVBGSVguIA0KICAN Cg0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtQYWdlIDIzXSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBGSVggQXBw bGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgIEZ1cnRoZXIgZmVh dHVyZXMgbGlrZSBhcmNoaXZhbCBhY2NvdW50aW5nIGFuZCBwcmUtYXV0aG9yaXphdGlvbiwgDQog ICAgYXJlIG91dCBvZiBzY29wZSBvZiB0aGUgSVBGSVggc3BlY2lmaWNhdGlvbiBidXQgbmVlZCB0 byBiZSANCiAgICByZWFsaXplZCBpbiBiaWxsaW5nIHN5c3RlbSBhcmNoaXRlY3R1cmVzIGFzIGRl c2NyaWJlZCBpbiANCiAgICBbUkZDMjk3NV0uIA0KICAgICANCiAgNC4zIFVzaW5nIGEgRGlmZmVy ZW50IFRyYW5zcG9ydCBQcm90b2NvbCB0aGFuIFNDVFAgDQogICAgIA0KICAgIFNDVFAgaXMgdGhl IHByZWZlcnJlZCBwcm90b2NvbCBmb3IgSVBGSVgsIGkuZS4gYSBjb25mb3JtaW5nIA0KICAgIGlt cGxlbWVudGF0aW9uIG11c3Qgd29yayBvdmVyIFNDVFAuIEFsdGhvdWdoIElQRklYIGNhbiBhbHNv IHdvcmsgDQogICAgb3ZlciBUQ1Agb3IgVURQLCBib3RoIHByb3RvY29scyBoYXZlIGRyYXdiYWNr cyBbSVBGSVgtUFJPVE9dLiANCiAgICBVc2VycyBzaG91bGQgbWFrZSBzdXJlIHRoZXkgaGF2ZSBn b29kIHJlYXNvbnMgYmVmb3IgdXNpbmcgDQogICAgcHJvdG9jb2xzIG90aGVyIHRoYW4gU0NUUCBp biBhIHNwZWNpZmljIGVudmlyb25tZW50LiANCiAgICAgDQogIDQuNCBQdXNoIHZzLiBQdWxsIE1v ZGUgDQogICAgIA0KICAgIElQRklYIHdvcmtzIGluIHB1c2ggbW9kZS4gVGhhdCBtZWFucyBJUEZJ WCByZWNvcmRzIGFyZSANCiAgICBhdXRvbWF0aWNhbGx5IGV4cG9ydGVkIHdpdGhvdXQgd2FpdGlu ZyBmb3IgYSByZXF1ZXN0LiAgDQogICAgVGhlIHJlc3BvbnNpYmlsaXR5IGZvciBpbml0aWF0aW5n IGEgZGF0YSBleHBvcnQgbGllcyB3aXRoIHRoZSANCiAgICBleHBvcnRpbmcgcHJvY2Vzcy4gIA0K ICAgICANCiAgICBDcml0ZXJpYSBmb3IgZXhwb3J0aW5nIGRhdGEgbmVlZCB0byBiZSBjb25maWd1 cmVkIGF0IHRoZSANCiAgICBleHBvcnRpbmcgcHJvY2Vzcy4gVGhlcmVmb3JlIHB1c2ggbW9kZSBo YXMgbW9yZSBiZW5lZml0cyBpZiB0aGUgDQogICAgdHJpZ2dlciBmb3IgZGF0YSBleHBvcnQgaXMg cmVsYXRlZCB0byBldmVudHMgYXQgdGhlIGV4cG9ydGluZyANCiAgICBwcm9jZXNzIChlLmcuIGZs b3cgdGVybWluYXRpb24sIG1lbW9yeSBzaG9ydGFnZSBkdWUgdG8gbGFyZ2UgDQogICAgYW1vdW50 IG9mIGZsb3dzLCBldGMuKS4gSWYgdGhlIHByb3RvY29sIHVzZWQgcHVsbCBtb2RlLCB0aGUgDQog ICAgZXhwb3J0aW5nIHByb2Nlc3Mgd291bGQgbmVlZCB0byB3YWl0IGZvciBhIHJlcXVlc3QgdG8g c2VuZCB0aGUgDQogICAgZGF0YS4gV2l0aCBwdXNoIG1vZGUgaXQgY2FuIHNlbmQgZGF0YSBpbW1l ZGlhdGVseSBlLmcuIGJlZm9yZSANCiAgICBtZW1vcnkgc2hvcnRhZ2Ugd291bGQgcmVxdWlyZSBh IGRpc2NhcmRpbmcgb2YgZGF0YS4gDQogICAgIA0KICAgIFdpdGggcHVzaCBtb2RlIG9uZSBjYW4g cHJldmVudCB0aGUgb3ZlcmxvYWRpbmcgb2YgcmVzb3VyY2VzIGF0IA0KICAgIHRoZSBleHBvcnRp bmcgcHJvY2VzcyBieSBzaW1wbHkgZXhwb3J0aW5nIHRoZSBpbmZvcm1hdGlvbiBhcyANCiAgICBz b29uIGFzIGNlcnRhaW4gdGhyZXNob2xkcyBhcmUgYWJvdXQgdG8gYmUgZXhjZWVkZWQuIFRoZXJl Zm9yZSANCiAgICBleHBvcnRpbmcgY3JpdGVyaWEgYXJlIG9mdGVuIHJlbGF0ZWQgdG8gdHJhZmZp YyBjaGFyYWN0ZXJpc3RpY3MgDQogICAgKGUuZy4gZmxvdyB0aW1lb3V0KSBvciByZXNvdXJjZSBs aW1pdGF0aW9ucyAoZS5nLiBzaXplIG9mIGZsb3cgDQogICAgY2FjaGUpLiBCdXQgdHJhZmZpYyBj aGFyYWN0ZXJpc3RpY3MgYXJlIHVzdWFsbHkgcXVpdGUgZHluYW1pYyANCiAgICBhbmQgb2Z0ZW4g aW1wb3NzaWJsZSB0byBwcmVkaWN0LiBJZiB0aG9zZSBhcmUgdXNlZCB0byB0cmlnZ2VyIA0KICAg IGZsb3cgZXhwb3J0LCB0aGUgZXhwb3J0aW5nIHJhdGUgYW5kIHRoZSByZXNvdXJjZSBjb25zdW1w dGlvbiBmb3IgDQogICAgZmxvdyBleHBvcnQgYmVjb21lcyB2YXJpYWJsZSBhbmQgdW5wcmVkaWN0 YWJsZS4gIA0KICAgICANCiAgICBQdWxsIG1vZGUgaGFzIGFkdmFudGFnZXMgaWYgdGhlIHRyaWdn ZXIgZm9yIGRhdGEgZXhwb3J0IGlzIA0KICAgIHJlbGF0ZWQgdG8gZXZlbnRzIGF0IHRoZSBjb2xs ZWN0aW5nIHByb2Nlc3MgKGUuZy4gYSBzcGVjaWZpYyANCiAgICBhcHBsaWNhdGlvbiByZXF1ZXN0 cyBpbW1lZGlhdGUgaW5wdXQpLiAgDQogICAgIA0KICAgIEluIGEgcHVsbCBtb2RlLCBhIHJlcXVl c3QgY291bGQgc2ltcGx5IGJlIGZvcndhcmRlZCB0byB0aGUgDQogICAgZXhwb3J0aW5nIHByb2Nl c3MuIEluIGEgcHVzaCBtb2RlLCB0aGUgZXhwb3J0aW5nIGNvbmZpZ3VyYXRpb24gDQogICAgbXVz dCBiZSBjaGFuZ2VkIHRvIHRyaWdnZXIgdGhlIGV4cG9ydCBvZiB0aGUgcmVxdWVzdGVkIGRhdGEu IA0KICAgIEZ1cnRoZXJtb3JlLCB3aXRoIHB1bGwgbW9kZSBvbmUgY2FuIHByZXZlbnQgdGhlIG92 ZXJsb2FkaW5nIG9mIA0KDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNl ICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjRdIA0KDCAgICAgICAgICAgICAgICAg ICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQog ICAgdGhlIGNvbGxlY3RpbmcgcHJvY2VzcyBieSB0aGUgYXJyaXZhbCBvZiBtb3JlIHJlY29yZHMg dGhhbiBpdCANCiAgICBjYW4gcHJvY2Vzcy4gDQogICAgIA0KICAgIFdoZXRoZXIgdGhpcyBpcyBh IHJlbGV2YW50IGRyYXdiYWNrIGRlcGVuZHMgb24gdGhlIGZsZXhpYmlsaXR5IA0KICAgIG9mIHRo ZSBJUEZJWCBjb25maWd1cmF0aW9uIGFuZCBob3cgSVBGSVggY29uZmlndXJhdGlvbiBydWxlcyBh cmUgDQogICAgaW1wbGVtZW50ZWQuICAgDQogIA0KICA0LjUgVGVtcGxhdGUgSUQgbnVtYmVyIA0K ICAgICANCiAgICBUaGUgSVBGSVggc3BlY2lmaWNhdGlvbiBsaW1pdHMgdGhlIGRpZmZlcmVudCB0 ZW1wbGF0ZSBJRCBudW1iZXJzIA0KICAgIHRoYXQgY2FuIGJlIGFzc2lnbmVkIHRvIHRoZSBuZXds eSBnZW5lcmF0ZWQgdGVtcGxhdGUgcmVjb3JkcyBpbiANCiAgICBhbiBvYnNlcnZhdGlvbiBkb21h aW4uIEluIHBhcnRpY3VsYXIsIHRlbXBsYXRlIElEcyB1cCB0byAyNTUgYXJlIA0KICAgIHJlc2Vy dmVkIGZvciBUZW1wbGF0ZSBvciBvcHRpb24gc2V0cyAob3Igb3RoZXIgc2V0cyB0byBiZSANCiAg ICBjcmVhdGVkKSBhbmQgdGVtcGxhdGUgSURzIGZyb20gMjU2IHRvIDY1NTM1IGFyZSBhc3NpZ25l ZCB0byBkYXRhIA0KICAgIHNldHMuIEluIHRoZSBjYXNlIG9mIG1hbnkgZXhwb3J0cyByZXF1aXJp bmcgbWFueSBkaWZmZXJlbnQgDQogICAgdGVtcGxhdGVzLCB0aGUgc2V0IG9mIFRlbXBsYXRlIElE cyBjb3VsZCBiZSBleGhhdXN0ZWQuICAgDQogIA0KICA0LjYgRXhwb3J0aW5nIEJpZGlyZWN0aW9u YWwgRmxvdyBJbmZvcm1hdGlvbiANCiAgICAgDQogICAgQWx0aG91Z2ggSVBGSVggZG9lcyBub3Qg ZXhwbGljaXRseSBzdGF0ZSB0aGF0IGZsb3dzIGFyZSANCiAgICB1bmlkaXJlY3Rpb25hbCwgaW5m b3JtYXRpb24gZWxlbWVudHMgdGhhdCBkZXNjcmliZSBmbG93IA0KICAgIGNoYXJhY3RlcmlzdGlj cyBhcmUgZGVmaW5lZCBvbmx5IGZvciBvbmUgZGlyZWN0aW9uIGluIFtJUEZJWC0NCiAgICBJTkZP XS4gW0lQRklYLVBST1RPXSBhbGxvd3MgdGhlIHJlcG9ydGluZyBvZiBtdWx0aXBsZSBpZGVudGlj YWwgDQogICAgaW5mb3JtYXRpb24gZWxlbWVudHMgaW4gb25lIGZsb3cgcmVjb3JkLiBXaXRoIHRo aXMgaW5mb3JtYXRpb24gDQogICAgZWxlbWVudHMgZm9yIGZvcndhcmQgYW5kIHJldmVyc2UgZGly ZWN0aW9uIGNhbiBiZSByZXBvcnRlZCBpbiANCiAgICBvbmUgZmxvdyByZWNvcmQuICANCiAgICAg DQogICAgQnV0IHRoaXMgaXMgbm90IHN1ZmZpY2llbnQuIFVzaW5nIHRoaXMgZmVhdHVyZSBmb3Ig cmVwb3J0aW5nIA0KICAgIGJpZGlyZWN0aW9uYWwgZmxvdyBpbmZvcm1hdGlvbiB3b3VsZCByZXF1 aXJlIGFuIGFncmVlbWVudCBvbiB0aGUgDQogICAgc2VtYW50aWMgb2YgaW5mb3JtYXRpb24gZWxl bWVudHMgKGUuZy4gZmlyc3QgY291bnRlciBpcyBjb3VudGVyIA0KICAgIGZvciB0aGUgZm9yd2Fy ZCBkaXJlY3Rpb24sIHNlY29uZCBjb3VudGVyIGZvciByZXZlcnNlIA0KICAgIGRpcmVjdGlvbiku ICANCiAgICAgDQogICAgQW5vdGhlciBvcHRpb24gaXMgdG8gdXNlIHR3byBhZGphY2VudCBmbG93 IHJlY29yZHMgdG8gcmVwb3J0IA0KICAgIGJvdGggZGlyZWN0aW9ucyBvZiBhIGJpZGlyZWN0aW9u YWwgZmxvdyBzZXBhcmF0ZWx5LiBUaGlzIA0KICAgIGFwcHJvYWNoIHJlcXVpcmVzIGFkZGl0aW9u YWwgbWVhbnMgZm9yIG1hcHBpbmcgdGhvc2UgcmVjb3JkcyBhbmQgDQogICAgaXMgcXVpdGUgaW5l ZmZpY2llbnQgZHVlIHRvIHRoZSByZWR1bmRhbnQgcmVwb3J0aW5nIG9mIGZsb3cgDQogICAga2V5 cy4gDQogICAgIA0KICA0LjcgSVBGSVggYW5kIElQdjYgDQogICAgIA0KICAgIFRoZXJlIGFyZSB0 d28gaXNzdWVzIHRvIGNvbnNpZGVyOiAgDQogICAgIA0KICAgIC0gR2VuZXJhdGlvbiBhbmQgcmVw b3J0aW5nIG9mIElQRklYIHJlY29yZHMgYWJvdXQgSVB2NiB0cmFmZmljIA0KICAgIC0gRXhwb3J0 aW5nIElQRklYIHJlY29yZHMgb3ZlciBJUHY2IA0KICAgICANCg0KDQoNCg0KDQoNCiBac2VieSwg Qm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2Ug MjVdIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAgICAg ICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgVGhlIGdlbmVyYXRpb24gYW5kIHJlcG9ydGluZyBv ZiBJUEZJWCByZWNvcmRzIGFib3V0IElQdjYgdHJhZmZpYyANCiAgICBpcyBwb3NzaWJsZSBhcyBh cHByb3ByaWF0ZSBpbmZvcm1hdGlvbiBlbGVtZW50cyBleGlzdCBpbiBbSVBGSVgtDQogICAgSU5G T10uICANCiAgICBFeHBvcnRpbmcgSVBGSVggcmVjb3JkcyBvdmVyIElQdjYgaXMgbm90IGV4cGxp Y2l0bHkgYWRkcmVzc2VkIGluIA0KICAgIFtJUEZJWC1QUk9UT10uIFNpbmNlIElQRklYIHJ1bnMg b3ZlciBTQ1RQLCBTQ1RQLVBSLCBVRFAgb3IgVENQLCANCiAgICBpdCBpcyB0cml2aWFsIHRvIHJ1 biBJUEZJWCBvdmVyIElQdjYgbmV0d29ya3MsIHByb3ZpZGVkIHRoYXQgdGhlIA0KICAgIHRyYW5z cG9ydCBwcm90b2NvbCBiZWluZyB1c2VkIHRvIGNhcnJ5IElQRklYIGlzIHJ1bm5pbmcgb24gdGhl IA0KICAgIElQdjYgbmV0d29yay4gDQogIA0KICA0LjggUmVtb3RlIENvbmZpZ3VyYXRpb24gDQog ICAgIA0KICAgIFJlbW90ZSBjb25maWd1cmF0aW9uIHdhcyBpbml0aWFsbHkgb3V0IG9mIHNjb3Bl IG9mIHRoZSBJUEZJWCANCiAgICB3b3JraW5nIGdyb3VwIGluIG9yZGVyIHRvIGNvbmNlbnRyYXRl IG9uIHRoZSBwcm90b2NvbCANCiAgICBzcGVjaWZpY2F0aW9uLiBUaGVyZWZvcmUgdGhlcmUgaXMg Y3VycmVudGx5IG5vIHN0YW5kYXJkaXplZCB3YXkgDQogICAgdG8gY29uZmlndXJlIElQRklYIHBy b2Nlc3NlcyByZW1vdGVseS4gTmV2ZXJ0aGVsZXNzIGR1ZSB0byB0aGUgDQogICAgYnJvYWQgbmVl ZCBmb3IgdGhpcyBmZWF0dXJlLCBpdCBpcyBxdWl0ZSBsaWtlbHkgdGhhdCBzb2x1dGlvbnMgDQog ICAgZm9yIHRoaXMgd2lsbCBiZSBzdGFuZGFyZGl6ZWQgc29vbi4gIA0KICANCiA1LiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucyANCiAgICAgDQogICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhl IHVzYWdlIG9mIElQRklYIGluIHZhcmlvdXMgc2NlbmFyaW9zLiANCiAgICBTZWN1cml0eSByZXF1 aXJlbWVudHMgZm9yIElQRklYIHRhcmdldCBhcHBsaWNhdGlvbnMgYW5kIHNlY3VyaXR5IA0KICAg IGNvbnNpZGVyYXRpb25zIGZvciBJUEZJWCBhcmUgYWRkcmVzc2VkIGluIFtSRkMzOTE3XSBhbmQg W0lQRklYLQ0KICAgIFBST1RPXS4gVGhvc2UgcmVxdWlyZW1lbnRzIGhhdmUgdG8gYmUgbWV0IGZv ciB0aGUgdXNhZ2Ugb2YgDQogICAgSVBGSVguIFRvIG91ciBjdXJyZW50IGtub3dsZWRnZSwgdGhl IHVzYWdlIHNjZW5hcmlvcyBwcm9wb3NlZCBpbiANCiAgICBzZWN0aW9uIDIgZG8gbm90IGluZHVj ZSBmdXJ0aGVyIHNlY3VyaXR5IGhhemFyZHMuIA0KICAgICANCiAgICBTZWN0aW9uIDMgb2YgdGhp cyBkb2N1bWVudCBkZXNjcmliZXMgaG93IElQRklYIGNhbiBiZSB1c2VkIGluIA0KICAgIGNvbWJp bmF0aW9uIHdpdGggb3RoZXIgdGVjaG5vbG9naWVzLiBOZXcgc2VjdXJpdHkgaGF6YXJkcyBjYW4g DQogICAgYXJpc2Ugd2hlbiB0d28gaW5kaXZpZHVhbGx5IHNlY3VyZSB0ZWNobm9sb2dpZXMgb3Ig YXJjaGl0ZWN0dXJlcyANCiAgICBhcmUgY29tYmluZWQuIEZvciB0aGUgY29tYmluYXRpb24gb2Yg QUFBIHdpdGggSVBGSVggYW4gDQogICAgYXBwbGljYXRpb24gc3BlY2lmaWMgbW9kdWxlIChBU00p IG9yIGFuIElQRklYIGNvbGxlY3RvciBjYW4gDQogICAgZnVuY3Rpb24gYXMgdHJhbnNpdCBwb2lu dCBmb3IgdGhlIG1lc3NhZ2VzLiBJdCBoYXMgdG8gYmUgZW5zdXJlZCANCiAgICB0aGF0IGF0IHRo aXMgcG9pbnQgdGhlIGFwcGxpZWQgc2VjdXJpdHkgbWVjaGFuaXNtcyAoZS5nLiANCiAgICBlbmNy eXB0aW9uIG9mIG1lc3NhZ2VzKSBhcmUgbWFpbnRhaW5lZC4gDQogICAgIA0KIDYuIElBTkEgQ29u c2lkZXJhdGlvbnMgDQogICAgIA0KICAgIFRoaXMgZG9jdW1lbnQgaGFzIG5vIGFjdGlvbnMgZm9y IElBTkEuIA0KICAgICANCiA3LiBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgDQogICAgIA0KICAgIFtJ UEZJWC1JTkZPXSBKLiBRdWl0dGVrLCBTLiBCcnlhbnQsIEouIE1leWVyLCAiSW5mb3JtYXRpb24g TW9kZWwgDQogICAgICAgICAgICAgICAgICBmb3IgSVAgRmxvdyBJbmZvcm1hdGlvbiBFeHBvcnQi LCBJbnRlcm5ldCBEcmFmdCANCiAgICAgICAgICAgICAgICAgIDxkcmFmdC1pZXRmLWlwZml4LWlu Zm8tMDc+LCB3b3JrIGluIHByb2dyZXNzLCBNYXkgDQogICAgICAgICAgICAgICAgICAyMDA1IA0K ICAgICANCg0KDQoNCg0KDQogWnNlYnksIEJvc2NoaSwgQnJvd25sZWUsIENsYWlzZSAgICAgICAg ICAgICAgICAgICAgICAgICAgIFtQYWdlIDI2XSANCgwgICAgICAgICAgICAgICAgICAgICAgSVBG SVggQXBwbGljYWJpbGl0eSAgICAgICAgICAgICAgSnVuZSAyMDA2IA0KDQoNCg0KICAgIFtJUEZJ WC1QUk9UT10gQi4gQ2xhaXNlIChFZGl0b3IpLCAiSVBGSVggUHJvdG9jb2wgU3BlY2lmaWNhdGlv biIsIA0KICAgICAgICAgICAgICAgICAgSW50ZXJuZXQgRHJhZnQgPGRyYWZ0LWlldGYtaXBmaXgt cHJvdG9jb2wtMjEudHh0PiwgDQogICAgICAgICAgICAgICAgICB3b3JrIGluIHByb2dyZXNzLCBB cHJpbCAyMDA2ICANCiAgICAgDQogICAgW1BTQU1QLUlORk9dIFQuIERpZXR6LCBGLiBEcmVzc2xl ciwgRy4gQ2FybGUsIEIuIENsYWlzZSwgDQogICAgICAgICAgICAgICAgICAiSW5mb3JtYXRpb24g TW9kZWwgZm9yIFBhY2tldCBTYW1wbGluZyBFeHBvcnRzIiwgDQogICAgICAgICAgICAgICAgICBJ bnRlcm5ldCBEcmFmdCA8ZHJhZnQtaWV0Zi1wc2FtcC1pbmZvLTA0LnR4dD4sIHdvcmsgDQogICAg ICAgICAgICAgICAgICBpbiBwcm9ncmVzcywgTWFyY2ggMjAwNiANCiAgICAgDQogICAgW1JGQzM5 MTddICAgIEouIFF1aXR0ZWssIFQuIFpzZWJ5LCBCLiBDbGFpc2UsIFMuIFphbmRlciwgDQogICAg ICAgICAgICAgICAgICAiUmVxdWlyZW1lbnRzIGZvciBJUCBGbG93IEluZm9ybWF0aW9uIEV4cG9y dCIsIFJGQyANCiAgICAgICAgICAgICAgICAgIDM5MTcsIE9jdG9iZXIgMjAwNCANCiAgICAgDQog OC4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgDQogICAgIA0KICAgIFtCcm93MDBdICAgICBOZXZp bCBCcm93bmxlZSwgIlBhY2tldCBNYXRjaGluZyBmb3IgTmVUcmFNZXQgDQogICAgICAgICAgICAg ICAgICBEaXN0cmlidXRpb25zIiwgDQogICAgICAgICAgICAgICAgICBodHRwOi8vd3d3Mi5hdWNr bGFuZC5hYy5uei9uZXQvL0ludGVybmV0L3J0Zm0vbWVldGkNCiAgICAgICAgICAgICAgICAgIG5n cy80Ny1hZGVsYWlkZS9wcC1kaXN0LyANCiAgICAgDQogICAgW0R1R3IwMF0gICAgIE5pY2sgRHVm ZmllbGQsIE1hdHRoaWFzIEdyb3NzZ2xhdXNlciwgIlRyYWplY3RvcnkgDQogICAgICAgICAgICAg ICAgICBTYW1wbGluZyBmb3IgRGlyZWN0IFRyYWZmaWMgT2JzZXJ2YXRpb24iLCANCiAgICAgICAg ICAgICAgICAgIFByb2NlZWRpbmdzIG9mIEFDTSBTSUdDT01NIDIwMDAsIFN0b2NraG9sbSwgU3dl ZGVuLCANCiAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyOCAtIFNlcHRlbWJlciAxLCAyMDAwIA0K ICAgICANCiAgICBbR3JETTk4XSAgICAgSWFuIEQuIEdyYWhhbSwgU3RlcGhlbiBGLiBEb25uZWxs eSwgU3RlbGUgTWFydGluLCANCiAgICAgICAgICAgICAgICAgIEplZCBNYXJ0ZW5zLCBKb2huIEcu IENsZWFyeSwgIk5vbmludHJ1c2l2ZSBhbmQgDQogICAgICAgICAgICAgICAgICBBY2N1cmF0ZSBN ZWFzdXJlbWVudCBvZiBVbmlkaXJlY3Rpb25hbCBEZWxheSBhbmQgDQogICAgICAgICAgICAgICAg ICBEZWxheSBWYXJpYXRpb24gb24gdGhlIEludGVybmV0IiwgSU5FVCc5OCwgR2VuZXZhLCANCiAg ICAgICAgICAgICAgICAgIFN3aXR6ZXJsYW5kLCAyMS0yNCBKdWx5LCAxOTk4IA0KICAgICANCiAg ICBbSVBGSVgtQVJDSF0gRy4gU2FkYXNpdmFuLCBOLiBCcm93bmxlZSwgQi4gQ2xhaXNlLCBKLiBR dWl0dGVrLCAgICANCiAgICAgICAgICAgICAgICAgICJBcmNoaXRlY3R1cmUgZm9yIElQIEZsb3cg SW5mb3JtYXRpb24gRXhwb3J0IiwgDQogICAgICAgICAgICAgICAgICBJbnRlcm5ldCBEcmFmdCA8 ZHJhZnQtaWV0Zi1pcGZpeC1hcmNoaXRlY3R1cmUtDQogICAgICAgICAgICAgICAgICAwOC50eHQ+ LCB3b3JrIGluIHByb2dyZXNzLCBNYXJjaCAyMDA1IA0KICAgICANCiAgICBbUFNBTVAtUFJPVE9d IEJlbm9pdCBDbGFpc2UgKEVkLiksIFBhY2tldCBTYW1wbGluZyAoUFNBTVApIA0KICAgICAgICAg ICAgICAgICAgUHJvdG9jb2wgU3BlY2lmaWNhdGlvbnMsIEludGVybmV0IERyYWZ0IDxkcmFmdC0N CiAgICAgICAgICAgICAgICAgIGlldGYtcHNhbXAtcHJvdG9jb2wtMDQudHh0Piwgd29yayBpbiBw cm9ncmVzcywgDQogICAgICAgICAgICAgICAgICBNYXJjaCAyMDA2IA0KICAgICANCiAgICBbUFNB TVAtVEVDSF0gIFQuIFpzZWJ5LCBNLiBNb2xpbmEsIE4uIER1ZmZpZWxkLCBTLiBOaWNjb2xpbmks IEYuIA0KICAgICAgICAgICAgICAgICAgUmFzcGFsbCwgIlNhbXBsaW5nIGFuZCBGaWx0ZXJpbmcg VGVjaG5pcXVlcyBmb3IgSVAgDQogICAgICAgICAgICAgICAgICBQYWNrZXQgU2VsZWN0aW9uIiBJ bnRlcm5ldCBEcmFmdCA8ZHJhZnQtaWV0Zi1wc2FtcC0NCiAgICAgICAgICAgICAgICAgIHNhbXBs ZS10ZWNoLTA3LnR4dD4sIHdvcmsgaW4gcHJvZ3Jlc3MsIEp1bHkgMjAwNSANCiAgICAgDQogICAg W1JGQzI1OThdICAgIFYuIEphY29ic29uLCBLLiBOaWNob2xzLCBLLiBQb2R1cmksICJBbiBFeHBl ZGl0ZWQgDQogICAgICAgICAgICAgICAgICBGb3J3YXJkaW5nIFBIQiIsIFJGQyAyNTk4LCBKdW5l IDE5OTkgDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93bmxlZSwgQ2xhaXNlICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgMjddIA0KDCAgICAgICAgICAgICAgICAgICAgICBJUEZJ WCBBcHBsaWNhYmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIwMDYgDQoNCg0KDQogICAgIA0KICAg IFtSRkMyNjc5XSAgICBHLiBBbG1lcywgUy4gS2FsaWRpbmRpLCBNLiBaZWthdXNrYXMsICJBIE9u ZS13YXkgDQogICAgICAgICAgICAgICAgICBEZWxheSBNZXRyaWMgZm9yIElQUE0iLCBSRkMgMjY3 OSwgU2VwdGVtYmVyIDE5OTkgICANCiAgICAgDQogICAgW1JGQzI2ODBdICAgIEcuIEFsbWVzLCBT LiBLYWxpZGluZGksIE0uIFpla2F1c2thcywgIkEgT25lLXdheSANCiAgICAgICAgICAgICAgICAg IFBhY2tldCBMb3NzIE1ldHJpYyBmb3IgSVBQTSIsUkZDIDI2ODAsIFNlcHRlbWJlciANCiAgICAg ICAgICAgICAgICAgIDE5OTkgDQogICAgIA0KICAgIFtSRkMyNjgxXSAgICBHLiBBbG1lcywgUy4g S2FsaWRpbmRpLCBNLiBaZWthdXNrYXMsICJBIFJvdW5kLXRyaXAgDQogICAgICAgICAgICAgICAg ICBEZWxheSBNZXRyaWMgZm9yIElQUE0iLCBSRkMgMjY4MSwgU2VwdGVtYmVyIDE5OTkgDQogICAg IA0KICAgIFtSRkMyNzAyXSAgICBELiBBd2R1Y2hlLCBKLiBNYWxjb2xtLCBKLiBBZ29nYnVhLCBN LiBPJ0RlbGwsIEouICAgICAgICANCiAgICAgICAgICAgICAgICAgIE1jTWFudXMsICJSZXF1aXJl bWVudHMgZm9yIFRyYWZmaWMgRW5naW5lZXJpbmcgT3ZlciANCiAgICAgICAgICAgICAgICAgIE1Q TFMiLCBSRkMgMjcwMiwgU2VwdGVtYmVyIDE5OTkgDQogICAgIA0KICAgIFtSRkMyNzIwXSAgICBO LiBCcm93bmxlZSwgVHJhZmZpYyBGbG93IE1lYXN1cmVtZW50OiBNZXRlciBNSUIsIA0KICAgICAg ICAgICAgICAgICAgUkZDMjcyMCBPY3RvYmVyIDE5OTkgDQogICAgIA0KICAgIFtSRkMyNzIyXSAg ICBCcm93bmxlZSwgTi4sIE1pbGxzLCBDLiwgRy4gUnV0aCwgIlRyYWZmaWMgRmxvdyANCiAgICAg ICAgICAgICAgICAgIE1lYXN1cmVtZW50OiBBcmNoaXRlY3R1cmUiLCBSRkMgMjcyMiwgT2N0b2Jl ciAxOTk5IA0KICAgICANCiAgICBbUkZDMjkwM10gICAgQy4gZGUgTGFhdCwgRy4gR3Jvc3MsIEwu IEdvbW1hbnMsIEouIFZvbGxicmVjaHQsIEQuIA0KICAgICAgICAgICAgICAgICAgU3BlbmNlLCAi R2VuZXJpYyBBQUEgQXJjaGl0ZWN0dXJlIiwgUkZDIDI5MDMsIA0KICAgICAgICAgICAgICAgICAg QXVndXN0IDIwMDAgDQogICAgIA0KICAgIFtSRkMyOTYwXSAgICBSLiBTdGV3YXJ0IChlZC4pICJT dHJlYW0gQ29udHJvbCBUcmFuc21pc3Npb24gDQogICAgICAgICAgICAgICAgICBQcm90b2NvbCIs IFJGQyAyOTYwLCBPY3RvYmVyIDIwMDAgDQogICAgIA0KICAgIFtSRkMyOTc1XSAgICBCLiBBYm9i YSwgSi4gQXJra28sIEQuIEhhcnJpbmd0b24sICJJbnRyb2R1Y3Rpb24gdG8gDQogICAgICAgICAg ICAgICAgICBBY2NvdW50aW5nIE1hbmFnZW1lbnQiLCBSRkMgMjk3NSwgT2N0b2JlciAyMDAwIA0K ICAgICANCiAgICBbUkZDMzMzMF0gICAgSUFOQSwgIlNwZWNpYWwtVXNlIElQdjQgQWRkcmVzc2Vz IiwgUkZDIDMzMzAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgIFNlcHRl bWJlciAyMDAyIA0KICAgICANCiAgICBbUkZDMzMzNF0gICAgVC4gWnNlYnksIFMuIFphbmRlciwg Ry4gQ2FybGUsICJQb2xpY3ktQmFzZWQgDQogICAgICAgICAgICAgICAgICBBY2NvdW50aW5nIiwg UkZDIDMzMzQsIE9jdG9iZXIgMjAwMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAg ICANCiAgICBbUkZDMzM5M10gICAgQy4gRGVtaWNoZWxpcywgUC4gQ2ltZW50bywgIklQIFBhY2tl dCBEZWxheSANCiAgICAgICAgICAgICAgICAgIFZhcmlhdGlvbiBNZXRyaWMgZm9yIElQUE0iLCBS RkMgMzM5MywgTm92ZW1iZXIgMjAwMiANCiAgICAgDQogICAgW1JGQzM1NzddICAgIFMuIFdhbGRi dXNzZXIsIFIuIENvbGUsIEMuIEthbGJmbGVpc2NoLCANCiAgICAgICAgICAgICAgICAgIEQuUm9t YXNjYW51LCAiSW50cm9kdWN0aW9uIHRvIHRoZSBSZW1vdGUgTW9uaXRvcmluZyANCiAgICAgICAg ICAgICAgICAgIChSTU9OKSBGYW1pbHkgb2YgTUlCIE1vZHVsZSIsIFJGQyAzNTc3LCBBdWd1c3Qg MjAwMyANCiAgICAgDQogICAgW1JGQzM1ODhdICAgIFAuIENhbGhvdW4sIEouIExvdWdobmV5LCBF LiBHdXR0bWFuLCBHLiBab3JuLCBKLiANCiAgICAgICAgICAgICAgICAgIEFya2tvLCAiRGlhbWV0 ZXIgQmFzZSBQcm90b2NvbCIsIFJGQyAzNTg4LCANCiAgICAgICAgICAgICAgICAgIFNlcHRlbWJl ciAyMDAzIA0KICAgICANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2Ug ICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyOF0gDQoMICAgICAgICAgICAgICAgICAg ICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoNCiAg ICBbUkZDMzcyOV0gICAgUy4gV2FsZGJ1c3NlciwgIkFwcGxpY2F0aW9uIFBlcmZvcm1hbmNlIE1l YXN1cmVtZW50IA0KICAgICAgICAgICAgICAgICAgTUlCIiwgUkZDIDM3MjksIE1hcmNoIDIwMDQg DQogICAgIA0KICAgIFtSRkMzNzU4XSAgICBSLiBTdGV3YXJ0LCBNLiBSYW1hbGhvLCBRLiBYaWUs IE0uIFR1ZXhlbiwgUC4gDQogICAgICAgICAgICAgICAgICBDb25yYWQsICJTdHJlYW0gQ29udHJv bCBUcmFuc21pc3Npb24gUHJvdG9jb2wgDQogICAgICAgICAgICAgICAgICAoU0NUUCkgUGFydGlh bCBSZWxpYWJpbGl0eSBFeHRlbnNpb24iLCBSRkMgMzc1OCwgDQogICAgICAgICAgICAgICAgICBN YXkgMjAwNCAgDQogIA0KICAgIFtSRkM0MTUwXSAgICBSLiBEaWV0eiwgUi4gQ29sZSwgIlRyYW5z cG9ydCBQZXJmb3JtYW5jZSBNZXRyaWNzIA0KICAgICAgICAgICAgICAgICAgTUlCIiwgUkZDIDQx NTAsIEF1Z3VzdCAyMDA1IA0KICAgICANCiAgICBbWnNaQzAxXSAgICAgVC4gWnNlYnksIFMuIFph bmRlciwgRy4gQ2FybGUsICJFdmFsdWF0aW9uIG9mIA0KICAgICAgICAgICAgICAgICAgQnVpbGRp bmcgQmxvY2tzIGZvciBQYXNzaXZlIE9uZS13YXktZGVsYXkgDQogICAgICAgICAgICAgICAgICBN ZWFzdXJlbWVudHMiLCBQcm9jZWVkaW5ncyBvZiBQYXNzaXZlIGFuZCBBY3RpdmUgDQogICAgICAg ICAgICAgICAgICBNZWFzdXJlbWVudCBXb3Jrc2hvcCAoUEFNIDIwMDEpLCBBbXN0ZXJkYW0sIFRo ZSANCiAgICAgICAgICAgICAgICAgIE5ldGhlcmxhbmRzLCBBcHJpbCAyMy0yNCwgMjAwMSANCiAg ICAgDQogOS4gQWNrbm93bGVkZ2VtZW50cyANCiAgICAgDQogICAgV2Ugd291bGQgbGlrZSB0byB0 aGFuayB0aGUgZm9sbG93aW5nIHBlcnNvbnMgZm9yIHRoZWlyIA0KICAgIGNvbnRyaWJ1dGlvbiwg ZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCB2YWx1YWJsZSANCiAgICBjb21tZW50 czogDQogICAgIA0KICAgIFNlYmFzdGlhbiBaYW5kZXIgDQogICAgUm9iZXJ0IExvZXdlIA0KICAg IFJlaW5hbGRvIFBlbm5vIA0KICAgIEx1dHogTWFyayANCiAgICBBbmR5IEJpZXJtYW5uIA0KICAg ICANCiAgICBQYXJ0IG9mIHRoZSB3b3JrIGhhcyBiZWVuIGRldmVsb3BlZCBpbiB0aGUgcmVzZWFy Y2ggcHJvamVjdCA2UU0gDQogICAgY28tZnVuZGVkIHdpdGggc3VwcG9ydCBmcm9tIHRoZSBFdXJv cGVhbiBDb21taXNzaW9uLiAgIA0KICAgICANCiAxMC5BdXRob3JzJyBBZGRyZXNzZXMgDQogICAg IA0KICAgIFRhbmphIFpzZWJ5IA0KICAgIEZyYXVuaG9mZXIgSW5zdGl0dXRlIGZvciBPcGVuIENv bW11bmljYXRpb24gU3lzdGVtcyAoRk9LVVMpIA0KICAgIEthaXNlcmluLUF1Z3VzdGEtQWxsZWUg MzEgICANCiAgICAxMDU4OSBCZXJsaW4sIEdlcm1hbnkgICANCiAgICBQaG9uZTogKzQ5IDMwIDM0 NjMgNzE1MyAgIA0KICAgIEVtYWlsOiB6c2VieUBmb2t1cy5maGcuZGUgDQogICAgIA0KICAgIEVs aXNhIEJvc2NoaSANCiAgICBIaXRhY2hpIEV1cm9wZSBTQVMgIA0KICAgIEltbWV1YmxlIExlIFRo ZWxlbWUgIA0KICAgIDE1MDMgUm91dGUgZGVzIERvbGluZXMgIA0KICAgIDA2NTYwIFZhbGJvbm5l LCBGcmFuY2UgIA0KICAgIFBob25lOiArMzMgNCA4OTg3NDE4MCAgICAgDQogICAgRW1haWw6IGVs aXNhLmJvc2NoaUBoaXRhY2hpLWV1LmNvbSAgDQoNCg0KDQoNCiBac2VieSwgQm9zY2hpLCBCcm93 bmxlZSwgQ2xhaXNlICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMjldIA0KDCAgICAg ICAgICAgICAgICAgICAgICBJUEZJWCBBcHBsaWNhYmlsaXR5ICAgICAgICAgICAgICBKdW5lIDIw MDYgDQoNCg0KDQogICAgIA0KICAgIE5ldmlsIEJyb3dubGVlIA0KICAgIENBSURBIChVQ1NEL1NE U0MpIA0KICAgIDk1MDAgR2lsbWFuIERyaXZlIA0KICAgIExhIEpvbGxhLCBDQSA5MjA5My0wNTA1 IA0KICAgIFBob25lIDogKzEgODU4IDUzNCA4MzM4IA0KICAgIEVtYWlsIDogbmV2aWxAY2FpZGEu b3JnIA0KICAgICANCiAgICBCZW5vaXQgQ2xhaXNlIA0KICAgIENpc2NvIFN5c3RlbXMgDQogICAg RGUgS2xlZXRsYWFuIDZhIGIxIA0KICAgIDE4MzEgRGllZ2VtIA0KICAgIEJlbGdpdW0gDQogICAg UGhvbmU6ICszMiAyIDcwNCA1NjIyIA0KICAgIEVtYWlsOiBiY2xhaXNlQGNpc2NvLmNvbSANCiAg ICAgDQogMTEuRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50IA0KICAgICANCiAgICAiQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuIA0K ICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFu ZCBmdXJuaXNoZWQgDQogICAgdG8gb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNv bW1lbnQgb24gb3Igb3RoZXJ3aXNlIA0KICAgIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGluIGl0cyBp bXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIA0KICAgIGNvcGllZCwgcHVibGlzaGVkIGFu ZCBkaXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCANCiAgICByZXN0cmlj dGlvbiBvZiBhbnkga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IA0KICAg IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGll cyBhbmQgDQogICAgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93ZXZlciwgdGhpcyBkb2N1bWVudCBpdHNl bGYgbWF5IG5vdCBiZSANCiAgICBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92 aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIA0KICAgIHJlZmVyZW5jZXMgdG8gdGhlIEludGVy bmV0IFNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgDQogICAgb3JnYW5pemF0aW9ucywgZXhjZXB0 IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyANCiAgICBJbnRlcm5ldCBz dGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyANCiAg ICBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZvbGxv d2VkLCBvciANCiAgICBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50by4gDQogICAgIA0K IDEyLiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50IA0KICAgICANCiAgICBUaGUgSUVU RiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcgdGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIA0K ICAgIGFueSBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0 IG1pZ2h0IGJlIA0KICAgIGNsYWltZWQgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24g b3IgdXNlIG9mIHRoZSANCiAgICB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50 IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IA0KICAgIGxpY2Vuc2UgdW5kZXIgc3VjaCByaWdo dHMgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIA0KICAgIGRvZXMgaXQgcmVw cmVzZW50IHRoYXQgaXQgaGFzIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byANCiAgICBp ZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbiBvbiB0aGUgcHJvY2VkdXJlcyB3 aXRoIA0KICAgIHJlc3BlY3QgdG8gcmlnaHRzIGluIFJGQyBkb2N1bWVudHMgY2FuIGJlIGZvdW5k IGluIEJDUCA3OCBhbmQgDQogICAgQkNQIDc5LiANCiAgICAgDQogICAgQ29waWVzIG9mIElQUiBk aXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFyaWF0IGFuZCBhbnkgDQogICAgYXNz dXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBv ZiBhbiANCiAgICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBl cm1pc3Npb24gZm9yIHRoZSANCg0KDQoNCg0KIFpzZWJ5LCBCb3NjaGksIEJyb3dubGVlLCBDbGFp c2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAzMF0gDQoMICAgICAgICAgICAgICAg ICAgICAgIElQRklYIEFwcGxpY2FiaWxpdHkgICAgICAgICAgICAgIEp1bmUgMjAwNiANCg0KDQoN CiAgICB1c2Ugb2Ygc3VjaCBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVz ZXJzIG9mIHRoaXMgDQogICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUg SUVURiBvbi1saW5lIElQUiANCiAgICByZXBvc2l0b3J5IGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcv aXByLiANCiAgICAgDQogICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0 byBicmluZyB0byBpdHMgYXR0ZW50aW9uIA0KICAgIGFueSBjb3B5cmlnaHRzLCBwYXRlbnRzIG9y IHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIA0KICAgIHByb3ByaWV0YXJ5IHJpZ2h0cyB0 aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIA0KICAgIHJlcXVpcmVkIHRvIGlt cGxlbWVudCB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIA0KICAgIGluZm9ybWF0 aW9uIHRvIHRoZSBJRVRGIGF0IGlldGYtaXByQGlldGYub3JnLiANCiAgICAgDQogMTMuIENvcHly aWdodCBTdGF0ZW1lbnQgDQogICAgIA0KICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDYpLiAgVGhpcyBkb2N1bWVudCBpcyANCiAgICBzdWJqZWN0IHRvIHRoZSByaWdo dHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMgY29udGFpbmVkIGluIA0KICAgIEJDUCA3OCwg YW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMgcmV0YWluIGFsbCAN CiAgICB0aGVpciByaWdodHMuIA0KICAgICANCiAxNC4gRGlzY2xhaW1lciAgDQogICAgIA0KICAg IFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBw cm92aWRlZCANCiAgICBvbiBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRI RSBPUkdBTklaQVRJT04gSEUvU0hFIA0KICAgIFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVEIEJZ IChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgDQogICAgVEhFIElOVEVSTkVUIEVO R0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIA0KICAgIEVYUFJF U1MgT1IgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkg DQogICAgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5G UklOR0UgQU5ZIA0KICAgIFJJR0hUUyBPUiBBTlkgSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNI QU5UQUJJTElUWSBPUiBGSVRORVNTIA0KICAgIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gDQog IA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KIFpzZWJ5 LCBCb3NjaGksIEJyb3dubGVlLCBDbGFpc2UgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFn ZSAzMV0gDQoM ------_=_NextPart_001_01C695F5.4C2C173E-- -- 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 ursu@ad.funnel.revenuedirect.com.akadns.net Thu Jun 22 15:17:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtUfx-0007eb-Ek for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:17:13 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtUfw-0000ke-5j for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 15:17:13 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtUcY-0006ym-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 14:13:42 -0500 Received: from buffbody.com (LAubervilliers-151-12-87-13.w193-252.abo.wanadoo.fr [193.252.176.13]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5MJDfLd023740 for ; Thu, 22 Jun 2006 14:13:42 -0500 Message-ID: <000001c6962f$fac3e7d0$6f61a8c0@dhu54> Reply-To: "Ursula Wooster" From: "Ursula Wooster" To: ipfix-list@mil.doit.wisc.edu Subject: Re: ioliz Date: Thu, 22 Jun 2006 12:13:44 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C695F5.4E69CAC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.6 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C695F5.4E69CAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 =20 V / A G R A from 3,33 http://malisaborin.com =20 and many other =20 _____ =20 beating of his wings. Amid shrieks and wailing and the shouts of men he came over them, swept towards the bridges and was foiled! The bridge was gone, and his enemies were on an island in deep water-too deep and dark and cool for his liking. If he plunged into it, a vapour and a steam would arise enough to cover all the land with a mist for days; but the lake was ------=_NextPart_000_0001_01C695F5.4E69CAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
 
 
V / A G R A from 3,33 http://malisaborin.com
 
and many other
 

beating of his wings.
Amid shrieks and wailing and the shouts of men he came over them, = swept
towards the bridges and was foiled! The bridge was gone, and his
enemies were on an island in deep water-too deep and dark and cool = for
his liking. If he plunged into it, a vapour and a steam would arise
enough to cover all the land with a mist for days; but the lake = was
------=_NextPart_000_0001_01C695F5.4E69CAC0-- From 579timofei@australiamail.com Thu Jun 22 18:44:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtXuM-0002BG-Ux for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:44:18 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtXuL-0002zh-Nt for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:44:18 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtXpf-0004Qe-00; Thu, 22 Jun 2006 17:39:27 -0500 Received: from EQUIPO2.gia6i.org ([201.250.16.13]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5MMdDji026512; Thu, 22 Jun 2006 17:39:23 -0500 Message-Id: <200606222239.k5MMdDji026512@smtp.doit.wisc.edu> From: "Carmella Whitaker" <529herrick@freeproblem.com> To: Subject: Fw: Good girls Date: Thu, 22 Jun 2006 19:39:37 -0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: U5wKRa69HV6Mosx9iYDxXzIJLJBtbKeUIu2b Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hey Ipfix-list!!! I find your email in my address book and want to make you happy!:) One week ago myfiend has recommend great site to me, I joined this and been SHOCKED!!! On this site I find lots of YOUNG cuties, so sweet, so hot, so clear and so WET!!!! And now I want to recommend this site to you, my friend. QUALITY DIRTY MOVIES, EXCLUSIVE MODELS, VERY YOUNG PUSSIES, PINK ASSES, LITTLE CLITS, SEXY LIPS, etc..... I think you say many thanks to me after you joined to this site members area. These cuties waiting for you to introduce all this stuff to you. Don't save your money and time, we live on this earth only one life - spend it right, use your brain!!!:) He-He!!! The way to your desire is: http://www.geocities.com/carmella7559 Best Regards, your friend Fanny Mims Thu, 22 Jun 2006 19:39:37 -0300 From majordomo@mil.doit.wisc.edu Thu Jun 22 18:53:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtY33-000056-Kt for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:53:17 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtY31-0004RL-A4 for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 18:53:17 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtXzy-0004kI-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 17:50:06 -0500 Received: from willow.neustar.com ([209.173.53.84]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtXzx-0004kD-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 17:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5MMo2Rx025061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jun 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FtXzu-0007tX-6X; Thu, 22 Jun 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ipfix@net.doit.wisc.edu From: Internet-Drafts@ietf.org Subject: [ipfix] I-D ACTION:draft-ietf-ipfix-as-09.txt Message-Id: Date: Thu, 22 Jun 2006 18:50:02 -0400 Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.3 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Flow Information Export Working Group of the IETF. Title : IPFIX Applicability Author(s) : T. Zseby, et al. Filename : draft-ietf-ipfix-as-09.txt Pages : 31 Date : 2006-6-22 This document describes the applicability of the IP Flow Information Export (IPFIX) protocol for a variety of applications. It shows how applications can use IPFIX, describes the relevant information elements (IEs) and shows opportunities and limitations of the protocol. The document furthermore describes relations of the IPFIX framework to other architectures and frameworks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipfix-as-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipfix-as-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipfix-as-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-22160151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipfix-as-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipfix-as-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-22160151.I-D@ietf.org> --OtherAccess-- --NextPart-- -- 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 Jun 22 23:30:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtcNm-0007rI-FA for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 23:30:58 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtcNk-0001O8-5A for ipfix-archive@lists.ietf.org; Thu, 22 Jun 2006 23:30:58 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtbyY-0003DW-00 for ipfix-list@mil.doit.wisc.edu; Thu, 22 Jun 2006 22:04:54 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtbyX-0003DR-00 for ipfix@net.doit.wisc.edu; Thu, 22 Jun 2006 22:04:53 -0500 Received: from [192.168.1.128] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C03EF1BAC4D; Fri, 23 Jun 2006 04:52:48 +0200 (CEST) Date: Fri, 23 Jun 2006 05:04:42 +0200 From: Juergen Quittek To: Hitoshi Irino Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] new version of the IPFIX information model Message-ID: In-Reply-To: <449A4C62.1080608@lab.ntt.co.jp> References: <6AA5730EAA04A4F15B7DAC1A@[195.37.70.133]> <449A4C62.1080608@lab.ntt.co.jp> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Dear Hitoshi Irino, Thank you for the thorough review. I will keep a record for the next revision. Thanks, Juergen --On 22.06.2006 16:53 Uhr +0900 Hitoshi Irino wrote: > Dear Juergen > > I (probably) found a mistake of the Draft. > Section 5.4.11 is destinationIPv6PrefixLength, but > ElementId 30 is destinationIPv6Mask in the table of Page 16. > Correct IE is destinationIPv6PrefixLength, isn't it? > > regrads, > Hitoshi Irino > > Juergen Quittek wrote: >> Dear all, >> >> I submitted a new version of the IPFIX information model. >> Until it gets posted, please find it at >> . >> >> The new version includes all changes that were requested >> by the AD review. Also changes discussed recently on >> the mailing list are included. Furthermore, a lot of >> clarifications and minor changes have been applied. >> >> Please find a diff between the previous version -11 and >> the new version -12 at >> . >> >> 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/ >> > > > -- > ---------------------------------------------- > NTT Network Service Systems Laboratories > Broadband Network Systems Project > Service Edge Group > > Hitoshi Irino > Email: irino.hitoshi@lab.ntt.co.jp > Tel: +81-422-59-4403 Fax: +81-422-59-4549 > > > -- > 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 Jun 23 07:23:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftjkn-0004y2-Lq for ipfix-archive@lists.ietf.org; Fri, 23 Jun 2006 07:23:13 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftjkl-0006bI-Cc for ipfix-archive@lists.ietf.org; Fri, 23 Jun 2006 07:23:13 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtjhS-0003CJ-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Jun 2006 06:19:46 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtjhR-0003CE-00 for ipfix@net.doit.wisc.edu; Fri, 23 Jun 2006 06:19:45 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k5NBJKb24693; Fri, 23 Jun 2006 13:19:21 +0200 (MEST) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: [ipfix] RE: IPFIX-AS draft version 09 Date: Fri, 23 Jun 2006 13:19:32 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA11C7E40@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFIX-AS draft version 09 Thread-Index: AcaWGdnEY09jXAdbTCCHvcxGUkPd+gAmduEw From: "Tanja Zseby" To: "Bernard Aboba" Cc: , "Gray, Eric" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi Bernard, o.k. I can substitute the term commercial-grade billing by usage-based billing in the next version. I need to make another version anyway in order to incorporate Dans (and others) comments :-) Thanks for your review and kind regards, Tanja > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Thursday, June 22, 2006 6:35 PM > To: Tanja Zseby > Cc: ipfix@net.doit.wisc.edu; Gray, Eric > Subject: Re: IPFIX-AS draft version 09 >=20 > I have read the -09 document, and I think it could be more clear.=20 >=20 > The term "usage-based accounting" is used along with a=20 > statement that IPFIX isn't sufficiently reliable for=20 > "commercial-grade billing". =20 >=20 > This is confusing because the issue is really "usage-based=20 > billing" not usage-based accounting. Where bills are not=20 > based on usage (e.g. flat rate services), the usage=20 > information provided by IPFIX would not represent a problem=20 > if it were to be lost in transit. Usage-based accounting=20 > (how accounting data is collected) is a different thing from=20 > usage-based billing (how the accounting records are rated).=20 >=20 > So my recommendation is to replace "commercial-grade billing"=20 > with "usage-based billing". =20 >=20 >=20 >=20 > On Thu, 22 Jun 2006, Tanja Zseby wrote: >=20 > > Hi all, > >=20 > > I submitted a new version of the applicability statement=20 > (attached). In > > order to address Bernard Abobas comments on the IPFIX=20 > limitations for > > billing, I incorporated a section on the reliability limitations of > > IPIFX and warned in related sections, that IPFIX is=20 > currently not able > > to support commercial-grade billing. I did not remove the=20 > AAA examples > > because I think that they are still useful and especially may be > > valuable if reliability extensions from Benoits draft are=20 > incorporated.=20 > > Furthermore I tried to address all the comments from the=20 > Gen-ART review, > > did some re-wording and added a section on remote=20 > configuration in the > > limitations section. > >=20 > > Thanks to all that reviewed and commented the draft. > >=20 > > Regards, > > Tanja > >=20 >=20 >=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/ From majordomo@mil.doit.wisc.edu Fri Jun 23 07:35:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtjwZ-0002fq-GV for ipfix-archive@lists.ietf.org; Fri, 23 Jun 2006 07:35:23 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtjwY-00089S-78 for ipfix-archive@lists.ietf.org; Fri, 23 Jun 2006 07:35:23 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FtjtQ-0003h6-00 for ipfix-list@mil.doit.wisc.edu; Fri, 23 Jun 2006 06:32:08 -0500 Received: from mailhub.fokus.fraunhofer.de ([193.174.154.14]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FtjtP-0003gS-00 for ipfix@net.doit.wisc.edu; Fri, 23 Jun 2006 06:32:07 -0500 Received: from EXCHSRV.fokus.fraunhofer.de (bohr [10.147.9.231]) by mailhub.fokus.fraunhofer.de (8.11.6p2/8.11.6) with SMTP id k5NBVnb27045; Fri, 23 Jun 2006 13:31:49 +0200 (MEST) x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] IPFIX-AS draft version 09 Date: Fri, 23 Jun 2006 13:32:00 +0200 Message-ID: <804B13F8F3D94A4AB18B9B01ACB68FA11C7E45@EXCHSRV.fokus.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] IPFIX-AS draft version 09 Thread-Index: AcaWHUGrfyW2pkc0RIaBa/fpyoFN+gAm1aAQ From: "Tanja Zseby" To: "Gray, Eric" , Cc: "Bernard Aboba" , "Romascanu, Dan \(Dan\)" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Hi Eric, I will produce a version 10 based on the comments I got on the 08 version. I assume that I now have all comments because IESG LC on 08 has ended, correct? Is this o.k or do I need to somehow officially withdraw version 09? Kind regards, Tanja > -----Original Message----- > From: Gray, Eric [mailto:Eric.Gray@marconi.com]=20 > Sent: Thursday, June 22, 2006 6:59 PM > To: Tanja Zseby; ipfix@net.doit.wisc.edu > Cc: Bernard Aboba; Gray, Eric; Romascanu, Dan (Dan) > Subject: RE: [ipfix] IPFIX-AS draft version 09 >=20 > I agree with Dan. >=20 > People making review comments aim those comments at the LC=20 > version (including page numbers, sections and referring to=20 > text as they saw during the review period). Modifications to=20 > the document during the review period results in a "moving=20 > target" and makes the review process difficult for everyone. >=20 > If the revised edition already submitted is not withdrawn,=20 > then I suggest extending the last call until two weeks after=20 > the revised edition is available for review. >=20 > -- > Eric >=20 > --> -----Original Message----- > --> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > --> Sent: Thursday, June 22, 2006 8:22 AM > --> To: Tanja Zseby; ipfix@net.doit.wisc.edu > --> Cc: Bernard Aboba; Gray, Eric > --> Subject: RE: [ipfix] IPFIX-AS draft version 09 > -->=20 > --> I would like to draw your attention that draft-08 is=20 > still in IESG=20 > --> LC until today. It would be preferable not to issue=20 > revised drafts=20 > --> while a document is in LC. You may expect comments on=20 > draft-08 until=20 > --> today COB (including mine :-)). > -->=20 > --> Dan > -->=20 > -->=20 > -->=20 > -->=20 > --> =20 > --> =20 > -->=20 > --> > -----Original Message----- > --> > From: majordomo listserver > --> > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > --> > Sent: Thursday, June 22, 2006 3:14 PM > --> > To: ipfix@net.doit.wisc.edu > --> > Cc: Bernard Aboba; Gray, Eric > --> > Subject: [ipfix] IPFIX-AS draft version 09 > --> >=20 > --> > Hi all, > --> >=20 > --> > I submitted a new version of the applicability statement=20 > --> > (attached). In order to address Bernard Abobas comments on the=20 > --> > IPFIX limitations for billing, I incorporated a section on the=20 > --> > reliability limitations of IPIFX and warned in related=20 > sections,=20 > --> > that IPFIX is currently not able to support commercial-grade=20 > --> > billing. I did not remove the AAA examples because I think that=20 > --> > they are still useful and especially may be valuable if=20 > --> > reliability extensions from Benoits draft are incorporated. > --> > Furthermore I tried to address all the comments from=20 > the Gen-ART=20 > --> > review, did some re-wording and added a section on remote=20 > --> > configuration in the limitations section. > --> >=20 > --> > Thanks to all that reviewed and commented the draft. > --> >=20 > --> > Regards, > --> > Tanja > --> >=20 > -->=20 >=20 >=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/ From mdqcmnyazln@hotmail.com Sat Jun 24 02:45:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu1tt-00084R-0P for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 02:45:49 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu1tr-0006Rs-Pc for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 02:45:48 -0400 Received: from [220.165.130.114] (helo=mil.doit.wisc.edu) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Fu1pJ-0003L5-00 for ipfix-list@mil.doit.wisc.edu; Sat, 24 Jun 2006 01:41:06 -0500 From: "jsubc" To: ipfix-list@mil.doit.wisc.edu Content-type: text/html Subject: Obtain the career you have always wanted with the University Degree you deserve. Message-Id: Date: Sat, 24 Jun 2006 01:41:06 -0500 X-Spam-Score: 3.3 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

University Degree


OBTAIN @ PR0SPEROUS FUTURE, MONEY-E@RNING POWER,
AND THE PRESTIGE THAT COMES WITH HAVING THE CAREER POSITION YOU'VE
ALWAYS DREAMED OF. DIPLOMA FROM
PRESTIGIOUS NON-ACCREDITED
UNVERSITIES BASED ON YOUR PRESENT KNOWLEDGE AND PROFESSIONAL EXPERIENCE.
If you qualify, no required tests, classes, books or examinations.

Confidentiality Assured

1-815-828-2222
24 hours a day, 7 days a week including Sundays and Holidays



































Harry crossed to the dishwasher, took out a clean glass From cranston_maleah@gamebox.net Sat Jun 24 04:15:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu3IC-0005iA-JO for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 04:15:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu3IB-0001Nd-Bt for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 04:15:00 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fu2sP-00062I-00 for ipfix-list@mil.doit.wisc.edu; Sat, 24 Jun 2006 02:48:21 -0500 Received: from MICHEL.57j9ep.org (ip56535609.direct-adsl.nl [86.83.86.9] (may be forged)) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5O7mA25028814 for ; Sat, 24 Jun 2006 02:48:16 -0500 Message-Id: <200606240748.k5O7mA25028814@smtp.doit.wisc.edu> From: "Estella" To: Subject: Hoodia will change your life Date: Sat, 24 Jun 2006 09:48:27 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: 9MJBYxBBk8GrfBIuPJPA1PkL7aT8rjxcHY19 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Hi Ipfix-list! Amazing weight loss stories here: http://www.klevon.net/hd/?52&contradictory I've always had trouble with my weight ever since I was young. Of course I tried all the "best" fat loss products, nothing helped very much. It wasn't til I tried Hoodia 92O+ that I saw the pounds seriously start to melt away! Nothing helped me lose weight faster. I literally saw 15 pounds melt away within the first few weeks! There's nothing more exciting than watching pounds disappear, especially when you've tried all sorts of different methods and products before. I've since read up on Hoodia and am amazed at the number of people who have benefited from its amazing results. I'm halfway to my goal, Hoodia 920+ will get me the rest of the way ;) Mathew Alexander From tyndale_o@phreaker.net Sat Jun 24 04:20:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu3Nr-0001ty-0s for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 04:20:51 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fu3Np-0001cW-Pt for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 04:20:51 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fu2z6-00066p-00 for ipfix-list@mil.doit.wisc.edu; Sat, 24 Jun 2006 02:55:16 -0500 Received: from USER (61-231-102-111.dynamic.hinet.net [61.231.102.111]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5O7tDTC029509 for ; Sat, 24 Jun 2006 02:55:15 -0500 Message-Id: <200606240755.k5O7tDTC029509@smtp.doit.wisc.edu> From: "Cleveland" To: Subject: Join the Hoodia revolution Date: Sat, 24 Jun 2006 15:55:10 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: mFrj0O7VJ1gZxZRIMwY1Otjpf6dsKBtNViT1 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Score: 2.5 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Yo Ipfix-list!.! Here's that fat loss pill site you asked about, the one I told you with the amazing Hoodia pills. Hey- if they're good enough for Oprah, then they must be good enough for us lol ;) Check the site out and let me know later how they work for you, hope you lose as many pounds as I did! :) http://www.klevon.net/hd/?52&aloe Later babe xo From noreply@mil.doit.wisc.edu Sat Jun 24 14:55:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuDHe-0006at-W3 for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 14:55:06 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuDHc-0003rr-OJ for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 14:55:06 -0400 Received: from verance-fw.verance.com ([209.144.207.3] helo=sd-cstest.verancecorp.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FuD9v-0001ea-00 for ipfix-list@mil.doit.wisc.edu; Sat, 24 Jun 2006 13:47:09 -0500 Received: from [15.230.162.105] (port=8314 helo=pltwz) by sd-cstest.verancecorp.com with SMTP for ipfix-list@mil.doit.wisc.edu ; Sat, 24 Jun 2006 11:47:03 -0700 Message-ID: <0a53139447e$418145ae$74a5ec2e@ctoawd> From: "MAILER-DAEMON" To: Subject: failed Date: Sat, 24 Jun 2006 11:18:03 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0A26_FD3AFDEF.AF86421E" X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?209.144.207.3 X-Spam-Score: 1.9 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 ------=_NextPart_000_0A26_FD3AFDEF.AF86421E Content-Type: text/plain; charset="iso-8859-1" We attached some important information regarding your account. ------=_NextPart_000_0A26_FD3AFDEF.AF86421E Content-Type: application/x-compressed; name="info-text.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="info-text.zip" %TS_ZIP_ATTACH% ------=_NextPart_000_0A26_FD3AFDEF.AF86421E-- From chaneswanson@lucasforums.com Sat Jun 24 23:11:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuL1i-0001xj-RG for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 23:11:10 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuL1h-0001Ua-HO for ipfix-archive@lists.ietf.org; Sat, 24 Jun 2006 23:11:10 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FuKeV-0006Ym-00 for ipfix-list@mil.doit.wisc.edu; Sat, 24 Jun 2006 21:47:11 -0500 Received: from BABY (c-71-235-229-193.hsd1.ma.comcast.net [71.235.229.193]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5P2l8Vf004604 for ; Sat, 24 Jun 2006 21:47:09 -0500 Message-Id: <009001c697f9$7c9db900$4f309674@oibrkbs> From: "daveen acosta" To: "celisse sherman" Subject: Luxury Timepieces Date: Sun, 25 Jun 2006 01:52:30 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01C697F9.7C9DB900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0090_01C697F9.7C9DB900 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable TOP BRANDS - LOW LOW PRICES Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets=20 Leather, silk and white gold sound good? Visit our site for real photos. Everything comes with a certificate, tags and all the extras, plus a warran= ty. http://jesselansing.com/luxury/ machine-wrought true-paced head lamp base clef barnyard golf pre-emptory all-pervasive twice-noted kitchen garden register office yacht ensign late-cruising jolly jumper leakage conductance quarter-mile class number tongue-blade pennant fish same-minded gentleman-adventurer sab-cat buzz planer Non-swedish flutter kick ketch-rigged pseudo occupation crater basin ------=_NextPart_000_0090_01C697F9.7C9DB900 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

TOP BRANDS - LOW LOW PRICES

Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets

Leather, silk and white gold sound good? Visit our site for real photos.=
Everything comes with a certificate, tags and all the extras, plus a warran= ty.

http://jesselansing.com/luxury/=

machine-wrought true-paced head lamp
base clef barnyard golf pre-emptory
all-pervasive twice-noted kitchen garden
register office yacht ensign late-cruising
jolly jumper leakage conductance quarter-mile
class number tongue-blade pennant fish
same-minded gentleman-adventurer sab-cat
buzz planer Non-swedish flutter kick
ketch-rigged pseudo occupation crater basin
= ------=_NextPart_000_0090_01C697F9.7C9DB900-- From majordomo@mil.doit.wisc.edu Sun Jun 25 02:52:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuOUG-0003VL-JH for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 02:52:52 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuOUE-0004kE-8M for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 02:52:52 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FuOOl-00016D-00 for ipfix-list@mil.doit.wisc.edu; Sun, 25 Jun 2006 01:47:11 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FuOOl-000168-00 for ipfix@net.doit.wisc.edu; Sun, 25 Jun 2006 01:47:11 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5P6i17Q005660 for ; Sun, 25 Jun 2006 02:44:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] IPFIX-AS draft version 09 Date: Sun, 25 Jun 2006 09:47:05 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] IPFIX-AS draft version 09 Thread-Index: AcaWHUGrfyW2pkc0RIaBa/fpyoFN+gAm1aAQAFqUpEA= From: "Romascanu, Dan \(Dan\)" To: "Tanja Zseby" , "Gray, Eric" , Cc: "Bernard Aboba" X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Tanja, That's OK to issue version 10, there is no need to withdraw version 09. Just please take care to consider all comments.=20 Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: Tanja Zseby [mailto:Tanja.Zseby@fokus.fraunhofer.de]=20 > Sent: Friday, June 23, 2006 2:32 PM > To: Gray, Eric; ipfix@net.doit.wisc.edu > Cc: Bernard Aboba; Romascanu, Dan (Dan) > Subject: RE: [ipfix] IPFIX-AS draft version 09 >=20 > Hi Eric, >=20 > I will produce a version 10 based on the comments I got on=20 > the 08 version. I assume that I now have all comments because=20 > IESG LC on 08 has ended, correct? Is this o.k or do I need to=20 > somehow officially withdraw version 09? >=20 > Kind regards, > Tanja >=20 >=20 > > -----Original Message----- > > From: Gray, Eric [mailto:Eric.Gray@marconi.com] > > Sent: Thursday, June 22, 2006 6:59 PM > > To: Tanja Zseby; ipfix@net.doit.wisc.edu > > Cc: Bernard Aboba; Gray, Eric; Romascanu, Dan (Dan) > > Subject: RE: [ipfix] IPFIX-AS draft version 09 > >=20 > > I agree with Dan. > >=20 > > People making review comments aim those comments at the LC version=20 > > (including page numbers, sections and referring to text as they saw=20 > > during the review period). Modifications to the document=20 > during the=20 > > review period results in a "moving target" and makes the review=20 > > process difficult for everyone. > >=20 > > If the revised edition already submitted is not withdrawn, then I=20 > > suggest extending the last call until two weeks after the revised=20 > > edition is available for review. > >=20 > > -- > > Eric > >=20 > > --> -----Original Message----- > > --> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > --> Sent: Thursday, June 22, 2006 8:22 AM > > --> To: Tanja Zseby; ipfix@net.doit.wisc.edu > > --> Cc: Bernard Aboba; Gray, Eric > > --> Subject: RE: [ipfix] IPFIX-AS draft version 09 > > -->=20 > > --> I would like to draw your attention that draft-08 is > > still in IESG > > --> LC until today. It would be preferable not to issue > > revised drafts > > --> while a document is in LC. You may expect comments on > > draft-08 until > > --> today COB (including mine :-)). > > -->=20 > > --> Dan > > -->=20 > > -->=20 > > -->=20 > > -->=20 > > --> =20 > > --> =20 > > -->=20 > > --> > -----Original Message----- > > --> > From: majordomo listserver > > --> > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Tanja Zseby > > --> > Sent: Thursday, June 22, 2006 3:14 PM > > --> > To: ipfix@net.doit.wisc.edu > > --> > Cc: Bernard Aboba; Gray, Eric > > --> > Subject: [ipfix] IPFIX-AS draft version 09 > > --> >=20 > > --> > Hi all, > > --> >=20 > > --> > I submitted a new version of the applicability statement=20 > > --> > (attached). In order to address Bernard Abobas=20 > comments on the=20 > > --> > IPFIX limitations for billing, I incorporated a=20 > section on the=20 > > --> > reliability limitations of IPIFX and warned in related > > sections, > > --> > that IPFIX is currently not able to support commercial-grade=20 > > --> > billing. I did not remove the AAA examples because I=20 > think that=20 > > --> > they are still useful and especially may be valuable if=20 > > --> > reliability extensions from Benoits draft are incorporated. > > --> > Furthermore I tried to address all the comments from > > the Gen-ART > > --> > review, did some re-wording and added a section on remote=20 > > --> > configuration in the limitations section. > > --> >=20 > > --> > Thanks to all that reviewed and commented the draft. > > --> >=20 > > --> > Regards, > > --> > Tanja > > --> >=20 > > -->=20 > >=20 > >=20 >=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/ From mackenzi@firstnetva.com Sun Jun 25 06:12:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuRbt-0001V8-MG for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 06:12:57 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuRbs-00075S-DS for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 06:12:57 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FuRV7-0003We-00 for ipfix-list@mil.doit.wisc.edu; Sun, 25 Jun 2006 05:05:57 -0500 Received: from firstnetva.com (79.Red-83-45-65.dynamicIP.rima-tde.net [83.45.65.79]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5PA5tYK025748 for ; Sun, 25 Jun 2006 05:05:56 -0500 Message-ID: <000001c6983e$e83883d0$80bea8c0@ead87> Reply-To: "Utz Mackenzie" From: "Utz Mackenzie" To: ipfix-list@mil.doit.wisc.edu Subject: test ueu Date: Sun, 25 Jun 2006 03:05:37 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69804.3BD9ABD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.8 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69804.3BD9ABD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, X & N A X V A L / U M M E R / D / A V / A G R A S O M ^ P R O Z & C L E V / T R A C / A L / S A M B / E N all 50 % off - http://www.omeredatte.com _____ =20 stamped. They knew the sword at once. It had killed hundreds of goblins=20 in its time, when the fair elves of Gondolin hunted them in the hills or did battle before their walls. They had called it Orcrist,=20 Goblin-cleaver, but the goblins called it simply Biter. They hated it=20 and hated worse any one that carried it. Murderers and elf-friends!=20 the Great Goblin shouted. Slash them! Beat them! Bite them! Gnash them!=20 ------=_NextPart_000_0001_01C69804.3BD9ABD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

X & N A X
V A L / U M
M E R / D / A
V / A G R A
S O M ^
P R O Z & C
L E V / T R A
C / A L / S
A M B / E N

all 50 % off - http://www.omeredatte.com


stamped. They knew the sword at once. It had killed hundreds of = goblins
in its time, when the fair elves of Gondolin hunted them in = the hills or
did battle before their walls. They had called it = Orcrist,
Goblin-cleaver, but the goblins called it simply Biter. = They hated it
and hated worse any one that carried it. Murderers and = elf-friends!
the Great Goblin shouted. Slash them! Beat them! Bite = them! Gnash them!
------=_NextPart_000_0001_01C69804.3BD9ABD0-- From majordomo@mil.doit.wisc.edu Sun Jun 25 08:26:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuTgs-0000fG-J2 for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 08:26:14 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuTgq-0007eh-8q for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 08:26:14 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FuTcT-0001jU-00 for ipfix-list@mil.doit.wisc.edu; Sun, 25 Jun 2006 07:21:41 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FuTcS-0001jP-00 for ipfix@net.doit.wisc.edu; Sun, 25 Jun 2006 07:21:41 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5PCHVJh029541 for ; Sun, 25 Jun 2006 08:17:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipfix] new version of the IPFIX information model Date: Sun, 25 Jun 2006 15:21:38 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ipfix] new version of the IPFIX information model Thread-Index: AcaWdDDt0Qp7IQUjSKO73XybAcjipgB3Y7eg From: "Romascanu, Dan \(Dan\)" To: "Juergen Quittek" , "Hitoshi Irino" Cc: X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 As I am preparing the info model draft to go to IESG Last Call soon, I suggest to consider this comment a LC comment.=20 Dan =20 =20 > -----Original Message----- > From: majordomo listserver=20 > [mailto:majordomo@mil.doit.wisc.edu] On Behalf Of Juergen Quittek > Sent: Friday, June 23, 2006 6:05 AM > To: Hitoshi Irino > Cc: ipfix@net.doit.wisc.edu > Subject: Re: [ipfix] new version of the IPFIX information model >=20 > Dear Hitoshi Irino, >=20 > Thank you for the thorough review. > I will keep a record for the next revision. >=20 > Thanks, >=20 > Juergen >=20 > --On 22.06.2006 16:53 Uhr +0900 Hitoshi Irino wrote: >=20 > > Dear Juergen > > > > I (probably) found a mistake of the Draft. > > Section 5.4.11 is destinationIPv6PrefixLength, but ElementId 30 is=20 > > destinationIPv6Mask in the table of Page 16. > > Correct IE is destinationIPv6PrefixLength, isn't it? > > > > regrads, > > Hitoshi Irino > > > > Juergen Quittek wrote: > >> Dear all, > >> > >> I submitted a new version of the IPFIX information model. > >> Until it gets posted, please find it at=20 > >>=20 > . >> >> The new version includes all changes that were requested by the AD=20 >> review. Also changes discussed recently on the mailing list are=20 >> included. Furthermore, a lot of clarifications and minor changes=20 >> have been applied. >> >> Please find a diff between the previous version -11 and the new=20 >> version -12 at . >> >> 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=20 >> ipfix" in message body >> Archive http://ipfix.doit.wisc.edu/archive/ >> > > > -- > ---------------------------------------------- > NTT Network Service Systems Laboratories > Broadband Network Systems Project > Service Edge Group > > Hitoshi Irino > Email: irino.hitoshi@lab.ntt.co.jp > Tel: +81-422-59-4403 Fax: +81-422-59-4549 > > > -- > Help mailto:majordomo@net.doit.wisc.edu and say "help" in message body > Unsubscribe mailto:majordomo@net.doit.wisc.edu and say "unsubscribe=20 > 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 178park@yahoo.com Sun Jun 25 11:41:50 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuWkA-0002zw-IF for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 11:41:50 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuWk9-0006yP-BQ for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 11:41:50 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FuWYY-0003Ix-00; Sun, 25 Jun 2006 10:29:50 -0500 Received: from 9o3hu.p06od.aol.com (12-tami.tami.pl [195.149.118.12]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5PFTn4Y022851; Sun, 25 Jun 2006 10:29:50 -0500 Message-Id: <200606251529.k5PFTn4Y022851@smtp.doit.wisc.edu> From: "Roger Gilmore" <607lutero@hideakifan.com> To: Subject: Fwd: Need a University {}Degree to obtain the career you?ve always wanted? Date: Sun, 25 Jun 2006 17:29:39 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: Jd7oHyjzct7Hga5zkEOqCTT9GM3F5MXa4z5O Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 In just 2 years you can have a masters degree from a national university. A better job, more income and a better life can all be yours in just 2 years. No books to buy, no classes to go to, and no entrance exams. Learn in your own home at your own pace. We supply all the study materials, all you have to do is study and complete 2 tests per month. Telephone Us Today +1 (831) 302 66 63 Operators Waiting ----------------------------- boundary cloth ant bless claustrophobia armhole brotherhood catabolic From majordomo@mil.doit.wisc.edu Sun Jun 25 12:28:13 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuXT3-0007xj-Ox for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 12:28:13 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuXT3-0001Zr-Ms for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 12:28:13 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FuXT2-0000QW-1q for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 12:28:13 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FuXPl-0005Ns-00 for ipfix-list@mil.doit.wisc.edu; Sun, 25 Jun 2006 11:24:49 -0500 Received: from web51511.mail.yahoo.com ([206.190.39.157]) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FuXPk-0005Nn-00 for ipfix@net.doit.wisc.edu; Sun, 25 Jun 2006 11:24:48 -0500 Received: (qmail 20823 invoked by uid 60001); 25 Jun 2006 16:24:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=aRGImnM11offoGx843bKOIDD3AUyxsBwIl6V330e8tr+UkRc4G06AXRYxC3aSHGxBHFSb4yPWUKr9ktqtfqfkCvo3n5ZGDWtlWwWNH7k5uFrW5QXbMLpSyRQDu9Su5U2Cfaj8jt+XbpXlZzFy3AF1TUrJK8B+R+1gbLbwzgtl50= ; Message-ID: <20060625162447.20821.qmail@web51511.mail.yahoo.com> Received: from [59.92.202.180] by web51511.mail.yahoo.com via HTTP; Sun, 25 Jun 2006 09:24:47 PDT Date: Sun, 25 Jun 2006 09:24:47 -0700 (PDT) From: Manjunath R Subject: [ipfix] RE:I-D ACTION:draft-manjunath-ipfix-shifted-feedback-00.txt To: ipfix@net.doit.wisc.edu Cc: Dan Romascanu , David Kessens MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: -2.5 (--) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Hi all, Please find the announcement of internet draft on 'Shifted feedback technique for congestion notification'. Location: http://www.ietf.org/internet-drafts/draft-manjunath-ipfix-shifted-feedback-00.txt Appreciate your feedback. Regards, Manjunath.R I-D ACTION:draft-manjunath-ipfix-shifted-feedback-00.txt -------------------------------------------------------------------------------- To: i-d-announce at ietf.org Subject: I-D ACTION:draft-manjunath-ipfix-shifted-feedback-00.txt From: Internet-Drafts at ietf.org Date: Tue, 20 Jun 2006 18:50:01 -0400 Cc: List-archive: List-help: List-id: i-d-announce.ietf.org List-post: List-subscribe: , List-unsubscribe: , Reply-to: internet-drafts at ietf.org -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Shifted feedback technique for congestion notification Author(s) : R. Manjunath Filename : draft-manjunath-ipfix-shifted-feedback-00.txt Pages : 9 Date : 2006-6-20 The [RFC2581] provides a mechanism to indicate the congestion information of the network to the source. In this draft, time shifting of the signal before usage is suggested. The time shifting operation effectively counters the impact of the self similarity of the traffic that originates in a DiffServe network model as a result of the aggregation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manjunath-ipfix-shifted-feedback-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request at ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-manjunath-ipfix-shifted-feedback-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv at ietf.org. In the body type: "FILE /internet-drafts/draft-manjunath-ipfix-shifted-feedback-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -------------------------------------------------------------------------------- Prev by Date: I-D ACTION:draft-hart-pwe3-segmented-pw-vccv-00.txt Next by Date: I-D ACTION:draft-korhonen-mobopts-delivery-analysis-00.txt Previous by thread: I-D ACTION:draft-hart-pwe3-segmented-pw-vccv-00.txt Next by thread: I-D ACTION:draft-korhonen-mobopts-delivery-analysis-00.txt Index(es): Date Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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/ From jyxohqyhrda@hotmail.com Sun Jun 25 19:26:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FudzM-00084x-3E for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 19:26:00 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FudzK-0008B6-SU for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 19:26:00 -0400 Received: from [88.233.102.47] (helo=mil.doit.wisc.edu) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FudvV-00038o-00 for ipfix-list@mil.doit.wisc.edu; Sun, 25 Jun 2006 18:22:03 -0500 From: "jb699" To: ipfix-list@mil.doit.wisc.edu Content-type: text/html Subject: Tiered of been passed over for that promotion because you don’t have the proper Degree? Message-Id: Date: Sun, 25 Jun 2006 18:22:03 -0500 X-Spam-Score: 3.3 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

Univer$ity Degree


OBTAIN A PROSPEROUS FUTURE, MONEY-EARNING POWER,
AND THE PRESTIGE THAT COMES WITH HAVING THE CAREER POSITION YOU'VE
ALWAYS DREAMED OF. DIPLOMA FROM
PRESTIGIOUS NON-ACCREDITED
UNVERSITIES BASED ON YOUR PRESENT KNOWLEDGE AND PROFESSIONAL EXPERIENCE.
If you qualify, no required tests, classes, books or examinations.

Confidentiality Assured

1-815-828-2222
24 hours a day, 7 days a week including Sundays and Holidays



































leaving it only to go to the bathroom. Three times that day A unt Petunia From majordomo@mil.doit.wisc.edu Sun Jun 25 23:34:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuhri-0000x6-TP for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 23:34:22 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuhrh-00019r-8u for ipfix-archive@lists.ietf.org; Sun, 25 Jun 2006 23:34:22 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fuhb3-0006Sr-00 for ipfix-list@mil.doit.wisc.edu; Sun, 25 Jun 2006 22:17:09 -0500 Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fuhax-0006Si-00 for ipfix@net.doit.wisc.edu; Sun, 25 Jun 2006 22:17:07 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5Q3H1OR012056; Mon, 26 Jun 2006 12:17:01 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5Q3H0Be017881; Mon, 26 Jun 2006 12:17:00 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5Q3GxpP011014; Mon, 26 Jun 2006 12:16:59 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.13.7/8.13.7) with ESMTP id k5Q3GxsV029346; Mon, 26 Jun 2006 12:16:59 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k5Q3GxaP009984; Mon, 26 Jun 2006 12:16:59 +0900 (JST) Received: from imm.m.ecl.ntt.co.jp (imm0.m.ecl.ntt.co.jp [129.60.5.151]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k5Q3GwGs009973; Mon, 26 Jun 2006 12:16:58 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.96]) by imm.m.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k5Q3GikT020986; Mon, 26 Jun 2006 12:16:58 +0900 (JST) Message-ID: <449F51A2.2010802@lab.ntt.co.jp> Date: Mon, 26 Jun 2006 12:16:50 +0900 From: Hitoshi Irino User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Juergen Quittek CC: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] new version of the IPFIX information model References: <6AA5730EAA04A4F15B7DAC1A@[195.37.70.133]> <449A4C62.1080608@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Dear Juergen: I found another (maybe) mistake. In this draft, Information Elements grouped into 12 groups in a table of contents. 12 groups are: 5.1. Identifiers, 5.2. Metering and Exporting Process Configuration 5.3. Metering and Exporting Process Statistics 5.4. IP Header Fields 5.5. Transport Header Fields 5.6. Sub-IP Header Fields 5.7. Derived Packet Properties 5.8. Min/Max Flow Properties 5.9. Flow Time Stamps 5.10. Per-Flow Counters 5.11. Miscellaneous Flow Properties 5.12. Padding But, in section "5. Information Elements" in page 18, this draft describes: >The elements are grouped into 9 groups according to their semantics and ^ >their applicability: > > 1. Identifiers > 2. Metering and Exporting Process Properties > 3. IP Header Fields > 4. Transport Header Fields > 5. Sub-IP Header Fields > 6. Derived Packet Properties > 7. Min/Max Flow Properties > 8. Flow Time Stamps > 9. Per-Flow Counters > 10. Miscellaneous Flow Properties The sentence describes "9" groups and 10 groups are listed. Isn't this an error in writing? regrads, Hitoshi Irino Juergen Quittek wrote: > Dear Hitoshi Irino, > > Thank you for the thorough review. > I will keep a record for the next revision. > > Thanks, > > Juergen > > --On 22.06.2006 16:53 Uhr +0900 Hitoshi Irino wrote: > >> Dear Juergen >> >> I (probably) found a mistake of the Draft. >> Section 5.4.11 is destinationIPv6PrefixLength, but >> ElementId 30 is destinationIPv6Mask in the table of Page 16. >> Correct IE is destinationIPv6PrefixLength, isn't it? >> >> regrads, >> Hitoshi Irino >> >> Juergen Quittek wrote: >>> Dear all, >>> >>> I submitted a new version of the IPFIX information model. >>> Until it gets posted, please find it at >>> . >>> >>> >>> The new version includes all changes that were requested >>> by the AD review. Also changes discussed recently on >>> the mailing list are included. Furthermore, a lot of >>> clarifications and minor changes have been applied. >>> >>> Please find a diff between the previous version -11 and >>> the new version -12 at >>> . >>> >>> 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/ >>> >> >> >> -- >> ---------------------------------------------- >> NTT Network Service Systems Laboratories >> Broadband Network Systems Project >> Service Edge Group >> >> Hitoshi Irino >> Email: irino.hitoshi@lab.ntt.co.jp >> Tel: +81-422-59-4403 Fax: +81-422-59-4549 >> >> >> -- >> 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/ > > -- ---------------------------------------------- NTT Network Service Systems Laboratories Broadband Network Systems Project Service Edge Group Hitoshi Irino Email: irino.hitoshi@lab.ntt.co.jp Tel: +81-422-59-4403 Fax: +81-422-59-4549 -- 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 luke@compufort.com Mon Jun 26 02:06:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FukFF-0001wh-F6 for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 02:06:49 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FukFC-0000eo-5F for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 02:06:49 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fujz6-00076E-00 for ipfix-list@mil.doit.wisc.edu; Mon, 26 Jun 2006 00:50:08 -0500 Received: from compufort.com (207-37.dsl4.guernsey.net [213.133.207.37]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5Q5o7Kj020977 for ; Mon, 26 Jun 2006 00:50:07 -0500 Message-ID: <000001c698e3$e180f180$47cfa8c0@tnm80> Reply-To: "Martzel Luke" From: "Martzel Luke" To: ipfix-list@mil.doit.wisc.edu Subject: test waa Date: Sun, 25 Jun 2006 22:46:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C698A9.35246370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.0 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C698A9.35246370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, S O M ^ P R O Z & C A M B / E N M E R / D / A C / A L / S X & N A X L E V / T R A V A L / U M V / A G R A all 50 % off - http://www.chyahoo.com/o/ _____ =20 his hiding-place he kept a few wretched oddments, and one very beautiful thing, very beautiful, very wonderful. He had a ring, a golden ring, a=20 precious ring.=20 My birthday-present! he whispered to himself, as he had often done=20 in the endless dark days. Thats what we wants now, yes; we wants it!=20 He wanted it because it was a ring of power, and if you slipped that=20 ------=_NextPart_000_0001_01C698A9.35246370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

S O M ^
P R O Z & C
A M B / E N
M E R / D / A
C / A L / S
X & N A X
L E V / T R A
V A L / U M
V / A G R A

all 50 % off - http://www.chyahoo.com/o/


his hiding-place he kept a few wretched oddments, and one very = beautiful
thing, very beautiful, very wonderful. He had a ring, a = golden ring, a
precious ring.
My birthday-present! he = whispered to himself, as he had often done
in the endless dark days. = Thats what we wants now, yes; we wants it!
He wanted it because it = was a ring of power, and if you slipped that
------=_NextPart_000_0001_01C698A9.35246370-- From majordomo@mil.doit.wisc.edu Mon Jun 26 04:22:22 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumMQ-0000OT-2y for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 04:22:22 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumMO-0008Iu-Ol for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 04:22:22 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FumF7-00004T-00 for ipfix-list@mil.doit.wisc.edu; Mon, 26 Jun 2006 03:14:49 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FumF5-00003X-00 for ipfix@net.doit.wisc.edu; Mon, 26 Jun 2006 03:14:47 -0500 Received: from [10.1.1.104] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 807241BAC9F; Mon, 26 Jun 2006 10:02:20 +0200 (CEST) Date: Mon, 26 Jun 2006 10:14:38 +0200 From: Juergen Quittek To: Hitoshi Irino Cc: ipfix@net.doit.wisc.edu Subject: Re: [ipfix] new version of the IPFIX information model Message-ID: <2DA837AAE1761AC833C34827@[10.1.1.104]> In-Reply-To: <449F51A2.2010802@lab.ntt.co.jp> References: <6AA5730EAA04A4F15B7DAC1A@[195.37.70.133]> <449A4C62.1080608@lab.ntt.co.jp> <449F51A2.2010802@lab.ntt.co.jp> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Dear Hitoshi Irino, Thank you again for the careful review! Like your previous comment, I will consider it as input top the documents IETF last call that will start soon. Thanks, Juergen --On 26.06.2006 12:16 Uhr +0900 Hitoshi Irino wrote: > Dear Juergen: > > I found another (maybe) mistake. In this draft, Information Elements grouped into 12 groups in a table of contents. > 12 groups are: > 5.1. Identifiers, > 5.2. Metering and Exporting Process Configuration > 5.3. Metering and Exporting Process Statistics > 5.4. IP Header Fields > 5.5. Transport Header Fields > 5.6. Sub-IP Header Fields > 5.7. Derived Packet Properties > 5.8. Min/Max Flow Properties > 5.9. Flow Time Stamps > 5.10. Per-Flow Counters > 5.11. Miscellaneous Flow Properties > 5.12. Padding > > But, in section "5. Information Elements" in page 18, this draft describes: > >The elements are grouped into 9 groups according to their semantics and > ^ > >their applicability: > > > > 1. Identifiers > > 2. Metering and Exporting Process Properties > > 3. IP Header Fields > > 4. Transport Header Fields > > 5. Sub-IP Header Fields > > 6. Derived Packet Properties > > 7. Min/Max Flow Properties > > 8. Flow Time Stamps > > 9. Per-Flow Counters > > 10. Miscellaneous Flow Properties > > The sentence describes "9" groups and 10 groups are listed. > Isn't this an error in writing? > > regrads, > Hitoshi Irino > > Juergen Quittek wrote: >> Dear Hitoshi Irino, >> >> Thank you for the thorough review. >> I will keep a record for the next revision. >> >> Thanks, >> >> Juergen >> >> --On 22.06.2006 16:53 Uhr +0900 Hitoshi Irino wrote: >> >>> Dear Juergen >>> >>> I (probably) found a mistake of the Draft. >>> Section 5.4.11 is destinationIPv6PrefixLength, but >>> ElementId 30 is destinationIPv6Mask in the table of Page 16. >>> Correct IE is destinationIPv6PrefixLength, isn't it? >>> >>> regrads, >>> Hitoshi Irino >>> >>> Juergen Quittek wrote: >>>> Dear all, >>>> >>>> I submitted a new version of the IPFIX information model. >>>> Until it gets posted, please find it at >>>> . >>>> >>>> >>>> The new version includes all changes that were requested >>>> by the AD review. Also changes discussed recently on >>>> the mailing list are included. Furthermore, a lot of >>>> clarifications and minor changes have been applied. >>>> >>>> Please find a diff between the previous version -11 and >>>> the new version -12 at >>>> . >>>> >>>> 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/ >>>> >>> >>> >>> -- >>> ---------------------------------------------- >>> NTT Network Service Systems Laboratories >>> Broadband Network Systems Project >>> Service Edge Group >>> >>> Hitoshi Irino >>> Email: irino.hitoshi@lab.ntt.co.jp >>> Tel: +81-422-59-4403 Fax: +81-422-59-4549 >>> >>> >>> -- >>> 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/ >> >> > > > -- > ---------------------------------------------- > NTT Network Service Systems Laboratories > Broadband Network Systems Project > Service Edge Group > > Hitoshi Irino > Email: irino.hitoshi@lab.ntt.co.jp > Tel: +81-422-59-4403 Fax: +81-422-59-4549 > > > -- > 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 ginellejacobson@uaportal.com Mon Jun 26 12:33:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuu1c-0001sM-PW for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 12:33:24 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuu1b-0006Eg-3p for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 12:33:24 -0400 Received: from [212.158.151.10] (helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Futwp-0003Ah-00 for ipfix-list@mil.doit.wisc.edu; Mon, 26 Jun 2006 11:28:27 -0500 Message-Id: <00e101c69935$ad830880$343b4190@nhpdh> From: "nada devine" To: "broderic riddle" Subject: Re: Luxury Date: Mon, 26 Jun 2006 15:33:48 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E1_01C69935.AD830880" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.6 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_00E1_01C69935.AD830880 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable TOP BRANDS - LOW LOW PRICES Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets=20 Leather, silk and white gold sound good? Visit our site for real photos. Everything comes with a certificate, tags and all the extras, plus a warran= ty. http://poonered.com/luxury/ splay-kneed land side vengeance-sated terror-bringing quasi-spatial you-uns emulsion colloid cash sale limousine-landaulet troop train injury-proof soft-haired air machine trouble shooting vice-admiralship harvest queen pedal board cradle snatcher warp beam Non-jewish ostrich-egg derrick making capacity factor grain-cleaning feather cloth self-addiction disability insurance ------=_NextPart_000_00E1_01C69935.AD830880 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

TOP BRANDS - LOW LOW PRICES

Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets

Leather, silk and white gold sound good? Visit our site for real photos.=
Everything comes with a certificate, tags and all the extras, plus a warran= ty.

http://poonered.com/luxury/

splay-kneed land side vengeance-sated
terror-bringing quasi-spatial you-uns
emulsion colloid cash sale limousine-landaulet
troop train injury-proof soft-haired
air machine trouble shooting vice-admiralship
harvest queen pedal board cradle snatcher
warp beam Non-jewish ostrich-egg
derrick making capacity factor grain-cleaning
feather cloth self-addiction disability insurance
= ------=_NextPart_000_00E1_01C69935.AD830880-- From kkslrxcelxn@hotmail.com Mon Jun 26 12:47:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuuEm-0005ej-TH for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 12:47:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Futbf-00048Y-2L for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 12:06:35 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FutQ8-0000SN-0V for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 11:54:43 -0400 Received: from dslb-084-061-197-006.pools.arcor-ip.net ([84.61.197.6] helo=mil.doit.wisc.edu) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FutAL-0007Wa-00 for ipfix-list@mil.doit.wisc.edu; Mon, 26 Jun 2006 10:38:22 -0500 From: "jramzie99" To: ipfix-list@mil.doit.wisc.edu Content-type: text/html Subject: Tiered of been passed over for that promotion because you don’t have the proper Degree? Message-Id: Date: Mon, 26 Jun 2006 10:38:22 -0500 X-Spam-Score: 0.8 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

A Genuine University Degree in 4-6 weeks!


Have you ever thought that the only thing stopping you from a great job and better pay was a few letters behind you name?
Well now you can get them!

BA BSc MA MSc MBA PhD

Within 4-6 weeks!
No Study Required!
100% Verifiable!


These are real, genuine degrees that include Bachelors, Masters, MBA and Doctorate Degrees. They are fully verifiable and certified transcripts are also available.

Just call the number below.
You’ll thank me later…

1-815-828-2222
24 hours a day, 7 days a week including Sundays and Holidays



































nine months in what he had thought was Mad-Eye Moodys company only to From majordomo@mil.doit.wisc.edu Mon Jun 26 22:05:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv2wy-0001dZ-9j for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 22:05:12 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv2wv-0003Uu-Ul for ipfix-archive@lists.ietf.org; Mon, 26 Jun 2006 22:05:12 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1Fv2ne-0004Nl-00 for ipfix-list@mil.doit.wisc.edu; Mon, 26 Jun 2006 20:55:34 -0500 Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fv2nc-0004Ng-00 for ipfix@net.doit.wisc.edu; Mon, 26 Jun 2006 20:55:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 5B9EA34DC5 for ; Tue, 27 Jun 2006 13:55:31 +1200 (NZST) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26683-15 for ; Tue, 27 Jun 2006 13:55:31 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (motoko.itss.auckland.ac.nz [130.216.191.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 3E01034D00 for ; Tue, 27 Jun 2006 13:55:31 +1200 (NZST) Received: from motoko.itss.auckland.ac.nz (localhost.localdomain [127.0.0.1]) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11) with ESMTP id k5R1tV6M007711 for ; Tue, 27 Jun 2006 13:55:31 +1200 Received: (from apache@localhost) by motoko.itss.auckland.ac.nz (8.12.11/8.12.11/Submit) id k5R1tUWb007706 for ipfix@net.doit.wisc.edu; Tue, 27 Jun 2006 13:55:30 +1200 X-Authentication-Warning: motoko.itss.auckland.ac.nz: apache set sender to nevil@auckland.ac.nz using -f Received: from dyn54.caida.org (dyn54.caida.org [192.172.226.54]) by webmail.auckland.ac.nz (Horde MIME library) with HTTP; Tue, 27 Jun 2006 13:55:30 +1200 Message-ID: <20060627135530.0aomw2j83bk8k80c@webmail.auckland.ac.nz> Date: Tue, 27 Jun 2006 13:55:30 +1200 From: Nevil Brownlee To: ipfix Subject: [ipfix] DRAFT agenda for Montreal IETF MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Hi all: IPFIX Agenda for IETF 66, Montreal ---------------------------------- Last modified: 1815, Mon 26 Jun 06 (PDT) The IPFIX meeting is scheduled on Tuesday, 11 July Using jabber, the room is ipfix@jabber.ietf.org [Note: Since 18 Apr 06 IETF makes rooms like this available any time, should you want a place to chat about IPFIX!] Presentation slides (sent to me so far) are at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 (search for IPFIX in the Operations and Management Area) Agenda: 5 min 1) Agenda review 2) IPFIX WG status (Nevil Brownlee) IESG have approved the request to re-charter the IPFIX WG. The Protocol and Architecture drafts are being considered by IESG for approval, and the Information Model draft for IESG Last Call. The AS draft has finished IESG Last Call and is being revised. 3) Work items in the new charter Reports on each of these (would the people working on these email me and tell me who will be reporting, please?) 1. IPFIX Implementation Guidelines draft, to be an Informational RFC (6 months) 2. IPFIX Testing draft, to be an Informational RFC (6 months) 3. IPFIX Reducing Redundancy, to be an Informational RFC (6 months) 4. IPFIX MIB, to be a Standards Track RFC (12 months) 5. IPFIX Biflow draft, to be an Informational RFC (12 months) - Brian Trammell 4) Other drafts draft-trammell-ipfix-file-01.txt - Brian Trammell draft-muenz-ipfix-configuration-00.txt - Gerhard Muenz 5) Setting of Milestone dates 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 ----------------------------------------------------------------------- Nevil Brownlee Computer Science Department | ITSS Phone: +64 9 373 7599 x88941 The University of Auckland FAX: +64 9 373 7453 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 mychalchampagne@covad.com Tue Jun 27 05:39:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvA2v-0004cZ-QO for ipfix-archive@lists.ietf.org; Tue, 27 Jun 2006 05:39:49 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvA2t-0001DN-Ff for ipfix-archive@lists.ietf.org; Tue, 27 Jun 2006 05:39:49 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1Fv9p6-0002zB-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jun 2006 04:25:32 -0500 Received: from BABY (rsa59-3-82-240-142-56.fbx.proxad.net [82.240.142.56]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5R9PUMo019196 for ; Tue, 27 Jun 2006 04:25:30 -0500 Message-Id: <000501c699c3$0f3d8400$3a9fdddc@qjuhfeq> From: "mackenzie franco" To: "wrennie griffith" Subject: Job offer Date: Tue, 27 Jun 2006 08:30:58 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C699C3.0F3D8400" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.9 (+) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C699C3.0F3D8400 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How many times did you think of giving up your permanent job and join another "good looking" work-at-home scheme? And how many of them were successful? Did you earn more than $5000 a month with them? NO? Then you have an opportunity right now and right here! We made it possible for you to get a real part-time job in a world of transportation business and control your income on your own! We will never ask you about your credit rating and never put any inquiries to your credit profile. This is business of partners, we don't take, we give you this opportunity You can become our Representative and take part in a stunning world of financial operations. No more up-front costs or tricks. A steady income is just a click away! The best thing it all depends on you. Being a long-established solid corporation we understand how important it is to provide our customers the best possibilities and support. We always try our best to be cooperative and customer-friendly, you can call or email us any time and ask a question if something is not clear. Get involved in a great transportation business, and start making money in just a few clicks. You will make a fixed amount ($30) out of every shipped product. The usual product quantity range from 10 to 100 packages a month. This is not a dream, you enter a serious market! A unique opportunity where your income depends on you! More information \ apply \ send your resumes to: job@easternbridge.info saddle clip yellow-checked pseudo romanticism eyelet hole dust seal round-table conference bread beetle wool hall spinous-tailed quercitron lake mountain-loving quasi craft fever-lurden Pre-thanksgiving match lining sour-visaged end-measure gray-black world-serving wax-bearing red-coated clew jigger tie-tie quarter-bound ------=_NextPart_000_0005_01C699C3.0F3D8400 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How many times did you think of giving up your
permanent job and join another "good looking"
work-at-home scheme? And how many of them were
successful? Did you earn more than $5000 a month with
them? NO? Then you have an opportunity right now and
right here!

We made it possible for you to get a real part-time
job in a world of transportation business and control
your income on your own! We will never ask you about
your credit rating and never put any inquiries to your
credit profile. This is business of partners, we don't
take, we give you this opportunity

You can become our Representative and take part in a
stunning world of financial operations. No more
up-front costs or tricks. A steady income is just a
click away! The best thing it all depends on you.

Being a long-established solid corporation we
understand how important it is to provide our customers
the best possibilities and support. We always try our
best to be cooperative and customer-friendly, you can
call or email us any time and ask a question if
something is not clear.

Get involved in a great transportation business, and
start making money in just a few clicks. You will make
a fixed amount ($30) out of every shipped product. The
usual product quantity range from 10 to 100 packages a
month. This is not a dream, you enter a serious market!
A unique opportunity where your income depends on you!

More information \ apply \ send your resumes to: job@easternbridge.info

saddle clip yellow-checked pseudo romanticism
eyelet hole dust seal round-table conference
bread beetle wool hall spinous-tailed
quercitron lake mountain-loving quasi craft
fever-lurden Pre-thanksgiving match lining
sour-visaged end-measure gray-black
world-serving wax-bearing red-coated
clew jigger tie-tie quarter-bound
= ------=_NextPart_000_0005_01C699C3.0F3D8400-- From z_rash@bonbon.net Tue Jun 27 11:38:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFdi-0007Fl-Bp for ipfix-archive@lists.ietf.org; Tue, 27 Jun 2006 11:38:10 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvFdh-0007Yd-4g for ipfix-archive@lists.ietf.org; Tue, 27 Jun 2006 11:38:10 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FvFKe-0000dp-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jun 2006 10:18:28 -0500 Received: from ISMAIL.hni627y.org (dsl.dynamic85991504.ttnet.net.tr [85.99.150.4] (may be forged)) by smtp.doit.wisc.edu (8.13.1/8.13.1) with ESMTP id k5RFIQOO001209 for ; Tue, 27 Jun 2006 10:18:27 -0500 Message-Id: <200606271518.k5RFIQOO001209@smtp.doit.wisc.edu> From: "Carlton" To: Subject: Melt away pounds with Hoodia Date: Tue, 27 Jun 2006 18:18:30 +0300 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: nnqMPSmGUOAxTfyS8Il7BqNpSp1Ts9RT72Uc Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit X-Spam-Score: 1.0 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Yo Ipfix-list!. Here's that fat loss pill site you asked about, the one I told you with the amazing Hoodia pills. Hey- if they're good enough for Oprah, then they must be good enough for us lol ;) Check the site out and let me know later how they work for you, hope you lose as many pounds as I did! :) http://www.didyous.com/hd/?52&acrylate Later babe xo From mcduffyo@amer-law.com Tue Jun 27 15:15:56 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvJ2S-000764-Br for ipfix-archive@lists.ietf.org; Tue, 27 Jun 2006 15:15:56 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvJ2Q-0005LU-2i for ipfix-archive@lists.ietf.org; Tue, 27 Jun 2006 15:15:56 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FvIrC-0004mk-00 for ipfix-list@mil.doit.wisc.edu; Tue, 27 Jun 2006 14:04:18 -0500 Received: from amer-law.com (AReims-152-1-83-97.w86-198.abo.wanadoo.fr [86.198.178.97]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5RJ4Eld002684 for ; Tue, 27 Jun 2006 14:04:15 -0500 Message-ID: <000001c69a1c$fc9f06c0$cd0fa8c0@xsw2> Reply-To: "Ba Mcduffy" From: "Ba Mcduffy" To: ipfix-list@mil.doit.wisc.edu Subject: Re: with luuon Date: Tue, 27 Jun 2006 12:07:51 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C699E2.504278B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.6 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C699E2.504278B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Go to our site and econom ize on your med up to 60 % http://xundasefunterx.com , , , , , , breakfast for you, if only you wont have me for supper. Poor little blighter, said William. He had already had as much supper as he could hold; also he had had lots of beer. Poor little blighter! Let him go! Not till he says what he means by lots and none at all, said Bert. I dont want to have me throat cut in me sleep. Hold his toes in the ------=_NextPart_000_0001_01C699E2.504278B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi

Go to our site and econom ize on your med up to 60 %
http://xundasefunterx.com
,
,
,
,
,
,
breakfast for you, if only you wont have me for supper.
Poor little blighter, said William. He had already had as much
supper as he could hold; also he had had lots of beer. Poor little
blighter! Let him go!
Not till he says what he means by lots and none at all, said = Bert.
I dont want to have me throat cut in me sleep. Hold his toes in = the
------=_NextPart_000_0001_01C699E2.504278B0-- From goltzinicol@imgh.org Wed Jun 28 02:05:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvTBC-0002Ye-DY for ipfix-archive@lists.ietf.org; Wed, 28 Jun 2006 02:05:38 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvTBA-0006Hi-3j for ipfix-archive@lists.ietf.org; Wed, 28 Jun 2006 02:05:38 -0400 Received: from p6013-adsau08douji-acca.osaka.ocn.ne.jp ([220.111.229.13] helo=imgh.org) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FvSxd-0002hk-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jun 2006 00:51:37 -0500 Message-ID: <000001c69a76$e5448810$ce17a8c0@yor88> Reply-To: "Nicolau Goltz" From: "Nicolau Goltz" To: ipfix-list@mil.doit.wisc.edu Subject: Re: on tubiu Date: Tue, 27 Jun 2006 22:51:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69A3C.38E5B010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?220.111.229.13 X-Spam-Score: 2.6 (++) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69A3C.38E5B010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , Go to the site and economize up to 60 % on your med http://rungandeoinca.com , , , , , , they were locked in one anothers arms, and rolling nearly into the fire kicking and thumping, while Tom whacked at then both with a branch to bring them to their senses-and that of course only made them madder than ever. That would have been the time for Bilbo to have left. But his poor little feet had been very squashed in Berts big paw, and he had no breath in his body, and his head was going round; so there he lay for a ------=_NextPart_000_0001_01C69A3C.38E5B010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
,
Go to the site and economize up to 60 % on your med
http://rungandeoinca.com
,
,
,
,
,
,
they were locked in one anothers arms, and rolling nearly into the = fire
kicking and thumping, while Tom whacked at then both with a branch = to
bring them to their senses-and that of course only made them madder = than
ever. That would have been the time for Bilbo to have left. But his = poor
little feet had been very squashed in Berts big paw, and he had no
breath in his body, and his head was going round; so there he lay for = a
------=_NextPart_000_0001_01C69A3C.38E5B010-- From majordomo@mil.doit.wisc.edu Wed Jun 28 08:41:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZMN-0007h9-6y for ipfix-archive@lists.ietf.org; Wed, 28 Jun 2006 08:41:35 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvZMK-0003QI-R1 for ipfix-archive@lists.ietf.org; Wed, 28 Jun 2006 08:41:35 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FvZ22-0006Au-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jun 2006 07:20:34 -0500 Received: from faui70.informatik.uni-erlangen.de ([131.188.37.37]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FvZ21-0006Ap-00 for ipfix@net.doit.wisc.edu; Wed, 28 Jun 2006 07:20:33 -0500 Received: from faui7as.informatik.uni-erlangen.de (faui7as [131.188.37.230]) by faui70.informatik.uni-erlangen.de (8.9.3p2/8.1.3-FAU) with ESMTP id OAA18754; Wed, 28 Jun 2006 14:20:30 +0200 (MEST) Received: from [127.0.0.1] (faui7as.informatik.uni-erlangen.de [131.188.37.230]) by faui7as.informatik.uni-erlangen.de (Postfix) with ESMTP id 7F9D9CC187; Wed, 28 Jun 2006 14:20:30 +0200 (CEST) Message-ID: <44A27402.9040202@informatik.uni-erlangen.de> Date: Wed, 28 Jun 2006 14:20:18 +0200 From: Falko Dressler Organization: University of Erlangen-Nuremberg, Germany User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ipfix@net.doit.wisc.edu Subject: [ipfix] [Fwd: I-D ACTION:draft-dressler-ipfix-aggregation-03.txt] X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------040001080903040208050105" Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 This is a multi-part message in MIME format. --------------040001080903040208050105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello everybody, we prepared a new version of the aggregation draft. Besides several minor changes we - changed the term meta-flow to flow or flow aggregate, respectively - updated the flow key correlations - updated the terminology to correspond to the IPFIX protocol/info model - similarly updated the architecture Best regards, Falko. -------- Original Message -------- Subject: I-D ACTION:draft-dressler-ipfix-aggregation-03.txt Date: Tue, 27 Jun 2006 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPFIX Aggregation Author(s) : F. Dressler, et al. Filename : draft-dressler-ipfix-aggregation-03.txt Pages : 19 Date : 2006-6-27 IPFIX Aggregation describes a methodology for reducing the amount of measurement data exchanged between monitoring devices (IPFIX exporters) and analyzers (IPFIX collectors). Using aggregation techniques, measurement information of multiple similar flows is aggregated into one compound flow aggregate. Subsets of flows eligible for aggregation, as well as the degree of similarity, can be customized using aggregation rules. To ensure efficient communication of both aggregated flows and the aggregation rules used, the IPFIX Protocol and IPFIX Information Model are slightly extended to allow for two new abstract data types and a new type of template set. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dressler-ipfix-aggregation-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-dressler-ipfix-aggregation-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-dressler-ipfix-aggregation-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Dr.-Ing. Falko Dressler Computer Networks and Communication Systems University of Erlangen-Nuremberg, Germany Phone: +49 9131 85-27914 / Fax: +49 9131 85-27409 EMail: dressler@informatik.uni-erlangen.de / fd@acm.org WWW: http://www7.informatik.uni-erlangen.de/~dressler/ --------------040001080903040208050105 Content-Type: Message/External-body; name="draft-dressler-ipfix-aggregation-03.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-dressler-ipfix-aggregation-03.txt" Content-Type: text/plain Content-ID: <2006-6-27122621.I-D@ietf.org> --------------040001080903040208050105 Content-Type: text/plain; name*0="file:///C|/DOKUME%7E1/DRESSLER/LOKALE%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C|/DOKUME%7E1/DRESSLER/LOKALE%7E1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040001080903040208050105-- -- 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 Jun 29 00:38:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvoIg-0005vg-HQ for ipfix-archive@lists.ietf.org; Thu, 29 Jun 2006 00:38:46 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvoIg-0004Js-2k for ipfix-archive@lists.ietf.org; Thu, 29 Jun 2006 00:38:46 -0400 Received: from majordomo by mil.doit.wisc.edu with local (Exim 3.13 #1) id 1FvoDP-0007VW-00 for ipfix-list@mil.doit.wisc.edu; Wed, 28 Jun 2006 23:33:19 -0500 Received: from co300216-ier2.net.avaya.com ([198.152.13.103]) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FvoDN-0007VR-00 for ipfix@net.doit.wisc.edu; Wed, 28 Jun 2006 23:33:17 -0500 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5T4TvII020858 for ; Thu, 29 Jun 2006 00:29:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipfix] RE: WG Action: RECHARTER: IP Flow Information Export (ipfix) Date: Thu, 29 Jun 2006 07:33:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Action: RECHARTER: IP Flow Information Export (ipfix) Thread-Index: Acaa9ON41TjcORR4QNiqXFwxxn/5EAAP2Slg From: "Romascanu, Dan \(Dan\)" To: "IESG Secretary" Cc: "Nevil Brownlee" , "Dave Plonka" , , "Juergen Quittek" X-Scanner: InterScan AntiVirus for Sendmail Precedence: bulk Sender: majordomo listserver X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 I was expecting for the announcement to go out with the 4th paragraph including the improved text, and not with the old text and the comment.=20 Can you please make the change on the WG charter page:=20 OLD:=20 Out of scope are modifications to the core IPFIX and PSAMP protocol specifications. In scope is the definition of new IPFIX and PSAMP information elements. NEW:=20 Modifications to the core IPFIX and PSAMP protocol specifications is out of scope for this charter. However, the definition of new IPFIX and PSAMP information elements is within the scope of this charter. =20 Also, please replace the name of Dave Plonka with Juergen Quittek on the WG Chairs line.=20 Thanks and Regards, Dan =20 =20 > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 > Sent: Wednesday, June 28, 2006 10:50 PM > To: ietf-announce@ietf.org > Cc: Nevil Brownlee; Dave Plonka; ipfix@net.doit.wisc.edu > Subject: WG Action: RECHARTER: IP Flow Information Export (ipfix)=20 >=20 > The charter of the IP Flow Information Export (ipfix) working=20 > group in the Operations and Management Area of the IETF has=20 > been updated. For additional information, please contact the=20 > Area Directors or the working group Chairs. >=20 > COMMENT >=20 > Better wording for 4th paragraph: >=20 > "Modifications to the core IPFIX and PSAMP protocol=20 > specifications is out of scope for this charter. However, the=20 > definition of new IPFIX and PSAMP information elements is=20 > within the scope of this charter." >=20 > No need to change the meeting minutes, I believe.=20 >=20 > Thanks and Regards, >=20 > Dan >=20 > +++ >=20 > IP Flow Information Export (ipfix) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Current Status: Active Working Group >=20 > Chair(s): > Nevil Brownlee Dave Plonka=20 > =20 >=20 >=20 > Operations and Management Area Director(s): > Dan Romascanu =20 > David Kessens =20 >=20 > Operations and Management Area Advisor: > Dan Romascanu =20 >=20 > Mailing Lists: > General Discussion: ipfix@net.doit.wisc.edu > To Subscribe: majordomo@net.doit.wisc.edu > In Body: subscribe ipfix > Archive: http://ipfix.doit.wisc.edu/archive/ >=20 > Description of Working Group: >=20 > The IPFIX working group has specified the Information Model=20 > (to describe > IP flows) and the IPFIX protocol (to transfer IP flow data from IPFIX > exporters to collectors). The PSAMP working group has specified the > usage of the IPFIX protocol for exporting packet records. With both > specifications available, several implementers have started building > applications using the IPFIX protocol. >=20 > At two interoperability testing events, several IPFIX protocol > implementations were tested. The experiences made at these events were > fed back to IPFIX protocol specification, particularly for removing > ambiguities. In addition, several lessons were learned about how to > implement and use IPFIX correctly and efficiently. The exchange among > different implementers further led to new ideas for advanced usage of > IPFIX. Many of these ideas are currently documented in individual > Internet drafts. >=20 > The goal of the IPFIX working group is now to produce 'best current > practice' and 'guideline' documents concerning implementation, > application and usage of the IPFIX protocol. >=20 > Out of scope are modifications to the core IPFIX and PSAMP protocol > specifications. In scope is the definition of new IPFIX and PSAMP > information elements. >=20 > Specific Goals >=20 > o Develop guidelines for implementers based on experiences > gained individually by implementers and jointly at interoperability > testing events. The guidelines will give recommendations for > integrating IPFIX observation points, metering processes, > exporting processes and collecting processes into the packet flow > at different kinds of IPFIX devices. They will make suggestions for > efficient implementation of the IPFIX protocol features and identify > parts of the IPFIX specification that have already been misunderstood > by several implementors. For some implementation choices that the > protocol specification leaves to the implementer, the guidelines will > discuss advantages and disadvantages of the different choices. > Several recent individual drafts call for new Information Elements; > The implementation guidelines will explain procedures for requesting, > reviewing and approving new IEs. > Deliverables: > 1. IPFIX Implementation Guidelines draft, to be an Informational RFC > (6 months) > 2. IPFIX Testing draft, to be an Informational RFC (6 months) >=20 > o Develop methods and means for an efficient use of the IPFIX > protocol by reducing redundancy in flow reports. The basic idea > to be followed is very simple. For multiple flow records that all > report the same value in one or more of the contained IPFIX > information elements, those values are removed from the flow > records and instead reported once for all in a separate record. > Such an approach integrates very well with the IPFIX protocol and > only needs a few simple methods for expressing the relationship > between flow records and corresponding separate records. > Deliverable: > 3. IPFIX Reducing Redundancy, to be an Informational RFC (6 months) >=20 > o Create an IPFIX MIB, for reporting information and statistics > of IPFIX metering, exporting and collecing processes. Much of this > work has already been done by the PSAMP working group, and by > individuals working on IPFIX collectors. Deliverable: > 4. IPFIX MIB, to be a Standards Track RFC (12 months) >=20 > o Develop an effective method for exporting information about > bidirectional flows ('biflows'). The IP security community has > expressed a strong need to collect data on bidrectional flows. > A recent individual draft discusses several different ways to > support biflows in IPFIX - this work will produce a single, > best-practice method for handling them, without requiring changes > to the IPFIX protocol. > Deliverable: > 5. IPFIX Biflow draft, to be an Informational RFC (12 months) >=20 > Milestones: >=20 > August 06 Publish Internet Draft on IPFIX Implementation Guidelines >=20 > August 06 Publish Internet Draft on IPFIX Testing >=20 > August 06 Publish Internet Draft on Reducing Redundancy in IPFIX=20 > data transfer >=20 > August 06 Publish Internet Draft on IPFIX MIB >=20 > August 06 Publish Internet Draft on Handling IPFIX Bidirectional > Flows >=20 >=20 > November 06 Submit IPFIX Implementation Guidelines draft to IESG for > publication as Informational RFC >=20 > November 06 Submit IPFIX Testing draft to IESG for > publication as Informational RFC >=20 > November 06 Submit IPFIX Reducing Redundancy draft to IESG for > publication as Informational RFC >=20 > March 07 Submit IPFIX Biflows draft to IESG for > publication as Informational RFC >=20 >=20 > March 07 Submit IPFIX MIB draft to IESG for > publication as Standards track RFC >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=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/ From caily@ediets.com Thu Jun 29 06:15:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvtYJ-0002IE-LX for ipfix-archive@lists.ietf.org; Thu, 29 Jun 2006 06:15:15 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvtYF-000224-AI for ipfix-archive@lists.ietf.org; Thu, 29 Jun 2006 06:15:15 -0400 Received: from 24-183-239-160.dhcp.kgpt.tn.charter.com ([24.183.239.160] helo=ediets.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1FvtLm-0005Fn-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jun 2006 05:02:18 -0500 Message-ID: <000001c69b63$90f94280$4d99a8c0@erb35> Reply-To: "Rosamond Cail" From: "Rosamond Cail" To: ipfix-list@mil.doit.wisc.edu Subject: Re: to rodip Date: Thu, 29 Jun 2006 03:05:36 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69B28.E49A6A80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?24.183.239.160 X-Spam-Score: 2.6 (++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69B28.E49A6A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SA s VE UP TO 5 f 0 % on your PH a ARMAC l Y ! http://tocasonal.com =20 V c IAG k RA $ 6 u 9,9 a 5 ( 10 t a able y ts ) V r ALI j UM $ 10 t 5,4 h 5 ( 10 t i abl v ets ) C o IAL w IS $ 9 j 9,9 v 5 ( 10 t t ablet j s ) X l ANA l X $ 12 q 3,4 q 5 ( 30 ta z ble m ts ) AM c BIE s N $ 6 x 8,0 r 0 ( 10 t o able l ts ) And ma o ny othe d r . , , , , , building themselves places to live in among the more pleasant woods in the valleys and along the river-shores. There were many of them, and they were brave and well-armed, and even the Wargs dared not attack them if there were many together, or in the bright day. But now they had planned with the goblins help to come by night upon some of the villages nearest the mountains. If their plan had been carried out, ------=_NextPart_000_0001_01C69B28.E49A6A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SA s VE UP TO 5 f = 0 % on your PH a ARMAC l = Y !

http://tocasonal.com

V c = IAG k RA $ 6 u = 9,9 a = 5 ( 10 t a able y = ts )

V r = ALI j UM $ 10 t = 5,4 h = 5 ( 10 t i abl v = ets )

C o = IAL w IS $ 9 j = 9,9 v = 5 ( 10 t t ablet j = s )

X l = ANA l X $ 12 q = 3,4 q = 5 ( 30 ta z ble m = ts )

AM c = BIE s N $ 6 x = 8,0 r = 0 ( 10 t o able l = ts )

And ma o = ny othe d r =

,
,
,
,
,
building themselves places to live in among the more pleasant woods = in
the valleys and along the river-shores. There were many of them, and
they were brave and well-armed, and even the Wargs dared not attack = them
if there were many together, or in the bright day. But now they had
planned with the goblins help to come by night upon some of the
villages nearest the mountains. If their plan had been carried = out,
------=_NextPart_000_0001_01C69B28.E49A6A80-- From wysongagijsbert@dority-manning.com Thu Jun 29 18:39:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw5AF-000486-Mo for ipfix-archive@lists.ietf.org; Thu, 29 Jun 2006 18:39:11 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw5AE-0006cq-86 for ipfix-archive@lists.ietf.org; Thu, 29 Jun 2006 18:39:11 -0400 Received: from [201.225.160.74] (helo=dority-manning.com) by mil.doit.wisc.edu with smtp (Exim 3.13 #1) id 1Fw56J-0002ie-00 for ipfix-list@mil.doit.wisc.edu; Thu, 29 Jun 2006 17:35:09 -0500 Message-ID: <000001c69bcc$b16b9810$4231a8c0@kia46> Reply-To: "Gijsbert Wysong" From: "Gijsbert Wysong" To: ipfix-list@mil.doit.wisc.edu Subject: Re: at qoees Date: Thu, 29 Jun 2006 15:38:07 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C69B92.050CC010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-RBL-Warning: (bl.spamcop.net) Blocked - see http://www.spamcop.net/bl.shtml?201.225.160.74 X-Spam-Score: 4.1 (++++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C69B92.050CC010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , Go to the web site and economise up to 50 % on your Med http://aturalabur.com , , , , , , Victory had been assured before the fall of night, but the pursuit was still on foot, when Bilbo returned to the camp; and not many were in the valley save the more grievously wounded. Where are the Eagles? he asked Gandalf that evening, as he lay wrapped in many warm blankets. Some are in the hunt, said the wizard, but most have gone back to ------=_NextPart_000_0001_01C69B92.050CC010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi
,
Go to the web site and economise up to 50 % on your Med http://aturalabur.com
,
,
,
,
,
,
Victory had been assured before the fall of night, but the = pursuit
was still on foot, when Bilbo returned to the camp; and not many were = in
the valley save the more grievously wounded.
Where are the Eagles? he asked Gandalf that evening, as he lay
wrapped in many warm blankets.
Some are in the hunt, said the wizard, but most have gone back = to
------=_NextPart_000_0001_01C69B92.050CC010-- From 158bernard@qldsugar.com Fri Jun 30 11:33:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwKzQ-0004CP-TF for ipfix-archive@lists.ietf.org; Fri, 30 Jun 2006 11:33:04 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwKzO-0006AR-M7 for ipfix-archive@lists.ietf.org; Fri, 30 Jun 2006 11:33:04 -0400 Received: from pool-72-75-208-23.bflony.east.verizon.net ([72.75.208.23] helo=G-EZFKPK6ZN54LN.quae.com) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FwKus-0005Iv-00; Fri, 30 Jun 2006 10:28:22 -0500 From: "Elton Chung" <266jacobo@ciberaula.infase.es> To: Subject: Fw: Re: Need a University {}Degree to obtain the career you?ve always wanted? Date: Fri, 30 Jun 2006 11:28:25 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: ml4QJJxc1WGiWx3quKBsBNizvDG8kLQnmmSI Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 8bit Message-Id: X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Good day Ipfix-list!. There are no enforced tests, classes, books, or interviews ! Capture a_Bachelors, Masters., MBA, and Doctorate (PhD) diploma. Acquire the earnings and glorification_that comes with a.diploma ! Not a single person is turned away Anonymity set Buzz Right Now! +1 (831) 302 66 63 7 days a week 24 7 *-+*-+*-+*-+*-+*-+*-+*-+*-+*-+*-+ abdominal cardboard bucknell abed alongside athwart akron brutal From yiannis4013theobald@yemeni.cc Fri Jun 30 15:21:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOYr-0005pt-9t for ipfix-archive@lists.ietf.org; Fri, 30 Jun 2006 15:21:53 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOYq-00005r-1R for ipfix-archive@lists.ietf.org; Fri, 30 Jun 2006 15:21:53 -0400 Received: from up.doit.wisc.edu ([144.92.9.73] helo=smtp.doit.wisc.edu) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FwOK7-0003jg-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jun 2006 14:06:39 -0500 Received: from c-67-186-47-91.hsd1.oh.comcast.net (c-67-186-47-91.hsd1.oh.comcast.net [67.186.47.91]) by smtp.doit.wisc.edu (8.13.1/8.13.1) with SMTP id k5UJ6bgr009337 for ; Fri, 30 Jun 2006 14:06:37 -0500 Message-ID: From: yancy To: ipfix-list@mil.doit.wisc.edu Subject: fw[8]: Low-price S0ft V1agra is at $1.62 only. Date: Fri, 30 Jun 2006 22:01:35 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_4DDB8997.EC08F674" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa This is a multi-part message in MIME format. ------=_NextPart_000_0000_4DDB8997.EC08F674 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit ------=_NextPart_000_0000_4DDB8997.EC08F674 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable

viagra 100mg - 1.56$
cialis 20mg - 3$
levitra 20 mg - 2.78$

  • We guarantee 100% top-quality of the= product we offer
  • We offer a money-back guarantee in case the product doesn't = work for you or you may be somehow dissatisfied by its = performance
  • We've efficiently streamlined our service, letting you buy = from us in a very discreet, non-embarrassing and hassle-free manner =

special offer - click here=

------=_NextPart_000_0000_4DDB8997.EC08F674-- From desireewilder@hotbox.com Fri Jun 30 19:14:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwSBd-0003wO-FN for ipfix-archive@lists.ietf.org; Fri, 30 Jun 2006 19:14:09 -0400 Received: from mil.doit.wisc.edu ([128.104.31.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwSBc-0000nI-7L for ipfix-archive@lists.ietf.org; Fri, 30 Jun 2006 19:14:09 -0400 Received: from 20151237088.user.veloxzone.com.br ([201.51.237.88] helo=BABY) by mil.doit.wisc.edu with esmtp (Exim 3.13 #1) id 1FwRzd-0001Eb-00 for ipfix-list@mil.doit.wisc.edu; Fri, 30 Jun 2006 18:01:45 -0500 Message-Id: <00d801c69c90$d20e1600$c1fd146d@ukjrxnx> From: "natalie butcher" To: "vernor jeffers" Subject: Re: Your Luxury Date: Fri, 30 Jun 2006 22:07:18 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D8_01C69C90.D20E1600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. ------=_NextPart_000_00D8_01C69C90.D20E1600 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable TOP BRANDS - LOW LOW PRICES Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets=20 Leather, silk and white gold sound good? Visit our site for real photos. Everything comes with a certificate, tags and all the extras, plus a warran= ty. http://grownews.com/luxury/ slime thickening tank dome field poa grass horse dam needle diatom fire clay balm leaf light-complexioned palsy-quaking fixation pause thrill-sated tar-boiling offertory veil V thread tear-purchased Anti-athanasian broad-set wasp nest cerium dioxide back letter iron family drag fold box beam large-viewed winning gallery post-obit fork-tined ------=_NextPart_000_00D8_01C69C90.D20E1600 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

TOP BRANDS - LOW LOW PRICES

Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets

Leather, silk and white gold sound good? Visit our site for real photos.=
Everything comes with a certificate, tags and all the extras, plus a warran= ty.

http://grownews.com/luxury/

slime thickening tank dome field poa grass
horse dam needle diatom fire clay
balm leaf light-complexioned palsy-quaking
fixation pause thrill-sated tar-boiling
offertory veil V thread tear-purchased
Anti-athanasian broad-set wasp nest
cerium dioxide back letter iron family
drag fold box beam large-viewed
winning gallery post-obit fork-tined
= ------=_NextPart_000_00D8_01C69C90.D20E1600--