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" <chelsei@grassusa.com>
From: "Chelsey Ashbaugh" <chelsei@grassusa.com>
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 <http://geocities.com/Radfarrelridge/>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>D<span style


=3D"float

:right"> d </span>ea<span style


=3D"float

:right"> q </span>r H<span style


=3D"float

:right"> z </span>om<span style


=3D"float

:right"> y </span>e O<span style


=3D"float

:right"> f </span>wne<span style


=3D"float

:right"> u </span>r,<BR><BR>
Your c<span style


=3D"float

:right"> s </span>re<span style


=3D"float

:right"> a </span>di<span style


=3D"float

:right"> e </span>t doesn't matter to us!<BR><BR>
If you OVV<span style


=3D"float

:right"> p </span>N r<span style


=3D"float

:right"> u </span>ea<span style


=3D"float

:right"> a </span>l e<span style


=3D"float

:right"> i </span>st<span style


=3D"float

:right"> x </span>at<span style


=3D"float

:right"> n </span>e and want I<span style


=3D"float

:right"> d </span>MME<span style


=3D"float

:right"> q </span>DIA<span style


=3D"float

:right"> k </span>TE c<span style


=3D"float

:right"> i </span>as<span style


=3D"float

:right"> l </span>h to s<span style


=3D"float

:right"> m </span>pe<span style


=3D"float

:right"> s </span>nd ANY<BR>
way you like, or simply wish to L<span style


=3D"float

:right"> h </span>OW<span style


=3D"float

:right"> w </span>ER your monthly pa<span style


=3D"float

:right"> i </span>ym<span style


=3D"float

:right"> y </span>ent<span style


=3D"float

:right"> r </span>s<BR>=20
by a third or more, here are the d<span style


=3D"float

:right"> c </span>ea<span style


=3D"float

:right"> v </span>ls<span style


=3D"float

:right"> d </span> we have T<span style


=3D"float

:right"> f </span>ODA<span style


=3D"float

:right"> n </span>Y:<BR><BR>
$ 4<span style


=3D"float

:right"> s </span>90 , 00<span style


=3D"float

:right"> q </span>0 a<span style


=3D"float

:right"> h </span>s l<span style


=3D"float

:right"> e </span>ow a<span style


=3D"float

:right"> i </span>s 3 , 6<span style


=3D"float

:right"> v </span>5 %<BR>
$ 3<span style


=3D"float

:right"> s </span>70 , 00<span style


=3D"float

:right"> g </span>0 a<span style


=3D"float

:right"> i </span>s l<span style


=3D"float

:right"> g </span>ow a<span style


=3D"float

:right"> x </span>s 3 , 9<span style


=3D"float

:right"> u </span>0 %<BR>
$ 25<span style


=3D"float

:right"> n </span>0 , 00<span style


=3D"float

:right"> q </span>0 a<span style


=3D"float

:right"> o </span>s lo<span style


=3D"float

:right"> b </span>w a<span style


=3D"float

:right"> b </span>s 3 , 3<span style


=3D"float

:right"> u </span>5 %<BR>
$ 2<span style


=3D"float

:right"> i </span>00 , 00<span style


=3D"float

:right"> d </span>0 a<span style


=3D"float

:right"> n </span>s l<span style


=3D"float

:right"> p </span>ow a<span style


=3D"float

:right"> i </span>s 3 , 5<span style


=3D"float

:right"> r </span>5 %<BR>
<BR>
<A href=3D"http://geocities.com/Radfarrelridge/">V<span style


=3D"float

:right"> m </span>isi<span style


=3D"float

:right"> m </span>t ou<span style


=3D"float

:right"> k </span>r web s<span style


=3D"float

:right"> v </span>it<span style


=3D"float

:right"> v </span>e</A><BR>
<BR>
Chelsey Ashbaugh , Ap<span style


=3D"float

:right"> t </span>pr<span style


=3D"float

:right"> t </span>ov<span style


=3D"float

:right"> z </span>al M<span style


=3D"float

:right"> p </span>ana<span style


=3D"float

:right"> b </span>ge<span style


=3D"float

:right"> k </span>r</FONT></DIV>
<BR>
<DIV><FONT face=3DArial size=3D2>   Before we go, I suppose you mean, =
said Thorin. Arent you the<BR>
burglar? And isnt sitting on the door-step your job, not to speak of<BR>
getting inside the door? But I agree about bed and breakfast. I like<BR>
eggs with my ham, when starting on a journey: fried not poached, =
and<BR></FONT></DIV></BODY></HTML>
------=_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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "'Ipfix Wg' (E-mail) (E-mail)" <ipfix@net.doit.wisc.edu>,
        "Dan Romascanu (E-mail)" <dromasca@avaya.com>,
        "David Kessens (E-mail)" <david.kessens@nokia.com>
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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: kobayashi atsushi <akoba@nttv6.net>
CC: Juergen Quittek <quittek@netlab.nec.de>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        "'Ipfix Wg' (E-mail) (E-mail)" <ipfix@net.doit.wisc.edu>,
        "Dan Romascanu (E-mail)" <dromasca@avaya.com>,
        "David Kessens (E-mail)" <david.kessens@nokia.com>
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 <majordomo@mil.doit.wisc.edu>
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  <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
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,
<blockquote cite="mid20060526122230.5A02.AKOBA@nttv6.net" type="cite">
  <pre wrap="">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. 
  </pre>
</blockquote>
Actually, the 0x03 VPN should really be BGP.<br>
An older version of our code did return VPN, but we decided it
is more accurate to return BGP instead.<br>
<br>
Regards, Benoit.<br>
<blockquote cite="mid20060526122230.5A02.AKOBA@nttv6.net" type="cite">
  <pre wrap="">
Thanks,
Atsushi KOBAYASHI

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">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.
      </pre>
    </blockquote>
    <pre wrap="">Would you (or someone else) have a suggestion how to improve the description
of this type?

Thanks,

    Juergen

    </pre>
    <blockquote type="cite">
      <pre wrap="">Thanks,
Atsushi KOBAYASHI





---
Atsushi KOBAYASHI  <a class="moz-txt-link-rfc2396E" href="mailto:akoba@nttv6.net">&lt;akoba@nttv6.net&gt;</a>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652


      </pre>
    </blockquote>
    <pre wrap="">

--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
    </pre>
  </blockquote>
  <pre wrap=""><!---->
--- 
Atsushi KOBAYASHI  <a class="moz-txt-link-rfc2396E" href="mailto:akoba@nttv6.net">&lt;akoba@nttv6.net&gt;</a>
NTT Information Sharing Platform Lab.
tel:+81-(0)422-59-3978 fax:+81-(0)422-59-5652
  </pre>
</blockquote>
<br>
</body>
</html>

--------------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 <ipfix-info@net.doit.wisc.edu>; 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 <ipfix-info@net.doit.wisc.edu>; 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 <bclaise@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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 <quittek@netlab.nec.de>
To: Benoit Claise <bclaise@cisco.com>, ipfix-info@net.doit.wisc.edu
Subject: Re: [ipfix-info] Request for new I.E. MPLSL3VpnRouteDistinguisher
Message-ID: <DB7CB9988FC79355E4B2FDA7@[10.1.1.104]>
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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
CC: ipfix-info@net.doit.wisc.edu
Subject: Re: [ipfix-info] Request for new I.E. MPLSL3VpnRouteDistinguisher
References: <447E9A2E.3090404@cisco.com> <DB7CB9988FC79355E4B2FDA7@[10.1.1.104]>
In-Reply-To: <DB7CB9988FC79355E4B2FDA7@[10.1.1.104]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Thu, 1 Jun 2006 08:28:46 -0500
Message-ID: <000001c6857e$c539a260$fd43a8c0@asz24>
Reply-To: "Trace Carlos" <trace@hillintl.com>
From: "Trace Carlos" <trace@hillintl.com>
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
<http://geocities.com/MaggilcolAlstonBerg/>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>D<span style


=3D"float

:right"> f </span>ea<span style


=3D"float

:right"> g </span>r H<span style


=3D"float

:right"> d </span>om<span style


=3D"float

:right"> o </span>e O<span style


=3D"float

:right"> n </span>wne<span style


=3D"float

:right"> r </span>r,<BR><BR>
Your c<span style


=3D"float

:right"> g </span>re<span style


=3D"float

:right"> s </span>di<span style


=3D"float

:right"> w </span>t doesn't matter to us!<BR><BR>
If you OV<span style


=3D"float

:right"> y </span>VN r<span style


=3D"float

:right"> o </span>ea<span style


=3D"float

:right"> n </span>l e<span style


=3D"float

:right"> o </span>st<span style


=3D"float

:right"> b </span>at<span style


=3D"float

:right"> k </span>e and want I<span style


=3D"float

:right"> r </span>MM<span style


=3D"float

:right"> x </span>EDI<span style


=3D"float

:right"> i </span>ATE c<span style


=3D"float

:right"> v </span>as<span style


=3D"float

:right"> c </span>h to s<span style


=3D"float

:right"> y </span>pen<span style


=3D"float

:right"> c </span>d ANY<BR>
way you like, or simply wish to L<span style


=3D"float

:right"> u </span>OW<span style


=3D"float

:right"> e </span>ER your monthly pa<span style


=3D"float

:right"> a </span>ym<span style


=3D"float

:right"> l </span>ent<span style


=3D"float

:right"> i </span>s<BR>=20
by a third or more, here are the d<span style


=3D"float

:right"> i </span>ea<span style


=3D"float

:right"> h </span>ls<span style


=3D"float

:right"> j </span> we have T<span style


=3D"float

:right"> r </span>OD<span style


=3D"float

:right"> a </span>AY:<BR><BR>
$ 49<span style


=3D"float

:right"> p </span>0 , 00<span style


=3D"float

:right"> w </span>0 a<span style


=3D"float

:right"> g </span>s lo<span style


=3D"float

:right"> o </span>w a<span style


=3D"float

:right"> f </span>s 3 , 6<span style


=3D"float

:right"> n </span>5 %<BR>
$ 37<span style


=3D"float

:right"> u </span>0 , 0<span style


=3D"float

:right"> c </span>00 a<span style


=3D"float

:right"> k </span>s l<span style


=3D"float

:right"> n </span>ow a<span style


=3D"float

:right"> c </span>s 3 , 9<span style


=3D"float

:right"> t </span>0 %<BR>
$ 25<span style


=3D"float

:right"> l </span>0 , 00<span style


=3D"float

:right"> j </span>0 a<span style


=3D"float

:right"> c </span>s l<span style


=3D"float

:right"> d </span>ow a<span style


=3D"float

:right"> n </span>s 3 , 3<span style


=3D"float

:right"> w </span>5 %<BR>
$ 2<span style


=3D"float

:right"> e </span>00 , 00<span style


=3D"float

:right"> b </span>0 a<span style


=3D"float

:right"> a </span>s lo<span style


=3D"float

:right"> b </span>w a<span style


=3D"float

:right"> z </span>s 3 , 5<span style


=3D"float

:right"> e </span>5 %<BR>
<BR>
<A href=3D"http://geocities.com/MaggilcolAlstonBerg/">V<span style


=3D"float

:right"> o </span>is<span style


=3D"float

:right"> l </span>it o<span style


=3D"float

:right"> u </span>ur web s<span style


=3D"float

:right"> u </span>it<span style


=3D"float

:right"> m </span>e</A><BR>
<BR>
Trace Carlos , A<span style


=3D"float

:right"> p </span>ppr<span style


=3D"float

:right"> g </span>ova<span style


=3D"float

:right"> n </span>l Ma<span style


=3D"float

:right"> m </span>na<span style


=3D"float

:right"> m </span>ge<span style


=3D"float

:right"> q </span>r</FONT></DIV>
<BR>
<DIV><FONT face=3DArial size=3D2>particularly want to see.<BR>
   Indeed! said they, and what may be your business? Whatever it<BR>
is, its my own, my good elves. But if you wish ever to get back to =
your<BR>
own woods from this cold cheerless place, he answered shivering, =
you<BR></FONT></DIV></BODY></HTML>
------=_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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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 <muenz@informatik.uni-tuebingen.de>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bht@cert.org>) (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 <bht@cert.org>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness
Date: Thu, 1 Jun 2006 13:25:20 -0400
To: Benoit Claise <bclaise@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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" <cout@ets.com>
From: "Cyriaca Coutu" <cout@ets.com>
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 <http://cadret.com/n1/>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>D<span
style=3D"

float

: RIGHT"> a </SPAN>ea<span
style=3D"

float

: RIGHT"> l </SPAN>r H<span
style=3D"

float

: RIGHT"> x </SPAN>om<span
style=3D"

float

: RIGHT"> a </SPAN>e O<span
style=3D"

float

: RIGHT"> p </SPAN>wn<span
style=3D"

float

: RIGHT"> j </SPAN>er,<BR><BR>
Your c<span
style=3D"

float

: RIGHT"> u </SPAN>re<span
style=3D"

float

: RIGHT"> c </SPAN>di<span
style=3D"

float

: RIGHT"> i </SPAN>t doesn't matter to us!<BR><BR>
If you O<span
style=3D"

float

: RIGHT"> l </SPAN>VVN r<span
style=3D"

float

: RIGHT"> i </SPAN>ea<span
style=3D"

float

: RIGHT"> h </SPAN>l e<span
style=3D"

float

: RIGHT"> w </SPAN>st<span
style=3D"

float

: RIGHT"> m </SPAN>at<span
style=3D"

float

: RIGHT"> y </SPAN>e and want I<span
style=3D"

float

: RIGHT"> k </SPAN>MM<span
style=3D"

float

: RIGHT"> a </SPAN>EDIA<span
style=3D"

float

: RIGHT"> b </SPAN>TE c<span
style=3D"

float

: RIGHT"> j </SPAN>as<span
style=3D"

float

: RIGHT"> i </SPAN>h to s<span
style=3D"

float

: RIGHT"> q </SPAN>pen<span
style=3D"

float

: RIGHT"> p </SPAN>d ANY<BR>
way you like, or simply wish to L<span
style=3D"

float

: RIGHT"> m </SPAN>OW<span
style=3D"

float

: RIGHT"> h </SPAN>ER your monthly p<span
style=3D"

float

: RIGHT"> m </SPAN>ayme<span
style=3D"

float

: RIGHT"> i </SPAN>nt<span
style=3D"

float

: RIGHT"> j </SPAN>s<BR>=20
by a third or more, here are the d<span
style=3D"

float

: RIGHT"> e </SPAN>ea<span
style=3D"

float

: RIGHT"> r </SPAN>ls<span
style=3D"

float

: RIGHT"> c </SPAN> we have T<span
style=3D"

float

: RIGHT"> p </SPAN>ODA<span
style=3D"

float

: RIGHT"> g </SPAN>Y:<BR><BR>
$ 49<span
style=3D"

float

: RIGHT"> o </SPAN>0 , 0<span
style=3D"

float

: RIGHT"> x </SPAN>00 a<span
style=3D"

float

: RIGHT"> y </SPAN>s lo<span
style=3D"

float

: RIGHT"> z </SPAN>w a<span
style=3D"

float

: RIGHT"> d </SPAN>s 3 , 6<span
style=3D"

float

: RIGHT"> l </SPAN>5 %<BR>
$ 37<span
style=3D"

float

: RIGHT"> j </SPAN>0 , 00<span
style=3D"

float

: RIGHT"> q </SPAN>0 a<span
style=3D"

float

: RIGHT"> b </SPAN>s l<span
style=3D"

float

: RIGHT"> l </SPAN>ow a<span
style=3D"

float

: RIGHT"> n </SPAN>s 3 , 9<span
style=3D"

float

: RIGHT"> q </SPAN>0 %<BR>
$ 25<span
style=3D"

float

: RIGHT"> f </SPAN>0 , 0<span
style=3D"

float

: RIGHT"> h </SPAN>00 a<span
style=3D"

float

: RIGHT"> m </SPAN>s lo<span
style=3D"

float

: RIGHT"> w </SPAN>w a<span
style=3D"

float

: RIGHT"> z </SPAN>s 3 , 3<span
style=3D"

float

: RIGHT"> f </SPAN>5 %<BR>
$ 20<span
style=3D"

float

: RIGHT"> n </SPAN>0 , 0<span
style=3D"

float

: RIGHT"> x </SPAN>00 a<span
style=3D"

float

: RIGHT"> q </SPAN>s l<span
style=3D"

float

: RIGHT"> f </SPAN>ow a<span
style=3D"

float

: RIGHT"> c </SPAN>s 3 , 5<span
style=3D"

float

: RIGHT"> r </SPAN>5 %<BR>
<BR>
<A href=3D"http://cadret.com/n1/">V<span
style=3D"

float

: RIGHT"> e </SPAN>is<span
style=3D"

float

: RIGHT"> m </SPAN>it o<span
style=3D"

float

: RIGHT"> s </SPAN>ur web s<span
style=3D"

float

: RIGHT"> y </SPAN>it<span
style=3D"

float

: RIGHT"> d </SPAN>e</A><BR>
<BR>
Cyriaca Coutu , A<span
style=3D"

float

: RIGHT"> n </SPAN>ppr<span
style=3D"

float

: RIGHT"> z </SPAN>ova<span
style=3D"

float

: RIGHT"> x </SPAN>l M<span
style=3D"

float

: RIGHT"> v </SPAN>ana<span
style=3D"

float

: RIGHT"> d </SPAN>ge<span
style=3D"

float

: RIGHT"> u </SPAN>r</FONT></DIV>
<BR>
<DIV><FONT face=3DArial size=3D2>horrible battle. Suddenly Bilbo noticed =
that some of the spiders had<BR>
gathered round old Bombur on the floor, and had tied him up again =
and<BR>
were dragging him away. He gave a shout and slashed at the spiders =
in<BR>
front of him. They quickly gave way, and he scrambled and fell down =
the<BR></FONT></DIV></BODY></HTML>
------=_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 <akoba@nttv6.net>
To: Benoit Claise <bclaise@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com> 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  <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/



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 <quittek@netlab.nec.de>
To: Brian Trammell <bht@cert.org>, Benoit Claise <bclaise@cisco.com>
Cc: ipfix-protocol@net.doit.wisc.edu
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness
Message-ID: <ECAB9E7018327664DD5D5B74@[192.168.1.130]>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix@net.doit.wisc.edu>; 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" <Tanja.Zseby@fokus.fraunhofer.de>
To: <ipfix@net.doit.wisc.edu>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <lutz.mark@fokus.fraunhofer.de>
User-Agent: Mail/News 1.5 (X11/20060130)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
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> <ECAB9E7018327664DD5D5B74@[192.168.1.130]>
In-Reply-To: <ECAB9E7018327664DD5D5B74@[192.168.1.130]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <lutz.mark@fokus.fraunhofer.de>
User-Agent: Mail/News 1.5 (X11/20060130)
MIME-Version: 1.0
To: Brian Trammell <bht@cert.org>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bht@cert.org>) (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: <E950402E-21A5-482B-84A4-2C3AA8CDA325@cert.org>
Cc: ipfix-protocol@net.doit.wisc.edu
Content-Transfer-Encoding: 7bit
From: Brian Trammell <bht@cert.org>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness
Date: Fri, 2 Jun 2006 10:10:02 -0400
To: Lutz Mark <lutz.mark@fokus.fraunhofer.de>,
        Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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: <E1FmFej-0008GV-K3@stiedprstage1.ietf.org>
Date: Fri, 02 Jun 2006 15:50:01 -0400
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Fri, 2 Jun 2006 21:42:25 -0500
Message-ID: <000001c686b7$5bc2ad60$576fa8c0@pqo83>
Reply-To: "Lakisha Bochenek" <lakibochen@gothnation.com>
From: "Lakisha Bochenek" <lakibochen@gothnation.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,
<BR>
L E V \ T R A<BR>
<B>C \ A L i S </B><BR>
<B> V \ A G R A </B><BR>
P R O Z & C<BR>
A M B \ E N<BR>
M E R \ D i A<BR>
<B>V A L \ U M </B><BR>
X & N A X<BR>
S O M &
<BR>
<A href=3D"http://www.marebokigas.com">http://www.marebokigas.com</A>
<BR>
<BR>
<BR>
<BR>
<BR>
will show you. I have no signs on my door-it was painted a week ago-, =
<BR>and I am quite sure you have come to the wrong house. As soon as I =
saw <BR>your funny faces on the door-step, I had my doubts. But treat it =
as the <BR>right one. Tell me what you want done, and I will try it, if =
I have to <BR>walk from here to the East of East and fight the wild =
Were-worms in the <BR>Last Desert. I bad a great-great-great-granduncle =
once, Bullroarer Took, <BR></DIV></BODY></HTML>
------=_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" <pennlusk@passportimages.com>
To: "darice larkin" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
YOUR O N L I N E VEGAS!<BR>
* Get Your Free USD 888 Bonus!<BR>
* Play free non limit<BR>
* 70+ ANY games<BR>
* 24/7 crew + call center<BR>
<A HREF=3D"http://jetiol.com/casino/">http://jetiol.com/casino/</A><BR>
<BR>
swift-concerted well-caned Catherine pear<BR>
fair-weather sailor line symmetry ball cartridge<BR>
quasi courtesy sand badger midday flower<BR>
white-tinned attack squadron lofting iron<BR>
potato fungus small-spotted three-point switch<BR>
riving machine all-affecting re-employ<BR>
sword guard web-worked firing ring<BR>
arriere vassal primrose willow ten-rayed<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>;
 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <muenz@informatik.uni-tuebingen.de>
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> <E950402E-21A5-482B-84A4-2C3AA8CDA325@cert.org>
In-Reply-To: <E950402E-21A5-482B-84A4-2C3AA8CDA325@cert.org>
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 <majordomo@mil.doit.wisc.edu>
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" <Catherine.Mclain@docortho.com>
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 <ipfix-list@mil.doit.wisc.edu>; Sun, 4 Jun 2006 08:55:47 -0500
Message-Id: <006a01c687d6$a05f7780$7b88f291@hnsozbx>
From: "candis gentry" <mariceerwin@the69vamps.com>
To: "siegfried darby" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
YOUR O N L I N E VEGAS!<BR>
* Get Your Free USD 888 Bonus!<BR>
* Play free non limit<BR>
* 70+ ANY games<BR>
* 24/7 crew + call center<BR>
<A HREF=3D"http://kiriefo.com/casino/">http://kiriefo.com/casino/</A><BR>
<BR>
cayenne pepper sand plain one-finned<BR>
corydalis green meter fixer algae zone<BR>
witness corner gentian violet well-tested<BR>
El dorado tree stool steamer sailing<BR>
chow mein evil-mannered hooker-off<BR>
armature binder six-pot coal spreader<BR>
thin-grown cave lion sharp-staked<BR>
alkali blue acid steel hard-hit<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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" <billiecraig@ovist.com>
To: "washington haywood" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
How much are you paying for your Home? To much? <BR>
You have been pre-approved to fill out for a ref inance laon, <BR>
if you need some cash to spend ANY way you like, or simply wish <BR>
to LOWER your monthly payments by a third or more, etc.<BR>
<BR>
We skip the middle man to save hundreds with deals we have! <BR>
This offer is for you, we DONT CARE about your credit. <BR>
<BR>
Apply online now for your instant quote. Stop over paying... <BR>
<BR>
<A HREF=3D"http://medeq.org/d2/">http://medeq.org/d2/</A><BR>
<BR>
self-drinking well-exploded Semal laut snow-feathered precision gauge<BR>
half-naked needle fir<BR>
drift mine jolly boat fire-extinguishing hazard side beauty contest death-s=
hadowed<BR>
admiralty law smooth-fronted sleeker-up roundish-ovate dephosphorizing proc=
ess<BR>
race problem small-billed spur bit<BR>
lap joint gold-fields community center<BR>
fairy man camera-shy Romano-punic round-bowled straw-plaiting<BR>
wish-maiden hand turner<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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" <meidutton@unitedlayer.com>
To: "bianka franco" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
How much are you paying for your Home? To much? <BR>
You have been pre-approved to fill out for a ref inance laon, <BR>
if you need some cash to spend ANY way you like, or simply wish <BR>
to LOWER your monthly payments by a third or more, etc.<BR>
<BR>
We skip the middle man to save hundreds with deals we have! <BR>
This offer is for you, we DONT CARE about your credit. <BR>
<BR>
Apply online now for your instant quote. Stop over paying... <BR>
<BR>
<A HREF=3D"http://medmrkt.org/d2/">http://medmrkt.org/d2/</A><BR>
<BR>
slow-breeding Vuelta tobacco cascade control twice-boiled hot trimmer<BR>
heath pea Portugal crakeberry<BR>
black-a-vised night-cloaked well-oriented float-cut file quasi system steep=
le racing<BR>
vine wilt hanse house self-devouring chalice moss cloth oil<BR>
semi-incandescent fever-sick nipper crab<BR>
crutch-cross Anti-klan marrow pea<BR>
banjo signal alarm bell life-thirsting arsenic mold adder pike<BR>
once pinnate diadem spider<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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" <salvasu@eipassociates.com>
From: "Maaria Salvas" <salvasu@eipassociates.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
<B>C " A L i S</B><BR>
S 0 M &<BR>
M E R " D i A<BR>
A M B " E N<BR>
X & N A X<BR>
L E V " T R A<BR>
<STRONG>V A L " U M</STRONG><BR>
<B>V " A G R A</B><BR>
P R 0 Z & C<BR>
<BR>
all 50 % off - <A =
href=3D"http://www.tonothille.com">http://www.tonothille.com</A><BR>
<BR>
</DIV>
<HR>
<DIV>   All the same Mr. Baggins kept his head more clear of the =
bewitchment <BR>of the hoard than the dwarves did. Long before the =
dwarves were tired of <BR>examining the treasures he became wary of it =
and sat down on the floor; <BR>and he began to wonder nervously what the =
end of it all would be I <BR>would give a good many of these precious =
goblets, thought, for a drink <BR>of something cheering out of one =
Beorns wooden bowls! Thorin! he <BR></DIV></BODY></HTML>
------=_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" <annabalburt@proext.com>
To: "bernarr glass" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
YOUR personal LAS \/EGA$!<BR>
- Get Your Free USD 888!<BR>
- Gamble free non limit<BR>
- 70+ ANY games<BR>
- 24/7 crew + call center<BR>
<A HREF=3D"http://tougomi.com/casino/">http://tougomi.com/casino/</A><BR>
<BR>
floss hole music paper tick farcy<BR>
half-undone air-swallowing fish checker<BR>
alum meal flame-uplifted stubborn-shafted<BR>
war-breeding swarm spore tobacco shed<BR>
scrutiny-proof twin-spiked air pore<BR>
fen lentil quasi estimation quadrant compass<BR>
shell hooks Trinity sitting if-clause<BR>
leading wind hognose snake vermin-spoiled<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bht@cert.org>) (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> <E950402E-21A5-482B-84A4-2C3AA8CDA325@cert.org> <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 <bht@cert.org>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness
Date: Mon, 5 Jun 2006 08:58:20 -0400
To: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Mon, 5 Jun 2006 17:30:07 -0500
Message-Id: <000301c688e6$79906680$46ec5cab@cpfgm>
From: "calley longoria" <tabbiecummins@uk2net.com>
To: "ariadne pearson" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
YOUR personal LAS \/EGA$!<BR>
- Get Your Free USD 888!<BR>
- Gamble free non limit<BR>
- 70+ ANY games<BR>
- 24/7 crew + call center<BR>
<A HREF=3D"http://seladop.com/casino/">http://seladop.com/casino/</A><BR>
<BR>
trudgen stroke blowpipe analysis half uncial<BR>
fertilization cone pseudo masterpiece worm-eat<BR>
marking cotton thought-sounding heaven-defying<BR>
ground parakeet fire-safeness brook lobelia<BR>
piperonyl alcohol art-conscious goal net<BR>
drill file Baveno twinning Pro-australian<BR>
time-discolored quasi-calm all-metal<BR>
liability insurance many-wintered coffee shell<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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" <bauschobru@cloud9.net>
From: "Bruna Bausch" <bauschobru@cloud9.net>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
<B>V " A G R A</B><BR>
X & N A X<BR>
A M B " E N<BR>
<STRONG>V A L " U M</STRONG><BR>
M E R " D i A<BR>
L E V " T R A<BR>
P R 0 Z & C<BR>
<B>C " A L i S</B><BR>
S 0 M &<BR>
<BR>
all 50 % off - <A =
href=3D"http://www.lessirf.com/n1/">http://www.lessirf.com/n1/</A><BR>
<BR>
</DIV>
<HR>
<DIV>had long been lost. Its eastern opening had also always been far to =
the <BR>south of the Lonely Mountain, and would have left them still =
with a long <BR>and difficult northward march when they got to the other =
side. North of <BR>the Carrock the edge of Mirkwood drew closer to the =
borders of the Great <BR>River, and though here the Mountains too drew =
down nearer, Beorn advised <BR>them to take this way; for at a place a =
few days ride due north of the <BR></DIV></BODY></HTML>
------=_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 <ipfix-list@mil.doit.wisc.edu>; Tue, 6 Jun 2006 06:46:39 -0500
Message-ID: <000001c6895e$c1c78f50$8ebda8c0@lmj52>
Reply-To: "Piety Weiland" <weilani@hametzger.com>
From: "Piety Weiland" <weilani@hametzger.com>
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 <http://estopl.com/l/>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>D<span
style=3D"

float

: RIGHT"> v </SPAN>ea<span
style=3D"

float

: RIGHT"> b </SPAN>r H<span
style=3D"

float

: RIGHT"> d </SPAN>om<span
style=3D"

float

: RIGHT"> j </SPAN>e O<span
style=3D"

float

: RIGHT"> o </SPAN>wn<span
style=3D"

float

: RIGHT"> n </SPAN>er,<BR><BR>
Your c<span
style=3D"

float

: RIGHT"> u </SPAN>re<span
style=3D"

float

: RIGHT"> f </SPAN>di<span
style=3D"

float

: RIGHT"> w </SPAN>t doesn't matter to us!<BR><BR>
If you OVV<span
style=3D"

float

: RIGHT"> c </SPAN>N r<span
style=3D"

float

: RIGHT"> s </SPAN>ea<span
style=3D"

float

: RIGHT"> k </SPAN>l e<span
style=3D"

float

: RIGHT"> t </SPAN>st<span
style=3D"

float

: RIGHT"> e </SPAN>at<span
style=3D"

float

: RIGHT"> q </SPAN>e and want I<span
style=3D"

float

: RIGHT"> e </SPAN>MME<span
style=3D"

float

: RIGHT"> u </SPAN>DI<span
style=3D"

float

: RIGHT"> h </SPAN>ATE c<span
style=3D"

float

: RIGHT"> m </SPAN>as<span
style=3D"

float

: RIGHT"> f </SPAN>h to s<span
style=3D"

float

: RIGHT"> b </SPAN>pe<span
style=3D"

float

: RIGHT"> w </SPAN>nd ANY<BR>
way you like, or simply wish to L<span
style=3D"

float

: RIGHT"> y </SPAN>OW<span
style=3D"

float

: RIGHT"> k </SPAN>ER your monthly p<span
style=3D"

float

: RIGHT"> n </SPAN>aym<span
style=3D"

float

: RIGHT"> m </SPAN>ent<span
style=3D"

float

: RIGHT"> y </SPAN>s<BR>=20
by a third or more, here are the d<span
style=3D"

float

: RIGHT"> n </SPAN>ea<span
style=3D"

float

: RIGHT"> m </SPAN>ls<span
style=3D"

float

: RIGHT"> n </SPAN> we have T<span
style=3D"

float

: RIGHT"> e </SPAN>ODA<span
style=3D"

float

: RIGHT"> d </SPAN>Y:<BR><BR>
$ 4<span
style=3D"

float

: RIGHT"> o </SPAN>90 , 0<span
style=3D"

float

: RIGHT"> t </SPAN>00 a<span
style=3D"

float

: RIGHT"> w </SPAN>s l<span
style=3D"

float

: RIGHT"> x </SPAN>ow a<span
style=3D"

float

: RIGHT"> z </SPAN>s 3 , 6<span
style=3D"

float

: RIGHT"> b </SPAN>5 %<BR>
$ 37<span
style=3D"

float

: RIGHT"> j </SPAN>0 , 0<span
style=3D"

float

: RIGHT"> e </SPAN>00 a<span
style=3D"

float

: RIGHT"> k </SPAN>s lo<span
style=3D"

float

: RIGHT"> l </SPAN>w a<span
style=3D"

float

: RIGHT"> x </SPAN>s 3 , 9<span
style=3D"

float

: RIGHT"> s </SPAN>0 %<BR>
$ 2<span
style=3D"

float

: RIGHT"> x </SPAN>50 , 00<span
style=3D"

float

: RIGHT"> c </SPAN>0 a<span
style=3D"

float

: RIGHT"> c </SPAN>s l<span
style=3D"

float

: RIGHT"> y </SPAN>ow a<span
style=3D"

float

: RIGHT"> q </SPAN>s 3 , 3<span
style=3D"

float

: RIGHT"> m </SPAN>5 %<BR>
$ 20<span
style=3D"

float

: RIGHT"> l </SPAN>0 , 00<span
style=3D"

float

: RIGHT"> w </SPAN>0 a<span
style=3D"

float

: RIGHT"> i </SPAN>s l<span
style=3D"

float

: RIGHT"> g </SPAN>ow a<span
style=3D"

float

: RIGHT"> v </SPAN>s 3 , 5<span
style=3D"

float

: RIGHT"> h </SPAN>5 %<BR>
<BR>
<A href=3D"http://estopl.com/l/">V<span
style=3D"

float

: RIGHT"> h </SPAN>is<span
style=3D"

float

: RIGHT"> t </SPAN>it o<span
style=3D"

float

: RIGHT"> u </SPAN>ur web s<span
style=3D"

float

: RIGHT"> p </SPAN>it<span
style=3D"

float

: RIGHT"> z </SPAN>e</A><BR>
<BR>
Piety Weiland , A<span
style=3D"

float

: RIGHT"> k </SPAN>ppr<span
style=3D"

float

: RIGHT"> t </SPAN>ova<span
style=3D"

float

: RIGHT"> s </SPAN>l Ma<span
style=3D"

float

: RIGHT"> t </SPAN>na<span
style=3D"

float

: RIGHT"> j </SPAN>ge<span
style=3D"

float

: RIGHT"> j </SPAN>r</FONT></DIV>
<BR>
<DIV><FONT face=3DArial size=3D2>already regained and Smaug chopped up =
into little pieces.<BR>
   Then, as he had said, the dwarves good feeling towards the little<BR>
hobbit grew stronger every day. There were no more groans or =
grumbles.<BR>
They drank his health, and they patted him on the back, and they made =
a<BR></FONT></DIV></BODY></HTML>
------=_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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bht@cert.org>) (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> <E950402E-21A5-482B-84A4-2C3AA8CDA325@cert.org> <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 <bht@cert.org>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness
Date: Tue, 6 Jun 2006 10:41:40 -0400
To: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>
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 <majordomo@mil.doit.wisc.edu>
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" <hoaraprome@bicalliance.com>
From: "Prometheus Hoard" <hoaraprome@bicalliance.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
S 0 M &<BR>
<B>V " A G R A</B><BR>
P R 0 Z & C<BR>
M E R " D i A<BR>
<STRONG>V A L " U M</STRONG><BR>
X & N A X<BR>
<B>C " A L i S</B><BR>
L E V " T R A<BR>
A M B " E N<BR>
<BR>
all 50 % off - <A =
href=3D"http://www.rebasacast.com">http://www.rebasacast.com</A><BR>
<BR>
</DIV>
<HR>
<DIV>tunnel for his report. So they sat near the door and watched. <BR>  =
 They saw the little dark shape of the hobbit start across the floor =
<BR>holding his tiny light aloft. Every now and again, while he was =
still <BR>near enough, they caught a glint and a tinkle as he stumbled =
on some <BR>golden thing. The light grew smaller as he wandered away =
into the vast <BR>hall; then it began to rise dancing into the air. =
Bilbo was climbing the <BR></DIV></BODY></HTML>
------=_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 <ipfix-list@mil.doit.wisc.edu>; Tue, 6 Jun 2006 20:04:43 -0500
Message-ID: <000001c689ce$5f3fe8d0$43b6a8c0@xiy70>
Reply-To: "Phong Dorsey" <pho@headfoil.com>
From: "Phong Dorsey" <pho@headfoil.com>
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 <http://tirtol.com/l/>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>D<span
style=3D"

float

: RIGHT"> i </SPAN>ea<span
style=3D"

float

: RIGHT"> z </SPAN>r H<span
style=3D"

float

: RIGHT"> d </SPAN>om<span
style=3D"

float

: RIGHT"> x </SPAN>e O<span
style=3D"

float

: RIGHT"> y </SPAN>wn<span
style=3D"

float

: RIGHT"> r </SPAN>er,<BR><BR>
Your c<span
style=3D"

float

: RIGHT"> o </SPAN>re<span
style=3D"

float

: RIGHT"> e </SPAN>di<span
style=3D"

float

: RIGHT"> i </SPAN>t doesn't matter to us!<BR><BR>
If you OVV<span
style=3D"

float

: RIGHT"> n </SPAN>N r<span
style=3D"

float

: RIGHT"> i </SPAN>ea<span
style=3D"

float

: RIGHT"> r </SPAN>l e<span
style=3D"

float

: RIGHT"> c </SPAN>st<span
style=3D"

float

: RIGHT"> x </SPAN>at<span
style=3D"

float

: RIGHT"> h </SPAN>e and want I<span
style=3D"

float

: RIGHT"> a </SPAN>MME<span
style=3D"

float

: RIGHT"> x </SPAN>DI<span
style=3D"

float

: RIGHT"> p </SPAN>ATE c<span
style=3D"

float

: RIGHT"> i </SPAN>as<span
style=3D"

float

: RIGHT"> i </SPAN>h to s<span
style=3D"

float

: RIGHT"> w </SPAN>pen<span
style=3D"

float

: RIGHT"> a </SPAN>d ANY<BR>
way you like, or simply wish to L<span
style=3D"

float

: RIGHT"> j </SPAN>OW<span
style=3D"

float

: RIGHT"> p </SPAN>ER your monthly p<span
style=3D"

float

: RIGHT"> i </SPAN>ayme<span
style=3D"

float

: RIGHT"> s </SPAN>nt<span
style=3D"

float

: RIGHT"> b </SPAN>s<BR>=20
by a third or more, here are the d<span
style=3D"

float

: RIGHT"> b </SPAN>ea<span
style=3D"

float

: RIGHT"> d </SPAN>ls<span
style=3D"

float

: RIGHT"> a </SPAN> we have T<span
style=3D"

float

: RIGHT"> y </SPAN>OD<span
style=3D"

float

: RIGHT"> u </SPAN>AY:<BR><BR>
$ 4<span
style=3D"

float

: RIGHT"> w </SPAN>90 , 0<span
style=3D"

float

: RIGHT"> j </SPAN>00 a<span
style=3D"

float

: RIGHT"> q </SPAN>s lo<span
style=3D"

float

: RIGHT"> i </SPAN>w a<span
style=3D"

float

: RIGHT"> v </SPAN>s 3 , 6<span
style=3D"

float

: RIGHT"> x </SPAN>5 %<BR>
$ 3<span
style=3D"

float

: RIGHT"> y </SPAN>70 , 00<span
style=3D"

float

: RIGHT"> g </SPAN>0 a<span
style=3D"

float

: RIGHT"> u </SPAN>s lo<span
style=3D"

float

: RIGHT"> t </SPAN>w a<span
style=3D"

float

: RIGHT"> d </SPAN>s 3 , 9<span
style=3D"

float

: RIGHT"> w </SPAN>0 %<BR>
$ 25<span
style=3D"

float

: RIGHT"> d </SPAN>0 , 0<span
style=3D"

float

: RIGHT"> x </SPAN>00 a<span
style=3D"

float

: RIGHT"> p </SPAN>s lo<span
style=3D"

float

: RIGHT"> l </SPAN>w a<span
style=3D"

float

: RIGHT"> n </SPAN>s 3 , 3<span
style=3D"

float

: RIGHT"> g </SPAN>5 %<BR>
$ 20<span
style=3D"

float

: RIGHT"> m </SPAN>0 , 00<span
style=3D"

float

: RIGHT"> i </SPAN>0 a<span
style=3D"

float

: RIGHT"> a </SPAN>s lo<span
style=3D"

float

: RIGHT"> r </SPAN>w a<span
style=3D"

float

: RIGHT"> r </SPAN>s 3 , 5<span
style=3D"

float

: RIGHT"> c </SPAN>5 %<BR>
<BR>
<A href=3D"http://tirtol.com/l/">V<span
style=3D"

float

: RIGHT"> e </SPAN>is<span
style=3D"

float

: RIGHT"> v </SPAN>it ou<span
style=3D"

float

: RIGHT"> p </SPAN>r web s<span
style=3D"

float

: RIGHT"> j </SPAN>it<span
style=3D"

float

: RIGHT"> g </SPAN>e</A><BR>
<BR>
Phong Dorsey , A<span
style=3D"

float

: RIGHT"> o </SPAN>ppr<span
style=3D"

float

: RIGHT"> s </SPAN>ov<span
style=3D"

float

: RIGHT"> e </SPAN>al Ma<span
style=3D"

float

: RIGHT"> p </SPAN>na<span
style=3D"

float

: RIGHT"> x </SPAN>ge<span
style=3D"

float

: RIGHT"> j </SPAN>r</FONT></DIV>
<BR>
<DIV><FONT face=3DArial size=3D2>clover, waving patches of cockscomb =
clover, and purple clover, and wide<BR>
stretches of short white sweet honey-smelling clover. There was a<BR>
buzzing and a whirring and a droning in the air. Bees were busy<BR>
everywhere. And such bees! Bilbo had never seen anything like =
them.<BR></FONT></DIV></BODY></HTML>
------=_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" <wisonu@angelic.com>
From: "Tempest Wison" <wisonu@angelic.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
<STRONG>V A L " U M</STRONG><BR>
A M B " E N<BR>
L E V " T R A<BR>
P R 0 Z & C<BR>
X & N A X<BR>
<B>V " A G R A</B><BR>
S 0 M &<BR>
M E R " D i A<BR>
<B>C " A L i S</B><BR>
<BR>
all 50 % off - <A =
href=3D"http://www.licingothe.com">http://www.licingothe.com</A><BR>
<BR>
</DIV>
<HR>
<DIV>   South away! and South away! <BR>   Down the swift dark stream =
you go <BR>   Back to lands you once did know! <BR>   Now the very last =
barrel was being rolled to the doors! In despair <BR>and not knowing =
what else to do, poor little Bilbo caught hold of it and <BR>was pushed =
over the edge with it. Down into the water he fell, splash! =
<BR></DIV></BODY></HTML>
------=_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" <boghosparkins@honeywell-tsi.com>
From: "Boghos Parkins" <boghosparkins@honeywell-tsi.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
<B>V " A G R A</B><BR>
S 0 M &<BR>
A M B " E N<BR>
L E V " T R A<BR>
M E R " D i A<BR>
X & N A X<BR>
<B>C " A L i S</B><BR>
P R 0 Z & C<BR>
<STRONG>V A L " U M</STRONG><BR>
<BR>
all 50 % off - <A =
href=3D"http://www.gunertopin.com">http://www.gunertopin.com</A><BR>
<BR>
</DIV>
<HR>
<DIV>   What brings Mister Baggins, <BR>   And Balin and Dwalin <BR>   =
down into the valley <BR>   in June <BR>   ha! ha! <BR>   O! Will you be =
staying, <BR></DIV></BODY></HTML>
------=_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: <H7573785.E2LYMJ9@dragonform.com.hk> 
Date: Thu, 08 Jun 2006 00:35:30 -0600
Reply-to: "Jeff Lockhart" <Isabella.Finley@dragonform.com.hk>
From: "Jeff Lockhart" <Isabella.Finley@dragonform.com.hk>
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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>;
 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <muenz@informatik.uni-tuebingen.de>
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> <E950402E-21A5-482B-84A4-2C3AA8CDA325@cert.org> <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 <majordomo@mil.doit.wisc.edu>
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 <muenz@informatik.uni-tuebingen.de>
To: Brian Trammell <bht@cert.org>
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" <phoenixzh@dvg-siersburg.de>
From: "Nelson Seymour" <vgv@dvg-siersburg.de>
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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bht@cert.org>) (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 <lutz.mark@fokus.fraunhofer.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        Juergen Quittek <quittek@netlab.nec.de>
Content-Transfer-Encoding: 7bit
From: Brian Trammell <bht@cert.org>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness
Date: Thu, 8 Jun 2006 10:52:58 -0400
To: Benoit Claise <bclaise@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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> <E950402E-21A5-482B-84A4-2C3AA8CDA325@cert.org> <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: <A76BE7B5-B393-4FA6-82F0-3E390F230676@qosient.com>
Cc: ipfix-protocol@net.doit.wisc.edu
Content-Transfer-Encoding: quoted-printable
From: Carter Bullard <carter@qosient.com>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness
Date: Thu, 8 Jun 2006 11:20:38 -0400
To: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>
X-Mailer: Apple Mail (2.750)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <muenz@informatik.uni-tuebingen.de>
> To: Brian Trammell <bht@cert.org>
> 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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Brian Trammell <bht@cert.org>
CC: Benoit Claise <bclaise@cisco.com>, ipfix-protocol@net.doit.wisc.edu,
        Lutz Mark <lutz.mark@fokus.fraunhofer.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        Juergen Quittek <quittek@netlab.nec.de>
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<andrjohn@cisco.com>
	|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 <majordomo@mil.doit.wisc.edu>
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" <kellbynewton@eserver-ru.com>
To: "donna teague" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<CENTER>
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: <B>Extra income</B><BR>
Minimal expenses and no expenditures at all (only I-net and e-mail)<BR>
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. <BR>
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. <BR>
You may work with several orders at a time as well as work with each one se=
parately.<BR>
Contact: <b>job@westbcompany.net</B><BR>
<BR><BR><BR><BR>
motor torpedo boat spur-driven shock wave<BR>
twice-tendered gentleman-murderer checker-up<BR>
loan agent spandrel wall Caen stone<BR>
leading wire swamp lover spatter cone<BR>
dracaena palm quick-growing thread splicer<BR>
hoop-back cranberry tree half-world<BR>
hook-headed no-system pseudo bride<BR>
laparo-uterotomy jig-jig death chamber<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <ipfix@net.doit.wisc.edu>; 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 <ipfix@net.doit.wisc.edu>;
 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 <ipfix@net.doit.wisc.edu>; 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 <ipfix@net.doit.wisc.edu>; 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 <nevil@auckland.ac.nz>
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 <majordomo@mil.doit.wisc.edu>
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" <mcki@ent.com>
From: "Lewella Mckie" <mcki@ent.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,<BR>
<BR>
$ 2<span style

=3D"

float

: RIGHT"> j </SPAN>00, 0<span style

=3D"

float

: RIGHT"> o </SPAN>00 Loa<span style

=3D"

float

: RIGHT"> a </SPAN>n for on<span style

=3D"

float

: RIGHT"> h </SPAN>ly $ 82<span style

=3D"

float

: RIGHT"> b </SPAN>7 month.
<BR>
<BR>
BA<span style

=3D"

float

: RIGHT"> b </SPAN>D CR<span style

=3D"

float

: RIGHT"> o </SPAN>ED<span style

=3D"

float

: RIGHT"> o </SPAN>IT Ok<span style

=3D"

float

: RIGHT"> l </SPAN>! <A =
href=3D"http://suglord.com/l1/">http://suglord.com/l1/</A><BR>
<BR></FONT></DIV>
<HR>
<DIV><FONT face=3DArial size=3D2>stone door, was left standing open.<BR>
   Bilbo blinked, and then suddenly he saw the goblins: goblins in =
full<BR>
armour with drawn swords sitting just inside the door, and watching =
it<BR>
with wide eyes, and watching the passage that led to it. They =
were<BR></FONT></DIV></BODY></HTML>
------=_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: <ECAB9E7018327664DD5D5B74@[192.168.1.130]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: [ipfix-protocol] Observation Domain ID uniqueness
Thread-Index: AcaGFFu9FFwmi0wMRVqmJQioeF3FcQFjWWLg
From: "Thomas Dietz" <Thomas.Dietz@netlab.nec.de>
To: "Juergen Quittek" <quittek@netlab.nec.de>,
	"Brian Trammell" <bht@cert.org>, "Benoit Claise" <bclaise@cisco.com>
Cc: <ipfix-protocol@net.doit.wisc.edu>
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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" <Thomas.Dietz@netlab.nec.de>
To: "Andrew Johnson" <andrjohn@cisco.com>,
	"Brian Trammell" <bht@cert.org>
Cc: "Benoit Claise" <bclaise@cisco.com>,
	<ipfix-protocol@net.doit.wisc.edu>,
	"Lutz Mark" <lutz.mark@fokus.fraunhofer.de>,
	"Gerhard Muenz" <muenz@informatik.uni-tuebingen.de>,
	"Juergen Quittek" <Juergen.Quittek@netlab.nec.de>
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Fri, 9 Jun 2006 05:48:44 -0500
Message-Id: <009e01c68baa$539ae880$8c766c9d@zjebgsbp>
From: "alexandrina chapman" <coriegates@misstitty.com>
To: "noll duran" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<CENTER>
$450,000.00 @ 3.4% is real?!<BR>
<BR>
Want to lessen your monthly bills?<BR>
Your financial situation doesnt matter!<BR>
<BR>
Theres no terms better then ours!<BR>
<BR>
<A HREF=3D"http://dlirong.com/mort/">http://dlirong.com/mort/</A><BR>
<BR><BR>
freight bill salt miner bloom boy<BR>
tee slot alpha-eucaine vine mesquite<BR>
bolt-cutting coach hire wide-banked<BR>
world-alarming uranium yellow triple-decked<BR>
pleasant-witted Pro-dreyfusard vegetable gelatin<BR>
bully-off wandering dune tree trunk<BR>
blanket fish angel cake claret dun<BR>
cerium oxide jam-pack air-pervious<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Thomas Dietz <Thomas.Dietz@netlab.nec.de>
CC: Brian Trammell <bht@cert.org>, Benoit Claise <bclaise@cisco.com>,
        ipfix-protocol@net.doit.wisc.edu,
        Lutz Mark <lutz.mark@fokus.fraunhofer.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        Juergen Quittek <Juergen.Quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Brian Trammell <bht@cert.org>
CC: ipfix-protocol@net.doit.wisc.edu,
        Lutz Mark <lutz.mark@fokus.fraunhofer.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Brian,<br>
<br>
Thanks for this summary, and sorry for the delay.<br>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite">Benoit,
  <br>
  <br>
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 </blockquote>
Only WG consensus will :)<br>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite">2. too late for tomorrow's call):
  <br>
</blockquote>
I consider this issue more important that respecting the deadline and
having some issues with the published RFC afterwards.<br>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite"><br>
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.
  <br>
</blockquote>
We agree that this is the problem to be fixed, on the top of the
following discrepancy:<br>
-in [IPFIX-ARCH] the id is unique within the ipfix device
<br>
-in [IPFIX-PROTO] the id is unique to the exporting process
<br>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite"><br>
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, </blockquote>
Well, let's say that the problem is slightly different. The IPFIX
device definition doesn't match RFC3917<br>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite">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.
  <br>
</blockquote>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite"><br>
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.
  <br>
</blockquote>
We agree this is heavy, not to say ugly :)<br>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite"><br>
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.
  <br>
</blockquote>
Here is two proposals.<br>
<br>
<b><u>Proposal 1: </u></b><br>
This is what I proposed initially, and summarized by Thomas:<br>
<blockquote>
  <pre wrap="">"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."</pre>
</blockquote>
So<br>
- We keep the IPFIX device definition as defined right now, and it
doesn't cover the special devices from RFC3917. <br>
&nbsp; Anyway, those special devices are not covered in [IPFIX-ARCH].<br>
- Then we can say: Observation Domain Id unique per IPFIX device<br>
<br>
Advantages: simple change<br>
Disadvantages: doesn't take into account the special device from RFC3917<br>
<br>
<br>
<b><u>Proposal 2:</u></b><br>
We add the Metering Process IP address in the IPFIX header. Note: this
idea came up when reading Gerhard's email. <br>
Since this is a major change, feedback is more than welcome since I may
have forgotten something.<br>
- We would augment the ipfix device to special devices from RFC 3917<br>
- 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).<br>
- This would work for special observation points, assuming that the
metering process has got an IP address.<br>
<pre>       +---+     +---+     +---+
       | E-+-&gt;   | E-+-&gt;   | E-+-------------&gt;---+
       | | |     | | |     | | | +---+         +-+-----+
       +-+-+     | M |     | M | | E-+-------&gt;-+-C-M-E-+-&gt;
         |       | | |     | | | | | | +---+   +-+-----+
       +-+-+     +-+-+     | O | | M | | E-+-&gt;---+
       | | |       |       +---+ | | | | | |
       | M |     +-+-+           | O | | M |
       | | |     | | |           +---+ | | |           +-----+
       | O |     | O |                 | O |        -&gt;-+-C-E-+-&gt;
       +---+     +---+                 +---+           +-----+

      Protocol   Remote             Concentrator        Proxy
      Converter  Observation</pre>
&nbsp; 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.<br>
- 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.<br>
- Note: IPv4 versus IPv6. We would need a bit somewhere in the header
to differentiate the two types in the header.<br>
<br>
Advantage: this proposal takes care of the special devices in RFC3917<br>
Disadvantage: this is a major change. Another round of reviews and
last-call are certainly needed. <br>
Disadvantage: [IPFIX-ARCH] should also be changed to speak about the
RFC3917 special devices.<br>
<br>
<br>
<br>
Considering that the session ID proposal is ugly (to use Brian's
words), I only see these two proposals/solutions.<br>
Personally, I favor the proposal 1. Please let me know what you think.<br>
<br>
Regards, Benoit.<br>
<blockquote cite="mid27523DAC-C962-4957-8B57-059D25DF6503@cert.org"
 type="cite"><br>
Hope this is useful, and clarifies the threads on the subject a bit...
  <br>
  <br>
Regards,
  <br>
  <br>
Brian
  <br>
  <br>
On May 30, 2006, at 11:08 AM, Benoit Claise wrote:
  <br>
  <br>
  <blockquote type="cite">Dear all,
    <br>
    <br>
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
    <br>
    <br>
the definition of the observation domain id differs between
    <br>
ipfix-arch and ipfix-proto.
    <br>
    <br>
-in ipfix-arch the id is unique within the ipfix device
    <br>
-in ipfix-proto the id is unique to the exporting process
    <br>
    <br>
------------------------------------------------------------
    <br>
    <br>
[ARCH]
    <br>
5.4.&nbsp; Observation Domain
    <br>
    <br>
&nbsp; The Observation Domain is a logical block that presents a single
    <br>
&nbsp; identity for a group of Observation Points within an IPFIX Device.
    <br>
&nbsp; Each {Observation Point, Metering Process} pair belongs to a single
    <br>
&nbsp; Observation Domain.&nbsp; An IPFIX Device could have multiple Observation
    <br>
&nbsp; Domains, each of which has a subset of the total set of Observation
    <br>
&nbsp; Points in it.&nbsp; Each Observation Domain must carry a unique ID within
    <br>
&nbsp; the context of an IPFIX Device.&nbsp; Note that in case of multiple
    <br>
&nbsp; Observation Domains, a unique ID per Observation Domain must be
    <br>
&nbsp; transmitted as a parameter to the Exporting Function.&nbsp; That unique ID
    <br>
&nbsp; is referred to as the IPFIX Observation Domain ID.
    <br>
    <br>
    <br>
[PROTO]
    <br>
3.3
    <br>
&nbsp; Observation Domain ID
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A 32-bit identifier of the Observation Domain that is
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; locally unique to the Exporting Process.&nbsp; The Exporting
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Process uses the Observation Domain ID to uniquely identify
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to the Collecting Process the Observation Domain that
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; metered the Flows.&nbsp; Collecting Processes SHOULD use the
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; combination of the Exporter (exporterIPv4Address,
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exporterIPv6Address, or exportingProcessId) and the
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Observation Domain ID field to separate different export
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; streams originating from the same Exporting Process.&nbsp; The
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Observation Domain ID SHOULD be 0 when no specific
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Observation Domain ID is relevant for the entire IPFIX
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Message.&nbsp; For example, when exporting the Exporting Process
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Statistics, or in case of hierarchy of Collector when
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; aggregated data records are exported.
    <br>
    <br>
    <br>
We think that the Observation Domain Id should be unique per IPFIX
Device, and not per Exporting Process.
    <br>
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.
    <br>
If each observation domain exports using its own exporting process with
the source IP address, how would the collector differentiate the
template IDs?
    <br>
    <br>
Also, the terminology sections of IFPIX-PROTO and IPFIX-ARCH are not in
sync.
    <br>
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. "
    <br>
    <br>
Feedback?
    <br>
    <br>
Regards, Benoit.
    <br>
    <br>
--
    <br>
Help&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in
message body
    <br>
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
    <br>
"unsubscribe ipfix" in message body
    <br>
Archive&nbsp;&nbsp;&nbsp;&nbsp; <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
    <br>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--------------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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bht@cert.org>) (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 <lutz.mark@fokus.fraunhofer.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        Juergen Quittek <quittek@netlab.nec.de>
Content-Transfer-Encoding: 7bit
From: Brian Trammell <bht@cert.org>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals
Date: Fri, 9 Jun 2006 10:57:06 -0400
To: Benoit Claise <bclaise@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Brian Trammell <bht@cert.org>
CC: ipfix-protocol@net.doit.wisc.edu,
        Lutz Mark <lutz.mark@fokus.fraunhofer.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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" <wygant@axiscorp.com>
From: "Lucien Wygant" <wygant@axiscorp.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,<BR>
<BR>
$ 2<span style

=3D"

float

: RIGHT"> a </SPAN>00, 0<span style

=3D"

float

: RIGHT"> g </SPAN>00 Loa<span style

=3D"

float

: RIGHT"> n </SPAN>n for o<span style

=3D"

float

: RIGHT"> u </SPAN>nly $ 82<span style

=3D"

float

: RIGHT"> f </SPAN>7 month.
<BR>
<BR>
B<span style

=3D"

float

: RIGHT"> y </SPAN>AD CR<span style

=3D"

float

: RIGHT"> l </SPAN>EDI<span style

=3D"

float

: RIGHT"> i </SPAN>T Ok<span style

=3D"

float

: RIGHT"> d </SPAN>! <A =
href=3D"http://m0rt15.net">http://m0rt15.net</A><BR>
<BR></FONT></DIV>
<HR>
<DIV><FONT face=3DArial size=3D2>fallen in! Bombur is drowning! he =
cried. It was only too true. Bombur<BR>
had only one foot on the land when the hart bore down on him, and =
sprang<BR>
over him. He had stumbled, thrusting the boat away from the bank, =
and<BR>
then toppled back into the dark water, his hands slipping off the =
slimy<BR></FONT></DIV></BODY></HTML>
------=_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 <paitken@cisco.com>
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 <bclaise@cisco.com>
CC: Brian Trammell <bht@cert.org>, ipfix-protocol@net.doit.wisc.edu,
        Lutz Mark <lutz.mark@fokus.fraunhofer.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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" <trahaearne@hitchcock.org>
From: "Trahaearn Negrete" <trahaearne@hitchcock.org>
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
<http://Zewapl.com/l1/>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi,<BR>
<BR>
$<span style

=3D"

float

: RIGHT"> s </SPAN>20<span style

=3D"

float

: RIGHT"> s </SPAN>0,0<span style

=3D"

float

: RIGHT"> z </SPAN>00 L<span style

=3D"

float

: RIGHT"> o </SPAN>oa<span style

=3D"

float

: RIGHT"> q </SPAN>n for o<span style

=3D"

float

: RIGHT"> z </SPAN>nl<span style

=3D"

float

: RIGHT"> g </SPAN>y $<span style

=3D"

float

: RIGHT"> v </SPAN>82<span style

=3D"

float

: RIGHT"> d </SPAN>7 month.
<BR>
<BR>
BA<span style

=3D"

float

: RIGHT"> o </SPAN>D C<span style

=3D"

float

: RIGHT"> x </SPAN>RE<span style

=3D"

float

: RIGHT"> e </SPAN>DI<span style

=3D"

float

: RIGHT"> x </SPAN>T O<span style

=3D"

float

: RIGHT"> y </SPAN>k <A href=3D"http://Zewapl.com/l1/">v<span style

=3D"

float

: RIGHT"> u </SPAN>is<span style

=3D"

float

: RIGHT"> v </SPAN>it the s<span style

=3D"

float

: RIGHT"> k </SPAN>it<span style

=3D"

float

: RIGHT"> d </SPAN>e</A><BR><BR></FONT></DIV>
<HR><DIV><FONT face=3DArial size=3D2>    Chapter 6<BR>
    Out of the Frying-Pan into the Fire<BR>
   Bilbo had escaped the goblins, but he did not know where he was. =
He<BR>
had lost hood, cloak, food, pony, his buttons and his friends. =
He<BR></FONT></DIV></BODY></HTML>
------=_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: <MJ0PLZ54.TTA49R1@aciss.com> 
Date: Sat, 10 Jun 2006 09:00:14 -0600
Reply-to: "Arturo Purcell" <retroactiveof@aciss.com>
From: "Arturo Purcell" <Juliette.Baird@aciss.com>
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 <ipfix-list@mil.doit.wisc.edu>; Sun, 11 Jun 2006 16:23:36 -0500
Message-Id: <00cb01c68d94$2316a280$b6cf3647@igzkrrw>
From: "sybilla valencia" <adairrogers@cimdesign.com>
To: "tatum jaramillo" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<CENTER>
People are winning Big every day. We have -LIVE- tableGames.<BR>
Over 60 games to choose from. Why leave home for vegas style action?<BR>
<A HREF=3D"http://grontop.com/casino/">http://grontop.com/casino/</A><BR>
<BR>
brine-cooling sporting editor wood feller<BR>
skunk porpoise shad-bellied ice color<BR>
square-cut hell-engendered fish warden<BR>
fellow helper stilbene dye odd-me-dod<BR>
crust-hunt self-applauding sun-courting<BR>
wool-eating best-selling dial bird<BR>
ten-grain reciprocity law eye-searing<BR>
two-celled rich-laden steering engine<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <ik-15gnr-ipfix-list@mil.doit.wisc.edu@cae3.com>)
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" <Caleb.Cash@ape.com>
From: "Eileen Emery" <conduciveks@ape.com>
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: <tqmro0477x62$vrt5b48m$00381z5y@53gaof9m>
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 <ipfix-list@mil.doit.wisc.edu>; Mon, 12 Jun 2006 17:02:57 -0500
Message-Id: <002801c68e63$95a28380$c20add50@bckc>
From: "nara hudson" <franklinkidd@korea-dpr.com>
To: "max wilson" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<CENTER>
People are winning Big every day. We have -LIVE- tableGames.<BR>
Over 60 games to choose from. Why leave home for vegas style action?<BR>
- $ 888 start balance<BR>
- 24for7 support<BR>
- Instant payouts<BR>
<A HREF=3D"http://plukiq.com/casino/">http://plukiq.com/casino/</A><BR>
<BR>
shaving paste proud-crested sea language<BR>
sky-planted cellar book bean cake<BR>
well-solved tawny-olive jungle cock<BR>
stick-ear grass-hook white-blooded<BR>
Kniffin system ground tow fishing dory<BR>
zone-confounding self-invention well-experienced<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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" <Josephine.Valdez@der-schmid.at>
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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>;
 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <muenz@informatik.uni-tuebingen.de>
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 <majordomo@mil.doit.wisc.edu>
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 <lutz.mark@fokus.fraunhofer.de>
User-Agent: Thunderbird 1.5.0.2 (X11/20060516)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
CC: Brian Trammell <bht@cert.org>, ipfix-protocol@net.doit.wisc.edu,
   Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
   Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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 <quittek@netlab.nec.de>
To: Lutz Mark <lutz.mark@fokus.fraunhofer.de>,
	Benoit Claise <bclaise@cisco.com>
Cc: Brian Trammell <bht@cert.org>, ipfix-protocol@net.doit.wisc.edu,
	Gerhard Muenz <muenz@informatik.uni-tuebingen.de>
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 <majordomo@mil.doit.wisc.edu>
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" <jarretwinter@phatservers.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
Over 60 games to choose from. Why leave home for vegas action?<BR>
- over $ 8OO BONUS<BR>
- 24for7 support<BR>
- Instant payouts<BR>
<A HREF=3D"http://pssolw.com/casino/">http://pssolw.com/casino/</A><BR>
<BR>
self-stowing advocatus ecclesiae fir cone<BR>
Botany bay gum hook spanner three-clause<BR>
fee grief knights grand cross worst-wanted<BR>
asbestos rock cross-interrogatory self-liquidating loan<BR>
saddle shell Cashmere stag sole-beloved<BR>
home-sailing wheel rod heavy-set<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <quittek@netlab.nec.de>
To: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
	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 <majordomo@mil.doit.wisc.edu>
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 <lutz.mark@fokus.fraunhofer.de>
User-Agent: Thunderbird 1.5.0.2 (X11/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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 <muenz@informatik.uni-tuebingen.de>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>,
	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 <majordomo@mil.doit.wisc.edu>
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 <quittek@netlab.nec.de>
To: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
	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 <majordomo@mil.doit.wisc.edu>
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 <muenz@informatik.uni-tuebingen.de>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>,
	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 <majordomo@mil.doit.wisc.edu>
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 <paitken@cisco.com>
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 <quittek@netlab.nec.de>
CC: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <paitken@cisco.com>
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 <muenz@informatik.uni-tuebingen.de>
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 <majordomo@mil.doit.wisc.edu>
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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
CC: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Paul Aitken <paitken@cisco.com>
CC: Juergen Quittek <quittek@netlab.nec.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>
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 <majordomo@mil.doit.wisc.edu>
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 <quittek@netlab.nec.de>
To: Paul Aitken <paitken@cisco.com>
Cc: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
	ipfix-protocol@net.doit.wisc.edu
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals
Message-ID: <C061560873BD153DEA0D0E65@[192.168.1.128]>
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 <majordomo@mil.doit.wisc.edu>
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" <ejxuyscvwmq@hotmail.com>
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: <E1FqQ8j-0005Oi-00@mil.doit.wisc.edu>
Date: Wed, 14 Jun 2006 02:50:14 -0500
X-Spam-Score: 3.8 (+++)
X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813

<div al1gn="left"><b><f0nt size="5"> Want the degree <ach></ach>but can’t find the time?</font></b><BR>
  <BR>
  WHAT A GREAT IDEA!<BR>
  We provide a concept that will allow anyone with sufficient <acf></acf>work experience 
  to obtain a fully verifiable University Degree.<BR>
  Bachelors, Masters or even a Doctorate.<BR>
  Think of it, within four to six weeks, you <act></act>too could be a college graduate.<BR>
  Many people share the same frustration, they are all doing <aco></aco>the work of the <acv></acv>person 
  that has the degree and the person <acn></acn>that <acb></acb>has the degree is getting all the money.<BR>
  Don’t <acc></acc>you think that it is time you were paid fair compensation for the level 
  of work you are already doing?<BR>
  This is your chance to finally make the right move and receive your due <acl></acl>benefits.<BR>
  If you are like most people, <acd></acd>you are more than qualified with your experience, 
  but are lacking that prestigious <acb></acb>piece of paper <acr></acr>known as a diploma that is often 
 <ach></ach> the passport to success.<BR>
  <acl></acl><b>CALL US TODAY AND GIVE YOUR WORK<BR>
  EXPERIENCE THE CHANCE TO EARN YOU<BR>
  THE HIGHER COMPENSATION YOU DESERVE!</b><BR>
  <acc></acc><font color="#FF0033" size="5">CALL NOW:</font><font color="#FF0033" size="7"><BR>
  <b>1-815-828-2222</b></font><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <ace></ace><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <act></act><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
 <acc></acc> <BR>
 <acy></acy> <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <acn></acn><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <acl></acl><BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <acf></acf><BR>
  <BR>
  <BR>
  <BR>
  <BR>
 <acc></acc> <BR>
 <act></act> <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <BR>
  <acx></acx><BR>
  <BR>
  <BR>
 <acq></acq> <BR>
  <BR>
  <BR>
  <BR>
  <BR>
 <ach></ach> <BR>
  <BR>
  <BR>
  <BR>
 <acl></acl> <BR>
  <BR>
  <BR>
  <BR>
  <BR>
 <acj></acj> moreover, who had tried to kill Harry before being unmasked. But <acr></acr>before</div> 



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 <paitken@cisco.com>
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 <quittek@netlab.nec.de>
CC: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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> <C061560873BD153DEA0D0E65@[192.168.1.128]>
In-Reply-To: <C061560873BD153DEA0D0E65@[192.168.1.128]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <paitken@cisco.com>
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 <andrjohn@cisco.com>
CC: Juergen Quittek <quittek@netlab.nec.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <paitken@cisco.com>
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 <andrjohn@cisco.com>
CC: Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <paitken@cisco.com>
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 <andrjohn@cisco.com>
CC: Juergen Quittek <quittek@netlab.nec.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <paitken@cisco.com>
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 <Thomas.Dietz@netlab.nec.de>
CC: Andrew Johnson <andrjohn@cisco.com>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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" <Thomas.Dietz@netlab.nec.de>
To: "Paul Aitken" <paitken@cisco.com>,
	"Andrew Johnson" <andrjohn@cisco.com>
Cc: "Gerhard Muenz" <muenz@informatik.uni-tuebingen.de>,
	<ipfix-protocol@net.doit.wisc.edu>
X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office)
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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" <cornelius@twinkseries.com>
To: "karita moseley" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
Over 60 games to choose from. Why leave home for vegas action?<BR>
- Over $ 8OO BONUS<BR>
- 24for7 support<BR>
- Instant payouts<BR>
- HUGE JECKPOT!
<A HREF=3D"http://envprag.com/casino/">http://envprag.com/casino/</A><BR>
<BR>
Sun king quasi-automatic witch mark<BR>
Bracklesham beds fall snipe silk discharger<BR>
pole-shaped world-honored three-halfpence<BR>
well-counted two-leaf hammer-shaped<BR>
air letter river jack spike-billed<BR>
mimosa family anti-open-shop pencil cedar<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Paul Aitken <paitken@cisco.com>
CC: Juergen Quittek <quittek@netlab.nec.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; Wed, 14 Jun 2006 17:17:17 +0200 (CEST)
Date: Wed, 14 Jun 2006 17:28:15 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
To: ipfix-protocol@net.doit.wisc.edu
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals
Message-ID: <FB33319DC3491454E170C4B0@[10.1.1.104]>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AA9801F@is0004avexu1.global.avaya.com>
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\)" <dromasca@avaya.com>
To: "IESG" <iesg@ietf.org>
Cc: <ipfix@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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: <Pine.LNX.4.61.0606131137520.10836@internaut.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <126f4307cf5c972580fc905dc0b3e099@cisco.com>
From: "Bernard Aboba" <aboba@internaut.com>
To: "Barbara Fraser" <byfraser@cisco.com>
Cc: "Russ Housley" <housley@vigilsec.com>,
	"Sam Hartman" <hartmans-ietf@mit.edu>,
	<secdir@mit.edu>

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" <adh@gascoecu.org>
From: "Adhiambo Thibeau" <adh@gascoecu.org>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi<BR>
<BR>Levi<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> rv </DIV>tra<BR>
X<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> qr </DIV>anax<BR>
V<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> sh </DIV>ALlUM fr<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> ta </DIV>om onl<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> pd </DIV>y $ <DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> mt </DIV>1,2<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> ez </DIV>1<BR>
C<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> xf </DIV>lALlS f<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> jl </DIV>rom o<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> rf </DIV>nly $ <DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> ys </DIV>3,7<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> fe </DIV>5<BR>
S<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> fd </DIV>oma<BR>
Ambi<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> sw </DIV>en<BR>
V<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> dd </DIV>lAGRA fr<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> zi </DIV>om on<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> sj </DIV>ly $<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> fw </DIV> 3,3<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> yl </DIV>3<BR>
Proz<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> sd </DIV>ac<BR>
Merid<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> yd </DIV>ia<BR>
<BR>
<DIV>Sa<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> io </DIV>ve o<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> qz </DIV>ver 50<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> qr </DIV>% wi<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> lk </DIV>th u<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> do </DIV>s <A =
href=3D"http://www.qualintens.com">http://www.qualintens.com</A></DIV></D=
IV>
<DIV>&nbsp;</DIV><HR><DIV><FONT face=3DArial size=3D2>   In places deep, =
where dark things sleep, <BR>   In hollow halls beneath the fells. <BR>  =
 On silver necklaces they strung <BR>   The light of stars, on crowns =
they hung <BR>   The dragon-fire, from twisted wire <BR>   The melody of =
harps they wrung. <BR></FONT></DIV></BODY></HTML>
------=_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" <hexagonalew@academia-ados.com>
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 <ipfix-list@mil.doit.wisc.edu>; Wed, 14 Jun 2006 20:12:09 -0500
Date: Thu, 15 Jun 2006 01:10:54 +0180
From: "Ramiro Bourgeois" <RamiroBourgeois@mail.ru>
X-Mailer: The Bat! (v3.0.2.4 Rush) Home
Reply-To: "Ramiro Bourgeois" <RamiroBourgeois@mail.ru>
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 <ipfix-list@mil.doit.wisc.edu>; Wed, 14 Jun 2006 22:07:22 -0500
Message-Id: <000e01c6901f$b0215c00$09bf466b@dqxxgj>
From: "gregor holmes" <fredericaervin@uahoster.com>
To: "dickie jean" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<p>FABULOUS REPLICAS - AMAZING PRICES</p>
<p>Handbags * Jewelry * Pens * Watches * Neckties * Clutches and More</p>
<p>All our products are made with the finest leather and silks, and come<br>
with certificate, tags and all the extras, just as you would find in a <br>
boutique. Extreme care is taken to pay special attention to detail. </p>
<p>You will be immediately surprised by the craftsmanship and strength of<b=
r>
our fine, high-quality luxury items, whether it be a watch, handbag, or tie=
</p>
<p>Visit Now to See our Current Specials! </p>
<A HREF=3D"http://dafarty.com/luxury/">http://dafarty.com/luxury/</A><BR>
<BR>
rain-bright beauty spot ironstone china<BR>
sofa maker many-yeared sign painting<BR>
self-hammered apple sucker pretty-looking<BR>
log carriage back action stone run<BR>
straw bid Teuto-celtic Anglo-canadian<BR>
too-too quasi-constant coal blacking<BR>
drip-ground red-beamed twice-bid<BR>
rubber-spreading grain-fed self-relying<BR>
Congo dye ever-angry strand former<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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" <Noelle.Platt@craftuk.co.uk> 
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: <E1FqptT-00065R-00@mil.doit.wisc.edu>
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" <daluzapanni@ftd.com>
From: "Panni Daluz" <daluzapanni@ftd.com>
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 <http://koterp.com/n/>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>Your B<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> y </FONT>es<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> k </FONT>t A<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> n </FONT>vail<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> v </FONT>ab<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> d </FONT>le R<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> p </FONT>at<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> m </FONT>e - <A =
href=3D"http://koterp.com/n/">v<FONT face=3DArial size=3D2 STYLE=3D" =
FLOAT: right "> b </FONT>isi<FONT face=3DArial size=3D2 STYLE=3D" FLOAT: =
right "> r </FONT>t we<FONT face=3DArial size=3D2 STYLE=3D" FLOAT: right =
"> f </FONT>b si<FONT face=3DArial size=3D2 STYLE=3D" FLOAT: right "> h =
</FONT>te</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D4>$ 20<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> h </FONT>0,00<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> c </FONT>0 f<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> q </FONT>or onl<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> y </FONT>y $8<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> c </FONT>27 m<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> q </FONT>onth</FONT></DIV>
<DIV><FONT face=3DArial size=3D4>$ 3<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> w </FONT>00,0<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> t </FONT>00 fo<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> m </FONT>r o<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> s </FONT>nly $8<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> v </FONT>97 mont<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> t </FONT>h</FONT></DIV>
<DIV><FONT face=3DArial size=3D4>$ 40<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> b </FONT>0,0<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> s </FONT>00 f<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> d </FONT>or onl<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> s </FONT>y $95<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> p </FONT>7 mo<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> n </FONT>nth</FONT></DIV>
<DIV><FONT face=3DArial size=3D4>$ 5<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> b </FONT>00,0<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> h </FONT>00 f<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> f </FONT>or o<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> v </FONT>nly $1<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> r </FONT>007 m<FONT face=3DArial size=3D2 =
STYLE=3D" FLOAT: right "> h </FONT>onth</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D4>Ba<FONT face=3DArial size=3D2 STYLE=3D" =
FLOAT: right "> q </FONT>d C<FONT face=3DArial size=3D2 STYLE=3D" FLOAT: =
right "> n </FONT>re<FONT face=3DArial size=3D2 STYLE=3D" FLOAT: right =
"> c </FONT>di<FONT face=3DArial size=3D2 STYLE=3D" FLOAT: right "> u =
</FONT>t O<FONT face=3DArial size=3D2 STYLE=3D" FLOAT: right "> d =
</FONT>K</DIV>
<DIV>&nbsp;</DIV>
<HR>
<DIV><FONT face=3DArial size=3D2>the path from the deep red carpets of =
the forest. Still Bombur slept and<BR>
they grew very weary. At times they heard disquieting laughter.<BR>
Sometimes there was singing in the distance too. The laughter was =
the<BR>
laughter of fair voices not of goblins, and the singing was =
beautiful,<BR></FONT></DIV></BODY></HTML>
------=_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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Andrew Johnson <andrjohn@cisco.com>
CC: Paul Aitken <paitken@cisco.com>, Juergen Quittek <quittek@netlab.nec.de>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Thu, 15 Jun 2006 11:17:56 -0500
Message-Id: <003301c6908f$29a46300$13ae555a@kcmsm>
From: "fergus bentley" <tallulahdumas@ge.com>
To: "hart thornton" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<p>FATHER'S DAY IS APPROACHING!<br>
Why pick one of our watches?</p>
<p>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
</p>
<p><font color=3D"#000000">Rolex Cartier Bvlgari Tag=20
Heuer Officine Panerai Jaeger-Lecoultre A.Lange=20
&amp; Sohne &amp; More</font></p>
<p>ORDER NOW AND SAVE 25%</p>
<A HREF=3D"http://bsaine.com/luxury/">http://bsaine.com/luxury/</A><BR>
<BR>
Jura-triassic star-fed mouse grass<BR>
ceramic engineer dog bramble weak-spirited<BR>
bay ice fresh-killed shore whiting<BR>
tooth cleaner point handle gram-molecular<BR>
lig-by deckle edge plum-brown<BR>
ash tree hi-fi dim-gleaming<BR>
self-inductive brick hammer semen contra<BR>
orra man pedal point Anti-armenian<BR>
spring-flowering Trans-euphrates Semi-manichaeanism<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
CC: ipfix-protocol@net.doit.wisc.edu
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and
 proposals
References: <FB33319DC3491454E170C4B0@[10.1.1.104]>
In-Reply-To: <FB33319DC3491454E170C4B0@[10.1.1.104]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <andrjohn@cisco.com>
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 <majordomo@mil.doit.wisc.edu>
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 <nevil@auckland.ac.nz>
To: Benoit Claise <bclaise@cisco.com>
Cc: ipfix-protocol@net.doit.wisc.edu
Subject: [ipfix-protocol] FInialising documents
References: <FB33319DC3491454E170C4B0@[10.1.1.104]>
	<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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Thu, 15 Jun 2006 19:44:18 -0500
Message-ID: <000001c690dd$f390c0c0$40b8a8c0@obp20>
Reply-To: "Dimitar Reisner" <dimitaro@jcwhitneyco.com>
From: "Dimitar Reisner" <dimitaro@jcwhitneyco.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi<BR>
<BR>ClA<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> un </DIV>LlS fr<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> ed </DIV>om o<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> is </DIV>nly $ <DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> xr </DIV>3,7<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> qv </DIV>5<BR>
VlA<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> gx </DIV>GRA fro<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> kv </DIV>m on<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> um </DIV>ly $ <DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> en </DIV>3,3<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> ne </DIV>3<BR>
Amb<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> zb </DIV>ien<BR>
Proza<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> gk </DIV>c<BR>
S<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> ez </DIV>oma<BR>
Xa<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> mg </DIV>nax<BR>
Levi<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> kq </DIV>tra<BR>
VALl<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> uf </DIV>UM fro<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> kn </DIV>m o<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> em </DIV>nly $<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> je </DIV> 1,2<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> zt </DIV>1<BR>
Meridi<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> fb </DIV>a<BR>
<BR>
<DIV>Sa<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> li </DIV>ve o<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> rq </DIV>ver 5<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> ta </DIV>0% wit<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> mx </DIV>h u<DIV STYLE =3D "=20

MARGIN: 0px;

FLOAT
:
RIGHT"> pu </DIV>s <A =
href=3D"http://www.hotsotrom.com">http://www.hotsotrom.com</A></DIV></DIV=
>
<DIV>&nbsp;</DIV><HR><DIV><FONT face=3DArial size=3D2>   Then quieter =
than a mouse he stole back. He had precious little time, <BR>he knew, =
before the spiders were disgusted and came back to their trees <BR>where =
the dwarves were hung. In the meanwhile he had to rescue them. The =
<BR>worst part of the job was getting up on to the long branch where the =
<BR>bundles were dangling. <BR>   I dont suppose he would have managed =
it, if a spider had not luckily <BR></FONT></DIV></BODY></HTML>
------=_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 <quittek@netlab.nec.de>
To: Benoit Claise <bclaise@cisco.com>,
	Andrew Johnson <andrjohn@cisco.com>
Cc: Paul Aitken <paitken@cisco.com>,
	Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
	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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
CC: Andrew Johnson <andrjohn@cisco.com>, Paul Aitken <paitken@cisco.com>,
        Gerhard Muenz <muenz@informatik.uni-tuebingen.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <quittek@netlab.nec.de>
To: Andrew Johnson <andrjohn@cisco.com>,
	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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD1E67@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ipfix-protocol] FInialising documents
Thread-Index: AcaQzTA8RfS6jS7DQNyWsPg+80pxJgAU7pbw
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Nevil Brownlee" <nevil@auckland.ac.nz>,
        "Benoit Claise" <bclaise@cisco.com>
Cc: <ipfix-protocol@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Fri, 16 Jun 2006 03:55:16 -0500
Message-ID: <000001c69122$970635c0$3493a8c0@tqx21>
Reply-To: "Jacobine Folmar" <jacobinefolmar@baystar.com>
From: "Jacobine Folmar" <jacobinefolmar@baystar.com>
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 <http://intlao.com/n/>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>R<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> w </font>ef<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> g </font>ina<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> d </font>nce $ 20<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> t </font>0 , 0<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> o </font>00 for $ 82<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> g </font>5 / mon<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> p </font>th</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D3>These R<font face=3DArial size=3D2 =
STYLE=3D"

FLOAT:

right "> a </font>ate<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> b </font>s W<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> v </font>on'<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> j </font>t L<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> v </font>ast Forever , <BR> <A =
href=3D"http://intlao.com/n/">Re<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> d </font>fi<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> o </font>nan<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> p </font>ce T<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> q </font>oda<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> d </font>y and S<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> s </font>av<font face=3DArial size=3D2 STYLE=3D"

FLOAT:

right "> y </font>e</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<HR>
<DIV><FONT face=3DArial size=3D2>passages they had come through. That =
sent them on faster than ever, and<BR>
as poor Bilbo could not possibly go half as fast-for dwarves can =
roll<BR>
along at a tremendous pace, I can tell you, when they have to-they =
took<BR>
it in turn to carry him on their backs. Still goblins go faster =
than<BR></FONT></DIV></BODY></HTML>
------=_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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; Fri, 16 Jun 2006 13:07:49 +0200 (CEST)
Date: Fri, 16 Jun 2006 13:19:01 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
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: <FB33319DC3491454E170C4B0@[10.1.1.104]>
References:  <FB33319DC3491454E170C4B0@[10.1.1.104]>
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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Andrew Johnson <andrjohn@cisco.com>
CC: Juergen Quittek <quittek@netlab.nec.de>, 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 <majordomo@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
CC: ipfix-protocol@net.doit.wisc.edu
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and
 proposals
References: <FB33319DC3491454E170C4B0@[10.1.1.104]> <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 <majordomo@mil.doit.wisc.edu>
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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
CC: Juergen Quittek <quittek@netlab.nec.de>, 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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; 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 <ipfix-protocol@net.doit.wisc.edu>; 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 <bht@cert.org>) (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: <FB33319DC3491454E170C4B0@[10.1.1.104]> <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: <A78734A2-C2F4-4CE2-90C1-7892B5745389@cert.org>
Cc: ipfix-protocol@net.doit.wisc.edu
Content-Transfer-Encoding: 7bit
From: Brian Trammell <bht@cert.org>
Subject: Re: [ipfix-protocol] Observation Domain ID uniqueness - summary and proposals
Date: Fri, 16 Jun 2006 10:26:09 -0400
To: Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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 <andrjohn@cisco.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
CC: Juergen Quittek <quittek@netlab.nec.de>, 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 <majordomo@mil.doit.wisc.edu>
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: <ipfix-archive@megatron.ietf.org>
From: =?iso-2022-jp?B?cXFx?=<brown_4_bbc@yahoo.co.jp>
Subject: =?iso-2022-jp?B?GyRCIXk1Lkp9JEAkMSRLIXkbKEI=?=
MIME-Version: 1.0
Reply-To: <brown_4_bbc@yahoo.co.jp>
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}!"<Z6b$+$i3+J|$5$l$?$$5.J}$K!"$T$C$?$j$N=w@-$r>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$N<L%a$r$^$:Aw$C$F$/$l$k$H$N;v$G$9!#G/<}(B1000$BK|!#?T$/$7$F$/$l$^$9!#(B
$B!X6a$/$NJ,>y%^%s%7%g%s$K=;$s$G$$$^$9!#;E;v$@$1$N<d$7$$KhF|$G$9!#%b%G%k$N;E;v$J$N$GKhF|$,CY$$$s$G$9!#2?;~!"5.J}$+$iO"Mm$,Mh$k$N$+?4BT$A$K$7$F$$$^$9!#IU$-9g$C$F$/$@$5$k$N$J$i!";d5.J}$K?T$/$7$^$9!#;d!"?T$/$9=w$J$s$G$9$h!#M7$S$KMh$F$/$l$?$i!"??H~$N%i%6%K%"$4CZAv$7$^$9$h!#??H~$N%l%,%7%#$G%I%i%$%V$b$7$^$;$s$+!)!Y(B
 
$B"#M3H~;R"M(Bhttp://rrnj.com?yumi
$B"#(B30$BBe8eH>(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!D<qL#$OMg$K$J$k$3$H$G$9!#%9%]!<%D%8%`$K9T$/$HCK@-$N;k@~$,$/$.IU$1$H$J$j$^$9!#0JA0!"%8%`$G%P!<%Y%k$r;}$A>e$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<g?M$,KG0W2q<R$G3$30C1?HIkG$!#BN$r$b$F$"$^$7$F$$$^$9!#$9$i$j$H$7$?5S$K$O$5$^$l$?$i:G9b$G$9!#;q;:2H!#(B
$B!X<g?M$K$OFb=o$G#T%P%C%/$O$$$F$$$^$9!#fjLg$K?)$$9~$s$G$$$/463P$,:G9b$J$N!*(B
$B$@$+$i>.$5L\$N#T%P%C%/$O$$$F$$$k$s$@$1$I!"CQ$:$+$7$$OC$@$1$I!"EE<V$NCf$G$3$C$=$jEE<VCK$K?,$r$J$G$i$l$?$H$-!"$S$C$/$j$7$F$*$J$i$7$A$c$C$?$1$I!"#T%P%C%/$O$$$F$$$?$i$*$J$i$,:81&$KJ,;6$9$k$N$G$J$s$+JQ$J46$8$G$9$1$I$M!#$*4j$$$,$"$k$N$G$9$,!";d$H$*2q$$$7$?$i;d$,$O$$$F$$$k#T%P%C%/$r;W$$$C$-$j;}$A>e$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<i$C$F$4MxMQ2<$5$$!#(B


















$B$*<j?t$G$9$,G[?.5qH]$JJ}$O$3$A$i$^$G$*4j$$$7$^$9!#(B
nomail@rrnj.com





From 187anton@brainpod.com Fri Jun 16 15:18:35 2006
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FrJpz-0002QA-Mn
	for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 15:18:35 -0400
Received: from mil.doit.wisc.edu ([128.104.31.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FrJpy-0007HK-GF
	for ipfix-archive@lists.ietf.org; Fri, 16 Jun 2006 15:18:35 -0400
Received: from 200165153064.user.veloxzone.com.br ([200.165.153.64] helo=MTM34GDEYOI6D3J.asozu2bb.net)
	by mil.doit.wisc.edu with esmtp (Exim 3.13 #1)
	id 1FrJQb-0002n8-00; Fri, 16 Jun 2006 13:52:22 -0500
From: "Hung Avery" <64broderick@fiiqmx.net>
To: <ipfix-list@mil.doit.wisc.edu>
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: <E1FrJQb-0002n8-00@mil.doit.wisc.edu>
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: <ipfix-list@mil.doit.wisc.edu>
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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
CC: Nevil Brownlee <nevil@auckland.ac.nz>, ipfix-protocol@net.doit.wisc.edu
Subject: Re: [ipfix-protocol] FInialising documents
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD1E67@is0004avexu1.global.avaya.com>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD1E67@is0004avexu1.global.avaya.com>
Content-Type: multipart/alternative;
 boundary="------------000603090904000805080505"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dan, All,<br>
<br>
I will submit the draft on Sunday, with the proposed changes in <a
 class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/3366.html">http://ipfix.doit.wisc.edu/archive/3366.html</a>.<br>
Unless someone objects.<br>
<br>
Regards, Benoit.<br>
<blockquote
 cite="midAAB4B3D3CF0F454F98272CBE187FDE2F0AAD1E67@is0004avexu1.global.avaya.com"
 type="cite">
  <pre wrap="">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


 
 

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: majordomo listserver 
[<a class="moz-txt-link-freetext" href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>] On Behalf Of Nevil Brownlee
Sent: Friday, June 16, 2006 1:42 AM
To: Benoit Claise
Cc: <a class="moz-txt-link-abbreviated" href="mailto:ipfix-protocol@net.doit.wisc.edu">ipfix-protocol@net.doit.wisc.edu</a>
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 
<a class="moz-txt-link-freetext" href="http://www.auckland.ac.nz">http://www.auckland.ac.nz</a>


--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" 
in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say 
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->
--
Help        <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext" href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext" href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------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 <xm-%XBPSID-ipfix-list@mil.doit.wisc.edu@ambasciatoripalace.com>)
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" <Cora.Ross@ambasciatoripalace.com> 
From: "Leon Goodrich" <Cora.Ross@ambasciatoripalace.com> 
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 <ipfix-list@mil.doit.wisc.edu>; Sat, 17 Jun 2006 03:32:46 -0500
Message-Id: <004a01c691dd$f6241e80$bcb0322d@juzuvzy>
From: "esra gleason" <kamilahstone@too.de>
To: "crichton carmichael" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
How much are you paying for your Home? To much? <BR>
You have been pre-approved to fill out for a ref inance laon, <BR>
if you need some cash to spend ANY way you like, or simply wish <BR>
to LOWER your monthly payments by a third or more, etc.<BR>
Apply online now for your instant quote. Stop over paying... <BR>
<BR>
<A HREF=3D"http://travag.org/d2/">http://travag.org/d2/</A><BR>
<BR>
warrant officer turning engine truck farm rage-swelling grass snake<BR>
zeal-inspiring bob veal<BR>
pear thorn alfalfa meal bedbug hunter hornblende-gabbro chance-won dusky-ma=
ntled<BR>
F-flat sleeve target scrap rubber grim-visaged glow light<BR>
mind-healing school child seven-horned<BR>
damper rail chassis painter self-imposed<BR>
well-launched air-formed yard slings strange-favored violet-scented<BR>
gate tower fair-traded<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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: <ipfix-list@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; 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 <ipfix-list@mil.doit.wisc.edu>; 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" <LorenzoRice@0451.com>
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: <E1Frqg6-0003iw-00@mil.doit.wisc.edu>
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" <faithalfaro@djmag.com>
To: "devin bernal" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<p><strong>FATHER'S DAY GIFTS<br>
</strong><strong>Order Now and Save 25%</strong><br>
<br>
<font color=3D"#339900"><strong>Luxury Timepieces</strong></font><br>
<font color=3D"#999999">~-~-~-~-~-~-~-~-~-~-~-~-</font> <br>
<font color=3D"#00CC33">Rolex<br>
Cartier<br>
Bvlgari<br>
Tag Heuer <br>
Officine Panerai <br>
& More</font></p>
<p><strong><font color=3D"#339999">Designer Neckties</font></strong><br>
<font color=3D"#999999">~-~-~-~-~-~-~-~-~-~-~-~-</font> <br>
<font color=3D"#33CCCC">Versace<br>
Fendi<br>
Armani<br>
& More</font></p>
<p><strong><font color=3D"#006699">Brand Name Pens</font></strong><font col=
or=3D"#006699">=20
(including refills)</font><br>
<font color=3D"#999999">~-~-~-~-~-~-~-~-~-~-~-~-</font> <br>
<font color=3D"#0099CC">Mont-Blanc<br>
Cartier<br>
St. Dupont </font></p>
<A HREF=3D"http://prakisa.com/luxury/">http://prakisa.com/luxury/</A><BR>
<BR>
telpher railway twice-destroyed backing jointer<BR>
breaker-off tick doleru two-hand<BR>
partition law wind-pollination statute-barred<BR>
master builder deep-transported life-lengthened<BR>
service charge gourdhead buffalo ring-chain tautomerism<BR>
whitening stone Rhode islander group-connect<BR>
Iceland gull unself-assertive gray-cheeked<BR>
tangent-sawed re-elevate ice collar<BR>
table-tail bearskin jobber weak-ankled<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <bclaise@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Benoit Claise <bclaise@cisco.com>
CC: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, 
 Nevil Brownlee <nevil@auckland.ac.nz>,
  ipfix-protocol@net.doit.wisc.edu
Subject: Re: [ipfix-protocol] FInialising documents
References: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD1E67@is0004avexu1.global.avaya.com> <44931943.3020205@cisco.com>
In-Reply-To: <44931943.3020205@cisco.com>
Content-Type: multipart/alternative;
 boundary="------------050804070000030203000409"
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear all,<br>
<blockquote cite="mid44931943.3020205@cisco.com" type="cite">Dan, All,<br>
  <br>
I will submit the draft on Sunday, with the proposed changes in <a
 class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/3366.html">http://ipfix.doit.wisc.edu/archive/3366.html</a>.<br>
</blockquote>
FYI, done. The draft should appear in a few days.<br>
<br>
Regards, Benoit.<br>
<blockquote cite="mid44931943.3020205@cisco.com" type="cite">Unless
someone objects.<br>
  <br>
Regards, Benoit.<br>
  <blockquote
 cite="midAAB4B3D3CF0F454F98272CBE187FDE2F0AAD1E67@is0004avexu1.global.avaya.com"
 type="cite">
    <pre wrap="">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


 
 

  </pre>
    <blockquote type="cite">
      <pre wrap="">-----Original Message-----
From: majordomo listserver 
[<a class="moz-txt-link-freetext"
 href="mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wisc.edu</a>] On Behalf Of Nevil Brownlee
Sent: Friday, June 16, 2006 1:42 AM
To: Benoit Claise
Cc: <a class="moz-txt-link-abbreviated"
 href="mailto:ipfix-protocol@net.doit.wisc.edu">ipfix-protocol@net.doit.wisc.edu</a>
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 
<a class="moz-txt-link-freetext" href="http://www.auckland.ac.nz">http://www.auckland.ac.nz</a>


--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" 
in message body
Unsubscribe <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say 
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>

    </pre>
    </blockquote>
    <pre wrap=""><!---->
--
Help        <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say "help" in message body
Unsubscribe <a class="moz-txt-link-freetext"
 href="mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wisc.edu</a> and say
"unsubscribe ipfix" in message body
Archive     <a class="moz-txt-link-freetext"
 href="http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/archive/</a>
  </pre>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--------------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: <E1Fs2MO-0007DA-00@mil.doit.wisc.edu>
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 <ipfix-protocol@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD27BC@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ipfix-protocol] FInialising documents
Thread-Index: AcaTBkfy+SSTtV9vQw6b1TeYCTg8mwAWc/wg
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Benoit Claise" <bclaise@cisco.com>
Cc: "Nevil Brownlee" <nevil@auckland.ac.nz>,
        <ipfix-protocol@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2912" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D361352005-19062006><FONT face=3DArial color=3D#0000ff =

size=3D2><STRONG><EM>Thanks for the effort. =
</EM></STRONG></FONT></SPAN></DIV>
<DIV><SPAN class=3D361352005-19062006><STRONG><EM><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D361352005-19062006><STRONG><EM><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Do you have the draft available so that it can be referred to =
before it=20
shows up in the I-D repository? </FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=3D361352005-19062006><STRONG><EM><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></EM></STRONG></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D361352005-19062006><STRONG><EM><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Dan</FONT></EM></STRONG></SPAN></DIV>
<DIV><SPAN class=3D361352005-19062006></SPAN>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Benoit Claise =
[mailto:bclaise@cisco.com]=20
  <BR><B>Sent:</B> Sunday, June 18, 2006 9:37 PM<BR><B>To:</B> Benoit=20
  Claise<BR><B>Cc:</B> Romascanu, Dan (Dan); Nevil Brownlee;=20
  ipfix-protocol@net.doit.wisc.edu<BR><B>Subject:</B> Re: =
[ipfix-protocol]=20
  FInialising documents<BR></FONT><BR></DIV>
  <DIV></DIV>Dear all,<BR>
  <BLOCKQUOTE cite=3Dmid44931943.3020205@cisco.com type=3D"cite">Dan,=20
    All,<BR><BR>I will submit the draft on Sunday, with the proposed =
changes in=20
    <A class=3Dmoz-txt-link-freetext=20
    =
href=3D"http://ipfix.doit.wisc.edu/archive/3366.html">http://ipfix.doit.w=
isc.edu/archive/3366.html</A>.<BR></BLOCKQUOTE>FYI,=20
  done. The draft should appear in a few days.<BR><BR>Regards, =
Benoit.<BR>
  <BLOCKQUOTE cite=3Dmid44931943.3020205@cisco.com type=3D"cite">Unless =
someone=20
    objects.<BR><BR>Regards, Benoit.<BR>
    <BLOCKQUOTE=20
    =
cite=3DmidAAB4B3D3CF0F454F98272CBE187FDE2F0AAD1E67@is0004avexu1.global.av=
aya.com=20
    type=3D"cite"><PRE wrap=3D"">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

  </PRE>
      <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">-----Original =
Message-----
From: majordomo listserver=20
[<A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@mil.doit.wisc.edu">mailto:majordomo@mil.doit.wis=
c.edu</A>] On Behalf Of Nevil Brownlee
Sent: Friday, June 16, 2006 1:42 AM
To: Benoit Claise
Cc: <A class=3Dmoz-txt-link-abbreviated =
href=3D"mailto:ipfix-protocol@net.doit.wisc.edu">ipfix-protocol@net.doit.=
wisc.edu</A>
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
<A class=3Dmoz-txt-link-freetext =
href=3D"http://www.auckland.ac.nz">http://www.auckland.ac.nz</A>


--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help"=20
in message body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say=20
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>

    </PRE></BLOCKQUOTE><PRE wrap=3D""><!---->
--
Help        <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say "help" in message body
Unsubscribe <A class=3Dmoz-txt-link-freetext =
href=3D"mailto:majordomo@net.doit.wisc.edu">mailto:majordomo@net.doit.wis=
c.edu</A> and say
"unsubscribe ipfix" in message body
Archive     <A class=3Dmoz-txt-link-freetext =
href=3D"http://ipfix.doit.wisc.edu/archive/">http://ipfix.doit.wisc.edu/a=
rchive/</A>
  </PRE></BLOCKQUOTE><BR></BLOCKQUOTE><BR></BLOCKQUOTE></BODY></HTML>

------_=_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 <quittek@netlab.nec.de>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Cc: Benoit Claise <bclaise@cisco.com>,
	Nevil Brownlee <nevil@auckland.ac.nz>,
	ipfix-protocol@net.doit.wisc.edu
Subject: RE: [ipfix-protocol] FInialising documents
Message-ID: <BDB5718762AA04D86B61C298@[192.168.1.128]>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD27BC@is0004avexu1.global.avaya.com>
References:  <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD27BC@is0004avexu1.global.avaya.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 <majordomo@mil.doit.wisc.edu>
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
<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.txt>

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 <ipfix-protocol@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD28F5@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ipfix-protocol] FInialising documents
Thread-Index: AcaTbnOFwrVLfjOYTOSpM8RtPly6uAAAE5CA
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>
Cc: "Benoit Claise" <bclaise@cisco.com>,
        "Nevil Brownlee" <nevil@auckland.ac.nz>,
        <ipfix-protocol@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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
> <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-
> 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: <E1FsEXH-000568-00@mil.doit.wisc.edu>
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 <quittek@netlab.nec.de>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>,
	Benoit Claise <bclaise@cisco.com>
Cc: Nevil Brownlee <nevil@auckland.ac.nz>,
	ipfix-protocol@net.doit.wisc.edu
Subject: RE: [ipfix-protocol] FInialising documents
Message-ID: <9020E6EFB91C2108ABF0B27C@[10.1.1.104]>
In-Reply-To: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD27BC@is0004avexu1.global.avaya.com>
References:  <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD27BC@is0004avexu1.global.avaya.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 <majordomo@mil.doit.wisc.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c

Dan,

Please find all three documents at

<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-architecture-11.txt>
<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-protocol-22.txt>
<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.txt>

    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 <ipfix-protocol@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AAD29A3@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ipfix-protocol] FInialising documents
Thread-Index: AcaTeMFjv/cqi9bDS0utaF52tnD1wwAANcnQ
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>,
        "Benoit Claise" <bclaise@cisco.com>
Cc: "Nevil Brownlee" <nevil@auckland.ac.nz>,
        <ipfix-protocol@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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
> <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-
architecture-11.txt>
<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-protocol-2
2.txt>
<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.tx
t>

    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 <ipfix-list@mil.doit.wisc.edu>; 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" <ignacya@asbellho.com>
From: "Ignacy Rooks" <ignacya@asbellho.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV></DIV>
<DIV><STRONG></STRONG><IMG =
src=3D"cid:000101c693fe$8ed9aaa6$4c3aa8c0@ahb91"><STRONG></STRONG></DIV>
<FONT></FONT>
<DIV><SPAN></SPAN><A =
href=3D"http://parstripo.com">http://parstripo.com</A><B></B></DIV>
<FONT></FONT>
<DIV>
<HR><P></P>
</DIV><B></B>
<DIV><FONT></FONT>   Why, O why did I ever bring a wretched little =
hobbit on a treasure<BR>
hunt! said poor Bombur, who was fat, and staggered along with the =
sweat<BR>
dripping down his nose in his heat and terror.<BR>
   At this point Gandalf fell behind, and Thorin with him. They turned =
a<BR>
sharp corner. About turn! he shouted. Draw your sword, Thorin! There<BR>
was nothing else to be done; and the goblins did not like it. They =
came<BR><I></I></DIV></BODY></HTML>
------=_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 <paitken@cisco.com>
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 <andrjohn@cisco.com>
CC: Benoit Claise <bclaise@cisco.com>, Juergen Quittek <quittek@netlab.nec.de>,
        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 <majordomo@mil.doit.wisc.edu>
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 <ipfix@net.doit.wisc.edu>; Tue, 20 Jun 2006 17:35:22 +0200 (CEST)
Date: Tue, 20 Jun 2006 17:47:01 +0200
From: Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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
<ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.txt>.

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
<ftp://ftp.netlab.nec.de/pub/ipfix/diff-11-12.html>.

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: <E1FsmEc-0003cU-Fz@stiedprstage1.ietf.org>
Date: Tue, 20 Jun 2006 15:50:02 -0400
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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: <E1FsmEb-0003au-S5@stiedprstage1.ietf.org>
Date: Tue, 20 Jun 2006 15:50:01 -0400
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Wed, 21 Jun 2006 00:05:32 -0500
Message-ID: <000001c694f0$50b0be20$52b5a8c0@euc27>
Reply-To: "Ilaria Tomlinson" <ilaru@bienestar.org>
From: "Ilaria Tomlinson" <ilaru@bienestar.org>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<FONT></FONT>
<DIV><FONT></FONT><IMG =
src=3D"cid:000101c694f0$50ae658a$52b5a8c0@euc27"><P></P></DIV>
<P></P>
<DIV><P></P><A =
href=3D"http://saounfadewon.com">http://saounfadewon.com</A><B></B></DIV>=

<B></B>
<DIV>
<HR><SPAN></SPAN>
</DIV><SPAN></SPAN>
<DIV><I></I>   He scowled so angrily at Gloin that the dwarf huddled =
back in his<BR>
chair; and when Bilbo tried to open his mouth to ask a question, he<BR>
turned and frowned at him and stuck oat his bushy eyebrows, till =
Bilbo<BR>
shut his mouth tight with a snap. Thats right, said Gandalf. Lets<BR>
have no more argument. I have chosen Mr. Baggins and that ought to =
!6te<BR>
enough for all of you. If I say he is a Burglar, a Burglar he is, =
or<BR><P></P></DIV></BODY></HTML>
------=_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 <Jerry@brars.org.uk>
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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=windows-1251"
 http-equiv="Content-Type">
  <title>Read inside</title>
</head>
<body bgcolor="#ffffff" text="#000000">
<table align=center width=60%><tr><td>
<h3>Highly Paid Secondary Job</h3>

<p>
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.

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

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

<p>Requirements: You need to have Internet access and email.

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

<p>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. 

<p>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. 


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


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

<p>Thank You,<br>
Elsie Howard<br>


<p>Permission Settings 
<br><br>
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.
<br><br>
Steinberg Investments Inc.<br>
5360 Genesee Street<br>
Bowmansville, New York<br>

Phone: +1 (917) 591-7848<br>
</td></tr></table>
</body>
</html>

--------------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 <ipfix-list@mil.doit.wisc.edu>; Wed, 21 Jun 2006 12:05:46 -0500
Message-ID: <000001c69554$f11255e0$0b24a8c0@rrk97>
Reply-To: "Sami Evert" <everto@jasperbanking.com>
From: "Sami Evert" <everto@jasperbanking.com>
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
<http://stikalogaser.com>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><A href=3D"http://stikalogaser.com">Save over 50% on your =
medications with our online STORE</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV>Faerie in the West. There the Light-elves and the Deep-elves and =
the<BR>
Sea-elves went and lived for ages, and grew fairer and wiser and =
more<BR>
learned, and invented their magic and their cunning craft, in the =
making<BR>
of beautiful and marvellous things, before some came back into the =
Wide<BR>
World. In the Wide World the Wood-elves lingered in the twilight of =
our<BR>
Sun and Moon but loved best the stars; and they wandered in the =
great<BR></DIV></BODY></HTML>
------=_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: <E1Ft8i9-0003mJ-Sq@stiedprstage1.ietf.org>
Date: Wed, 21 Jun 2006 15:50:01 -0400
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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" <hargeru@atwc.teradyne.com>
From: "Mitchell Harger" <hargeru@atwc.teradyne.com>
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
<http://yontomahon.com>=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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><A href=3D"http://yontomahon.com">Save over 50% on your medications =
with our online STORE</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV>Bilbo). There is nothing like looking, if you want to find =
something (or<BR>
so Thorin said to the young dwarves). You certainly usually find<BR>
something, if you look, but it is not always quite the something you<BR>
were after. So it proved on this occasion.<BR>
   Soon Fili and Kili came crawling back, holding on to the rocks in =
the<BR>
wind. We have found a dry cave, they said, not far round the =
next<BR></DIV></BODY></HTML>
------=_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 <irino.hitoshi@lab.ntt.co.jp>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
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 <majordomo@mil.doit.wisc.edu>
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
> <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.txt>.
> 
> 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
> <ftp://ftp.netlab.nec.de/pub/ipfix/diff-11-12.html>.
> 
> 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 <ipfix@net.doit.wisc.edu>; 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 <ipfix@net.doit.wisc.edu>;
 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 <ipfix@net.doit.wisc.edu>; 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 <muenz@informatik.uni-tuebingen.de>
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 <majordomo@mil.doit.wisc.edu>
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.

<ftp://ftp.ietf.org/internet-drafts/draft-muenz-ipfix-configuration-00.txt>

_______________________________________________
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 <ipfix@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AB49243@is0004avexu1.global.avaya.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [ipfix] IPFIX-AS draft version 09
Thread-Index: AcaV9UwayRswx6y2SVuKo2LXNPVA0wAANu1Q
From: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
To: "Tanja Zseby" <Tanja.Zseby@fokus.fraunhofer.de>, <ipfix@net.doit.wisc.edu>
Cc: "Bernard Aboba" <aboba@internaut.com>,
        "Gray, Eric" <Eric.Gray@marconi.com>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AB49278@is0004avexu1.global.avaya.com>
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\)" <dromasca@avaya.com>
To: <iesg@ietf.org>, <ietf@ietf.org>
Cc: <ipfix@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 '
>    <draft-ietf-ipfix-as-08.txt> 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" <nessmbh1@bonbon.net>
To: <ipfix-list@mil.doit.wisc.edu>
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: <E1FtQ42-0007Mo-00@mil.doit.wisc.edu>
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 <ipfix@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AB49415@is0004avexu1.global.avaya.com>
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\)" <dromasca@avaya.com>
To: "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>, <iesg@ietf.org>,
        <ietf@ietf.org>
Cc: <ipfix@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 '
> >    <draft-ietf-ipfix-as-08.txt> 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" <Tanja.Zseby@fokus.fraunhofer.de>
To: <ipfix@net.doit.wisc.edu>
Cc: "Bernard Aboba" <aboba@internaut.com>,
   "Gray, Eric" <Eric.Gray@marconi.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Thu, 22 Jun 2006 14:13:42 -0500
Message-ID: <000001c6962f$fac3e7d0$6f61a8c0@dhu54>
Reply-To: "Ursula Wooster" <ursu@ad.funnel.revenuedirect.com.akadns.net>
From: "Ursula Wooster" <ursu@ad.funnel.revenuedirect.com.akadns.net>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>V / A G R A from 3,33 <A =
href=3D"http://malisaborin.com">http://malisaborin.com</A></DIV>
<DIV>&nbsp;</DIV>
<DIV>and many other</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV>beating of his wings.<BR>
   Amid shrieks and wailing and the shouts of men he came over them, =
swept<BR>
   towards the bridges and was foiled! The bridge was gone, and his<BR>
enemies were on an island in deep water-too deep and dark and cool =
for<BR>
his liking. If he plunged into it, a vapour and a steam would arise<BR>
enough to cover all the land with a mist for days; but the lake =
was<BR></DIV></BODY></HTML>
------=_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: <ipfix-list@mil.doit.wisc.edu>
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: <E1FtXzu-0007tX-6X@stiedprstage1.ietf.org>
Date: Thu, 22 Jun 2006 18:50:02 -0400
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <quittek@netlab.nec.de>
To: Hitoshi Irino <irino.hitoshi@lab.ntt.co.jp>
Cc: ipfix@net.doit.wisc.edu
Subject: Re: [ipfix] new version of the IPFIX information model
Message-ID: <F95272E5446D52D2E0A37CE2@[192.168.1.128]>
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 <majordomo@mil.doit.wisc.edu>
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
>> <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.txt>.
>>
>> 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
>> <ftp://ftp.netlab.nec.de/pub/ipfix/diff-11-12.html>.
>>
>> 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" <Tanja.Zseby@fokus.fraunhofer.de>
To: "Bernard Aboba" <aboba@internaut.com>
Cc: <ipfix@net.doit.wisc.edu>, "Gray, Eric" <Eric.Gray@marconi.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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" <Tanja.Zseby@fokus.fraunhofer.de>
To: "Gray, Eric" <Eric.Gray@marconi.com>, <ipfix@net.doit.wisc.edu>
Cc: "Bernard Aboba" <aboba@internaut.com>,
   "Romascanu, Dan \(Dan\)" <dromasca@avaya.com>
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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" <mdqcmnyazln@hotmail.com>
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: <E1Fu1pJ-0003L5-00@mil.doit.wisc.edu>
Date: Sat, 24 Jun 2006 01:41:06 -0500
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370

<h1 a]ign="center">University Degree</h1>
<div align="center"><br>
  OBTAIN @ PR0SPEROUS FUTURE, MONEY-E@RNING <acm></acm>POWER,<BR>AND THE PRESTIGE THAT COMES 
  WITH HAVING THE CAREER POSITION YOU'VE<BR>ALWAYS DREAMED OF. DIPLOMA FROM<BR>PRESTIGIOUS 
  NON-ACCREDITED<BR>UNVERSITIES BASED ON YOUR PRESENT <acj></acj>KNOWLEDGE AND PROFESSIONAL 
  <acw></acw>EXPERIENCE.<br>
  <i><font size="4"><b><font size="5">If you qualify, no required tests, classes, <acc></acc>
  books <acf></acf>or examinations.</font></b></font></i> <font size="5"><b><br>
  </b></font><br>
  <b><font size="5">Confidentiality Assured<br>
  </font></b><br>
  <font color="#FF0033" size="+2"><b>1-815-828-2222</b></font><br>
  24 hours a day, 7 days a week including Sundays and Holidays<br>
</div><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>Harry crossed <acb></acb>to the dishwasher, took out <acu></acu>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 <ipfix-list@mil.doit.wisc.edu>; Sat, 24 Jun 2006 02:48:16 -0500
Message-Id: <200606240748.k5O7mA25028814@smtp.doit.wisc.edu>
From: "Estella" <cranston_maleah@gamebox.net>
To: <ipfix-list@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Sat, 24 Jun 2006 02:55:15 -0500
Message-Id: <200606240755.k5O7tDTC029509@smtp.doit.wisc.edu>
From: "Cleveland" <tyndale_o@phreaker.net>
To: <ipfix-list@mil.doit.wisc.edu>
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" <noreply@mil.doit.wisc.edu>
To: <ipfix-list@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Sat, 24 Jun 2006 21:47:09 -0500
Message-Id: <009001c697f9$7c9db900$4f309674@oibrkbs>
From: "daveen acosta" <chaneswanson@lucasforums.com>
To: "celisse sherman" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<p>TOP BRANDS - LOW LOW PRICES</p>
<p>Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets </p>
<p>Leather, silk and white gold sound good? Visit our site for real photos.=
<br>
Everything comes with a certificate, tags and all the extras, plus a warran=
ty.</p>
<A HREF=3D"http://jesselansing.com/luxury/">http://jesselansing.com/luxury/=
</A><BR>
<BR>
machine-wrought true-paced head lamp<BR>
base clef barnyard golf pre-emptory<BR>
all-pervasive twice-noted kitchen garden<BR>
register office yacht ensign late-cruising<BR>
jolly jumper leakage conductance quarter-mile<BR>
class number tongue-blade pennant fish<BR>
same-minded gentleman-adventurer sab-cat<BR>
buzz planer Non-swedish flutter kick<BR>
ketch-rigged pseudo occupation crater basin<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <ipfix@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AB4988B@is0004avexu1.global.avaya.com>
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\)" <dromasca@avaya.com>
To: "Tanja Zseby" <Tanja.Zseby@fokus.fraunhofer.de>,
        "Gray, Eric" <Eric.Gray@marconi.com>, <ipfix@net.doit.wisc.edu>
Cc: "Bernard Aboba" <aboba@internaut.com>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Sun, 25 Jun 2006 05:05:56 -0500
Message-ID: <000001c6983e$e83883d0$80bea8c0@ead87>
Reply-To: "Utz Mackenzie" <mackenzi@firstnetva.com>
From: "Utz Mackenzie" <mackenzi@firstnetva.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
X & N A X<BR>
<STRONG>V A L / U M</STRONG><BR>
M E R / D / A<BR>
<B>V / A G R A</B><BR>
S O M ^<BR>
P R O Z & C<BR>
L E V / T R A<BR>
<B>C / A L / S</B><BR>
A M B / E N<BR>
<BR>
all 50 % off - <A =
href=3D"http://www.omeredatte.com">http://www.omeredatte.com</A><BR>
<BR>
</DIV>
<HR>
<DIV>stamped. They knew the sword at once. It had killed hundreds of =
goblins <BR>in its time, when the fair elves of Gondolin hunted them in =
the hills or <BR>did battle before their walls. They had called it =
Orcrist, <BR>Goblin-cleaver, but the goblins called it simply Biter. =
They hated it <BR>and hated worse any one that carried it. Murderers and =
elf-friends! <BR>the Great Goblin shouted. Slash them! Beat them! Bite =
them! Gnash them! <BR></DIV></BODY></HTML>
------=_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 <ipfix@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0AB96F31@is0004avexu1.global.avaya.com>
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\)" <dromasca@avaya.com>
To: "Juergen Quittek" <quittek@netlab.nec.de>,
        "Hitoshi Irino" <irino.hitoshi@lab.ntt.co.jp>
Cc: <ipfix@net.doit.wisc.edu>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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
> <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-
info-12.txt>.
>>
>> 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 <ftp://ftp.netlab.nec.de/pub/ipfix/diff-11-12.html>.
>>
>> 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: <ipfix-list@mil.doit.wisc.edu>
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 <manju_r_99@yahoo.com>
Subject: [ipfix] RE:I-D ACTION:draft-manjunath-ipfix-shifted-feedback-00.txt 
To: ipfix@net.doit.wisc.edu
Cc: Dan Romascanu <dromasca@avaya.com>,
  David Kessens <david.kessens@nokia.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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:
<http://www1.ietf.org/pipermail/i-d-announce> 
List-help:
<mailto:i-d-announce-request@ietf.org?subject=help> 
List-id: i-d-announce.ietf.org 
List-post: <mailto:i-d-announce@ietf.org> 
List-subscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=subscribe>

List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=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.

<ftp://ftp.ietf.org/internet-drafts/draft-manjunath-ipfix-shifted-feedback-00.txt>
_______________________________________________
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" <jyxohqyhrda@hotmail.com>
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: <E1FudvV-00038o-00@mil.doit.wisc.edu>
Date: Sun, 25 Jun 2006 18:22:03 -0500
X-Spam-Score: 3.3 (+++)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f

<h1 @l1gn="center">Univer$ity Degree</h1>
<div @lign="center"><br>
  OBTAIN <acl></acl>A PROSPEROUS FUTURE, MONEY-EARNING POWER,<BR>AND THE PRESTIGE THAT COMES 
  WITH HAVING THE CAREER POSITION YOU'VE<BR>ALWAYS DREAMED <acp></acp>OF. DIPLOMA FROM<BR>PRESTIGIOUS 
  NON-ACCREDITED<BR>UNVERSITIES BASED ON <aca></aca>YOUR PRESENT KNOWLEDGE AND PROFESSIONAL 
  EXPERIENCE.<br>
  <i><font size="4"><b><font size="5">If you qualify, <acj></acj>no required tests, classes, 
  books or examinations.</font></b></font></i> <ack></ack><font size="5"><b><br>
  </b></font><br>
  <b><font size="5">Confidentiality Assured<br>
  </font></b><br>
  <font color="#FF0033" size="+2"><b>1-815-828-2222</b></font><br>
  <acf></acf>24 hours a day, 7 days a week including <acr></acr>Sundays and Holidays<br>
</div><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR> leaving it only to go to the bathroom. Three times that day A
unt <acb></acb>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 <irino.hitoshi@lab.ntt.co.jp>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Juergen Quittek <quittek@netlab.nec.de>
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> <F95272E5446D52D2E0A37CE2@[192.168.1.128]>
In-Reply-To: <F95272E5446D52D2E0A37CE2@[192.168.1.128]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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
>>> <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.txt>. 
>>>
>>>
>>> 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
>>> <ftp://ftp.netlab.nec.de/pub/ipfix/diff-11-12.html>.
>>>
>>> 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 <ipfix-list@mil.doit.wisc.edu>; Mon, 26 Jun 2006 00:50:07 -0500
Message-ID: <000001c698e3$e180f180$47cfa8c0@tnm80>
Reply-To: "Martzel Luke" <luke@compufort.com>
From: "Martzel Luke" <luke@compufort.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi,<BR>
<BR>
S O M ^<BR>
P R O Z & C<BR>
A M B / E N<BR>
M E R / D / A<BR>
<B>C / A L / S</B><BR>
X & N A X<BR>
L E V / T R A<BR>
<STRONG>V A L / U M</STRONG><BR>
<B>V / A G R A</B><BR>
<BR>
all 50 % off - <A =
href=3D"http://www.chyahoo.com/o/">http://www.chyahoo.com/o/</A><BR>
<BR>
</DIV>
<HR>
<DIV>his hiding-place he kept a few wretched oddments, and one very =
beautiful <BR>thing, very beautiful, very wonderful. He had a ring, a =
golden ring, a <BR>precious ring. <BR>   My birthday-present! he =
whispered to himself, as he had often done <BR>in the endless dark days. =
Thats what we wants now, yes; we wants it! <BR>He wanted it because it =
was a ring of power, and if you slipped that <BR></DIV></BODY></HTML>
------=_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 <quittek@netlab.nec.de>
To: Hitoshi Irino <irino.hitoshi@lab.ntt.co.jp>
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> <F95272E5446D52D2E0A37CE2@[192.168.1.128]> <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 <majordomo@mil.doit.wisc.edu>
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
>>>> <ftp://ftp.netlab.nec.de/pub/internet-drafts/draft-ietf-ipfix-info-12.txt>.
>>>>
>>>>
>>>> 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
>>>> <ftp://ftp.netlab.nec.de/pub/ipfix/diff-11-12.html>.
>>>>
>>>> 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" <ginellejacobson@uaportal.com>
To: "broderic riddle" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<p>TOP BRANDS - LOW LOW PRICES</p>
<p>Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets </p>
<p>Leather, silk and white gold sound good? Visit our site for real photos.=
<br>
Everything comes with a certificate, tags and all the extras, plus a warran=
ty.</p>
<A HREF=3D"http://poonered.com/luxury/">http://poonered.com/luxury/</A><BR>
<BR>
splay-kneed land side vengeance-sated<BR>
terror-bringing quasi-spatial you-uns<BR>
emulsion colloid cash sale limousine-landaulet<BR>
troop train injury-proof soft-haired<BR>
air machine trouble shooting vice-admiralship<BR>
harvest queen pedal board cradle snatcher<BR>
warp beam Non-jewish ostrich-egg<BR>
derrick making capacity factor grain-cleaning<BR>
feather cloth self-addiction disability insurance<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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" <kkslrxcelxn@hotmail.com>
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: <E1FutAL-0007Wa-00@mil.doit.wisc.edu>
Date: Mon, 26 Jun 2006 10:38:22 -0500
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32

<h1 align="center">A <acz></acz>Genuine University Degree <acr></acr>in 4-6 weeks!</h1>
<div align="center"><br>
  Have you <acc></acc>ever thought that the only thing stopping you from a great job and 
  better pay was a few letters behind you name?<br>
  Well now you can get them!<br>
 <acw></acw> <br>
  <b><font size="+3">BA BSc MA MSc MBA PhD</font></b><br>
  <br>
  <font size="+2"><b>Within 4-6 weeks!<br>
  No Study Required!<br>
  100% Verifiable!</b></font><br>
  <acp></acp><br>
  These are real, genuine degrees <acu></acu>that <acv></acv>include Bachelors, Masters, MBA and Doctorate 
  Degrees. They are fully verifiable <acn></acn>and certified transcripts are also available. <acs></acs>
  <br>
  <br>
  <b><font size="5">Just call the number below.<br>
  <acv></acv>You’ll thank me later…<br>
  </font></b><br>
  <font color="#FF0033" size="+2"><b>1-815-828-2222</b></font><br>
  24 <acy></acy>hours a day, 7 <ack></ack>days a week including Sundays and Holidays<br>
</div><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR
><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>nine <aca></aca>months in what he <acb></acb>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 <ipfix@net.doit.wisc.edu>; 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 <ipfix@net.doit.wisc.edu>;
 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 <ipfix@net.doit.wisc.edu>; 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 <ipfix@net.doit.wisc.edu>; 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 <nevil@auckland.ac.nz>
To: ipfix <ipfix@net.doit.wisc.edu>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Tue, 27 Jun 2006 04:25:30 -0500
Message-Id: <000501c699c3$0f3d8400$3a9fdddc@qjuhfeq>
From: "mackenzie franco" <mychalchampagne@covad.com>
To: "wrennie griffith" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<CENTER>
How many times did you think of giving up your<br>
permanent job and join another "good looking"<br>
work-at-home scheme? And how many of them were<br>
successful? Did you earn more than $5000 a month with<br>
them? NO? Then you have an opportunity right now and<br>
right here!<br>
<br>
We made it possible for you to get a real part-time<br>
job in a world of  transportation business and control<br>
your income on your own! We will never ask you about<br>
your credit rating and never put any inquiries to your<br>
credit profile. This is business of partners, we don't<br>
take, we give you this opportunity<br>
<br>
You can become our Representative and take part in a<br>
stunning world of financial operations. No more<br>
up-front costs or tricks. A steady income is just a<br>
click away! The best thing it all depends on you.<br>
<br>
Being a long-established solid corporation we<br>
understand how important it is to provide our customers<br>
the best possibilities and support. We always try our<br>
best to be cooperative and customer-friendly, you can<br>
call or email us any time and ask a question if<br>
something is not clear.<br>
<br>
Get involved in a great  transportation business, and<br>
start making money in just a few clicks. You will make<br>
a fixed amount ($30) out of every shipped product. The<br>
usual product quantity range from 10 to 100 packages a<br>
month. This is not a dream, you enter a serious market!<br>
A unique opportunity where your income depends on you!<br>
<br>
More information \ apply \ send your resumes to: job@easternbridge.info<br>
<BR>
saddle clip yellow-checked pseudo romanticism<BR>
eyelet hole dust seal round-table conference<BR>
bread beetle wool hall spinous-tailed<BR>
quercitron lake mountain-loving quasi craft<BR>
fever-lurden Pre-thanksgiving match lining<BR>
sour-visaged end-measure gray-black<BR>
world-serving wax-bearing red-coated<BR>
clew jigger tie-tie quarter-bound<BR>
</FONT></DIV></BODY>=
</HTML>

------=_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 <ipfix-list@mil.doit.wisc.edu>; Tue, 27 Jun 2006 10:18:27 -0500
Message-Id: <200606271518.k5RFIQOO001209@smtp.doit.wisc.edu>
From: "Carlton" <z_rash@bonbon.net>
To: <ipfix-list@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Tue, 27 Jun 2006 14:04:15 -0500
Message-ID: <000001c69a1c$fc9f06c0$cd0fa8c0@xsw2>
Reply-To: "Ba Mcduffy" <mcduffyo@amer-law.com>
From: "Ba Mcduffy" <mcduffyo@amer-law.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi<BR>
<BR>
Go to our site and econom ize on your med up to 60 %<BR><A =
href=3D"http://xundasefunterx.com">http://xundasefunterx.com</A></DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>breakfast for you, if only you wont have me for supper.<BR>
   Poor little blighter, said William. He had already had as much<BR>
supper as he could hold; also he had had lots of beer. Poor little<BR>
blighter! Let him go!<BR>
   Not till he says what he means by lots and none at all, said =
Bert.<BR>
I dont want to have me throat cut in me sleep. Hold his toes in =
the<BR></DIV></BODY></HTML>
------=_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" <goltzinicol@imgh.org>
From: "Nicolau Goltz" <goltzinicol@imgh.org>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi<BR>
<DIV>,</DIV>
Go to the site and economize up to 60 % on your med<BR><A =
href=3D"http://rungandeoinca.com">http://rungandeoinca.com</A></DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>they were locked in one anothers arms, and rolling nearly into the =
fire<BR>
kicking and thumping, while Tom whacked at then both with a branch =
to<BR>
bring them to their senses-and that of course only made them madder =
than<BR>
ever. That would have been the time for Bilbo to have left. But his =
poor<BR>
little feet had been very squashed in Berts big paw, and he had no<BR>
breath in his body, and his head was going round; so there he lay for =
a<BR></DIV></BODY></HTML>
------=_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 <dressler@informatik.uni-erlangen.de>
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 <majordomo@mil.doit.wisc.edu>
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 <ipfix@net.doit.wisc.edu>; 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: <AAB4B3D3CF0F454F98272CBE187FDE2F0ABDDABA@is0004avexu1.global.avaya.com>
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\)" <dromasca@avaya.com>
To: "IESG Secretary" <iesg-secretary@ietf.org>
Cc: "Nevil Brownlee" <n.brownlee@auckland.ac.nz>,
        "Dave Plonka" <plonka@doit.wisc.edu>, <ipfix@net.doit.wisc.edu>,
        "Juergen Quittek" <quittek@netlab.nec.de>
X-Scanner: InterScan AntiVirus for Sendmail
Precedence: bulk
Sender: majordomo listserver <majordomo@mil.doit.wisc.edu>
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 <plonka@doit.wisc.edu> with
Juergen Quittek <quittek@netlab.nec.de> 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 <n.brownlee@auckland.ac.nz> Dave Plonka=20
> <plonka@doit.wisc.edu>=20
>=20
>=20
> Operations and Management Area Director(s):
> Dan Romascanu <dromasca@avaya.com>=20
> David Kessens <david.kessens@nokia.com>=20
>=20
> Operations and Management Area Advisor:
> Dan Romascanu <dromasca@avaya.com>=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" <caily@ediets.com>
From: "Rosamond Cail" <caily@ediets.com>
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 <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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<P><FONT face=3DArial><STRONG>SA<font face=3DArial style=3D"FLOAT: =
right"> s </font>VE UP TO 5<font face=3DArial style=3D"FLOAT: right"> f =
</font>0 %</STRONG> on your <STRONG>PH<font face=3DArial style=3D"FLOAT: =
right"> a </font>ARMAC<font face=3DArial style=3D"FLOAT: right"> l =
</font>Y</STRONG> !</FONT></P>
<P><A href=3D"http://tocasonal.com"><FONT =
face=3DArial>http://tocasonal.com</FONT></A></P>
<P><FONT face=3DArial>V<font face=3DArial style=3D"FLOAT: right"> c =
</font>IAG<font face=3DArial style=3D"FLOAT: right"> k </font>RA <FONT =
color=3D#cc0000><STRONG>$ 6<font face=3DArial style=3D"FLOAT: right"> u =
</font>9,9<font face=3DArial style=3D"FLOAT: right"> a =
</font>5</STRONG></FONT> ( 10 t<font face=3DArial style=3D"FLOAT: =
right"> a </font>able<font face=3DArial style=3D"FLOAT: right"> y =
</font>ts )</FONT></P>
<P><FONT face=3DArial>V<font face=3DArial style=3D"FLOAT: right"> r =
</font>ALI<font face=3DArial style=3D"FLOAT: right"> j </font>UM <FONT =
color=3D#cc0000><STRONG>$ 10<font face=3DArial style=3D"FLOAT: right"> t =
</font>5,4<font face=3DArial style=3D"FLOAT: right"> h =
</font>5</STRONG></FONT> ( 10 t<font face=3DArial style=3D"FLOAT: =
right"> i </font>abl<font face=3DArial style=3D"FLOAT: right"> v =
</font>ets )</FONT></P>
<P><FONT face=3DArial>C<font face=3DArial style=3D"FLOAT: right"> o =
</font>IAL<font face=3DArial style=3D"FLOAT: right"> w </font>IS <FONT =
color=3D#cc0000><STRONG>$ 9<font face=3DArial style=3D"FLOAT: right"> j =
</font>9,9<font face=3DArial style=3D"FLOAT: right"> v =
</font>5</STRONG></FONT> ( 10 t<font face=3DArial style=3D"FLOAT: =
right"> t </font>ablet<font face=3DArial style=3D"FLOAT: right"> j =
</font>s )</FONT></P>
<P><FONT face=3DArial>X<font face=3DArial style=3D"FLOAT: right"> l =
</font>ANA<font face=3DArial style=3D"FLOAT: right"> l </font>X <FONT =
color=3D#cc0000><STRONG>$ 12<font face=3DArial style=3D"FLOAT: right"> q =
</font>3,4<font face=3DArial style=3D"FLOAT: right"> q =
</font>5</STRONG></FONT> ( 30 ta<font face=3DArial style=3D"FLOAT: =
right"> z </font>ble<font face=3DArial style=3D"FLOAT: right"> m =
</font>ts )</FONT></P>
<P><FONT face=3DArial>AM<font face=3DArial style=3D"FLOAT: right"> c =
</font>BIE<font face=3DArial style=3D"FLOAT: right"> s </font>N <FONT =
color=3D#cc0000><STRONG>$ 6<font face=3DArial style=3D"FLOAT: right"> x =
</font>8,0<font face=3DArial style=3D"FLOAT: right"> r =
</font>0</STRONG></FONT> ( 10 t<font face=3DArial style=3D"FLOAT: =
right"> o </font>able<font face=3DArial style=3D"FLOAT: right"> l =
</font>ts )</FONT></P>
<P><FONT face=3DArial>And ma<font face=3DArial style=3D"FLOAT: right"> o =
</font>ny othe<font face=3DArial style=3D"FLOAT: right"> d </font>r =
</FONT></P></FONT></DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>building themselves places to live in among the more pleasant woods =
in<BR>
the valleys and along the river-shores. There were many of them, and<BR>
they were brave and well-armed, and even the Wargs dared not attack =
them<BR>
if there were many together, or in the bright day. But now they had<BR>
planned with the goblins help to come by night upon some of the<BR>
villages nearest the mountains. If their plan had been carried =
out,<BR></DIV></BODY></HTML>
------=_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" <wysongagijsbert@dority-manning.com>
From: "Gijsbert Wysong" <wysongagijsbert@dority-manning.com>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi<BR>
<DIV>,</DIV>
Go to the web site and economise up to 50 % on your Med <A =
href=3D"http://aturalabur.com">http://aturalabur.com</A></DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>,</DIV>
<DIV>   Victory had been assured before the fall of night, but the =
pursuit<BR>
was still on foot, when Bilbo returned to the camp; and not many were =
in<BR>
the valley save the more grievously wounded.<BR>
   Where are the Eagles? he asked Gandalf that evening, as he lay<BR>
wrapped in many warm blankets.<BR>
   Some are in the hunt, said the wizard, but most have gone back =
to<BR></DIV></BODY></HTML>
------=_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: <ipfix-list@mil.doit.wisc.edu>
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: <E1FwKus-0005Iv-00@mil.doit.wisc.edu>
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 <ipfix-list@mil.doit.wisc.edu>; Fri, 30 Jun 2006 14:06:37 -0500
Message-ID: <e1d701c69c77$e57062f9$f5ec5d4f@yemeni.cc>
From: yancy <yiannis4013theobald@yemeni.cc>
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

<p>viagra 100mg - 1.56$<br>
  cialis 20mg - 3$<br>
  levitra 20 mg - 2.78$</p>
<ul>
  <li><font size=3D"2"><strong><font face=3D"Verdana, Arial, Helvetica, =
sans-serif">We guarantee <font color=3D"#FF0000">100% top-quality of the=
 product we offer</font></font></strong></font></li>
  <li><font size=3D"2"><strong><font face=3D"Verdana, Arial, Helvetica, =
sans-serif">We offer a money-back guarantee in case the product doesn't =
work for you or you may be somehow dissatisfied by its =
performance</font></strong></font></li>
  <li><font size=3D"2"><strong><font face=3D"Verdana, Arial, Helvetica, =
sans-serif"> We've efficiently streamlined our service, letting you buy =
from us in a very discreet, non-embarrassing and hassle-free manner =
</font></strong></font></li>
</ul>
<p>special offer - click <a =
href=3D"http://fepjbucqjwlv5v4e1eht88jv8qjd8q8.pickeeai.com/?elhat">here=
</a> <br>
</p>



------=_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" <desireewilder@hotbox.com>
To: "vernor jeffers" <ipfix-list@mil.doit.wisc.edu>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3DWindows-1252">
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>
<p>TOP BRANDS - LOW LOW PRICES</p>
<p>Jewelry * Handbags * Pens * Watches * Neckties * Clutches * Wallets </p>
<p>Leather, silk and white gold sound good? Visit our site for real photos.=
<br>
Everything comes with a certificate, tags and all the extras, plus a warran=
ty.</p>
<A HREF=3D"http://grownews.com/luxury/">http://grownews.com/luxury/</A><BR>
<BR>
slime thickening tank dome field poa grass<BR>
horse dam needle diatom fire clay<BR>
balm leaf light-complexioned palsy-quaking<BR>
fixation pause thrill-sated tar-boiling<BR>
offertory veil V thread tear-purchased<BR>
Anti-athanasian broad-set wasp nest<BR>
cerium dioxide back letter iron family<BR>
drag fold box beam large-viewed<BR>
winning gallery post-obit fork-tined<BR>
</FONT></DIV></BODY>=
</HTML>

------=_NextPart_000_00D8_01C69C90.D20E1600--





